认知与设计

RAG 怎么搭才不翻车

检索增强生成（RAG）把外部知识库接给大模型，用来压住幻觉、给出可溯源的答案。但它在工程里是一条多段链路。索引、检索、生成任何一段没处理好都会答非所问。本篇从链路结构、失败点、分块、检索算法、检索前中后优化，到评估与治理，给出一套能落地的完整判断。

原生 / 增强 RAG
七类翻车点
分块策略
向量检索算法
检索前中后优化
四指标评测
选型边界
知识库治理
真实案例归因

做个靠谱的产品经理

概念界定：原生 RAG 与增强 RAG

先分清两种形态，后面所有优化都是「增强」在做的事

原生 RAG（Naive RAG）是最朴素的链路：用户提问 → 向量检索出相关片段 → 拼进提示交给大模型生成。它快、好理解，但把「检索质量」「问题理解」「上下文整合」全交给最基础的向量相似度，翻车率很高。
增强 RAG（Advanced RAG）重点仍聚焦检索阶段，但在「检索」之外增加了检索前（Pre-Retrieval）与检索后（Post-Retrieval）两段处理：检索前优化索引结构与查询方式，检索后做重排与上下文压缩。这里讨论的痛点与解法，几乎都落在这两段里。

图 1 · RAG 全链路：索引侧 + 查询侧（橙色为增强 RAG 新增环节）

一句话区分：原生「检索到了就直接用」，增强「检索前先理顺、检索后再提纯」。生产环境几乎都该用增强形态。后文所有招数都挂在橙色环节上。

检索链路为何翻车：七类失败点

翻车的根因分两层。外层靠治理，内层靠检索与生成调优

一篇被广泛引用的工程经验报告（Barnett 等，2024，arXiv:2401.05856）把 RAG 系统的失败点归纳为七类，并按「索引构建过程」与「检索增强过程」两段归位。把它们按根因再归一次类，会发现一个关键结论：一部分翻车是知识库本身的问题（外在），RAG 检索再强也救不了；另一部分是链路处理的问题（内在），可以靠增强手段解决。这正好呼应「答案在输入里才治得了幻觉」的判断。

图 2 · 失败点在链路上的分布：索引构建过程 vs 检索增强过程

判断第一问永远是：答案到底在不在召回回来的上下文里？不在 → 外在（治理）；在但答错 → 内在（链路调优）。

表 1 · 七类失败点与对应解法

失败点	所在段	典型表现	解法方向
内容缺失	知识库治理（前）	答案压根不在库里，模型给看似合理实则错的答案	补录知识库、数据清洗、提示「找不到答案就明说」
错过排名靠前的文档	检索 / 重排	召回 top5，但正确答案在第 6 条	加大 topK（注意 token 与干扰代价）、重排 rerank
不在上下文	上下文拼接	召回后拼进上下文的内容与答案无关	更精准检索、上下文压缩、关键句强调
未提取到答案	生成	上下文有答案，模型没提取出来	更强模型、提示「必须基于上下文回答」
格式错误	生成	要 JSON 给了字符串	提示调优、格式校验（如输出解析器）、自动修复
具体度不当	生成	答案太具体或太笼统	提示改善、提升基座模型能力
答案不完整	生成	只回答了问题的一部分	问题拆成子问题，并行 / 串行求解后汇总

分块策略：决定召回上限的第一步

切分的大小和位置，直接影响检索出的上下文完整性与 token 成本

「分块质量几乎决定了 RAG 系统的性能上限。」即使换上高性能大模型和精心设计的提示词，分块不当仍会导致上下文缺失、事实性错误、拼接不连贯与幻觉。

为什么必须分块？一是模型上下文窗口有限；二是控制检索信噪比。块过大引入噪声、稀释关键信息，块过小缺乏上下文、难以理解语义；三是靠重叠窗口（overlap）缓解边界断裂，避免定义、条件等关键内容被拆散。理想状态是在「上下文完整性」与「信息密度」之间取得动态平衡。这也是检索块与生成块可以分开设计的原因。

表 2 · 分块策略分类、参数与适用

