原创 Celia、Siqi 2026-07-22 20:10 北京

Real-world Data 背后的创业机会

编译：Celia

编辑：Siqi

最近和不同 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

排版：陈宇聪

延伸阅读

当开源模型逼近闭源，谁会成为 AI 世界的路由器？

深度讨论 Fable 5：模型收入分化，RSI，Tokenmaxxing 减速｜Best Ideas

Modal 的 Infra 复利，从 GPU Cloud 到 Agent Sandbox

Mintlify 做的开发者文档，如何成为 Coding Agent 生产和消费的第一波内容？

从 Agent 开权限开始，Serval 想成为下一代 ServiceNow