很多团队刚接大模型时，关注点会放在“这个模型会不会答”“哪个模型更快”“这次调用有没有成功”。等业务跑起来以后，真正麻烦的问题会变成：今天换了模型名，昨天的流程还稳不稳；Base URL 从一个入口切到另一个入口，RAG 的答案有没有漂；提示词改了一行，结构化 JSON 还会不会少字段。

这些问题靠人工点几下页面很难发现。多模型调用需要一套回归测试，把模型接口当成普通工程依赖来管理。它不要求答案每个字都一样，但要能检查请求形状、状态码、耗时、关键字段、错误类型和结构化输出。只要这些指标稳定，业务才敢升级模型、调整路由或切换兼容入口。

这篇写的是一套可以放进团队流水线的做法：先定义接口契约，再准备样本集，然后跑基准请求、结构检查、延迟记录和发布门禁。向量引擎中转站在文中作为一个 OpenAI 兼容入口样例出现，用来说明注册地址、Base URL 和多模型调用测试如何放在同一套工程流程里。

1. 不要把模型接口只当外部服务

传统后端依赖数据库、缓存、对象存储和第三方 API，研发流程里通常会有连接检查、迁移检查、回归测试和上线观察。模型接口也应该被这样对待。它不是“能返回文字就行”的黑盒，而是会影响业务结果的核心依赖。

我见过不少问题都不是模型完全不可用，而是更细的变化：返回字段从 JSON 变成了自然语言，流式响应少了结束标记，某个模型对工具参数更宽松，另一个模型更容易把数字转成字符串。用户只会觉得系统变笨了，研发却很难从单次日志里定位。

回归测试的价值就在这里。它把“感觉稳定”变成一组可比较的记录：同一批样本、同一套契约、同一类指标。每次换模型、换 Base URL、改提示词、改 RAG 切片，都能留下前后对比。

2. 先写接口契约

契约文件不需要复杂，关键是让团队知道一次模型调用到底依赖什么。下面是一个 YAML 示例。

name: agent_summary_contract
base_url: https://api.vectorengine.cn/v1
endpoint: /chat/completions
method: POST
auth:
  type: bearer
  env: MODEL_API_KEY
models:
  primary: your-primary-model
  backup: your-backup-model
timeout:
  connect_ms: 5000
  read_ms: 35000
retry:
  network_error: 2
  rate_limit: 2
  server_error: 1
response:
  must_have:
    - choices[0].message.content
    - usage.prompt_tokens
    - usage.completion_tokens
  json_mode: false
owner:
  team: ai-platform
  alert: model-runtime-alert

这个文件最大的好处是减少口头约定。Base URL、模型名、超时、重试、关键字段、负责人都写在一起，后面排查时不用翻聊天记录。

如果要使用向量引擎中转站做接入样例，注册入口只需要在环境说明里出现一次：

https://178.nz/awa

常见地址层级如下：

https://api.vectorengine.cn
https://api.vectorengine.cn/v1
https://api.vectorengine.cn/v1/chat/completions

实际写 SDK 配置时，通常把 base_url 放到 /v1 这一层，具体接口路径交给 SDK 或封装函数处理。

3. 样本集要按风险分类

很多回归测试失败，是因为样本集太像演示问题。真实业务里，模型调用会遇到短问答、长上下文、结构化提取、工具调用、多轮追问、空结果、异常输入和权限拒绝。样本集至少要覆盖这些类型。

[
  {
    "id": "short_summary_001",
    "type": "short_summary",
    "input": "把这段会议记录压缩成三条待办。",
    "assert": {
      "format": "markdown_list",
      "min_items": 2,
      "max_items": 5
    }
  },
  {
    "id": "json_extract_001",
    "type": "json_extract",
    "input": "从报修文本里抽取设备、地点、紧急程度。",
    "assert": {
      "format": "json",
      "required": ["device", "location", "priority"]
    }
  },
  {
    "id": "rag_boundary_001",
    "type": "rag",
    "input": "只根据给定材料回答，不要补充材料外结论。",
    "assert": {
      "must_refuse_when_missing": true
    }
  }
]

