真实工作流，正在成为下一代训练数据

数据市场的故事，正在进入新一轮周期。来自企业真实工作流的 Real-world Data，成为越来越多 AI Labs 争夺的新资源。

比如 GitHub 就是典型的 Real-world Data，它几乎完整保留了一个问题从出现到解决的全过程。相比之下，今天绝大多数 Human Data 公司提供的，仍是人为构造的数据。

这篇文章整理了近期关于数据赛道的阅读与交流笔记，大多来自一线从业者的观察和复盘。一个结论是，如果你是 VC，不应该投资一家对 Real-world Data 没有路线图的公司。如果你是 SPL，也不该长期停留在项目交付，不如尽早向更技术化的能力升级。

最近和不同 AI labs、数据公司交流时，我们会感受到一个明显的趋势：real-world data，也就是企业真实工作流中产生的数据，正在成为新的训练需求。

相比已经被充分挖掘的互联网数据，这仍是一座尚未开采的矿藏，淘金者才刚刚进场。

这个市场有意思的地方，是数据和利用数据的能力恰好分布在两端：模型公司通常是 MLE (Machine Learning Engineer)-rich、data-poor。企业则完全相反，data-rich、MLE-poor。

在这个趋势下，我们观察到市场上出现了两类公司，他们是这一个市场的一体两面：

• Human data company：服务模型实验室，提供数据。

• RLaaS (RL-as-a-service) company：服务企业，把企业自己的业务流程转化为可训练的模型环境。本质上卖的是外包 MLE 咨询 + agent system 搭建 + post-training 服务。

这篇文章整理了我们最近对这个数据赛道的 20 条阅读笔记和交流笔记，其中基本都是一线从业者的观察和复盘。具体 reference 附在文末，方便大家自行延伸阅读。

01

数据市场是一门冲浪生意

1. 数据市场是一门冲浪的生意。数据需求会长期存在，但每当一个能力瓶颈被突破，「最有价值的数据」就会换一种类型和形态，因此整个数据市场的玩家也在跟着模型的训练范式不断翻页。

2. 过去几年，每一轮新的数据需求，都带来了一批新的赢家。Scale AI 抓住了自动驾驶和早期 LLM 的数据标注机会；Mercor、Surge AI 和 Handshake 赶上了专家数据浪潮；当训练进一步转向真实工作流时，Protege、Sunset、SF Data 等新公司又开始出现。

与此同时，老玩家也在紧跟 frontier labs 的需求调整方向。Mercor 和 Handshake 最近都开始讲企业数据的故事，为下一轮浪潮提前卡位。

3. 新一波浪潮：Real-world Data。

过去几年，frontier labs 的预算重点从专家标注转向 RL environments，到如今又开始关注 real-world data。

核心原因是 Long Horizon 是模型进步最关键的一个主线方向。模型处理任务的单位，正在从一次代码修改，上升到一个文件、一个 codebase，最终是一整个 project。

任务越长，人工搭环境就越难。真实项目里充满了历史状态、工具依赖、组织规则和意外分支，这些细节很难靠专家坐在沙盒里凭空编出来。因此，Frontier labs 开始需要采购真实世界的数据。

4. 数据和 RL 市场还远未饱和。虽然这个市场的淘金热升温很快，但总体上，供给并没有跑过需求，大量真实的白领工作、企业流程和专业知识，至今没有被转化成模型可以学习的数据，或可以反复训练的环境。未来应该会出现越来越多围绕「数据生产」和「环境生产」的公司，甚至可能出现一些新型中间层公司 (e.g. 企业数据中介，专家网络)，形成一条更成熟、分工更细化的供应链。

02

如何做好一家数据公司

1. 根据数据来源，今天市场上的数据可以被分为两类：

