2026 年自定义 LLM 的自动化回归测试

发布周期笔记 —— 第 7 部分

周五下午 4:47,你提交了一个仅一字符的提示词微调。聚合评估得分从 0.873 变为 0.871 —— 完全在噪声地板之内。周一早上,你的客服队列被一类查询点燃了 —— 半年前你停止关注这类查询,因为它们一直很稳定。

模型没有任何回归。模型还是同一个模型。是评估自身从你脚下漂走了。 半年来某个客户细分群体的缓慢增长从未进入黄金数据集;评判器提示词上一次针对人工标注校准是十月份;检索索引上周三在一个刷新过的嵌入模型上悄悄重建了自己。

这正是第 6 篇所指出的 —— 大约每七次告警中只有一次,模型才是正确答案。这意味着你的回归测试套件必须能够检测套件自身的漂移,而不仅仅是模型的漂移。本文就是这套套件。

自定义 LLM 的回归测试究竟是什么?

软件回归测试断言:对于固定输入,output == expected。它们能工作,是因为函数是确定性的。

语言模型在同样的意义上并不是函数。同一个提示词在 temperature > 0 时会产生一个有效补全的分布,而“有效”是多维的:它有没有回答问题、答案是否扎根于检索到的上下文、有没有停留在安全边界之内、有没有在延迟预算内返回。所以对自定义 LLM 做回归测试意味着 测量行为分布对照一个冻结的基线分布 —— 跨越对你有意义的切片,使用经过人工校准的评判器,并基于看起来像生产流量的输入进行测量。

在这一切真正有意义之前,有三件事必须就位:

1. 一个 黄金数据集,在切片层面而不仅是聚合层面上与生产相似。
2. 一个 经过校准的评判器 —— 不是“我们用 GPT-5 当评判器”,而是“我们测得对照三位人工评分者的 Spearman ρ ≥ 0.7,上周刚刚刷新过”。
3. 一份 基线清单 —— 那些得分对应的精确模型权重、提示词模板、检索索引和评判器版本。如果没有这个,你就无法分辨得分变动是因为模型变了还是因为尺子变了。

Divinci 将这三者作为一等对象运行,通过哈希链接,在每次提交时打分。本文剩余部分就是如何把它们组装起来。

为什么大多数 LLM 回归套件抓不到真正的回归

2026 年自定义 LLM 占主导地位的失败模式,正是 Tianpan 的 Sigma Inference 团队在其 2026 年 4 月事后复盘中命名的 Semver 谎言^[1]:一个聚合指标维持平稳或者改善,而其中一两个生产切片在静默回归。该切片在设计测试时不到流量的 5%,所以从未进入黄金数据集;半年后,它占到流量的 12%,模型在该切片上退化了,而聚合数字永远不可能注意到。

我们查阅了过去十八个月所有公开的 LLM 发布事后复盘,模式不断重复:套件之所以亮绿灯,是因为它在测错的东西。 具体来说:

• 黄金数据集是团队在发布时手工编写的,从未根据偏移后的流量分布重新分层。
• LLM-as-judge 的提示词设置了一次,之后再没有针对人工标签重新校准。评判器一致性悄然衰减^[2]。
• 基线分数以原始数字形式存储,而不是作为 (model_sha, prompt_sha, judge_sha, dataset_sha, score) 元组 —— 所以当某个东西回归时,没人能说清这四个里哪一个动了。

任何回归套件如果没有把这三件事都解决,就只是一个在部署时变绿、给你虚假信心的 CI 步骤。修复方法不是“加更多用例”。修复方法是 每次发布时,按切片感知、按版本锚定、按评判器校准 的测量。

构建一个经得起切片感知分析的黄金数据集

我们默认提供的四桶组成 —— 生产样本 60%、对抗样本 15%、专家精选边界情况 15%、失败回放 10% —— 是合理的起点。真正让它能够抓到回归的,是附加在每个用例上的 切片元数据。

数据集中的每一项都携带:输入、期望行为(评分准则,而非精确字符串)、检索上下文(如有)和一个 slice 标签 —— 领域、用户细分、查询意图、语言、长度区间,任何对你的产品有意义的分解维度。套件 按切片 打分,任何切片只要跌过其阈值就阻塞发布,即便聚合分数上升也不行。

我们已经学会强制执行的两条操作规则:

