先用一把 key 跑一遍六个后端再决定：一份可复用的 A/B 脚本

为什么要做后端 A/B 测试

在 LLM API 聚合站上，一个 key 可以调用多个模型后端。不同后端在响应速度、输出风格、特定任务准确性上存在差异。仅凭主观感受或单一案例选择后端容易产生偏差。通过设计可复现的小型基准测试，用同一套问题集分别请求各后端，记录并对比结果，能更客观地评估哪个后端更适合你的场景。

设计可复现的小题集

题集的质量直接决定测试价值。建议遵循以下原则：

• 覆盖核心场景：根据你的实际用途（如文本分类、信息抽取、代码生成、对话）设计 5-10 个典型问题。
• 控制变量：每个问题使用相同的提示词模板，仅改变后端模型参数。
• 包含明确答案：尽量选择有客观正确答案或可量化评分标准的问题，减少主观判断。
• 记录元数据：为每个问题标注预期输出格式（如 JSON、短文本）和评分规则（如精确匹配、关键词命中）。

例如，题集可以包含：

1. 从一段产品评论中抽取情感倾向（正向/负向/中性）。
2. 将给定文本翻译成英文，检查关键术语准确性。
3. 根据描述生成一个简单的 Python 函数，验证功能正确性。
4. 回答一个事实性问题，比对标准答案。
5. 对一段长文本生成摘要，评估要点覆盖度。

编写可复用的 A/B 脚本

脚本的核心逻辑是：读取题集，循环请求每个后端，保存原始响应和耗时，最后汇总评分。以下是一个概念性流程：

1. 准备配置文件：列出后端名称（如 claude、gpt、deepseek、qwen、glm、kimi）和对应的模型标识（具体标识以文档为准）。
2. 定义请求函数：使用统一的 HTTP 客户端，设置相同的超时、温度等参数（除非测试目的需要变化）。
3. 遍历题集与后端：对每个问题，依次请求每个后端，记录响应内容、HTTP 状态码、耗时（从发送到接收完成）。
4. 保存结果：将结果写入结构化文件（如 JSON 或 CSV），包含问题 ID、后端名称、响应文本、耗时、错误信息（如有）。
5. 自动评分：根据预设规则对响应评分，例如精确匹配得 1 分，否则 0 分；或使用关键词列表计算命中率。

脚本应支持重复运行，并可通过环境变量指定 API key 和基础 URL。注意在请求间加入适当延迟，避免触发速率限制（具体限制请参考文档）。

如何解读结果而不被噪声误导

小样本测试容易受随机性影响，解读时需注意：

• 多次运行取平均：每个后端对每个问题至少运行 3 次，观察评分和耗时的波动范围。若某后端结果方差很大，说明其稳定性不足。
• 区分任务类型：不要只看总分，按问题类别（如抽取、生成、翻译）分别统计，找出后端的强项和弱项。
• 关注失败模式：记录错误类型（如超时、格式错误、内容偏离），失败模式比平均分更能反映实际使用中的风险。
• 考虑成本因素：聚合站按官方价 ×1.3 扣费，不同后端单价不同。在评分相近时，选择成本更低的后端。但不要为了省钱牺牲关键任务的质量。
• 避免过拟合：题集应代表真实场景，不要针对特定后端调整提示词。如果某个后端在题集上表现异常好，检查是否因提示词风格恰好匹配其训练数据。

实践建议

• 从 5 个问题、每个后端运行 3 次开始，快速获得初步印象，再根据发现扩展题集。
• 将脚本和结果保存在版本控制中，便于回溯和复现。
• 定期重跑测试，因为后端模型可能更新，你的需求也可能变化。
• 如果测试中发现某个后端持续表现优异，可以考虑将其作为主力，同时保留其他后端作为降级备选。

通过以上方法，你可以用一把 key 低成本地完成多后端对比，让数据辅助决策，而非依赖猜测。