跨供应商 LLM API 响应测试与评估:回归测试、质量保障与生产环境评估框架实战指南

面向多供应商 LLM 路由场景的测试实战指南。覆盖 Golden Dataset 构建、模型更新后回归测试、LLM-as-a-Judge 评分、Promptfoo / DeepEval / Braintrust / LangSmith 等开源评估框架的选型与集成。

2026-08-08· TheRouter

把 LLM 请求路由到多个供应商(OpenAI、Anthropic、DashScope、DeepSeek),有一个绕不开的问题,就是你怎么确认路由之后的回答质量没变?GPT-4o 上跑得好的 prompt 换到 Claude Sonnet 4 可能表现不一样,某个供应商更新了模型,回答的质量会悄悄变化,没有任何错误码会告诉你这件事。评估是唯一靠得住的防线。

这篇指南覆盖跨供应商测试的完整工作流,从构建 Golden Dataset、选择评估指标、运行跨供应商评估,到把回归测试接进 CI/CD。

LLM API 测试和传统 API 测试有什么不一样

传统 API 测试检查状态码、响应格式和延迟就够了。LLM API 测试面对的难题更底层，因为同一个输入可以产出许多合格的回答，“正确”本身经常带主观性。

三个因素让跨供应商测试尤其棘手。

输出的不确定性。 即使把 temperature 设成 0,不同供应商在不同请求之间仍可能返回略有差异的文本。精确匹配的断言几乎没法用。

模型版本漂移。 各家供应商按自己的节奏更新模型。OpenAI 用带日期的快照(gpt-4o-2024-11-20),Anthropic 用 claude-sonnet-4-20250514,DashScope 的滚动别名会安静地指向更新的权重。上周通过的测试今天可能失败,你这边一行代码都没改。

供应商之间的行为差异。 system prompt 的处理方式、tool calling 的格式、token 计数规则、内容过滤的阈值,每家都不一样。同一条 prompt 可能在一个供应商上得到详尽回答,在另一个上直接被拒绝。

结论很明确,只靠状态码检查测不了 LLM API 集成。你需要评估,用结构化的方式衡量输出质量。

构建 Golden Dataset

所有认真做评估的团队,起点都是 Golden Dataset,一组经过人工审核的输入-输出对,定义了什么是合格的回答。

应该放什么进去

类别	示例	为什么重要
核心场景	用户最常见的 20 个问题	覆盖绝大多数流量命中的主线路径
边界用例	超长输入、多语言查询、模糊请求	抓住只在边缘出现的失败
回归用例	以前出过问题并修复过的输入	防止已知 bug 再次冒出来
对抗性输入	prompt 注入尝试、跑题查询	验证安全和内容过滤行为

实操建议

从小开始。 精选的 50 到 100 条数据胜过粗糙的 1000 条。发现新的失败模式时再扩充。
版本化管理。 把数据集和 prompt 一起放进 Git。当某条测试用例变了,diff 会告诉你原因。
加元数据标签。 给每条用例打上预期行为分类(事实准确性、语气、格式合规),后续切片分析时用得上。
用真实的线上流量。 每周从实际用户输入中采样,让领域专家审核或修正输出。合成数据适合冷启动,但没有什么能替代真实查询。

评估指标的三个层次

LLM 评估指标按速度和准确度分成三档,实际使用时组合部署效果最好。

第一档:确定性检查(最快、最脆)

这类检查瞬间执行,能拦住明显的格式问题。

# 检查回答里包含必要信息
assert "API key" in response.text
assert len(response.text) > 100
assert response.text.count("```") % 2 == 0  # 代码块标记配对

# 正则检查格式合规
import re
assert re.match(r"^\d+\.", response.text)  # 以编号列表开头

确定性检查擅长格式合规和关键信息的存在性判断。它判断不了推理质量、细微差别和回答是否真的有帮助。

第二档:Embedding 相似度(中等速度、中等准确度)

用 embedding 向量衡量测试输出和参考答案之间的语义距离。

