企业数据造不出来，因为真实数据根本不让碰：生成式模拟如何绕开这道墙

你有没有想过一个很现实的问题：训练一个能帮企业订机票、处理报销、管理工单的AI助手，到底需要什么样的数据？

答案很简单，需要大量真实的企业数据库快照,也就是那种装满了订单、员工信息、报销记录的数据库状态,让AI在上面反复练习操作。但这里有个死结：真实的企业数据库里全是客户隐私、员工薪资、商业机密,根本不可能拿出来给AI训练用。数据库的结构设计（也就是“schema”）同样敏感,因为它暴露了公司的业务逻辑和系统架构,大多数企业连这个都不愿意公开。

于是摆在研究者面前的问题就变成了：既然真实数据拿不到，能不能造一批假的，但是造得足够像真的？

这事儿说起来容易,做起来却撞上了一堵两难的墙。一边是统计方法造的假数据,比如用GAN或者扩散模型去学习一堆表格数据的分布规律,这类方法的毛病是它们只管数值像不像真的,完全不管业务规则对不对。举个例子,一个员工的记录里引用的部门编号必须真实存在,请假天数不能超过已经攒下的假期余额,这些规则在统计生成器眼里根本不存在,它们生成的数据可能一眼就能看出是编的,因为违反了最基本的业务逻辑。

另一边是按脚本写死的程序化方法,这类方法把业务规则直接写进生成脚本里,保证了数据在规则上说得通,但代价是每换一个行业,工程师就得重新把所有规则和采样逻辑手写一遍,费时费力,而且写出来的数据往往只是“合规”,不是“逼真”,它只保证了什么是被允许的,却没管什么是真实世界里真正常见的。

这篇论文提出的方法,叫做“通过模拟来合成”

STS（Synthesis Through Simulation）：一种让AI智能体在模拟的企业系统里真实地“操作”一遍，从而生成数据的方法，而不是直接伪造数据本身。

核心思路说出来其实挺朴素的：既然业务规则是在系统的API（也就是对外开放的操作接口）层面被检查的，那干脆就让AI智能体直接通过这些API去执行操作，数据自然就是在规则约束下生成出来的，天生就合规。

这就好比你要办一张银行卡，银行柜台的系统会自动检查你的身份证号对不对、资料填得全不全,你不可能绕过柜台系统直接在后台数据库里手写一条记录。如果真这么干了，大概率会出现身份证号和姓名对不上、账户类型根本不存在这种离谱错误,因为没有任何东西在检查你写的是否合理。但只要你是走正常柜台流程，哪怕你填的信息再怎么稀奇古怪，只要通过了系统检查，这条记录在结构上就是站得住脚的。STS的设计思路正是如此,把“保证数据结构有效”这件事完全交给企业系统自己的检查机制去做，智能体只管怎么操作得更像真实场景。

这样一来，原本纠缠在一起的两个难题被彻底拆开了：结构是否合规，这件事由企业系统的政策检查层自动保证；数据是否真实、符不符合实际分布规律，这才是留给智能体去解决的问题。

论文里专门给出了一个数学证明，叫做“结构有效性由构造保证”

Proposition 1（结构有效性命题）：只要一条操作轨迹是通过环境的API成功执行的，那么最终生成的数据库状态一定满足所有的校验规则，这是可以严格证明的，不是碰运气。

证明过程用的是数学归纳法，逻辑很直白：初始状态肯定是合法的（空数据库天然满足一切规则），之后每一次写入操作要么因为违反规则被拒绝（数据库状态不变），要么因为符合规则被接受（数据库状态在保持所有约束的前提下更新）。所以不管走了多少步，最后的状态必然是合法的。

那么问题来了：既然结构合规已经被系统保证了，接下来要解决的就是智能体到底该怎么操作，才能让生成的数据在统计分布上也像真的。这就是这篇论文真正的技术核心,一个叫做“通才填充器”的智能体系统。

通才填充器：怎么在完全不知道数据库长什么样的情况下，造出分布真实的数据

Generalist Populator（通才填充器，简称GP）

