RAG：检索增强生成

RAG（Retrieval-Augmented Generation，检索增强生成）在生成回答前检索外部资料，再让模型利用选中的证据作答。它把一部分知识维护从模型参数转到可更新、可追溯的数据源，但正确性取决于整条链路：资料是否可用，检索是否找到，输入是否保留关键条件，回答是否忠于证据。

RAG 不限定向量数据库。关键词、向量、结构化查询或混合检索都可以提供证据。Haystack 的 Retriever 就是检索阶段的一种组件接口：接收查询，返回候选文档，后续步骤继续处理这些候选。Retriever 文档

两条流程：准备知识，回答问题

flowchart TB
%% title: 数据流图
 subgraph Index["知识准备"]
 D["原始资料"] --> P["解析与语义切分"]
 P --> I["文档、元数据与索引"]
 end
 subgraph Query["在线回答"]
 Q["问题、身份、适用时间"] --> R["限定范围召回"]
 R --> J["融合、重排与去重"]
 J --> C["带来源装配上下文"]
 C --> G["生成回答"]
 G --> V["核验引用、事实与缺口"]
 end
 I -->|授权且适用的候选| R

RAG 数据流区分离线准备与在线回答。图是本文参考设计：来源、版本和权限跨越两条链路；引用存在和结论受支持需要分别验收。

离线流程把原始资料变成可检索对象；在线流程为当前问题找到足够的证据。两条流程通过文档身份、版本和索引连接。

流程	顺序	关键产物
知识准备	获取 → 解析 → 切分 → 编码或建索引 → 发布	带来源、版本和访问范围的片段
回答问题	明确问题范围 → 检索 → 融合与重排 → 装配 → 生成 → 核验	有来源支持、适用条件明确的回答

下面使用虚构案例：用户在 9 月 10 日询问“当前差旅额度是多少”。旧规定额度为 500，新规定于 9 月 1 日发布、9 月 15 日生效，额度为 600。假设适用范围相同，且没有其他变更，正确回答应使用 500，并说明新规定何时生效。

如果系统只按“发布时间最新”选文档，即使向量检索和模型理解都正常，也会答错。问题出在证据适用条件，而非措辞。

切分保留什么，比固定长度更重要

切分是为检索创造处理单位。片段过小，条件与结论可能分离；片段过大，匹配信号变稀，模型输入又被无关内容占据。应先按标题、条款、段落或表格关系保持语义，再用长度限制处理超长单元。

本例中，“600”和“9 月 15 日生效”必须可以一起恢复。可以让片段保留父文档、章节编号及邻接关系，先检索短片段，再按需读取完整条款。重叠切分有助于避免边界断裂，但会产生重复候选，需要按来源与内容关系去重。

建议每个片段至少关联文档 ID、版本、片段位置、来源地址、适用范围和权限信息。发布时间、业务生效时间和入库时间分别记录：它们回答三个不同问题。Embedding 模型或切分规则更新时，索引也要有版本；查询编码与文档向量必须处于兼容的表示空间。

这些是数据设计建议，具体字段随资料类型变化。切分器不知道业务上哪些条件不可分，需要利用真实失败样本检查。

召回、融合和重排分别改变什么

召回先找到候选；融合整合不同检索路径；重排再判断有限候选与当前问题的匹配程度。

方法	可以利用的信号	主要代价或盲点
关键词检索	名称、编号、术语等词项匹配	改写、同义表达可能匹配不足
向量检索	编码后的语义相近性	相似不代表日期、数字或权限正确
混合召回	多种互补的匹配信号	多路成本、重复候选与分数融合
Rerank	查询与候选的联合相关性判断	新增计算，也无法找回未进入候选的资料

不同检索器的分数通常不能直接相加。RRF 可以用排名而不是原始分数融合：候选在多路靠前，就获得较高贡献。但多路共同返回同一份过期规定，仍然只是共同偏差。

