怎么考「用户说「答非所问」，你怎么归因是检索问题还是生成问题？」
谁在问：二三面·追问重灾区；本章最能拉开差距的一题
开场怎么问
上线后用户投诉答得不对，你从哪开始查？
换个问法
- 怎么判断是没检索到，还是检索到了但模型没答好？
- 给你一个 badcase，说说你的排查流程。
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
检索结果里有正确 chunk 但排在第 15 位，你怎么修？
- 期望
- 这是排序问题不是召回问题——加 rerank 是最直接的解；也可以调融合参数（RRF 的 k 或加权 α）、检查是不是这类 query 该加重 BM25。不该做的是加大 top-k 硬塞，那会引入噪音、加剧失焦。
- 信号
- 能明确区分「召回问题」和「排序问题」对应不同解法的，框架清晰。
手工塞了正确文档模型还是答错，接下来查什么？
- 期望
- 按顺序——① 看 prompt 里的指令是否明确要求「只依据材料回答」；② 看材料在上下文里的位置（中间位置利用率低）；③ 看材料是不是太长太杂；④ 看是不是模型能力不够（换更强的模型试一次，作为诊断而非解法）；⑤ 看是不是问题本身需要多跳推理而材料只覆盖了一跳。
- 信号
- 能给出有序清单而不是「调一调 prompt 试试」的，说明有方法论。
怎么区分「知识库里没有」和「检索没找到」？
- 期望
- 直接在原始文档里全文搜关键词（或人工翻）。这一步经常被跳过，但它能立刻把「数据缺失」这类非技术问题摘出去——否则你会花一周优化检索，去找一个根本不存在的答案。
- 信号
- 能想到这个动作的，排查过真实线上问题；想不到的，通常会在错误方向上浪费大量时间。
你怎么把这些排查沉淀成可复用的东西？
- 期望
- badcase 打标签分类（分块/召回/排序/生成/数据缺失/预期错位）→ 统计各类占比 → 按量级排优先级 → 每类沉淀典型 case 进回归集 → 定期回看分布变化。回归集只增不减，是防止「修 A 打坏 B」的唯一保障。进阶：把归因流程做成半自动脚本（自动记录检索结果、自动跑「塞正确文档」对照实验）。
- 信号
- 能说出「统计各类占比再排优先级」的，有数据驱动意识；只说「记录下来」的偏弱。
老板明天要看改善，你只有一天，怎么排优先级？
- 期望
- 不做大改造。① 先抽 20–30 个 badcase 快速归因打标，看哪一类占比最大；② 挑「改动最小、覆盖面最大」的那一项动手——通常是加 rerank、调 top-k、补分词词典、加「不知道就说不知道」的约束，这些都是小时级改动；③ 跑回归确认没打坏别的；④ 汇报时给分类统计 + 本次修了哪类 + 剩下哪类需要更长周期，而不是拍胸脯说都修好了。
- 信号
- 一天之内选择重建索引或上 GraphRAG 的，缺乏工期判断；能给出「先归因统计再挑性价比最高的一刀」的，是成熟工程师的反应。
危险信号
听到这些话，基本可以判定是背题而不是做过。
「先看看日志」——没有具体的第一动作，等于没有排查框架。
直接开始猜「可能是 chunk 切得不好」，不做任何对照实验就动手调参。
检索和生成混在一起排查，改了一堆东西说不清哪个起了作用。
一个 badcase 就要上 GraphRAG / 换大模型——过度反应。
修完就完了，不分类、不统计、不进回归集。
从没想过「知识库里可能压根没这个答案」。
评分卡
- 第一动作明确：把检索和生成切开（手工塞正确文档做对照）
- 检索侧能再分层（召回失败 / 排序靠后 / 过滤误杀）
- 生成侧能再分层（指令不清 / 材料过长 / 位置靠中 / 材料不足硬答）
- 能区分「知识库没有」与「检索没找到」并给出验证动作
- 有「一次只改一个变量」的纪律
- 加分：不为单个 badcase 做架构决策，先看类别量级
- 加分：badcase 沉淀进回归集
- 加分：能想到「用户预期错位」这类非技术根因
参考答案与考察意图面试中途别看这一段
考察意图
这是整个 RAG 章最能区分「做过系统」和「读过教程」的一题。 读过教程的人知道每个组件是什么；做过系统的人知道出了问题该按什么顺序拆。面试官在看三件事：① 你有没有一个确定的第一动作（而不是「先看看日志」这种废话）；② 你的排查是否有序、是否收敛；③ 你会不会在没有证据前就动手调参。
参考答案
60 分答案（及格线）
第一步是把检索和生成切开：取出这次实际检索到的 chunk 看一眼——
- 如果正确答案根本不在检索结果里 → 检索的锅，去查分块、embedding、混合检索、rerank。
- 如果正确答案在检索结果里但模型没答对 → 生成的锅，去查 prompt、上下文组装顺序、模型能力。
最直接的验证方法是：把正确的文档手工塞进 prompt 再问一次。答对了就是检索问题，还答错就是生成问题。这一刀成本极低，能立刻把问题范围缩小一半。
90 分答案（有生产经验的回答）
在这一刀之后，给出完整的分层排查树：
【第 0 步】复现 + 看实际检索结果（不看日志的排查都是猜） 【第 1 刀】手工塞正确文档 → 还答错吗？ ├─ 答对了 ──────────────► 检索侧问题，继续往下切 └─ 还是错 ──────────────► 生成侧问题，跳到第 3 步 【第 2 步】检索侧再分三层 ├─ 正确 chunk 根本不在候选里（recall 失败） │ ├─ 知识库里压根没有这条 → 数据缺失，不是技术问题 │ ├─ chunk 被切碎/语义断裂 → 分块问题（Q2-03/04） │ ├─ 是型号/编号类精确查询 → BM25 缺失或分词切碎（Q2-09） │ └─ 是口语化/多轮指代 → 查询改写缺失（Q2-13） ├─ 在候选里但排名靠后被截断 → 排序问题，加/调 rerank（Q2-11） └─ 被元数据过滤误杀（权限、时间）→ 过滤逻辑问题 【第 3 步】生成侧再分三层 ├─ 材料够但答偏 → prompt 指令不清、缺少「只依据材料」的约束 ├─ 材料多而杂 → 上下文太长导致失焦（context rot），减 top-k 或加 rerank ├─ 材料在中间被忽略 → 上下文顺序问题（lost in the middle），把最相关的放首尾 └─ 材料不足却硬答 → 缺少「不知道就说不知道」的约束与检索分数阈值 【第 4 步】归类打标 → 统计量级 → 按量排优先级 → 改一个变量 → 全量回归 → 加进回归集
三条纪律（这部分最能体现成熟度）：
- 不看实际检索结果就不动手。 没有证据的调参是玄学，改完效果变了也不知道为什么。
- 一次只改一个变量。 同时换 embedding 又改 chunk 大小，收益无法归因。
- 单个 badcase 不驱动架构决策。 一个 case 修完要看它属于哪一类、这一类占多少量——为一个孤例上 GraphRAG 是典型的过度反应。
还要补一个反直觉的可能：用户说「答非所问」，有时问题既不在检索也不在生成，而在用户预期——他问的是「这个功能怎么用」，期待的是操作步骤，而知识库里只有功能定义。这属于知识库覆盖度问题，解法是补内容，不是调技术参数。能想到这一层，说明有产品视角。
攒够了去组卷页一键生成可打印的面试题单