随着大型语言模型的发展，检索增强生成（Retrieve Augment Generation，简称RAG）已成为构建问答和会话AI系统的一种流行方法。如果你正在构建LLM应用，你可能已经知道RAG很容易起步，但很难达到生产可用。本文总结了来自关于“让检索增强生成（RAG）系统产品化就绪”的网络研讨会的一些要点。

参与人员：Jerry Liu（LlamaIndex的创造者）、Bob（Weaviate的联合创始人/CEO）、Max（sid.ai的联合创始人/CEO）、Tuana（Haystack工程师）。

一、RAG介绍

1. RAG的定义

RAG是指结合检索系统找到相关上下文，与大型语言模型生成回答的方法。检索系统从大量文本中寻找与问题或查询相关的文本片段作为上下文，而语言模型则利用这些上下文生成回答。这有助于语言模型回答它本身无法回答的问题。

2. RAG的工作原理

RAG系统典型由三部分组成：

(1) 检索器：从大规模文本数据中检索与输入查询相关的文本片段。

(2) 语言模型：利用检索到的相关文本生成回答。 

(3) 提示优化：将检索文本以适合语言模型使用的方式提供给模型。

检索器找到相关上下文，提示优化将上下文整合到提示模板中，然后输入语言模型进行生成。RAG系统充分利用了检索和生成能力的结合。

二、考虑生产环境下的RAG 

将RAG系统引入生产环境时，需要全面考虑其在性能、成本、延迟、可扩展性和安全性等方面的要求。

1. 性能、成本、延迟、可扩展性和安全性

 （1）性能

在生产环境下，RAG系统需要承载大量用户查询流量。因此查询吞吐量是一个关键指标。系统需要能够以每秒数百或数千次的速度响应查询。否则，在流量高峰期就会出现延迟或错误。此外，还需要关注系统各组件的响应时间，比如检索延迟，语言模型生成延迟等。需要对关键路径进行优化，以提升整体性能。

（2) 成本

运行RAG系统需要承担云计算成本和模型成本。如使用基于GPU/TPU的语言模型，计算成本会很高。此外，大规模文本数据需要持久化存储，也会产生一定成本。需要根据查询量级估算总体成本，确保成本可控。

(3) 延迟

系统端到端查询延迟是关键的用户体验指标。查询延迟受到数据规模、检索算法、网络IO等多方面影响。系统需要进行流量管理，保证尾端延迟(比如P99)在可接受范围内。同时，还需要设置超时限制，避免个别慢查询拖累整体延迟。

(4)可扩展性

随着查询量的增长，需要能够轻松扩展系统计算资源和存储资源，如通过增加服务器数量来扩展。要有清楚的资源监控和弹性扩展机制。同时需要关注各系统组件的可扩展性，避免单点限制系统扩展能力。

(5)安全性

RAG系统直接利用用户输入来生成文本，存在悲观生成风险。需要采取多项措施防止生成有害或不当内容。包括训练语言模型时的数据过滤，在线内容审查，块列表封禁等。同时不能存储或泄露用户隐私数据。

2. 检索模型的选择

在RAG系统中，检索模型的选择对系统整体性能和质量有重要影响。主要有以下两种检索模型可供选择：

（1） 基于关键词的原生检索

这类检索利用词袋模型等技术，based对查询和文本进行关键词匹配。优点是实现简单，计算效率高。但精度相对较低，无法处理语义相似的文本。

（2） 基于embedding的语义检索

这类检索会先将文本映射到语义embedding空间，然后计算查询和文本之间的语义相似度。BERT等预训练语言模型提供了语义匹配的能力。但搜索过程计算量大，实时性略差。

检索模型的选择需要根据数据规模、查询类型、实时性要求等因素进行全面考虑和权衡。应充分利用两种检索的优势，同时适当权衡精度和延迟等指标，为RAG系统选择最佳的检索方案：

(1)可以先用更快的关键词检索获取召回候选集，再用语义检索模型重新对候选集打分排序。这种cascade结构可以平衡两者。

(2)原生检索可以考虑 indexer 和 searcher 分离，indexer 离线处理，searcher 在线响应更快。

(3)语义检索可以考虑采用 GPU 进行并行加速，或者使用量化、混合精度技术来加速查询。

(4)还可以考虑将部分热点内容做成索引，来加速对应查询的响应。

(5)对两种检索方式使用不同的文本块规模，以发挥各自优势。

(6)可以使用一些聚合技巧，对两种检索结果进行整合，而不是简单顺序执行。

3. 语言模型的选择和托管

(1)可以选择轻量级的无监督语言模型或大型的微调语言模型。无监督模型计算效率更高，微调模型效果更好。

(2)自建语言模型服务需要准备模型训练和服务部署技术，但可以确保数据安全性。第三方语言模型服务更便捷，但需要关注可能的安全与合规风险。

4. 法律合规性 

使用第三方语言模型服务时，需要审视其服务协议。重点关注内容生成的安全性需求，您的数据使用权限等。必要时可以申请第三方审计。