是STS框架里负责真正干活的智能体，它的设定非常苛刻：不能看数据库的表结构，没有人工写好的任务脚本，不需要针对每个新领域单独配置，唯一能拿到的东西是API工具的注册表（也就是一堆函数名字、输入参数格式和自然语言描述）。

这个设定听起来有点像蒙眼做菜,你不知道厨房里具体有什么食材，也没有菜谱，只能靠摸索各个调料罐上贴的标签去猜这是什么、该怎么用。但正是这种“什么都不告诉你”的苛刻条件，逼出了GP的核心设计：它得自己去探索、自己去规划、自己去执行，而且探索的经验还得能被后面的操作复用，不然每次都从零开始摸索效率太低了。

GP的整个工作流程被拆成三个阶段，循环执行N次，每次执行对应一个具体的任务。

第一个阶段叫探索（EXPLORE）,目标是搞清楚这个系统里到底有哪些工具、哪些是只读的查询操作、哪些是会改变数据库状态的写入操作、创建不同实体之间有什么先后依赖关系、以及现实世界里各种操作出现的频率大概是什么样子。这个阶段有个很关键的设计：所有的写入操作全部被屏蔽，智能体只能靠读取操作和查看工具说明书来摸索。

为什么要屏蔽写入？因为如果让智能体在还没搞清楚状况的时候就瞎写，相当于让一个刚进厨房、还没认全食材的新人直接开始下锅炒菜,炒出来的菜大概率是乱七八糟的，而且这些错误的“菜”已经进了数据库，没法撤回了。这跟后面要生成的数据质量直接挂钩，一旦前期探索不充分就动手，生成出来的数据会严重偏离真实分布，而这种偏差是没法靠后续补救的。

探索阶段的成果会被记录进一个叫做“探索手册”的东西里。

ExplorationManifest（探索手册）：一个轻量级的SQLite数据库，充当GP的长期记忆，跨越所有N次任务循环持续积累信息，包括工具分类（哪些是读、哪些是写）、实体之间的创建依赖关系图、各类操作应该出现的相对频率权重、最近做过的任务描述（避免重复）、以及从实战中提炼出来的成功经验技巧。

有意思的是，探索阶段并不是每次任务循环都要重新跑一遍,只有最开始的K次循环会执行探索，之后GP判断自己已经把这个系统的脾气摸透了，就直接跳过探索，复用手册里积累的知识去做规划和执行。论文做了实验验证这个K该设多大合适，发现K=3是个实用的甜点：探索3次之后，衡量字段之间相关性的指标（PDF）已经从K=0时的0.813跳到K=3时的0.900，之后再怎么多探索几次也不会有明显提升，而且过度探索反而会让跨表关联的统计指标（CDF）出现下滑，因为探索得越杂，智能体对任务类型的采样会越分散，反而偏离了参考的真实分布。

第二个阶段是规划（PLAN）,这一步会发起一次结构化的大模型调用，生成这一轮任务的具体描述。它参考的信息包括探索手册里的全部背景知识、最近做过的任务历史（避免重复套路）、以及一个“覆盖率检查”，专门标记出哪些写入操作还没被用过，强制规划器优先安排它们登场。

如果有人工提供的参考分布（比如某个字段里各个类别应该占多大比例），规划器会把目标值锚定在这些先验知识上；如果没有提供，它就靠大模型自身的世界知识去猜一个合理的分布。最终输出的是一个任务描述，比如“为一位金卡会员预订一张往返的商务舱机票”,这个描述里会写明具体的属性取值，但故意不写死具体的实体身份（比如哪个用户ID、哪个订单号），因为这些具体身份信息得留到执行阶段，从数据库的实时状态里去现查。

第三个阶段是执行（EXECUTE），智能体带着任务描述和完整的工具权限，真刀真枪地去操作系统，先查数据库拿到需要的实体ID，再按照依赖顺序依次调用写入工具，遇到被拒绝的调用就根据系统返回的错误信息调整策略。每轮任务跑完之后，还会有一个“经验提炼”的步骤：让大模型回顾整条操作轨迹，看看有没有出现某个关键操作，一旦用了就让后面一连串操作都顺利成功的情况（比如发现查一下现有订单就能拿到合法的航班路线，比瞎猜参数试错效率高得多），如果找到这种规律，就把它当成一条命名好的经验法则存进手册，让以后所有任务都能直接用上，不用每次都重新摔跟头去发现。

