RAG全链路关键模块权威评测榜单

RAG（检索增强生成）的概念于2020年由Meta首次提出。其核心论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》确立了一个关键范式：让语言模型不再仅依赖内部参数化记忆，而是从外部知识库中实时检索相关信息，再基于这些信息生成更可靠的输出。在大模型时代，这一思路尤为关键——幻觉问题、知识滞后、超长文本处理等长期难题，几乎都依赖于RAG来兜底。

RAG的三大核心挑战

真正将RAG落地，难度不小。归纳下来，挑战集中在三个环节：检索质量、增强过程与生成质量。

检索质量

首先，语义歧义是一道硬坎。例如用户问“苹果”，究竟指水果还是科技公司？向量嵌入很可能无法捕捉这些细微差异，导致检索结果偏离目标。其次，用户输入日趋复杂，不再只是关键词搜索，而是自然、口语化、甚至包含多轮上下文的对话。文档切分方式也直接影响效果——是按段落、标点硬切，还是基于语义边界切分？切分后的“块”如何转化为计算机能理解的向量表示，最终又怎样匹配用户真实需求？此外，表格、图表、公式等多模态内容的提取与表征，同样是现实场景里的棘手问题。处理不当，整个RAG系统的性能将大幅打折。

增强过程

检索到的段落如何与当前生成任务无缝集成，是一个技术活。生硬拼接会导致输出前言不搭后语。若多个段落讲述同一主题，生成时可能出现冗余和重复。更关键的是，面对一堆检索结果，如何判断谁更重要、谁的优先级更高？增强过程必须学会权衡每个段落的“分量”。

生成质量

生成模型过度依赖检索内容，反而可能引发新的幻觉——它可能照搬信息而非进行真正的整合与提炼。当然，生成的答案答非所问，或带有偏见、有害内容，也是需要直面的问题。

整体架构

一个成熟的RAG系统，底层逻辑通常是分层的。

产品架构

从产品角度看，最底层是模型层，作用是屏蔽不同模型的差异——既可使用自研模型，也可接入开源或第三方大模型。为优化跨语言检索效果，还专门设计了跨语言Embedding模型。再往上是离线理解层，核心是智能知识库与搜索增强两大模块。知识库负责将非结构化文本（如PDF、网页）处理成可检索形式，涉及文本解析、表格识别、OCR等。搜索增强则通过问句改写、重排等模块，死磕检索精度。再上一层是在线问答层，需满足多文档、多轮次、多模态以及安全拒识等产品需求。最上层是场景层，针对不同行业预制了各种角色，降低使用门槛。

技术架构

拆开来看，RAG的核心技术链条可分为三部分：Query理解、检索模型和生成模型。

• Query理解：目标是搞清用户真正想问什么，甚至将非结构化自然语言问题转换成可查询结构化或非结构化数据的结构化形式。包含query改写、扩写、意图识别等模块。
• 检索模型：任务是从文档集或知识库中捞出相关信息。主要依赖文档加载、文本转换（分块）、Embedding（向量化）等技术。
• 生成模型：接收检索到的信息，结合Prompt与上下文，生成最终答案。涉及长短期记忆管理、Prompt优化等。

简言之，先用检索模型保证准确性，再用生成模型产出内容。两者结合，取长补短。

Query理解

很多时候，RAG检索不到用户想要的东西，问题往往出在“问”的方式上。要么是用户措辞不利于检索，要么是压根无法从问题中提取出有效的结构化查询。因此，专门的Query理解模块变得至关重要。

意图识别

该模块原理很直接：接收用户query与一系列预定义“选项”，让LLM（或传统分类模型）决定选哪个。例如，判断当前问题是该做摘要还是语义搜索，或者该从哪个数据源捞数据。常用实现方式有两种：一是让LLM当裁判，把选项塞进Prompt让它选；二是训练传统分类模型，如基于语义匹配或Bert的意图分类器。

Query改写

很多时候，用户的原始input并非最佳检索条件。所以得先让大模型“润色”一下问题，让它更适合检索。

• HyDE：核心思路是让LLM先基于query生成一个假设性回答。虽然答案可能不够准确，但能捕捉问题的核心模式。然后再将query与假答案一起转成向量去检索，效果往往优于单用query。
• Rewrite-Retrieve-Read：该框架更直接，先训练一个小模型（如T5）作为专门改写器，专门调整query措辞，以适应固定的检索器和LLM。为让改写器学得更聪明，还会用强化学习训练——检索效果越好，奖励越大。

Query扩写

复杂问题不能直接丢给检索，得“分而治之”。

• Step-Back Prompting：遇到涉及很多细节的复杂问题时，先让LLM“后退一步”，提炼出一个更高层次的抽象概念。随后拿着抽象概念与原始问题一起去检索，结果更靠谱。
• CoVe：Chain of Verification的思路是用LLM生成的答案反过来验证自己。在RAG场景里，可把一个复杂问题拆成多个更简单、更利于搜索的子问题，并行检索，最后汇总答案，有效减少幻觉。
• RAG-Fusion：通过LLM将一个问题生成多个不同角度的query，并行检索后，再用倒数排名融合（RRF）算法合并排序。特别适合需要多维度信息才能回答的问题。
• ReAct：将思维链（CoT）与行动（Action）结合。模型不仅能推理，还能主动决定查询知识库的哪个部分，并根据返回的信息调整下一步行动。在复杂组合式查询中非常有用。

Query重构

