换用新模型前，先用历史失败用例回归测试

dev.to · AI#模型评估#Prompt工程#AI编程

Editor brief · 编辑速览

建议用积累的真实失败用例（回归集）验证新模型，而非轻信基准测试排名。发布说明不了解你的代码库和错误日志，榜单高分不代表在实际业务场景下不翻车。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

不要因为某个基准测试或发布说明看起来不错就贸然换用更便宜的新模型。先用你已经收集好的真实失败案例回放一个小型回归集，让候选模型先通过这些用例，再对生产环境做任何变更。

声明：本文是 MonkeyCode 产品推广的一部分。MonkeyCode 提供免费模型访问和免费服务器选项，这让在投入预算前运行测试变得很容易。你不一定需要用他们的端点，任何 OpenAI 兼容的 base URL 都可以。

为什么新模型名称是回归触发器，而非替代信号

发布说明的作者不了解你的代码库、错误日志，也不了解那个每隔几周就会提交同一个令人困惑的 bug 的客户。某个检查点在公开排行榜上看起来很出色，却仍然可能在你的应用所依赖的那一个 prompt 上折戟。当 DeepSeek-V4-Pro-0813 或 Gork 4.6 这样的字符串开始流传时，我把它当作一个占位符，而不是事实。真正有用的问题不是排行榜喜不喜欢它，而是它能否通过那些曾经让你栽跟头的用例。

在依赖任何版本号或价格宣传之前，先去原始发布说明或代码仓库核实一下实际发生了什么变化。我通常检查三件事：

什么东西变了：上下文窗口、工具调用、输出风格、分词器行为，还是价格。

我的已知失败类别中哪些可能受到该变化的影响。

旧的回归用例是否仍然代表我需要的契约。

公开基准测试是在受控环境下对模型进行比较。你的回归文件则是将候选模型与你的实际错误进行比较。第二种比较才是能告诉你更低价格是否意味着可以无缝替代的唯一依据。

把真实失败转化为可回放的回归用例

我会在出问题的模块旁边放一个名为 regression_cases.jsonl 的文件。每一行都是一个真实失败，缩减为四个字段：prompt、必要短语或事实、禁用短语，以及 token 限制。

一个有用的用例不是一个完美的基准测试。它是：

一个能复现问题的 prompt
一个 required 列表，迫使你写下正确答案必须包含的内容
一个 forbidden 列表，捕捉通常代价高昂的失败模式
一个可选的 max_tokens，使探测保持廉价且可重复

把文件存为 JSON Lines 格式。例如：

{"id":"stacktrace-to-fix","prompt":"Here is a Python traceback from a small CLI tool...","required":["IndexError","slice"],"forbidden":["rewrite the whole module","delete the function"],"max_tokens":300}
{"id":"sql-null-handling","prompt":"Fix the query builder so it does not drop NULL filters...","required":["WHERE","IS NULL"],"forbidden":["remove the filter","silent ignore"],"max_tokens":250}
{"id":"invoice-date-format","prompt":"Refactor date formatting in invoice export...","required":["ISO 8601","UTC"],"forbidden":["moment.js","local timezone"],"max_tokens":400}

required 和 forbidden 列表故意设计得很粗糙。这种粗糙感正是关键所在：你必须在看到候选模型的输出之前就定义出正确答案的样子。如果你写不出这些列表，说明你还没有把问题定义得足够清晰到可以测试它。

用小型 Python 测试工具运行探测

这个工具会通过 OpenAI 兼容端点回放每个用例。它调用 chat completions API，设置较低的 temperature 以获得更可重复的输出，并用 time.perf_counter 记录墙上时钟秒数。

import json, time, os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ['MODEL_BASE_URL'],
    api_key=os.environ.get('MODEL_API_KEY', 'not-needed'),
)

CASES = 'regression_cases.jsonl'
MODEL = os.environ.get('MODEL_NAME', 'deepseek-v4-pro-0813')