from openai import OpenAI

client = OpenAI()

def cosine_similarity(a, b):
    import numpy as np
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

ref_embedding = client.embeddings.create(
    model="text-embedding-3-small",
    input=reference_answer
).data[0].embedding

test_embedding = client.embeddings.create(
    model="text-embedding-3-small",
    input=test_answer
).data[0].embedding

score = cosine_similarity(ref_embedding, test_embedding)
assert score > 0.85  # 阈值因场景而异

Embedding 相似度能捕捉保留含义的改写,也能发现答案偏离主题的情况。但它分辨不了两个语义相近的答案在事实上谁对谁错。

第三档:LLM-as-a-Judge(最慢、最准)

让一个强模型给弱模型或低成本模型的输出打分。

judge_prompt = """你正在评估一个 AI 助手的回答。

问题:{question}
参考答案:{reference}
助手回答:{answer}

请按以下标准评分(每项 1-5 分):
1. 事实准确性:是否包含正确信息?
2. 完整性:是否覆盖了参考答案中的关键要点?
3. 清晰度:组织是否清楚、是否容易理解?

返回 JSON:{{"accuracy": N, "completeness": N, "clarity": N, "explanation": "..."}}
"""

judgment = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": judge_prompt.format(
        question=test_case["input"],
        reference=test_case["expected"],
        answer=actual_output
    )}],
    response_format={"type": "json_object"}
)

LLM-as-a-Judge 是最灵活的方法,适合处理带主观性的质量维度。代价是成本和延迟,每次评估都要跑一次完整的推理调用。

最佳实践: 三档结合使用。先跑确定性检查快速拦住格式问题,再用 embedding 相似度做批量筛选,最后把 LLM-as-a-Judge 留给最重要的用例。

跨供应商评估实操

核心思路很简单:用同一套测试集跑多个供应商,把结果放在一起对比。

一个最小的跨供应商测试脚本

from openai import OpenAI
import json

providers = {
    "openai": {
        "client": OpenAI(),
        "model": "gpt-4o"
    },
    "dashscope": {
        "client": OpenAI(
            base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
            api_key="sk-..."
        ),
        "model": "qwen-max"
    },
    "deepseek": {
        "client": OpenAI(
            base_url="https://api.deepseek.com",
            api_key="sk-..."
        ),
        "model": "deepseek-chat"
    }
}

test_cases = json.load(open("golden_dataset.json"))

for case in test_cases:
    results = {}
    for name, provider in providers.items():
        response = provider["client"].chat.completions.create(
            model=provider["model"],
            messages=case["messages"],
            temperature=0
        )
        results[name] = response.choices[0].message.content

    for name, output in results.items():
        score = evaluate(output, case["expected"])
        print(f"{case['id']} | {name}: {score:.2f}")

这个模式之所以能用,是因为 OpenAI、DashScope 和 DeepSeek 都支持 OpenAI 兼容的 chat completions 格式。同一套测试框架,同一个 Golden Dataset,只需要换 base_url 和 model。

对比的维度

维度	怎么测	为什么重要
输出质量	LLM-as-a-Judge 评分	核心问题,这个供应商的回答到底好不好?
一致性	同一条输入跑 5 次,看方差	方差大意味着用户体验不可预测
延迟	首 token 时间和总响应时间	影响用户体验,流式输出场景尤其明显
成本	输入/输出 token 数量 × 单价	同等质量下成本更低,本身就是合理的路由决策
拒绝率	触发内容过滤的输入占比	供应商 A 可能回答的问题,供应商 B 可能拒绝

开源评估框架选型

评估基础设施不需要从零搭建。几个成熟的框架已经解决了测试编排、评分、结果可视化和 CI 集成的问题。

Promptfoo

Promptfoo 是命令行优先的开源评估工具(2026 年 3 月被 OpenAI 收购,仍然保持 MIT 协议)。它天然为跨供应商对比而设计。

核心优势:

基于 YAML 的测试定义,基础评估不需要写代码
内置支持 50+ 供应商,包括 OpenAI、Anthropic 及任何 OpenAI 兼容端点
矩阵视图让你并排对比不同 prompt 和供应商的输出
通过 GitHub Actions 集成 CI/CD
内置红队测试和安全扫描

典型工作流:

# promptfooconfig.yaml
providers:
  - openai:gpt-4o
  - openai:compatible:https://dashscope.aliyuncs.com/compatible-mode/v1:qwen-max
  - openai:compatible:https://api.deepseek.com:deepseek-chat

prompts:
  - "请简明回答这个问题:{{question}}"

tests:
  - vars:
      question: "什么是 API 网关?"
    assert:
      - type: contains
        value: "路由请求"
      - type: llm-rubric
        value: "回答技术上准确且不超过 200 字"

运行 npx promptfoo eval,然后用 npx promptfoo view 在浏览器里查看结果。

DeepEval

DeepEval 走的是 Pytest 原生路线。如果团队已经在用 Python 写测试,DeepEval 可以直接融入现有工作流。

核心优势:

Pytest 插件,评估和单元测试一起跑
内置 14+ 指标,包括幻觉检测、回答相关性、忠实度(RAG 场景)和偏差检测
支持从生产日志自动生成 Golden Dataset
Confident AI 仪表盘追踪评分趋势

from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric, HallucinationMetric

def test_customer_support_response():
    test_case = LLMTestCase(
        input="怎么重置密码?",
        actual_output=get_response_from_provider("openai", "怎么重置密码?"),
        expected_output="进入设置 > 安全 > 重置密码...",
        retrieval_context=["密码重置文档..."]
    )

    relevancy = AnswerRelevancyMetric(threshold=0.7)
    hallucination = HallucinationMetric(threshold=0.5)

    assert_test(test_case, [relevancy, hallucination])

Braintrust

Braintrust 把评估、链路追踪和 prompt 管理整合在一个平台里。开源 SDK 负责评估,托管平台增加了协作和线上监控能力。

核心优势:

追踪和评估打通,每条生产调用都能回流到评估数据集
实验对比带统计显著性检验
同时支持离线评估(开发阶段)和在线评估(生产环境)
内置数据集版本管理

LangSmith

LangSmith(LangChain 团队出品)提供链路追踪、评估和数据集管理。和 LangChain 生态配合最好,但也支持独立使用。

核心优势:

多步骤链路和 agent 工作流的深度追踪
生产监控搭配采样评估
一键把生产 trace 转成回归测试用例
人工标注队列支持人工评估工作流

Arize Phoenix

Arize Phoenix 是 LLM 应用的开源可观测性平台,评估能力同样成熟。

核心优势:

完全开源(Apache 2.0)
Embedding 漂移检测,用于发现渐进式质量退化
Trace 可视化,调试复杂的 agent 工作流
集成 OpenTelemetry,对接生产可观测体系

快速对比

框架	协议	跨供应商支持	CI/CD	LLM-as-Judge	链路追踪	定价
Promptfoo	MIT	原生(50+ 供应商)	GitHub Actions	支持	不支持	免费(开源)
DeepEval	Apache 2.0	通过自定义 provider	Pytest	支持(14+ 指标)	通过 Confident AI	免费(开源)+ 托管
Braintrust	MIT(SDK)	通过 OpenAI SDK	支持	支持	支持	免费层 + 付费
LangSmith	商业	通过 LangChain	支持	支持	支持	免费层 + 付费
Arize Phoenix	Apache 2.0	通过 OpenTelemetry	支持	支持	支持	免费(开源)+ 托管

模型更新后的回归测试

模型更新是生产环境 LLM 应用质量退化的最常见来源。当 OpenAI 把 gpt-4o-2024-11-20 替换成更新的快照,或者 DashScope 更新了 qwen-max 别名背后的模型权重,你的输出就变了。你需要知道它变好了还是变差了。

回归测试工作流

