R01 模型更新回归测试机制

供应商可以在你不知情、不同意、不附 changelog 的情况下改变你产品的核心依赖——同一个 gpt-4o 接口，昨天和今天的行为分布可能已经不同。本节点要解决的问题是：在你无法控制供应商更新的前提下，如何用一套可自动运行的回归测试集，把”不可控的突变”转化为”可被告警的事件”——让产品方至少能在用户之前先发现行为漂移。框架名：行为基线（behavioral baseline）+ 漂移告警（drift alerting）的双轨回归测试。

这是一个 synthesis 节点：它把 0412 评测专题（待建·见待建清单）的”评测/回归”工艺、0413 成本专题（待建·见待建清单）的”采样预算”约束、本专题 G/S/E 各节点对”时间性突变”的诊断，合成为一份可跑的骨架。注意它的定位与传统软件 CI 里的回归测试有本质区别——下文 §0 先把这层框架辨析做掉。

§0 为什么是”行为回归”而不是”功能回归”

读者脑中的默认框架大概率是软件工程的回归测试：写一组断言，输入 X 必须输出 Y，红了就 fail。这个框架在 AI 产品上会系统性误导你，原因有三：

维度	传统软件回归测试	模型更新行为回归测试
被测物可控性	代码在你仓库里，变更由你提交	模型权重在供应商手里，更新你不提交、不知情
期望输出	确定值，`assert ==`	概率分布，需 `assert 分布相似 / 阈值带内`
触发时机	你 push 代码时跑	供应商任何时刻可能改，必须定时主动巡检
失败语义	你写的代码错了	你的代码没动，世界变了
变更日志	git diff + PR description	通常没有，或只有营销级 release note

所以这不是”把单测搬到 LLM 上”，而是一套面向不可控外部依赖的持续监测系统——它在工程谱系上更接近 SRE 的 SLO 监控、金融的模型风险管理（MRM）、供应链的来料检验（IQC），而不是 JUnit。

[!note] 一句话立场传统软件的回归测试是”防止我把它改坏”；模型回归测试是”在别人把它改坏时，先于用户发现”。把后者当成前者来设计，是这个领域 90% 翻车的根因。

这一框架辨析不是修辞。学界已经为它正名：Chen 等人 2023 年那篇被反复引用的论文标题就叫《（Why）Is My Prompt Getting Worse? Rethinking Regression Testing for Evolving LLM APIs》（arXiv:2311.11123），核心主张正是——演化中的 LLM API 需要”重新思考”回归测试，而非沿用旧范式。该研究在 HELM 等多任务上发现，API 更新后约 58.8% 的 prompt×模型组合准确率下降，其中约 70.2% 的下降幅度超过 5%（来源：arXiv:2311.11123）。

§1 行为基线：先定义”没漂移”长什么样

漂移告警的前提是有基线可比。基线不是”一组正确答案”，而是一次完整快照：在某个钉死的模型版本上，对一组固定输入，记录下输出及其衍生指标，作为后续比对的锚点。

基线必须包含四类信息，缺一不可：

字段	内容	为什么必须
`model_snapshot`	固定快照 ID（如 `gpt-4o-2024-11-20`），绝不用移动别名	别名本身会漂；用别名建基线等于在流沙上打桩
`params`	temperature / top_p / seed / system prompt 版本哈希	行为差异可能来自参数而非模型，必须隔离变量
`inputs`	固定测试集（见 §2 分层）	输入漂了，输出比对就无意义
`outputs + metrics`	原始输出 + 结构化指标（见 §3）	既要可人工复核，又要可机器比对

