知识库

企业级RAG应用优化大全【下】：检索与生成阶段的8个必知技巧

2024 年 9 月 9 日

点击上方蓝字关注我们

在上篇中（企业级RAG应用优化大全【上】：数据索引阶段的8个必知技巧），我们对企业级RAG应用在数据索引阶段的常见优化方法做了总结。本篇将专注到RAG应用在检索与生成阶段的优化：

使用查询重写提高检索的精确性
用语义路由来分发请求
使用高级检索机制
用检索后处理来丰富上下文
选择合适的LLM
优化你的响应生成模式
用Agent（智能体）的思想优化RAG
在上线前评估你的RAG系统

使用查询重写提高检索的精确性

查询重写（也称为查询转换或查询分析等）已经成为RAG工作流的常见环节。当用户的查询不够明确或具体时，可以通过查询重写来分解或者细化问题，以提升检索与生成的准确性。因此，查询转换是一种“检索前”的处理步骤。

一个常见的重写方案是HyDE（假设性文档嵌入）。即用LLM生成假设性答案，并用这个答案来检索相似的上下文内容：

这种生成的假设性答案（有可能是幻觉）有助于更全面地捕获查询意图与上下文，提高召回文档的相关性。当然，由于这个答案可能存在虚假信息，也可能会影响检索结果的质量。

另外一种常见的策略是基于上下文的查询细化。通常用于在多次、连续、有上下文的RAG对话中，根据历史对话记录与当前输入消息，改写出一个独立的、具备完整语义的问题，然后做检索。常用来消除一个连续对话场景下的问题中的指代词、歧义，并让输入问题更完整。

其他常见的一些重写策略包括后退提示、子问题重写、分步问题重写等；当然都需要借助LLM来完成，因此也会带来一定的性能与成本开销。

更多的查询重写策略可以参考：

构建“生产就绪”的企业级RAG应用的6大优化考量【下】

用语义路由来分发请求

借助于路由模块（Router）可以在检索之前识别使用者的意图，并根据意图将输入问题交给后续不同的检索生成流程来完成。这通常借助LLM来提供基于语义的判断能力，以实现类似如下场景的选择：

在多种不同的数据源中选择需要查询的目标
在多种不同的索引与问题类型中选择（如回答事实问题还是总结性问题）
选择多个合适的查询引擎同时生成（多选），并合并结果

在大型的RAG应用中，借助于语义路由在检索与生成之前进行意图的区分与分发，可以更好地提高检索的精准度（更小的检索范围）、提高检索效率（更小的数据集）、提高系统的可扩展性（动态增加不同的分支）等，是一种常见的优化策略。

使用路由时需注意的问题是，尽量确保不同的路由分支之间有更大的可区分度，并且在提问中更容易通过自然语言识别，以提高路由的准确性。

使用高级检索策略

一个RAG管道中最重要的环节是检索（Retrieval）。在经典的RAG应用中，检索通常是基于向量索引的语义检索，并根据相似性取top_K召回知识形成增强的上下文。但在复杂的数据环境下，单一的检索方法很多时候无法确保最终检索效果。而常见的一种优化策略是融合检索，如结合向量与关键词检索，并将结果进行融合与重排（rerank）后作为关联上下文：

当然，这只是融合检索的一种形式。你可以融合更多的算法与索引类型，比如融合向量与知识图谱索引的检索。融合检索的意义在于可以更大可能地召回遗漏的上下文，以帮助LLM生成。

之前我们还详细介绍过的另一种高级检索策略是递归检索，即通过多次检索实现一种类似向下“钻取”的检索方法。这种方法意义在于将检索过程分层次的多次完成，有利于简化复杂数据环境下的检索过程，且具有极大的可控性与灵活性。比如通过一级的摘要索引检索到某个文档，然后在该文档执行二级的内容检索，以定位到最相关的块（二次检索甚至可以是一个独立的RAG管道来完成）。关于融合与递归检索可以参考：

一文说清大模型RAG应用中的两种高级检索模式：你还只知道向量检索吗？

用检索后处理来丰富上下文

一种常见的问题是：为了保证检索的结果尽量精准，通常会尝试尽量小的文本块（chunk），以保持较高的检索质量；但另一方面这又牺牲了更多的语义与上下文的丰富性。因此可以考虑通过检索后处理来对检索结果进行改进，对上下文进行丰富。以开发框架LlamaIndex中提供的两种策略为例：

扩充句子窗口：简单的说，就是在通过相似度检索到最高分的Chunk后，在将内容发送给LLM之前，给这个Chunk前后添加一定数量的Chunk，这个数量取决于你设定的窗口大小。这里的原理就在于：尽管你的问题最相似的可能只是某个中间块，但这个块提供的信息很可能是不完整的。

