欢迎访问本站，持续更新中…
RSS

WikiFw 维基框架

4B模型检索打平GPT-5.6 成本只要1%

4 天前 检索RL后训练RAG成本优化开源模型

4B模型检索打平GPT-5.6 成本只要1%

数据库检索与AI检索管道场景

做 RAG 的团队这两年应该都有同感：检索从一次查询变成了一个循环。2022 年那会儿，pgvector 是最流行的方案，把文档切成块、embedding 进数据库、算相似度，一次查询完事。到了 2025 年，agent 化检索成了主流——模型先规划，再搜好几轮，每轮之间根据结果调整下一步。能力是上去了，代价也上去了：循环里的每一次调用都要走一次前沿模型。

Neon 在 8 月 5 日的博客里给了一个具体数字：用 GPT-5.6 Sol 做一次典型的多轮检索请求，端到端超过 10 秒，成本大约 0.03 美元。单看一次不算贵，但 agent 应用里这是每个用户请求的固定开销，量一大，模型账单就成了产品的成本结构问题。

训练贵一次，推理便宜一百倍

Neon 和 Castform 合作展示的路线是：别让前沿模型在推理时反复烧钱，把能力提前灌进一个小模型。他们用 Castform 对一个 4B 参数的开源模型做强化学习后训练，在检索任务上准确率和 GPT-5.6 Sol 对齐，成本是后者的百分之一。

Castform 做的事情是让 RL 后训练的门槛低到"像调 prompt 一样"。整个流程绕不开三样东西：任务、环境、奖励函数。任务来自企业自己的语料——内部文档、产品记录、支持工单、wiki，这些数据大多已经在数据库里躺着。Castform 用合成数据生成把语料变成训练任务，奖励函数定义模型要擅长什么：检索到正确的块、引用正确的来源、给出正确的答案，三者加权打分。

检索成本对比：前沿模型多轮调用 vs 小模型

训练和推理用的是同一个工具调用——混合检索（BM25 加向量检索做 RRF 融合）。这一步很关键：训练时模型学会的是"用这个工具、按这种方式搜索"，推理时工具不变，行为才能迁移过去。

钱省在哪，代价在哪

这笔账的本质是把成本从推理端挪到训练端。训练一次要花钱花时间，但训完的模型每次推理几乎免费，100 倍的成本差就是这么来的。前提是任务足够专用——检索就是典型场景，目标明确、工具固定、奖励函数好定义。任务越宽泛，后训练就越难奏效。

需要提醒的是，这是 Neon 自己博客上的数据，没有独立评测。4B 模型"打平 GPT-5.6 Sol"限定在检索任务上，不是全面能力对标。任何厂商自测的 benchmark 都应该这么看：看方法，看场景边界，别直接当结论用。

训练 stateful agent 的工程细节

文章里有个容易被忽略的工程点：Neon 的数据库分支（branching）用来给每个训练 rollout 提供隔离的数据库状态。RL 训练是上千个并行 rollout 同时跑，每个 rollout 都要做几十次搜索调用，负载很突发。如果 agent 开始改数据，还需要每个 rollout 有独立的、可以廉价创建和重置的环境——一个 rollout 的动作不能污染另一个，更不能碰到生产数据。分支隔离加 time-travel 查询可以重建 agent 当时面对的状态，配合自动扩缩容和 scale-to-zero，训练几千个有状态 agent rollout 就不需要维护几千个常驻环境。

这个思路对做 agent 训练基础设施的团队有参考价值：环境隔离不是事后补的，是训练流程的一部分。

对大多数团队来说，真正值得思考的不是"我该不该后训练一个 4B 模型"，而是"我的 agent 检索成本结构是不是已经失控了"。多轮检索、每轮调前沿模型，这种架构在小流量下没问题，上量之后账单会先于用户体验出问题。把检索这类高频、目标明确的任务从通用模型上拆下来，无论是换小模型还是后训练专用模型，都是值得先做一次成本测算的方向。奖励函数怎么防 reward hacking、语料更新后模型要不要重新训练、后训练的模型怎么持续跟进数据变化，这些问题都还没有成熟答案——但至少，检索这条路被证明是走得通的。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。