一文详谈RAG优化方案与实践

从理论到实践：RAG的完整落地指南

RAG到底是怎么回事？简单来说，就是通过检索现有的大量知识，结合强大的生成模型，为复杂的问答、文本摘要等任务提供了一种全新的解题思路。这篇文章将会把RAG遇到的挑战、通用范式、工程实践以及优化策略，掰开揉碎了说清楚。

一、RAG的背景介绍

自从ChatGPT火了之后，大语言模型又一次站上了风口浪尖。它们在自然语言处理领域的表现——无论是语言识别、理解还是推理能力——都让人惊叹。越来越多的行业开始尝试把大模型落地到实际业务中，比如政务、医疗、交通、导购等等。

通义系列、GPT系列、LLama系列……这些模型在语言交互场景下的表现相当抢眼。而以Gemini为代表的多模态模型，甚至开始涉足视觉和听觉领域，朝着真正的智能体方向演化。在某些指标上，它们展现的能力甚至已经超越了人类。

不过，再强大的大模型也有自己的短板：

• 知识的局限性：
  模型的知识面完全取决于训练数据集。市面上大多数大模型的训练数据都来自公开网络，对于企业内部数据、特定领域或高度专业化的知识，它们根本无从学习。

• 知识的滞后性：
  模型的知识是在训练那一刻“凝固”的。训练完成后出现的新知识，模型是完全不知道的。而大模型的训练成本高昂，不可能三天两头为了更新知识就重新训练一次。

• 幻觉问题：
  所有AI模型的底层原理都是基于数学概率的——大模型也不例外。所以它有时候会一本正经地胡说八道，尤其是在它本身不具备某方面知识或不擅长的场景下。更麻烦的是，这种幻觉很难被察觉，因为使用者自己得先懂行才行。

• 数据安全性：
  对企业来说，数据安全是命门。没有哪家公司愿意冒着数据泄露的风险，把自己的私域数据上传到第三方平台去训练。这也意味着，完全依赖通用大模型的应用方案，不得不在数据安全和实际效果之间做痛苦的取舍。

为了解决纯参数化模型的这些局限，一种半参数化的方法应运而生——把非参数化的语料库数据库与参数化模型结合起来。这种方法，就是RAG。

二、RAG的挑战

RAG通过检索大量现有知识，再结合强大的生成模型，确实为复杂任务带来了新解法。但理想很丰满，现实却有不少坑等着我们去踩。

2.1 数据质量差导致检索效果差

在RAG模型里，检索阶段的质量直接决定了生成阶段的输入和最终输出。如果知识库里塞满了错误信息并且被检索出来，那等于是在把模型往歪路上引。就算你在检索阶段做再多的优化，效果也可能微乎其微。

2.2 数据向量化的信息损失

为了实现高效检索，得先把原始文本转成数值向量——这个过程叫数据向量化。目的是把文本映射到一个低维向量空间里，让语义相似的文本在空间里靠得更近。但问题是，文本数据的复杂性和多样性，很难用有限的向量完全表达出来。这一步必然会丢失一些细节和特征，最终影响检索的准确性。

2.3 语义搜索的不准确

在RAG里，语义搜索是指根据用户的问题，从文档集合里找出语义最相关的那些文档——这叫数据召回。难点在于：怎么理解用户问题和文档的语义？怎么衡量它们之间的相似度？目前的主流方法是基于向量化结果，利用向量空间里的距离或相似度来衡量。但这种方法也有局限——向量空间里的距离，未必就等于真实的语义相似度，噪声和异常值也会干扰结果。所以，语义搜索的准确率永远不是100%。

三、RAG通用范式

3.1 Naive RAG

原始RAG是最早的研究范式，步骤也很直接：

• 建立索引：
  这一步通常在离线完成。先清洗数据并分块，然后用embedding模型把每个块转成语义向量，最后建好索引。

• 检索：
  拿到用户的query后，用同样的embedding模型，计算问题嵌入和文档块嵌入之间的相似度，挑出最相似的前K个文档块。

• 生成：
  把问题和相关文档合并成一个新提示，交给大语言模型来回答。如果有历史对话，也可以一并加进去处理多轮对话。

不过，初级RAG主要在三个方面踩坑：检索质量低、生成质量差、增强过程难。