Haystack 的固定提交研究用两组受控排名验证了 RRF 与直接拼接排序的差异，源码入口是 DocumentJoiner。实验说明融合语义，没有证明真实任务准确率提升，也没有运行学习型向量检索或 Rerank 模型。

查询改写同样需要约束。“当前差旅额度”可以补充同义词，却不应丢掉查询日期、所属部门或制度名称。多查询扩大候选面后，还要保留每个查询的来源，才能判断哪些分支带来有效证据、哪些只增加噪声。

权限和版本是硬条件

“相关性高”不能抵消“当前用户无权访问”。可信服务端应根据身份限定检索范围，并在资料进入模型前确认访问权限。用户或模型提供的搜索条件，只能在这个范围内进一步筛选。

具体配置名也不能当成权限保证。Haystack 固定版本实验显示，初始化与运行时 filter 的 MERGE 在同字段冲突时可能使用运行时值，不等价于权限集合取交集。过滤策略源码

若业务要求只能搜索租户 A，应由服务端构造不可被调用参数覆盖的范围。仅在 Prompt 写“请勿泄露其他租户”，既不能限制检索，也无法撤销已经进入模型请求的资料。

版本过滤还取决于问题：询问“当前额度”与“下月额度”，允许采用的生效区间不同。删除与撤权需要传播到原文、片段、索引、摘要和相关缓存；索引中移除一条记录不代表此前生成的答案已经全部失效，治理方式见 Memory：记忆治理。

进入上下文，不等于被正确使用

检索命中十个片段，装配器可能只放入三个。必须记录最终选入的资料，而不是只记录检索结果。

本例应向模型提供查询日期、当前适用规定、新规定的未来生效条件，以及两者的来源。若预算不足，优先缩减无关正文；把“9 月 15 日开始执行”删掉，只保留 600，会改变证据含义。装配的具体责任见 Context Engineering。

回答生成后至少核验两种关系：引用编号能否指向真实资料；资料内容是否支持引用处的具体结论。链接存在，只完成了第一项。若正文写额度 600，却引用当前额度 500 的条款，形式完整仍然是错误。

对无答案和冲突也要有输出契约。资料不足时说明缺少什么；资料冲突时保留各自范围与来源，再判断能否消解。模型不应为了交付一句确定答案，把两个不兼容的版本融合。

固定 RAG 与 Agentic RAG 怎样选择

固定流程预先规定检索、重排和生成顺序，适合路径稳定、容易建立评测样本的任务。Agentic RAG 由模型根据中间结果决定是否改写问题、追加查询或切换来源，适合下一步取证依赖已发现线索的任务。

后者增加的是控制能力，也增加重复查询、走偏和费用失控的可能。需要明确可用来源、总预算、停止条件和答案验收。常见组合是把稳定的检索流程封装成工具，由外层 Agent 决定何时调用。Haystack 的 PipelineTool 实现研究展示了这种接法；其中本地实验止于检索与上下文构建，没有运行真实模型回答。

RAG 与 Memory 也不互相替代：RAG 讨论如何取证并生成，Memory 讨论哪些经验被保存、更新和删除。记忆可以成为 RAG 的一个来源，文档 RAG 也可以完全不保存会话经验。

用分阶段实验定位错误

先构建带答案和支持证据的任务集，再分别检查：入库是否保留原意，候选是否覆盖必要证据，装配是否遗漏条件，回答是否得到证据支持。多条证据共同支撑的答案，不能只用“命中任意一条”判断检索成功。

一个有区分力的对照是把人工确认的完整证据直接交给生成阶段。如果仍答错，应检查提示、模型或验收；若能够答对，再调查检索、排序和装配。随后逐项比较关键词、向量、混合、重排与查询改写，保持其他条件一致，记录逐题正确性、无答案处理、费用和延迟。

本文案例与上述对照是设计方案，并非已运行的端到端评测。已有 Haystack 实验可解释组件机制；“哪种 RAG 最好”仍须由目标资料、查询分布和服务约束下的任务结果决定。