什么是RAG

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让大模型“先查资料，再根据资料回答”的方法。 它把信息检索与语言生成结合起来，让模型能够使用企业文档、产品手册、数据库、网页等外部信息。

你可以把它理解为“开卷作答”：模型负责理解问题、组织语言和推理，检索系统负责找到相关参考资料。常见 RAG 系统在回答时把资料放进模型的上下文，通常无需修改模型参数。2020 年的经典 RAG 论文研究了把模型参数中的知识与外部检索知识结合起来的方案。RAG 原始论文

下面从一个例子开始，再逐步展开它的工作原理和工程实现。

假设你在做一个文档产品的客服助手，用户问：

基础版可以批量导出 PDF 吗？

知识库中有这样一段内容，以下为虚构示例：

《产品手册 v3》第 8 节：基础版支持单篇导出 PDF；批量导出功能仅向专业版开放。

RAG 系统检索到这段资料后，把它和问题一起交给模型，模型就可以回答：

基础版暂不支持批量导出 PDF，可以逐篇导出。批量导出需要专业版。依据：《产品手册 v3》第 8 节。

如果产品规则发生变化，系统可以通过更新知识库来使用新规则。资料何时同步到检索系统，决定了回答能否反映这次变化。

RAG 的核心流程可以拆成三个动作：检索、增强和生成。

• 检索（Retrieve）：从外部数据中找到与问题有关的内容。
• 增强（Augment）：把这些内容连同问题、回答规则一起组织成模型输入。
• 生成（Generate）：模型阅读证据，生成回答，并按需要给出引用。

检索既可以使用关键词搜索，也可以使用向量搜索、混合搜索或其他数据查询方式。微软 RAG 概念说明

整个系统通常分为建库和问答两个阶段：

flowchart TB
    subgraph A["建库阶段：资料新增或更新时"]
        D["文档、网页、业务资料"] --> P["解析、清洗、切块"]
        P --> E["建立关键词与向量索引"]
        E --> I[("索引、原文与元数据")]
    end

    subgraph B["问答阶段：用户提问时"]
        Q["用户问题"] --> R["检索相关资料"]
        R --> K["筛选、去重与重排序"]
        K --> C["问题＋证据＋回答规则"]
        C --> L["大模型生成"]
        L --> O["回答与来源引用"]
    end

    I --> R
    Q --> C

下面沿着这条链路，看看每一步具体做什么。

1. 解析和清洗：让原始资料能够被正确使用。

   原始资料可能是 PDF、Word、网页、Markdown、扫描件或表格。系统需要提取正文，并尽量保留标题层级、表格结构、页码、版本等信息。

   这一步经常决定后面的质量。例如，一个表格原本表示：

   版本	单篇导出	批量导出
   基础版	支持	不支持
   专业版	支持	支持

   如果解析后变成“基础版 专业版 支持 不支持 支持 支持”，列与行的对应关系就丢失了。后续即使检索命中，大模型也可能解释错误。

   扫描件通常需要 OCR；网页需要去除导航和重复页脚；重复文档需要去重。知识库的质量首先取决于这些基础处理。

2. 切块（Chunking）：把资料拆成适合检索的单元。

   一份长文档可能包含很多主题，直接用整篇文档进行匹配，容易让相关内容被其他主题稀释。因此，系统常把文档拆成若干片段，每个片段称为一个 chunk。

   切块需要在信息完整性和检索精度之间取舍：

   • 块太小，容易丢掉主语、适用条件、例外和前后文。
   • 块太大，容易引入无关内容，增加模型输入成本。
   • 相邻块适当重叠，可以保留边界处的上下文，但也会增加重复内容。

   实际上可以按标题、段落、句子或固定长度切分，也可以组合使用。例如，先按章节划分，再把过长的章节拆开。长度通常按 token 衡量，token 是模型处理文本的单位，与中文字数没有固定换算比例。文档切块说明

   每个块最好保留来源信息，例如：

   文档：产品手册
   章节：导出功能
   版本：v3
   页码：18
   正文：基础版支持单篇导出……
   

   这些信息既帮助检索，也方便生成可追溯的引用。