• 检索质量低：
  用长文本做索引时，核心知识容易被大量无用信息淹没。再加上直接用用户的原始query去检索，没法精准抓住核心诉求，检索质量自然不高。

• 生成质量差：
  如果没检索到知识，或者检索到的知识质量不行，大模型就只能凭自己的“常识”去回答私域问题——幻觉就这么来了。回答空洞，没法直接用，知识库也就失去了意义。

• 增强过程难：
  把检索到的信息跟不同任务整合起来，本身就有挑战性，很容易导致输出不连贯。另一个担心是，生成模型可能过度依赖增强信息，最后变成单纯复述检索内容，缺乏洞察和综合。

要解决这些问题，就得在检索前和检索后动些脑筋——这就催生了高级RAG。

3.2 Advanced RAG

高级RAG在初级RAG的基础上，围绕知识检索做了优化——新增了检索前、检索中和检索后的优化策略，专门解决索引、检索和生成的问题。

检索前优化主要聚焦在知识切分、索引方式和query改写上。

知识切分是把长文本按语义内聚性切成小块，避免核心知识被淹没或语义被截断。索引方式优化则是通过调整数据索引的组织方式——比如去掉无效数据，或者插入某些数据来提高覆盖程度。query改写则需要理解用户的真实意图，把原始问题转换成更适合知识库检索的形式。

检索阶段的目标是召回知识库中最相关的知识。通常基于向量搜索，计算查询与索引数据之间的语义相似度。所以大多数检索优化都围绕嵌入模型展开。

可以微调嵌入模型，把它定制成特定领域的上下文——特别是那些术语不断变化或比较罕见的领域。比如BAAI/bge就是一个高性能的嵌入模型，支持微调。

动态嵌入会根据单词的上下文来调整，而静态嵌入则是每个单词一个固定向量。像OpenAI的embeddings-ada-02就是比较复杂的动态嵌入模型，能捕捉上下文理解。

除了向量搜索，还有混合搜索——通常是把向量搜索跟基于关键字的搜索结合起来。如果你的检索场景需要精确的关键字匹配，那这种方法会很实用。

对检索到的上下文做额外处理，可以解决一些头疼的问题——比如超出上下文窗口限制，或者引入了噪声。具体的检索后优化技术包括：

提示压缩：删除无关内容，突出重要上下文，缩短整体提示长度。重新排序：用机器学习模型重新计算检索到的上下文的相关性得分。

3.3 Modular RAG

随着RAG技术的进一步发展，新的思路开始突破传统的“检索-生成”框架，模块化RAG的概念就这样诞生了。它在结构上更自由、更灵活，引入了更多具体功能模块——比如查询搜索引擎、多回答融合。技术上也把检索跟微调、强化学习融合在一起。流程上，RAG模块之间可以实现设计和编排，催生出了多种RAG模式。

不过，模块化RAG并不是凭空出现的——三个范式之间是继承与发展的关系。Advanced RAG可以看作是Modular RAG的一种特例，而Naive RAG又是Advanced RAG的一种特例。

3.3.1 新增模块

• 搜索模块：
  跟普通的相似度检索不同，这个模块可以应用到特定场景，在特殊语料上做检索。一般用向量、分词、NL2SQL或NL2Cypher这些能力。

• 预测模块：
  这个模块负责减少用户问题中的冗余和噪声，突出真实意图。它不是直接检索，而是先让LLM生成必要的上下文——跟直接检索相比，这种方式更有可能找到相关信息。

• 记忆模块：
  留存多轮对话的历史信息，方便下次会话时知道用户之前问了什么。

• 融合模块：
  RAG-Fusion用LLM把用户查询扩展成多个查询。这种方法不仅抓住了用户的显式需求，也揭示了更深层的意图。融合过程包括对原始查询和扩展查询的并行向量搜索，然后智能重排序，得到最佳结果。

• 路由模块：
  RAG系统的检索流程会用到各种来源的内容——不同领域、语言、形式。查询路由器的作用，就是为查询选择合适的数据库——可能是向量数据库、图数据库、关系数据库，或者层次结构索引。开发者需要预先定义好决策方式，通过LLM调用执行，把查询指向选中的索引。

