RAG关键模块解析：实践必备指南

检索增强生成（RAG）首次由Meta在2020年的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中提出。核心思路是让大模型不再依赖内部知识，而是从外部知识库实时检索并利用信息。在大模型落地场景中，RAG已成为解决幻觉、知识滞后、超长文本处理等系统性问题的“标配”方案。

RAG的挑战

理想与现实存在差距。RAG在实际部署时，核心挑战集中在三个环节：检索精度、增强衔接、生成质量。

检索质量

• 语义歧义：典型如“苹果”指水果还是科技公司？向量表示常混淆概念，导致检索结果偏离目标。
• 用户输入变复杂：用户提问从关键词转向完整自然语言对话，包含多轮上下文和口语化表达，传统关键词逻辑严重失效。
• 文档切分：基于标点、段落还是语义切分？切分后的“块”如何向量化？这些细节直接决定后续匹配效果。
• 多模内容的提取及表征：现实文档包含表格、图表、公式等非纯文本内容。如何提取并清晰表达这些信息？尤其在处理模糊或否定查询时，影响显著。

增强过程

• 上下文的集成：检索结果与生成任务如何无缝衔接？若衔接不当，生成内容则像拼接般缺乏连贯性。
• 冗余和重复：多段检索结果信息重叠，生成时容易重复表述，导致内容冗余。
• 排名和优先级：面对多个检索结果，如何判断哪段对当前任务最重要？增强过程需学会赋予每段信息合理权重。

生成质量

• 过度依赖检索内容：模型有时过于信任检索材料，丧失自主判断，甚至将检索中的错误一并吸收，加剧幻觉。
• 无关性：生成的答案未能解决用户提问，答非所问，是常见痛点。
• 毒性或偏见：生成内容包含有害信息或偏见，必须彻底根除。

整体架构

面对上述挑战，一个健壮的RAG系统应具备怎样的分层架构？

产品架构

宏观上，产品架构分为四层：

• 模型层：作为地基，需屏蔽不同模型（如自研序列猴子、开源模型、第三方API）的差异。同时，为支持向量跨语言检索，需专门开发跨语言Embedding模型。
• 离线理解层：负责“后勤”工作。一是构建智能知识库，对非结构化文本（PDF、表格、图片中的文字等）进行解析、打标、入库。二是搜索增强，通过问句改写、重排等技巧提升检索精准度。
• 在线问答层：面向用户的前线，需支持多文档、多轮对话、多模态问答，同时做好安全性和拒识，直接影响用户体验与竞争力。
• 场景层：针对不同行业（金融、医疗、法律等）预制角色与模板，降低用户使用门槛。

技术架构

从技术实现角度看，RAG核心可拆为三部分：Query理解、检索模型和生成模型。

• Query理解：明确用户意图，将问题“翻译”为系统能高效执行的结构化查询。涵盖Query改写、扩写、意图识别等子模块。
• 检索模型：从知识库中“捞”出最相关信息。核心技术包括文档加载、文本转换、Embedding和向量检索。
• 生成模型：基于Prompt和检索到的上下文，生成连贯且有价值的答案。涉及聊天系统（短期/长期记忆管理）、Prompt优化等。

简言之，RAG通过检索的“准确”与生成的“创意”互补，用知识库为大模型“打底”，确保输出有据可依。

Query理解

许多RAG系统效果不佳，根因在于Query理解。用户提问方式未必适合检索，或需从问题中提取结构化查询条件。因此，必须在此下功夫。

意图识别

判断用户想做什么。例如，用户要摘要还是具体答案？通常可用LLM决策（将各种选择塞入Prompt供其选择），也可单独训练传统分类模型（如基于Bert的意图分类器）。应用场景包括决定从哪个数据源查询、使用摘要还是搜索策略、是否同时尝试多个方案。

Query改写

原始用户问题常非最优检索词。需利用LLM进行“润色”。

• HyDE：先让LLM根据问题生成一个“假设的”完美答案，再用该假设答案的向量检索真实文档。因假设答案的语义空间与文档更接近，可搜到更相关的内容。
• Rewrite-Retrieve-Read：直接使用LLM改写查询。还可训练小模型（如T5）专门负责，甚至用强化学习优化改写策略，目标使改后query在后续检索和生成中表现更佳。

Query扩写

面对复杂问题，采用“分而治之”。将大问题拆解为多个具体子问题分别检索，最后整合结果。

• Step-Back Prompting：鼓励LLM“后退一步”，先抽象出问题的更高层级概念。例如问“水温是多少”，先抽象成“水的物理性质”，再会同原问题一起检索，效果更优。
• CoVe：Chain of Verification。让LLM自我“挑错”：先生成初步答案，围绕该答案生成验证问题，检索知识库验证，最后修正答案，赋予模型自我纠错能力。
• RAG-Fusion：简单但有效。让LLM生成多个不同角度的子查询，并行搜索，再用“倒数排名融合”算法排序合并，覆盖更广知识面。
• ReAct：推理与行动结合的经典范式。模型一边推理（CoT），一边执行动作（如搜索知识库），根据反馈更新推理，循环直至解决问题。

Query重构

在实际pipeline中，我们将上述思想综合，自研“Query重构”模块。只需一次请求，即可对用户复杂问题同时进行改写、拆解和拓展，挖掘深层子问题，一举解决复杂问题检索不准的痛点。

