当构建需要多次调用大型语言模型 (LLM) 来完成任务的生成式 AI 应用程序时，一个常见的问题是对 LLM 的重复查询可能既昂贵又不可预测。 GPT-3.5/4 等大型模型对于训练和运行推理来说非常耗费资源；这反映在 API 费用以及偶尔的服务中断中。 ChatGPT 最初作为研究预览版发布，并不打算用于生产应用程序。然而，它在众多应用程序中的实用性是无可争议的，因此人们对法学硕士的兴趣激增。
自 ChatGPT 诞生以来，用户一直在寻找解决使用 GPT 时缺乏隐私以及无法控制正常运行时间或推理设置的方法。这导致了免费公共模型（例如 Meta 的Llama 2）的流行，以及后来创建了可以在消费类硬件上运行的 Llama 的量化和低参数版本。这些公共模型能够以更少的计算能力提供与 GPT 相同的功能，但代价是参数更少和详细输出更少。
如果您的应用程序不一定依赖于处理过大的上下文或生成详细的输出，那么在您控制的实例上托管您自己的推理可能是一个更具成本效益的选择。当涉及到检索增强生成（RAG）的实际应用时，成本差异可能会变得更加显着。
我将演示一种简单的方法，将向量存储、词法搜索和提示工程相结合，以在商品硬件上执行准确的 RAG。使用这种方法，您既可以降低大量信息的复杂性，又可以使大规模运行的生成式 AI 应用程序更加准确、高效且经济高效。通过在特定的信息存储上使用 RAG，您可以消除幻觉并从任何源材料创建有效且知识丰富的代理，而无需支付第三方 API 费用。
首先，您将需要 DataStax Enterprise 7 实例或DataStax Astra DB来存储向量和文本数据，以及 LLM 和句子转换器模型来生成响应并使用向量对数据进行编码。根据数据或用户提示的复杂性，您还可以考虑将其与 DataStax Enterprise 6.8 数据库结合使用，该数据库可以执行Solr搜索以匹配更广泛的数据，这就是我在本示例中使用的数据库。 DataStax 不断致力于改进，以便通过单个数据库实现所有这些操作，但目前，我使用两个数据库。
解决幻觉
无论你选择哪个LLM，他们都仍然患有幻觉。目前，需要通过在 LLM（也称为 RAG）提示上下文中提供真实信息来解决该限制。查找信息并将其转换为提示的方法完全取决于您的数据模型，但您可以通过使用矢量数据库以更有效的方式找到更相关的信息。
举例来说，假设您有一系列关于您想要探索的主题的电子书，例如如何玩《战锤 40,000》 。在正常情况下，需要花费数年的时间来阅读支持文献并获得足够的游戏经验才能达到专家水平。
有针对性的问题，例如“你能告诉我关于 Adepta Sororitas 的 Morvenn Vahl 的什么信息吗？”资深玩家或战锤商店的任何员工都可以回答这个问题。虽然 ChatGPT 可以回答有关游戏的许多问题，但不幸的是它没有涵盖这个特定角色的训练数据：
将此与托管在配备 Nvidia RTX A4000 显卡的消费者工作站上的 Llama 2 13B 参数 LLM 进行比较。同样，该模型可以展示战锤宇宙的基本知识，但由于调整，该模型并不关心角色是否被发现，而是提供了尽力而为的幻觉：
如果你想构建一个可以帮助新手和老手玩战锤 40,000 的聊天机器人，那么这些输出是不可接受的。要成为有效的游戏指南，聊天机器人需要了解游戏规则、每个单元的规则、一些知识点以及一些策略和评论。幸运的是，有关第 10 版规则的所有信息都可以从 Games Workshop 和粉丝网站免费获得，您所需要做的就是让您的聊天机器人应用程序可以搜索到这些信息。
将此与相同的 13B Llama 模型进行比较，其中使用 RAG，要求比较 Morvenn Vahl 上的几个来源，并根据用户提示设计相关答案。这次，聊天机器人可以访问搜索数据库和矢量数据库，其中包含有关如何玩《战锤 40,000》第 10 版的所有公开信息：
多么不同啊！它不仅找到有关这个小众角色的相关信息，而且还使其输出符合如何使用第 10 版规则玩游戏的上下文。
所有这一切中最困难的部分是执行有效的搜索以找到相关页面以输入法学硕士。这就是矢量数据库特别有用的地方。
应用向量
在此示例中，我们将使用在 Docker 实例中运行的 DSE 7 和 DSE 6.8 来满足聊天机器人应用程序的数据库要求，该应用程序需要能够比较向量并执行词法搜索。 DSE 7 和 Astra DB 引入了存储向量和执行向量搜索以及通过文本匹配进行过滤的功能。我们只需要搜索几十本示例书籍，因此在 Docker 中运行 DSE 实例对于大多数消费类硬件来说就足够了。
在数据库中使用向量将有助于查找与给定查询相似的文档，或者它们可用于比较从其他搜索检索到的结果。这可以帮助您克服词汇搜索的局限性并提高数据模型的有效性。
例如，电子书 PDF 等内容可以受益于使用miniLM等句子转换器进行编码，并且向量可用于在查询和给定源之间运行相似性比较。在这种情况下，句子转换器模型用于在电子书中创建页面文本的嵌入，这可以使您能够与用户的提示进行比较，以确定结果是否与查询相关。相关页面应包含一个或多个与用户查询相似的术语实例，并且从模型的角度来看会产生更好的相似度分数。
也就是说，向量最好用作现有词汇搜索模型的补充。如果您仅按向量搜索，那么您最终可能会意外地检索到不相关的文档，并将它们作为不适用的上下文提供。
在此示例中，查询“您能告诉我有关 Adepta Sororitas 的 Morvenn Vahl 的什么信息吗？”法学硕士可以将其转换为一组简单的搜索词：
Morvenn, Vahl, Adepta, Sororitas
查找相关文档的第一步是搜索包含这些基本术语的文档。这可以通过首先过滤数据库中的文本匹配以查找页面文本中与此类查询匹配的关键字来完成。使用LLM生成关键字的原因是为了提供更广泛的可能关键字进行搜索，因为它经常尝试添加更多相关但不在原始提示文本中的关键字。不过，请小心这一点，因为法学硕士还可能生成您需要清理的特殊字符和奇怪的序列。
一旦获得至少一个结果，您就可以对用户的查询进行向量化，并将其与词法搜索的向量进行比较，从而为每个结果的相关程度创建分数。这使您可以检查搜索结果的查询准确性，并在最终向法学硕士提交结果时设置拒绝不相关结果的阈值。
在这种情况下，第一步应该匹配专门显示 Morvenn Vahl 的索引卡或游戏机制的页面，因为这些页面描述了角色的单位在游戏中的表现。如果页面满足应用程序确定的与用户查询的特定相关性阈值，则会对其进行汇总并放置在结果列表中。
最后，搜索结果可以被编译成一个列表并反馈给法学硕士，法学硕士被要求使用最相关的上下文来回答原始查询。这是流程的可视化：
正如您所看到的，法学硕士在这个流程中被频繁调用。法学硕士负责将用户提示转换为关键字，总结适用的结果，并选择最能回答查询的上下文。每个要检查的源都会添加另一个 LLM 调用，这在查询 GPT 时可能会非常昂贵。但如果你已经有了所需的信息，只是想对其进行总结或改造，那么你可能不需要使用这么大的模型。事实上，改用较小的型号可以带来很多好处。
通过使用较小的 LLM，您可以减少每个查询的计算成本，随着时间的推移，这可以带来显着的节省。这还可以缩短用户的响应时间，从而改善他们的整体体验。在此示例中，RAG 是使用小型 LLM 和小型数据库执行的，所有这些都托管在同一 GPU 实例上，需要大约 30 秒的时间来检索 15 个源、分析它们的相关性并提供最终答案。提示（源）越短，返回输出的速度就越快。
此外，该方法还可以提高安全性和可扩展性。通过及时的工程设计和对法学硕士的调用管道，您可以完全控制数据的访问方式以及用户将在响应中得到什么。在资源使用方面，示例 13B 参数模型仅消耗略高于 8GB 的 VRAM，并且仍然提供相关答案。根据需要，这甚至显示出在无数其他平台（例如用户工作站和移动设备）上运行 RAG 的潜力。
控制输出
及时的工程设计是让 RAG 完全按照您的要求行事的关键。您可以控制聊天机器人如何解释数据以及它应该思考的上下文。在此示例中，我们希望确保聊天机器人知道我们正在专门寻找战锤信息，因此我们可以首先要求它帮助为用户的查询提供支持上下文：
查询：“<用户查询>”
给我一个用于搜索引擎的最小的、以逗号分隔的《战锤 40K》关键字列表。仅响应查询。请勿使用表情符号或特殊字符。
回答：
《战锤 40,000》中充满了可能出现在其他不相关的流行文化中的术语和名称，因此在第一个查询中设置 RAG 的上下文非常重要。如果您的应用程序涵盖多个上下文，例如您需要涵盖多个版本的战锤游戏规则或将它们与官方传说书籍结合起来，则该上下文应该可供选择或修改。
请注意，对于此实验，用户的查询始终用引号括起来。这有助于法学硕士区分它试图直接回答的查询和它不能直接回答的单独的提示工程指令。提示的问题/答案部分可以调整以适应特定的上下文，但大多数情况下，您需要做的就是告知法学硕士应该和不应该直接回答什么以及如何回答。
在这种情况下，可以安全地假设法学硕士对游戏世界有一般了解，因为该系列相当受欢迎并且一般信息是免费提供的。第一个查询的输出有助于生成一些用于词法搜索的关键字，而无需我们在应用程序中构建备忘单。
然后可以在后台执行词汇和向量比较，并编译结果列表以供法学硕士审查。由于用户的原始提示永远不会在第一步直接通过推理来回答，因此法学硕士只会转换搜索中找到的内容，并且很容易被阻止回答其护栏或知识库之外的查询。
如果搜索有相关结果：
查询：“<用户查询>”
查看这些搜索结果并使用它们来回答查询。
结果1
结果2
ETC。
回答：
如果搜索没有相关结果：
查询：“<用户查询>”
礼貌地告诉我您已搜索但找不到该查询的答案。请尽您所知回答。
回答：
为了增加安全性，当请求无法得到服务时，您可以完全拒绝或重定向请求。
查询：“<用户查询>”
礼貌地告诉我您已搜索但找不到查询的答案。指示我联系客户支持团队寻求帮助。
回答：
您甚至可以通过询问更多详细信息来使输出更长。只要您能够将源材料放入上下文窗口中，法学硕士就可以为您进行转换。
查询：“<用户查询>”
查看这些搜索结果并使用它们来回答查询。尽可能详细并引用来源。
结果1
结果2
ETC。
回答：
局限性
法学硕士的上下文窗口有限，无法处理特别大的文本页面。考虑对行大小进行限制，以便您的数据更易于管理且更易于法学硕士处理。例如，将页面切成约 1,000 个字符的块似乎效果很好，并尽量避免在提示中输入超过四到五个详细答案。
除了您可以在上下文窗口中容纳的内容之外，法学硕士没有任何对话记忆。建立对话数据的永久存储是可能的，但法学硕士不可能将过大的对话或详细的上下文放入提示中；它所能改变的东西是有上限的。这意味着无论如何，在某个时刻，你会注意到法学硕士似乎“忘记”了某些细节，即使它们是作为上下文提供的；这只是该工具的固有限制。最好只依靠它进行简短的对话，并集中精力一次转换少量文本，以尽量减少幻觉。
法学硕士的随机性可能是一个问题。需要进行测试和调整，以确定哪种提示最适合您的数据集，并找出哪种模型最适合您的用例。在我使用 13B 参数模型进行的测试中，关于从第一个提示生成哪些搜索关键字存在很多不可预测性，尤其是随着提示长度的增加。为了获得最佳结果，请坚持使用较短的提示。
结论
总之，通过结合向量和词汇搜索模型来利用 RAG 可以更有效地查找和排序相关结果，并生成不易产生幻觉的代理输出。可搜索的上下文越小，响应就越精确。构建您自己的 LLM 调用的自定义管道可以提供更大的灵活性，可以根据您所需的准确性和防护等级调整响应。
虽然它无法在有限的上下文窗口内处理过多的数据，但它确实提供了在有限的知识库上创建有效助手的能力，以及在与以前相同或更少的硬件上运行更多并发代理的能力。这可以为虚拟助手的桌面游戏等应用开辟更多可能性，甚至涵盖政府、法律和会计师事务所、科学研究、能源等领域使用的更复杂的主题。
如果您准备好开始构建，可以免费试用 Astra DB 。立即创建数据库并开始加载 RAG 源，无需云或数据库运维经验。
作者：Mario Charnell-Delgado，DataStax
也发布在这里。