策略	做法与关键参数	适用场景	注意
固定长度	按字符数硬切；中文 chunk_size 300–800 字，overlap 10%–20%	结构弱的纯文本、基线方案	极易破坏语义边界
句子 / 递归	先句后段；递归按「标题→段落→换行→空格→字符」粗到细分隔符链切	说明文档、知识库条目、综合语料	中文分句别用 NLTK（不支持中文标点），用 HanLP / Stanza / 正则
结构感知	以标题层级为父聚合内容，超长章节二次细分；注入父级路径（如「指南＞安装」）	技术文档、手册、白皮书	过短块在同父标题下合并
对话式	以「说话人＋轮次」为单位，按话题窗口聚合；用轮次重叠而非字符重叠	客服对话、会议纪要	召回后做「邻接扩展」（拼接前后轮次）
语义 / 主题	句向量相似度骤降处切分；或句向量聚类按主题切换点切	论文、白皮书、长篇报告	计算开销大，短文档效果有限
小-大 / 父子	小块高精度召回，命中后回溯父大块给完整上下文	需句级证据 + 段落解释的问答	维护父子映射，易于去重与回链
代理式	用小模型动态判断边界：不在代码/表格中间切、保持标题链完整	高度复杂的混合格式长文档	需规则护栏 + 自动回退，控制成本
混合分块	先粗切结构、再按需细化；同时建「小块索引 + 大块存储」	大多数生产环境（推荐）	原子块（代码/表格）保持完整

重叠窗口是维持上下文连续的关键，但不宜过大（通常 ≤20%）；元数据（标题路径、块类型、位置）同样重要，可显著提升检索与重排效果。

图 3 · 块大小权衡：两条反向曲线的交点附近为最优块长区间

表 3 · 分块场景推荐（tokens）

场景	建议区间
通用问答	128–512，最常见的平衡区间
技术文档 / 论文	200–300，保术语与逻辑结构
长叙事（小说）	500–1000，保情节连贯
社媒 / 短文本	100–200，适配碎片检索
复杂任务	1024，响应时间与质量的平衡点

表 4 · 质量-成本档位

档位	策略	适用
Fast	结构→递归	快速上线
Balanced	+ 异常块语义分块 + 小-大检索	多数生产
Quality	+ 代理式精修 + 强 rerank	高精度

调优方法论：固定检索与重排，只动分块参数，用 Recall@k、nDCG、忠实度评估。

表 5 · 实测案例：同一套企业级 RAG，三种块大小对比

案例背景：一套企业级问答 RAG 应用，用评估框架和评估数据集实测三种 chunk_size。除块大小外其余条件全部固定。LangChain 递归字符分块（默认分隔符，overlap 为 chunk_size 的 20%）、生成模型 qwen-max-latest、向量模型 text-embedding-v3、向量库 FAISS、纯向量检索（未加任何 Advanced RAG 增强）、top_k=10。三个指标各管一段链路：事实准确性看答案是否忠于召回的上下文（生成层），上下文精度看相关块是否排在召回结果前列（检索层），答案相关性看回答是否切题（生成层）。

chunk_size	分块数	事实准确性	上下文精度	答案相关性	结论
128	1546	最高	中	0.90+	事实最准，token 消耗约为 256 的一半。成本敏感场景的最优
256	821	中高	中高	0.90+	综合最优，优先选用
512	462	中	最低	0.90+	低精准度拉低整条链路，性价比极低

三种块大小的整体表现都在中高区间，拉开差距的是「事实准确性 × 上下文精度」的组合。条件不同结论会变。所以可迁移的不是「记住 256」，而是「用评估框架在真实数据上跑」这套动作。

向量检索算法：从暴力搜索到 IVF 与 HNSW

检索阶段的底层引擎。选型直接影响速度、召回率与知识库能否增量更新

「与其追求 100% 精确的最近邻（KNN），不如在毫秒内找到 99% 相似的近似最近邻（ANN）。对大多数应用，速度上的提升远比微小的精度损失更有价值。」

图 4 · 两大 ANN 主流算法：IVF 先分区再精搜，HNSW 分层导航