• 任务适配器模块：
  根据具体任务定制化Adapter。

3.3.2 新增模式

基于上面六大模块，可以快速组合出适合自己业务的RAG方案——每个模块都高度可扩展，灵活性极大。

举个例子：RR模式可以构建出传统的Naive RAG；RRRR模式则可以构建出Advanced RAG。还可以实现基于检索结果和用户评价的奖惩机制，用来强化和纠正检索器的行为。

四、RAG通用范式的工程实践

4.1 技术架构

我们落地的RAG技术架构，可以概括为“一底座三中心”：数据管理底座、模型中心、多引擎中心、召回策略中心。

在工程架构上，每个子系统按能力划分成子Modular，上层配置调度策略并统一调度——这符合Modular RAG的技术规范。在检索技术上，围绕检索做了大量索引降噪、多路召回、知识去重、重排等操作——这又符合Advanced RAG的技术规范。

4.1.1 知识库基础数据底座

基础数据底座包含数据生产和数据加工的能力。数据生产里有数据版本、血缘管理、引擎同步等能力。知识加工则包括数据切片、索引优化等。

4.1.2 模型中心

模型中心主要包含生成式大模型和理解式小模型。

生成式大模型提供的是：

• 引用式生成的能力——通过检索到的知识和用户的问题做增强生成。
• query改写能力——理解用户真实意图，改写成适合知识库检索的query。
• Text2Cypher能力——把知识库元数据和用户问题转成图谱语言，支撑上层的图谱检索。
• NL2SQL能力——如果需要访问数据库来获取数据，可以用这个。

理解式小模型提供的是：

• 文档切块能力——把大块的知识切分成小片段。
• embedding能力——把知识库元数据和用户问题转成向量。
• rerank能力——把多路召回的数据精排。

4.1.3 多引擎中心

多引擎中心包含向量、分词以及图谱引擎，提供多种检索方式，提高知识的命中率。

4.1.4 召回策略中心

召回策略中心在整个RAG建设中起到调度作用。在这里执行query改写、多路召回、检索后置处理以及大模型引用式生成答案。

基于“一底座三中心”的架构，每个子能力模块化，在上层配置调度策略——这符合Modular RAG的技术规范。

4.2 RAG建设路径

RAG的整体业务链路主要分为五大步骤：知识生产与加工、query改写、数据召回、后置处理、大模型生产。

4.2.1 第一阶段——可运行

这个阶段的核心目标是保证系统能用。

先按固定字符切分，预留冗余字符来保证语义不被截断。

结合上下文，先用大模型理解用户意图，以便更好地回答问题。

先实现向量召回。多路召回中，向量召回的比重最大，也最关键。需要找一个跟业务比较契合的embedding模型和向量数据库。

因为目前只有向量召回，所以直接使用向量近似得分做排序，设定符合业务预期的阈值来筛选数据。然后把筛选后的知识交给大模型生成答案。

4.2.2 第二阶段——提效果

这个阶段的主目标是提升检索效果。

• 基于固定字符的切分虽然预留了冗余，但知识内聚性还是可能被破坏。这时候需要一个基于语义切分的模型，把上下文紧密的句子拆成一条完整知识。
• 根据数据检索情况，分析索引噪音，制定降噪措施。

• 明确用户意图。
• 探索RAG-Fusion模式——根据用户的query生成多个相似query，并行检索。
• 多任务query抽取——把一个query任务拆成多个子query来检索。

• 在向量检索的基础上，根据业务场景探索分词、图谱的能力。有些业务甚至需要NL2SQL。

• 数据去重合并。
• 多路召回结果的重排能力建设，设定统一的排序筛选标准。

4.2.3 第三阶段——高扩展

这个阶段的目标是在工程上提升可扩展性。各个业务功能做模块化设计，通过召回策略配置中心，配置出业务所需的RAG流程。

五、RAG范式的优化实现策略

5.1 知识加工生成的实现策略

5.1.1 知识切片优化

文档片段过长会对知识检索造成很大影响，主要有两个问题：一是索引混淆——核心关键词被大量无效信息淹没，导致无论语义匹配、分词匹配还是图谱检索，都很难精准命中；二是token过长导致语义被截断——embedding时可能因为超长导致语义不完整；检索结束后，片段越长，能输入给大模型的信息条数就越少，最终影响生成答案的质量。

