从POC到生产中的RAG缩放

实现扩展所需的常见挑战和架构组件

1. 简介

1.1. RAG概述

那些沉浸在生成式人工智能及其个人生产力应用以外的大规模应用中的人们可能已经了解到检索增强生成（RAG）的概念。RAG体系结构由两个关键组成部分组成——检索组件使用矢量数据库对大量文档进行基于索引的搜索。然后将其发送到大型语言模型（LLM）以根据提示中更丰富的上下文生成扎实的响应。

无论您是构建面向客户的聊天机器人以回答重复性问题并减轻客服工作人员的工作量，还是为工程师构建副驾驶员，帮助他们逐步浏览复杂的用户手册，RAG已经成为LLM应用的关键原型之一。这使得LLM能够基于数百万甚至数百万份文件的真实情况提供上下文相关的响应，减少幻觉并提高基于LLM的应用程序的可靠性。

1.2. 为什么要从概念验证（POC）扩展到生产？

如果你正在问这个问题，我可能会挑战你回答，如果没有将其投入生产的意图，你为什么要建立一个概念验证？试点炼狱是开始实验的组织常见的风险，然后陷入实验模式。记住，概念验证很昂贵，真正的价值实现只有在你进入生产并大规模做事情时才会发生- 无论是释放资源，让它们更有效率，还是创造额外的收入来源。

2. 扩展RAG时的关键挑战

2.1. 性能

RAGs中的性能挑战多种多样。检索速度通常不是主要挑战，除非您的知识语料库包含数百万个文档，即使如此，也可以通过建立正确的基础设施来解决 - 当然，我们受到推理时间的限制。我们遇到的第二个性能问题是如何获得“正确”的块，以供馈送给LLM用于生成，高精度和召回率。检索过程越差，LLM响应的上下文相关性就越差。

2.2. 数据管理

我们都听过古老的谚语“垃圾进，垃圾出（GIGO）”。 RAG 只是我们可以利用的一组工具，但真正的价值来自实际数据。由于 RAG 系统处理非结构化数据，它具有一系列挑战，包括但不限于文档的版本控制和格式转换（例如将 pdf 转换为文本）。

2.3. 风险

有一个最大的原因是企业在从试水转为全面采用时犹豫不前的可能风险，这些风险与使用基于人工智能系统有关。虽然使用RAG降低了幻觉的可能性，但仍然存在非零风险。还有其他相关风险，包括偏见、毒性、监管风险等，可能会产生长期影响。

2.4. 集成到现有工作流程中

构建一个离线解决方案更容易，但引入最终用户的观点对于确保解决方案不会感觉像负担至关重要。没有用户希望转到另一个屏幕使用“新的人工智能功能”-用户希望人工智能功能内置到他们现有的工作流程中，使技术具有辅助性，而不会对日常工作造成干扰。

2.5. 成本

3. 用于扩展的建筑组件

如果我们不讨论“我们该怎么做”，仅仅谈论挑战是不公平的。您可以在架构堆栈中添加一些必要的组件，以克服/减轻我们上面概述的一些问题。

3.1. 可伸缩矢量数据库

许多团队开始使用开源矢量数据库如ChromaDB，这对于POC来说很棒，因为它们易于使用和定制。然而，面临大规模部署时可能会遇到挑战。这就是可扩展矢量数据库发挥作用的地方（比如Pinecone，Weaviate，Milvus等），它们针对高维度矢量搜索进行了优化，使得即使数据集大小增加到数百万或数十亿个矢量，也能实现快速（亚毫秒级），准确的检索，因为它们使用了近似最近邻搜索技术。这些矢量数据库具有API、插件和SDK，可实现更容易的工作流集成，也具有水平扩展性。根据所在平台，可能有必要探索由Databricks或AWS提供的矢量数据库。

3.2. 缓存机制

缓存的概念几乎与互联网同龄，可以追溯到1960年代。相同的概念也适用于生成式人工智能——如果有大量查询，也许有几百万个（在客户服务功能中非常常见），那么很可能许多查询是相同的或非常相似的。缓存使我们能够避免向LLM发送请求，如果我们可以改为从最近缓存的响应中返回响应。这有两个目的：降低成本，以及改善常见查询的响应时间。

这可以作为内存缓存（内存缓存，如Redis或Memcached）、磁盘缓存用于不太频繁的查询或分布式缓存（Redis集群）来实现。像Anthropic这样的一些模型供应商在其API中提供了快速缓存。

3.3. 高级搜索技术

虽然不是一个极为关键的架构组件，但多种技术可以提升搜索引擎的效率和准确性。其中一些技术包括：

• 混合搜索：与其仅依赖于语义搜索（使用向量数据库）或关键字搜索，不如结合两者来增强您的搜索功能。
• 重新排序：使用LLM或SLM来计算与每个搜索结果的查询相关性得分，并重新对它们进行排序以仅提取并共享高度相关的结果。这对于复杂领域或可能返回许多文档的领域特别有用。其中一个例子是Cohere的重新排序。

3.4. 负责任的人工智能层

您的负责任的人工智能模块必须被设计来减少偏见，确保透明度，与您的组织的道德价值观保持一致，持续监测用户反馈并追踪符合法规以及其他与您所在行业/职能相关的事项。有许多方法可以实现这一目标，但基本上必须通过程序设计来实现，同时需要人类监督。以下是一些能够实现这一目标的方法：

• 预处理：在将用户查询发送到基础模型之前，先对其进行过滤。这可能包括检查偏见、毒性、意外使用等问题。
• 后处理：在结果从FM返回之后，再次应用一组检查，然后再向最终用户公开结果。

这些检查可以作为小型可重复使用的模块启用，您可以从外部供应商购买，或为自己的需求进行构建/定制。组织常用的一种方法是使用精心设计的提示和基础模型来编排工作流程，并防止结果传递给最终用户，直到通过所有检查。

3.5. API 网关

一个API网关可以服务多个目的，有助于管理成本和各种方面的负责任人工智能。

• 提供一个统一的接口来与基础模型互动，并对其进行实验。
• 帮助团队/用例/成本中心开发对成本和使用情况的细粒度视图，包括限速、速度调节和配额管理。
• 作为负责任的AI层，过滤掉意外的请求/数据，使其不会影响模型。
• 启用审计跟踪和访问控制

4. 这足够了吗，还需要更多吗？

当然不是。还有一些其他事情也需要记住，包括但不限于：

• 在您的用例路线图中，用例占据了战略位置吗？这可以让您获得领导支持，并进行正确的投资来支持开发和维护。
• 一个清晰的评估标准，用来衡量应用程序在准确性、成本、延迟和可负责的AI等方面的表现。
• 改进业务流程以保持知识更新，维护版本控制等。
• 设计RAG系统，使其只根据最终用户的权限级别访问文档，以防止未经授权的访问。
• 使用设计思维将应用程序整合到最终用户的工作流程中，例如，如果您正在构建一个机器人来回答关于Confluence作为知识库的技术问题，您应该构建一个单独的用户界面，还是将其集成到团队/Slack/其他用户已经使用的应用程序中？

5. 结论

RAG是一个突出的用例原型，并且是组织尝试实现的最初几个之一。将RAG从POC扩展到生产环境仍面临挑战，但通过谨慎的计划和执行，许多问题都可以克服。一些问题可以通过在架构和技术上的战术投资来解决，而一些需要更好的战略方向和巧妙的规划。随着LLM推理成本持续下降，无论是因为推理成本降低还是更广泛地采用开源模型，成本障碍可能对许多新用例不再构成问题。