检索模型

检索模型的挑战

检索环节面临直接挑战：Embedding模型向量化是否准确？文档切分是否合理？此外，将检索内容拼接成Prompt送入大模型时，模型能否在长上下文中快速定位有用信息？《Lost in the Middle》论文指出，大模型对长上下文中间位置的信息“迟钝”，开头或结尾的信息更易被采纳。

文档加载器

负责从各种来源（.txt文件、网页、甚至YouTube字幕）加载文档数据，转化为文本和元数据。支持“懒加载”，避免一次性加载所有内容到内存。

文本转换器

加载后的文档需先“切块”。理想情况是将语义相关的片段合并，并控制块大小，确保能塞入模型上下文窗口。常见切分方式：按字符递归切分（最推荐）、按HTML/Markdown标签切分（保留结构化信息）、按代码语言切分、按Token数量切分。开源工具Chunkviz可辅助可视化，便于调整参数。

文本嵌入模型

将文本转化为向量表示的核心。理想嵌入模型应具备跨语种关联能力（如“苹果”与“Apple”），能关联长原文与短摘要、不同表述但语义相同的文本、以及问题与可能答案。更重要的是，检索结果越靠前越有用，最好能自动过滤低质量片段。

向量数据库与索引

数据处理后需建立索引以支持快速检索。常见索引结构包括：摘要索引（按顺序存储）、树索引（构建层级摘要树，便于高层检索）、关键词表索引（建立关键词到文档块的多对多映射）、以及主流的向量索引（基于向量相似度匹配）。

排序和后处理

检索结果需排序。常用策略：按相似度分数过滤、按关键词过滤、让LLM打分重排、按时间过滤、或按时间对相似度加权排序等。

生成模型

回复生成策略

检索到的文本块如何喂给大模型生成回答？常见两种思路：一种是“吃一口想一步”，每拿一个块就让模型修正一次答案；另一种是“吃饱再想”，一次性将所有块塞入Prompt，让模型一次性生成。实践中可组合使用。

Prompt拼接策略

如何将系统指令、检索文档、历史对话和用户问题组装成有效Prompt？常用字符串提示（直接拼接所有模板）和聊天提示（按消息列表组织，如SystemMessage、HumanMessage、AIMessage等）。

基于混合演示检索的上下文学习

这听起来复杂，实则在做RAG时不仅检索知识库，还检索“过往成功问答案例”（示范性示例）。将与当前问题最相似的问答对一并塞入Prompt，让模型模仿回答。但关键是如何找到最合适的示例？单一检索方法（如纯语义或纯文本）效果不佳。

我们的解法是构建“混合检索+重排”插件模块。

检索模块

采用多路召回。语义检索使用双塔模型（如OpenAI的embedding-ada），文本检索使用BM25。既能捕捉语义相似，又能确保关键词匹配，互补短板。

重排模块

多路召回结果如何融合？不同算法分数区间不同，无法直接比较。我们引入倒数排名融合算法：忽略分数，只看排名，将各算法给候选示例的排名位置综合计算新分数。鉴于大模型“偏食”开头和结尾，我们不简单按新分数排序，而是将结果“两头填”——例如排好的12345重排后变为13542，确保重要信息置于模型最容易看到的两端。

生成模块

最后，将重排后的示例、系统Prompt、长期/短期对话记录及用户当前问题，一起组装成Prompt，送入大模型生成最终答案。

引用或归因生成

让模型“有据可查”至关重要。归因即让生成答案指向知识库具体来源，提高用户信任度，也是减少幻觉的有效手段。

实现方式主要有两种。一种是模型生成：在Prompt中要求模型“每个观点后面注明来源”。该方法最直接，但对指令遵循能力要求极高，且易编造引用。另一种是动态计算：在模型流式生成时，实时将生成句子与参考源匹配（关键词或向量相似度），找出最可能来源并附上。该方法更可控，badcase修复周期短，但依赖良好匹配阈值，且假设模型文本确实来源于参考信息。

评估

开发AI应用需具备MDD（指标驱动开发）意识。理想情况是先确定场景、数据、指标、目标分值，再逐步实现。但现实中常面临场景不清、数据难洗、指标未定义。

如何量化证明RAG系统更优？需关注以下方面对性能的影响：位置偏见（大模型偏爱开头和结尾）、检索内容相关性（不相关即噪音）。

评测指标

• Faithfulness：生成回答是否忠实于检索到的上下文？这是避免幻觉的关键。
• Answer Relevance：生成答案是否真正解决用户问题？
• Context Relevance：检索到的上下文是否精炼，尽可能少含无关信息？冗余越少，相关性越高。

评测方法

• RGB：系统评估LLM在噪声鲁棒性、拒答能力、信息整合和反事实鲁棒性四项基本能力。
• RAGAS：提供无需参考答案的评估框架，从检索、利用和生成质量三维度打分，已开源。
• Llamalindex-Evaluating：LlamaIndex提供衡量生成和检索质量的模块，非常实用。

总结

大模型浪潮催生了大量技术细节。从Query理解到检索、生成、评估，每个环节若想在企业级应用中做到极致，都需要长期研究、实践和打磨。本文总结了我们团队过去一年在RAG实践中的核心模块，希望能带来启发。