从概念验证到生产的RAG放大

来源：使用OpenAI的Dall-E模型创建

那些深入研究生成式人工智能及其在个人生产力应用之外的大规模应用的人们，很可能已经遇到过检索增强生成（RAG）这一概念。RAG架构包含两个关键组件——检索组件使用向量数据库对大量文档进行基于索引的搜索。然后将这些内容发送给大型语言模型（LLM），以生成基于更丰富提示上下文的响应。

无论您是构建面向客户的聊天机器人来回答重复性问题，从而减轻客户服务代理的工作负担，还是构建工程师的副驾以帮助他们逐步导航复杂的用户手册，RAG 已成为 LLM 应用中的关键类型。这使 LLM 能够基于成百上千万文档的真实信息提供上下文相关的响应，减少虚假信息，并提高基于 LLM 的应用的可靠性与准确性。

如果你问这个问题，我可能会挑战你回答为什么没有将其投入生产的打算还在建立一个PoC。试点困局是组织开始实验但随后陷入实验状态时常见的风险。记住，PoC是昂贵的，只有真正投入生产并实现规模化操作时，真正的价值才会实现——无论是释放资源、提高效率，还是创造新的收入渠道。

2. 扩展RAG的关键挑战

RAGs中的性能挑战形式多样。检索速度通常不是主要问题，除非你的知识库包含数百万份文档，即便如此，通过正确设置基础设施也可以解决该问题——当然，我们还会受到推理时间的限制。我们遇到的第二个性能问题是，如何将“正确的”片段以高精度和高召回率提供给LLMs进行生成。检索过程越糟糕，LLM的响应就越不相关。

大家都知道那句老话“垃圾进，垃圾出（GIGO）”。RAG不过是一套我们手头的工具，但真正的价值在于实际的数据。由于RAG系统处理的是非结构化数据，它带来了一系列挑战，包括但不限于文档版本控制、格式转换（如pdf转文本）等。

公司犹豫不决，从试水到全面采用基于人工智能的系统的主要原因之一是这些系统可能带来的风险。虽然使用检索增强生成（RAG）技术可以显著降低幻觉，但仍然存在。还有其他相关风险，包括偏见、毒性、监管风险等，这些都可能带来长期影响。

构建一个离线解决方案相对较为容易，但考虑到最终用户的角度至关重要，确保方案不会给用户带来负担。用户不想切换到另一个屏幕去使用“新AI功能”——用户希望AI功能能够无缝整合到他们现有的工作流程中，使技术成为辅助工具，而不是日常工作的干扰，而是有助于日常工作。

这似乎很明显，对吧？组织正在应用生成式人工智能，以便对公司产生影响。如果收益不及预期，或者成本超出预算，那么影响将会大大减弱，甚至完全消失。

如果我们只谈问题而不提解决办法，这就不公平了。那我们能做些什么呢？你可以向你的架构栈中添加几种关键的组件，来解决或减轻一些我们在上面提到的问题。

许多团队正确地从开源向量数据库开始，例如ChromaDB，这些数据库非常适合于POC（即Proof of Concept，简称POC），因为它们易于使用和定制。然而，在大规模部署时，可能会面临挑战。这时候可扩展的向量数据库就派上用场了（如Pinecone，Weaviate，Milvus等），这些数据库针对高维向量搜索进行了优化，即使数据集规模扩大到数百万甚至数十亿个向量，它们也能实现亚毫秒的快速和准确检索，因为他们使用了近似最近邻搜索技术。这些向量数据库提供API、插件和SDK，使工作流集成更加容易，同时它们也是横向扩展的。根据所处的平台环境，可能更合适去探索Databricks或AWS提供的向量搜索服务。

来源：用AI（比如OpenAI的Dall-E模型）做出来的

