什么是模型 A/B？两套模型对比

拿不准两套 AI 模型哪个更好？模型 A/B 就是把这个问题变成数据的方法：让两套模型同时在线，一部分用户走 A 版，另一部分走 B 版，其余条件尽量对齐，跑一段时间后比结果。它和部署切换环节的蓝绿部署经常被混为一谈，其实前者比的是效果，后者管的是切换是否平滑。

模型 A/B 到底在比什么

比的对象是同一批真实请求下的表现差异。常见的比较项包括：回答被采纳或继续追问的多少、平均响应时间、人工抽检打出的评分、触发安全拦截的次数。除了模型不同，两组的其他条件要尽量一致——提示词模板、上下文长度、采样参数都要对齐，否则比出来的差距说不清来自哪里。

举个例子，你基于开源底座微调了一个客服模型，想验证它是否强过直接调用 Kimi 或豆包的方案，就让两组真实用户分别走两条链路，一周后再看各自的解决率和响应时长，结论比内部评测集上跑分更有说服力。

两套模型怎么一起跑

做法是在入口处分流：按用户编号、随机数或者时间片，把请求稳定地分成两组，每组固定走一套模型。关键是「稳定」两个字——同一位用户今天走 A 明天走 B，体验忽好忽坏，数据也会被搅浑。分流的实现机制和灰度发布同源，只是目的不同：A/B 是为了比出优劣，灰度是为了控制风险。

类比奶茶店上新：两个窗口各备一款新口味，随机给排队的客人发不同颜色的杯套，凭杯套去对应窗口取餐，晚上数两种杯套各自卖掉多少。这个类比大体成立，但失效的地方也要说清——奶茶试饮人人同杯，而线上两组用户的问题分布可能天然不同，比如晚间用户问得更刁钻，这会直接影响结论。

从对比到决策

跑完数据不等于自动得出结论。差距要大到统计上说得过去才算数：样本太少、差距微弱，都可能是运气使然。实践里常见的做法是先定好评判指标和最小样本量，跑满周期再下判断。如果 A/B 期间新模型偶尔超时拖后腿，先排查是不是算力没备够，这就回到容量规划的问题。

带走一个判断：模型 A/B 的价值在于用真实用户代替拍脑袋，但它只回答「哪套更好」，不回答「为什么更好」，后者要靠人工复盘那些答得不好的例子。服务运行期间的数字怎么看，可参考监控指标一篇；把模型推到设备侧后再做对比，思路可以参考边缘部署。

还有一组容易混淆的概念：内部评测和线上 A/B。评测集是固定题目，跑分快、成本低，但题目再全也模拟不了真实用户的千奇百怪；线上对比用的是活生生的请求，结论更贴近实际，代价是周期长、要动真实流量。成熟的团队通常两步走：先用评测集把明显差劲的方案筛掉，再让剩下的候选上线上比武，省时间也省算力。

模型 A/B 自查清单

• 指标先行：先定好评判指标，再开始分流
• 分组稳定：同一位用户始终走同一套模型
• 条件对齐：提示词、参数、链路其余部分保持一致
• 样本够量：差距小、样本少时不要急着下结论

记住这条：A/B 只负责告诉你哪套更好，解释原因要另做功课。

关于模型 A/B 的三个常问问题

• 两组用户各占多少比例合适？：对半分最常见，流量紧张时也可以先按小比例跑，缺点是攒够样本要等更久。
• 测试期间新模型频繁出错怎么办？：先把它的分组比例调小或暂停分流，排查原因后再恢复，别让对比影响真实用户。
• 必须同时上线两套才能比吗？：也可以前后错开各跑一段时间，但要保证请求分布相近，否则季节性波动会污染结论。