考察点
大模型应用迭代快，prompt 改一行、模型升一版，效果可能在你没测的场景里崩掉。这道题看候选人有没有建立「变更-验证-发布-监控」完整防线的经验。面试官想听到具体机制而不是口号。追问常往「评测有随机性怎么设门禁」「线上指标波动多少算倒退」「怎么定位倒退是哪个环节引起的」走。
参考答案
问题的本质
传统软件改代码，单测能覆盖确定性逻辑；大模型应用的核心行为由 prompt 和模型权重决定，输出有随机性，场景空间又接近无限，你不可能穷举测试。所以防倒退要靠「代表性样本集 + 统计化判定 + 分层发布」的组合拳，而不是追求绝对保证。
第一道防线：把变更管起来
prompt 必须当代码管理：进 git，走 code review，每次变更有说明（改了什么、为什么、预期影响哪些场景）。模型版本、温度等参数、检索配置同理，全部配置化、版本化。很多线上事故查到最后是「某人直接在生产环境改了 prompt 没留记录」，管理混乱比技术问题更常见。评测用的 golden set 也要版本化，保证「这个分数是在哪份数据、哪个 prompt 版本上跑的」可追溯。
第二道防线：离线 CI 门禁
每次变更触发离线回归：在固定评测集上跑完整链路，输出核心指标——意图准确率、忠实度、安全通过率、格式合规率，按场景分开展示。门禁规则是「核心指标下降超过阈值则阻断合入」。
阈值的设定有讲究。LLM 输出有随机性，同一版本跑两遍指标也会波动零点几个点，门禁阈值必须大于自然波动，否则天天误报团队就麻木了。做法是先测系统噪声水平：同一版本跑 3-5 遍看指标方差，阈值设在噪声上限之上，比如噪声是 0.5 个点，阈值设 1-2 个点。重要版本对比时，双方各跑多次取均值再比，单次结果不做决策。评测报告要给 case 级 diff：哪些变好哪些变差，变差的 case 人工看一眼是真退化还是标注噪声，case diff 比总分更能暴露问题。
第三道防线：线上分层发布
离线通过不等于线上安全，发布要分层。先 shadow：新版本并行处理真实流量，只记录不返回，对比新旧输出的差异率和关键指标，零风险地拿到真实分布下的表现。再 canary：5%-10% 真实用户切到新版本，观察解决率、点踩率、转人工率、延迟、成本这些护栏指标，观察窗口至少覆盖一个业务周期，防止「周一效果好、周末崩掉」这类周期性问题。最后逐步放量到全量。模型供应商的版本升级（比如 API 模型静默更新）也要纳入这套流程，做法是锁定模型版本号，升级前先在评测集上跑对比。
第四道防线：线上监控与回滚
护栏指标实时看板，设告警阈值：点踩率突增、转人工率上升、延迟 P95 恶化、成本异常。告警触发后的标准动作是回滚——因为一切都在版本管理里，回滚就是把上一个 prompt 版本切回来，分钟级完成。所以回滚能力要在平时演练，不能等出事才发现回滚链路是断的。
最后强调 badcase 闭环：每次抓到的倒退 case 必须进回归集，这样防线越用越厚。倒退的根因要归类：prompt 变更直接引起的、模型版本差异引起的、数据分布漂移引起的，不同根因进不同的修复流程。
可能的追问
- 改动很小时也要全量回归吗？ 按变更半径定测试范围：只改某个意图的话术，重点跑该意图的评测集加核心集冒烟；动 system prompt 主干、换模型、改检索配置，跑全量。但安全对抗集无论什么变更都必跑。
- A 场景提升 2 个点、B 场景下降 1 个点，发不发？ 看场景权重：核心高频场景一票否决，边缘场景可以接受权衡但要有明确记录；更好的做法是看能否通过场景路由（不同场景用不同 prompt 版本）做到两头兼顾。
- 多次采样取均值成本高，怎么省？ 分层：常规迭代用单次低温（temperature=0）跑，结果只做粗筛；发版决策和重要对比才上多次采样。温度设 0 不能完全消除随机性（batch、浮点、供应商端都有因素），但能把方差降一个量级。