实验结果说明了什么

论文在十个企业场景下做了测试，覆盖人力资源、航空订票、IT运维、银行、电商、零售、大学选课、药房配药、论坛社区和云计算基础设施。每个场景都配了一个SQLite数据库和对应的API工具集。

结果显示GP在全部十个场景里的结构合规率（VPR）都是100%，这一点是数学证明直接保证的，不需要靠运气。更关键的是分布真实性指标：五个场景里，字段层面的真实度（MDF）超过了0.93，比如航空场景达到0.973，电商场景达到0.983。这意味着GP生成的舱位等级、支付方式这些字段的分布，和参考的真实世界比例已经相当接近。

但也不是所有场景都表现完美。银行和论坛两个场景的跨表关联指标（CDF）比较低，分别是0.421和0.318。深挖原因发现，问题出在GP的规划器对不同任务类型的采样比例判断有偏差：在论坛场景里，GP给“发帖”和“回帖”这两类任务分配了差不多的权重，结果生成的帖子平均每个主题下只有1到2条回复，而真实世界的参考数据显示一个帖子通常会累积到3条回复甚至更多；银行场景同理，开户和存取款交易被平均对待，而现实中一个账户往往会随时间积累5到30笔交易。这说明GP在没有专门的领域频率信号时，完全靠大模型的世界知识去猜测任务比例，这种猜测存在系统性偏差，但这是一个可以靠后续引入种子数据统计或领域提示来修正的问题，而不是GP从根本上造不出关联结构。

为了验证GP是不是真的理解了系统结构，而不是靠字面意思猜测，论文还做了一个“混淆测试”：把航空场景里所有有意义的名字全部换成无意义的代号，比如把“预订商务舱”换成“object_c的type_b”。结果GP在混淆版本上的表现和正常版本几乎一样，探索阶段推断出的实体依赖关系图在两个版本之间只相差2条边（用图编辑距离衡量，归一化后是0.154）。这说明GP是真的从参数结构里推断出了创建顺序，而不是靠工具名字里的语义线索蒙对的。

这就好比你把一套乐高积木说明书上所有的零件名字都换成了代号，一个真正理解组装逻辑的人照样能拼出正确的结构，因为他看的是零件之间怎么卡住、哪个该先装哪个该后装，而不是零件标签上写了什么好听的名字。如果GP只是依赖字面语义去猜测，一旦名字被替换成乱码，它的表现应该会显著下滑,但实验数据没有显示这种下滑，这反过来证明了GP学到的是结构性的东西。

和其他方法比，差距在哪

论文还对比了几种主流的统计表格数据生成方法，包括CTGAN、TVAE、SDV的HMA模块和REaLTabFormer。这些方法有个绕不开的硬伤：它们需要种子数据来训练,但在GP测试的十个场景里，有七个场景压根没有预先填充好的种子数据，这些方法直接就不适用了。

论文把这种情况称为“冷启动问题”,这就像让你照着一本从没见过的菜谱做菜，但菜谱里一道菜的成品照片都没有，你压根不知道做出来该是什么样子。而GP不需要任何“成品照片”作为参照，它靠的是一边操作一边观察系统反馈来学习，这种能力在数据完全空白的场景下是决定性的优势。

在剩下三个有种子数据的场景里（航空、零售、银行），统计方法终于可以派上用场了，论文对比发现最大的分野还是结构合规性：GP做到了100%，而其他方法最高只能到0.923，而且这个天花板是没法靠喂更多训练数据突破的，因为这些方法压根不经过API的检查层，生成出来的记录是直接硬塞进数据库的，自然可能出现违反业务规则的情况。

