第 9 章 RAG 方法 · 答案可追溯¶
本章定位： 知识单元 · Delta 技术方法（对准实操三），把 LLM 四层级金字塔的第 2 层（RAG）讲透，并落地本书四条红线里的"答案可追溯"。坡度上：上一章的诉求分类器是"一次 LLM 调用"，本章的 RAG 是"检索 + 生成"——先找到相关政策片段，再基于片段作答并标注来源。
建议读者： Delta（施工主力必读，直接用于实操三）与 Echo（选型判断需双角色共识）均适用。
前置： 四层级金字塔（RAG 在分类之上、微调之下）；一次 LLM 调用 = 分类器。
本章学习目标：
- 说清 RAG 的核心思想（检索外部信息补足模型语料）；
- 画出 RAG 核心链路（解析→分块→向量化→向量库→检索→生成 + 来源引用），说出每步输入、输出与常见坑；
- 判断一个场景该用 RAG / 超长上下文 / 微调 / 纯关键词 / 提示词（对照"从最简单开始"）；
- 对文档解析、分块、Embedding、向量库、检索增强做选型与参数判读；
- 理解并会用"答案准确率 + 来源可追溯率"双指标验收 RAG 系统，并落地检索与生成分开评估、固定评估配置、外部给定库外问题；
- 完成 20–30 分钟最小 RAG 预实验，把链路每一步亲手走一遍。
9.1 RAG 是什么：检索外部资料补足模型语料¶
9.1.1 RAG 是什么：给大模型补上"它不知道的信息"¶
大语言模型的知识来自训练语料——训练时没见过的信息，模型就"不知道"：要么答不出，要么凭印象编。RAG（Retrieval-Augmented Generation，检索增强生成）的思路是：不改变模型本身，在回答前先从外部资料库检索相关信息，让模型"看着资料作答"。
RAG 与微调是解决同一类问题（模型语料不全）的两条互补路径。
| RAG（检索增强） | 微调（参数内化） | |
|---|---|---|
| 怎么补信息 | 回答时临时检索外部资料，拼进提示词 | 把信息"学进"模型参数，之后凭参数作答 |
| 适合 | 资料常更新、答案需溯源（政策 / 法规 / 手册） | 行为 / 风格要固化、资料相对稳定 |
| 更新方式 | 重建索引，不动模型 | 重新训练 / 微调 |
| 成本 | 低（无需训练） | 高（要数据 + 算力） |
flowchart TB
q["模型不知道的信息<br/>训练语料没覆盖 · 或已过时"]
rag["RAG · 开卷式<br/>回答时临时检索外部资料<br/>拼进提示词 · 答案带出处"]
ft["微调 · 背书式<br/>把信息学进模型参数<br/>之后凭参数作答"]
rag_ans["适用：资料常更新 · 需溯源<br/>更新 = 重建索引"]
ft_ans["适用：行为 / 风格要固化<br/>更新 = 重新训练"]
q --> rag
q --> ft
rag --> rag_ans
ft --> ft_ans
style rag fill:#dbe4f0,stroke:#3949ab
style ft fill:#f5ece0,stroke:#a8895f打个比方（帮助记忆，不是严格定义）： 可以想成"考试时翻开书找答案，而不是把书背进脑子"——开卷（RAG）适合资料总在变、要能指出依据的场景；背书（微调）适合要把能力"长在身上"的场景。两种方式没有优劣，只有适用场景不同。
9.1.2 三步工作原理与组件总览¶
RAG 的工作落成三个动作的流水线——检索（Retrieval）→ 增强（Augmentation）→ 生成（Generation）：
flowchart TB
q["用户提问"]
ret["1 检索 Retrieval<br/>从知识库找出最相关片段"]
aug["2 增强 Augmentation<br/>片段 + 问题 → 组装提示词"]
gen["3 生成 Generation<br/>LLM 基于片段作答 · 标注出处"]
ans["可溯源答案"]
q --> ret --> aug --> gen --> ans
style ret fill:#dbe4f0,stroke:#3949ab
style aug fill:#f5ece0,stroke:#a8895f
style gen fill:#e4efe4,stroke:#5b7a5b- 1 检索：把问题变成查询，去索引库找最相关的 K 个片段；
- 2 增强：把检索到的片段与原始问题拼成一段"带参考资料的提示词"；
- 3 生成：LLM 只基于片段作答并标注出处。
组件 → 后续各节： 一个完整 RAG 系统的四个组件阶段，正好对应本章后续各节的展开顺序——先看总览，后面每一节都是其中一块：
| 组件阶段 | 干什么 | 本章展开（各节主题） |
|---|---|---|
| 数据准备与索引（离线一次） | 解析 → 分块 → 向量化 → 存向量库 | 文档解析 · 分块策略 · 向量化 · 向量库 |
| 查询与检索（在线多次） | 问题向量化 → top-K 相似搜索 →（可选）混合检索 / 重排 / 改写 | 检索与召回增强 |
| 增强与生成 | 片段 + 问题组装提示词 → LLM 生成 + 来源引用 | 生成与来源引用 |
| 评估与监控 | 双指标验收、建索引三问、落地评估 | 评估与生产化 |
典型场景：企业知识库问答、智能客服、政策 / 法规问答（政务）、文献综述与代码生成——"某个场景该不该用 RAG、还是超长上下文 / 微调 / 纯关键词"，判断方法见下文选型边界。
9.1.3 RAG 解决的三个问题¶
RAG 同时解决三类问题：
| 问题 | 现象 | RAG 的解法 |
|---|---|---|
| 记忆漂移 | 政策一更新，模型凭旧记忆答错 | 答案来自最新索引库的数据，更新内容只需重建索引，不用重新训练 |
| 成本 | 每次把整本手册塞进上下文，token 贵且响应慢 | 只检索出与问题最相关的一小段放进提示词，成本与延迟可控 |
| 可追溯 | 答非所问或答错时，没人知道依据是什么 | 答案强制带出处（文号 + 条款号），可核对、可免责 |
Important
"答案可追溯"是政务 AI 的准入门槛。 市民问政策，AI 答错了，坐席和平台要负责。如果答案能做到"某政策 第X条"，市民可核对，坐席也能说"这是按文件规定来的"。来源引用不是锦上添花，而不是政务 AI 上线的硬门槛。
9.1.4 选型边界：这层工具该用哪一种¶
一个知识问答场景该用哪一层技术，对照四层级金字塔"从最简单开始"来选：
| 方案 | 核心机制 | 何时适用 | 政策问答为何这样选 |
|---|---|---|---|
| RAG | 检索相关片段 → 基于片段生成 + 引用 | 文档常更新、答案需溯源 | ✅ 政策常更新，RAG 只需重建索引；答案天生带引用 |
| 超长上下文 | 一次塞入全文，靠模型阅读 | 单份长文档、要全局理解且不需逐条溯源 | ❌ 每次带全文成本高、溯源弱、长文易失焦 |
| 微调 | 让模型"学会"固定领域知识 | 模型需内化领域风格、且具备标注数据与算力 | ❌ 政策一更新就要重训；答案仍无法溯源；易幻觉 |
| 纯关键词搜索 | 问句里的字面词去匹配文档 | 查编号、查专有名词这种精确匹配 | ❌ "外地户口能交社保吗"与"灵活就业人员参保条件"有语义鸿沟，字面匹配不上 |
| 提示词 / 一次调用 | 直接用模型现有能力 | 只是判断类别、简答、摘要 | ❌ 政策问答要输出"一段话 + 来源"，不是一句话分类 |
Tip
选型判读记一句话： 文档常更新 + 答案要溯源 → 用 RAG；固定领域 + 有数据算力 → 才考虑微调；精确词匹配 → 关键词；单纯分类 → 一次调用。先从最简单、最够用的那层起步。
9.2 RAG 核心链路：从文档到可溯源的答案¶
一条完整的 RAG 链路分为离线建库与在线问答两段。
- 离线建库（做一次）：解析文档 → 分块 → 向量化 → 存入向量库。政策更新时，只需对更新部分重跑这一段（重建索引）。
- 在线问答（做多次）：问题向量化 → 检索最相关片段 → 组装提示词 → 模型生成答案并标注来源。
flowchart TB
A1["政策文档"]
A2["1. 读取 / 解析<br/>（PDF / Word / 扫描件）"]
A3["2. 分块（chunk）"]
A4["3. 向量化（embedding）"]
A5["4. 存入向量库<br/>（向量 + 原文 + 来源）"]
DIV["—— 离线建库：做一次 ——"]
B1["用户提问"]
B2["5. 问题向量化"]
B3["6. 检索 top-K 最相关片段"]
B4["7. 生成答案 + 标注来源"]
A1 --> A2 --> A3 --> A4 --> A5 --> DIV
B1 --> B2 --> B3 --> B4
A5 -.-> B3
style DIV fill:#f5ece0,stroke:#a8895f链路每一步各有明确的输入、输出与常见坑，后面各节逐段展开。
| 步骤 | 输入 | 输出 | 一句话作用 | 常见坑 |
|---|---|---|---|---|
| 1. 解析 | 政策文档（PDF/Word/扫描件） | 可检索的纯文本 / 结构化内容 | 把"纸"变成文字 | 扫描件不出字、表格被切乱 |
| 2. 分块 | 长文本 | 若干语义片段（chunk） | 决定"一个答案对应哪几段" | 块太小截断信息、太大检索不准 |
| 3. 向量化 | 片段文字 | 片段向量 | 让语义相近的文字在数字空间"靠近" | 中文用错 embedding 模型，语义鸿沟大 |
| 4. 存库 | 片段向量 + 原文 + 来源 | 可检索向量库 | 同时存"向量 + 原文"，溯源靠原文 | 只存向量丢原文，来源就没了 |
| 5. 问题向量化 | 用户问题 | 问题向量 | 把问题放到与片段同维空间 | 分词/语义与库不一致 |
| 6. 检索 | 问题向量 | top-K 最相关片段 | 找出支撑答案的依据 | K 太小漏、K 太大噪 |
| 7. 生成 + 引用 | 系统提示 + 片段 + 问题 | 答案 + 出处 | 限定只用片段应答、并标来源 | 模型越出片段自由发挥 = 幻觉 |
Caution
全章纪律：检索不到不能编。 如果检索到的片段不足以支撑答案，模型应明确说"未检索到、无法回答"，而不是凭空编一段。这条纪律会写进实操三的 SPEC 与 DoD，并用外部给定的库外问题来验收。
9.3 文档解析：把"纸"变成可检索的文字¶
9.3.1 为什么要专门做解析¶
很多"文档"并非纯文本：PDF 有版式、有分段页眉页脚，Word 里有表格，纸质文件要 OCR（OCR, Optical Character Recognition，光学字符识别）转文字。直接硬切原文会得到"夹着版面噪声、表格错乱"的碎片，检索和问答都会受影响。所以 RAG 第一步是把各种格式归一到结构化、可检索的文字。
9.3.2 解析器选型¶
主流开源/托管解析器如下（版本以官方发布为准）：
| 解析器 | 定位 | 版本 / 许可 | 何时用 |
|---|---|---|---|
| Docling（IBM） | 开源文档转换库，统一转为结构化文档（含布局 / 表格 / 阅读顺序，可导出 Markdown / JSON） | 现行主线 · MIT 许可（以官方仓库为准） | 混合格式、含表格与复杂版式的常用首选 |
| LlamaParse（LlamaIndex） | 托管式解析云服务（PDF/PPT/扫描件），面向索引即用 | 闭源 API | 不想自建解析、接受托管时 |
| Unstructured | 开源 + 托管，按元素（标题/段落/表格）切分，与 LangChain 生态耦合深 | Apache-2.0 | 已在 LangChain 生态、要代码级控制分界时 |
| PyMuPDF | 轻量底层 PDF 文字提取，无版面理解，速度快 | 开源 + 商业双许可 | 纯文本 PDF、作兜底预处理 |
9.3.3 中文扫描件的注意点¶
纸质文件必须先 OCR。Docling 内置多套 OCR 引擎（如 Tesseract、EasyOCR），中文效果取决于所选引擎对中文的支持。落地前务必用自己那批扫描件实测，而不是只看宣传。混合格式场景常见做法：规范电子件用 Docling 直接解析，扫描件走 OCR 后再归一化。
Tip
解析判读： 西岭场景是"5 份混合格式政策文档"（md / pdf / docx，含杂乱格式），这正好考验解析与分块（对应实操三）。归纳起来：混合格式+表格复杂 → Docling；扫图居多 → 先 OCR 实测；纯文本 → 轻量打底。
9.4 分块：决定检索命中精度的粒度¶
9.4.1 分块要"自包含、不过大不过小"¶
分块（chunking）是把长文档切成语义完整的小段。切得好不好，直接影响"检索能否命中、命中后能否答全"：
- 块太小：关键信息被切断——检索到了，但片段不含完整答案；
- 块太大：一段里塞了太多无关内容——检索不精准，模型也容易跑偏。
9.4.2 固定长度分块的参数起点¶
最常用的基线方案是固定长度 + 重叠：
- chunk_size（块长）：常见起点 256–1024 token；中文场景实践经验常用 512–1024。
- overlap（重叠）：相邻块之间重叠 10%–20%，避免语义正好被切断在边界上。
这些是经验起点值，不是万能最优。最优值因语料与检索器而异，落地时用"建索引抽查"验证调参。
9.4.3 两条调整方向¶
拿到实测结果后再微调：
| 症状 | 判定 | 调整方向 |
|---|---|---|
| 检索命中但回答不完整 | 块太小，切断了完整答案 | 增大 chunk_size / overlap |
| 检索不精准、常带无关内容 | 块太大，噪声多 | 缩小 chunk_size |
9.4.4 进阶分块：语义分块 / 父子文档 / 上下文检索¶
当固定长度不够用时，可以按需升级（从简单到进阶）：
| 策略 | 解决什么问题 | 关键做法 |
|---|---|---|
| 语义分块 | 按主题/段落语义边界切，减少"一句话被拦腰斩断" | 依标题、主题、段落划分而非固定 token 数 |
| 父子文档 | 小片嵌入提高召回精度，命中后再取父级大块供模型读 | 小片用来检索，命中后回取其所属大块给模型 |
| 上下文检索（Contextual Retrieval） | chunk 脱离文档语境导致召回失败，先给它补一段"在文档中的位置/主题" | 嵌入前用一个小模型为每块补写上下文（有成本），Anthropic 官方基准显示检索失败率显著下降 |
说明： 上下文检索的数据由厂商官方发布于 2024-09，年限较早，具体数字落地前以其官方工程博客最新版本为准（https://www.anthropic.com/engineering）。
9.5 向量化（Embedding）：把文字变成可比较的向量¶
9.5.1 什么是 Embedding¶
Embedding（嵌入）把一段文字映射成一个高维数字向量，并保证语义相近的文字在向量空间里距离更近。有了它，"比较两段文字像不像"就变成"比较两个向量的相似度"（常用余弦相似度）。
这一机制正是解决"语义鸿沟"的关键："外地户口能交社保吗"与"灵活就业人员参保条件"字面上几乎不重合，但因为语义接近，向量距离很近，能被适配的 embedding 模型抓出来——而纯关键词搜索在这里就失效了。
9.5.2 中文 Embedding 选型¶
中文场景的两个主流选择：
| 维度 | BGE-M3（BAAI） | Qwen3-Embedding（阿里） |
|---|---|---|
| 向量维度 | 1024 维 | 0.6B → 1024 维；4B → 2560 维；8B → 4096 维 |
| 最大输入长度 | 8192 token | 32k token |
| 能力 | 同时输出稠密 + 稀疏 + 多向量三重表示，支持"同索引三路检索" | 支持 Matryoshka 维度压缩；4B/8B 支持稠密 + 稀疏双输出 |
| 部署 | MIT 许可，可本地自部署（满足"数据不出域"） | 开源权重，可本地或走托管 |
注意
以上为官方口径，Embedding 系列仍在迭代（官方博客显示含多模态新方向），落地前以各家官方仓库/博客最新版本为准。 托管选择： 不想自建的，走国内托管（如硅基流动 SiliconFlow 提供 BGE / Qwen3-Embedding / Reranker API）；具体单价随定价页实时变动，落地前查官方定价页。
9.5.3 选 embedding 模型的落地判读¶
- 要"数据不出域" → 选可本地部署的中文模型（如 BGE-M3，MIT 可自建），对应私有化部署的底座；
- 要语义靠近（问答、长文档）→ 选强语义的 embedding，而不是简单的词向量；
- 要精确词命中（编号、专名）→ embedding 只做语义召回，精确匹配交给 mixed retrieval 里的关键词通道。
9.6 向量库：存"向量 + 原文"，支持相似度检索¶
9.6.1 向量库要存三样东西¶
向量库不只是存"向量"。一次检索命中后，模型要读的是可读的原文片段，而不是一串数字；来源追溯也要回取原文。所以每个条目至少存：
- 向量：用于相似度检索；
- 原文片段：命中后给模型读、给答案做依据；
- 来源元数据：文号、条款号、页号、文档名——溯源全靠它。
Important
只存向量、丢原文，溯源就断了。 从三大问题看，向量解决"找得准"，原文与来源解决"答得可追溯"。二者缺一不可。
9.6.2 向量库选型¶
| 维度 | Chroma | Milvus | pgvector |
|---|---|---|---|
| 定位 | 嵌入式向量库，Python 原生，本地文件持久化 | 分布式、云原生独立向量数据库 | PostgreSQL 扩展 |
| 部署 | 进程内 / 轻量服务，开箱即用 | 单机 Docker 或集群（K8s） | 随 Postgres 部署（含云 RDS） |
| 适用规模 | PoC / 中小规模（万级–百万级内） | 生产、大规模（亿级向量为常见基准对象） | 百万级内、数据本就在 Postgres |
| 混合检索 | 以稠密为主 | 原生支持稠密 + 稀疏 + 混合检索 | 稠密向量 + SQL/全文可拼混合 |
| 何时用 | PoC 首选，上手成本最低 | 生产、规模上量后 | 不想引入新组件、数据已在 Postgres |
9.6.3 "从最简单开始"的取舍¶
PoC 与原型阶段用 Chroma 开箱即用即可；等数据规模、并发、混合检索要求上来，再迁 Milvus 或 pgvector。不要一上来就搭分布式。
9.7 检索与召回增强：从 top-K 到混合检索、重排、HyDE¶
9.7.1 基础：top-K 向量检索¶
在线问答时，把问题向量化后在向量库中取相似度最高的 top-K 个片段。K 的取值有两难的均衡：K 太小漏掉相关片段，K 太大混入噪声，需按场景权衡（通常从几到十几起步）。
9.7.2 三段递进增强¶
基础检索不理想时，按"先解决漏、再解决排序、再解决表达不对齐"的顺序逐段加，每一步都有明确触发条件与成本，不是默认全上：
flowchart TB
base["基础：纯向量检索（top-K）<br/>语义相似的基线"]
mix["→ 混合检索<br/>稠密向量 + 关键词（BM25·中文配 jieba）"]
rr["→ 重排（rerank）<br/>用 cross-encoder 精排 top-K"]
hyde["→ HyDE / 查询改写<br/>先造假设答案再检索 / 改写多角度查询"]
base --> mix --> rr --> hyde
style base fill:#e4efe4,stroke:#5b7a5b
style mix fill:#dbe4f0,stroke:#3949ab
style rr fill:#f5ece0,stroke:#a8895f
style hyde fill:#fdecea,stroke:#a34a3a| 阶段 | 解决什么问题 | 何时值得上 | 成本 / 注意 |
|---|---|---|---|
| 基础向量检索 | 语义相似召回 | 语料规整、查询与文档用词接近 | 基线方案，先做它 |
| 混合检索 | "召回漏"——dense 漏掉的精确词（编号、专名）由 BM25 兜住 | 语料含编号、产品名、中文专名时显著提升 | 融合常用 RRF；中文配 jieba 分词 BM25 |
| 重排（rerank） | "排序差"——向量粗召回后再精排 | 已做混合召回、对首屏精度敏感时 | 对 top-K 逐对推理，延迟/成本可控；中文可用 BGE Reranker / Qwen3-Reranker |
| HyDE / 查询改写 | "查询与文档措辞不对齐"——查询过短或口语化 | 检索为空或召回极差、查询是问句口语时 | HyDE 先生成"假设答案文档"再 embedding 检索；改写可多角度扩展子查询再融合 |
Tip
从最简单开始： 先用基础 top-K 验证；明确漏了精确词再加混合检索；首屏精度不够再加重排；查询表达确实对不上，才考虑 HyDE/改写。每一层都先确认"问题确实存在"，再决定是否加。
Caution
中文混合检索必须显式配置 jieba 分词——这是"能不能跑通"的硬细节。 BM25 是"按词统计词频"的关键词检索，对中文若不先加载 jieba 分词器（如在 bm25s/rank_bm25 构建索引前用 jieba.analyse 分词），一整句话会被当成一个"词"，导致精确词命中失效、混合检索退化为近似纯向量。落地时务必在建立关键词索引之前显式配置 jieba，并用带编号/专名的测试数据抽检命中效果。
9.8 生成 + 来源引用：把"答案可追溯"做成硬指标¶
9.8.1 提示词如何组装¶
检索到片段后，提示词由三部分拼成：系统提示限定"只用所给片段作答，不要凭记忆补充" + 检索到的片段 + 用户问题。这一步要让模型"只做转述与组织，不做自由发挥"。组装后的形态大致是：
【系统提示】你是政务政策问答助手。只能基于"参考资料"作答，不得凭记忆补充；
资料不足时回答"未检索到、无法回答"；回答末尾标注引用（文件名 + 文号 + 条款）。
【参考资料】
1. 片段 1（来自检索，按相关性排序，建议 3–8 段）
2. 片段 2
【用户问题】……
flowchart LR
sys["系统提示<br/>只用所给片段作答"]
ctx["检索到的相关片段"]
q["用户问题"]
out["模型输出<br/>答案 + 引用（文号 · 条款）"]
sys --> out
ctx --> out
q --> out
style out fill:#3949ab,color:#fff,stroke:#1a237e两条组装纪律：
- 只给检索片段，不给全文：把整本手册塞进去，等于退回"超长上下文"的教训（见本章选型表），成本高、模型易失焦；
- 片段按相关性排序、控制数量：top-K 的 K 就是片段数，政务问答建议 3–8 段；片段去重后按相关性从高到低排，模型优先引用靠前的。
常见坑： 片段塞得太满反而稀释关键信息；系统提示没写死"只用片段作答、不得凭记忆补充"，模型会回归"凭记忆编"——引用就不可信了。
9.8.2 引用格式与"检索不到不能编"¶
- 引用格式（规范写法）：答案要能对上"哪份文件、哪条"，标准写法是"依据《XX 办法》（文号）第 X 条"；多个来源并列时写成"依据《A》第 X 条、《B》第 Y 条"；片段没有文号 / 条款时，降级为"文件标题 + 段落位置"。这是"来源引用"落地的抓手，也是实操三 DoD 的检查点。
- 检索不到不能编（三条判据）：模型拿到的资料不足以支撑答案时，必须拒答而不是编：
- 检索为空 / 片段太少 → 回答"未检索到、无法回答"；
- 命中但不相关（片段答非所问） → 说明"未找到与问题直接相关的条款"，不硬答；
- 片段互相冲突 → 如实标注"不同条款存在差异"，交人工确认，不自行取舍。
引用是否站得住，最终看三类失败有没有被拦下：错引（条款张冠李戴）、漏引（关键论断没出处）、引而不符（出处对了但答案跨出条款本意）——这三类会在双指标验收中逐类核验。
Important
红线"答案可追溯"落此处： 这一节就是红线从"口号"到"硬指标"的桥。先有"检索到的片段 + 原文 + 来源元数据"，再有"只用片段作答 + 强制引用 + 检索不到不编"，最后才有可量化的双指标验收。
一个完整示例会话（示意内容，非真实政策文本）：
【用户提问】外地户口能在这交社保吗？
【检索到的片段】
片段 1：《XX 市社会保险办法》（X 政发〔2022〕12 号）第 18 条：外地户籍人员
在本市就业的，由用人单位为其办理社会保险登记，缴费比例与本市户籍一致。
片段 2：《XX 市灵活就业人员参保实施细则》第 3 条：非本市户籍灵活就业人员，
可凭居住证参加职工基本养老保险。
【组装后的提示词】
系统：你是政务政策问答助手。只能基于"参考资料"作答，不得凭记忆补充；
资料不足时回答"未检索到、无法回答"；回答末尾标注引用（文件名 + 文号 + 条款）。
参考资料：片段 1、片段 2（见上）
用户问题：外地户口能在这交社保吗？
【模型输出（正常作答）】
可以。按《XX 市社会保险办法》第 18 条，外地户籍人员在本市就业的，由用人
单位办理社保登记，缴费比例与本市户籍一致；未就业的灵活就业人员也可凭居住证
参保（依据：《XX 市社会保险办法》（X 政发〔2022〕12 号）第 18 条、
《XX 市灵活就业人员参保实施细则》第 3 条）。
【对照：资料不足时的输出（拒答）】
未检索到与"外地户口能否在这交社保"直接相关的条款，无法回答——建议咨询
市社保局服务热线或政务窗口核实。
9.8.3 更新即重建索引，而不是重新训练¶
政策更新时，RAG 只需对更新文档重跑离线建库（解析→分块→向量化→入库），模型本身不用重新训练。这是 RAG 相对微调在政务常更新场景下的核心优势——印证了选型判断。
9.9 评估与生产化：双指标验收¶
9.9.1 为什么 RAG 要专门评估¶
一条 RAG 答案要正确，其实要过三道关：检索得准（找对片段）、生成得对（转述正确）、引用得对（出处对应）。只看"最终答案像不像对的"不够——答案对但引用张冠李戴，审不了；答案错但引用全对，也没意义。因此要分维度评估。
9.9.2 RAGAS 指标：每个指标只回答自己的问题¶
RAGAS 是目前常用的开源 RAG 评估框架（版本以官方发布为准）。它按评价对象拆开评估，核心是：每个指标只能回答它自己的那个问题，不能互相替代：
| 评价对象 | 示例指标 | 不能替代什么 |
|---|---|---|
| 检索质量（召回 / 排序） | Context Precision、Context Recall、命中率 | 引用正确性（检索命中 ≠ 引用支撑结论） |
| 回答相关性 | Answer Relevancy | 事实正确性（切题 ≠ 答对） |
| 上下文忠实度 | Faithfulness | 外部事实正确性（忠实于上下文 ≠ 上下文本身正确） |
| 回答正确性 | 与参考答案或人工标准对照 | 引用是否支撑声明 |
| 引用质量 | 引用正确性、完整性、声明—证据对齐 | 检索排序质量（引用对了 ≠ 排序最好） |
反例（两类典型失败）： 1）"答案正确但引用错误"——结论答对了，引用的条款号却是张冠李戴，审不了；2）"引用正确但回答过度推断"——引用对了条款，答案却跨出了条款本意。这两类失败自动指标都抓不全，必须靠专门的人工 / 规则核验（固定评估配置 + 人工抽检）才能识别。
Note
与实操三双指标的关系："答案准确率 / 来源可追溯率"是本次实操的验收口径（由人工对照参考答案核验）；RAGAS 是技术指标（可自动化、按评价对象拆分）。两者是"业务口径 vs 技术指标"的关系，本书不声称双指标等价于 RAGAS 的某一指标。
9.9.3 本书的双指标验收口径¶
透视到政务交付，把上面的技术指标收敛成两个可量化的验收口径（也是实操三的 DoD）：
- 答案准确率：抽查答案，判断每一条结论是否正确、切题、没有幻觉；
- 来源可追溯率：抽查答案，判断每条关键论断是否都带了对的出处（文号 + 条款），且出处与答案内容能对上。
Caution
验收只看"答案对不对"、不看"引用准不准"，是政务 RAG 最常见的失效点。 双指标都必须过线，"答对但引错"同样不验收。
9.9.4 生产化要点：建索引三问¶
上线前用"建索引三问"系统性自查，把断点找出来：
- 解析：这份文档（含扫描/表格/混合格式）解析出来可读、结构未被切乱吗？
- 分块：chunk 自包含、粒度合适吗？回答不完整还是检索不精准？
- 检索索引：向量库所用的 embedding 维度与模型一致吗？top-K、过滤、来源元数据配好了吗？
这三问是教材框架，其内核（解析质量、分块粒度、检索 / 向量索引配置）与行业实践一致。逐问验证通过，再进入生产化（含模型选型、并发、成本）。
9.9.5 评估怎么落地：检索与生成分开评估 + 固定配置 + 库外问题¶
双指标是"最终口径"，但答案错了不等于生成错，更可能是检索没找对。落地评估要分三件事：
1. 检索与生成分开评估（先定位，再修）：
| 评估对象 | 看什么 | 对应"修哪里" |
|---|---|---|
| 检索侧 | 对每条验证题，相关片段是否真的出现在 top-K（命中率 / Recall@K） | 找不找得对 → 调分块 / embedding / 混合检索 / 重排 |
| 生成侧 | 给定"正确的片段"，答案是否忠实、切题、无幻觉 | 答得对不对 → 调提示词组装 / 模型 |
| 引用侧 | 每条关键论断是否带了对的出处，出处与内容能对上 | 引用准不准 → 调引用格式与强制规则 |
排错口诀："先问找没找对，再问答没答对，最后问引没引对"——检索空/错时去调检索，不要盲目改生成提示词。
2. 固定评估配置（结果可比的前提）： 用 LLM-as-judge 打分时，评估 prompt、模型、参数必须固定，否则"换了个模型分数就变了"，结果不可比、不可复现。建议：
- 固定 evaluator prompt（评估你评判的标准问题为模板，如："逐条判断答案是否仅由给定片段支持（是/否+原因）；标注每条关键论断的出处是否正确"）；评估用温度
0、固定模型名与版本； - 人工复核规则：LLM 打分只作初筛，抽检 ≥20% 由人工复核；LLM 与人工结论冲突时以人工为准并记录。
3. 库外问题（外部给定，验收含拒答）： 只测"库内问答"会漏掉最危险的幻觉场景。库外问题（知识库中不存在答案的问题）由讲师/评分脚本外部给定，验收口径为：模型应回答"未检索到、无法回答"，不得编造——库外拒答是"答案可追溯"红线的另一面。
9.10 最小 RAG 预实验：可选动手 20–30 分钟¶
目的不是搭一个完整系统，而是把核心链路亲手走一遍，建立"每一环节输入什么、输出什么、坏了什么表现"的手感。不引入向量库也可以做——用内存中的余弦相似度即可。
- 素材（自拟即可，不依赖实操三素材）：手写 3–5 段政策式片段（每段 100–200 字，各带文号 / 条款），另写 1 个库外问题。
- 步骤：
- 解析与分块：把每段按"条款"切成 4–8 个 chunk（就当"结构规整的文档"）；
- 向量化：任选一个 embedding（本地 BGE-M3 或托管 API，参照本章向量化选型）；
- 检索：对 2 个库内问题各取 top-1/top-2，对 1 个库外问题看检索结果；
- 组装与生成：按本章生成与引用一节的写法组装提示词，让模型"只用片段作答 + 标注文号条款"；
- 自评：用本章的三步定位法——先看检索命中没，再看生成忠不忠实，最后看引用对不对；库外问题必须拒答。
- 验收（你自己的 DoD）：库内 2 题都命中相关片段、答案有正确出处；库外 1 题模型拒答不编；你能说清"如果答案错了，是检索、生成还是引用的问题"。
提示
这一步全部使用自拟片段；实操三会改用真实政策文档 + 完整 gstack，把同一套链路做成可验收的系统。
反模式与红线¶
- 让模型凭记忆答题、不检索文档。 那不是 RAG，又回到"凭模型训练记忆硬答"，政策一更新就会答错。
- 答不给出来源。 政务 AI 若不能溯源（哪份文件、哪条），坐席无法免责——违反"答案可追溯"红线。
- 只塞全文、不做检索（退化为超长上下文）。 成本高、溯源弱、长文易失焦，是"超长上下文取代 RAG"的误判。
- 选错层：想直接上微调 / 用纯关键词。 政策常更新需溯源 → RAG；语义匹配 → 不能用纯关键词。
- 检索不到还硬编。 片段不足时应答"未检索到、无法回答"，绝不凭空造条文。
- 验证只看"答案对不对"、不看"引用准不准"。 验收要用双指标：答案准确率 + 来源可追溯率。
- 只评生成、不评检索。 答案错了先分侧定位——"先问找没找对，再问答没答对"。
- 评估配置不固定。 换模型 / 换 evaluator prompt 分数就变，结果不可比、不可复现（对治：固定评估配置）。
- 不测库外问题。 只测库内问答会漏掉最危险的幻觉场景——库外必须拒答。
Caution
红线本处落地：答案可追溯。 本章为知识章，但"答案必须带来源引用、检索不到不能编、双指标验收、库外拒答"这套口径，会在实操三的 SPEC 与 DoD 里强制写死，并呼应导读页四条红线。
本章小结¶
- RAG 是什么：检索外部资料补足模型语料——先检索相关片段，再基于片段作答并标注出处；与微调是两条互补路径、各有所长；同时解决记忆漂移、成本、可追溯三问题。
- 选型边界：政策问答用 RAG 而不用超长上下文 / 微调 / 纯关键词（关键判断："超长上下文解决'能读多少'，RAG 解决'读哪几段、答得有依据'"）。
- 核心链路：解析 → 分块 → 向量化 → 向量库 → 检索 → 生成 + 来源引用（离线建库一次、在线问答多次）。
- 选型：常更新需溯源 → RAG；固定领域有数据 → 微调；精确词 → 关键词；单纯分类 → 一次调用；先最简单。
- 关键参数：分块起点 512–1024 token + 10–20% 重叠；top-K 太少漏、太多噪；检索增强按"漏→序→表达"逐段加、不全上。
- 政务命门：答案可追溯是政务 AI 准入门槛，验收用"答案准确率 + 来源可追溯率"双指标，检索不到不能编。
- 评估落地：检索 / 生成 / 引用分开定位；evaluator prompt、模型、参数固定并配人工抽检；库外问题外部给定、必须拒答。
- 最小预实验：20–30 分钟把链路亲手走一遍，不依赖实操三的素材。
动手自检：
- 我能说清 RAG 的核心思想（检索外部资料补足模型语料），并给一个外行讲明白吗？
- 我能画出 RAG 核心链路并说出每步输入/输出/常见坑吗？
- 我能说清"为什么政策问答用 RAG，不用超长上下文 / 微调 / 纯关键词"吗？
- 我能解释分块参数两个方向的调整（回答不完整→增大；检索不精准→缩小）吗？
- 我能说清"为什么验收必须有来源可追溯率这一个指标"吗？
- 我能用"先找没找对、再答没答对、后引没引对"给一条错答案排错吗？
- 我能说清评估配置为什么要固定、库外问题为什么要测吗？
练习与思考¶
- 基础： 默写 RAG 核心链路（离线/在线两段）；列出分块与检索的四个常见坑；默写三步定位法。
- 进阶： 给定"外地户口能在西岭交社保吗"，说明一次 RAG 问答里分块→检索→组装→生成+引用分别做了什么，并指出纯关键词为何失败、重排在这里是否必要；再用最小预实验走一遍并写 3 行自评。
- 挑战（迁移练习）： 为一份每季度更新的业务手册设计 RAG 方案：说明"更新时只需重建索引、不用改模型"如何落地，并预设两处数据漂移 / 解析失效风险与排查方法（可套用建索引三问）；再为它设计"检索 / 生成 / 引用分开评估 + 库外拒答"的验收方案（固定 evaluator prompt 与人工抽检比例）。
延伸阅读¶
- 见 FDE-101 https://www.cloudzun.com/fde-course/（第 16 章 AI FDE 落地：Delta 技术与场景）——RAG 检索与向量库的落地选型深读。
- 见 FDE-101 https://www.cloudzun.com/fde-course/（第 15 章 AI FDE 落地：Echo 共识与对齐）——AI 能力如何与 FDE 判断力对齐的扩展。
- 下一章： 实操三 · 政策法规 RAG 问答系统（把本章当场做出来，练"答案可追溯"双指标）。