基于《大规模语言模型：从理论到实践（第2版）》第9章 检索增强生成
爆款小标题：检索不准、生成不贴原文？原书 RAG 优化与评估一节打通
为什么这一节重要
搭好 RAG 基础链路后，常见问题是：检索到的文档与问题不够相关、或生成答案没有紧扣检索内容。原书第 9 章系统总结了查询侧（改写、分解、多查询）、检索侧（混合检索、重排序、HyDE）等优化策略，以及检索层与生成层的评估维度与指标。本节把这些策略与评估方法讲清，并给出「先建评估集再迭代」的工程习惯，避免只凭感觉调参或上线后才发现问题。
学习目标
- 掌握优化策略：能说明查询改写、查询分解、多查询检索、混合检索、重排序、HyDE 等各自的目的与原理（原书第 9 章）。
- 掌握评估维度与指标：区分检索层（召回率、准确率、MRR）与生成层（与参考答案的匹配、事实一致性）、以及端到端（人工或模型打分）的用法。
- 能设计最小评估方案：根据业务设计包含「标准问+标准答」的评估集，并选定检索与生成指标及「可上线」的阈值或流程。
一、查询侧优化（原书第 9 章）
查询改写：用户输入可能含糊、简写或带错别字（如「llm 是啥」「BERT 和 GPT 区别」）；先用小模型或规则把查询改写成更完整、更利于检索的形式（如补全主语、纠错、扩展同义词、补充领域语境），再拿改写后的 query 做检索，可提升召回与鲁棒性。改写可在检索前单独调用一次轻量模型，成本可控。
查询分解：若问题包含多个子问题（如「A 和 B 的区别是什么？各自优缺点？」），单次检索可能只覆盖部分子问题。可先用模型将用户问题分解成 2–3 个子查询，分别检索后合并结果（去重、排序）或分步生成（先答子问题再综合），避免遗漏。原书第 9 章对查询分解有讨论。
多查询检索：对同一用户问题生成多个不同表述的 query（如用模型生成 2–3 个变体，或用同义词扩展），分别检索后取并集或做 RRF 融合，再重排序或直接送入生成。可提升覆盖不同表述方式的相关文档的概率，尤其当文档表述与用户问法差异较大时。
二、检索侧优化（原书第 9 章）
混合检索：单一向量检索有时会漏掉「关键词精确匹配」更合适的文档（如专有名词、产品编号、法规条文）。将向量检索与关键词检索（如 BM25）结合，对两路结果做融合——常用 RRF（Reciprocal Rank Fusion）：按在两路排序中的名次计算得分并合并，再取 Top-K——可兼顾语义与字面匹配。原书第 9 章对混合检索有讨论。
重排序（Reranker）：首轮检索用轻量嵌入做粗排，返回的 Top-K（如 20）中可能仍有无关文档。用 Cross-Encoder（对 query–document 对做联合编码并打分）对 Top-K 做精排，只保留 Top-N（如 5）送入生成，可显著提升「送入 prompt 的内容」的相关性。代价是增加一次模型调用与延迟；可根据业务设定 K 与 N（如先检索 20 条、重排后取 5 条），并监控 P99 延迟。
HyDE：先用生成模型根据用户问题「假设」一段可能的相关文档，向量化后去检索真实文档。思路是「假设文档」与真实相关文档在语义上更接近，能提升召回。实现时需控制生成长度与成本，避免假设文档过长或偏离主题。HyDE 适合「用户问题较抽象、与文档表述差异大」的场景；若用户问题已足够具体、文档表述接近，HyDE 的额外模型调用可能得不偿失，需结合 A/B 测试决策是否启用。
检索结果融合（RRF）的细节：当混合检索或多查询检索得到多路结果时，RRF 公式为 (\text{score}(d) = \sum_{r} 1/(k+r))，其中 (r) 为文档 (d) 在某一路排序中的名次，(k) 为常数（常用 60）。多路结果按此公式汇总后重排，取 Top-K。RRF 的优点是无需各路的绝对分数可比、实现简单；缺点是对名次敏感、对「某路完全没召回到」的文档无法补救。
三、评估维度与指标（原书第 9 章评估部分）
检索层：衡量「查到的文档是否相关」。常用指标包括：召回率（Recall@K：标准相关文档中有多少出现在 Top-K）、准确率（Precision@K：Top-K 中有多少是相关）、MRR（Mean Reciprocal Rank：第一个相关文档排名的倒数）。可基于「标准问 + 标注相关文档 id」构造评估集。
生成层：衡量「答案是否依据检索、是否与参考答案一致」。可用：与参考答案的匹配度（如 BLEU、ROUGE、BERTScore）、事实一致性（生成内容是否与检索片段矛盾）、或引用正确性（是否引用了正确片段）。需要「标准问 + 标准答 + 可选的相关文档 id」。
端到端：人工或模型对「最终答案」做整体打分（相关性、完整性、是否有幻觉等），用于上线前或迭代中的整体质量把控。原书第 9 章对上述维度有进一步说明。
如何构造最小评估集：建议从业务中抽取 20–50 条「标准问」，并为每条标注：至少一个标准答（用于生成层匹配）、以及「相关文档 id 列表」（用于检索层召回评估）。标注时注意覆盖：高频问法、边界问法、多跳问题、以及「应回答不知道」的 case。评估集应版本化，与数据管线一起管理，避免「改完检索或模型后无处可回归」的情况。
四、案例：RAG 评估方案的具体实现步骤
以下给出「最小可上线 RAG 评估」的 5 步落地流程。
步骤 1：构造评估数据
- 格式：每条为
{query, expected_answer, relevant_doc_ids}。 query：标准问法，从业务日志或产品经理提供的 FAQ 中抽取 20–50 条。expected_answer：标准答，人工撰写或从高赞回复中筛选，用于生成层匹配。relevant_doc_ids：与 query 相关的 chunk id 列表，用于检索层 Recall 计算；可由人工标注或规则（如包含关键词的 chunk）生成。
步骤 2：检索层评估
- 对每条 query 执行检索，得到 Top-K（如 K=5）的 doc id 列表。
- 计算 Recall@K = |Top-K ∩ relevant_doc_ids| / |relevant_doc_ids|；若 relevant 为空则跳过。
- 汇总：对所有样本求平均 Recall@5；可同时算 Precision@5、MRR。
- 可上线阈值建议：Recall@5 ≥ 0.7 或 0.8，视业务而定。
步骤 3：生成层评估
- 用检索到的 Top-K 拼 prompt，调用 LLM 生成答案。
- 自动指标：用 BLEU 或 ROUGE 计算生成答案与 expected_answer 的匹配度；或用 BERTScore 做语义相似度。
- 事实一致性：检查生成内容是否与检索片段矛盾（可用 NLI 模型或规则关键词）。
步骤 4：人工抽检
- 对 10–20 条样本做人工打分：相关性（1–5 分）、完整性、是否有幻觉、格式是否正确。
- 记录「通过率」：得分 ≥ 4 的比例；可上线阈值如通过率 ≥ 80%。
步骤 5：自动化与回归
- 将上述流程写成脚本（Python），输入评估 JSON、输出指标报告。
- 每次改切块、检索或 prompt 后自动跑一遍，对比基线指标，避免回归。
五、工程实战要点
1. 先建评估集再迭代
先建 10–50 条标准问+标准答（及可选的相关文档标注），再迭代切块、检索策略、重排序与 prompt；每次改完都跑一遍评估集，避免凭感觉调参。评估集应包含「检索层」与「生成层」两类标注：检索层用「标准问 + 相关文档 id」算 Recall@K、Precision@K；生成层用「标准问 + 标准答」算 BLEU/ROUGE 或人工打分。两端指标需分开看，便于定位问题在检索还是生成。
2. 重排序与延迟的权衡
重排序能明显提升送入生成的内容质量，但会增加延迟；可根据业务设定 K 与 N（如先检索 20 条、重排后取 5 条），并监控 P99 延迟。若延迟敏感，可考虑：使用轻量 Cross-Encoder、或只在「首轮检索结果质量存疑」时触发重排序、或对高价值请求启用重排序而普通请求跳过。
3. 查询改写的成本与收益
查询改写需额外一次模型调用，会增加延迟与成本。建议先在「无改写」基线上建立评估，再 A/B 测试加入改写后的 Recall 与端到端效果提升；若提升有限，可对改写做条件触发（如仅当查询过短、或检测到错别字时改写），以控制成本。
六、常见误区与避坑指南
- 只优化检索或只优化生成：检索差时生成难以补救；生成不引用检索时检索再好也无效。避坑：两端都要看指标，检索用 Recall/Precision，生成用依据性与一致性。
- 没有评估就上线：避坑：至少做小规模人工或规则评估，设定「可上线」的底线（如 Recall@5 或人工通过率），再发布。
七、小结与衔接
本节基于原书第 9 章梳理了 RAG 的查询侧与检索侧优化策略，以及检索层、生成层与端到端的评估维度与常用指标；并强调了先建评估集再迭代、重排序与延迟的权衡。下一节将专门讲向量检索与嵌入模型选型（原书第 9 章延伸）：嵌入模型的作用、精确与近似检索的取舍、以及如何根据规模与成本选型（4.3 节）。
课后思考题
- 列举三种「提升 RAG 检索相关性」的策略，并各用一句话说明原理。
- 设计一个最简单的 RAG 评估方案：需要哪些数据、算哪些指标、如何判断「可以上线」？
