把 LLM 评测接进 CI:提示词与模型变更的自动回归防线

一次线上事故的复盘往往长这样:有人为了让客服机器人的回答更礼貌一点,在 system prompt 里加了一句约束;两周后运营发现工单里答非所问的比例悄悄涨了,但没人能说清是哪次改动引入的。回滚哪一版?没人敢拍板,因为改的只是一句自然语言,既没报错也没红线,常规测试全绿。更隐蔽的一种是模型供应商在你不知情时把 checkpoint 静默升级了,输入分布没变、输出却整体漂移。这两类问题的共同点是:它们不会让程序崩溃,只会让质量在统计意义上退化,而人工抽查几条样本根本看不出来。现象:改一句话,整条输入分布都在动传统单元测试的前提是相同输入得到相同输出,于是可以写死断言。LLM 系统违背了这个前提。改写一句系统提示、把模型从某一代升到下一代、调整检索的召回配置,任何一处变动都可能让输出在整个输入分布上发生偏移,而这种偏移对着几个手挑的例子是看不见的。结果就是回归测试的语义变了。你不再是验证这个函数返回 42,而是要回答一个统计问题:这次变更之后,系统在一批代表性任务上的整体质量,相比上一版是升了还是降了、降了多少、能否接受。工程团队缺的不是跑一遍看看的能力,而是一条能在每次提交时自动给出这个判断、并在质量掉到阈值以下时挡住合并的流水线。是否提示词 / 模型 / 检索变更核心黄金数据集确定性断言模型评分门禁是否通过允许合并阻断并复核原理:评测是分布上的度量,不是一次断言要把这件事做对,得先接受两个事实。第一,断言分两层。据 promptfoo 文档,断言可以是确定性的(deterministic),比如contains、regex、is-json、cost、latency——这些不调用模型、快、免费、可复现,负责守住格式、结构、成本、延迟这类硬约束;另一层是模型评分(model-graded),比如llm-rubric、factuality、g-eval、select-best,用一个裁判模型(LLM-as-a-judge)去判断答案是否切题、是否符合事实、语气是否达标这类主观质量。硬约束能挡住的问题就别交给裁判模型,先用确定性断言兜住下限,再用模型评分覆盖它够不着的语义层。第二,模型评分天生是非确定性的,所以门禁不能要求每次都满分。promptfoo 的llm-rubric支持一个 threshold 属性:输出得分需大于等于阈值才算通过。文档里的说法很直白——之所以用阈值而不是全有或全无,是因为模型评分本身有噪声,要求每轮都 100% 只会得到不断闪烁的构建(flaky build)。把温度设为 0 能提高可复现性,但据多份资料,供应商并不保证零温度下的严格确定性,一次静默的版本升级就能在一夜之间重置你的基线。因此稳健的做法是把单点分数换成分布。据公开的评测实践资料,对波动较大的输出,常见做法是每条用例采样 N 次(5 到 10 是常见区间),看分数分布,再用多数投票或 best-of-N 之类的方式聚合。一个直观的判据是:某条用例在 10 次运行里得 0.78±0.04 属于健康波动,而 0.78±0.25 则是在告诉你底层系统不稳定——这种用例本身就不该进门禁,它只会制造假警报。这套判断的定位其实是变更上线前的最后一道观测,和灰度、影子流量是同一层防线;如果你需要一份把影子期该看哪些指标、放行条件怎么定列清楚的上线前 dry-run 与影子期核对清单,可以直接照着把评测这一环嵌进去,而不是每次临时拍脑袋。落地:把评测配置化,再接进 CI 的退出码promptfoo 的接入之所以轻,是因为它在断言失败时返回非零退出码——CI 里本质上就是跑命令、看退出码两行活。核心是一个promptfooconfig.yaml,把提示词、模型、数据集、断言都声明成版本化、可评审的契约:# promptfooconfig.yamlprompts:-file://prompts/support_reply.txt# 被测提示词,纳入版本管理providers:-id:openai:gpt-4o-mini# 泛指:此处写你实际用的模型config:temperature:0# 提高可复现性,但不假设严格确定tests:-vars:question:我的订单一直没发货,能退款吗?assert:-type:is-json# 确定性:结构必须合法-type:containsvalue:退款-type:llm-rubric# 模型评分:主观质量value:回答需明确给出退款条件与下一步操作,语气礼貌不敷衍threshold:0.8# 得分 0.8 才通过,给噪声留余地这里的tests就是所谓的黄金数据集(golden dataset)——它不是拍脑袋编的,而应从真实失败样本里沉淀。推荐的演进路径是:先用一个配置文件加少量llm-rubric用例起步,之后每抓到一个线上 bad case 就补一条进去,让数据集随真实失败长大。接进 CI 的关键是哪些改动该触发评测。据公开实践,凡是碰了提示词、模型版本或检索配置的 PR,都应对黄金数据集跑一遍,回归超过容忍阈值就不许合并:# .github/workflows/eval.yml 片段on:pull_request:paths:[prompts/**,promptfooconfig.yaml,retrieval/**]jobs:eval:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4-run:npx promptfoolatest eval-c promptfooconfig.yaml--no-cache# 断言失败 - 非零退出码 - job 失败 - PR 被挡需要提醒一点:很多文章会教你去解析结果 JSON 里stats.successes/stats.failures来做更细的门禁逻辑,这条路可行,但字段路径请以官方 CI/CD 文档为准再抄,别照搬博客里的老结构。边界与取舍:阈值不是一天能定的,裁判也会漂这套机制不是免费的,几个取舍必须提前想清楚。其一,阈值需要数据喂养。据评测实践资料,合理的阈值来自校准集和历史运行,团队通常需要积累几周的评测数据,回归门禁才真正可靠;一上来就卡死一个数字,要么频繁误杀、要么形同虚设。其二,裁判模型自己会漂移,也需要被校准。模型评分要定期对齐人工标注,否则你用一个在变的尺子去量另一个在变的系统,分数波动到底来自被测对象还是裁判,根本分不清。把裁判模型的版本也钉住、纳入变更评审,和钉住被测模型同等重要。其三,成本与延迟。每条用例采样多次、又要额外调用裁判模型,评测本身就是一次不小的模型消费。务实的做法是分层:PR 级别只跑一个小而稳的核心集拦住明显回归,完整的大数据集评测放到发布前或定时任务里,别让每次提交都背上全量成本。技术结论把 LLM 评测接进 CI,本质是把改一句话/换一个模型会不会让质量退化这个原本靠人肉抽查、事后复盘的问题,变成一次提交就能自动回答的统计判断。可落地的最小闭环是四件事:确定性断言守硬约束、模型评分带阈值覆盖语义层、黄金数据集从真实失败里长大、CI 用非零退出码挡住越过容忍度的回归。真正决定这套系统有没有用的,不是工具选型,而是三个持续动作——数据集是否在积累、阈值是否经过几周校准、裁判模型是否定期对齐人工标注。工具能在十分钟内接好,可信的门禁得靠这三件事养出来。