独家 | 如何为GenAI应用程序选择架构

数据派THU

共 9643字,需浏览 20分钟

 ·

2024-10-25 17:00

    
作者:Lak Lakshamanan
翻译:陈之炎
校对:ZRX
本文约6200字,建议阅读10+分钟
本文将描述一个框架,助力实现多因素之间的平衡。

标签:LLM,智能体,设计模式


选取最简单、最快、最便宜的架构,以平衡LLMs的创造力和风险。

假设希望LLM生成一封感谢信,首先需要查看LLM教程,按照教程中建议的方式调用API,发送提示语,并使用响应。具体可以这样做:

虽然这可以用于实现概念验证(PoCs),但如果将LLM仅视为一个文本转文本(或文本转图像/音频/视频)API并将其投入生产,那么需要兼顾风险、成本和延迟等因素。

解决方案应避免走向极端,通过微调LLM并通过添加护栏来解决过度设计应用程序。目标与其他工程项目一样,根据每个用例的具体情况找到复杂性、适用性、风险、成本和延迟之间的平衡。本文将描述一个框架,助力实现多因素之间的平衡。

LLM应用程序架构的框架

本框架用来决定GenAI应用程序或智能体的架构,将在以下各节中介绍下图中显示的八种方案。

为GenAI应用程序选取正确的应用程序架构。图表由作者提供。

这里的坐标轴(即,决策标准)分别是风险和创造力,在每个使用LLM的用例中,首先需要确定LLM的创造力以及用例所承担的风险量。通过缩小选择范围,找到适合的平衡点。

请注意,是否使用Agentic系统是一个完全独立的决策,当任务太复杂,无法通过单个LLM调用来完成,或者任务需要非LLM功能时,应使用Agentic系统。此时,可以将复杂任务分解为简单的任务,并在智能体框架中协调风险和创造力。本文将展示如何构建一个GenAI应用程序(或代理)来执行这些任务。

为什么首要的决策标准是创造力

为什么坐标轴是创造力和风险?因为LLMs是一种非确定性技术,这种不确定性在现实中带来的麻烦要比它能带来的价值要多出许多。

例如,如果LLM生成了一个产品目录页面,它与现实中真的产品目录区别有多大?客户希望获得有关产品的准确信息,他们并不在乎SLR相机页面,并以相同的方式解释SLR技术的好处——实际上,一定程度的标准化会更有利于轻松比对LLM生成的内容,这是一个对LLM的创造力要求比较低的案例。

事实证明,非确定性较小的架构可以减少对LLM的总调用次数,由此降低使用LLM的总体成本。由于LLM调用比典型的网络服务慢,同时减少了传输延迟。这就是为什么y轴是创造力,为什么在坐标轴上也有成本和延迟。

说明:按创造力排序的用例。图表由作者提供

查看上图中列出的不同用例,探讨不同用例是否需要低创造力或高创造力。这取决于不同商业应用的场景,如果客户是一家杂志或广告代理机构,那么即便是信息性内容网页(与产品目录页面不同)也同样需要有创造力。

为什么第二个决策标准是风险

LLM会生成幻觉细节,并反映出训练数据中的偏见和毒性。鉴于此,直接将LLM生成的内容发送给最终用户存在一定的风险。该问题的解决增加了项目的复杂性——需要引入人工审核内容,或者添加护栏来验证生成的内容是否违反政策。

如果用例中允许最终用户向模型发送提示,应用程序在后端采取动作(在许多SaaS产品中常见的情况)以生成面向用户的反应,那么与错误、幻觉和毒性相关的风险就相当高。

同样的用例(艺术生成)会根据上下文携带不同级别和种类的风险,如下图所示。例如,如果需要为电影生成背景音乐,相关的风险会涉及错误地复制受版权保护的音乐,而如果需要生成广告图像或视频广播,则会担心毒性的发生。

不同类型的应用面临的风险程度各不相同。举另一个例子,如果需要构建一个企业搜索应用程序,该应用程序返回企业文档存储库中技术文档的片段,与LLM相关的风险则相当低。如果文档存储库由医学教科书组成,搜索应用程序返回的上下文外内容的风险会很高。

说明:按风险排序的用例。图表由作者提供。

就像按创造力排序的用例列表一样,可以对按风险排序的用例顺序提出异议。但是一旦确定了与用例相关的风险和它所需的创造力,将以推荐的架构作为起点。在了解这些架构模式背后的“为什么”之后,可以选择一个合适架构以平衡不同的需求。

