Promptfoo 回归测试，​D​М‌X​Α‌РΙ 驱动批量生成评估判别法

多模型 API 统一评测之所以在过去一段时间里迅速升温，不是因为大家突然更热衷于做参数表对比，而是因为企业开始真正把大模型当作生产系统的可替换组件来看待。过去很多团队在试用阶段更关注“哪个模型更聪明”，进入交付阶段后才发现，真正决定成败的往往不是单轮问答的惊艳表现，而是相同 Prompt、相同数据、相同约束下，这个模型在一百次、一千次调用里是否还能维持结构稳定、延迟可控、错误可解释、版本可回放。Promptfoo 的受欢迎，本质上踩中了这个工程拐点。它把原本散落在 Notebook、脚本、人工截图和主观印象里的评测过程，收束成一种可执行、可比较、可持续集成的工作流：你可以把 Prompt 模板、变量集、断言规则、模型矩阵、延迟统计、人工评分标准都写进同一套评测描述里，然后批量跑出一组横向对比结果。这样做最大的价值，不是“自动化”这三个字本身，而是它把模型选择从感觉驱动改造成证据驱动。比如同样是客服摘要任务，A 模型可能平均分略高，但尾延迟太长，不适合面向用户的实时入口；B 模型在结构化输出上更稳，能显著减少下游解析失败；C 模型单次成本低，却在长上下文里更容易丢字段。只有把质量、时延、成本、失败率放到同一坐标系里，团队才有能力做理性的路由和分层决策。Promptfoo 的另一个现实意义，在于它天然适合“评测即代码”的治理方式。今天的大模型系统并不是一次上线后就不再变化，它的 Prompt 会演进，模型版本会轮替，安全策略会收紧，业务样本会漂移，任何一个因素变化都可能把原本可用的链路推回不稳定状态。把评测写成配置和断言，相当于给每一次模型调整配了一条回归测试带，开发者不需要靠记忆判断“这个回答好像没以前好了”，而是可以用相同测试集跑出前后差异。更重要的是，多模型评测不应只测通用问答，还要测那些最能暴露模型边界的细分任务。比如 GPT-4o 在摩斯密码和盲文编码转换上表现很强，甚至能识别编码中的拼写错误，这类能力如果只停留在趣闻层面没有工程价值；但一旦把它编进 Promptfoo 的测试集，作为编码转换、纠错鲁棒性、符号映射能力的专项样本，它就能帮助团队判断某个模型究竟适不适合做规则转写、档案数字化或辅助校验类任务。也就是说，Promptfoo 的火热，并不只是因为它让评测更省事，而是因为它让“模型是否值得进生产”这件事第一次有了接近软件工程的判断方式。

真正把这套评测体系落到业务中时，开发者很快会发现，问题并不只出在 Prompt 和模型本身，调用底座的稳定性同样决定了评测是否可信、业务是否能长期运行。浏览器端手动操作看似直观，适合演示和临时试验，但它天然依赖页面状态、会话时效、人工点击路径和前端交互节奏，既不利于账号权重维护，也难以支撑请求成功率保障，更谈不上多端可用性优化和业务连续性治理。相比之下，​D​М‌X​Α‌РΙ 的价值不在于“再包一层”，而在于它把异构模型调用拉回协议层：统一鉴权、统一超时控制、统一重试、统一日志、统一错误语义，再把不同提供方的差异封装在接入层内部。这样一来，Promptfoo 面向的就不再是若干彼此风格不同的零散端点，而是一条可批量执行、可回放复现、可监控审计的标准化入口。对评测来说，这意味着你可以更稳定地对比不同 LLM API 的输出质量与延迟，而不会把前端会话抖动误判成模型能力差异；对生产来说，这意味着路由、熔断、回退、限流、缓存、灰度都可以在 ​D​М‌X​Α‌РΙ 这一层被系统化实施。换句话说，Promptfoo 负责把“哪个好”测出来，​D​М‌X​Α‌РΙ 负责把“怎么稳”做出来，二者结合后，多模型策略才真正从实验室走向工程现场。