• Type 1：从真实工作中捕获的数据它比较接近「工作过程录像」，比如 Session replay、屏幕操作、公司内部协作记录。最好的 Type 1 数据不仅记录动作，还能还原动作背后的意图。比如 GitHub 就是很好的 Type 1 数据。Commit message、issue 和 ticket resolution 串在一起，几乎完整保留了一个问题从出现到解决的过程：一个人想解决什么、尝试了哪些修改、为什么这样改，以及最终是否被接受。
• Type 2：人为构造的数据这就是现在绝大部分 human data 类公司在做的事情：找领域专家→人工设计任务→让他们在设计好的环境里完成工作→收集结果→再加工成模型可训练的格式。

2. Type 2 很适合做预训练或早期能力爬坡，但当模型开始处理链路更长、经济价值更高的任务时，Type 1 数据会变得越来越重要。

但纯粹的 Type 1 数据很难拿到，现实中更可行的是先实现 Type 1.5 的中间形态，即把 Type 2 做得更像 Type 1。这通常包括：

• 长期绑定少量高质量专家，并让他们理解基本的 reward shaping 和模型训练逻辑；
• 重新设计激励机制，人类往往比模型更擅长 reward hacking，所以要防止人类标注员乱标数据；
• 设计多层 QA (质量检查)。让运营团队 QA 外包，ML 工程师 QA 运营团队，最终交付前所有人都从不同维度进行检查。并把成熟的检查方法逐步工程化，包括异常检测、贡献者行为分析，以及用实际训练效果反向检验数据质量。

3. 设计训练数据的时候，真正重要的是 hillclimbability（爬坡能力）。

很多公司在设计任务的逻辑是：只要我做出一个模型不会的任务，就能证明这里有机会。但问题在于，设计一个让前沿模型做不出来的任务并不难。难的是让任务刚好卡在模型能力边界上，使它既有挑战性，又仍然可以通过训练逐步爬坡。

可以设想两种情景：

• pass@1 = 0%，pass@32 = 30%。即模型一次尝试做不对，但允许模型独立探索 32 次后，有 30% 的概率能够成功。这证明模型已经偶尔摸到成功路径，只是还不稳定。这个任务就正好卡在模型的能力边界上，很有训练价值。
• pass@1 = 0%，pass@256 = 0%。尝试 256 次依然没有一次成功，说明任务远超模型当前能力，或者任务本身太偏门，这就往往不是一个好的训练 benchmark。

4. 如果看今天的数据市场，还存在四类问题：

• 数据失真：Type 2 经常被包装成来自真实工作的 Type 1。
• Eval 失真：数据公司会设计一些不够贴近真实工作的 eval，当 SOTA 模型已经能开箱即用地做好某些 eval 时，供应商还会刻意增加难度，制造「模型还有很多提升空间」的假象。尤其当研究员或采购方自己不是该领域专家时，这招很有效。
• QA 不可规模化：很多公司把 QA 当成一个运营问题，通过堆人力，多加几层人工审核来解决。但 QA 本质上应是工程问题——靠自动化质检、数据追溯、环境生成和评测系统，把质量稳定地嵌进生产流程。工程团队如果总在忙一次性的客户定制，长期就很难搭起真正可规模化的数据能力。
• 需求传递失真：Researcher 自己有时也未必能把数据需求交代得足够清楚，或者做好质检工作。但如果 model labs 在内部单独设一个 data 采购团队，又要在 researcher 与外部供应商之间多加一层沟通，信息传递又会多一道磨损。这也是为什么不少实验室仍把数据采购预算直接交给 researcher。

5. 一个数据供应商能否获得 model labs 的信任，通常取决于三种能力：

• Data taste：是否真正知道好数据长什么样，也就是把握数据质量的能力；
• Research taste：知道模型现在卡在哪里，也知道该为这个问题寻找什么类型的数据；
• Scalability：能否在规模扩大后，依然维持同样的质量。这一点很容易被轻视，因为很多公司在 demo 阶段会找最好的专家，由创始人亲自盯项目，再叠加大量人工 QA，因此小规模交付看起来非常漂亮。但这并不意味着它们能够把同样的质量复制 10 倍、100 倍。