在后文中,将从图表中的#1开始顺序描述不同架构。

1. 单次内容生成(适用于高创造力、低风险任务)

这是默认的架构模式——每次想要生成内容时,都会调用部署的LLM的API。这是最简单的,每次内容生成都需要进行LLM调用。

通常,会使用PromptTemplate,并根据运行时参数模板,发送给LLM的提示。当无需更换LLM的框架时,是一个好的选择。

对于需要根据提示发送电子邮件的示例,可以使用langchain:


因为每次内容生成都在调用LLM,所以它只适用于需要极高创造力的任务(例如,希望每次都生成不同内容的感谢信)以及不担心有风险的场景(例如,最终用户在点击“发送”之前可以阅读和编辑该笔记)。

这种模式通常适用于需要响应各种提示的交互式应用程序(需要对各种提示做出响应)并面向内部用户(因此风险较低)。

2. 响应/提示缓存(适用于中等创造力、低风险任务)

这种情况不会再次向同一个人发送相同的感谢信,而是每次生成不同内容的感谢信。

如果需要根据过往历史查询构建一个搜索引擎,例如,协助内部客户的支持团队?在这种情况下,希望对重复问题每次都生成相同的答案。

能大幅降低成本和延迟的一种方法是缓存过去的提示和响应。可以使用langchain在客户端实现此类缓存:


当缓存过去的提示和响应之后,缓存的响应只花了1/1000的时间,并完全避免了LLM调用。

缓存的用途不仅限于客户端缓存确切的文本输入及其相应的响应(见下图)。Anthropic支持“提示缓存”,可以要求模型在服务器端缓存部分提示的内容(通常是系统提示和重复的上下文),同时在每个后续查询中继续发送新的指令。使用提示缓存减少了每次查询的成本和延迟,同时不影响创造力。当示例数量变大时,它在RAG、文档提取和少量提示时特别有帮助。

响应缓存减少了LLM调用的数量,上下文缓存减少了单次调用中处理的令牌数量。它们减少了总令牌数量,降低了成本和延迟。图表由作者提供。

Gemini将此功能分离为上下文缓存(它降低了成本和延迟)和系统指令(它们不减少标记数量,但降低了延迟)。OpenAI最近宣布支持提示缓存,在预先设置好API之后,能实现自动缓存,当提示超过1024个标记时,能保存先前发送到API的提示的最长前缀。这种服务器端缓存不会降低模型的性能,但能降低延迟和/或成本,因为相同的文本提示会获得不同的结果。

内置的缓存方法需要精确的文本匹配。然而,可以利用案例之间的细微差别实现缓存。例如,可以将提示重写为规范形式以增加缓存命中的机会。另一个常见技巧是存储一百个最频繁的问题,对于相似的问题,可以重写提示并存储询问的问题。在多轮聊天机器人中,甚至可以让用户确认这种语义相似性。这种语义缓存技术会降低模型的性能,因为类似的提示会获得相同的响应。

3. 预生成模板(适用于中等创造力、低至中等风险任务)

有时,要求对每个处于相同情况的不同个人生成相同的感谢信,比如需要向购买相同产品的不同客户写感谢信,并且不介意对任何购买该产品的客户生成相同的感谢信。

这个用例风险度会更高,因为这些感谢信是发送给最终用户的,并且没有内部工作人员在发送之前编辑确认每封生成的信件。

在这种情况下,可以预先生成模板化响应。例如,假设客户是一家旅游公司,提供了5种不同的套餐。需要为这些套餐中的每一种类别都写一封感谢信,或许需要为独自旅行者、家庭与团体提供不同的信息,此时需要有3倍于套餐数量的信息。

针对不同团体类型和旅游目的地,生成如下结果:

生成这些消息之后,让真人审核它们,并将它们存储到数据库中。

如图所示,要求LLM在消息中插入占位符,可以动态替换这些占位符。每当需要发送响应时,可以从数据库中检索消息并将占位符替换为实际数据。

使用预生成模板将一个需要每天审核数百条消息的问题转变为只需要在添加新旅游时审核几条消息的问题。

4. 小型语言模型(低风险,低创造力)

最近的研究表明,由于大模型学习无法穷尽所有可计算函数之间的关系,消除LLMs中的幻觉是不可能的。对于更有针对性的任务,较小的LLM比过大的模型产生幻觉的风险要小。或许,您可能正在使用前沿的LLM来执行不需要如此强大的模型便可执行的任务。