3. 向量化（Embedding）：把文本转换成能够比较的数值表示。

   Embedding 模型会把文本映射成一个向量，例如：

   “如何一次导出多个文件？”
           ↓
   [0.12, -0.37, 0.08, ...]
   

   这串数字用于表示文本的语义特征。问题和文档使用匹配的编码方式进入同一个向量空间后，系统就能通过相似度寻找相关片段。Sentence Transformers 文档

   例如，“一次导出多个文件”和“批量导出”文字不同，但语义接近，向量搜索有机会把它们匹配起来。

   在常见的文本 RAG 中，向量主要用于定位资料，最终交给生成模型阅读的仍然是检索到的正文。

   还要注意，向量相似度表达的是匹配程度，不能直接当作答案正确的概率。 “支持批量导出”和“不支持批量导出”主题非常接近，区别却决定了答案。

4. 检索（Retrieval）：从大量资料中筛出候选内容。

   常见方法各有用途：

   检索方式	匹配依据	适合处理的情况
   关键词检索	词项匹配，常用 BM25 排序	产品型号、错误码、术语、编号
   向量检索	语义相似度	同义表达、口语化问题
   混合检索	综合关键词与向量结果	同时需要精确匹配和语义理解
   元数据过滤	版本、日期、产品、权限等字段	限定资料的适用范围

   例如，问题里出现 ERR_1042，精确匹配这个编号很有价值；问题是“为什么一直进不去”，语义检索可能更有帮助。混合检索可以综合两类结果，再去重、融合排序。混合检索示例

   检索返回数量常用 Top-K 表示，即取排名靠前的 K 条。K 太小可能遗漏证据，太大可能引入噪声，具体数值需要通过实际问题测试。

5. 重排序（Reranking）：进一步判断哪些候选资料最有用。

   第一轮检索强调效率，需要从大量内容中快速找出候选集。重排序则对候选集做更细致的相关性判断。

   一种常见方式是使用 Cross-Encoder：把“问题＋某个候选片段”一起输入模型，让它直接评估两者的相关性。由于需要对候选逐一计算，这类方法通常用于第一轮检索之后。检索与重排序说明

   例如，可以先召回 40 个片段，再重排序选出 6 个作为回答依据。这只是流程示例，数量应根据质量、延迟和成本调整。

   重排序能改善候选顺序，但它无法找回第一轮完全没有检索到的证据。

6. 组织上下文并生成回答：让模型准确使用证据。

   系统会把筛选后的片段组织成类似这样的输入：

   回答规则：
   - 根据参考资料回答问题。
   - 对关键事实标注资料编号。
   - 资料不足时说明缺少什么信息。
   - 资料存在冲突时指出冲突及适用版本。
   
   参考资料：
   [资料1] 产品手册 v3，第8节：……
   [资料2] 导出功能更新说明：……
   
   用户问题：
   基础版可以批量导出 PDF 吗？
   

   生成模型负责综合证据、解释概念、比较差异，并把答案组织成自然语言。

   工程上还可以在生成后检查：引用编号是否存在、链接是否有效、关键陈述是否得到引用内容支持。出现一个引用，只说明系统给出了来源标记；引用是否真正支持结论，需要另外验证。

RAG 与微调解决的问题有交集，但主要作用位置不同。

对比维度	RAG	微调
主要改变什么	模型回答时获得的外部上下文	模型或适配器的可训练参数
常见用途	使用私有资料、动态知识、可追溯证据	改善特定任务表现、领域表达和输出习惯
知识更新方式	更新数据源和索引	通常需要更新训练数据并再次训练
来源追溯	可以把检索来源与回答关联	通常需要额外设计来源追溯机制
主要工程成本	数据处理、检索、上下文和运行维护	数据准备、训练、评估和模型维护

