选模型前先做可复现性验证：单次pass rate不足以决策

选模型前先做可复现性验证：单次pass rate不足以决策 | 前端进阶之旅

Full translation

完整中文译文

第一个将可用模型路由与 Demo 区分开来的数字，是 temperature 设为 0 时五次相同调用的精确匹配一致率。当这个数字低于 1.0 时，下游通过率测量的更多是采样方差而非模型能力。当前的模型讨论往往会跳过这个检查：团队把新端点对准评估集，读一个通过率，然后合并。这个单一数字无法告诉你这条路由是否能在两次调用时产生相同的结果。

Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free model access and free server option make the harness below easier to run without a local GPU, but the method is provider-agnostic. MonkeyCode's operator describes the current free access as 30,000,000 tokens plus a free server option; the exact allowance changes, so verify it before you commit CI minutes.

一次全栈模型变更需要三层保障：固定的任务契约、消耗预算，以及fail-closed 阈值。契约是一个 JSONL 文件，其预期输出足够稳定以支持断言。预算是在允许路由变更前允许的最大 token 消耗量。阈值是重复运行一致性，而非单次 best-of-n 分数。Best-of-n 是一个优化流程，它通过预选「幸运答案」来隐藏方差。部署决策应该基于同一契约下输出的分布。

上述阈值是起点，而非通用规则。高风险路由可能需要更高的通过率，而内部草稿功能如果没有任何写入路径，则可以容忍更大的方差。

五次运行门禁实际测量的是什么

五次运行门禁是一个分布检查，而非质量基准。如果一个模型从同一输入返回三个正确的 JSON 对象和两个不同的 JSON key，失败就是集成失败：下游解析器会遇到契约违反。单次基准运行可能完全跳过那个 case。重复运行同一契约可以使故障在到达用户流量之前就被观察到。

Temperature 0 并不能保证跨提供商的可确定性。硬件、批处理和服务器端变更仍可能影响输出。这就是为什么门禁将任何不一致都视为信号，而不是等到完整基准测试失败。假阴性的成本是一次被阻止的部署。假阳性的成本是一条有时返回不同契约的生产路由。

以下脚本假设一个 OpenAI 兼容的聊天补全端点。它读取 cases.jsonl，对每个 case 运行五次，跟踪 token 使用量，并在门禁失败时以非零退出。

import json
import os
import statistics
import time
import httpx

BASE_URL = os.environ['BASE_URL']
MODEL = os.environ['MODEL']
API_KEY = os.environ.get('API_KEY', '')
RUNS = int(os.environ.get('RUNS', '5'))
TOKEN_BUDGET = int(os.environ.get('TOKEN_BUDGET', '500000'))

with open('cases.jsonl') as f:
    cases = [json.loads(line) for line in f]

passed = 0
used = 0
rows = []
for case in cases:
    answers = []
    latencies = []
    for _ in range(RUNS):
        started = time.perf_counter()
        response = httpx.post(
            f'{BASE_URL}/chat/completions',
            headers={'Authorization': f'Bearer {API_KEY}'},
            json={
                'model': MODEL,
                'temperature': 0,
                'messages': [
                    {'role': 'system', 'content': 'Return only the JSON object requested.'},
                    {'role': 'user', 'content': case['prompt']},
                ],
            },
            timeout=60,
        )
        response.raise_for_status()
        body = response.json()
        content = body['choices'][0]['message']['content'].strip()
        usage = body.get('usage') or {}
        used += usage.get('total_tokens') or (
            usage.get('prompt_tokens', 0) + usage.get('completion_tokens', 0)
        )
        answers.append(content)
        latencies.append(time.perf_counter() - started)

    expected = case['expected'].strip()
    exact = sum(1 for answer in answers if answer == expected)
    rows.append({
        'id': case.get('id'),
        'exact_agreement': exact / RUNS,
        'median_latency_ms': round(statistics.median(latencies) * 1000, 1),
        'max_latency_ms': round(max(latencies) * 1000, 1),
        'distinct_answers': sorted(set(answers)),
    })
    if exact == RUNS:
        passed += 1

report = {
    'tasks': len(cases),
    'passed': passed,
    'pass_rate': passed / len(cases),
    'token_used': used,
    'budget': TOKEN_BUDGET,
    'budget_exceeded': used > TOKEN_BUDGET,
    'rows': rows,
}
print(json.dumps(report, indent=2))

if passed != len(cases) or used > TOKEN_BUDGET:
    raise SystemExit(1)

这个脚本是有意严格的。对于开放式任务，请将精确匹配替换为归一化断言或 embedding 阈值，并使通过率为小数而非分类值。重要的属性是门禁可以在没有人工重读每个输出的情况下失败。

免费服务器适合在哪里使用

你应该在新的路由成为依赖项之前运行这个门禁。如果你已有基线端点，先针对它执行脚本以捕获基线分布。然后将 BASE_URL 指向免费服务器选项，使用免费 token 配额来评估候选模型，而无需借用生产配额。保持服务器只读，不要将其附加到用户流量。

免费服务器最有价值的地方是运行与生产最终会使用的相同契约。如果测试工具指向不同的 prompt 集，你测量的就不是路由边界，而是 Demo。

局限性和谁应该跳过此方法

精确匹配不适用于高熵创意输出。请改用基于断言的回归集。

五次运行是一个小样本。如果罕见的不稳定问题很重要，请增加 RUNS 或每晚运行门禁。

Temperature 0 不能保证确定性。提供商仍可能通过批处理或后端变更来改变输出。

免费层和免费服务器不应取代生产容量、重试策略或可观测性。

如果任务没有稳定的参考契约，请跳过此方法；方差门禁需要一个稳定的预期输出。

从五个稳定的 case 开始，而不是五十个 prompt。当门禁能够在新模型到达路由边界之前 fail-closed 时，它才开始有用。只有当你喂给它固定契约和预算时，免费服务器选项才有帮助；否则你仍在采样。