IVF：K-Means 把全库聚成 nlist 个簇并记录质心，查询只与质心比距离、在最近 nprobe 个簇内暴力搜。快，但答案可能落在没搜的簇里。HNSW：借鉴小世界网络与跳表，从顶层入口贪婪逼近，逐层下探到底层精细搜索。召回率通常更高，且支持增量添加数据。

表 6 · HNSW 三大核心超参数

参数	作用	调大的代价与收益	类比
M（最大连接数）	控制每个节点的邻居数量（出度）	图更稠密、召回率更高；内存与构建时间显著增加	每条街道的交叉口数量
efConstruction	建索引时为每个新节点找邻居的候选队列大小	图质量更高、利于最终精度；索引构建大幅变慢	修路时考察更多备选路线
efSearch	查询时候选队列大小。最重要的查询时参数	探索更广、召回率显著提高；查询延迟增加	导航时同时考虑更多备选路径

表 7 · IVF vs HNSW 全方位对比

特性	IVF（倒排文件索引）	HNSW（分层导航小世界）
搜索类型	基于聚类的搜索	基于图的搜索
搜索速度	快	非常快，超大规模下尤甚
构建速度	相对较快	计算量大，相对耗时
内存占用	较低，适合与量化结合、处理载不进内存的超大规模数据	需将向量全量载入内存，开销巨大
召回率	靠 nprobe 参数在召回与速度间权衡	通常能达到非常高的召回率
动态数据	对新增数据不友好，通常需定期重建索引	支持增量添加，无需全量重建
适用场景	静态、超大规模、内存有限	高召回实时应用，数据可全量载入内存

产品侧最该记住的是「动态数据」这一行：规则 / 政策类知识库天天在更新。选 IVF 就意味着每次更新可能要重建索引、服务中断；选 HNSW 才有「改一条录一条」的增量能力。这就是知识库治理里「增量更新」的底层依据。

检索前、中、后优化手段

增强 RAG 把优化拆成三段。先看全景骨架，再逐招拆开：基本思路、是否用 LLM、流程图、适用场景与实例

图 5 · 三段优化全景：每段的招数清单

检索前提高「被索引内容的质量」并理顺查询意图；检索阶段决定「找什么、怎么合」；检索后解决「给模型的上下文纯不纯」。

检索前 · 索引优化四招（逐招拆解）

图 6 · 摘要索引：用摘要当「替身」检索，命中后回溯原文

LLM 参与：建库时逐块生成摘要查询时不额外调用 LLM

解决什么：半结构化文档（文本＋表格混排）直接切分会切碎表格，整张表做向量检索又难以匹配。基本思路三步：①建库时让 LLM 为每个块生成摘要，向量化存入摘要库；②查询时先在摘要库里命中最相关的摘要；③回溯到摘要对应的原始块，把原始块（而不是摘要）送入模型作答。

适用：需要快速定位、上下文要求简洁的场景。新闻资讯平台从海量新闻中快速提取关键信息。两个注意：摘要必须包含高价值表格的关键信息，过简会丢信息；每个块一次 LLM 调用，要按数据价值权衡成本。

图 7 · 父子索引：子块负责检得准，父块负责答得全

LLM 参与：不需要（纯索引结构策略）

基本思路三步：①文档切成层级化块结构，只用最小的叶子块建向量索引；②检索时召回 top-k 个叶子块。块小，向量语义准，匹配得准；③若多个叶子块指向同一个父块，用父块替换这些子块送入模型。块大，上下文全，答得全。

适用：文档有清晰层次、查询针对具体细节、需要保上下文完整。技术文档（API 文档）、书籍、代码库检索；法律检索按条款命中后召回完整条文，避免分块过细丢前提。

父子索引为什么存在：一对天然矛盾

「检索需要细粒度：越细越容易匹配问题里的关键词；生成需要粗粒度：模型需要完整上下文才能正确理解。传统 RAG 无法兼顾二者，陷入精度 vs 完整性的两难。」

一个典型翻车：合同里写「违约要赔偿 30%」，前提是「非不可抗力情形下」。如果前提那一条没被一起召回，AI 给出的答案就是错的。父子索引让「检得准」与「答得全」同时成立。

图 8 · 假设性问题索引：用「问题」检索「问题」，同语义空间更好匹配