更值得玩味的对比，是GP和一个叫EnvScaler的“特权”智能体之间的较量。EnvScaler可以看到完整的数据库表结构、实时状态和所有业务规则，相当于手握一本详细的说明书；而GP只能看到API工具的描述，相当于两眼一抹黑。按常理，信息更多应该表现更好,但实际测试结果是EnvScaler在航空场景里82%的任务轨迹都是“零写入”，也就是全程空转，什么有效数据都没生成出来。

深究原因发现，EnvScaler因为掌握了数据库的实时状态，它生成的任务描述会直接写死具体的实体ID，比如“取消用户Alice Johnson的预订ZFA001”。但问题是，数据库状态是在不断变化的，等到这个任务真正被执行的时候，预订ZFA001可能早就在之前的某个任务里被取消过了，于是第一步调用就直接失败，后面的步骤全部卡死，整个任务作废。这就好比你提前写好了一张详细的购物清单，上面精确写着“去超市货架第三排拿那瓶红色标签的番茄酱”，结果等你真去超市的时候，那瓶酱早就被别人买走了，而你的清单压根没有“如果没货怎么办”的应对方案，只能站在空货架前发呆。

而GP的任务描述是故意写得“模糊”的，比如“找一个有可用支付方式的用户，预订一张往返经济舱机票”,它不提前锁定具体身份，而是把发现具体实体这件事留到真正执行的那一刻，现场去数据库里查。这种设计看起来信息量更少，但反而更有韧性，因为它从不依赖一个可能早已过时的假设。

不过EnvScaler也不是一无是处，在云计算场景里，跨表关联指标（CDF）它反而略胜一筹（0.649对0.610），原因是云计算场景里虚拟私有网络和子网之间的从属关系，直接写在数据库表结构里，EnvScaler看一眼表结构就能精确复刻这种关系，而GP得靠自己从工具参数里一点点摸索出来。这个对比说明，拿到表结构这种特权信息，只在它直接编码了某种关键关联结构时才有用，大多数情况下并不能提升字段层面或字段组合层面的真实度，反而可能因为任务描述和实时状态脱节而彻底搞砸执行。

规划阶段到底有多重要

论文专门做了一个消融实验，把规划阶段直接砍掉，换成一句笼统的指令：“往数据库里填充真实多样的数据”。结果让人意外：虽然智能体每轮任务写入的数据量暴涨（从平均0.61次预订跳到16.7次），但所有的分布真实性指标全线下降,字段真实度掉了0.065，字段组合真实度掉了0.062，跨表关联真实度掉了0.071。

最直观的例子是往返机票的比例，有规划阶段时是52.5%，接近参考值55%；砍掉规划之后暴跌到7.9%。原因是没了具体任务指引，智能体会倾向于遍历数据库里所有用户，给每个人挨个订最简单的单程票，因为组合一张往返票需要多拼接一个航段，这步操作在没有明确指令的情况下，智能体根本不会主动去尝试。

这个发现戳破了一个容易被想当然的假设：数据量大不等于数据质量高。写入次数翻了27倍，但因为写入的内容全是重复的、简单的套路，反而让生成数据的分布面目全非,这就好比一个厨师拼命往锅里加各种食材，看起来份量十足，但如果他不看菜谱只凭感觉乱放，最后端出来的菜可能根本不是你点的那道菜。规划阶段的作用，正是给每一轮操作设定一个具体明确的目标和对应的属性取值，而不只是追求操作数量上的堆砌。

经验提炼这步棋走对了吗

论文还单独测试了关掉“经验提炼”功能会发生什么,结果在三个场景里暴露出三种不同的失效模式。银行场景里，没了经验提炼，平均每轮成功写入次数掉了33%，69%的任务轨迹都退化成同一套刻板的三步流程,相当于智能体每次都要重新发明一遍轮子，没法把上一次摸索出的高效路径复用到下一次。人力资源场景里，没有经验提炼的话，任务彻底失败（零写入）的比例从7%涨到12%，说明经验法则在这里起到了避免走进死胡同的作用。航空场景里，每完成一次成功写入所需的工具调用次数几乎翻倍（增加96%），因为丢掉了“先查现有预订记录拿到合法航线”这条捷径，智能体只能靠反复试错去摸索参数。

