#RAG 是什么

模型可以回答通用问题，却未必知道公司刚更新的制度、内部接口文档，或某个项目的最新约定。RAG（Retrieval-Augmented Generation，检索增强生成）正是为这类问题设计的：先检索与问题相关的外部知识，再将检索结果作为上下文交给模型生成答案。

#为什么需要 RAG

只依赖模型参数回答问题，通常会遇到以下限制。

• 模型知识不是实时的：模型参数中的知识来自训练数据，不会自动同步最新的制度、接口或产品规则，容易给出过期答案；
• 私有知识不在模型参数里：公司制度、内部 API 文档、项目资料和运维手册等内容通常不在模型参数中，或者模型掌握的版本已经落后；
• 用户问题通常很具体：退款流程、错误码或鉴权失败等答案常藏在某个段落、表格或规则里，先检索相关证据通常比只靠模型泛化更稳；
• 长上下文无法替代检索：把全部资料直接放入上下文会增加成本、延迟和噪声，相关信息也可能被淹没。RAG 先筛选资料，再将最相关的部分提供给模型。

#什么场景适合用 RAG

判断是否适合使用 RAG，主要看知识源是否包含回答所需的信息，并且可靠、可检索。

适合的场景包括：

• 企业内部知识问答，如制度、流程、客服知识库和项目资料；
• 专业资料问答，如产品文档、API 文档、代码库和运维手册；
• 需要引用来源、便于核验答案的文档助手。

以下情况不适合只使用 RAG：

• 答案主要依赖开放式推理或创作，检索外部资料无法提供有效帮助；
• 知识源不完整、已过期或无法稳定检索，RAG 无法弥补源数据的质量问题；
• 任务需要多步执行、调用工具或推进流程，此时应由工作流或 Agent 负责调度，RAG 可以提供检索能力。

#RAG 的处理流程

以文档知识库为例，RAG 的处理流程分为两个阶段：

• 离线阶段：处理原始文档，构建可检索的知识库；
• 在线阶段：根据用户问题检索相关内容，组装上下文并生成答案。

#离线阶段：构建知识库

离线阶段负责处理原始文档，并将结果写入可检索的索引。

#数据接入与清洗

原始数据可能来自 PDF、Word、Markdown、网页、数据库或工单系统。接入后需要先正确解析内容并清理噪声，解析质量会直接影响后续召回。

常见的解析问题包括：

• PDF 解析顺序错乱；
• 表格被拆坏；
• 标题层级丢失；
• 页眉页脚和噪声混进正文。

#切块

切块就是把文档拆成适合检索的文档块（chunk）。系统通常以文档块为检索单位，需要在信息完整性和检索精度之间取得平衡：

• 文档块过大，容易混入无关内容，降低检索精度；
• 文档块过小，容易丢失必要的语义上下文；
• 切分边界不合理，可能把相关信息拆散。

常见做法是优先按标题、段落等结构切分，再用长度限制兜底，并在相邻文档块之间保留少量重叠内容（overlap）。重叠范围过大会增加重复结果和排序噪声，不能代替合理的切分边界。

#元数据补充

除了文本内容，还要给文档块补充元数据，比如：

• 文档标题；
• 章节路径；
• 更新时间；
• 来源链接；
• 业务域；
• 权限标签。

元数据可用于检索过滤、来源引用和结果解释。权限标签可以参与授权过滤，但系统仍需根据当前用户的权限执行访问控制。

#构建索引

索引形式取决于检索方式：

• 向量检索：通过 Embedding 模型将文档块转换为向量，按语义相似度召回内容；
• 关键词检索：建立关键词索引，适合匹配错误码、接口名、表名和版本号等精确内容；
• 混合检索：结合向量和关键词检索，再合并两路结果。

Embedding 模型负责生成向量，索引系统负责存储并检索向量或关键词，两者职责不同。

知识源发生新增、修改或删除时，也要同步更新对应的文档块和索引，避免检索到过期内容。

#在线阶段：检索并生成答案

在线阶段根据用户问题检索相关证据，组装上下文并交给模型生成答案。问题改写和重排根据实际需求加入，意图识别则通常位于 RAG 之前，负责应用级路由。

#意图识别（按需）

在同时支持知识问答、工具调用和闲聊的应用中，意图识别先判断任务类型：知识问答进入 RAG，其他请求转到对应的处理链路。只提供知识问答的应用可以省略这一环节。

#问题改写（按需）

当用户原话不适合直接检索时，可以先做问题改写，常见情况包括：

• 问题太短，比如“退款怎么走”；
• 指代不清，比如“这个接口为什么失败”；
• 依赖上下文，比如“那第二种情况呢”；
• 用户使用的术语与文档不一致。

系统可以补足上下文、展开缩写、替换为知识库中的标准说法，或者生成多个检索查询。改写需要保留用户原意，必要时可以同时使用原问题和改写后的查询进行召回。

#召回

召回负责从知识库中找出可能相关的候选内容，并尽量避免遗漏真正相关的证据，常见方式包括：

• 向量召回：按语义相似度找内容；
• 关键词召回：按术语、错误码、接口名精确匹配；
• 混合召回：两路一起做，再合并结果；
• 多路召回：使用不同查询、索引或数据域并行召回。

检索时还要根据当前用户的权限，通过元数据过滤数据范围，避免未授权内容进入候选集。

#重排（按需）

召回阶段会尽量覆盖可能相关的内容，但候选结果的排序不一定准确。重排会进一步评估候选内容与问题的相关性，调整顺序，选出最适合放入上下文的内容。

常见的重排策略包括：

• 规则重排：根据关键词命中、来源权威性、更新时间等条件调整分数；
• 排名融合：使用 RRF 等算法合并多路召回的排名；
• 专用重排模型：同时输入问题和候选内容，计算更精确的相关性分数；
• 大模型重排：让大模型比较少量候选内容，适合复杂判断，但成本和延迟更高。

实际系统可以组合多种策略，例如先融合多路召回结果，再用专用模型评估排名靠前的候选。如果相关证据已经进入候选集，却没有进入最终上下文，通常需要检查重排或上下文组装策略。

#上下文组装

拿到召回或重排后的候选内容后，上下文组装负责将其整理成模型输入，常见处理包括：

• 删除重复内容，合并相邻文档块，保留完整语义；
• 根据 token 预算在完整文档块之间取舍，优先保留相关性更高的内容；
• 添加标题和来源标识，保留证据与来源的对应关系。

最终上下文应保留相关、完整且来源可追溯的证据，为生成答案提供依据。

#生成答案

生成阶段将用户问题和组装后的上下文一起交给模型，并通过提示词明确以下约束：

• 只回答有上下文证据支持的内容；
• 证据不足时明确说明，避免强行生成结论；
• 引用上下文中提供的来源标识，并保持引用与证据对应。

这些约束可以减少无依据的内容，但不能完全消除错误，关键结论和引用仍需结合原始证据核验。

#RAG 的优化思路

RAG 优化应先定位问题，再调整对应环节。开始前应建立代表性问题集，标注期望召回的证据或答案要点，并记录候选内容、最终上下文、生成结果、延迟和成本。

每次调整后，都应使用同一组问题重新评测，比较回答质量、召回效果、引用准确性、延迟和成本。每次只调整一个主要变量，其他条件保持不变，才能判断优化是否有效。

#总结

RAG 在模型生成答案前检索外部知识，为回答提供与问题相关、来源可追溯的证据。它的效果取决于知识源质量、检索与筛选结果、上下文组织和生成约束；出现问题时，应根据评测结果定位具体环节，再进行针对性调整。