LLM 参与：建库时为每块预生成 n 个问题查询时不额外调用 LLM

基本思路三步：①建库时让 LLM 为每个块生成 n 个假设性问题（这些问题和块内容强相关），向量化存入问题向量库；②查询时拿用户问题向量检索「问题向量库」。用问题搜问题（query-to-query），替换掉常规的「问题搜文档」；③命中后回溯到原始文本块送入模型作答。

优点：用户问题与预生成问题同属一个语义空间，比「问题对文档」更容易匹配；用户措辞与原文差异大也能召回。局限：依赖 LLM 生成问题的质量，专业领域可能需微调或人工校验。适用：FAQ、产品手册、教育客服等问法高度重复可预测的场景。药品咨询里为每种药品预生成「感冒了吃什么药」一类问题。

图 9 · 元数据索引：先按标签过滤收窄范围，再向量检索定位

LLM 参与：可选（文档没标签时可让 LLM 推理补出）查询时过滤为结构化操作

解决什么：几百个来源与类型的大文档集，只靠「切块＋top-k 相似检索」会精度不足、知识互相干扰。基本思路三步：①定义标签体系（topic / author / year 等，文档自带就用，没有可让 LLM 建库时推理补出）；②查询时先按标签过滤；③在过滤后的子集里做向量检索定位 Top-K。LangChain 中用自查询检索器（SelfQueryRetriever）实现。

适用：多源异构、需分层筛选的大文档集。电商推荐按用户偏好标签先筛商品知识。规则 / 政策类场景尤其关键：活动、品类、版本多轴并存，只靠相似度分不出「哪条适用」，必须先按维度过滤。

检索前 · 查询优化三招（逐招拆解）

图 10 · 完善问题（Enrich）：模型主动追问，把模糊问题问清楚

LLM 参与：查询时，多轮对话补全

解决什么：口语表达过于简略或含糊，容易引发语义歧义；问题里隐含要素多、表达出的信息却不足。基本思路：让模型主动与用户多轮沟通，不断收集信息、完善对真实意图的理解，补全执行所需的各项参数，得到一个完善后的查询再送检索。

适用：C 端自然语言对话入口。表达简略、语义歧义、信息不足三类问题都靠它兜底；代价是多一轮交互，适合异步场景或对话式产品。

图 11 · 多路召回（Multi-Query）：一问变多问，覆盖不同视角

LLM 参与：查询时，生成 N 个相关问题

解决什么：单一查询措辞有限，覆盖不全。用户措辞与文档表述稍有差异就漏召。基本思路三步：①用 LLM 基于原始问题生成 N 个不同视角的相关问题；②N 个新问题连同原始问题一起送检索，各自召回一批文档；③所有结果汇总去重后交给模型，生成更完整的答案。

适用：通用问答里单条查询覆盖不全的场景。视角怎么定不是拍脑袋。让 LLM 从「政策 / 费用 / 时效」等维度改写；多路检索的代价是调用量翻 N 倍，配合后面的 RRF 融合排序使用效果最好。

图 12 · 问题分解（Decomposition）：复合问题拆成子问题，分而治之

LLM 参与：查询时，CoT 提示拆解

解决什么：复杂问题需要多步推理才能回答，模型一步到位容易漏。基本思路：用思维链（CoT）提示把问题拆成小问题，再选一种执行策略。并行：每个子问题各自检索作答，最后把所有子答案汇总成最终答案；串行：依次执行，把前一问的答案并入后一问的提示，逐步逼近。

适用：对比类、多跳类复合问题。「A 和 B 哪个更满足条件 X」拆成分别查 A、查 B、查 X 的定义；串行适合「先查资质，再按资质查适用政策」这类有依赖关系的问题。

检索 · 混合检索

图 13 · 混合检索标准流程：两路并行 → 标准化评分 → 加权融合

「标准化评分 → 加权融合 → 排序」这三步正是「无脑拼接」会跳过的部分。没有归一，两路分数根本不可比。

表 8 · 三种检索方式对比

