RETRIEVAL-AUGMENTED GENERATION

从「找得到」到「说得准」

8 个核心知识点 · 全流程动态图解 · 点击节点可跳转

① 检索链路 ② 增强与治理 文档切分 向量检索 混合检索 重排 GraphRAG 事实校验 引用溯源 知识更新 切得对 找得到 不漏不错 排得准 连得起来 说得真 可回溯 不过期
1

检索链路：让正确的片段进入上下文

文档切分 → 向量检索 → 混合检索 → 重排

文档切分

索引质量的地基Chunking
原始文档.pdf 1 递归字符切分（默认） 2 语义切分：相似度骤降处断开 3 固定窗口 + 重叠窗口 按文档类型选：论文 / 法条 / 表格 / 代码各不相同 Chunk 1 ↕ overlap 重叠 64 tokens Chunk 2 ↕ 跨块句子不再被截断 Chunk 3 Chunk 4 + 元数据：标题层级 / 页码 / doc_id chunk_size 512 · overlap 64 · 每个块都能独立回答一个问题
  • 递归切分是最稳的默认：段落 → 句子 → 字符逐级降级
  • 语义切分：相邻句 embedding 相似度骤降处断开
  • overlap 10%–20%，防止关键句被腰斩
  • Small-to-Big：小块检索、大块喂给模型
切分决定了召回上限：切错了，后面再强的重排也救不回来。

向量检索

语义召回Vector Retrieval
用户 Query "报销发票丢了怎么办" 向量空间（ANN 索引） Top-1 Top-2 Top-3 query 向量 Top-K = 3 ① 报销制度 v3 ② 发票补办流程 ③ 财务 FAQ Embedding 决定天花板 · HNSW 高精度 / IVF-PQ 省内存 · 余弦相似度
  • 把文本压成向量，用距离找最近邻
  • Embedding 模型必须与语料同语言、同领域
  • ANN 近似检索：HNSW 快而准，IVF-PQ 省内存
  • 向量不认识型号 / 编号 / 人名拼写 → 需混合检索
  • 召回 Top-50~100，宁多勿漏，交给重排收口
向量检索负责「语义像不像」，不负责「关键词准不准」。

混合检索

稀疏 + 稠密Hybrid Retrieval
Query「iPhone 17 电池健康」 BM25 · 稀疏 关键词精确匹配 → 召回「iPhone 17」 Embedding · 稠密 语义匹配 → 召回「电池续航下降」 #1 iPhone 17 规格表 #2 手机型号对照 #3 iPhone 17 拆机报告 #1 电池健康度说明 #2 续航下降排查 #3 充电循环计数 RRF 融合 Σ 1 / (60 + rank) 融合 Top-K → 送去重排 两路都出现的文档排名自然靠前 RRF 只用排名、不需分数归一化，是工程上最省心的融合方式
  • BM25 补齐型号、编号、法条号等精确匹配
  • 向量补齐同义改写、跨语言、语义相关
  • RRF：score = Σ 1/(k + rank)，k ≈ 60
  • 也可用加权融合，但需先做分数归一化
  • 单路召回落下的，另一路往往能补回来
实践结论：混合检索几乎总是优于任一路单检。

重排

精度收口Rerank
召回 Top-8（粗排） Bi-Encoder · 毫秒级 条越长 = 向量相似度越高（前 4 名送精排） Cross-Encoder 精排 Query [SEP] Doc tokens Query 与 Doc 拼接后全交互打分 慢（几十毫秒）但准得多 精排 Top-4 色深 = Cross-Encoder 打分高低 12 34 #1 报销制度 v3 0.72 #2 发票补办流程 0.86 #3 差旅规定 0.31 #4 报销 FAQ·补办专章 0.94 粗排第 4 名，精排后跃居第 1 —— 这才是重排存在的意义
  • 两段式：Bi-Encoder 粗召回 → Cross-Encoder 精排
  • 典型配比：召回 50–100 → 精排 5–10
  • LLM listwise 重排更准，但延迟与成本高
  • 延迟敏感场景：只重排 Top-20，或做结果缓存
重排是性价比最高的一道工序：不动索引，直接涨准确率。
2