很多时候，一个用户问题里可能同时包含需要改写、拆解、扩展的需求。因此我们自研了一个“一条龙”的Query重构模块。它可以在一次请求中，自动完成对原始复杂问题的改写、拆解和拓展，挖掘出更深层次的子问题，从而显著提升复杂问题的检索质量。

检索模型

检索是整个链条的“水源”，其效果直接决定了后续生成的天花板。挑战也很明显：向量化的准确性、文档分割的合理性、以及最终Prompt拼接——即将检索到的相关文档与用户问题一起丢给大模型时，大模型能否在长上下文中准确定位关键信息。有意思的是，研究《Lost in the Middle》表明，当相关信息出现在输入内容的开头或结尾时，大模型表现最好；一旦被埋在了中间，性能就会明显下降。

文档加载器

这是最基础的模块，负责从各种数据源（如txt文件、网页、YouTube字幕）加载文档数据。

文本转换器

加载完文档，下一步是把它切成适合检索的小块。理想情况下，切分要保证每个块在语义上是完整的。常见切分方式有按字符切、按递归逻辑切（更推荐）、按HTML标签切、按Markdown标记切、按代码语法切，还有按Token切。更高级的实验性“语义切分器”会先把文本切成句子，再将语义相似的句子合并成一个块。

文本嵌入模型

切好的块需要转成向量。理想的嵌入模型应具备多种能力：跨语言关联（如中文query搜英文文档）、长短文本关联（如长原文与短摘要）、同义表达关联、相同意图的不同问题关联，以及问题与答案文本关联。此外，检索器最好还能给出尽可能多的相关片段，把真正有用的排在最前面，并过滤掉低质量内容。一个能覆盖多领域、开箱即用的通用模型，自然是更好的。

向量数据库与索引

有了向量，就需要数据库来存和搜。常见索引结构有几种：摘要索引（按顺序存，按关键词过滤）、树索引（构建层级结构，父节点是子节点的摘要，查询更高效）、关键词表索引（建立关键词到节点的多对多映射）、以及最流行的向量索引（直接计算向量相似度）。

排序和后处理

检索结果不止一条，需要筛选。常见策略包括：基于相似度分数排序、基于关键词过滤、让LLM重新排序、基于时间过滤，或对相似度进行时间加权后再排序。

生成模型

检索是手段，生成才是目的。如何利用检索到的信息生成回答，也有讲究。

回复生成策略

一种策略是迭代式：每检索到一个相关块，就将其与当前生成结果结合，不断修正。另一种是批量式：尽可能多地在一次Prompt里填充文本块，让LLM一次性参考所有信息。如果一次塞不下，再拆成多次。

Prompt拼接策略

Prompt的拼接方式也很关键。可用字符串提示（直接把多个模板串起来），也可用聊天提示（把system、user、assistant消息组合在一起）。后者在开发体验上会更友好。

插件：基于演示检索的上下文学习

传统大模型上下文学习，需要手动在Prompt里提供示范例子。这会拉长Prompt长度，增加成本。于是有了“基于演示检索的上下文学习”——从任务库中检索出与当前问题最相似的几个例子，自动加入Prompt。但单一检索策略的召回率往往不高。

为此，我们提出一种混合检索方法，结合文本检索（如BM25）与语义检索（如Embedding），进行多路召回。但多路召回带来的新问题是，不同算法的分数范围不匹配（BM25分数可能很高，而余弦相似度在0-1之间），无法直接排序。于是又引入了基于逆序排序融合（RRF）的重排算法，利用位置信息来融合不同检索算法的结果。考虑到大模型对首尾内容的偏好，还设计了特殊的重排策略，把最有用的信息尽量放在Prompt的开头或结尾。

引用与归因

在知识问答场景下，信息来源的可靠性是核心。归因的作用，对用户来说是验证回答是否靠谱，对模型来说则是提高准确率、减少幻觉。

实现归因主要有两种方式：一是让模型在生成答案时直接输出引用（这依赖模型的指令遵循能力）；二是在生成过程中动态计算——当生成完一个完整语义单元（如一句话）后，实时将其与参考信息进行匹配，找出最相关的来源并附加返回。第二种方式更可控，但前提是模型的生成文本确实来源于参考信息。

评估：如何证明你的RAG比隔壁老王强

开发大模型应用，光有热情不够，还得有“Metrics-Driven Development”意识。理想情况是先定义好场景、数据和指标，再按部就班实现。但现实往往是，场景模糊、数据混乱、指标空白。那么，量化评估该从哪里下手？

影响RAG系统性能的两个关键偏见是：位置偏见（模型更关注开头和结尾的内容）与检索内容相关性（不相关的内容会引入噪音）。针对这些，目前主流的评测指标有三个：

• Faithfulness（忠实度）：生成的回答是否严格基于检索到的上下文，有没有“自由发挥”。
• Answer Relevance（答案相关性）：生成的答案是否解决了用户的实际问题。
• Context Relevance（上下文相关性）：检索到的上下文是否精简，包含尽可能少的无关信息。

在评测方法上，RGB系统性地研究了LLM在RAG场景下的四项基本能力（噪声鲁棒性、拒答、信息整合、反事实鲁棒性）。而RAGAS则提供了一个更全面的无参考评估框架，并已开源。此外，LlamaIndex也提供了衡量生成质量和检索质量的关键模块。

总结

这一波LLM浪潮催生了很多技术，而RAG无疑是其中最“务实”的一个。从Query理解到检索，从生成到评估，每一个环节要想真正做好、达到企业级应用的标准，都需要大量的实践与沉淀。本文总结了过去一年在这一块摸爬滚打的核心经验和关键模块，希望能给正在这条路上的朋友们带来一些实用的参考。