RAG 工程化 · 面试级方法论
RAG 怎么做 Bad Case 分析？
从「看指标」到「拆链路」
「统计准确率、召回率，通过这些指标发现问题」——这句话没错，但它是正确的废话。面试官真正想听的，是你有没有把 RAG 当成一条链路去拆、知不知道 bad case 可能坏在哪一环、有没有真正动手排查过。本文把这套方法论讲透，配图、配场景、配可直接背的框架。
整体指标→
逐环节排查→
打标归类→
具体案例→
回归沉淀
1师弟的答案到底错在哪
先承认：这句话不算错，但它只回答了「知道要看指标」，完全没回答更关键的「具体怎么做」
面试官
你们平时怎么做 Bad Case 分析的？
面试者（师弟）
我们会统计一些指标，比如准确率、召回率，通过这些指标发现问题。
面试官（笑了一下，没接话）
召回率低，你怎么知道是检索的问题，还是排序的问题？
（当场卡住）
这就好比面试官问「怎么排查一个线上 bug」，你回答「看日志，找问题」——听起来对，但等于没说。
为什么这种回答会暴露「水分」？四个典型破绽
1只谈指标，不谈拆解。RAG 不是黑盒，它是链路。整体指标只能告诉你「效果不好」，没法告诉你「到底哪里不好」。面试官那句追问，问的就是你有没有分环节排查的方法论。
2潜台词里透露出「甩锅模型」的思维。继续往下答，大概率会冒出「效果不好可能是模型能力不够」。但真实工程里，大多数 bad case 出在检索和知识库层面，而不是生成模型本身。上来就怪模型，是没有工程经验的表现。
3没有提「人工看中间结果」这种最朴素的手段。指标是抽象的，出问题的往往是具体某一条数据。把改写后的 query、召回的 chunk、拼接进 prompt 的完整上下文一步步打印出来用肉眼看，是最基本也最有效的手段——师弟完全没提。
4没有具体案例。「比如用户问了个问题，系统答错了，我们就去分析」——这种例子等于没举。错在哪、怎么验证、怎么修，一个都没有。
📌 一句话定性：「统计准确率、召回率」是一个合格的开场白，但如果没有后续的「分环节排查方法论」+「具体案例」，就很容易被一句追问打回原形。这道题，本质是筛选真实经验 vs 背过八股的分水岭。
2先建立认知框架：RAG 是一条链路，不是黑盒
任何一环出错，都可能导致最终答案不理想。Bad Case 分析的第一步，就是把这条链路画在脑子里
图 1：RAG 五环节链路 —— Bad Case 分析的「地图」
💡 认知升级：只要你说得出「RAG 不是黑盒，它是一条从查询理解到生成的链路，bad case 要按环节拆」，面试官就立刻知道你脑子里有完整链路，而不是停留在「整体指标」的上帝视角。这句话，是整场回答的地基。
3核心方法：漏斗式逐环节排查
RAG 的排查本质是一个「漏斗」——按顺序检查每个环节，定位坏在哪一层
| 环节 | 排查什么 | 典型故障信号 |
|---|
| ① 查询理解 | Query 改写 / 拆解有没有偏离原意？意图识别对不对？是否路由到正确知识源？ | 用户问「个人还剩多少」，被当成「公司政策」检索；多轮指代没解析 |
| ② 检索召回 | 相关文档到底有没有被召回回来？召回数量够不够？Embedding 是否语义匹配？ | 正确答案根本不在召回集合里；召回了一堆无关文档 |
| ③ 排序 / 重排 | 召回来了，但排名够不够靠前？能否进入送给 LLM 的上下文窗口？ | 正确答案排在第 20 名，被 top-k 截断丢弃 |
| ④ 上下文拼接 | 最终喂给 LLM 的 prompt 内容是否完整、格式是否正确？有没有截断、错乱？ | chunk 被截断一半；多个 chunk 拼接后指代混乱 |
| ⑤ 生成 | 模型有没有正确利用给到的内容？有没有幻觉、答非所问、漏读？ | 明明给了资料却胡编；答非所问；忽略了关键字段 |
✅ 回到那个追问：「召回率低，怎么知道是检索还是排序的问题？」答案就在漏斗里——先确认正确答案有没有进召回集合：① 没进 → 是检索（②）问题（Embedding / 知识库）；② 进了但排得靠后 → 是排序（③）问题（Reranker / top-k）。一句话就拆开了。
① 查询理解Query 改写 · 意图识别 · 路由标记故障
看改写后的 query 是否忠实于原意；是否选对了知识源 / 工具。
▼
② 检索召回向量库 · BM25 · 混合检索标记故障
把正确答案的原文拿去搜，看它能否被召回；对比召回 top-k 里有没有它。
▼
③ 排序 / 重排Reranker · 重排 · top-k标记故障
看正确答案在重排后的位置；调大 top-k 或换更强的 Reranker 验证。
▼
④ 上下文拼接Prompt 组装 · 截断 · 格式标记故障
打印最终送进 LLM 的完整 prompt，肉眼检查内容完整性与格式。
▼
⑤ 生成LLM 作答 · 幻觉 · 漏读标记故障
固定上下文，换模型 / 换 prompt 看是否仍错，定位是不是生成环节。
点击每层的「标记故障」可模拟「定位坏在哪一环」——这就是漏斗式排查的直觉
4第三步：打标归类，按优先级修
每个 bad case 打标签，统计各类占比，优先解决「高频且影响大」的问题——这是工程化思维，不是救火式排查
检索问题
排序问题
生成幻觉
知识库质量
意图识别错误
图 2：从散落 bad case → 打标统计 → 优先级矩阵（先修「高频且高影响」）
📌 工程化 vs 救火式：碰到一个修一个，是「救火」；打标 + 统计占比 + 按优先级排期，是「工程化」。面试官想看到的是后者——你眼里 RAG 是一个可度量、可优先级排序的系统，而不是一堆随机 bug。
5第四步：讲一个具体、有细节的例子
这一步最容易拉开差距。面试官问「能举个例子吗」，考察的就是你有没有真的动手做过
📋 真实案例：年假余额答非所问
系统错误回答
- 「根据公司规定，员工每年可享受 10 天带薪年假。」
这是一个典型的答非所问。用户问的是「我个人还剩多少」，需要去查个人请假记录；但系统把它当成了「公司年假政策」来检索。
🔍 排查结论：检索和生成环节其实都没问题——给到模型的资料是准确的政策条文，模型也 faithfully 回答了。问题出在最上游的查询理解 / 意图识别：系统没有区分「知识库问答」和「需要查询个人数据的业务问题」，属于典型的路由缺失。
✓具体错在哪：意图路由缺失，个人数据类问题误走知识库检索。
✓怎么验证：打印改写后的 query 与路由决策，确认它被标记为「政策问答」而非「个人数据查询」。
✓怎么修：在查询理解层加一层意图分类——个人数据类走业务接口 / 数据库，知识类才走向量检索；必要时加「是否需查个人数据」的路由判断。
✅ 例子的价值在于「具体」：具体到问题是什么、答案是什么、错在哪个环节、怎么验证、怎么修——一步都不能少。笼统的「用户问了个问题，系统答错了，我们就去分析」等于没举。
6第五步：提一句沉淀机制（闭环意识）
很多人排查完 bad case 就觉得结束了。成熟的工程实践一定会考虑「怎么防止同样的问题再次发生」
修复验证过的 bad case
▼
沉淀成固定的回归测试集
▼
后续换模型 / 调 prompt / 改检索时
▼
自动跑回归，防止老问题复现
📌 这一句话虽然短，但能体现闭环意识：你不是「排查完就完事」，而是把每次修复变成系统的「免疫记忆」。换模型、调 prompt 这种高风险操作，最容易让老问题复活——有个回归集罩着，才敢动。
7整理成可直接背的答题框架
五步法，按顺序说，面试官基本挑不出毛病
1为什么做（认知框架）：「整体指标只能告诉我们效果好不好，但没法告诉我们坏在哪、怎么修。所以我会针对具体 bad case 做逐环节排查。」——一句话亮出链路思维。
2排查顺序（漏斗）：按顺序查 ① 查询理解 → ② 检索召回 → ③ 排序重排 → ④ 上下文拼接 → ⑤ 生成，定位坏在哪层。
3归类 + 排优先级：给每个 case 打标签（检索/排序/幻觉/知识库/意图），统计占比，优先修「高频且高影响」。
4具体案例：举一个有细节的例子（如年假余额路由缺失），说清错在哪、怎么验证、怎么修。
5沉淀机制：修复验证过的 case 沉淀成回归测试集，防老问题复现。
🎯 一句话记住：指标是「开场白」，链路是「地基」，漏斗是「方法」，案例是「杀手锏」，回归是「闭环」。五步齐了，这道题从「送分题」变成你的「加分题」。
8写在最后
很多「送分」问题，恰恰是筛选真实经验与背八股的分水岭
「统计准确率、召回率」不是错，而是太浅。它是一个合格的开场白，但如果没有后续的「分环节排查方法论」+「具体案例」，就很容易被一句追问打回原形。
如果你也快面试了，提前把这几个问题在脑子里过一遍
?我遇到过的 bad case，错在哪个环节？
?我怎么验证是那一环的问题？
?我怎么修的？
?修复之后，我们有没有做防止它再犯的事？
📌 把这几个问题想清楚，比背十个术语都管用。共勉。