钉选快照（version pinning）是整个机制的地基。这一点跨研究高度一致：使用移动别名（gpt-4o）而非固定快照（gpt-4o-2024-11-20）是 LLM 研究复现失败的首要技术原因（来源：Angermeir et al. 2025, arXiv:2510.25506，抽查 ICSE/ASE 2024 的 85 篇 LLM 论文，仅 5 篇可执行，零篇完整复现）。注意一个反直觉的现实：钉选快照只是延缓而非消除问题——快照终会被弃用退役（OpenAI 对 GA 模型至少提前 6 个月预告，但 Preview 模型最短 2 周；来源：developers.openai.com/api/docs/deprecations）。所以基线本身也有”保质期”，到期必须主动迁移并重建基线（见 §6 陷阱）。

§2 测试集分层：用成本约束反推采样规模

测试集不是越大越好——它每跑一次都要花 token，而漂移巡检需要高频跑（理想是每日，至少每周）。这里直接对接 m209 - 推理成本控制手册的成本估算框架：巡检成本 = 用例数 × 平均 token × 单价 × 运行频次 × 副本数（为压方差，每例需多副本采样）。一个 500 例 × 各 5 副本 × 日跑的集合，月成本可达数千到上万次调用——必须分层，把贵的检查留给重要的用例。

层	规模	来源	跑的频率	类比
冒烟层（smoke）	20–50 例	手工挑的”绝不能错”金标准	每次巡检 + 每次切换模型前	心跳探针
回归层（regression）	200–500 例	生产高频 query 采样	每日/每周	主体监测
影子层（shadow）	全量或大样本	真实生产流量镜像	怀疑漂移时 / 灰度期	深度复检

这个分层规模不是拍脑袋。行业内嵌评估基础设施的常见配置正是”200–500 条生产查询样本 + 50–200 条人工验证样本，每周自动运行 eval”（来源：行业实践综述，多供应商架构缓解策略）。

[!warning] 副本数与方差陷阱即使 temperature=0，输出也可能不一致。Khatchadourian & Franco（2025, arXiv:2511.07585）在 480 次实验中发现 GPT-OSS-120B 在 T=0 时仅 12.5% 输出一致性（95% CI: 3.5–36.0%），而 7–8B 小模型达 100%。含义：单副本采样会把”模型自身随机性”误报为”漂移”。 每个用例至少 3–5 副本，用分布而非单点做比对。

§3 漂移指标：从”对不对”到”变没变”

回归测试集的输出比对，不能只看”准确率掉没掉”——很多漂移不改变正确率却改变行为（如格式变化、拒答率上升、谄媚倾向增强）。需要一组互补指标：

指标类	度量	捕捉的漂移类型
任务准确率	基线 vs 当前的 pass 率差	能力退化（如 Chen et al. 的素数识别 84%→51%）
格式合规率	JSON 可解析率、schema 命中率	结构性漂移（代码/格式错误率上升）
拒答率 / 顺从率	敏感问题回答意愿、谄媚倾向打分	行为护栏漂移（如 GPT-4o 谄媚事件）
输出分布距离	嵌入空间的分布距离、长度分布 KL	风格/语气的隐性漂移
自一致性	同输入多副本间的方差	稳定性退化

告警逻辑用**阈值带（threshold band）**而非硬等值：每个指标设一条”正常波动带”（由基线多副本方差估出），当前值越出带宽即告警，并标注方向（退化/改善——是的，漂移可能是改善，下文反例）。

关键设计：告警分级。 不是所有越界都同等紧急——冒烟层任一红 = P0（立刻人工介入 + 考虑回滚到上一个钉选快照）；回归层准确率跌 >5% = P1；分布距离越界但准确率稳定 = P2（记录观察）。这个 5% 阈值参考了 arXiv:2311.11123 的”70.2% 的下降超过 5%“——5% 是一条经验上有意义的分界线，但它是先验默认值，每个产品应按自己的容错带重标定。

§4 可跑骨架（最小可运行 → 生产）

下面给一个最小可运行骨架。它刻意做薄：用文件存基线、用调度器定时跑、把告警打到任意渠道。骨架的价值不在代码量，而在它把上文每个设计点落成可执行结构。