每季度重采样。 生产流量分布的偏移速度比大多数团队的测量频率更快。我们每个季度都会针对最近 90 天的流量重新分层生产样本桶;如果任何切片增长超过流量的 5% 且在黄金数据集中占比不足 2%,就会在下一次发布前回填进去。

每次事后复盘都新增一个用例。 进入生产却未被捕获的回归,就是数据集中缺失的用例。我们会在事后复盘后 48 小时内将它添加到回放桶中,并打上揭示它的那个切片的标签。

如何在用户之前发现漂移?

漂移有四种截然不同的类型,只盯着最后一种的回归套件,会错过大多数回归。

大多数套件测量的是质量漂移;另外三种才是周五下午回归通常隐藏之处。Divinci 对照基线清单跟踪所有这四种,每个 PR 上都会显示每切片的得分分解,每周还有一项评判器校准任务在漂移累积之前就标记出来。

多维评估 —— 每切片同时打四项分

单一的综合得分比四个标量得分的信号更差。我们在四个维度上进行门控:

• 任务完成度 —— 响应是否真的回答了问题,由经过校准的评判器按评分准则给出。切片感知。
• 忠实度 —— 对任何引用了检索上下文的响应,每条主张是否扎根于该上下文。幻觉首先在这里显现。
• 安全性 —— 拒答正确性、越狱抵抗能力、PII / 政策暴露。几乎总是以 ≥ 0.99 通过率作门控;安全是硬墙,不是软折中。
• 延迟预算 —— 切片 SLA 内的 p95。一次让每响应令牌数翻倍的提示词修改即便质量上升也是回归。

每个维度都有自己的每切片基线和每切片阈值。在门控时我们绝不把它们合并为单一加权标量;我们把每个切片的四项分数都展示出来,并阻塞首先越过其阈值的那一项。一个在医疗切片上以 1 分忠实度为代价换取 4 分任务完成度提升的模型仍然是回归。

哪些门控应阻塞自定义 LLM 的部署?

我们运行三层架构,每一层为流水线中的不同阶段把关(阶段分类参见第 1 篇)。

第 1 层 —— 冒烟测试(每次提交,约 90 秒)。 从影响最大的切片中抽取 20 到 30 个关键用例。在完整套件耗费算力之前捕获灾难性回归。如果冒烟测试失败,其余的不会运行。

第 2 层 —— 完整套件(每个 PR,约 12 分钟)。 完整的黄金数据集,在所有四个维度上按切片打分。针对基线清单的切片感知 Spearman ρ。阈值越线阻塞合并。PR 评论列出哪些切片在哪些维度上移动了多少,并附带五个失败示例用例。

第 3 层 —— 基线对比(发布候选版本,约 25 分钟)。 候选模型针对最近 14 天的生产追踪进行回放 —— 即我们在第 1 篇中提到的 闭环生产追踪回放。对黄金数据集打分的同一个经过校准的评判器也对回放输出打分。任何切片如果回放得分与离线得分相差超过其阈值,就阻塞发布。这一层正是用来捕获黄金数据集尚不知道的漂移的。

在你信任评判器产生的任何一个分数之前,先校准它

LLM-as-judge 是让这一切超越数百个用例规模扩展的关键。它也是回归套件悄然失效的地方,因为评判器在更新或者你的数据分布偏移时,并没有义务保持校准。

我们针对一个冻结的、至少 100 个用例、与黄金数据集相同切片分层的人工标注审计集对每个评判器提示词进行校准,并且每周重新运行校准。我们的上线门槛是 Spearman ρ ≥ 0.7(相对于人工评分者中位数)以及 Cohen’s κ ≥ 0.6(在二分类安全判断上)。两者都高于 MT-Bench 风格评判器被证明能够以人际一致性水平跟踪人工评分者的阈值^[2]。

当每周校准跌破阈值时,评判器会被自动退役,值班评估工程师会被呼叫。发布流水线宁可让候选发布悬而未决,也不基于一个不再测量它原本所测之物的评判器进行门控。

# 运行每周评判器校准任务
curl -X POST https://api.divinci.ai/v1/regression/judges/calibrate \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "judge_id":     "rubric-v7",
    "audit_set":    "human-labels-2026-04",
    "min_spearman": 0.70,
    "min_kappa":    0.60,
    "on_fail":      "retire_judge_and_page"
  }'

Divinci 差异化能力 —— 闭环生产追踪回放