三个场景，三种截然不同的表现，但共同点是去掉经验提炼之后，表现都在变差。这说明经验提炼不是锦上添花的装饰，而是实实在在支撑整个系统效率的一根梁柱。

把生成的数据拿去训练智能体，效果真的更好吗

最后论文做了一个很实际的验证：用STS生成的航空场景数据库快照，去训练一个真正的对话智能体，看它处理航空订票任务的表现，和用原始的种子数据快照训练出来的智能体相比，到底谁更强。

实验用GPT-4.1生成多轮对话样本，分别从STS填充后的数据库和预先填充的种子数据库里取样，筛选出完成度达到满分的对话，用来微调一个Qwen2.5-7B模型，再放到τ?-bench的航空评测基准上打分。

结果显示，用STS数据训练出来的模型，在全部五项评测指标上都超过了原始模型，也都超过了用种子数据训练的版本。差距最大的是pass@k这个指标（直接衡量任务是否成功完成），比原始模型高出0.214，比种子数据训练的版本高出0.125。更值得注意的是，用种子数据训练出来的那版模型，在AUC和平均进度这两项指标上甚至没能超过完全没训练过的原始模型。

这个结果说明了一件很朴素但容易被忽视的事：让模型见过更多样、更丰富的数据库状态，比单纯让它多看几遍同一套固定数据更能提升实际能力。种子数据训练失败的原因不是因为微调没用，而是因为种子数据本身的多样性不够，模型没能从中学到应对真实世界各种变化场景的能力。

写在后面

读完这篇论文，有一个细节让人印象很深：GP在完全看不见数据库表结构、完全没有人工写好的意图库、完全没有针对特定领域做任何配置的情况下，依然能在十个风格迥异的企业场景里稳定生成高质量数据，这件事本身就在说明一个道理,真正限制AI系统能力的，有时候不是信息量不够，而是信息组织和利用的方式不对。EnvScaler拿到的信息比GP多得多，结果在航空场景里却因为任务描述和实时状态脱节而大面积失败，这个反差比任何理论论证都更有说服力。

还有一点值得单独拿出来说：探索预算K=3这个数字背后藏着一种朴素的经验主义,不是探索得越多越好，而是存在一个边际收益递减甚至转为负收益的临界点。这让人想起很多领域里都存在的类似现象，学习一门新技能时，前几次尝试带来的进步最明显，之后继续重复同样的动作反而可能固化错误习惯。GP的探索机制某种程度上印证了这种直觉在AI系统设计里同样成立。

论文里提到的局限也很诚实：GP的表现依赖底层大模型的质量，而且在没有参考分布的字段上，它靠世界知识做出的猜测会带有模型本身的偏见，这不是一个轻易能消除的问题。另外，STS这套方法起作用的前提是企业的API层真的把所有业务规则都完整地检查到位了，如果某条规则漏检了，那生成的数据照样可能是有漏洞的,这意味着这套框架的保证，本质上是把责任转移给了API设计者，而不是凭空消除了风险。

Q&A

Q1：STS（通过模拟来合成）是什么？

A：STS是一种数据生成方法，让AI智能体直接通过企业系统的API接口去执行操作，而不是直接伪造数据记录。因为所有写入都经过系统自带的业务规则检查，生成的数据天然满足结构有效性，不需要额外验证。

Q2：通才填充器（GP）和传统的统计数据生成方法比，优势在哪？

A：GP不需要种子数据、不需要数据库表结构、不需要针对每个领域手工配置。在论文测试的十个企业场景里，有七个场景根本没有种子数据，这类场景下CTGAN、TVAE等统计方法完全无法使用，而GP可以从零开始正常工作。

Q3：为什么掌握更多信息的EnvScaler反而在航空场景里82%的任务都失败了？

A：EnvScaler因为能看到数据库实时状态，会把具体的实体ID写死进任务描述里，但数据库状态在不断变化，等任务真正执行时这些ID可能早已失效，导致第一步调用就失败。GP则故意把任务描述写得模糊，实体身份留到执行时现场查找，反而更有韧性。