自动合并检索：每个文本块被指定一个“父”块，你甚至可以构建一个多层级、树状的块结构，每个级别可以有不同的块大小。（这里的父子关系并不一定是文档中的大小关系，你可以根据需要设定）。

在做检索时，首先在叶子“块”这个层级上进行检索，然后在检索出的块基础上，采用一定的算法判断是否需要合并到具有更丰富语义的“父”块，并用于生成（在LangChain中也有类似的父子检索器来实现）。

选择合适的LLM

选择合适的LLM并不像看起来那么简单，因为这不仅仅是一个直接选用最强大、最先进模型的问题。因为实际应用场景中，特别是在需要综合考虑准确性、用户体验、成本等诸多因素的企业场景下。一些LLM选择的建议有：

考虑在不同的任务环节选择不同的LLM。RAG应用并不只有生成阶段才会需要LLM，在索引、路由、查询重写、生成等阶段都需要LLM，针对这些不同的任务要求使用不同的模型组合可以更好地发挥整体优势。
认识到最强大与最先进的模型并不总是最合适的模型。不能基于简单的官方宣传或者公开测试报告做直接选择，对于许多任务而言，较小、成本更低、速度更快的模型可能更适合。比如，如果需要在多个RAG管道中进行决策推理，生成的文本不需要极高的复杂性，但响应时间却至关重要。这时候可能较小的模型可以显著提升响应速度，可能会更合适。
企业应用场景下，需要充分考虑部署的要求。自托管的模型可能更适合对数据隐私要求严格的场景，而依赖云端服务的闭源模型则通常提供了更为强大的算力和模型更新频率；此外，开源模型的可定制性则为高度个性化的应用提供了支持。
通过评估测试的结果进行比较与选择。这包括不同模型的生成质量、速度与成本。在你的个性化RAG流程中进行实际验证，并最后选择能够在成本、速度与准确性达到平衡的LLM。

优化你的响应生成模式

经典RAG应用的生成模式是比较简洁易懂的：把输入的问题与检索的相关上下文（无论通过怎样的检索方式）输入LLM，并要求输出符合指定格式的响应答案。

但在实际应用中，由于输入问题或任务的多样性，这种简单模式并不总是合适的，又或者生成的质量不高，很多时候你需要结合任务输入与响应要求来优化自己的生成模式，这包括生成的流程与可能涉及的提示词模板。在LangChain与LlamaIndex框架中都内置了多种不同的响应生成模式，比如在LlamaIndex中的默认响应生成模式也并非简单的让LLM参考上下文给出答案，而是一个多次迭代、不断精炼（refine）的过程：

这种模式下，将检索出的块（首先做合并）多次输入LLM，并不断的对生成结果进行完善，最后获得响应结果。

其他一些常见的生成模式：

简单合并生成：用检索出的多个关联块，借助LLM依次生成答案，并对答案进行简单合并，如使用某个分割符。用于一些希望获得多个答案的任务场景。

自我反思生成：借助LLM对生成的响应进行评估与反思（如与问题的相关性、正确性等），并根据评估结果进行选择或再次优化（如通过问题重写后再次生成）。推荐参考一些新的RAG范式，比如Self-RAG：

树状总结生成：用于对检索出的关联块，自底向上的进行不断合并与摘要生成，直到无法合并（只有一个摘要结果）。

用Agent（智能体）的思想优化RAG

简单的单向RAG应用往往很难满足企业级应用的要求，很多时候可以借助AI Agent的思想来让你的RAG应用更加聪明与智能。比如：

将复杂问题拆分成多个步骤或者小问题，并借助不同的RAG管道来完成
在多知识源的RAG应用中，能够回答跨越多知识源、多RAG管道的问题（比如比较两个文档中知识的差异）
将知识密集型任务的RAG应用与其他类型的应用进行集成，以完成更加复杂的流程，比如涉及数据操作的任务

看这样一个Agentic RAG的应用架构：

在这样的架构中，传统的RAG应用（RAG pipeline）退化成一个Agent可以使用的Tool，Agent借助于LLM推理完成任务的步骤、使用的工具以及输入参数，并调用必要的工具来最终完成任务。比如，在完成一个数据比对任务时，Agent可能会借助LLM推理，决定首先调用第一个RAG应用获得数据，再调用另一个RAG应用获得数据，最后将两部分数据输入LLM进行比对获得答案。

这样的方案可以根据需要扩展的更强大，例如：