缓存的概念几乎和互联网的发展一样悠久，可以追溯到20世纪60年代的IBM单处理器超级计算机努力。同样的概念也适用于生成式AI——如果有大量的查询，比如数百万（在客户服务功能中非常常见），那么很可能许多查询是相同的或极其相似的。缓存允许我们避免向大语言模型发送请求，而是直接从最近的缓存响应中获取答案。这有两个好处：一是降低成本，二是加快常见查询的响应时间。

这可以实现为内存缓存（如Redis或Memcached），或者对于不太频繁的查询使用磁盘缓存，还可以使用分布式缓存，比如Redis集群。一些模型提供商，比如Anthropic，提供prompt缓存作为其API的一部分。

这是用AI（比如OpenAI的Dall-E模型）生成的。

虽然不像架构组件那样清晰明了，但仍有一些技术可以帮助提升搜索，从而提高其效率和准确性。其中一些方法有：

• 混合搜索： 通过结合语义搜索（使用向量数据库）和关键词搜索，而不是仅依赖其中一种，来增强搜索。
• 重排序： 使用大语言模型（LLM）或特定场景语言模型（SLM）来计算查询与每个搜索结果的相关性分数，并重新排序，仅提取并分享最相关的结果。这在复杂领域或可能返回大量文档的场景特别有用。例如，一个例子是Cohere的Rerank。

利用OpenAI的Dall-E模型生成的

您的负责任的AI模块必须设计为减少偏见、确保透明度、符合组织的伦理价值观、持续监控用户反馈以及确保符合监管要求等，这些都与您的行业/职能相关。虽然实现方式多样，但归根结底，这需要通过编程实现并辅以人工监督。在具体实施过程中，以下是几种可行的方法：

• 前期处理: 在用户查询提交给基础模型前进行过滤。这可能包含检查偏见、毒性、非预期使用等。
• 后期处理: 在从基础模型获取结果后，但在展示给最终用户前，应用另一组检查。

这些检查可以作为小型可重用模块启用，这些模块可以从外部供应商购买，或根据您的需求进行构建和定制。组织通常采取的一种常见做法是使用精心设计的提示和基础模型来协调工作流程，并直到结果通过所有检查后才提供给最终用户。

来源：用AI（OpenAI的Dall-E模型）生成的

一个 API 网关可以实现多种功能，例如帮助管理成本以及确保负责任 AI 的各个方面。

• 提供统一的界面来与基础模型交互，进行它们的实验
• 帮助开发一个细粒度的成本和使用视图，按团队/用例/成本中心划分——包括速率限制、速度节流、配额管理
• 担任负责任的人工智能层，在请求或数据到达模型之前过滤掉不符合预期的请求/数据
• 提供审计跟踪和访问控制

来源：借助OpenAI的Dall-E模型生成

当然不是这样。还有其他一些需要注意的地方，比如包括但不限于：

• 这个用例在你的用例路线图中是否占据战略领导地位？这使你能够做出正确的投资以支持应用的发展和维护。
• 有一个明确的评估标准来衡量应用的性能，包括准确度、成本、延迟和负责任的AI等方面。
• 改进业务流程以保持知识的时效性，包括维护版本控制等。
• 设计RAG系统，使其仅根据最终用户的权限级别访问文档，以防止未经授权的访问。
• 使用设计思维，将应用集成到最终用户的流程中。例如，如果你正在构建一个用于回答技术问题的机器人，而Confluence作为知识库，你应该构建单独界面，还是整合到Teams/Slack等现有应用中？

RAGs 是一个突出的用例模型，也是组织首批尝试实施的用例之一。从概念验证（POC）阶段扩展到生产环境会遇到挑战，但通过仔细的规划和执行，许多这样的挑战可以通过克服。其中一些可以通过对架构和技术的战略性投资来缓解，而另一些需要更好的战略指导和周密的计划。随着LLM推理成本的持续下降，无论是由于推理成本的降低还是开源模型更广泛采用，成本障碍可能已经不再是许多新用例的主要顾虑。

本文中的观点仅代表作者的看法，并不代表任何产品或服务的认可。