Neon 和 Castform 联合发布了一篇博客，展示了一个惊人的结果：一个 4B 参数的开源模型，经过 RL 后训练之后，在检索任务上的准确率追平了 GPT-5.6 Sol，但每次请求的成本只有对方的 1/100。

具体来说，GPT-5.6 Sol 做一次典型的多轮搜索请求需要超过 10 秒，端到端成本约 0.03 美元。对于需要反复搜索的 agent 工作流来说，这个速度和成本都"高得让人没法用"。而 4B 开源模型在推理速度上快了几个数量级，成本低了两三个数量级。

问题在于，小模型开箱即用时的检索能力确实远不如闭源前沿模型。差距在哪？就在 RL 后训练。

从 RAG 到 agentic 搜索

博客回顾了 agent 搜索的演进路径。2022 年左右，行业押注的是 embedding 搜索，pgvector 是 Neon 下载量最高的扩展。开发者手动搭建 RAG pipeline，本质上就是某种 embedding 相似度搜索。

到了 2025 年，agent 开始真正落地。开发者不再满足于一次搜索得到结果，而是创建多跳搜索工作流——把大问题拆成小问题，模型在循环中反复规划和搜索。每次循环迭代需要再调用一次前沿模型，延迟和成本同时飙升。

一个行业共识正在形成：未来不是"更大的模型解决一切"，而是"小模型 + 针对性后训练 = 特定任务上超越大模型"。

Castform 做的就是这件事——让开发者不需要了解机器学习和 GPU 内部细节，就能对模型进行 RL 后训练。他们的目标是让后训练变得像 prompt engineering 一样简单。

用你自己的数据训练自己的模型

Castform 的核心洞察是：大多数公司最好的训练数据已经存在于他们的数据库里了。

内部文档、产品记录、支持文章、客户交互、wiki、运营数据库——这些数据里有 agent 需要的所有知识。但把这些原始数据变成有效的训练数据集，通常需要大量的数据工程和人工标注。

Castform 的工作流程是：从你的语料库中自动生成训练任务 → 管理 RL 循环 → 输出一个能在你的数据上高效搜索的专用模型。

具体来说，流程是这样的：

1. 合成数据生成：从你现有的文档中提取 ground truth，自动生成问答对。例如，从"通过 Navan 预订的火车票将由 GitLab 旅行卡支付。火车行程必须是标准舱位，提前 14 天预订"这样的文档中，生成"预订 Navan 铁路旅行时，需要提前多久预订，应该选择什么舱位？"之类的问题。

2. RL 训练：在 Neon 的 Lakebase Search（hybrid search = BM25 + vector + RRF 合并）上运行。每个 rollout 中的搜索工具调用都使用 Lakebase Search。

3. 奖励函数：评分模型在三个维度上的表现：是否检索到了正确的源文档、是否引用了正确的片段、是否给出了正确的最终答案。

Neon 的底层为什么是关键

训练过程中，agent 反复调用 Lakebase Search，数千个并行 rollout 各自可能发出数十次搜索调用，形成了一个高度突发的工作负载。Neon 的动态计算伸缩可以吸收这些峰值，不需要 Castform 为最大容量持续预留资源。

更重要的是，Neon 的数据库分支（branching）让每个 rollout 都能获得一个隔离的数据库状态。不同 rollout 之间互不干扰，也不会触及生产数据。时间旅行查询（time-travel queries）可以重建和审查 agent 遇到的状态。这意味着你可以训练数千个有状态的 agent rollout，而不需要维护数千个持续运行的环境。

这篇博客本质上是一篇合作案例。Neon 解决了"怎么给 agent 提供正确的数据"的问题，Castform 解决了"怎么让模型知道搜什么"的问题。两者结合，一个 4B 模型做到了 GPT-5.6 Sol 级别的检索准确率，成本降低 100 倍。

开源模型 + 后训练 + 专用基础设施 = 前沿模型的替代方案。这个公式正在越来越多的领域被验证。

参考来源：

• Neon 博客：How Castform + Neon Beats Frontier Models on Price and Efficiency
• HN 讨论