第 3 层门控正是大多数回归套件所没有的部分。流程与我们在第 1 篇所发布的相同,只是为回归测试做了一项专门化:每个发布候选版本都会逐切片地将其在离线黄金数据集上的得分与其在 14 天生产追踪回放窗口上的得分进行比较。黄金数据集测量的是我们 期望 模型做什么。回放测量的是模型 上周实际 会做什么。

当两组分数偏差超过每切片的差距预算时,发布被阻塞。这种不匹配本身就是信号:要么黄金数据集不再具有代表性(覆盖漂移),要么候选模型在由生产预处理与检索塑造的追踪上行为不同(生产漂移)。无论是哪种情况,你都会在用户之前发现。

对离线运行打分的评判器,与对回放运行打分的评判器是同一个。审计日志会记录两组得分、两个评判器版本、被回放的追踪 ID,以及触发阻塞的差距。这个差距本身就是我们拥有的最有用的诊断信号,也是接下来交给负责执行 第 6 篇诊断树 的人的内容。

用 vindex 凭据锚定黄金数据集

如果你之后无法复现,套件里的每一个得分都没有意义。我们在每次发布时对黄金数据集进行哈希,并将该哈希与模型 SHA、提示词 SHA、评判器 SHA 和校准记录一起链入 vindex 凭据。该凭据可外部锚定 —— 审计员可以在六个月后回放我们精确的回归运行并验证我们所声明的分数。

{
  "release_id": "rel_3f1a-2026-05-26",
  "model": { "sha": "0c1f9…", "weights_uri": "r2://models/custom-v7.2", "open_weights": true },
  "prompt": { "sha": "c4a8e…", "template_id": "support-v3.4" },
  "retrieval": { "index_sha": "b21f0…", "embedder": "e5-mistral-7b-instruct" },
  "judge": { "sha": "d8e21…", "rubric_id": "rubric-v7", "spearman_vs_humans": 0.74 },
  "dataset": { "sha": "a90b1…", "n": 512, "slices": 17, "stratified_at": "2026-04-30" },
  "scores": { "aggregate": 0.872, "by_slice": { "/* … */": "/* per-slice scalars */" } },
  "replay": { "trace_window_days": 14, "n_traces": 8430, "max_gap": 0.018 },
  "vindex_anchor": "sha256:f0bfd2…",
  "verifiable_at": "https://vindex.divinci.ai/rel_3f1a-2026-05-26"
}

开放权重说明。 上述凭据仅在模型为开放权重时才携带权重溯源 —— vindex 锚定的是实际的权重字节。对于闭源 API 模型后端(OpenAI / Anthropic / Google 托管模型),凭据仍然携带决策链 —— 每个门控分数、每个评判器结果、校准记录 —— 但权重字段为空,你无法独立验证模型构件。我们在凭据本身和合规文档中都明确这一点,这样审计员不会产生错误印象。能从完整的 vindex 链中受益最多的,是你拥有权重控制权的那些发布。

一个我们实际推行过的四阶段实施时间线

试图在第一周就上线完整架构的团队会卡在工具上。下面的顺序是能行得通的顺序。

阶段 1 —— 基线(第 1 周)。 抽取过去 30 天生产追踪的分层样本。让两位工程师各自对 100 个用例的任务完成度进行人工标注。计算评分者间一致性(目标 Cohen’s κ ≥ 0.6)。你得到的数字就是你的人工基线起点;之后一切都将以此为准进行校准。

阶段 2 —— 评估框架(第 2–3 周)。 在 100 用例数据集上搭建评估框架。加入一个对照你的人工标签校准过的评判器。验证框架能以 ρ ≥ 0.7 重现人工分数。大多数团队会发现他们的第一版评判器提示词通不过,会重写两遍 —— 这很正常。

阶段 3 —— 门控(第 3–4 周)。 将评估框架接入 CI 作为警告,而非阻塞。观察两周。通过观察误报率所发现的阈值,才是唯一能存活下来的阈值。只在误报率低于 5% 时才升级为阻塞。

阶段 4 —— 回放循环(持续)。 一旦门控可靠地阻塞,就启用生产追踪回放层。这是切片覆盖差距浮现的地方,也是每次事后复盘开始向黄金数据集补回用例的地方。

这套体系不能解决什么

三条诚实的局限,与我们在本系列每一篇中的表述一致。

