# We’re Thinking Too Small About Synthetic Data
**作者**: Yuhan Luo
**日期**: 2026-10-17T16:23:23.000Z
**来源**: [https://x.com/_yuhanluo/status/2111493287085535304](https://x.com/_yuhanluo/status/2111493287085535304)
---
Synthetic data is much more than large scale inference or pre-training data mixture design. It's a deep data research problem, and much of it is still wide open.
# What are we even synthesizing today?
It’s easy to think of synthetic data as example generation. A typical process might be to give a model some prompts or templates and output a larger training corpus. When producing enough examples was the bottleneck, a lot of the work was fun engineering stuff, like spending days figuring out how to share prompt prefixes and reuse the KV cache to squeeze more examples out of the same GPUs.
Things are looking different now. We’re training agents to handle whole workflows. We’re designing the whole system that creates those training experiences. That means we need to build usable tasks and environments, along with verifiers that judge success fairly. Otherwise, cheap data just ends up consuming expensive training compute with little to no learning value.
The research problem goes beyond generation and data mixture design. I’ve been thinking about [simulation vs distillation](https://x.com/_yuhanluo/status/2103626833644458349) for synthetic data, as treating all of this as distillation overlooks what generators contribute.
The generator itself is a research problem.
# We don't necessarily need a generative model to generate a world
And you know what… not every part of the generator needs an LLM. Python code still works! And maths and physics exist for a reason. State-transition models and discrete-event simulation can generate a world’s history without an LLM, with real use as the prior for the relationships and situations we choose to model.
Take the [customer service agent training example I wrote about earlier](https://x.com/_yuhanluo/status/2104325531982528994).
The agent’s starting world is the end state of this simulated history.
It’s tempting to generate the tickets, emails, and refund records separately, then patch the inconsistencies afterward. For example, we might manually change a payment record from $100 to $70 in database, but overlook the email that still says $100. When scenarios get complex, it's even more expensive and unreliable to check after the fact.
I’d rather generate the payment record from the events that led to it. Things like ticket statuses, balances, and past events would live in a shared state, updated by explicit rules: sₖ₊₁ = F(sₖ, eₖ), where sₖ is the current world state, eₖ the event, and F the transition rule.
One way to build this is a [discrete-event simulator](https://ocw.mit.edu/courses/2-854-introduction-to-manufacturing-systems-fall-2016/0dc16a918eabd3f47e3f6d573485dccf_MIT2_854F16_Simulation.pdf#page=15) that advances the clock from event to event, using state-dependent rules and distributions for ticket arrivals, refunds, and escalation delays. We generate the records from the history it produces, so their relationships are established during generation. This isn’t a novel approach; it has been battle tested in real-world professional domains for decades.
This buys us strong internal consistency.
# Humans and synthetic systems better together
While simulation can give us consistency by design, we still have to decide whether its assumptions reflect the real world and which situations are worth learning from. Real human knowledge gives us a prior for those choices:
- Distribution design: human knowledge helps us ground the right set of users and workflows/capabilities to train for.
- Realism grounding: use examples from people doing the work to capture the constraints and details our simulation misses.
- Human review: domain experts can catch answers that pass our checks but would cause trouble in practice, before we reinforce them in training.
## Designing the right training distribution
With a limited training budget, we need to choose whose problems we want it to handle and which capabilities to develop.
Imagine we’re building a personal agent, but focusing on “pushing the frontier” with PhD-level intelligence. This could mean making all those users patient and thoughtful about what they want. We could end up benchmaxxing and still miss what a real, impatient human needs when they say “my wifi is down and my meeting starts in five minutes”. The agent might start diagnosing the router, but the simple, often right answer may just be to switch to a hotspot.
Then, on task distribution. If the agent already handles routine status lookups well, I’d give it fewer of those and more of the escalation decisions it keeps getting wrong. Status lookups might be more common in real use, but it doesn’t mean they deserve more of the training budget.
Essentially, designing the distribution is deciding who to train for and where it needs more practice. Real use is the prior; learning value reweights it.
## Pushing realism in content “texture”
There’s content (is the information correct and coherent across everything the model sees?) and there’s texture (does it look and behave like the messy mix of artifacts humans actually work with?).
We’ve seen a steady stream of great knowledge work benchmarks recently. [DAYJOB](https://arxiv.org/html/2610.01306v1) does a good job simulating complex professional work from short requests. [AA-Briefcase](https://artificialanalysis.ai/evaluations/aa-briefcase) puts tasks inside multi-week business projects. These prompt contents are getting much more realistic.
But realistic prompts + synthetic-looking files isn’t realistic work yet. Imagine a legal agent getting 10 PDFs from different stakeholders, all in the same template. The content might be detailed and diverse, but the texture of those files is a dead giveaway of a fake world.
To get this texture right, we will need much real world references from experts who do the work. Those references will be the source to ground our generators with realism.
## Augmenting machine checks with human judgment
Automated checks can cover a lot of quality issues, yet we’ll still keep human in the loop to spot problems those checks miss. In the customer support case, an escalation request might get all the facts right, but somehow the customer sounds perfectly calm after several angry messages. A human reviewer could read the thread and think, “wait, this feels off”, even after all factual checks have passed.
Sometimes we’re rewarding the wrong thing in the first place. In [Anthropic’s August 2026 report](https://www.anthropic.com/research/improving-alignment-security-efforts), a model gamed an honesty reward by piling on disclaimers. They already had humans reviewing flagged environments, but generation was outpacing their ability to check and fix them. Figuring out how to keep up with HITL is part of the research too, and a key part of making training safer.
# Looking ahead to adaptive curriculum design
All of these are parts of the generator we should be researching and improving as a system. We should judge it by training lift at a fixed budget.
> “any static procedure for synthetically generating data will quickly become outstripped.” — David Silver and Richard Sutton, [Welcome to the Era of Experience](https://storage.googleapis.com/deepmind-media/Era-of-Experience /The Era of Experience Paper.pdf)
I believe the combo of physics- and math-grounded simulation + LLMs + human expertise can go a very long way.
Once we've encapsulated the generator as a research problem, agents could start improving it and using it to train their next versions, and repeat. This could become a foundation for RSI.
We're still very early.
## 相关链接
- [Yuhan Luo](https://x.com/_yuhanluo)
- [@_yuhanluo](https://x.com/_yuhanluo)
- [16K](https://x.com/_yuhanluo/status/2111493287085535304/analytics)
- [simulation vs distillation](https://x.com/_yuhanluo/status/2103626833644458349)
- [customer service agent training example I wrote about earlier](https://x.com/_yuhanluo/status/2104325531982528994)
- [discrete-event simulator](https://ocw.mit.edu/courses/2-854-introduction-to-manufacturing-systems-fall-2016/0dc16a918eabd3f47e3f6d573485dccf_MIT2_854F16_Simulation.pdf#page=15)
- [DAYJOB](https://arxiv.org/html/2610.01306v1)
- [AA-Briefcase](https://artificialanalysis.ai/evaluations/aa-briefcase)
- [Anthropic’s August 2026 report](https://www.anthropic.com/research/improving-alignment-security-efforts)
- [Welcome to the Era of Experience](https://storage.googleapis.com/deepmind-media/Era-of-Experience%20/The%20Era%20of%20Experience%20Paper.pdf)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:23 AM · Oct 18, 2026](https://x.com/_yuhanluo/status/2111493287085535304)
- [16.2K Views](https://x.com/_yuhanluo/status/2111493287085535304/analytics)
- [View quotes](https://x.com/_yuhanluo/status/2111493287085535304/quotes)
---
*导出时间: 2026/10/18 09:48:00*
---
## 中文翻译
# 我们对合成数据的思考太狭隘了
**作者**: Yuhan Luo
**日期**: 2026-10-17T16:23:23.000Z
**来源**： [https://x.com/_yuhanluo/status/2111493287085535304](https://x.com/_yuhanluo/status/2111493287085535304)
**阅读**: 16K
**点赞**: 348
**转发**: 15
**回复**: 16
---
合成数据远不止是大规模推理或预训练数据配比设计。它是一个深度的数据研究问题，而且其中大部分领域仍然是一片开阔的未知。
# 我们今天到底在合成什么？
人们很容易把合成数据理解为样本生成。一个典型的过程可能是给模型一些提示词或模板，然后输出一个更大的训练语料库。当“生成足够多的样本”是瓶颈时，很多工作是有趣的工程活，比如花上几天时间研究如何共享提示词前缀、复用 KV cache，以便在同样的 GPU 上榨出更多样本。
现在情况不一样了。我们在训练能处理完整工作流的智能体。我们在设计创建那些训练体验的整个系统。这意味着我们需要构建可用的任务和环境，以及能公平判断成败的验证器。否则，廉价的数据最终只会消耗昂贵的训练算力，却几乎没有任何学习价值。
这个研究问题超越了生成和数据配比设计。我一直在思考合成数据中的[模拟 vs 蒸馏](https://x.com/_yuhanluo/status/2103626833644458349)问题，因为把这一切都当作蒸馏来看待，忽视了生成器的贡献。
生成器本身就是一个研究问题。
# 我们不一定需要生成式模型来生成一个世界
而且你知道吗……生成器并非每个部分都需要 LLM。Python 代码仍然好使！数学和物理的存在也是有原因的。状态转移模型和离散事件模拟可以在没有 LLM 的情况下生成一个世界的历史，并在对我们选择建模的关系和情境设置先验时发挥实际作用。
以[我之前写过的客服智能体训练示例](https://x.com/_yuhanluo/status/2104325531982528994)为例。
智能体的起始世界就是这个模拟历史的终态。
人们很容易把工单、邮件和退款记录分开生成，然后再事后修补不一致之处。例如，我们可能在数据库里手动把一条支付记录从 100 美元改成 70 美元，却忽略了仍然写着 100 美元的邮件。当场景变得复杂时，事后检查更加昂贵且不可靠。
我更倾向于从导致支付记录的事件中生成它。工单状态、余额和过去的事件等应该存在于一个共享状态中，由明确的规则更新：sₖ₊₁ = F(sₖ, eₖ)，其中 sₖ 是当前世界状态，eₖ 是事件，F 是转移规则。
一种构建方式是使用[离散事件模拟器](https://ocw.mit.edu/courses/2-854-introduction-to-manufacturing-systems-fall-2016/0dc16a918eabd3f47e3f6d573485dccf_MIT2_854F16_Simulation.pdf#page=15)，它从一个事件推进到下一个事件，利用依赖状态的规则和分布来处理工单到达、退款和升级延迟。我们根据它生成的历史来生成记录，因此记录之间的关系在生成过程中就已确立。这并不是什么新颖的方法；它已经在现实世界的专业领域里历经数十年的实战检验。
这为我们带来了强大的内部一致性。
# 人类与合成系统更好地结合
虽然模拟可以给我们带来设计上的一致性，但我们仍然需要判断它的假设是否反映了真实世界，以及哪些情境值得学习。真实的人类知识为这些选择提供了先验：
- 分布设计：人类知识帮助我们锚定要训练的正确用户群体和工作流/能力。
- 现实性锚定：使用人们实际工作的样本，来捕捉我们的模拟所遗漏的约束和细节。
- 人工审核：领域专家可以在我们于训练中强化之前，发现那些通过了我们的检查、但在实践中会引发麻烦的答案。
## 设计正确的训练分布
在训练预算有限的情况下，我们需要选择让它处理谁的问题，以及发展哪些能力。
假设我们在构建一个个人智能体，但专注于用博士级别的智能来“推进前沿”。这可能导致所有用户都被设定为对自己想要的东西耐心而深思熟虑。我们可能最终在跑分上卷得天昏地暗，却仍然无法理解一个真实的、不耐烦的人说“我的 wifi 断了，五分钟后就要开会了”时的需求。智能体可能会开始诊断路由器，而那个简单、往往正确的答案可能只是切换到手机热点。
然后是任务分布。如果智能体已经能很好地处理例行的状态查询，我会减少这类任务，增加它总是搞错的升级决策类任务。状态查询在真实使用中可能更常见，但这不意味着它们应该分得更多的训练预算。
本质上，设计分布就是在决定为谁训练、以及它需要在哪些方面多加练习。真实使用是先验；学习价值对其进行重新加权。
## 在内容“质感”上推进现实性
有内容（模型看到的所有信息是否正确且连贯？），也有质感（它看起来和行为上是否像人类实际使用的那种杂乱的工件混合体？）。
最近我们看到了源源不断的优秀知识工作基准。[DAYJOB](https://arxiv.org/html/2610.01306v1) 在从简短的请求模拟复杂的专业工作方面做得很好。[AA-Briefcase](https://artificialanalysis.ai/evaluations/aa-briefcase) 把任务置于为期数周的商业项目之中。这些提示词内容正变得越来越真实。
但真实的提示词 + 看起来像是合成的文件，还不等于真实的工作。想象一个法律智能体收到来自不同利益相关方的 10 份 PDF，却全都使用同一个模板。内容可能详细而多样，但这些文件的质感一眼就能暴露这是一个虚假的世界。
要把这种质感做对，我们将需要大量来自实际从业专家的真实世界参考。这些参考将成为让我们的生成器锚定现实性的源头。
## 用人类判断增强机器检查
自动化检查可以覆盖很多质量问题，但我们仍需要保持人在回路中来发现那些检查遗漏的问题。在客服案例中，一次升级请求可能在所有事实层面都是对的，但客户在发送了几条愤怒的消息后听起来却异常平静。人工审核员可以读一遍对话，然后想：“等等，这感觉不对劲”，即便所有事实检查都已经通过。
有时我们一开始就在奖励错误的东西。在 [Anthropic 2026 年 8 月的报告](https://www.anthropic.com/research/improving-alignment-security-efforts)中，一个模型通过堆砌免责声明来骗取诚实奖励。他们已经有人工审核被标记的环境，但生成速度超出了他们检查和修复的能力。如何跟上 HITL（人在回路）也是研究的一部分，而且是让训练更安全的关键一环。
# 展望自适应课程设计
以上这些都是生成器的组成部分，我们应该将其作为一个系统来研究和改进。我们应该以固定预算下的训练提升（training lift）来评判它。
> “任何静态的合成数据生成方法都将很快被超越。” — David Silver 和 Richard Sutton，《[Welcome to the Era of Experience](https://storage.googleapis.com/deepmind-media/Era-of-Experience /The Era of Experience Paper.pdf)》
我相信，基于物理和数学的模拟 + LLM + 人类专业知识的组合可以走得很远。
一旦我们把生成器封装为一个研究问题，智能体就可以开始改进它，并用它来训练自己的下一个版本，然后不断重复。这可能成为 RSI（递归自我改进）的基础。
我们仍处于非常早期的阶段。
## 相关链接
- [Yuhan Luo](https://x.com/_yuhanluo)
- [@_yuhanluo](https://x.com/_yuhanluo)
- [16K](https://x.com/_yuhanluo/status/2111493287085535304/analytics)
- [simulation vs distillation](https://x.com/_yuhanluo/status/2103626833644458349)
- [customer service agent training example I wrote about earlier](https://x.com/_yuhanluo/status/2104325531982528994)
- [discrete-event simulator](https://ocw.mit.edu/courses/2-854-introduction-to-manufacturing-systems-fall-2016/0dc16a918eabd3f47e3f6d573485dccf_MIT2_854F16_Simulation.pdf#page=15)
- [DAYJOB](https://arxiv.org/html/2610.01306v1)
- [AA-Briefcase](https://artificialanalysis.ai/evaluations/aa-briefcase)
- [Anthropic’s August 2026 report](https://www.anthropic.com/research/improving-alignment-security-efforts)
- [Welcome to the Era of Experience](https://storage.googleapis.com/deepmind-media/Era-of-Experience%20/The%20Era%20of%20Experience%20Paper.pdf)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:23 AM · Oct 18, 2026](https://x.com/_yuhanluo/status/2111493287085535304)
- [16.2K Views](https://x.com/_yuhanluo/status/2111493287085535304/analytics)
- [View quotes](https://x.com/_yuhanluo/status/2111493287085535304/quotes)
---
*导出时间： 2026/10/18 09:48:00*
