🧠 图解记忆： 差评是结果信号；切片找范围、Trace 找环节、回放找证据、灰度验证修复。
面试场景： 几乎必问的生产题。错误回答："我再调一下参数 / 换个模型试试"——一听就是没排查过，全靠猜。
核心答案：一套分层排查方法论
第一层：确认问题范围（先别动代码）
- 是所有问题都差，还是某类问题差？（泛化 vs 特例）
- 是检索阶段就错了，还是检索对了但生成错了？（分离检索质量与生成质量）
- 是最近变差的，还是一直都不好？（回归 vs 历史债）
- 怎么分离？看 trace 日志：每次请求记下 query → 检索到的文档 → 最终回答。对比「检索结果是否相关」和「最终回答是否正确」，即可定位是检索问题还是生成问题。
第二层：检索有问题，逐层查
- 切分问题：chunk 太大不精准 / 太小丢上下文 → 抽样检查 chunk 边界，看关键信息有没有被切断
- embedding 问题：专有名词、缩写语义没对上 → 对比 BM25 和向量检索的召回差异，BM25 能召回而向量不能，说明 embedding 在关键词场景弱
- 检索策略问题：top_k 不够、混合检索权重偏了 → 跑 A/B 实验调 top_k 和 RRF 参数
- 重排问题：reranker 没用 / 阈值不对 → 加 cross-encoder 重排，设置信度阈值过滤低分结果
第三层：生成有问题
- prompt 问题：指令不明确、上下文太长挤掉关键信息 → 精简 prompt、最相关文档放前面
- 模型问题：能力不够或幻觉严重 → 换更强模型、要求输出带引用来源、二次校验关键事实
- 格式问题：返回的不是结构化数据 → 加强 schema 约束 + 解析兜底
第四层：系统性预防（查完还要防）
- 建分层标注集：样本量由错误类型、风险和统计目标决定；每次改策略都跑回归，防止“修好 A 搞坏 B”
- 设质量门禁：Recall@K 和端到端准确率低于阈值自动告警
- 做灰度发布：新策略先 5% 流量，指标 OK 再放量
面试话术：
"排查的核心是'别猜，用数据和分层定位'。我会先看 trace 把问题切成检索层还是生成层，检索层再往下拆切分/embedding/检索策略/重排四环，每环都有对应的验证手段（比如对比 BM25 与向量召回判断 embedding 是否在关键词场景弱）。修完之后靠标注集回归 + 质量门禁防止复发。从用户反馈到具体哪一层出错、怎么改、怎么验证，每一步都有章法。"