方式	擅长	短板	角色
向量检索	捕捉语义相似	受向量空间表示能力限制，易漏「关键词匹配、表述不同」的核心信息	理解意图
关键词 / BM25	精确术语匹配、召回率高	对自然语言表达不友好，易召回「词频相似、语义无关」的块	抓准专有词
混合检索	取长补短、动态适配	需调权重，绝不能无脑拼接	生产默认

表 9 · 实测对照：同一应用四种检索方案（汽车手册问答）

案例背景：一套汽车手册问答 RAG 应用作固定底座，在同一评估数据集上每次只替换 / 叠加一个检索组件，其余条件不变。指标沿用 RAGAS 体系：忠实度（答案是否忠于上下文）、上下文精准度（相关块是否排得靠前）、上下文召回率（关键信息是否被覆盖）。括号内为相对第一行纯向量基线的百分点变化。

方案	忠实度	上下文精准度	上下文召回率	结论
原始：纯向量（256 块）	0.7619	0.8514	0.8750	忠实度是最大短板
＋上下文压缩检索器	0.8615（+9.96%）	0.9028（+5.14%）	0.8194（−5.56%）	以小幅召回损失换核心指标双升，综合 F1 几乎不变（0.8630→0.8591）
＋混合检索（无脑拼接）	0.8474（+8.55%）	0.4257（近乎减半）	0.8750（持平）	几乎不可用。两路分数没归一就合并
混合＋调权重＋重排	从「最差方案」变「最优方案」，指标提升的同时成本还下降			重排是保留优势、剔除缺陷的必备操作

这组数据把两条工程铁律钉死了：①混合检索绝不简单拼接结果；②所有指标的最终落脚点都是「检索到的上下文质量」。优化围绕完整度＋纯净度展开。

检索后 · 三件套（逐招拆解）

图 14 · 重排（Rerank）：用更专业的排序模型，把最相关的顶到最前

模型参与：交叉编码器（专用排序模型，非生成式 LLM）

解决什么：检索器（向量 / BM25）为了快，排序都比较粗。最相关的文档不一定排最前，而模型对上下文开头的内容最敏感。基本思路：用更专业的排序模型对候选重新打分。交叉编码器把「查询＋文档」成对送入逐条打分，比向量检索的「各自编码再算距离」准得多。把最相关、最合规的结果顶到上下文最前端。

生产必备。表 9 的实测里，混合检索要加上调权重＋重排才从最差方案变成最优方案。重排是「保留召回优势、剔除排序缺陷」的核心操作。

图 15 · RAG-Fusion / RRF：多路排名列表，按「倒数排名」融合成一份

LLM 参与：多路问题由 LLM 生成；融合本身是纯计算

解决什么：多路查询（Multi-Query / 混合检索）各自返回一个排名列表，直接合并会让不相关文档排在前面。基本思路：用倒数排名融合（RRF）把多个排名列表合并成一个。不看原始分数（不同检索器的分数不可比），只看「在各自列表里排第几」：排得越靠前贡献越大，「两路都认可」的文档合成后最靠前。输出 Top-K 再送模型。免分数归一化，简单稳健。

RRF 公式：对每个文档，把它在各列表里的「倒数排名」加起来 RRF(d) = Σ 1 / (k + rankᵢ(d)) · N：参与融合的检索列表数量（BM25＋向量 → N=2；多路召回生成 3 问 → N=3） · rankᵢ(d)：文档 d 在第 i 路检索结果里的排名（从 1 数起） · k：平滑常数，通常取 60。压平不同检索器间不可比的分差 → 「两路都认可」比「单路第一」更可信，这正是融合排序的价值。

适用：多路召回 / 混合检索的结果合并场景，是 Multi-Query 的标配后处理。

图 16 · 上下文压缩：按查询抽取相关内容，不带噪声送模型

模型参与：可用 LLM 抽取，也可用轻量小模型降成本

解决什么：切块的时候并不知道用户会问什么。与查询最相关的信息可能埋在一大段无关文本里，原样送模型既贵又稀释注意力。基本思路：检索返回文档后不直接使用，先用「给定查询的上下文」对文档做压缩，只返回与查询相关的部分。

