Skip to content
←

필사 모드: 「便宜 100 倍」这个主张，只有在任务被收窄时才成立 —— 验证与盈亏平衡

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

当一篇标题里带着 100 倍的文章丢进你的频道

团队频道里冒出一个链接。内容是：把开源模型做了后训练，在检索任务上赢过了前沿模型，而且便宜 100 倍。紧接着就跟来一个问题：我们是不是也这么干就行了？

与其用「那就试试吧」或者「那是营销」来回答这个问题，不如把原文里能确认的和不能确认的分开，这要有用得多。因为结论通常不是这两者之一，而是有条件地为真。

原文实际做了什么

这篇文章是 2026 年 8 月 5 日公开的 Beating GPT-5.6 Sol on retrieval with 100x cheaper open models。这是 Castform 和 Neon 双方人员合写的案例报告，概括起来是这样。

他们把一个 40 亿参数级的开源模型，针对检索任务用强化学习做了后训练。训练数据是从自有语料合成出来的，检索用的是关键词得分与向量相似度并用的混合方式。奖励函数分别对检索质量、引用准确性、最终答案准确性打分。训练期间，数千个并行 rollout 各自触发几十次调用，产生非常起伏不定的负载。

原文的核心句子是这样一句：在检索这类特定任务上，经过后训练的开源模型可以与前沿模型打平甚至胜出，而单次请求的成本可以低上一个数量级。这里，特定任务这个限定语占了这句话的一半。

检索为什么很适合这套做法

这个结果出在检索上并不是偶然。它具备三个适合被做成窄任务的条件。

第一，成功可以用代码判定。检索到的文档里有没有正确答案的依据、引用是不是指向真实存在的文档，都可以不靠人来评分。这意味着奖励函数造得出来，而这正是后训练的前提条件。

第二，输出空间很窄。生成查询、挑选结果、附上依据，这些事情几乎不需要自由撰写。

第三，领域语料是固定的。前沿模型的长处 —— 广博的世界知识 —— 在这里不算什么优势。需要的知识就在被检索的文档里。

这三个条件缺了任何一个，同一套策略的成功概率都会大幅下降。把自己的任务代进去时，先确认第一个条件，才是正确的顺序。

举个反例就有感觉了。回答客户咨询的客服助手，三个条件里没有一个能干净地满足：什么算好答案没法用代码判定，输出是自由撰写，而且不断需要公司政策之外的常识。把同一套方法原样搬过来，在造奖励函数这一步就已经卡住了。

能确认的数字与确认不了的数字

这里有必须老实区分的部分。我在原文中能确认到的具体数值，都在比较对象那一侧：一次多轮检索请求在前沿模型上要花 10 秒以上，端到端成本大约在 0.03 美元的水平。

反过来，后训练模型的准确率是多少、在哪个评测集上用什么方式测的，这类可以被独立验证的数值，我在原文里没能确认到。文中有「性能相当」的表述，但没有第三方能够复现的那种表格。

而且这篇文章是由卖数据库产品和卖训练平台的两家公司合写的。这绝不意味着结果是假的，但读的时候应该把「任务选择和比较条件可能对自己有利」这种可能性考虑进去。所以从这篇文章里该带走的不是数字，而是方法与条件。

后训练何时优于路由

方法带回来了，接下来就是算账。后训练是固定成本大、可变成本小的选择；路由和提示词优化是固定成本小、可变成本大的选择。哪一边更好，由量决定。

"""后训练的盈亏平衡：按回收时点判断，而不是按节省比例。"""
from dataclasses import dataclass


@dataclass
class Option:
    name: str
    fixed_cost: float      # 训练、数据构建、评测集制作（一次性）
    monthly_ops: float     # 服务基础设施、重训练、值班
    per_request: float     # 单次请求成本

    def total(self, monthly_requests: int, months: int) -> float:
        return (
            self.fixed_cost
            + self.monthly_ops * months
            + self.per_request * monthly_requests * months
        )


def break_even(a: Option, b: Option, monthly_requests: int, horizon: int = 36):
    """找出 a 首次比 b 便宜的那个月。没有就返回 None。"""
    for m in range(1, horizon + 1):
        if a.total(monthly_requests, m) < b.total(monthly_requests, m):
            return m
    return None


frontier = Option("前沿 API", fixed_cost=0, monthly_ops=0, per_request=0.03)
tuned = Option("后训练 4B", fixed_cost=60_000, monthly_ops=4_000, per_request=0.0003)

for volume in (50_000, 500_000, 5_000_000):
    m = break_even(tuned, frontier, volume)
    print(f"每月 {volume:>9,} 次 -> 回收时点: {m if m else '36 个月内没有'}")

这段代码里重要的是 monthly_ops。只比单次请求的单价，后训练看起来总是压倒性的；可实际上服务基础设施、重训练和值班是每个月都要花出去的。把这一项当成 0 来算的方案书，是实务中最常见的错误。

怎样测量被收窄的任务的边界

还有一项没进入计算的成本。后训练模型在边界之外会悄无声息地变差。前沿模型面对陌生请求还能勉强应付，而被窄训练过的模型一旦离开训练分布，就会自信满满地答错。

所以引入时需要的是边界检测。实务上能用的最小配置有三项：输入嵌入到训练分布中心的距离、模型对自己给出结果的自信度，以及混合检索中关键词得分与向量得分是否严重背离。三项里只要有一项越过阈值，这个请求就往上交给前沿模型。

这个回退比例一开始定得宽裕些、比如 20% 左右，再看着真实数据往下压，会更稳妥。而且这个比例必须原样进到盈亏平衡的计算里。

真正的成本在维护这一侧

原文之所以花很长篇幅讲训练期间的负载，是有原因的。后训练不是做一次就完事的工作。语料变了要再做一次，用户查询分布迁移了要再做一次，奖励函数的漏洞暴露出来了还要再做一次。

也就是说，这个选择不是「换个模型」的决定，而是给团队新增一个运维对象的决定。你需要训练流水线、合成数据生成器、评测集、服务栈，以及一个把这些全都懂的人。在人手少的团队里，这份成本很容易压过单次请求单价的差额。

尤其是奖励函数，绝不是写一次就完。把检索质量定义成文档命中，模型就会被训练成生成命中率高的宽泛查询；把引用准确性压得很重，它就可能倾向于安全地大段照抄原文。这类偏差要等训练结束、在真实使用日志里才会浮现，所以把奖励函数的修订与重训练排成定期工作，才比较现实。

引入之前要过的检查清单

总结起来是这样。只有当下面五项都能回答「是」，才进入下一步。

项目确认问题
可判定性成功能不能不靠人、用代码来评分
输出宽度答案是以固定形态给出，而不是自由撰写吗
量盈亏平衡的计算里，回收时点是否落在 12 个月以内
边界能不能检测出偏离训练分布的请求并往上转交
人力有没有人能持续把训练、服务和评测运转下去

最后还有一条。就算这五项都过了，先该做的也不是后训练，而是试着把提示词和上下文精简一下。单次请求成本里相当一部分来自输入的大小，而不是模型单价，而那一边几天就能试完。被 100 倍这个数字牵着走、先开一个好几个月的项目，才是最贵的错误。

参考资料

현재 단락 (1/60)

团队频道里冒出一个链接。内容是：把开源模型做了后训练，在检索任务上赢过了前沿模型，而且便宜 100 倍。紧接着就跟来一个问题：我们是不是也这么干就行了？

작성 글자: 0자원문 글자: 3,595자작성 단락: 0/60