在生产环境中A/B测试微调模型与GPT-4

你已经在领域数据上微调了一个模型。评估结果看起来很有前景。离线测试显示准确率在你的特定任务上匹配GPT-4。但部署到生产环境感觉有风险——如果它在你的评估数据集没有捕获的方面对真实用户更差呢？

答案不是猜测，而是A/B测试。将一定比例的生产流量路由到你的微调模型，测量结果，并随着信心的建立逐步迁移。

路由架构

最简单的实现：一个API网关，根据分流比例将请求路由到你的云API或本地微调模型。

用户请求
     ↓
API网关（路由器）
     ↓
┌─────────────────────┐
│  10% → Ollama       │  （微调模型，本地）
│  90% → OpenAI API   │  （GPT-4o，云端）
└─────────────────────┘
     ↓
日志：model_used, input, output, metrics
     ↓
返回用户响应

实现选项：

简单： 每个请求随机分配（Math.random() 小于 0.1 则走Ollama，否则走OpenAI）
更好： 按用户会话一致分配（同一用户在会话期间始终使用同一模型，防止行为不一致）
最佳： 功能标记服务（LaunchDarkly、PostHog、自定义），允许你无需部署即可调整分流比例

Ollama和OpenAI都暴露OpenAI兼容的API，所以路由器的工作仅是URL切换。请求格式完全相同。

测量什么

主要指标（业务结果）

这些告诉你微调模型是否产生与GPT-4相同的用户结果：

指标	测量内容	如何捕获
任务完成率	用户是否完成了他们来做的事？	跟踪下游动作（例如，用户在客服回复后点击"已解决"）
用户满意度	用户对AI输出满意吗？	回复的点赞/点踩、NPS或CSAT
错误率	模型是否产生需要人工纠正的输出？	跟踪手动覆盖或纠正
转化影响	AI功能是否推动了预期的业务行为？	跟踪AI交互下游的转化事件

次要指标（模型质量）

这些告诉你模型的技术性能：

指标	测量内容
响应延迟	从请求到完成响应的时间（本地应该更快）
格式合规性	匹配预期输出结构的响应比例
幻觉率	响应中的事实错误（需要抽查审查）
回退率	模型产生无响应或错误的频率

成本指标

指标	GPT-4o	微调本地模型
每个请求成本	$0.003-0.01	约$0
月成本（在测试量下）	跟踪实际支出	硬件成本（固定）
预计月成本（100%）	从测试推算	同样的固定成本

需要多少查询

A/B测试需要统计显著性。所需查询数取决于你要检测的差异和当前指标：

经验法则： 要以95%的置信度检测任务完成率5%的差异：

如果当前率为80%：每个变体约1,500个查询
如果当前率为90%：每个变体约3,500个查询
如果当前率为95%：每个变体约7,300个查询

在每天500个查询的情况下，10%分流每天约发送50个查询到微调模型。在这个速率下：

检测5%差异：约30-70天
检测10%差异：约7-18天

实践建议： 无论请求量如何，至少运行测试2周，以捕获星期和时段模式。

渐进迁移路径

阶段1：验证（10%流量，2-4周）

将10%的流量路由到微调模型。监控所有指标。目标不是证明微调模型更好——而是证明它不会明显更差。

通过标准：

任务完成率在GPT-4的3%以内
错误率未增加
用户投诉未增加
格式合规性达到阈值

如果微调模型不满足这些标准，不要放弃。调查失败原因，为失败模式添加训练样本，重新训练，然后再次测试。

阶段2：扩展（50%流量，2-4周）

如果阶段1通过，增加到50%。在这个流量下，你将看到更罕见的边界情况浮出水面。监控相同指标。

这个阶段也测试基础设施：你的本地硬件能否处理50%的生产流量？负载下是否有延迟问题？Ollama在持续请求量下表现是否良好？

阶段3：主力（90%流量，1-2周）

翻转比例：90%微调，10% GPT-4。GPT-4路径作为对照组和回退。这是你的"软上线"——微调模型处理绝大多数流量，但你仍有安全网。

阶段4：完全迁移（100%流量）

禁用GPT-4路径。所有流量通过你的微调模型。保持GPT-4凭证有效以备紧急回滚。

总迁移时间线： 从首次测试到完全迁移6-12周。这个时间线感觉很慢，但获得的信心值得耐心。将不良模型发布给100%用户的代价远高于多一个月的测试。

常见A/B测试结果

根据典型的微调结果：

结果1：微调模型在领域任务上胜出

最常见的结果。微调模型在你的特定领域任务上优于GPT-4——更高的准确率、更一致的格式、更少的关于你产品的幻觉。

行动： 迁移到微调模型。成本节省是质量提升之外的额外收益。

结果2：微调模型匹配GPT-4

微调模型产生等效结果。指标在噪声范围内。

行动： 迁移到微调模型。以大幅降低的成本获得相同质量是一个容易的决定。

结果3：微调模型在特定场景上失败

微调模型处理90%的情况很好，但在特定子集上表现不佳——不寻常的查询、复杂的多步推理，或训练数据中代表不足的场景。

行动： 两个选择：

为失败场景添加训练样本并重新训练
使用混合方法：微调模型处理90%，GPT-4回退处理10%（仍然大幅节省成本）

结果4：微调模型明显更差

当你已经进行了适当的离线评估时，这种情况很少见。如果发生：

检查训练数据质量（数据质量清单）
验证量化是否导致问题（测试Q8_0而不是Q4_K_M）
确保基础模型适合你的任务
考虑你的任务是否真正需要前沿智能（何时不该微调）

实施技巧

记录所有内容

记录两个变体的每个请求和响应。你需要这些数据来：

调试微调模型的失败
为下一个重训练周期构建训练数据
向利益相关者证明迁移是数据驱动的

使用相同的温度

在测试期间将两个模型的温度设置为0（或固定的低值）。可变温度引入的噪声会使比较更困难。

测试完整流水线

不要只测试模型输出质量。测试完整的流水线：请求 → 模型 → 响应解析 → 下游动作。一个产生正确输出但格式略有不同的模型可能破坏你的解析器。

制定回滚计划

即使在完全迁移后也保持GPT-4路径可用。如果生产中出了问题，你应该能在几分钟内切换回GPT-4。这是配置变更，不是部署。

与团队沟通

让客服、销售和其他团队知道测试。如果用户报告质量差异，客服需要知道是哪个模型提供了响应（检查你的日志）。

开始

在Ertas上微调你的模型，并使用你的评估数据集进行离线验证
通过Ollama与现有OpenAI集成并行部署
实现简单路由器（10% Ollama / 90% OpenAI）
为所有指标添加日志（任务完成、满意度、错误、延迟、成本）
运行阶段1持续2-4周
分析结果，根据需要调整训练，然后逐步推进各阶段

A/B测试消除了迁移的风险。你不是在猜测你的微调模型是否足够好——你在测量它。在大多数情况下，数据表明：它更好而且更便宜。