标准回答
先复现并对齐变更，再分环节定位（独占一行）
「质量下降」要先量化、再复现：拿一批可复现的 bad case 与固定评测集跑一遍，确认确实下降及下降幅度，避免凭主观感受。
对齐变更时间线
LLM 应用是组合系统，先查最近改了什么：模型/接口版本升级、Prompt 或模板变更、温度等参数调整、上游检索/知识库数据更新、依赖库升级。多数线上回归对应一次具体变更。
抓 trace 全链路复盘
借助 LLM 可观测性 记录每次调用的真实输入、最终拼好的 Prompt、检索到的上下文、模型原始输出与 token 用量。逐条看 bad case，区分是检索给错了料、Prompt 拼装出错，还是模型本身答偏。
上下文与参数
检查上下文是否超出窗口被截断、关键指令或证据被挤出、system/few-shot 被用户输入覆盖；核对温度、top-p、max_tokens 是否被改动导致发散或截断。
量化与回归评测
维护固定回归评测集（含人工或 LLM-as-Judge 评测），新版本上线前回归、上线后 A/B 对比，把「感觉变差」变成可定位、可回滚的指标。
常见误区
⚠️ 常见踩坑
凭个别 case 主观判断「模型变笨了」就急着换模型/改 Prompt，却不看 trace、不跑回归评测集，也不对齐最近的版本与数据变更，导致定位错方向、无法回滚。
追问
追问 1：怎么区分是模型本身变差，还是 RAG 检索/上下文出了问题？
看 trace 里喂给模型的最终上下文：若检索内容缺失/不相关或被截断，是检索/上下文问题；把同样的输入与上下文喂给已知好的旧版本模型，若旧版本答得好、新版差，则是模型/参数问题。隔离变量逐项替换即可定位。
追问 2：没有标准答案的开放生成任务，怎么持续监控质量？
组合多种信号：用 LLM-as-Judge 按既定准则打分、规则/校验器检查格式与约束、采样人工评审、以及业务侧代理指标（采纳率、重试率、用户负反馈）。把这些指标做成看板与告警，并维护回归评测集在每次发布时对比。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。