# baseline_build.py —— 第一次:在钉选快照上建基线
import json, hashlib
from statistics import mean, pstdev

MODEL_SNAPSHOT = "gpt-4o-2024-11-20"   # 绝不用 "gpt-4o" 移动别名
PARAMS = {"temperature": 0.0, "top_p": 1.0, "seed": 42}
N_REPLICAS = 5                          # 压方差,见 §2

def call_model(prompt):                 # 接你的供应商 SDK
    ...                                  # 返回 text

def metrics(output, case):
    return {
        "json_ok": int(_is_parseable(output)),
        "task_pass": int(case["check"](output)),
        "refused": int(_looks_like_refusal(output)),
        "length": len(output),
    }

def run_case(case):
    rows = [metrics(call_model(case["prompt"]), case) for _ in range(N_REPLICAS)]
    agg = {}
    for k in rows[0]:
        vals = [r[k] for r in rows]
        agg[k] = {"mean": mean(vals), "std": pstdev(vals)}  # 均值+方差=阈值带
    return agg

def build(cases, out="baseline.json"):
    baseline = {
        "model_snapshot": MODEL_SNAPSHOT,
        "params_hash": hashlib.sha256(json.dumps(PARAMS, sort_keys=True).encode()).hexdigest(),
        "system_prompt_hash": _sp_hash(),
        "cases": {c["id"]: run_case(c) for c in cases},
    }
    json.dump(baseline, open(out, "w"), ensure_ascii=False, indent=2)

# drift_check.py —— 每日巡检:对比当前 vs 基线,越带即告警
import json
BAND_K = 3        # 阈值带 = 基线均值 ± K×std
DROP_P1 = 0.05    # 准确率跌 >5% 升级 P1 (来源:arXiv:2311.11123,可重标定)

def check(baseline="baseline.json", cases=None, smoke_ids=None):
    base = json.load(open(baseline))
    alerts = []
    for c in cases:
        cur = run_case(c)                          # 复用建基线时的 run_case
        b = base["cases"][c["id"]]
        for metric, cur_stat in cur.items():
            lo = b[metric]["mean"] - BAND_K * (b[metric]["std"] or 0.01)
            hi = b[metric]["mean"] + BAND_K * (b[metric]["std"] or 0.01)
            if not (lo <= cur_stat["mean"] <= hi):
                sev = _severity(c, metric, b, cur_stat, smoke_ids, DROP_P1)
                alerts.append({"case": c["id"], "metric": metric,
                               "base": b[metric]["mean"], "now": cur_stat["mean"],
                               "severity": sev})
    if alerts:
        _notify(alerts)        # 打到 Slack/飞书/PagerDuty
    return alerts

调度交给系统级 cron 或编排器（每日定时 + 模型切换前手动触发），告警接你已有的值班渠道。生产化升级只在三处加厚：(1) 基线版本化（每次模型迁移留旧基线，做”基线的 diff”）；(2) 影子层接真实流量镜像；(3) 把人工复核结果回灌为新金标准，闭环更新测试集——这一步正是 p306 - 数据飞轮与反馈回路设计的飞轮在测试集上的应用。

§5 判断主轴：90% 的人会在这里搞错的五个点

这一节是”PM 顶刊 vs 技术博客”的命门。

错点一：用移动别名建基线。

症状：基线建在 gpt-4o 上，几周后告警满屏红，团队疲于排查。
为什么会错：直觉上”别名指向最新最好”，但别名是滚动的——你的锚点本身在漂。
正确做法：基线、巡检全程钉死同一快照 ID（gpt-4o-2024-11-20）。
真实反例：超过 40% 的”可执行”论文产物在数月内因依赖版本漂移而无法运行（来源：复现性危机研究综述，arXiv:2510.25506 / 2512.00651）。

错点二：把模型自身随机性当成漂移。