样本不用一开始就很多。二三十条高质量样本，比几百条随手拼出来的问题更有价值。每条样本都要知道自己在测什么：格式、字段、边界、拒答、延迟，还是路由稳定性。

4. 用 Python 跑第一版回归

下面脚本从样本文件读取测试项，请求 OpenAI 兼容接口，然后保存状态码、耗时、内容长度和用量字段。它没有引入复杂依赖，适合先跑通流程。

import json
import os
import time
from pathlib import Path

import requests

BASE_URL = os.getenv("MODEL_BASE_URL", "https://api.vectorengine.cn/v1")
API_KEY = os.getenv("MODEL_API_KEY")
MODEL = os.getenv("MODEL_NAME", "your-model-name")

def call_model(case):
    started = time.time()
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
            "X-Case-Id": case["id"],
        },
        json={
            "model": MODEL,
            "messages": [
                {"role": "system", "content": "按要求完成任务，必要时返回结构化结果。"},
                {"role": "user", "content": case["input"]},
            ],
            "temperature": 0.2,
        },
        timeout=(5, 35),
    )
    elapsed_ms = round((time.time() - started) * 1000)
    text = response.text
    try:
        payload = response.json()
    except ValueError:
        payload = {}

    return {
        "id": case["id"],
        "type": case.get("type"),
        "status": response.status_code,
        "elapsed_ms": elapsed_ms,
        "content": payload.get("choices", [{}])[0].get("message", {}).get("content", ""),
        "usage": payload.get("usage", {}),
        "raw_prefix": text[:300],
    }

def main():
    cases = json.loads(Path("cases.json").read_text(encoding="utf-8"))
    rows = []
    for case in cases:
        rows.append(call_model(case))
    Path("model-regression-result.json").write_text(
        json.dumps(rows, ensure_ascii=False, indent=2),
        encoding="utf-8",
    )
    print({"total": len(rows), "ok": sum(1 for r in rows if r["status"] == 200)})

if __name__ == "__main__":
    main()

第一版不要急着判断答案好坏，先把“能否稳定拿到响应”测清楚。状态码、耗时、用量字段和内容长度都稳定以后，再加更细的断言。

5. 结构化断言比全文对比更实用

模型答案很少适合逐字比较。今天多一个逗号，明天换一种表达，不一定代表业务失败。回归测试更适合做结构化断言。

import json
import re

def assert_json_fields(content, required):
    try:
        obj = json.loads(content)
    except json.JSONDecodeError:
        return False, "not_json"
    missing = [name for name in required if name not in obj]
    if missing:
        return False, "missing:" + ",".join(missing)
    return True, "ok"

def assert_markdown_list(content, min_items=2, max_items=6):
    items = [line for line in content.splitlines() if re.match(r"^[-*]\\s+", line.strip())]
    if len(items) < min_items:
        return False, "too_few_items"
    if len(items) > max_items:
        return False, "too_many_items"
    return True, "ok"

def assert_contains_any(content, words):
    if any(word in content for word in words):
        return True, "ok"
    return False, "missing_expected_word"

比如客服摘要、工单归类、报修提取、RAG 引用检查，都可以写成这种断言。不要一开始就追求复杂评分模型，先让断言足够朴素、透明、可维护。

6. 记录耗时和失败类型

多模型场景里，平均耗时意义有限。用户体验通常被 P95、偶发超时和连续 429 影响。回归报告里建议保留这些字段：

字段	说明	为什么有用
case_id	样本编号	对比同一条样本的前后变化
route	当前路由	判断是否切到备用模型
model	模型名	追踪模型版本或别名变化
status	HTTP 状态码	快速区分权限、路径、限流和服务异常
elapsed_ms	调用耗时	观察 P50、P95 和异常峰值
prompt_tokens	输入用量	判断上下文是否异常变长
completion_tokens	输出用量	判断输出是否失控
assertion	断言结果	判断是否可发布
error_code	错误归类	用于告警和复盘

这些字段不需要等线上事故发生再补。回归脚本第一天就写进去，后面会省很多事。

