怎么考「说一个你处理过的最难的 RAG badcase」
谁在问：简历深挖环节；几乎所有写了 RAG 项目的候选人都会被问到
开场怎么问
讲一个你们上线后遇到的最棘手的问题。
换个问法
- 你这个项目里，最让你头疼的 case 是什么？怎么解决的？
- 有没有那种查了好几天才找到原因的问题？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
你当时怎么发现是这个原因的？有没有别的可能性被排除了？
- 期望
- 要能说出具体的对照实验（手工塞文档、打印实际检索结果、单独跑某一路检索），而不是「分析了一下觉得是」。排除其他可能的过程越具体越可信。
- 信号
- 这是本题最强的真伪探针。编的经历在这里会开始含糊，转向抽象描述。
这个解法有什么副作用？有没有打坏别的场景？
- 期望
- 真实的解法都有代价——加 BM25 可能让语义类 query 变差、加改写增加延迟、表格摘要增加索引成本。能主动说出副作用并说明怎么验证没打坏其他桶（全量回归、分桶对比）的，可信度极高。
- 信号
- 说「没有副作用，全面提升」的，要么没做分桶评测，要么是编的。
修完之后指标提升了多少？怎么测的？
- 期望
- 要有数字，哪怕是粗略的（「那一类 query 的 recall@5 从 0.4 提到 0.8」「客服反馈量减少了一半」）。测法要说得出——评测集分桶对比、线上 A/B、点踩率变化。
- 信号
- 完全给不出任何数字的，说明项目没有评测体系（这本身就是扣分项，见 Q2-15）。
现在回头看，这个问题本来能不能更早发现？
- 期望
- 能——如果评测集一开始就按 query 类型分桶，型号类那一桶的低分会在上线前暴露；如果解析环节有质量验收，表格问题也能提前发现。这题考的是复盘深度，好的回答会指向机制建设而不只是这一次的修复。
- 信号
- 能自我批评并指出机制缺失的，成熟度高；说「已经是最快了」的，缺少复盘意识。
如果这个问题现在还没解决，你下一步会做什么？
- 期望
- 给出有优先级的行动清单——先量化这类问题的占比（值不值得投入）、再列候选方案按改动成本排序、先做最小验证再全量。关键是展示「在不确定中推进」的能力，而不是纠结于没有完美答案。
- 信号
- 能坦然承认「有些问题当时没彻底解决，我们做了降级方案」的，反而比强行圆满的故事更可信。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 现象描述具体、有量化（不是「效果不好」）
- 讲得出走过的弯路和被排除的假设
- 归因过程有具体的对照实验动作
- 解法能说清为什么选它、代价是什么
- 有副作用意识并说得出怎么验证
- 能给出提升的量化结果和测法
- 加分：修完沉淀进回归集或形成机制
- 加分：复盘能指向「本可以更早发现」的机制缺失
参考答案与考察意图面试中途别看这一段
考察意图
这是简历深挖环节的真实性验证题，不考知识，考经历的密度。面试官在听三样东西：① 细节的颗粒度——编的经历讲不出具体数字、具体现象、具体工具；② 无效尝试——真实排查一定走过弯路，全程一帆风顺的故事反而可疑；③ 归因质量——你最后归因到的根因，是表层（「chunk 切得不好」）还是深层（「表格被拍扁导致数字丢失语义关联」）。
参考答案
回答结构（必须准备，不能临场发挥）
不是背答案，而是把你自己的真实经历套进这个五段式：
- 现象（20 秒）：谁、在什么场景、遇到什么具体表现。要有可感知的细节和量化——「客服反馈约 15% 的型号类问题答非所问」远胜于「效果不太好」。
- 初步排查与走过的弯路（30 秒）：这一段最能证明真实性。你先怀疑了什么？为什么排除了？试了什么没用？
- 归因（30 秒）：怎么定位到真正的根因。要能说出你用的具体动作（比如「把正确文档手工塞进 prompt 做对照，发现能答对，确认是检索侧」）。
- 解法与取舍（30 秒）：最终怎么修的，为什么选这个方案而不是另一个，付出了什么代价。
- 沉淀（15 秒）：加进回归集了吗？有没有形成机制防止同类问题再发生？
三个可参考的真实 badcase 形态
如果你的项目经历里有类似情况，可以按上面五段式组织。不要照抄下面的案例当自己的经历——面试官的追问会立刻穿帮。
形态一：型号类查询大面积失败 现象：设备手册问答，用户问「SK-3200 报 E05 怎么处理」，返回的是通用故障总览。走过的弯路：先怀疑 chunk 切太大，调小了没用；又换了 embedding 模型，仍然不行。归因：手工塞正确文档能答对 → 确认是检索侧；进一步发现纯向量检索对型号编号这类低频符号区分度极低。解法：加 BM25 做混合检索 + RRF 融合，并且发现分词器把「SK-3200」切碎了，加自定义词典后才真正生效。代价：多维护一套倒排索引。沉淀：把型号类 query 单独作为评测集的一个桶。
形态二：表格里的数字答不出来 现象：产品参数问答，凡是问具体参数值的都答错或答不出。弯路：以为是模型不会读表格，换了更强的模型没用。归因：查检索结果发现表格 chunk 根本没被召回——因为表格被拍扁成一行行文本后，全是数字和短标签，和自然语言问句在向量空间距离极远。解法：整表存为 Markdown chunk，额外用模型生成一句自然语言摘要作为检索向量（检索用摘要，回答用原表）。沉淀：所有含表格的文档走单独的解析分支。
形态三：多轮对话第二问开始崩 现象：单轮问答表现不错，但对话到第二三轮准确率骤降。弯路：怀疑是上下文太长导致失焦，压缩了历史没用。归因：打印实际送去检索的 query，发现是「那它多少钱」这种带指代的原话——检索器根本不知道「它」是谁。解法：加查询改写，用小模型结合对话历史把 query 改成自包含形式；并保留原 query 一起检索做兜底。代价：多一次 LLM 调用。沉淀：评测集加入多轮桶。