6. 随着旧金山小圈子里「卖 RL 环境 / data」的淘金热升温，越来越多创业者涌入这个市场，但 model labs 的 researcher 已经听腻了这些公司的 pitch。

今天想真正获得研究员的信任，需要能真正证明前面这三点能力，证明的方式包括：

• 发布 benchmark 和技术文章；
• 用自己的数据训练模型，展示实际提升；
• 提供可审计的 data lineage，说明数据来源、清洗过程、专家资质和 QA 机制。

7. 可以通过招聘结构粗略判断公司 DNA：

更偏 Type 2 的公司，通常更重项目管理和运营，会频繁招聘 SPL (Special Project Leads)，本质上是在不断接订单、扩团队、做定制交付。而真正想向 Type 1 靠拢的公司，几乎只招「members of technical staff」，重点放在数据工程、环境工程和 QA 自动化。

前者在「卖人力」，后者在「建工厂」。

随着数据价值不断向 Type 1 迁移，Type 2 的窗口可能只剩两年。

所以，如果你是一个 VC，不应该投资一家对 Type 1 没有任何路线图的公司。如果你是一个 SPL，也不该把自己长期锁在项目交付里。你手上的 lab 人脉足够值钱，不如自己补一点技术能力，出来做一个更技术化的新玩家。

03

RL 如何持续进化

1. RL environment 到底是什么?

RL environment 可以理解为，一个模型能够进入、调用工具、完成任务、被检查和得到奖励的软件环境。

以一个销售运营 agent 为例，它的环境里可能包含：模拟 Salesforce、邮箱、客户数据库、产品文档、审批系统等。

假如我们给到 Agent 一个任务是：找出过去三个月流失风险最高的 20 个客户，为每个客户准备个性化续约邮件

为了完成任务，模型需要：查询数据→理解客户历史→判断流失风险→调用 CRM→写邮件→生成报价→提交审批。

环境则会根据一组预设规则进行评分：找对客户了吗？风险判断合理吗？邮件是否符合要求？报价是否合适？是否在适当时间内完成？

2. 一个明显趋势是，Agent 的环境和任务都在变得越来越复杂，最主要的 4 个变化方向包括：

• 空间变大：一个 agent 不再只在一个沙盒里完成所有工作，而是能穿梭于多个 environment。
• 工具变活：未来 agent 可能直接调用一些输出结果并不确定的工具，比如，环境中的「搜索工具」不一定是传统搜索 API，也可能是另一个 SOTA model，因此 agent 还要学会控制参数、判断结果和交叉验证。
• 组织变复杂：复杂任务会由一个 agent 拆解并分配给多个 sub-agent，再统一汇总结果。这时，reward 不仅要衡量任务是否完成，还要考虑成本和 latency。同样的结果，40 分钟完成和 3 分钟完成，商业价值完全不同。
• 任务边界上移：模型变强后，任务拆法也会变化，原来需要拆成 20 步训练的任务，可能变成 1 步就能确定性地做好。于是 RL env 的训练目标也会不断上移，从训练模型执行一个动作，到完成一个子流程，再到规划和编排一整套工作流。

3. 什么样的 RL 数据最适合模型学习？

Jason Wei 提出过一个 Verifier's Law：训练 AI 解决某个任务的容易程度，与该任务的可验证性成正比。最终任何可以被衡量的，都可以被优化。这种可验证性主要包含 7 个维度：

4. 这里要额外强调的一点是，RL 的关键不只是「结果是否可验证」，还有「环境能否反复重置」，让模型获得足够多的练习。

Coding 特别适合强化学习，不只是因为有清晰的 reward signal，更因为整个环境很容易复制、并行和重置。一个代码仓库可以复制成上万个 container，模型可以不断改代码、跑测试、失败后重来。即使每次学习效率很低，也可以靠海量尝试把能力堆出来。