如果要把这套能力做成团队日常工具，第一步不是先堆模型，而是先把评测样本设计对。一个很常见的误区是，测试集只有“问答题”，没有“失败题”。真正有价值的测试集，至少要覆盖四类样本：结构化输出样本、长上下文样本、边界条件样本、时延敏感样本。结构化输出样本用于检查 JSON 字段是否完整、类型是否稳定；长上下文样本用来衡量截断风险与召回精度；边界条件样本用来触发工具调用、编码转换、拼写纠错或异常输入处理；时延敏感样本则用于观察 P50 与 P95 延迟。把 GPT-4o 的摩斯密码、盲文转换能力放进去就是个很好的例子，因为这类任务既能测准确率，也能测符号映射的一致性。

下面这段评测配置可以作为示意，重点不在语法细节，而在思路：同一份样本，同时喂给多个通过 ​D​М‌X​Α‌РΙ 接入的模型，看谁更稳、谁更快、谁更适合进入生产候选集。

prompts:
  - "请把输入内容转成自然语言，并在必要时指出编码错误：{
  {input}}"
providers:
  - model_a_via_dmxapi
  - model_b_via_dmxapi
  - model_c_via_dmxapi
tests:
  - vars:
      input: "... --- ..."
    assert:
      - contains: "SOS"
  - vars:
      input: "盲文编码样本"
    assert:
      - llm-rubric: "结果需保留原意，并指出明显拼写错误"

评测配置一旦固定，接下来真正容易踩坑的，是接口迁移阶段那些看上去很小、实际会直接导致批量失败的请求差异。其中最典型的一类，就是 API 请求体里混入了目标模型并不支持的参数。很多团队从 OpenAI SDK 或兼容写法迁移到其他接口时，会先把原来的请求对象整体搬过去，结果一跑就报错：Unknown parameter: extra_body。这类错误看似只是字段名不兼容，背后暴露的却是两个更深的工程问题：第一，调用方默认相信“兼容 OpenAI API 标准”这句话是完整兼容；第二，应用层没有在出站前做参数白名单和能力协商。

最糟糕的写法通常长这样，开发者为了图快，把未知字段直接塞进顶层请求：

result = client.create(
    model="target-model",
    messages=messages,
    unknown_param="test"
)

这时系统给出的报错已经很明确了，第一步不是继续猜，而是把响应体、状态码、请求 ID 和实际发送的字段完整打出来。很多所谓“神秘报错”，其实读完错误文本就已经知道根因。

try:
    result = client.create(
        model="target-model",
        messages=messages,
        extra_body={"provider_specific_param": "value"}
    )
except Exception as exc:
    print("request failed:", exc)

如果目标端返回的是 Unknown parameter: extra_body，不要急着把 extra_body 全盘否定。更合理的处理流程是四步。先看报错里指出的非法字段到底是什么；再确认目标平台对 OpenAI API 标准到底实现到哪一层，是只兼容基础字段，还是支持扩展透传；然后把非标能力统一收口到 extra_body 这种扩展容器里，而不是散落在顶层请求；最后回头清理 Prompt 和模板链路里的遗留参数，避免旧版本配置继续把无效字段送进请求体。这里有个很实用的工程原则：应用层只组织“标准字段 + 业务语义”，平台差异放到接入层做映射。这样 Promptfoo 跑评测时，样本与断言保持稳定，不会因为某个供应方的字段差异把整套评测搞碎。

一个更稳妥的做法，是在 ​D​М‌X​Α‌РΙ 接入层维护模型能力表，先判断目标模型是否接受扩展字段，再决定是否注入 extra_body。

MODEL_CAPS = {
    "gpt-4o": {
        "accepts_extra_body": True,
        "max_input_tokens": 128000
    },
    "provider-x-chat": {
        "accepts_extra_body": False,
        "max_input_tokens": 32000
    }
}