可以看出，在产品化过程中，RAG系统不仅要追求指标，更需要关注可维护性、可运营性。只有在生产环境中全面验证测试之后，才能确保RAG系统足以承载真实业务流量，为用户提供稳定、快速、可靠的服务。

三、数据提取和加载 

数据提取和加载是构建RAG系统的基础工作，直接影响到系统的覆盖范围、检索质量以及知识的新鲜度。主要的挑战和解决方案包括：

1. 处理多种异构数据源

RAG系统的数据可能来自网站内容、产品文档、数据库、电子邮件等多种格式。需要能够处理多种数据源，转化为统一的存储格式，进行存储和索引。还需要处理各数据源的编码、标记语言等区别。

2. 增量数据同步

对于持续变化的数据源，需要建立增量同步机制。比如对网站内容定期爬取更新，识别增量内容并处理。邮件也需要增量获取最新邮件并处理。

3. 访问权限管理

访问第三方数据源时，需要正确管理各类访问凭证、令牌、密码等，并注意其更新周期。否则会出现数据无法正常获取的情况。

4. 设置限流与容错机制

需要针对不同数据源设置提取速率限制，避免对源网站造成影响。同时建立重试与容错机制，避免临时问题导致数据丢失。

5. 内容审核

根据法律合规要求对提取内容进行审核，过滤违规信息。可以通过黑白名单、机器学习等技术实现。

6. 去冗余

对重复或近似文本进行去冗余，避免索引冗余内容。可以使用局部敏感hash或语义重复检测手段。

此外，还需要关注文本预处理，提取结构化数据等额外优化点。只有高质量的数据整备，才能支撑RAG系统达到优秀的检索和生成效果。

四、文本块处理

1. 更小的文本块通常可实现更好的嵌入式检索，但更大的文本块可为语言模型提供更多上下文来生成详细的答案

如果文本块太小，无法提供充足上下文;但如果文本块太大，则会影响检索质量。需要在二者间找到平衡。

2. 在不同使用案例下找到平衡

不同的使用场景需要不同的文本块处理方式。如果是文档摘要这样的任务，则需要较大的上下文;如果是对话系统，则可能需要较小的文本块。

五、检索问题和解决方案

构建RAG系统中，经常会遇到一些检索质量不佳的问题，以及对应的解决方案。主要挑战包括：

1. 关键词检索需求无法满足

依赖embedding相似度的语义检索，无法响应明确的关键词检索需求。这时就需要引入基于关键词匹配的检索能力。

2. 没有考虑查询意图和场景

相似的查询在不同意图和场景下，需要不同的检索策略。仅仅依赖相似度无法满足这一需求。

3. 长尾查询无法被高质量匹配

一些长尾查询由于对应样本稀少，无法被准确匹配。这需要扩大覆盖的样本量。还可以考虑根据查询内容进行扩展。

4. 结果相关度需要提升

检索结果的相关度离用户预期还有一定差距，这需要迭代优化查询表达、检索策略等。同时可以引入用户反馈来检索质量。

对应的解决方案包括：

1. 结合关键词检索实现混合搜索 (1) 可以将关键词检索作为候选生成层，语义检索作为排序层。利用两者的优势。(2) 也可以并行使用两种检索，然后聚合结果。要关注结果去重问题。(3) 可以让用户指定需要关键词匹配的必选项，语义匹配其它部分。

2. 引入基于意图的检索路由 (1) 构建查询分类模型，对不同类别查询使用不同检索方案。(2) 对明确导向 Transactional 的查询直接连接数据库查询。(3) 构建用户画像，根据用户属性调整检索策略。

3. 扩充样本量覆盖长尾 (1) 收集用户长尾查询，扩充语料库中对应的样本文档。(2) 对长尾词进行词义扩展，找到相关同义词丰富查询表达。(3) 针对长尾词，放宽检索要求，回退到全文搜索结果。

4. 不断根据用户反馈改进策略  (1) 通过 A/B 测试比较不同检索策略。(2) 收集用户点击数据，分析提升相关文档的排序。(3) 让用户对结果打分，直接优化语义匹配的向量空间。(4) 分析无点击结果，添加对应语料样本。

六、提示工程和LLM选择的综合影响

1. 联合评估它们的重要性

提示模板设计和语言模型的选择需要系统联合考虑和评估，二者密不可分。

2. RAG管道需要针对特定数据和使用案例进行微调

每个RAG系统都需要针对具体使用场景和数据类型自定义优化。没有一成不变的最佳解决方案。

综上所述，将RAG系统引入生产环境需要全面考虑性能、成本、数据处理、检索质量、模型选择等多方面因素。同时还需要针对具体使用场景和数据类型进行定制化调整。只有做到这些，才能使RAG系统真正产品化，为最终用户提供可靠、高效的服务。

出自：https://mp.weixin.qq.com/s/yj6wTkAt-PwXxaclCcFIsQ