比如有一个非常简单的任务,它是一个不需要太多创造力并且风险容忍度非常低的用例,可以选择使用小型语言模型(SLM)。这确实会牺牲准确率——在2024年6月的一项研究中,微软的研究人员发现,对于从对应于发票的非结构化文本中提取结构化数据,利用较小的基于文本的模型(Phi-3 Mini 128K)便可以达到93%的准确率,而GPT-4o可以实现99%的准确率。

LLMWare团队评估了大量的SLM。在撰写本文方面(2024年),他们发现Phi-3是性能最好的,但随着时间的推移,更小的模型便能实现这种性能。

用图表表示这两项研究,SLM正在利用越来越小的模型实现同样的准确率(幻觉越来越少),而LLM一直专注于通过越来越大的模型增加任务性能(幻觉越来越多)。小型语言模型在文档提取等任务上的准确率差异已经稳定(见下图)。

趋势是SLM使用越来越小的模型获得相同的准确率,而LLM专注于通过越来越大的模型获得更强的性能。简单任务上的准确率差异已经稳定。图表由作者提供。

如果这种趋势持续下去,预计未来将越来越多地使用SLM和非前沿LLM来执行更多只需要低创造力并且风险容忍度低的企业任务。从文档中创建嵌入,例如知识检索和主题建模是非常适合这种配置文件的用例。对于这些任务,请使用小型语言模型。

5. 组装重排(中等风险,低创造力)

组装重排背后的基本思想是使用预生成来降低动态内容的风险,并仅将LLM用于提取和总结,这些任务即使需要实时完成,也只会引入低级别的风险。

假设机械零件的制造商需要为产品目录中的每个项目创建一个网页,此时需要关注准确率。不希望错误地将不耐热产品声称为是耐热的产品,不希望LLM根据幻想安装零件。