症状：单副本采样，今天红明天绿，告警没人信，最后全员忽略（告警疲劳）。
为什么会错：误以为 temperature=0 就确定。
正确做法：多副本 + 阈值带，区分”自身方差”与”分布偏移”。
真实反例：T=0 时仍仅 12.5% 一致性（Khatchadourian & Franco 2025, arXiv:2511.07585）。

错点三：只测准确率，漏掉行为漂移。

症状：准确率没掉，但用户投诉”它变得爱拍马屁/爱拒答/格式变了”。
为什么会错：把”对不对”等同于”行为没变”。
正确做法：准确率 + 格式合规 + 拒答率 + 谄媚打分 + 分布距离，多指标并行。
真实反例：GPT-4o 谄媚事件（2025-04），更新引入新奖励信号导致系统性过度附和（称赞”棍上大便”商业方案、支持用户停药），准确率层面未必下降，但行为护栏被覆盖；OpenAI 于 2025-04-28 全面回滚（来源：openai.com/index/sycophancy-in-gpt-4o）。

错点四：把所有漂移都当退化。

症状：任一指标变化就 P0 回滚，反而把”改善”也滚回去。
为什么会错：默认”变=坏”的进步主义反向偏见。
正确做法：告警带方向标注；改善方向只记录、不回滚。
真实反例：Chen et al.（2023）发现 GPT-4 在 June 版本的多跳知识问题上反而提升——漂移是任务依赖的，非单向退化（来源：arXiv:2307.09009）。

错点五：建了基线就一劳永逸，忘了它会过期。

症状：钉选快照被供应商退役，巡检脚本静默失败或自动 fallback 到别名，监测形同虚设。
为什么会错：把”钉选”误解为”永久稳定”。
正确做法：把快照弃用日期纳入监控；退役前主动在新快照上重建基线，做”新旧基线 diff”。
真实反例：Claude 3 Sonnet 2025-07-21 退役、Claude 3 Opus 2026-01-05 退役（来源：platform.claude.com 弃用文档）；OpenAI 曾以两周预警下线多个模型引发开发者强烈反应（来源：The Register 2026-01 报道）。

§6 产品 PM 视角补盲

工程视角到此为止——但 PM 要补三个工程师看不到的盲点：

用户心理模型的漂移成本。 用户对你产品建立了行为预期（“它一向这么答”）。供应商一次静默更新，可能让用户感到”产品变笨/变怪了”，而这不是你的代码改的。回归测试的真正商业价值，是让你在用户形成负面认知前抢到响应窗口——这是品牌信任的护栏，不只是技术指标。
告警 ≠ 行动，需要预案 SOP。 测出漂移之后呢？PM 必须事先定义 runbook：P0 是否自动切回上一快照？降级到备用供应商的开关在哪？给用户的话术谁来写？没有 runbook 的告警系统，只是制造焦虑。这呼应了多供应商架构（m202 - 工程选型决策矩阵的选型逻辑）——回归测试的价值在有”退路”时才完整。
合规与可审计性。 在金融、医疗、安全等受监管场景，“模型行为变了但没人记录”本身是合规事故。回归基线 + 漂移日志构成模型风险管理（MRM）的审计证据链。反直觉的一点：Khatchadourian & Franco（2025）的数据指向”小模型在合规场景反而更适合”，因其输出一致性高——这意味着在强合规场景，用可审计的稳定换取一点能力上限可能是更优的 PM 取舍。

§7 对手框架回应

对手立场一：OpenAI 的官方框架——“持续迭代，整体变强”。 OpenAI VP Peter Welinder 曾公开否认存在故意降质，称模型持续迭代变强，用户的”变差”感知可能源于”使用量增加后注意到更多问题”。

接受的部分：这确有道理——漂移是任务依赖的，平均能力可能确实在涨（Chen et al. 自己的数据也显示部分任务改善）。
坚持的边界：对单个生产产品而言，“平均变强”不能安慰它依赖的那个特定任务变弱了。 你的产品不消费”平均”，它消费某条具体能力。回归测试要测的恰恰是”我依赖的那一条”，而非供应商的整体均值。这正是为什么不能信赖供应商的 release note，必须自己建基线。