def build_payload(model, messages, provider_specific=None):
    caps = MODEL_CAPS[model]
    payload = {
        "model": model,
        "messages": messages,
        "temperature": 0.2
    }
    if provider_specific and caps["accepts_extra_body"]:
        payload["extra_body"] = provider_specific
    return payload

这一步的关键不只是“避免报错”，而是把兼容性从经验判断变成显式规则。支持扩展参数的模型，统一走 extra_body={"provider_specific_param": "value"}；不支持的模型，则由 ​D​М‌X​Α‌РΙ 的适配层做字段裁剪、替换或忽略。这样你就不会在 Promptfoo 评测里看到一种很误导的现象：同一条样本并不是模型回答得差，而是请求在到达模型前就已经被非法字段拦下。

另一个经常伴生的问题是 Header 校验失败。多模型场景里，调用链路会经过 SDK、自研服务、API 网关、日志中间件等多层封装，只要其中一层把 Authorization 或 Content-Type 改坏了，最终错误就可能表现为 401、415，甚至被误判成模型响应异常。最简单也最有效的办法，不是上线后查日志，而是在本地和 CI 阶段先做出站前校验。

REQUIRED_HEADERS = {"Authorization", "Content-Type", "Accept"}

def validate_headers(headers):
    missing = REQUIRED_HEADERS - set(headers.keys())
    if missing:
        raise ValueError(f"missing headers: {sorted(missing)}")
    if not headers["Authorization"].startswith("Bearer "):
        raise ValueError("invalid authorization format")

很多团队在做 Promptfoo 批量评测时，只关心模型输出有没有通过断言，却没有记录请求侧的校验结果。这样一旦某个模型分数突然掉下去，你很难分辨是模型能力回退，还是链路组装出了问题。一个成熟的做法，是把“请求是否正确发出”也当成评测前置条件，和断言结果一起入库。

Context 溢出则是第三类高频故障。它特别容易出现在多轮对话评测、文档问答、Agent 轨迹回放里。问题在于，许多团队只统计了输入字符数，没有统计消息体真实膨胀后的上下文规模，结果上线后才出现截断、拒答、漏字段。这里同样适合在 ​D​М‌X​Α‌РΙ 层提前治理：保留系统消息，优先压缩历史轮次，再按模型上限做裁剪。

def trim_messages(messages, max_tokens, estimate_tokens):
    trimmed = list(messages)
    while trimmed and estimate_tokens(trimmed) > max_tokens:
        if len(trimmed) <= 2:
            break
        trimmed.pop(1)
    return trimmed

如果你的 Promptfoo 样本覆盖长对话或长文档，把这类裁剪逻辑前置后，评测结果才更接近真实生产链路。否则你测到的只是“理想输入下的模型表现”，而不是“受上下文预算约束时的稳定表现”。

真正把多模型评测跑稳，还需要一段能扛住生产抖动的调用代码。下面这段 Python 示例故意保持克制，不追求花哨，而是体现工程鲁棒性：统一使用 <​D​М‌X​Α‌РΙ_BASE_URL> 和 <​D​М‌X​Α‌РΙ_ACCESS_TOKEN>，对 500/502 做指数退避，对网络异常做重试，对 4xx 立即暴露，对返回体做基本校验。这样的代码即使先用于评测，也可以平滑过渡到生产调用。

import time
import requests
from requests.exceptions import Timeout, ConnectionError, RequestException

BASE_URL = "<​D​М‌X​Α‌РΙ_BASE_URL>"
ACCESS_TOKEN = "<​D​М‌X​Α‌РΙ_ACCESS_TOKEN>"
RETRYABLE_STATUS = {500, 502}

