考察点
这道题考察的是把「评测」从一次性动作变成持续流程的能力，常作为评估类问题的收口题出现。面试官想确认你理解大模型应用和传统软件发布的关键差异：行为不确定、依赖外部模型服务、知识库随时在变，所以「测完上线」不成立，必须是「上线前门禁 + 上线后持续回归」的组合。
参考答案
大模型应用的发布为什么特殊
传统软件发版，测试通过基本意味着行为确定。大模型应用有三个额外的不确定性源：模型是概率系统，同样的输入输出会变；模型服务可能被供应商静默升级（线上调 API 的团队都遇到过「什么都没改效果变了」）；知识库、外部工具接口持续变化。所以发布管理的目标不是「保证这次上线没问题」，而是「任何一层变化时都能快速发现、快速定位、快速回退」。
上线前：三层评测集 + 门禁
评测资产按用途分三层组织：
- 核心场景集：覆盖主要业务场景和关键用户路径，几百条量级，带标准答案或环境校验规则。这是质量的基本盘。
- badcase 回归集：历史线上事故和修复记录沉淀下来的 case，每条带错误标签和预期行为。它防的是「改了 A 坏了 B」。
- 红队安全集：越狱、注入、越权、泄露攻击样本。安全是独立的一票否决线。
发布门禁的常规配置：核心场景集成功率不低于基线（或不低于上一版本），回归集修复保持率 100%，红队集攻击全部拦截（高危类目零通过）。门禁跑在 CI 里，prompt、模型版本、工具 schema、知识库构建流程的任何变更都触发。注意门禁要测端到端链路而不是只测模型输出——检索配置改了、工具描述改了，影响都在链路上。
评测结果要和变更绑定存档：哪个 commit、配的哪版评测集、各层指标多少。出线上问题时这是回溯的起点。
上线中：灰度与影子测试
门禁过了也不全量推。两条渐进路径按风险选：
灰度发布：新版本切 5% 真实流量，盯核心指标（成功率、延迟、成本、投诉率）与对照组的差异，逐步放到 50%、100%。适合改动较小、评测集信心足的情况。
影子测试：新版本与老版本并行处理同样的真实请求，但新版本的结果不生效、不对用户可见，只记录用于离线对比。零用户风险，能看到新版本在真实分布上的表现，适合模型切换、架构大改这类高风险变更。代价是双倍的推理成本和一套请求复制的基础设施。
上线后：监控、抽检、持续回归
三层监控撑起日常质量运营。第一层指标监控：成功率、P95 延迟、单请求成本、工具调用失败率、审核拦截率，设告警阈值。第二层质量抽检：线上流量按 1%-5% 抽样送 LLM-as-Judge 评分，再抽更小比例人工复核校准 judge，分数趋势下跌就是信号。第三层badcase 管道：点踩、转人工、行为异常信号进 badcase 库，按错误类型归因，修复后进回归集——这就和上线前的门禁闭环接上了。
还有一个容易被忽略的定期全量回归：即使你的代码没动，也要定期（比如每天或每周）用评测集重放线上服务。模型供应商升级、知识库更新、外部工具变化都会被这个动作抓住。某次「什么都没改但指标掉了」，先查这个回归的历史曲线，多半能定位到外部变化的时间点。
回退预案
大模型应用的回退比传统软件复杂：prompt 和配置可以秒级回滚（所以 prompt 必须版本化管理、支持灰度），但知识库回滚要考虑重建成本，模型版本回滚要看供应商是否还保留旧版本端点。工程上 prompt、模型版本、评测集版本三者绑定记录，回滚时整套回滚，避免「新 prompt 配旧模型」这种没测过的组合上线。
可能的追问
- 评测集和线上表现不一致怎么办（离线涨线上不涨）？ 答：评测集分布和真实流量漂了。从线上最新流量重采样补集，尤其要补新出现的长尾场景；同时检查评测集的答案是否过期（业务规则变了旧答案不再对）。
- 小团队没资源搭全套，最小可行方案是什么？ 答：三样东西必须有：一个几十条的核心场景评测集（手工攒）、prompt 版本管理和一键回滚、线上成功率监控。这三样成本极低，缺了任何一样都是在裸奔。
- 模型供应商升级导致线上效果波动，怎么应对？ 答：固定模型版本号而不是用 latest；供应商通知弃用时，先在评测集上对比新旧版本再迁移；对关键业务同时保留备选供应商的适配层，极端情况可以切换。