5.1.1.1 按固定字符切分

按固定字符拆分知识，通过设置冗余字符来降低句子截断的问题。这样能保证每个完整的句子要么在上文、要么在下文，尽量避免在句子中间断开。这种方式成本最低，在业务起步阶段可以先这么用。

5.1.1.2 按句子语义切分

固定字符切分有时候会把语义联系紧密的片段切成两条数据，导致质量下降。可以通过语义理解小模型来做句子拆分，让切分出来的知识片段语义更完整。

5.1.2 索引优化

5.1.2.1 HyDE

原始文档和用户问题一对一匹配，容错率低——一旦第一次没匹配上，知识就永远无法被召回了。优化的思路是：针对处理后的知识数据，预先用大模型生成一些有关联的假设性问题。当命中这些假设性问题时，也能搜索到相应的知识数据。

5.1.2.2 索引降噪

索引降噪的核心是去除索引数据中的无效成分，突出核心知识，降低噪音干扰。对QA-pair对和文章片段的知识，处理方法也类似。

这种数据一般以Q作为索引列，跟用户的问题组成“QQ搜索”模式，匹配难度更低。但如果直接用原始Q做索引，又会有无效词干扰的问题。比如：

用户query	匹配到的query
How can I start to sell on Alibaba?	How can I register an account on Alibaba.com?

这两句话里，无效的相似成分超过了60%，对索引匹配造成很大干扰。优化的方法是：通过大模型泛化向量索引中的Q，突出核心关键词，同时把对应的Answer主题也用大模型抽取出来——Q和A都突出关键词。比如“How can I register an account on Alibaba.com?”可以变成“register an account”加上Answer主题。这样就能突出核心主题，降低无效数据的干扰。

文章片段类知识篇幅长，语义上跟问题可能差异较大，导致匹配困难。优化的方法是：通过HyDE生成假设性问题，组成QA-pair对的形式，然后再用大模型抽取核心关键词来降噪。

5.1.2.3 多级索引

近似检索跟传统数据库检索不同——它通过聚类或HNSW建立索引后，在检索时会有一定的近似误差。如果知识库数据量很大，就会产生准确度和性能的问题。一个有效的办法是创建两个索引：一个由摘要组成，另一个由文档块组成。分两步搜索——先通过摘要过滤掉相关文档，然后只在相关组内搜索。

5.2 query改写的实现策略

直接用原始query检索，会遇到几个问题：知识库里的数据可能没法直接回答，需要组合知识才能找到答案；涉及细节比较多的问题，大模型往往无法高质量回答。针对这些情况，业务上提出了两种优化方案：RAG-Fusion和Step-Back Prompting。

5.2.1 RAG-Fusion

RAG-Fusion可以看作是MultiQueryRetriever的升级版。它首先根据原始question从不同角度生成多个新question，提升question的质量；然后针对每个question做向量检索——到此为止还是MultiQueryRetriever的功能；不同之处在于，RAG-Fusion在喂给LLM生成答案之前增加了排序步骤。

主要流程是这样的：

• 查询生成/改写：
  用LLM对用户的初始查询进行改写，生成多个查询。

• 向量搜索：
  对每个生成的查询做基于向量的搜索，形成多路搜索召回。

• 倒数排序融合：
  应用倒数排名融合算法，根据文档在多个查询中的相关性重新排列。

• 重排：
  用一些重排算法对结果进行重排。

• 输出生成：
  参考重新排列后的topK搜索结果，生成最终输出。

排序包含两个动作：一是独立对每个question检索返回的内容按相似度排序，确定每个返回chunk在各自候选集中的位置——相似度越高排名越靠前；二是对所有question返回的内容用RRF（Reciprocal Rank Fusion）做综合排序。

5.2.2 Step-Back Prompting

通过引入一个“后退一步”的问题——这个问题通常更容易回答，并且围绕更广泛的概念或原则——大语言模型可以更有效地构建推理。典型的Step-Back Prompting过程包括两个步骤：

1. 抽象：
   LLM不会直接尝试回答原始问题。相反，它会提出一个关于更大概念或规则的更一般性问题——这有助于它思考和查找事实。