此时有一个描述每个零件属性的数据库。一个简单的方法是使用LLM为每个属性生成内容。与预生成模板(模式#3中所述)一样,在将内容存储到内容管理系统之前,应确保有人工对它们进行审核。

但是,简单地将所有LLM生成的文本添加进来将不利于阅读,可以将所有生成的内容组装到提示的上下文中,并要求LLM将内容重排为所需的网站布局:

如果需要总结评论,或关于该配件的交易文章,可以在批处理管道中完成这项工作,并将摘要输入上下文。

6. ML选择模板(中等创造力,中等风险)

组装重排方法适用于内容相当静态的网页(如产品目录页面)。然而,如果是电子商务零售商想创建个性化推荐,内容则更加动态。此时,需要LLM提供更高的创造力,在准确率方面的风险容忍度仍然相同。

此时,可以继续为单个产品使用预生成模板,然后使用机器学习来选取将要使用的模板。

对于个性化推荐,例如,可以使用传统的推荐引擎来选择将向用户显示哪些产品,并为该产品加入适当的预生成内容(图像+文本)。

这种结合预生成+ML的方法可以为不同的客户旅程定制网站。将预生成着陆页,并使用倾向模型来选择下一个最佳动作。

7. 微调(高创造力,中等风险)

如果要求高创造力,无法避免使用LLM来生成所需要的内容。但是,每次生成内容又无法进行人工审核。

解决这个难题有两种方法。从工程复杂性的角度来看,较为简单的一种方法是教LLM生成想要的内容类型,通过微调来实现。

微调基础模型有三种方法:适配器调整、蒸馏和人类反馈,三种微调方法分别对应不同的风险:

  • 适配器调整保留了基础模型的全部能力,但允许选择特定的风格(例如,适配公司的内容),它解决的风险是品牌风险。
  • 蒸馏与基础模型的能力近似,但在有限的任务集上,可以在本地部署更小的模型,或在防火墙后面部署模型,它解决的风险是保密性。
  • 利用RLHF或DPO的人类反馈是提高模型准确性的起点,但人类反馈会更好些,它解决的风险是适用性。

微调的常见用例包括能够创建品牌内容、总结机密信息和个性化内容。

8. 护栏(高创造力,高风险)

如果想要全方位的功能,并且有多种类型的风险需要缓解——也许担心品牌风险、机密信息泄露和/或希望通过反馈进行持续改进?

那时,别无选择,只能全力以赴构建护栏。护栏涉及预处理输入模型的信息,后处理模型的输出,或根据错误条件迭代提示。

预构建的护栏(例如Nvidia的NeMo)的常用功能很多,如检查越狱、在输入中屏蔽敏感数据和事实自检。

必须自己构建护栏。图表由作者提供。

然而,必须自行实现一些护栏(见上图)。需要与可编程护栏一起部署的应用程序是最为复杂的实现GenAI应用程序的方式。在走这条路之前,请确保这种复杂性是合理的。

总结

建议使用一个平衡创造力和风险的框架来决定GenAI应用程序或智能体的架构。创造力指的是生成内容所需的独特性水平,风险是如果LLM生成不准确、有偏见或有毒内容的话带来的影响。解决高风险场景需要提高项目复杂性,如人工审核或护栏。

该框架由八种架构模式组成,分别解决不同的创造力和风险组合:

1.单次生成:每次内容生成请求都调用LLM API,提供最大创造力,但成本和延迟更高。适用于没有太多风险的交互式应用程序,如内部工具。
2. 响应/提示缓存:适用于中等创造力、低风险任务。缓存过去的提示和响应以降低成本和延迟。当需要一致的答案时会很有用,如内部客户支持搜索引擎。提示缓存、语义缓存和上下文缓存等技术在不牺牲创造力的情况下能提高效率。
3. 预生成模板:使用预先生成、审核过的模板实现重复性任务,减少对持续人工审核的需求。适用于中等创造力、低至中等风险情况,其中需要标准化但个性化的内容,如旅游公司的客户端通信。
4. 小型语言模型(SLM):与较大的LLM相比,使用较小的模型来降低幻觉和成本。适用于低创造力、低风险任务,如用于知识检索或主题建模的嵌入创建。
5. 组装重排:使用LLM进行重排和总结,预生成内容以确保准确率。适用于内容如产品目录,在某些内容部分需要准确率,而其他部分需要创意写作。
6. ML选择模板:利用机器学习根据用户上下文选择适当的预生成模板,平衡个性化与风险管理。适用于个性化推荐或动态网站内容。
7. 微调:微调LLM以生成所需内容,同时最小化不需要的输出,解决与品牌声音、机密性或准确率相关的风险。适配器调整侧重于风格调整,蒸馏侧重于特定任务,人类反馈侧重于持续改进。

8. 护栏:高创造力、高风险任务需要护栏来缓解多种风险,包括品牌风险和机密性,通过预处理、后处理和迭代提示。护栏能解决常见的问题,如越狱和敏感数据屏蔽,定制护栏需要满足特殊的行业/应用程序要求。

通过使用上述框架来构建GenAI应用程序,将能够为每个用例平衡复杂性、适用性、风险、成本和延迟。

(定期提醒:这些帖子是我个人观点,不是我的现雇主或前雇主的观点)


作者简介:

本文由Lak Lakshmanan撰写

1.06K关注者 · Towards Data Science撰稿人

本文是个人观察,并非投资建议。


原文标题:How to Choose the Architecture for Your GenAI Application
原文链接:https://towardsdatascience.com/how-to-choose-the-architecture-for-your-genai-application-6053e862c457

编辑:黄继彦





作者简介





陈之炎,北京交通大学通信与控制工程专业毕业,获得工学硕士学位,历任长城计算机软件与系统公司工程师,大唐微电子公司工程师,现任北京吾译超群科技有限公司技术支持。目前从事智能化翻译教学系统的运营和维护,在人工智能深度学习和自然语言处理(NLP)方面积累有一定的经验。业余时间喜爱翻译创作,翻译作品主要有:IEC-ISO 7816、伊拉克石油工程项目、新财税主义宣言等等,其中中译英作品“新财税主义宣言”在GLOBAL TIMES正式发表。能够利用业余时间加入到THU 数据派平台的翻译志愿者小组,希望能和大家一起交流分享,共同进步



转载须知

如需转载,请在开篇显著位置注明作者和出处(转自:数据派ID:DatapiTHU),并在文章结尾放置数据派醒目二维码。有原创标识文章,请发送【文章名称-待授权公众号名称及ID】至联系邮箱,申请白名单授权并按要求编辑。

发布后请将链接反馈至联系邮箱(见下方)。未经许可的转载以及改编者,我们将依法追究其法律责任。





关于我们

数据派THU作为数据科学类公众号,背靠清华大学大数据研究中心,分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识,努力建设数据人才聚集平台、打造中国大数据最强集团军。




新浪微博:@数据派THU

微信视频号:数据派THU

今日头条:数据派THU


点击“阅读原文”拥抱组织


浏览 35
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报