def load_cases(path):
    with open(path) as f:
        return [json.loads(line) for line in f if line.strip()]

def run_case(case, model=MODEL):
    start = time.perf_counter()
    response = client.chat.completions.create(
        model=model,
        messages=[{'role': 'user', 'content': case['prompt']}],
        temperature=0.2,
        max_tokens=case.get('max_tokens', 600),
    )
    text = response.choices[0].message.content or ''
    elapsed = time.perf_counter() - start
    return text, elapsed

def evaluate_case(case, text):
    required = case.get('required', [])
    forbidden = case.get('forbidden', [])
    missing = [r for r in required if r.lower() not in text.lower()]
    leaked = [r for r in forbidden if r.lower() in text.lower()]
    ok = not missing and not leaked
    return {'ok': ok, 'missing': missing, 'leaked': leaked}

def main():
    cases = load_cases(CASES)
    passed = 0
    for case in cases:
        text, elapsed = run_case(case)
        verdict = evaluate_case(case, text)
        if verdict['ok']:
            passed += 1
        print(json.dumps({
            'id': case.get('id'),
            'passed': verdict['ok'],
            'seconds': round(elapsed, 2),
            'missing': verdict['missing'],
            'leaked': verdict['leaked'],
        }))
    print(f'{passed}/{len(cases)} passed')

if __name__ == '__main__':
    main()

export MODEL_BASE_URL='https://your-openai-compatible-endpoint'
export MODEL_NAME='candidate-model-name'
python regression_probe.py

当 required 短语缺失或 forbidden 短语泄露时，脚本会打印失败判定。这不是一个语义神谕，这是有意为之。这些检查足够弱，所以透明；也足够强，所以能捕捉到那些让模型替换代价高昂的失败：一个模型避开了错误、建议重写整个模块，或者编造了一个不存在的函数。

先看失败，再看通过率，然后决策

候选模型可以通过九个简单用例，却仍然在那个关键的用例上失败。我先看失败。例如输出：

{"id":"stacktrace-to-fix","passed":false,"seconds":0.87,"missing":["IndexError"],"leaked":["delete the function"]}

这告诉了我一些具体的东西：候选模型避开了那个特定的异常，并建议删除函数。这是推迟更换的理由，而不是感觉。如果所有用例都通过了，我仍然保留回归文件，并把每一个新失败都加进去，因为下一个版本号会在我记得旧版本为什么失败之前就到来。

局限性和谁应该跳过

这个探测是第一层过滤器，不是发布关卡。

工具只了解你喂给它的东西，所以它可能过拟合旧的失败，而漏掉那些你还没见过的失败。

required 和 forbidden 检查是词法层面的，所以它们可能让一个碰巧包含正确词汇但结构很差的答案通过。

免费服务器上的计时测量对粗略比较有用，对精确基准测试没有意义；环境、队列和模型路由可能在运行之间发生变化。

除非你已经检查了数据处理条款，否则不要向任何端点发送私人客户数据。这不是一个安全或合规关卡。

如果你的产品需要精确的输出契约、确定性格式或可审计的推理，请将这个探测与适当的评估集和人工审查配对使用。

如果你是仅为周末项目在两个公开模型之间做选择，如果你的应用还太新而无法收集真实失败用例，或者你需要评估一个受到严格监管的工作流，那就跳过这种方法。廉价探测适用于中间地带：你有一个在线项目、一堆过去的错误，以及一个想要相信更低价格就意味着无缝替代的诱惑。

下一步：在下一次模型更换前回放五个失败

从上月选取五个失败。把它们放进 regression_cases.jsonl，用当前模型和候选模型分别运行测试工具，然后在打开 Pull Request 之前比较失败情况。如果一个便宜的新模型通过了那些曾经让你栽跟头的用例，这是一个比排行榜数字好得多的信号。如果没有，你就让自己从一个非常无聊的事故中拯救出来了。