1. 套件漂移是永无止境的工作。 回归测试是基础设施,不是项目。黄金数据集必须每季度重新分层,评判器必须每周重新校准,阈值预算必须每次事后复盘后重新调优。没有任何版本允许你交付一套套件之后就走人。
2. 完美校准的评判器仍然是一个模型。 相对于人工评分者 Spearman ρ = 0.74 意味着大约四分之一的评判器调用与人工中位数不一致。这残余的不一致就是每个得分上的噪声地板。我们在每份发布报告中都明确把它呈现出来;忘记它存在的团队迟早会因此感到意外。
3. 闭源 API 后端限制了你能验证的程度。 使用闭源 API 模型时,回归套件可以测量行为,但无法验证权重溯源。如果你需要完整的可复现性 —— 受监管行业、被审计的部署 —— 这个折中在模型选择上,而不在套件上。

下一篇

第 8 篇是本系列的最后一篇,在 CI 内部收尾闭环。如果本文和第 5 篇讲的是门控处运行什么,那么下一篇讲的就是为门控产生候选版本的 CI 层 —— 合并前评估、对提示词模板的契约测试,以及如何在不让预算破产的情况下为 12 分钟评估套件配置 CI 算力规模。这是支撑我们目前所写一切的工程层。

常见问题

LLM 评估与 LLM 回归测试有何区别?

评估测量模型在某个时间点上、相对于一个绝对评分准则是否达到质量门槛。回归测试测量候选版本是否表现得与冻结的基线一致,按切片、跨多个维度。基线正是它之所以是回归测试的原因 —— Divinci 同时提供两者,而其回归模式会固定 (model_sha, prompt_sha, judge_sha, dataset_sha),这样一个移动的得分就能识别出哪个输入发生了变化。

黄金数据集应当包含多少用例?

比你以为的更少,分层得比你以为的更好。我们曾用 200 个用例、5 个定义良好的切片就提供了有用的回归覆盖,也见过 5,000 用例的数据集因为没有分层而错过一切重要的东西。从 200 个开始,做好分层,然后通过事后复盘逐个增长回放桶。

我应该使用人工评审还是 LLM-as-judge?

两者都要,由人工来校准评判器。人工跟不上发布周期 CI 门控所需的打分体量。评判器填补体量,人工校准评判器 —— 每周用 Spearman ρ ≥ 0.7 衡量。任何一者单独使用都是一种失败模式。

如何为非确定性输出做测试?

对分布而不是字符串打分。使用评判器可以跨多种表达应用的评分准则进行打分,并在 temperature > 0 的条件下对每个输入运行 3 到 5 次,这样切片感知的得分就是一个补全分布上的得分,而不是单一样本。仅对确实需要确定性输出的用例(结构化输出工具调用、分类)收紧温度。

对第一道 CI 质量门控,我应当优先采用哪些指标?

任务完成度和一道安全门控。两者都按切片。在前两者校准之前增加更多维度会产生噪声;部署更多维度的团队最终通常以噪声为基础进行门控。在开启检索后再增加忠实度;在前两者稳定后再增加延迟。

参考资料

1. Pan, Tianpan. "The Semver Lie: how a minor LLM update broke production." 29 April 2026. The named 2026 failure mode for slice-aware regression analysis; aggregate scores hold flat while a low-volume slice silently regresses.
2. Zheng et al. "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685. Empirical evidence that strong LLM judges agree with human raters at roughly inter-human-agreement levels (≈ 80%) on open-ended tasks, with reported failure modes that calibrate-against-humans audits are designed to detect.
3. Kirkpatrick et al. "Overcoming catastrophic forgetting in neural networks." PNAS / arXiv:1612.00796. The foundational result on catastrophic forgetting in fine-tuned neural networks — why a fine-tuned custom LLM has to be regression-tested for general capability loss, not just gain on the target task.
4. Amazon Web Services. "SageMaker Deployment Guardrails — blue/green deployments and canary monitoring." The closed-API contrast: gates on infrastructure metrics (latency, errors, CPU) rather than on per-slice semantic quality.
5. Spearman, C. "The proof and measurement of association between two things." American Journal of Psychology, 15(1):72–101, 1904. The rank-correlation coefficient that anchors the slice-aware gate — robust to scoring-scale drift in the judge, which is the property we needed.
6. DORA / Google Cloud. "Accelerate State of DevOps — change-failure-rate and time-to-restore-service metrics." The cross-industry baseline for "how often deploys cause incidents" and "how fast you recover." Regression suites that block at the gate move the first metric down; instant rollback ([post 5](/zh/blog/automated-llm-ci-cd-pipelines-with-instant-rollback/)) moves the second.