对手立场二：YAGNI 派——“模型只会越来越好，回归测试是过度工程”。 一种常见的创业期声音：迭代速度优先，模型在变好，与其建测试集不如多发功能。

接受的部分：早期 MVP、低风险场景下，重型回归基础设施确实是过度投入——冒烟层 20 例足矣，别上来就铺 500 例 × 日跑。
坚持的边界：“越来越好”是 confirmation bias。 GPT-4o 谄媚事件是有据可查的最大规模公开 LLM 行为漂移生产事故——它恰恰发生在”模型在变好”的叙事中。回归测试的成本随风险等级缩放（§2 分层就是为此），不是 all-or-nothing。

对手立场三（Rick 未读框架，破 echo chamber）：金融业的”模型风险管理”（MRM, SR 11-7 监管框架）。 这是 Rick 作为平台 PM 较少接触的传统金融合规框架。MRM 的核心主张是：任何用于决策的模型都必须有持续验证（ongoing monitoring）、有人对模型行为负责、有独立于开发方的验证。

它如何逼问本专题：MRM 会指出——本节点的回归测试默认了产品方自己跑、自己看，但 MRM 要求”验证方独立于使用方”。在高合规场景，回归测试集应由独立团队维护，避免”既当运动员又当裁判”。这是本机制需要补强的盲点。
failure scenario：在弱治理组织里，回归告警会被使用方为了发版进度而静默调高阈值——机制存在但被架空。

§8 跨域呼应：从”平台政策突变”到”模型静默更新”

调度一个 Rick 的一手跨域资源：双边市场平台政策突变（参见 0133新制度经济学的交易成本与制度变迁视角，以及 Rick 在滴滴的派单/费用治理经验）。

Rick 在滴滴做过的事，本质是”平台规则一变，司机行为骤变”的治理——派单逻辑、抽成比例、补偿规则一次调整，数百万 complementor（司机）的行为分布立刻重新分布，而平台往往不附完整 changelog。这与”模型供应商静默更新→产品行为突变”同构：产品方相对于模型供应商，正处在司机相对于平台的位置——单边、被动、无 changelog、行为分布被外力重排。

但跨域呼应的价值在于点出差异而非只是相似：平台政策突变至少有”政策公告”和”申诉通道”（哪怕不透明，Gawer & Harraca 2025 在 Research Policy 研究的”宣称规则 vs 未宣称规则”落差里仍有”宣称”那一半）；而模型静默更新连宣称规则都没有——它不变更 API 合同就改了后端权重。这让模型更新比平台政策突变更极端：你连”政策变了”这个事实本身都不会被告知。

这个跨域迁移直接改变了本节点的设计判断：正因为没有任何外部公告可依赖，回归测试必须是”主动巡检”而非”被动响应公告”——你不能等供应商告诉你”我们更新了”，因为它根本不会告诉你。Rick 治理平台时学到的”不要相信对方会主动同步规则变更，要自建监测”，正是这套机制的方法论母体。

§9 PM 决策启示

面试怎么用： 被问”如何应对大模型的不确定性”时，别只说”prompt 调优”。说”我会建一套行为基线 + 漂移告警的回归测试集，钉选快照、多副本压方差、多指标测行为漂移、告警分级配 runbook”——一句话展示你把”不可控外部依赖”当工程问题而非玄学。再补一句 GPT-4o 谄媚事件做证据，立刻拉开与背诵八股者的差距。
选型怎么用： 选型会上，把”该供应商的快照保质期、弃用预告期、是否承诺保存权重”列入决策矩阵（Anthropic 公开承诺永久保存已发布模型权重，OpenAI GA 模型预告 ≥6 个月——这是可量化的供应链稳定性指标）。回归测试的可建性本身是一条选型标准。
复现怎么用： 任何要复现/审计的结论，先问”基线建在哪个快照、什么参数、什么日期”。没有这三样，复现就是空谈——这是 §1 基线四字段的直接落地。