实测（表 9）：上下文压缩让忠实度 +9.96%、上下文精准度 +5.14%，代价是召回率 −5.56%，综合 F1 几乎不变。省下的 token 和提纯的注意力，换的是更高的答案质量。

评测方法：四个指标与归因诊断

检索和生成必须分开测，否则归因会指错方向

任何 RAG 系统的有效性都依赖两个核心组件：检索器（高效找到最相关文档）与生成器（用检索内容生成连贯准确的回答）。评估的输入有四要素：问题（question）、答案（answer）、上下文（context）、参考答案（reference answer，需人工标注）。据此拆成检索评估与响应评估两组。核心认知是：忠实度低 ≠ 检索差，往往是生成阶段忽略了上下文；召回率低才指向检索与治理。两组分开看，才能定位瓶颈。

图 17 · 四个指标在链路上的归属

理想状态是「高召回 + 高精准」：该找到的都找到、找到的都是相关的。但大规模数据上二者常难兼得。很多业务（客服、技术文档问答）宁可优先保证信息不遗漏，接受「高召回 + 中等精准」。

表 10 · 指标含义与评估输入

指标	归属	评估输入	含义
context_recall	检索	上下文 + 参考答案	上下文覆盖问题所需关键信息的比例
context_precision	检索	上下文 + 参考答案 / 问题	相关信息是否排在前列、占比如何（按位置 k 计算排序质量）
faithfulness	生成	答案 + 上下文	答案是否完全基于上下文、无捏造。拆成原子事实逐条核对依据
answer_relevancy	生成	答案 + 问题	答案是否直接、清晰回答了问题。不考虑正确性，答非所问即无效

表 11 · 四个判例：指标怎么读

问题	关键事实	指标读数
苹果公司总部在哪？	上下文四句里只有一句含「库比蒂诺」，其余是成立年份、CEO、产品	精准度 = 1/4 = 25%。相关内容占比低
《三体》作者是谁？哪年出版？	参考答案两个要点「刘慈欣」「2006 年」，上下文都包含 → 召回 100%；缺「2006 年」则只剩 50%	召回率按关键点覆盖计
爱因斯坦哪年获诺贝尔奖？	答案与上下文一致 → 忠实度 100%；若答案多写一句「当时在普林斯顿任教」（上下文没有），即使正确也判不忠实	忠实度看「有无上下文依据」
如何煮咖啡？	答「研磨至中粗、90℃ 冲 3 分钟」→ 相关性高；答「咖啡起源于埃塞俄比亚」→ 忠实但答非所问	相关性看「是否回应所问」

表 12 · 指标等级标准（满分 1.0）

指标	高	中	低
context_recall	≥ 0.8	0.5 ~ 0.8	< 0.5
context_precision	≥ 0.7	0.4 ~ 0.7	< 0.4
faithfulness	≥ 0.9	0.7 ~ 0.9	< 0.7
answer_relevancy	≥ 0.9	0.7 ~ 0.9	< 0.7

两组指标各有高低、难分优劣时，用 F1（精确率与召回率的调和平均）综合评估。比如 recall 0.67 / precision 0.45（F1≈0.54）对阵 recall 1.00 / precision 0.39（F1≈0.56），F1 给出可比较的综合分。「多高算高」也要按业务风险定，见下面的阈值表。

表 13 · 归因诊断：哪个指标低，指向哪

低指标	可能的问题场景	核心指向
context_recall	检索器未覆盖关键文档（知识库缺失）、嵌入模型语义匹配能力不足	检索器
context_precision	返回大量无关文档、向量库索引策略有误、相关文档排名低	检索器
faithfulness	生成未严格遵循上下文（提示没约束「基于提供的信息回答」）、上下文过长信息稀释	生成器
answer_relevancy	未准确理解问题意图（复杂问题没用链式提示分解）、上下文与问题关联弱	生成器
四指标全低	系统性问题：检索质量极差导致生成器输入混乱；或问题本身超出系统能力	检索优先

优化顺序遵循「先固根基，再求精进」：生成器的输出上限受限于检索器给的输入。Garbage In, Garbage Out。调检索策略（调参、混合检索、重排）通常比大规模微调生成模型更快见效、成本更低。第一阶段夯实检索（recall & precision），第二阶段提升生成（faithfulness & relevancy）。