但真实世界没有这么多存档点。比如，「在 Amazon 上成功买到一件商品」当然可以验证，但很难让模型同时复制出一万个真实 Amazon，在每个副本里下单、付款、重新开始。即使人工仿制一个电商网站，也需要维护库存、付款、账户、物流等大量细节。

进入真实世界则更难，创业、管理、投资、法律、销售都有结果，但很难开出一万个平行世界，让模型反复尝试。它们反馈慢、因果关系模糊，而且每次机会都不可重复。

因此，未来 AI 要进入真实世界，不能永远依赖暴力刷题，它必须提高自己的 sample efficiency，从少量、不可重复、反馈模糊的经历中，快速提取可以迁移的规律。这仍然是人类相对模型最明显的优势之一。

5. 目前外界对如何提高 sample efficiency 有几种想象，比如：

• 思路 1: OPSD (on-policy self-distillation）

它可以被理解成一种「经验压缩」机制。

假设一个模型已经和用户一起工作了一周。到了第七天，它的记忆里会逐渐形成对这个组织的理解：它知道用户反复纠正过哪些问题，哪些方法已经试过但效果不好。

此时的模型像一个熟悉了公司的老员工。

接下来，可以让这个「老员工模型」充当 teacher，指导一个没有看过完整历史记录的基础模型。Student 不需要记住过去一周发生的每个细节，而是要学会 teacher 最终形成的判断方式：哪些信息更重要、什么时候应该追问，以及什么情况下可以直接行动。

这和把聊天记录拿去做 SFT 不同。普通 SFT 很容易让模型学习如何复述 transcript，连其中无关紧要的细节也一起记住，OPSD 想蒸馏的是经历之后形成的 policy。

它的另一个优势在于，监督信号不必只来自最终的成功或失败。即使一个项目最终需要几个月才知道结果，带完整 context 的 teacher 也可以在过程中的每一个决策点给出更好的行动示范。

因此，稀疏的现实反馈可以被转化为相对密集的训练信号。

• 思路 2: Dreaming

如果说 OPSD 是向内压缩经验，那么 Dreaming 就是向外展开经验。

模型在完成一天工作后，不只是简单总结发生了什么，而是基于已有经历，建立一个内部的 world model，并在里面继续做大量模拟。

比如，模型白天只经历了一次客户谈判。到了晚上，它可以继续推演：客户提出不同反对意见时怎么办、如果换一种定价策略会怎样、如果换一种沟通方式，结果会不会更好。

然后模型在这些自己生成的模拟世界里反复练习，再更新自己的权重。

这和人类的学习很像。人并不是只有在真实事件发生时才学习。我们会复盘、想象其他可能性。一场重要对话可能只发生了十分钟，但之后几小时的反思会让它产生远超十分钟的信息量。

一个比较接近的例子是，在 DeepMind 发布 AlphaZero 几年后，一组研究人员训练出了一个叫 EfficientZero 的模型。

假设 EfficientZero 和一个人类都只有 2h 可以和一个此前从未见过的游戏模拟器互动，最后 EfficientZero 很可能会战胜这个人类新手。

因为 EfficientZero 在真实游戏中每走一步，都会在自己的内部模型里模拟几十局游戏。表面上，它和真实环境只交互了少量次数，但在内部，它其实已经进行了大量练习。

如果模型能在泛化环境里做到这一点，这可能在 pretraining、RL 和 inference-time compute 之后形成一条新的 scaling 路径，也可以叫 test-time training。

04

企业要自训模型吗？

1. 如果工作流正在变成训练数据，企业要不要也考虑自己 post-train 模型？

硅谷这方面的讨论越来越多，但目前看，这个市场还处于相当早期，企业自己 post-train 模型，主要出于两个方面原因：

• 通用模型不理解企业的独特偏好。

典型比如客服场景，通用模型被训练得友好、顺从，但企业不希望模型面对退款有求必应，所以 Sierra、Decagon 等客服公司是最先自研模型的。

• 成本考虑。

Cursor 是一个典型例子，Claude Code、Codex 都在大量补贴自己的产品，Cursor 如果一直按外部 API 价格买模型，就等于每增长一个用户，都要向竞争对手交一笔过路费，让他们能降价补贴自家产品。所以 cursor 必须自研模型，做到能力达到 Frontier 的 80-90%，价格是他们的 1/5-1/10，用户体感上竞争力才相近。

今年，硅谷一些垂直 AI 公司，比如 Harvey 等也开始沿着类似路径试水。今年上半年企业 AI 用量指数增长，但 token 成本受算力限制居高不下，造成了非常明显的毛利压力，所以目前这些公司首先在探索更好的 model routing，其次就是开始考虑自己 post-train 模型。

2. 企业该怎么判断自己要不要试水 post-training？

自己 Post-train 模型本质上是用 Capex 换 Opex，用一次性训练成本替代长期重复的推理开销。

这笔账能不能算过来，大体取决于四个乘数：数据独特性 × Eval 清晰度 × 任务频率 × 单次改善价值。其中任何一个乘数接近于零，这笔投资都很难成立：

• 数据越独特，通用模型越难直接学会；
• Eval 越清晰，训练越容易稳定优化；
• 任务发生得越频繁，训练成本越容易被摊薄；
• 每次能力提升带来的价值越高，post-training 的 ROI 也越大。

一个典型案例是 DoorDash 的菜单录入。每年超过 10 万家商户入驻 doordash，他们会上传菜单图片，系统需要提取其中的信息，再按照 DoorDash 的内部规则，转换成电子菜单。

通用模型虽然能识别菜单，但不知道 DoorDash 内部关于商品、modifier、add-on 等细节的具体规则。所以他们和外部 RLaaS vendor 合作，用内部数据自己 RL 了一个能理解自己业务标准的小模型。

3. 应用公司自己 post-train 模型的优势是什么？

1. 应用公司最重要的资产，是它占据了真实用户的工作流入口，天然能拿到高质量、完整的 agentic trajectory data。这类数据在外部市场昂贵，高质量轨迹的单条报价可以达到上千美金。
2. 企业任务的范围通常很窄，既不用在乎跨领域的泛化能力，也不用在乎其它产品环境的泛化能力，所以可以很高的资本效率做专项 RL。比如 Cursor 至今的一大优势是，OpenAI、Anthropic 其实不敢直接做太多 coding RL，因为模型还要做 PPT、Chat 等其它任务，如果做太多 coding RL，其它能力就容易退化，但 Cursor 没有这个顾虑。

4. 除了 Cursor 之外，其它通用领域的 Agentic 数据能拿来训练模型吗？

事实上，coding 之外的 agentic trajectory data 反而非常稀缺和珍贵。即使没有 coding 那么清晰的 hard reward，也可以用很多方式训练，比如，用户行为本身就包含大量隐性的偏好数据，可以被整理成 DPO 等训练方法需要的 preference pair：

• 成功完成 vs 失败；
• 用户接受结果 vs 拒绝结果；
• 少量修改 vs 大幅重写；
• 被下载 vs 未被使用。
• 低 token、低 latency 的实现路径 vs 高成本路径。

Reference

To Build an RL Envs and Human Data Startup | Sean Cai

https://seanzcai.substack.com/p/to-build-an-rl-envs-and-human-data

The next big breakthrough will be AIs learning on the job | Dwarkesh Patel

https://www.dwarkesh.com/p/the-next-paradigm

Stanford MS&E 435: Economics of the AI Supercycle, Enterprise Internal Knowledge | Yash Patil

https://www.youtube.com/watch?v=LRGX-gTegVA

文章来自于微信公众号 “Founder Park”，作者 “Founder Park”