项目复盘：RAG 上线后答案质量下降，应该如何定位？

面试时怎么答

这是故障复盘题，没有真实经历也不要编数据，可以明确按线上事故处理。回答顺序从止损、定位到防复发：先确认影响范围并回滚，再按数据、索引、检索、组装、模型和配置逐层对照。

最好说出“拿同一批请求回放新旧链路”，因为这能把流量变化与系统变化分开。追问根因时，用指标和证据说话，不要只列一长串猜测。

可以这样答：

先冻结发布并确认影响范围，必要时切回上一版索引或模型。随后抽取同一批失败请求回放新旧链路，逐层比较文档版本、解析与 Chunk、召回候选、重排分数、上下文截断、Prompt 和模型输出，找到首个发生差异的环节。修复后不仅回归最终正确率，还要补对应的分层指标、金丝雀流量和自动回滚门禁，避免同类问题再次上线。

核心回答

回答项目复盘题不要罗列 RAG 技术，而要证明你能基于证据定位。先用 STAR 交代业务背景、量化影响、自己的职责和恢复目标。排查时固定用户请求，回放旧新两版本，按数据摄取、解析、切块、Embedding、索引、查询、召回、重排、打包、生成逐层比较中间产物。

先回答“充分证据是否进入候选”，再回答“最终上下文是否保留证据”，最后判断“模型是否忠实使用”。每轮只替换一个组件，形成能证伪的假设。结尾给即时止损、根因、永久修复、前后指标和流程改进，避免把相关性写成根因。

展开说明

常见根因包括文档版本未切换、ACL 过滤改变、解析丢标题、Chunk 边界变化、Embedding 未同步重建、近似索引参数变化、重排截断和 Prompt 覆盖引用。总体正确率下降还可能来自流量构成变化，因此要同时看固定回归集与线上同分布切片。

工程实践

为每次回答保存可回放 Trace：数据与索引版本、查询改写、候选及分数、最终上下文、模型和 Prompt。事故先暂停放量或回滚，再用几十条代表性失败做逐阶段 Diff。修复后补数据契约、索引双读 Canary、切片告警和故障样本回归。

常见追问

为什么先看 Recall 而不是先改 Prompt？ 若正确证据根本未进入候选，Prompt 无法创造事实；先定位证据链可避免在生成层盲调。
回滚后还需要做什么？ 保存事故证据、完成根因分析与永久修复，并增加能在发布前捕获同类问题的测试和监控。
如何证明修复不是偶然波动？ 在固定成对样本上重放，报告差值置信区间，并验证线上同切片指标和护栏均恢复。

一句话复习

RAG 质量复盘要用同请求回放逐层找首个差异，先止损，再以根因、量化恢复和防复发措施收尾。