7. 在 Node.js 服务里暴露健康检查

除了离线脚本，服务端也可以提供一个只读健康检查接口。它不跑完整业务，只验证模型入口、模型名、认证和响应结构。

import express from "express";

const app = express();

app.get("/internal/model-health", async (_req, res) => {
  const baseURL = process.env.MODEL_BASE_URL || "https://api.vectorengine.cn/v1";
  const model = process.env.MODEL_NAME || "your-model-name";
  const started = Date.now();

  try {
    const r = await fetch(`${baseURL}/chat/completions`, {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.MODEL_API_KEY}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        model,
        messages: [
          { role: "user", content: "返回 ok 两个字。" }
        ],
        temperature: 0
      })
    });

    const body = await r.json().catch(() => ({}));
    res.json({
      ok: r.ok,
      status: r.status,
      elapsed_ms: Date.now() - started,
      has_content: Boolean(body.choices?.[0]?.message?.content),
      usage: body.usage || null
    });
  } catch (error) {
    res.status(500).json({
      ok: false,
      status: "network_error",
      elapsed_ms: Date.now() - started,
      error: String(error).slice(0, 200)
    });
  }
});

这个接口不要对外开放，放在内网或运维面板即可。它的目标不是证明模型聪明，而是证明调用链还活着。

8. 把路由切换纳入演练

多模型系统最怕“理论上能切换，实际没人切过”。如果路由策略只写在配置文档里，真正出问题时会担心影响业务，不敢操作。回归测试应该定期演练路由切换。

routes:
  summary:
    primary:
      provider: vector-compatible-a
      model: your-primary-model
    backup:
      provider: vector-compatible-b
      model: your-backup-model
    switch_policy:
      fail_rate_over_5m: 0.08
      p95_over_ms: 12000
      manual_switch: true

演练时不一定要切全量。可以只切回归样本、内部账号或少量灰度流量。重点是确认三件事：配置能生效，日志能看出当前路由，回滚路径明确。

9. RAG 场景要做上下文回放

RAG 应用的回归测试更复杂，因为答案不只受模型影响，也受切片、召回、排序和提示词影响。最简单的办法是把上下文一起保存下来，做回放。

{
  "id": "rag_replay_001",
  "question": "报修单超过 24 小时未处理时如何升级？",
  "contexts": [
    {
      "doc_id": "ops_handbook_12",
      "text": "高优先级报修单超过 24 小时未处理，应通知值班主管并生成升级记录。"
    }
  ],
  "assert": {
    "must_include": ["24 小时", "值班主管", "升级记录"],
    "must_not_include": ["自动关闭"]
  }
}

回放样本能帮你区分两个问题：是检索层没拿到材料，还是模型拿到材料以后没有按材料回答。没有回放记录时，这两类问题很容易混在一起。

10. 发布门禁可以很朴素

门禁不需要一开始就复杂。下面是一组比较容易执行的规则：

检查项	通过标准
连通性	所有样本请求没有认证失败和路径错误
结构	结构化样本必填字段全部存在
延迟	P95 没有超过团队设定阈值
限流	429 比例没有明显升高
用量	prompt_tokens 和 completion_tokens 没有异常膨胀
路由	当前模型和上游入口可在日志中确认
回滚	配置有上一版本记录，可在 10 分钟内恢复

如果某一项失败，不一定要阻断所有发布，但必须有人确认。比如只是某个非核心样本耗时升高，可以带备注发布；如果结构化字段缺失，就应该停下来。

11. 回归报告示例

一份好报告不需要很花哨，研发、产品和运维能看懂即可。

{
  "run_id": "model-regression-20260703-01",
  "base_url": "https://api.vectorengine.cn/v1",
  "model": "your-model-name",
  "total": 32,
  "passed": 30,
  "failed": 2,
  "p50_ms": 1420,
  "p95_ms": 6810,
  "rate_limit": 0,
  "network_error": 0,
  "failed_cases": [
    {
      "id": "json_extract_004",
      "reason": "missing:priority"
    },
    {
      "id": "rag_boundary_002",
      "reason": "missing_expected_word"
    }
  ]
}