基线采集。 在做任何改动之前,用完整的 Golden Dataset 跑一次当前生产配置。保存所有输出和评分。
变更检测。 模型更新、prompt 修改或供应商切换之后,用同一套数据集再跑一次。
差异对比。 对比两次评分。标记出质量低于阈值的用例。
决策关卡。 如果退化在容忍范围内(比如整体评分下降不超过 5%,没有关键失败),放行。否则排查问题或回滚。

CI/CD 集成示例

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'config/models.yaml'

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npx promptfoo eval --config promptfooconfig.yaml
      - run: npx promptfoo eval --output results.json
      - uses: actions/upload-artifact@v4
        with:
          name: eval-results
          path: results.json

每个修改 prompt 或模型配置的 Pull Request 都会触发一次评估运行。Reviewer 在合并之前就能看到质量评分。

生产环境监控

离线评估拦住部署之前的退化。生产环境监控拦住剩下的一切,包括新的用户查询模式、数据分布偏移和渐进式模型漂移。

采样策略

评估每一条生产请求成本太高。实际可行的做法分几步走。

采样 1-5% 的请求做自动化评估
异步评分,不要给用户侧的响应增加延迟
评分下降告警,给每个指标设阈值,滚动均值低于阈值时触发告警
把有价值的用例反哺到 Golden Dataset,生产流量是新测试用例的最佳来源

需要追踪的关键指标

质量评分趋势,7 天移动平均是稳定、上升还是下降
各供应商的拒绝率,突然上升可能意味着内容策略变了
延迟分位数,按供应商看 p50、p95、p99
单次请求成本,token 用量 × 单价,跨供应商对比
错误率,4xx/5xx 响应、超时和限流

生产监控的详细搭建方式参见 LLM API 可观测性与监控工具对比。

TheRouter 集成说明

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model，并返回 OpenAI 形式的流式响应。

通过 OpenAI 兼容网关路由请求时,你的评估框架每个后端只需要维护一份客户端配置,网关负责处理认证和端点路由。这意味着你可以用同一套 Promptfoo 或 DeepEval 测试集对多个供应商做评估,只需要换一个 model 参数,不用在测试配置里维护各家单独的 API key 和 base URL。

对于使用模型 fallback 路由的团队,评估还有一层额外的作用，就是验证 fallback 响应和主路径响应达到同样的质量标准。如果你的主模型是 GPT-4o、fallback 是 Qwen-Max,Golden Dataset 应该在两边都能产出合格的评分。

生产环境 LLM API 测试检查清单

在跨供应商 LLM 部署中搭建评估时,用这份清单逐项核对。

Golden Dataset 已建立,50+ 条经过审核的输入-输出对,覆盖核心场景、边界用例和回归用例
指标已定义,每条测试用例至少一个确定性检查和一个 LLM-as-a-Judge 指标
跨供应商基线已采集,路由配置中每个供应商都有评分记录
CI/CD 已接入,prompt 或模型配置变更时自动触发评估
回归阈值已设定,有明确的通过/失败标准,质量下降时阻止部署
生产采样已启动,1-5% 线上流量异步评分
告警管道已配置,质量评分下降时在用户感知之前发出通知
数据集维护节奏已确定,每周回顾生产流量更新 Golden Dataset
人工校准环路已就位,每月检查自动评分和人工判断之间的一致性

LLM API 测试和传统 API 测试有什么不一样

构建 Golden Dataset

应该放什么进去

实操建议

评估指标的三个层次

第一档:确定性检查(最快、最脆)

第二档:Embedding 相似度(中等速度、中等准确度)

第三档:LLM-as-a-Judge(最慢、最准)

跨供应商评估实操

一个最小的跨供应商测试脚本

对比的维度

开源评估框架选型

Promptfoo

DeepEval

Braintrust

LangSmith

Arize Phoenix

快速对比

模型更新后的回归测试

回归测试工作流

CI/CD 集成示例

生产环境监控

采样策略

需要追踪的关键指标

TheRouter 集成说明

生产环境 LLM API 测试检查清单

延伸阅读