大模型应用上线前如何做评测、回归和灰度发布？

简化版

上线前要建立固定评测集和回归流程，覆盖高频任务、边界问题、安全问题、格式输出和成本延迟。发布时对 prompt、RAG、模型、工具和后处理都做版本管理，通过离线评测、影子流量、灰度发布和回滚机制降低风险。

详细版

• LLM 应用变更不只是代码变更，prompt、知识库、模型版本都可能改变行为。
• 评测集要包含真实用户问题、人工标注期望、拒答边界和难例。
• 自动评测可以提高效率，但关键场景仍需要人工抽检。
• 灰度发布要按租户、流量比例或用户群分层推进。
• 每次发布都要记录版本组合，方便复现线上问题。

完整版教学

记忆钩子：LLM 发布不是“改 prompt 立即上线”，而是“任何影响输出分布的变更都要回归”。

一、这题真正考什么

记忆钩子：LLM 发布不是“改 prompt 立即上线”，而是“任何影响输出分布的变更都要回归”。

Prompt、模型、检索索引、工具 schema 和策略配置任一变化都可能改变输出，因此都属于可发布版本。离线门禁回答“能否灰度”，灰度指标回答“能否扩大”，二者必须共享同一版本标识。

二、核心原理和工程边界

传统软件回归主要看功能是否符合预期，LLM 应用还要看答案质量是否退化。因为模型输出具有随机性，评测通常采用多样本、多指标和人工审查组合。发布系统要把 prompt 版本、模型版本、检索索引版本和工具版本绑定成一次 release。

三、带数字的工程算例

一次 prompt 改动让 JSON 合规率从 98% 提到 99%，但客服拒答率从 4% 升到 12%。如果只看格式指标会误判成功；完整发布门槛应同时检查任务成功率、拒答率、幻觉率、延迟和成本。

发布准入 = 核心任务达标 && 安全指标达标 && 成本延迟不超阈值
回归差异 = 新版本指标 - 基线版本指标
灰度风险 = 影响用户数 * 失败概率 * 失败严重度

四、典型链路怎么跑

可以把这类问题拆成下面的链路来理解：

变更提交
   |
绑定 prompt/model/index/tool 版本
   |
离线评测
   |
人工抽检高风险样本
   |
影子流量
   |
灰度发布
   |
监控与回滚

五、方案对比和选择标准

阶段	目标	常见指标
离线评测	快速拦截退化	成功率、合规率、幻觉率
人工抽检	识别细微质量问题	专业性、风险等级
影子流量	验证真实分布	差异率、成本、延迟
灰度发布	控制影响范围	投诉率、错误率、回滚率

六、上线后最容易出问题的地方

• 评测集长期不更新会被 prompt 过拟合，线上新问题仍然暴露风险。

• 只记录代码版本无法复现 LLM 行为，必须记录 prompt、模型和知识库版本。

• Judge 模型升级也会改变分数，评分器版本与人工校准集必须和被测系统一起冻结。

七、常见误区与追问

• 误区：prompt 改动不算发布。 Prompt 会改变行为分布和工具选择，必须版本化、回归、灰度并支持原子回滚。
• 误区：用大模型当裁判就不需要人工评审。 Judge 有位置、长度和自偏好，需要用人工金标校准，并对高风险失败保留人工复核。
• 误区：离线评测通过就可以全量上线。 离线集覆盖有限，仍要用小流量观察真实分布、成本、延迟和未知失败。
• 追问：评测集如何防止过拟合？ 隔离开发集与最终门禁集，限制查看频率，持续加入线上新失败并保留隐藏测试。
• 追问：如何做 prompt 版本回滚？ 保存不可变模板、变量 schema 和依赖版本，用网关路由切回上一完整发布单元，而非只替换文本。
• 追问：灰度期间应该监控哪些指标？ 比较任务成功、拒答、解析失败、工具副作用、TTFT/TPOT、成本和用户投诉，并按请求类型切片。

八、加强记忆

把发布记成“版本绑定、离线回归、人工抽检、影子流量、灰度回滚”。LLM 应用的发布风险来自输出分布变化，所以任何影响输出的东西都要入版本。