表 14 · 阈值参考：按业务风险定线

场景	核心指标线	关注点
医疗 / 法律（高风险）	Faithfulness ≥ 0.9，Context Recall ≥ 0.9	任何事实错漏都可能造成严重后果
客服 / 电商 / 咨询	Answer Relevancy ≥ 0.8，Context Precision ≥ 0.7	直接解决问题、少冗余干扰
通用问答 / 内容生成	Answer Relevancy ≥ 0.7，Context Recall ≥ 0.7	覆盖面与相关性的平衡

通用基准可再细一档：忠实度 ≥0.85 是行业普遍追求的目标，低于 0.7 可能存在严重幻觉；答案相关性低于 0.6 用户通常难以接受（开放域 0.7 也可接受）；召回率在知识密集场景要求更高，若允许部分信息缺失（如新闻摘要）可降至 0.6。

适用边界与选型决策

RAG 不是万能，先判断该不该上，再谈怎么搭

当业务需要「用自有、易变的知识回答」，RAG 通常优于微调与纯长上下文：微调改不动、成本高、难溯源；长上下文在知识频繁更新、超长语料、精确溯源上都不如外挂知识库。但以下情况 RAG 不是最优解，需换思路。

表 15 · RAG vs 微调 vs 长上下文

维度	RAG	微调	长上下文
知识更新	即时（改库即可）	慢（需重训）	受窗口限制
溯源能力	强（可附引用）	弱	中
适合	易变、专属知识问答	稳定风格 / 能力塑形	单次超长文档理解
不适合	实时长尾（行情/库存/天气）	频繁变的知识	知识需持续更新

实时、长尾、强时效的信息靠外部 API / 工具调用更合适，不是知识库能兜的。这划定了 RAG 的边界。

现代口径：长上下文没有让检索过时

大窗口和检索不是二选一。窗口是工作容量（一次能同时摆下多少材料），检索是选择器（从海量知识里挑出此刻该看的几段）。两者正交、互补：检索把对的材料送进窗口，窗口负责把材料与问题一起消化。
窗口越长，越要防「上下文腐烂」——内容一多，模型对中间部分的注意力会掉（Lost-in-the-Middle），把整库塞进去反而稀释信号。所以即便百万级窗口，仍靠检索先筛掉噪声，再用窗口承载被筛出的工作集与推理过程。
现实分工：易变、专属知识用检索外挂（即时更新、可溯源）；单次超长文档的理解用大窗口直读。把长上下文当成 RAG 的替代方案，是选型里最常见的误判。

知识库治理：翻车的真正高发区

外在层问题靠治理，不靠检索调优。这是产品侧最该扛的卡

前面所有失败点里，最高频、最难靠工程手段救的，是知识库自身的治理问题：内容缺失、版本过期、多版本并存。这些本质是产品与数据问题，不是算法问题。「输入垃圾，必定输出垃圾」，任何 RAG 链路想获得好表现，都得先清洗数据。对规则 / 政策密集的电商场景尤其突出。

图 18 · 治理两子类：覆盖缺失 vs 版本冲突

治理四要点

覆盖确保该有的规则都进库，建立录入与校验流程；新政策上线与知识库录入必须同步。
时效规则更新时旧版标记过期而非删了重写；定期增量更新并重建索引，避免知识滞后。
版本给知识块打活动 / 品类 / 时间维度标签，检索时先过滤。版本冲突的唯一解。
增量索引选型直接决定治理成本：HNSW 支持增量添加、无需全量重建；IVF 对新增数据不友好，频繁更新的知识库慎选。

成本与延迟权衡

轻量一节：工程取舍要算账

重排、上下文压缩、混合检索都能提质量，但各有代价：重排与压缩要额外的模型调用（token 成本、延迟）；混合检索需调权重。原则是用最低成本的组合达标。小团队可优先「递归分块 + 混合检索 + 轻量重排」，大流量再做更重的增强。实测里上下文压缩以 5.56% 的召回损失换来忠实度 +10%、精准度 +5%，综合 F1 几乎不动。这就是「算得过账」的增强；反过来，没调好权重的混合检索会让精准度近乎减半，得不偿失。评估前也要对 token 消耗有心理预期：评测本身就是一轮不小的调用开销。

