说一个你处理过的最难的 RAG badcase

Q2-18项目经历深挖难高频项目经历badcaseSTAR真实性验证开放题

谁在问：简历深挖环节；几乎所有写了 RAG 项目的候选人都会被问到

口语化问法

讲一个你们上线后遇到的最棘手的问题。
你这个项目里，最让你头疼的 case 是什么？怎么解决的？
有没有那种查了好几天才找到原因的问题？

考察意图

这是简历深挖环节的真实性验证题，不考知识，考经历的密度。面试官在听三样东西：① 细节的颗粒度——编的经历讲不出具体数字、具体现象、具体工具；② 无效尝试——真实排查一定走过弯路，全程一帆风顺的故事反而可疑；③ 归因质量——你最后归因到的根因，是表层（「chunk 切得不好」）还是深层（「表格被拍扁导致数字丢失语义关联」）。

参考答案

图 2 · 过关线与雷区：判分点和常见失分

回答结构（必须准备，不能临场发挥）

不是背答案，而是把你自己的真实经历套进这个五段式：

现象（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 调用。沉淀：评测集加入多轮桶。

追问链

图 1 · 五层追问树：面试官会往哪儿挖

简历深挖题：五层全在验你的归因过程，不验知识点

你当时怎么发现是这个原因的？有没有别的可能性被排除了？
期望说得出具体的对照实验：手工塞文档、打印实际检索结果、单独跑某一路检索 —— 而不是「分析了一下觉得是」；排除其他可能的过程越具体越可信
信号本题最强的真伪探针：在这里开始含糊、转向抽象描述 → 经历大概率是编的
这个解法有什么副作用？有没有打坏别的场景？
期望真实解法都有代价：加 BM25 让语义类 query 变差、加改写增加延迟、表格摘要增加索引成本；主动说副作用 + 说清怎么验证没打坏其他桶（全量回归、分桶对比）
信号说「没有副作用，全面提升」→ 要么没做分桶评测，要么是编的
修完之后指标提升了多少？怎么测的？
期望要有数字，粗略也行 ——「那类 query 的 recall@5 从 0.4 提到 0.8」「客服反馈量减半」；测法也要说得出：评测集分桶对比、线上 A/B、点踩率变化
信号一个数字都给不出 → 项目根本没有评测体系（这本身就是扣分项）
现在回头看，这个问题本来能不能更早发现？
期望能 —— 评测集一开始就按 query 类型分桶，型号类那桶的低分上线前就会暴露；解析环节有质量验收，表格问题也能提前发现。这层考复盘深度，好答案指向机制建设而不是这一次的修复
信号能自我批评、指出机制缺失 → 成熟度高；说「已经是最快了」→ 缺复盘意识
如果这个问题现在还没解决，你下一步会做什么？
期望按优先级给行动清单：先量化这类问题的占比（值不值得投入）→ 再列候选方案按改动成本排序 → 先做最小验证再全量。考的是「在不确定中推进」，不是纠结于没有完美答案
信号坦然承认「当时没彻底解决，做了降级方案」→ 比强行圆满的故事更可信

这题没有标准答案，第 1 层的对照实验和第 2 层的副作用就是真伪分水岭 —— 编的经历在这两处会从具体动作滑向抽象描述；第 3 层要数字，第 4 层要复盘，第 5 层要在不确定中推进的排序能力。

评分要点

现象描述具体、有量化（不是「效果不好」）
讲得出走过的弯路和被排除的假设
归因过程有具体的对照实验动作
解法能说清为什么选它、代价是什么
有副作用意识并说得出怎么验证
能给出提升的量化结果和测法
加分：修完沉淀进回归集或形成机制
加分：复盘能指向「本可以更早发现」的机制缺失

常见错误

讲一个教科书式的通用问题（「幻觉」「切分不好」），没有任何本项目的独特细节。

全程一帆风顺，没有任何弯路——真实排查几乎不可能一次命中，这反而是最大的可疑信号。

说不出具体数字、具体工具、具体现象。

归因停留在表层（「就是 chunk 切得不好」），说不清为什么切不好会导致这个具体现象。

解法说得很完美、零代价、全面提升。

讲了半天其实是别人解决的，追问细节就露馅——这题一定要选自己主导过的 case。