本文内容
小模型微调：Airbnb 分类器给生产系统的启示
产品只需要一个标签：把工单分到正确队列、标记异常，或允许用户提交内容。每个请求却仍然要经过通用语言模型。流量足够大时，这个架构选择会持续产生工程和运营开销。
当产品反复执行稳定的分类决策，你能提供有代表性的标注样本，且预期节省足以覆盖整个系统的运营成本时，小模型微调值得测试。是否采用，要看冻结后的评估能否证明：在预计上线流量下，错误、尾延迟和回退成本都在可接受范围内。
资料核查日期：2026年11月9日。本文基于一手资料，提出评估方法，并给出假设性的成本计算。我们没有复现该模型基准，也没有为本文训练模型。
Airbnb 的分类器基准证明了什么？
Airbnb 报告：其 Gemma4-E2B 定价与支付政策分类器，最高 F1 从 0.563 升至 0.902；服务端 p50/p99 延迟为 35/约 85 ms；训练使用数十万样本，评估使用 10,000 个加权样本。详细提示下，GPT-6.1 Sol 与 Claude Sonnet 5.5 的质量相近；每分钟数千次请求时，该分类器的推理服务成本约为前沿模型 API 的 1%。
这个结果足以支持一次专用分类器实验，却不能替你确定可接受错误率，也不能证明所有专用小模型都有优势。训练后的模型仍需与好的提示方案、更简单的分类器及各自的维护成本比较。F1 不等于准确率，推理服务成本也不等于完整投资。
Google 模型卡将 E2B 列为 2.3B 有效参数，计入嵌入后为 5.1B。应按实际权重文件和运行时测算内存，不能只凭“2B”这个名称做预算。
什么情况下值得用小模型微调做文本分类？
当输出范围明确、决策重复发生，且正确答案的定义能稳定到足以收回投入时，小模型微调是合理的实验方向。我们建议从一个成本较高的分类调用开始，写清它会怎样出错，先比较最简单且可行的方案，再选模型。
微调通过任务样本更新预训练模型。这里真正有价值的资产，是经过复核的“输入与产品应采取的行动”之间的对应关系。历史对话堆积得再多，也只是原材料。
用一页纸写清决策约定：允许哪些标签、决策时能获得什么信息、哪些错误代价高、最长响应时间、如何转交复核，以及谁负责业务规则。例如，客服队列中的“账单问题”可以定义为账务团队能够解决的请求。仅凭消息里出现“发票”一词，远不足以定义这个标签。
接着，在同一批样本上比较规则或传统文本分类器、经过认真调试的 API 提示方案，以及微调后的小模型。如果向量分类器或线性基线能够表达这项任务，也应该纳入实验。把工程投入用在仍未解决的错误上。
如果标签频繁变化、流量不高，或任务需要开放式生成和广泛推理，我们倾向于保留提示方案。如果真正缺的是最新知识，先参考我们的 RAG、微调与长上下文对比，解决前一层架构选择。
小模型微调需要多少标注样本？
样本量应足以画出针对你自己验收标准的学习曲线。一个通用的最低数量，无法说明少见错误、不同语言和客户群体是否已被覆盖。我们建议分阶段投入标注，观察哪些错误在减少；如果瓶颈是标签不清或输入缺失，就停止盲目追加随机样本。
EMNLP 2025 一项覆盖八个分类任务和八个语言模型的研究发现，样本需求与任务特点及性能波动有关。研究中的性能平衡点是在比较质量；财务上何时回本，要另算一笔账。
下面是我们建议的实验流程。子集大小只是规划示例，并不承诺用某个数量的标签就能达到前沿模型的水平。
- 先统一标签定义。让两名复核者分别判断模糊样本。先解决业务规则上的分歧，再训练模型，避免把某个人的猜测教给模型。
- 分开训练、验证和最终测试。先将相关对话或客户记录分组，再切分数据。数据充足时，另外保留较晚的时间窗口，用于检测分布变化。
- 使用逐步扩大的嵌套子集。例如，比较 500、2,000 和 8,000 条复核后的训练样本，保持验证集相同，训练预算可比。如果性能差异小于不同运行之间的波动，就重复训练确认。
- 检查有业务意义的分组。分别看少见标签、每种上线语言、短输入、长输入和政策例外。除了总指标，还要记录错误数量及其不确定性。
- 冻结候选模型和决策规则。最终测试集只用于一次上线判断。如果根据其中的错误继续修改模型，下次最终评估就要保留新的独立证据。
scikit-learn 的数据泄漏指南解释了为何测试数据不能参与模型选择。在我们建议的流程中，模型输入只能包含原始决策时已经可用的信息。把后来的退款结果或人工修正后的工单类别放进输入，会泄漏答案。独立复核后的类别本身仍可以作为有效的目标标签。
性能停滞时，先看错误，再买更多标注。文本是否缺少决策所需的事实？两个标签是否重叠？规则是否已经变化？继续收集同样模糊的样本，补不上缺失的业务规则。确认值得训练后，我们的 Unsloth 与 Colab 上的 Gemma 微调流程介绍具体训练方法。
分类器可以犯哪些错，阈值该怎样定？
生产分类器的阈值应由错误后果决定。对于内容发布关卡，误拦正常提交和放过违规内容，代价可能不同。我们建议先与产品负责人明确边界，再用未参与阈值选择的样本，评估冻结后的决策规则。
scikit-learn 的阈值指南将预测与行动分开，并提醒不要用训练数据调阈值。实验中得分最高的阈值有助于探索；上线报告需要呈现的是实际部署阈值的表现。
可以测试一种三路策略：明确判为非违规的样本自动放行，不确定的样本交给复核，只有经验证据支持时才自动拦截。两条边界都应来自错误预算。没有理由把随手设定的 0.5 当成产品要求。
Guo 等人的校准研究表明，神经网络的置信度可能不能准确反映正确性。具体实现可参考我们的 AnyJev 校准与覆盖率分析，它区分了概率估计质量与自动接受决策的风险。
执行权限也要放在分类器之外。“同意退款”标签可以建议下一步流程，但应用仍需检查谁有权退款、该笔付款是否已退过。这些确定性检查不能交给分类分数代替。
回退到大模型，就能保证答案等价吗？
回退路径不能保证答案等价：小模型可能很有信心地答错，从而根本不触发转交；第二个模型也可能引入自己的错误。我们建议用带标签的决策评估完整路由策略，包括小模型自动接受的错误。只有前沿模型的答案本身合格时，与它一致才有参考价值。
选择性预测研究考察自动接受的覆盖率与风险之间的关系。可以据此提问：在错误预算内，专用模型能处理多少流量？随后再核算转交出去的全部工作。
需要区分两种设计。路由器在生成答案前选择模型；级联系统先运行小模型，再根据结果决定是否转交。在级联方案中，转交请求已经消耗了一次小模型计算。RouteLLM 研究项目评估的是成本与质量之间的取舍，并未声称每个请求都能获得完全相同的答案。
Vercel 的决策回退文档明确说明：触发的阶段依次运行，两阶段都计费。文档还区分了正类概率低与不确定性。模型确定答案为“false”时，不应仅因为 P(true) 较低就转交。
准备上线时，建议记录自动接受的错误、被纠正的错误、回退新增的错误、转交比例和最终延迟。还要抽查自动接受的决策；如果只审核转交请求，最自信的错误就会一直留在视野之外。
算一笔账：专用分类器何时回本？
只有在错误率可接受的前提下，减少的 API 费用超过专用方案的全部增量运营成本，专用分类器才开始省钱。计算要使用实际工作负载，不能只看模型标价。下面的例子说明：即使模型权重完全相同，流量、回退比例、人力和容量也能改变投资结论。
以下是假设规划输入，并非供应商价格或 Wavect 报价：N 表示月请求量；A = €0.003 为每个原始请求的实际平均 API 成本；F = €1,800/月 为专用方案的固定增量成本；V = €0.0002 为每次请求的可变成本；f = 10% 为回退比例。假设每次回退的费用同样为 A。
F 需覆盖所需容量和冗余、运营维护责任、定期标注及重训。V 包括新增的请求处理与验证费用，不重复计算固定托管费用。如果方案需要人工复核，还要加入相应可变费用。两种方案必须达到相同质量目标；若业务损失不同，应另计预期错误成本。
C_api = N × A
C_specialist = F + N × (V + f × A)
N_break_even = F / (A × (1 − f) − V)| 请求数/月 | 仅使用 API | 专用模型、回退与运营 |
|---|---|---|
| 100,000 | €300 | €1,850 |
| 1,000,000 | €3,000 | €2,300 |
| 10,000,000 | €30,000 | €6,800 |
成本持平点是每月 1,800 / (0.003 × 0.9 − 0.0002) = 720,000 次请求。月请求量为 100 万时，专用方案每月节省 €700。若前期数据准备和集成投入假设为 €6,000，在节省金额保持稳定的情况下，约需 8.6 个月才能收回这笔启动投入。
再做敏感性分析：固定运营成本翻倍至 €3,600，持平点升至每月 144 万次请求。固定成本不变、回退比例增至 40%，持平点则为每月 112.5 万次。如果公式分母为零或负数，在这些假设下，再高的流量也无法摊回固定成本。
表中 1,000 万次请求对应的一行假设原有容量能承受该流量，需要实测验证；新增计算实例会使 F 阶梯式上升。应以实际输入输出比例、缓存和商务条款替换平均 API 估算。如果转交请求更长或更难，就给它们单独计算平均价格，不要继续套用 A。
分类器很快，整个产品就会变快吗？
只有其余处理环节也能控制在产品延迟预算内，快速分类器才能改善完整体验。应从收到请求开始，计时到用户可观察到相应动作为止，包含排队、预处理、验证和转交。我们建议分别报告普通路径与回退路径的分布，并测量代表性负载下整体的 p95 和 p99。
举一个延迟预算示例：产品要求 200 ms 内完成，可分配 40 ms 给接入和预处理、80 ms 给模型、30 ms 给规则检查，余下 50 ms 留作余量。这些是建议分配，不是实测组件耗时。若第二个模型会阻塞响应，它也必须满足同一时限，否则流程需要明确的待处理或复核状态。
不要把各组件的 p99 相加，就称为测得的端到端 p99。应使用请求链路记录。如果较多请求进入慢速回退路径，它可能主导尾延迟，即使中位数仍然很好看。还应在计算实例重启和突发流量下重复测试，再决定增加容量，还是调整用户交互。
分类器试点上线前，必须证明什么？
分类器试点应与一个确实可以上线的基线比较，形成书面的上线或停止结论。我们建议保留数据质量、自动处理中的错误、完整链路延迟和全部成本的证据，并明确复核与回滚负责人。以下是建议的验收方法，具体限值应由产品要求和风险容忍度决定。
| 要回答的问题 | 保留什么证据 | 何时暂停 |
|---|---|---|
| 标签可靠吗？ | 带版本的标注规则、分歧复核、数据使用权限和切分清单 | 复核者无法就影响上线决策的样本达成一致 |
| 自动接受的决策达标吗？ | 冻结的阈值、混淆矩阵计数、高风险分组及不确定性 | 高代价误报或漏报超过约定预算 |
| 转交真的有帮助吗？ | 覆盖率、仍被自动接受的错误和最终回退结果 | 高置信度错误依旧未被观察 |
| 产品满足时限吗？ | 突发负载及计算实例故障下的端到端 p95/p99 | 慢速路径违背用户可见的响应约定 |
| 投资能回本吗？ | 实际流量、完整成本、容量阶梯和启动投入回收期 | 合理的回退或人力变化就让节省消失 |
先以影子模式运行候选方案，再进行范围受控的灰度上线，并记录触发回滚的条件。新系统尚未证明能处理预期流量前，保留原有基线。业务规则、客户构成或输入分布发生变化时，重新评估。
在 Wavect，我们会先明确决策约定，再分析错误。我们的机器学习开发服务覆盖模型适用性判断和实现。Twinsoft AI 案例提供相关 AI 交付背景，并不证明我们部署过类似 Airbnb 的分类器。关于自建与采购的责任划分，可参考定制软件与现成软件选择指南。
准备一份代表性样本、当前 API 账单、期望响应时间，以及代价最高的错误，再进行分类器可行性讨论。有价值的首项交付，可以是有依据的实验方案，也可以是有依据的保留现有系统建议。