增强与治理：让答案可信、可查、不过期

GraphRAG → 事实校验 → 引用溯源 → 知识更新

GraphRAG

跨文档 · 多跳Graph-based RAG
文档语料 非结构化文本 LLM 抽取 实体 · 关系 · 主张 （索引期一次性成本） 知识图谱 + 社区聚类（Leiden 分层社区） 社区 C1 社区 C2 社区 C3 第 1 跳 第 2 跳 第 3 跳 C1 社区摘要 自底向上逐层聚合生成 C2 社区摘要 实体关系 + 关键主张 C3 社区摘要 可增量更新，不必全量重算 Query：A 与 D 什么关系？ 先映射到相关社区 全局答案 Map-Reduce 汇总各社区 部分回答 → 合并去重
  • 索引期：抽取实体/关系 → 建图 → 社区聚类 → 生成社区摘要
  • 查询期：社区映射 + 多跳遍历，比向量更会"连"
  • 擅长跨文档、多跳、总结类问题（"整体趋势是什么"）
  • 代价：构建贵、更新慢，宜与向量库并存而非替代
向量库擅长"哪段像"，图谱擅长"谁跟谁有关"，两者互补。

事实校验

防幻觉闸门Fact Verification
生成的答案（逐句拆解） S1「发票可提交电子复印件补办」 证据命中 S2「必须在 3 天内提交申请」 与证据冲突 S3「逾期将影响下月报销额度」 证据中未提及 NLI 校验 蕴含 Entailment 矛盾 Contradiction 中立 Neutral 逐句 ↔ 证据比对 ✓ 保留并附引用 ✕ 删除 / 改写为正确期限 ? 触发补充检索 补充检索 → 仍无法证实 → 回答「未找到」 宁可说"我不知道"，也不要一本正经地编
  • NLI 三分类：蕴含 / 矛盾 / 无法证实
  • 无法证实 → 再检索一次，仍无则降级为"未找到"
  • 自一致性：多次采样投票，少数派说法重点复核
  • 医疗、金融、法务等场景应强制校验后再出
校验放在生成之后、返回之前，是最后一道闸门。

引用溯源

可审计Citation & Provenance
答案（句级角标） 发票遗失可提交电子版补办申请， [1] 需在报销周期内完成提交。 补办流程由财务部门在 5 个工作日内 审核完成。[2] 逾期未补办将影响当期报销， [3] 具体以最新制度为准。 原文出处 [1] 报销制度v3.pdf · P12 · L230-268 [2] 财务SOP.md · §3.2 · char 1204-1310 [3] FAQ.html · 更新时间 2026-09-30 每条引用需记录：doc_id · 版本号 · 页码/段落 · char_start–char_end · 抓取时间 校验环节再确认一次：被引用的 span 是否真的支撑这句话（防止"引了但没支撑"） 可溯源 = 可复核 = 可追责，是企业级 RAG 的入场券
  • 生成时即要求句级标注，而非事后匹配
  • 引用要落到 span 级别（字符区间），不是只给文档名
  • 记录 版本与抓取时间，避免引用已失效的旧版
  • 再校验一次：引用片段是否真的支撑该句
引用同时是给用户的安全感，也是给排查的线索。

知识更新机制

索引保鲜Knowledge Update
T0 建库T1 新增T2 变更T3 升级 索引 v1 索引 v2 · 增量 新块 upsert 新文档 → 切分 → 嵌入 → 写入 索引 v2.1 · 失效 旧版本块 → 软删除 doc_id + version 定位 源文件变更 → 定位受影响块 索引 v3 · 重建 切分/模型升级 → 全量 增量 upsert · 版本化 + 软删除 · TTL 定时校验源变更 · 双索引蓝绿切换 · 大改动才全量重建
  • 增量 upsert：新文档走同一条切分→嵌入→写入流水线
  • 版本 + 软删除，杜绝"新旧混杂"的答案
  • TTL / 定时巡检：源变了就触发重建
  • 切分策略或 Embedding 模型升级 → 必须全量重建
  • 重建期间用双索引蓝绿切换，避免服务中断
知识库的对手不是"没数据"，而是"数据悄悄过期了"。