def post_chat(model, messages, extra_body=None, max_retries=4, timeout=30):
    url = f"{BASE_URL}/chat/completions"
    headers = {
        "Authorization": f"Bearer {ACCESS_TOKEN}",
        "Content-Type": "application/json",
        "Accept": "application/json",
    }

    validate_headers(headers)

    payload = {
        "model": model,
        "messages": messages,
        "temperature": 0.2,
    }

    if extra_body:
        payload["extra_body"] = extra_body

    for attempt in range(max_retries):
        try:
            response = requests.post(
                url,
                headers=headers,
                json=payload,
                timeout=timeout,
            )

            if response.status_code in RETRYABLE_STATUS:
                if attempt == max_retries - 1:
                    response.raise_for_status()
                time.sleep(2 ** attempt)
                continue

            if 400 <= response.status_code < 500:
                raise RuntimeError(
                    f"non-retryable error: {response.status_code}, body={response.text}"
                )

            response.raise_for_status()
            data = response.json()

            if "choices" not in data:
                raise ValueError(f"unexpected response schema: {data}")

            return data

        except (Timeout, ConnectionError) as exc:
            if attempt == max_retries - 1:
                raise RuntimeError(f"network error after retries: {exc}") from exc
            time.sleep(2 ** attempt)

        except RequestException as exc:
            raise RuntimeError(f"http request failed: {exc}") from exc

这段代码的价值，在于它把“评测脚本”和“生产调用”之间的距离缩短了。很多团队的问题不是不会做 Promptfoo 评测，而是评测时一套逻辑、上线时另一套逻辑，最后评测结论无法外推。把重试、超时、出站校验、字段裁剪、扩展参数映射都提前落在统一调用层，Promptfoo 跑出来的质量和延迟数据才更接近真实业务环境。尤其是延迟指标，不能只看平均值。对用户可感知系统来说，P95 往往比平均延迟更重要；对批处理任务来说，吞吐和失败重试成本更关键。​D​М‌X​Α‌РΙ 把这些行为收敛到协议层后，Promptfoo 不只是一个“比较答案”的工具，而变成了一个“比较完整调用链表现”的自动化基座。

再往前走一步，多模型评测不该停留在单次横评，而应该形成持续回归机制。比如每次你更换默认模型、调整系统 Prompt、修改工具定义、切换路由策略时，都让 Promptfoo 自动跑一次基线集，输出质量差异、延迟变化和错误码分布。测试集里可以同时包含“业务核心题”和“故障注入题”。前者用于判断回答质量，后者专门验证鲁棒性，例如故意喂超长上下文、故意注入不支持的扩展字段、故意删除请求头、故意把编码样本写错一个字符，看模型与调用链分别如何表现。这样的评测体系一旦建立，团队讨论“该不该切模型”时就不需要争论感受，而是直接看数据：质量下降了几个点，P95 涨了多少，500/502 重试次数是不是异常抬升，结构化解析成功率是否回落。

从更长期的工程视角看，Promptfoo 和 ​D​М‌X​Α‌РΙ 的组合，其实是在给下一阶段的 Agentic Workflow 和多模型路由打地基。因为 Agent 系统一旦进入真实业务，调用不再是单轮问答，而是规划、检索、工具执行、反思、再执行的链式过程。此时单个模型是否聪明当然重要，但更重要的是整条链路能不能被稳定编排。多模型路由也绝不是简单轮询，而是基于任务类型、上下文长度、结构化输出要求、延迟预算、成本阈值和历史成功率做策略决策：快速分类用轻量模型，复杂推理用高能力模型，编码转换或符号纠错用在专项评测里表现更稳的模型，长文档问答则优先给上下文窗口和引用一致性更好的模型。只有前面通过 Promptfoo 建好了可重复评测体系，通过 ​D​М‌X​Α‌РΙ 建好了统一接入和治理底座，这种路由才有可能是“证据驱动”的，而不是凭经验拍板。对企业效率的提升也正体现在这里：不是盲目追新模型，而是在统一协议、统一评测、统一监控的前提下，把模型能力按任务颗粒度拆开使用，让高能力模型只出现在它真正值回成本的位置，让轻量模型承担大部分常规流量，让异常和抖动被接入层吸收，而不是传导到业务表面。最终，多模型系统的竞争力，不会体现在它接了多少家模型，而会体现在它能否把“调用成功率、输出质量、延迟稳定度、回归可验证性”同时做成工程常态。