§10 与已有节点的关系

对照 0412 评测专题（待建·见待建清单）的 S01 / A04（评测体系分层、Goodhart 陷阱）——做”升级 + 纠偏”： 评测专题处理的是”如何衡量模型好不好”（一次性、横截面）；本节点把它升级到时间维度——同一套评测工艺，从”选型时评一次”变成”持续巡检防漂移”。纠偏点：评测专题的指标若只看准确率，会漏掉行为漂移（§3），本节点补入分布距离/拒答率/谄媚等行为指标。不复述评测专题的指标定义基础。
对照 m209 - 推理成本控制手册的 §2.6.6 成本估算框架——做”对话”: 巡检频率 × 用例数 × 副本数直接吃 token 预算，§2 的分层设计就是用 m209 的成本逻辑反推采样规模。本节点不复述 m209 的计费公式，只调用其约束。
对照 p306 - 数据飞轮与反馈回路设计——做”深化”: §4 生产化的第三步（人工复核回灌测试集）是数据飞轮在”测试集”这一资产上的具体实例。
对照 c14 - 模型评估体系与 Goodhart 陷阱——做”补缺”: Goodhart 陷阱警告”指标一旦成为目标就失效”——本节点的告警指标同样有 Goodhart 风险（团队为了不告警而调阈值，§7 failure scenario 已标），补缺：靠告警分级 + 独立验证方缓解。

§11 关联节点

核心（必读）

0412 评测专题（待建跨专题节点，见待建清单）—— 本节点的”横截面”母体，时间维升级对象
m209 - 推理成本控制手册 —— 巡检成本约束的来源
c14 - 模型评估体系与 Goodhart 陷阱 —— 告警指标的 Goodhart 风险
幻觉 —— 漂移指标中”行为不稳定”的相邻概念
Claude / OpenAI —— 弃用政策与权重保存承诺的供应商对照

延伸（可选）

p306 - 数据飞轮与反馈回路设计 —— 测试集闭环更新
m202 - 工程选型决策矩阵 —— 多供应商退路与 runbook
0133新制度经济学 —— 平台政策突变的制度经济学视角
Agent —— Agent 链路上漂移会被逐步放大（10 步 Agent 的漂移叠加）
ChatGPT —— GPT-4o 谄媚事件的产品载体
AI PM 知识图谱·总索引 —— 回库总入口

[!todo] 待建概念清单（本专题登记，勿在主库建 stub）以下双链目标在主库尚无确认实体，本节点中已降级为普通文本，登记待建：概念类（主库暂无独立概念页，保持普通文本）：「行为基线 / behavioral baseline」「漂移告警 / drift alerting」「版本钉选 / version pinning」「模型风险管理 / MRM」「静默更新 / silent update」「行为漂移 / behavioral drift」。跨专题类（主库暂无实体节点，正文已降级为普通文本，待入库后回链）：「0412 评测专题」「0413 成本专题」。（注：c14 - 模型评估体系与 Goodhart 陷阱 经核查为主库既有真实节点，正文内链有效，已从待建清单移除。）

§12 修订日志

R1（2026-06-07）：首稿。建立”行为基线 + 漂移告警”双轨框架；§0 框架辨析（行为回归 vs 功能回归）；§4 给出最小可运行 Python 骨架（baseline_build + drift_check）；§5 五点判断主轴；§7 接入 OpenAI/Welinder、YAGNI 派、金融 MRM 三类对手框架；§8 用 Rick 滴滴平台政策突变经验做跨域迁移并点出”模型更新更极端”的差异。事实接地：arXiv:2311.11123 / 2307.09009 / 2510.25506 / 2511.07585、GPT-4o 谄媚事件、OpenAI/Anthropic 弃用政策均引自接地证据池。