报告里保留 Base URL 和模型名，是为了以后能追溯。只看“通过 30 条”意义不够，因为同一批样本在不同入口、不同模型、不同提示词下的结果都可能变化。

12. 常见排错表

现象	先查字段	可能原因	处理办法
全部样本 401	auth.env、Key 后四位	环境变量没注入或 Key 失效	重新加载密钥，确认服务端读取的是同一份配置
全部样本 404	base_url、endpoint	/v1 层级或完整路径拼错	区分 SDK baseURL 和完整接口路径
只有 JSON 样本失败	assertion、content	模型没有稳定遵守结构	降低温度，增加 schema 检查，必要时换模型
RAG 样本答偏	contexts、prompt	召回材料缺失或提示词约束弱	先回放固定上下文，再排检索层
P95 突然升高	elapsed_ms、route	上游慢或路由切到备用入口	看路由日志，必要时降级批处理
用量翻倍	prompt_tokens	上下文拼接重复	检查模板、历史消息和 RAG chunk 去重
流式输出中断	finish_reason、raw_prefix	网关或客户端读取方式不一致	单独跑非流式对比，确认是模型还是客户端
429 增多	retry_count、case_id	回归并发太高或线上共用额度	降低测试并发，分离测试 Key 和生产 Key

13. FAQ

问：多模型回归测试是不是会增加费用？

会有少量调用成本，所以样本集要精。核心样本每天跑，完整样本在发布前跑，压力样本按需跑。比起线上异常后返工，这点成本通常更可控。

问：模型答案不固定，回归测试还有意义吗？

有意义。不要逐字比较，改看结构、关键字段、拒答边界、耗时和错误类型。模型可以换表达，但不能把必填字段丢掉。

问：向量引擎中转站在这套流程里放在哪？

它可以作为 OpenAI 兼容入口之一，放在契约文件的 base_url 和路由配置里。业务代码只依赖内部封装，不直接散落多个上游地址。

问：什么时候需要备用模型？

当业务对可用性敏感，或者同一功能有高峰期调用，就应该准备备用路由。备用模型不一定常用，但要定期演练。

问：回归样本要不要包含真实用户数据？

尽量不要。可以把真实问题脱敏、改写成样本。测试系统不应该保存敏感内容。

问：本地脚本通过了，线上还会失败吗？

会。脚本只能覆盖接口和样本，线上还受并发、网络、权限、队列和前端读取影响。所以脚本、健康检查和线上日志要一起看。

问：Base URL 切换后最先看什么？

先看认证、状态码、模型名、响应结构和用量字段，再看业务答案。底层字段不稳，答案质量也很难稳定。

问：回归测试适合接入 CI 吗？

适合，但要分层。轻量样本可以进每次发布，完整样本可以放在手动门禁或夜间任务里。

14. 一套推荐落地节奏

第一周先写契约文件和十条样本，只测连通性、状态码、耗时和内容是否为空。第二周增加结构化断言，把 JSON、列表、拒答和 RAG 引用分开检查。第三周接入服务端健康检查和路由字段。第四周再把轻量样本接进 CI。

不要一开始就追求大而全。模型应用的工程化，靠的是持续留下可比较的证据。每次发布都能回答“这次改了什么、影响哪类样本、失败率有没有变化、能不能回滚”，系统就会稳很多。

15. 小结

多模型调用不是把几个模型名写进配置就完事。只要业务开始依赖模型结果，就需要契约、样本、断言、报告和发布门禁。OpenAI 兼容接口让接入形式统一，但统一入口不代表没有差异，真正的稳定来自持续测试和清晰日志。

向量引擎中转站可以作为一个兼容入口样例，放进小流量、回归样本和路由演练里验证。团队要关注的不只是能否成功返回，还要看 Base URL 层级是否清楚，模型名是否可追踪，状态码是否可归类，用量字段是否完整，失败后是否能回滚。做到这些，模型接口才更像一个可管理的工程依赖，而不是只能靠感觉维护的外部黑盒。