有许多不同的方法可以使用LLM进行构建,包括从头开始训练模型、微调开源模型或使用托管API。我们在这里展示的堆栈是基于上下文学习的,这是我们看到的大多数开发人员一开始的设计模式(现在只有基础模型才有可能)。
下一节将简要解释这种模式;有经验的LLM开发人员可以跳过本节。
设计模式:情境学习
上下文学习的核心思想是使用现成的LLM(即,没有任何微调),然后通过对私人“上下文”数据的巧妙提示和条件调节来控制他们的行为。
例如,假设你正在构建一个聊天机器人来回答有关一组法律文件的问题。采取一种天真的方法,您可以将所有文档粘贴到ChatGPT或GPT-4提示中,然后在最后询问有关它们的问题。这可能适用于非常小的数据集,但不会扩展。最大的GPT-4模型只能处理大约50页的输入文本,当你接近这个极限时,性能(通过推理时间和准确性来衡量)会严重下降,这被称为上下文窗口。
上下文学习用一个聪明的技巧解决了这个问题:它不是在每个LLM提示下发送所有文档,而是只发送少数最相关的文档。最相关的文件是在…的帮助下确定的。你猜对了。LLM。
在非常高的级别上,工作流可以分为三个阶段:
数据预处理/嵌入:这个阶段涉及存储私人数据(在我们的例子中是法律文件),以便稍后检索。通常,文档被分解成块,通过嵌入模型传递,然后存储在一个称为向量数据库的专门数据库中。
提示构造/检索:当用户提交查询(在这种情况下是法律问题)时,应用程序构造一系列提示以提交到语言模型。编译后的提示通常结合了由开发人员硬编码的提示模板;有效输出的示例称为少镜头示例;从外部API检索到的任何必要信息;以及从矢量数据库检索到的一组相关文档。
即时执行/推理:一旦编译了提示,它们就会提交给预先训练的LLM进行推理——包括专有模型API和开源或自训练模型。一些开发人员还在这个阶段添加了日志记录、缓存和验证等操作系统。
这看起来工作量很大,但通常比其他选择更容易:培训或微调LLM本身。你不需要一个专门的ML工程师团队来进行上下文学习。您也不需要托管自己的基础设施,也不需要从OpenAI购买昂贵的专用实例。这种模式有效地将人工智能问题简化为大多数初创公司和大公司已经知道如何解决的数据工程问题。对于相对较小的数据集,它也往往优于微调——因为一条特定的信息需要在训练集中出现至少约10次,LLM才能通过微调记住它——并且可以近乎实时地合并新数据。
上下文学习中最大的问题之一是:如果我们只是改变底层模型以增加上下文窗口,会发生什么?这确实是可能的,而且是一个活跃的研究领域(例如,请参阅Hyena的论文或这篇最近的帖子)。但这需要进行一些权衡——主要是推理的成本和时间与提示的长度成二次方。如今,对于许多应用来说,即使是线性缩放(最佳理论结果)也会导致成本过高。按照目前API的价格,一个超过10000页的GPT-4查询将花费数百美元。因此,我们不希望基于扩展的上下文窗口对堆栈进行大规模更改,但我们将在文章正文中对此进行更多评论。
继续阅读