2. 推理：
   得到一般问题的答案后，LLM用这些信息来思考并回答原始问题。这被称为“抽象基础推理”——利用来自更大观点的信息来对原始的、更难的问题给出好的答案。

问：如果一辆汽车以100公里/小时的速度行驶，行驶200公里，需要多长时间？

大模型对数学计算可能会比较迷茫。

后退提示：给定速度和距离，计算时间的基本公式是什么？

输入：为了计算时间，我们使用以下公式：时间=距离/速度

使用公式，时间=200公里/100公里/小时=2小时。

5.2.3 用户query降噪

用户提问时，有些停用词是不起作用的。比如“How to register an account on Alibaba.com”，在这个语境里，核心诉求是“register an account”，至于“How to”在表达核心诉求时意义没那么大。其次，当业务下沉到Alibaba的外贸业务时，“on Alibaba.com”也变得没那么重要——因为Alibaba的外贸业务系统就运行在Alibaba.com上，知识库里的知识自然也是相关的。

可以针对用户问题去除停用词。比如ES里就维护了一份停用词库，可以直接用。如果没有ES，也可以自己维护——nltk、stopwords-iso、Rank NL、Common Stop Words in Various Languages等开源库里都有大量停用词库，可以根据需要取用。

5.3 数据召回的实现策略

5.3.1 向量召回

在NLP领域，向量召回一直占据着无可替代的地位。把自然语言转成低纬度向量，基于向量相似度来评判语义相似程度——这是业界的主流做法。再结合前面提到的向量索引降噪、假设性问题以及对用户query的优化，一般都能取得不错的效果。

不过，当文本向量化模型训练得不够好时，向量召回的准确率会比较低——这时就需要用其他召回方式来做补充。除了向量召回，常见的还有分词召回和图谱召回。

5.3.2 分词召回

传统的倒排索引检索，基于BM25打分排序机制，找到分词上比较相似的知识数据。再结合前面提到的去除停用词策略，可以达到比较精准的程度。

5.3.3 图谱召回

知识图谱在知识生产和关系提取上有独特优势——它能基于现有数据，根据关系抽象，产生新的知识。比如现在有两条知识：一条是“阿里巴巴在国内采用A公司的物流服务”，另一条是“阿里巴巴与物流公司B达成合作”。经过NL2Cypher抽取后得到“alibaba-logisticsServices-A”和“alibaba-logisticsServices-B”，基于这两条知识可以产生新知识“alibaba-logisticsServices-A & B”。当用户问阿里巴巴平台支持哪些物流服务时，可以直接找到A和B。

5.3.4 多路召回

当文本向量化模型不够优时，单纯靠向量召回准确率有限。一般业务会采用多路召回的方式来提升召回效果，多路召回的结果经过模型精排，最终筛选出优质结果。至于用几种召回策略，根据业务实际情况来定。

5.4 后置处理的实现策略

5.4.1 文档合并去重

多路召回可能会召回同一个结果，这部分数据需要去重——否则对大模型输入的token数是一种浪费。去重后的文档可以根据数据切分的血缘关系做合并。比如检索到的D1、D2、D3都来自同一个父知识片段D，那就用D替换D1、D2、D3，以保证知识语义的完整性。

5.4.2 Rerank精排

每种召回策略的排序打分模型有差异，在最终统一的数据筛选层面，需要有一个统一的评判标准。目前可用的重新排序模型不算多——比如Cohere提供的在线模型，可以通过API访问；还有像bge-reranker-base、bge-reranker-large这些开源模型，可以根据业务需要择优选择。

六、优化经验总结

RAG想做出来不难，但想做好真不容易——每个步骤都有可能影响最终效果。我们在RAG上也做了大量探索：知识切分方面，做了固定字符切分的效果验证，分析索引噪音点，利用大模型做了大量降噪处理；query改写方面，利用大模型做了更明确的意图抽取，并对用户query做了降噪探索；数据召回方面，基于bge、voyage和cohere对embedding模型做了大量测评，探索了向量+分词的召回策略；后置处理优化上，做了知识去重和rerank的探索。

可以肯定的是，RAG的发展会越来越快。只要知识依赖和知识更新的问题没有彻底解决，RAG就有它存在的价值和空间。