总链路图：一段一段看翻车点

把所有环节拼成一条端到端链路，红点即易翻车处

图 19 · RAG 端到端链路与易翻车点

链路越往后，问题越难靠单点解决；越往前（治理、查询），性价比越高。四个指标怎么读这张图：recall 低先看治理，precision 低看检索与融合排序，faithfulness / relevancy 低才轮到生成侧。

真实案例归因

两个电商问答场景，对应治理两子类

案例① · 大促「满减 + 品类券」互斥规则答错（版本冲突型）

事实：用户问「满减和品类券能叠加吗？」系统答「可以叠加」，实际双 11 期间互斥不可叠加 → 错答、客诉。

归因：现行「双 11 互斥」规则在库，排除内容缺失。根因是库里同时躺着现行版（互斥）与过期版（年中促·可叠加），两版语义相近，召回时过期版排前，重排没带时效信号，模型照过期版作答。翻在后段（排序 / 重排 / 拼接）。

指标与痛点：context_precision 低 + faithfulness 低（指向检索器为主因）；痛点对应「错过排名靠前的文档」与「不在上下文」。解法钥匙是元数据 / 维度过滤 + 重排带版本信号。

案例② · 新业务线「以旧换新」政策未录入答错（覆盖缺失型）

事实：新上线「以旧换新」配套新售后政策（不支持 7 天无理由退）。用户问能否 7 天无理由退，系统按通用政策答「支持」 → 实际不支持 → 错答。

归因：知识库里压根没有这条新政策。答案根本没进库，翻在前段（覆盖 / 治理）。context_recall 低，并连带把 faithfulness 拉低（模型回退参数记忆泛化作答）。痛点对应「内容缺失」。

解法：补录入 + 时效更新，并加提示兜底。「根据当前知识库，无法回答该问题」，别让模型编。

表 16 · 两案例对照

	案例① 版本冲突	案例② 覆盖缺失
根因	多版本并存、排序错	根本没进库
翻车段	后段（排序/重排/拼接）	前段（覆盖/治理）
低指标	precision + faithfulness	recall + faithfulness
解法	元数据过滤 + 重排带信号	补录入 + 时效 + 兜底提示
共性	均属外在幻觉，检索器治不了，靠知识库治理

迁移检验：售后政策（A/B 品类维度）、金融合规（监管版本迭代）与这两个案例同构。「同主题多版本需元数据/维度过滤 + 重排带信号」是可跨业务迁移的判据。

三条可复用判断

从上文提炼，可直接用于需求评审与排障

判断一 定位先看「答案在不在召回上下文」。不在，归治理 / 覆盖（前段）；在但答错，归检索排序 / 生成（后段）。这是评测诊断表的口语版。

判断二 治理问题分两子类，解法不同。覆盖缺失（补录入 + 时效）vs 版本冲突（元数据 / 维度过滤 + 重排），别混为一谈，也别指望调检索器解决治理病。

判断三 规则 / 政策类知识库必须带「维度 + 时效」标签，索引选支持增量的。电商的活动、品类、版本天然多轴并存，只靠向量相似分不出；而知识库频繁更新，索引得选 HNSW 这类支持增量添加的，别让每次改规则都要重建。

反例边界：生成器忽略上下文瞎编（recall/precision 正常，靠提示约束）、表格半结构化（需摘要 / 表格专用索引）、实时长尾（需外部 API）、问题含糊（需查询优化）。这些超出三条判断的覆盖，需落到对应专项。

进阶方向速览

生产深入时可关注的四个方向

GraphRAG

用知识图谱做检索，擅长多跳、实体关联类问答，搜索精度高但构建成本高。

Self-RAG

自反思式检索生成，用反思标记自主决定是否检索、是否采信，可显著降低幻觉。

CRAG

对检索结果做置信度评估，不确定时触发外部兜底，提升鲁棒性。

Agentic RAG

把复杂查询拆成并行子查询、动态路由，适合跨源、多步推理场景。

音乐

音乐