RAG 和微调可以组合使用，例如用微调改善模型对行业术语、任务格式或证据使用方式的掌握，再通过 RAG 提供最新业务资料。微调也能学习事实知识，只是频繁更新、精确修订和追溯事实通常需要额外设计。微软研究：RAG 与微调的比较

如果资料很少，直接把完整资料放进模型上下文，也值得作为基线方案测试。随着资料量增加，选择性检索通常更有利于控制输入规模。不过，上下文容量和实际利用能力需要分别评估；已有研究观察到，相关信息在长上下文中的位置会影响回答效果，具体表现仍取决于模型和任务。长上下文研究

RAG 可以降低凭空编造的风险，但最终可靠性取决于整条证据链。

常见问题及其原因可以这样排查：

表现	可能原因	优先检查
知识库里有答案，却答不出来	查询表达不匹配，或切块不合理	检索结果、关键词、分块边界
回答引用了旧规则	索引未同步，或版本混用	更新时间、生效日期、版本过滤
找到了正确段落，却漏掉例外	例外条款在其他片段	相邻段落、父章节、补充检索
答案看似合理，但证据不支持	模型进行了无依据补充	逐条核对陈述与证据
跨多份资料的问题表现差	一次检索没有覆盖全部证据	问题拆解、多轮检索
问答很慢、成本很高	候选过多、上下文过长或调用轮次过多	各阶段耗时与输入规模

检索到的资料也可能本身有误。模型忠实复述错误资料，依然会产生错误答案，因此资料质量和来源权威性也需要管理。

企业应用还需要让检索范围遵守用户权限，并及时同步权限变化。文档级访问控制说明 外部文档中的指令性文字也应作为资料内容处理，避免其中的恶意指令影响系统行为；这类问题通常称为间接提示注入。间接提示注入说明

评估 RAG 时，应分别衡量“资料找得怎么样”和“答案写得怎么样”。 这也是 RAGAs 等评估研究采用的基本思路。RAGAs 论文

可以重点观察以下指标：

• 检索召回率 Recall@K：所有标注的相关证据中，前 K 条结果找回了多少。
• 检索精确率 Precision@K：前 K 条结果中，有多少确实相关。
• 答案正确性：答案是否符合真实业务事实，是否完整回答了问题。
• 证据忠实度：答案中的陈述是否得到提供资料的支持。
• 引用质量：引用是否支持对应结论，关键结论是否都有依据。
• 资料不足时的表现：系统能否识别缺少证据，并说明需要补充什么。
• 运行表现：响应延迟、单次成本、失败率和资料同步时效。

测试集应包含正常问题、口语化问题、跨文档问题、版本冲突，以及知识库中根本没有答案的问题。自动评分可以辅助定位问题，关键业务结论仍适合结合人工抽查。

复杂任务还会在基础 RAG 上增加不同能力。

• 查询改写与拆解：把“那专业版呢？”结合对话历史改写成完整问题，或把复杂问题拆成几个可分别检索的子问题。
• 多轮检索／Agentic RAG：让系统根据已有证据决定是否继续搜索、换一种查询或访问其他数据源，需要控制轮次和停止条件。
• 带上下文的切块：为片段补充所属文档、主题或适用范围，帮助检索理解脱离原文后容易失去含义的内容。Contextual Retrieval
• GraphRAG：利用实体、关系及图结构组织证据。以微软的实现为例，局部搜索结合图信息与原文片段，全局搜索使用社区摘要处理整个资料集的主题问题。GraphRAG 查询说明

这些方法适用于不同问题，复杂程度增加后也需要额外的数据处理、评估和运行成本。

如果准备实际开发，我建议先选一个范围明确的场景，例如“产品手册问答”，准备几十份高质量文档和一组真实问题，做出包含解析、切块、检索、带引用回答、效果评估的完整流程。根据失败案例决定下一步：找不到资料就改善检索；找到了却答错就改善上下文和生成；证据分散在多处，再加入问题拆解或多轮检索。