高频辅助任务何时适合换小模型

Intercom 把客服 Agent 的一个高频辅助步骤，从 GPT-4.1 换成了微调后的 140 亿参数 Qwen 模型。据其首席 AI 官 Fergal Reid 回忆，这一步原先每月可能花费约 25 万美元，替换后省掉了其中几乎全部推理支出。负责最终回答的模型则继续使用 Claude Sonnet 4。

这个案例值得读的地方，是它给出了一个可执行的判断顺序：先挑边界清楚的任务，确认未训练的开源模型已经接近，再考虑微调，最后用线上业务结果验证。省钱只是结果，选对替换位置才是关键。

哪种调用适合交给小模型

Fin 在检索之前，会先把用户的问题做摘要和规范化（query canonicalization）。用户可能用口语提问，描述不完整，甚至把问题说错。这个步骤负责整理表达，让后面的检索模型更容易找到合适的资料，进而帮助最终回答。

它任务窄、调用频繁，而且不直接承担最难的用户回答。单次成本看着不大，每个请求都经过它，账单就会积累起来。

他们最初认为，GPT-4 或 Claude Opus 对这一步有些过剩，因此选了性价比更合适的 GPT-4.1。后来，开放权重模型与闭源模型的差距变化、后训练人员到位、产品逐渐成熟，共同促成了替换。作者提到了 DeepSeek 出现前后的模型差距，也说 Qwen 3 在较简单任务上的回测表现不错。

但最关键的门槛在训练之前。

先证明提示词调好的未训练模型已经接近，再花钱微调。

他们会让这个候选模型先进入生产测试，判断它是否有希望接班。基础能力已经够用，后训练才有机会补齐任务细节，并带来更细的控制。如果差距很远，作者的建议是别从这里切。

原文没有说明最终使用的具体 Qwen 检查点、训练样本量和微调方法，因此不能据此复刻训练方案。能拿走的是筛选顺序，而非一套现成配方。

解决率从约 30% 走向 70%，靠的是什么

Reid 把 Fin 描述为由 10 或 15 个机器学习问题组成的系统。上线时，解决率约为 30%，采访时正在接近 70%；他认为，绝大多数提升来自核心大模型周边的系统。

这些工作包括检索模型、排序模型、基于 ModernBERT 几乎从头构建的定制重排器，以及检索前的问题规范化。重排器还使用了他们自己的损失函数。一个环节增加一点，另一个环节再增加一点，最终累积成用户能感受到的改善。

检索模型的训练信号也很具体：当用户确认某篇文章解决了问题，系统就能学到「这类问题适合这类文章」。只盯着最终回答模型训练，就会漏掉这部分机会。

这里需要分开看两件事：周边系统建设用于提高解决率，小模型替换用于降低已知任务的成本、增加控制。原文没有证明，140 亿参数 Qwen 本身推动了解决率从 30% 走向 70%。

最难的回答步骤仍由 Claude Sonnet 4 承担，采访时团队正在迁移到更新的 Sonnet。这次讨论发生在 2026 年 2 月，相关播客为 Chain of Thought 第 49 期，页面标注 2 月 26 日、时长 54 分钟。模型配置应按当时情况理解。

为什么离线赢了，还不能上线

他们遇到的一个反直觉现象是：延迟增加，往往伴随更多问题被解决，连用户明确确认的解决结果也会增加。

团队依然相信，更低延迟通常有利于体验。但固定题集上的回答质量评分，看不到用户因为等待时间变化而改变行为。作者没有给出延迟影响解决率的完整因果解释，所以不能把这个观察变成「故意让回复慢一点」的优化技巧。

为避免把用户离开误判成成功，他们区分两种结果：

• 软解决（soft resolution）：Fin 已回答，自评正确，提供了人工服务选项，用户没有继续发言就离开。
• 硬解决（hard resolution）：用户明确确认问题已解决，例如清楚地表示肯定或感谢。

据 Reid 介绍，硬解决率通常约为软解决率的 30% 到 40%。硬解决是他们最看重的真实信号。候选模型上线时，应观察软解决增加、硬解决不下降，并检查两者比例是否大致稳定。如果只是更多用户沉默离开，就可能是在减少转人工，而没有改善问题解决。

Fin 每周成功解决超过 100 万次对话，Reid 认为实际可能明显更多。从 GPT 切到 Claude Sonnet 的测试，覆盖了数百万次终端用户交互。他们关注的差异小到 0.1 个百分点，因此实验需要足够的统计功效，也就是有足够样本识别这么小的变化。

原文给出的最小代码示意里，这段用于稳定分流，避免同一对话重试时跨模型：

import hashlib

EXPERIMENT_ID = "canonicalizer"

def assign_arm(conversation_id: str) -> str:
    key = f"{EXPERIMENT_ID}\n{conversation_id}".encode("utf-8")
    bucket = int.from_bytes(hashlib.sha256(key).digest()[:8], "big") % 100
    return "small_ft" if bucket < 50 else "frontier"

要看最后一行：bucket < 50 对应 50/50 分流，而稳定性依赖 EXPERIMENT_ID 和 conversation_id 保持一致。这只是分流片段，真正执行请求时也必须遵守同一分配结果。

完整示意还按对话保留最后一条结果，统计 soft_rate、hard_rate 和 hard_per_soft，并用 math.sqrt(rate * (1 - rate) / n) 估算单个比例的标准误。但它不是完整实验库，也没有完成组间显著性检验或样本量计算。

他们也没有在生产环境直接做开放式强化学习。LLM 强化学习留在线下，使用解决结果预测模型作为代理信号，混合回答长度、项目符号数量等检查，以及其他开放权重模型的评判；发布候选再接受线上 A/B 测试。直接学习线上确认反馈的是检索模型。作者认为，客服信号按月变化的速度，足以让离线训练跟上。

我的判断

我赞成先拆任务再选模型。对于有检索链路的 AI 产品，先找一个输入输出稳定、能单独测量的辅助步骤，比直接替换整个回答模型更容易控制影响。

不过，约 25 万美元是 Reid 带有「记不太清」限定的估计。原文没有给出请求量、token 分布、自托管成本、训练费用和维护人力。省掉几乎全部原有推理支出，不等于总成本也按相同比例下降，更不能据此计算普通团队的回本周期。

相较于继续优化提示词、缓存重复请求或使用更便宜的托管模型，微调是否更划算，原文没有提供对照数据。这些替代方案应进入同一张成本表。

实验指标也有一个需要核对的细节：文字描述没有完全说清软解决与硬解决的包含关系，示意代码却用 if/elif 把两者记成互斥结果。照搬前必须先统一事件口径。只盯 hard_per_soft 也不够，因为比例下降可能来自软解决增长，未必代表硬解决率下降，必须结合原始计数和两个解决率判断。

这个案例支持的是一套验证流程，尚不足以支持「微调小模型普遍更划算」的结论。

能拿来做什么

• 如果你的 Node 服务在检索前调用 LLM 整理问题，可以先统计该步骤的调用量、token 成本和失败样例，再挑提示词调好的开放模型测试，确认差距后再决定是否微调。
• 给候选规范化模型保留独立开关，并按会话 ID 稳定分流，让一次用户对话始终经过同一条处理路径，方便定位回归和回滚。
• 在客服 AI 界面中分别记录明确确认解决、沉默离开和转人工，先定义好统计口径，再比较模型。离线摘要评分只能作为筛选信号。
• 如果流量不足以识别 0.1 个百分点的差异，就按自己的流量与可接受损失设计实验，同时核算部署、训练和维护成本，不必照搬 Intercom 的精度目标。