← 返回 PaperDaily 视觉与图像

告别脏数据！亚马逊开源Data Turnstile，让0.6B模型逼近7倍大模型

这篇论文切中了AI智能体落地的一个真痛点：小模型工具调用能力弱，但可靠数据既贵又脏。Data Turnstile把整段对话拆成带校验的角色化有向无环图，用开源权重模型就能批量产出高质量函数调用数据。0.6B微调后BFCL直逼7倍大的Qwen3-4B，多轮电信任务1.7B直接超越32B——数据质量对小模型而言，就是胜负手。

龙哥读论文发布于 2026-08-14 21:47:05 阅读 4 查看原文

#大语言模型 #Agent #数据集 #模型训练

告别脏数据！亚马逊开源Data Turnstile，让0.6B模型逼近7倍大模型

原论文信息如下：

论文标题:
Data Turnstile: A Scalable Open Framework for Function-Calling Data Generation

发表日期:
2026年7月发表单位:
Amazon AGI 原文链接:
https://arxiv.org/pdf/2607.29595v1.pdf

好的，龙哥已经仔细研读了这篇来自Amazon AGI的最新论文，现在就带大家一文读懂这个开源框架。以下为公众号文章主体内容，可直接与引言部分拼接。

龙哥导读：大家有没有想过，为什么手机上的语音助手总感觉比电脑上的“笨”一点？因为跑在手机上的模型必须足够小（小于40亿参数），而小模型（SLM，Small Language Model）天生在“调用工具”这件事上就比大模型弱一截。大模型记性好，你给几个例子它就能照着调用API（应用程序接口，即软件之间交互的接口）；小模型没这个记性，只能靠训练数据“死记硬背”。所以小模型的工具调用能力怎么样，几乎完全取决于喂给它的数据有多好。如果数据本身是脏的、乱的，那训练出来的模型就像用劣质食材做菜——大厨（大模型）还能化腐朽为神奇，但小模型这口锅直接就糊了。

龙哥一直强调，数据质量是小模型落地的胜负手。这一次，Amazon AGI带来的Data Turnstile框架，直接把这个痛点当成核心问题来解：它把一段复杂的“人机对话”拆成一张有向无环图，每个环节单独生成、单独验证、错了就重试，从而保证每一份训练数据都是“干净”的。用这套框架产出的数据去微调一个0.6B的小模型，单轮函数调用准确率直接干到75.9%，逼近7倍大的Qwen3-4B；在多轮电信客服任务上，1.7B的小模型甚至直接超越了32B的大家伙。

图1：τ²-bench多轮结果：使用Turnstile数据训练的小模型在零样本设置下击败了32B模型

图1：τ²-bench多轮结果：Turnstile数据训练的SLM零样本击败32B模型

小模型也能学会调用工具？Data Turnstile把数据质量做到了极致

先看一个有意思的现象。大模型（LLM，Large Language Model，大语言模型）天生就会调用工具，你给一个API列表，它能自己理解该用什么、怎么传参。但小模型不行。论文里明确指出，小模型推理能力弱、容量不够，无法像大模型那样通过“思考”自动纠正使用工具时的错误。对它们来说，唯一可靠的办法就是在高质量的监督数据上进行微调（SFT，Supervised Fine-Tuning，监督微调）。

这个问题的麻烦之处在于：高质量的工具调用训练数据非常稀缺，而人工标注的成本高到离谱。市面上已有的开源数据集质量参差不齐，很多都包含错误的API调用、不自然的对话，甚至凭空捏造的参数。论文作者观察到，如果直接拿这些“脏”数据去微调小模型，效果甚至可能不如不用——本来还会点工具调用的小模型，被脏数据一教反而学坏了。

对于这个困境，业界此前的两代方案各有短板：早期的端到端生成方法（如ToolBench）让LLM一次性生成一整段多轮对话——看似省事，其实质量失控，对话里API调用经常格式错乱、参数幻觉；后来的执行验证方法（如APIGen）倒是能保证正确性，但要求每个API都有真实的可执行后端，严重限制了适用范围。而现有方法普遍依赖ChatGPT等商业闭源大模型来生成数据，团队复现成本高、迭代很难。

Data Turnstile的出现就是要把“数据生成”本身变成一道可控制的工业流水线，而不是依赖大模型“灵光一现”。核心思想一句话：不要求模型一步生成完美对话，而是把对话拆成可控步骤，每步独立生成、独立检查，错哪改哪。

图2：Data Turnstile概览：按角色逐步生成，带逐步验证和错误反馈重试

核心思想：把“一段对话”拆成“一张DAG”

Data Turnstile最核心的抽象是“交互模板”（Interaction Template），本质是一个有向无环图（DAG，Directed Acyclic Graph，即有方向、无回环的图结构）。论文用数学形式定义如下：

其中V是节点集合，每个节点对应一个“角色”（Role），也就是一个原子化的生成步骤；E是有向边，编码角色之间的依赖关系；Θ是额外的生成规格参数，比如API定义、用户画像、质量检查条件等。模板描述了交互的“骨架”（结构），但不限定具体“血肉”（内容）。同一个模板配合不同的参数Θ，就能产出大量结构相同但内容多样化的交互样本。

论文定义了函数调用数据的五个角色：

USER用户查询：模拟真实用户提出的自然语言请求。

THINKING推理轨迹：模型在调用工具之前的思维链（CoT，Chain-of-Thought，即让模型先推理再作答的提示技术）过程。

API CALLAPI调用：模型实际发出的结构和参数都符合要求的函数调用。

API OBS工具响应：API执行后返回的观察结果，必须是结构合法的JSON格式。

ASSISTANT助手回复：模型综合工具结果后对用户做出的最终回答。

生成过程按DAG的拓扑顺序依次执行。每一步构造提示词时，模型能看到三样东西：整个模板的结构上下文、之前已经生成的角色输出、当前角色专属的生成上下文。这样模型既能掌握全局，又只需聚焦当前一步。DAG的边明确编码了角色间的依赖关系，比如模型知道下一步要生成一个API CALL，那么在生成USER查询时就会自然地“铺垫”一个能引出该调用的真实问题——这种远见是单次生成整段对话的方案很难做到的。

三步质量控制：结构验证、前置校验、错误重试

光有拆分还不够，关键在于每个环节都要有质量把关。Turnstile在这一点上设计了三个层次的防御机制。

第一层：结构验证。这是最硬性的规则约束，完全不需要依赖模型智能。Turnstile在模板层面强制两个级别的格式合规：一是序列层面的顺序规则，比如API OBS必须跟在API CALL后面，THINKING必须出现在API CALL或ASSISTANT之前；二是角色层面的校验规则，比如API CALL必须符合API的模式定义，每个API OBS必须是包含必填字段的合法JSON。这些规则在结构上就决定了“工具调用后必须有回应”、“推理必须先于行动”这些基本逻辑不可能出错。

第二层：前置校验。在生成当前角色之前，Turnstile会让LLM先对上一个角色的内容做一次“体检”，检查结构验证无法捕捉的深层问题，比如API调用参数是否存在幻觉、工具响应是否符合常理。这一层叫“先验证再生成”，把问题扼杀在萌芽状态。

第三层：错误反馈与提前终止。当某一步验证失败时，Turnstile不会立刻丢弃整个交互，而是带着错误信息重试。论文设定了一个重试预算，在预算内模型可以反复修正之前的输出。如果模型判断问题已经无法修复，也可以触发提前终止，避免在一条“坏样本”上越走越偏。这个机制的实际效果相当惊人——约84%的成功生成率中，有22%的交互在过程中至少遇到过一次错误，但通过重试机制被成功“救”回来了。

在整个质量体系之外，还有一套完整的多样性保障机制。模板层面可以控制结构多样性，比如设定50%单API单轮、25%多API单轮、25%多轮对话的分布；参数层面通过不同的用户画像、API组合、场景上下文来实现内容多样性；此外还支持动态扰动——比如故意让API执行失败，迫使模型学会“出错后重试”；或者让用户信息不完整，训练模型主动追问。这些扰动对于训练一个能在真实世界中稳健运行的智能体至关重要。

图3：τ²-bench Telecom多轮数据生成：可复用的Issues组合成Scenarios，带动态扰动

实验硬核：0.6B干翻32B，靠的是什么？

论文在两大权威基准上验证了数据的威力：BFCL（Berkeley Function Calling Leaderboard，伯克利函数调用排行榜，单轮工具调用评测标准）和τ²-bench（多轮智能体对话基准，评估模型在真实客服场景中的政策遵循、多步推理和错误恢复能力）。

先看单轮结果。论文的核心实验设置非常清晰：用Qwen3-0.6B作为“试验田”，分别对比：原始开源数据微调（Raw-OS）、Turnstile生成数据微调（Turnstile-OS），以及在此基础上加更多元数据（Turnstile-OOD）和加入目标域数据（Turnstile-OOD+ID）的效果。

这里有组数据龙哥觉得特别能说明问题：在完全相同的API体系下，用原始开源数据微调，0.6B的准确率只有55.1%；而用Turnstile生成的数据微调，准确率达到70.4%——光靠改进数据的生成方式，就带来了15.3个百分点的提升。更值得关注的是，原本0.6B模型不开思考（no-think）只有58.2%，开思考（think）才有67.4%；而用Turnstile数据训练的0.6B不开思考直接到75.9%，比开思考的原版还高一大截——这说明训练数据已经把推理过程“内化”进模型参数，推理时不依赖显式思维链了。这也意味着在边缘部署时无需额外的思考Token开销，延迟和成本双降。

接下来放上论文的核心结果表，这张表信息量很大，建议收藏细看。

图2：BFCL单轮结果：Turnstile微调的Qwen3-0.6B在不开思维链的情况下达到75.9%，逼近开思维链的4B模型（79.9%）

论文用特别严谨的消融实验论证了“为什么Turnstile数据有效”。在同样用开源API集合的前提下，原始数据（Raw-OS）的关键弱点是：Irrelevance（无关检测）从基线模型的81%掉到35.7%——因为每个训练样本都调用了工具，模型完全没学会“该拒绝时拒绝”；而Turnstile数据通过动态注入无关场景，把这项能力恢复到77.5%，非常接近基线水平。除了方法论对比，论文还进一步加测了Turnstile-OOD（开源API+合成API混合）和Turnstile-OOD+ID（再加入BFCL目标API）两组设置，量化了API多样性和目标域对齐各自的贡献。Turnstile-OOD+ID在Live简单/多API并行场景的优势尤其明显，说明ID数据的增量不可忽视。

图3：多样性对比：Turnstile生成的数据在四项指标上全面超过开源数据

除了准确率，论文还用四个量化指标对比了数据多样性：工具均衡度（Tool Balance）、调用序列多样度（Call Sequence）、结构多样度（Structure）和参数丰富度（Arg Richness）。Turnstile在全部指标上碾压开源数据。比如工具均衡度方面，开源数据0.92对Turnstile的0.98——说明开源数据里某些高频API被反复调用，而Turnstile生成的数据每个API的使用频次更均匀；参数丰富度上开源数据0.84对Turnstile的0.89——Turnstile生成的数据里同一个工具的使用方式花样更多。此外，Turnstile生成的数据在平均角色数、API调用数、Token数上都显著高于开源数据，信息密度更高。

再来看看更硬核的多轮场景。τ²-bench Telecom模拟真实电信客服，用户提问由LLM模拟，模型要遵循政策文档、多步诊断、处理报错、恢复失败，总共114个任务，每个任务跑4次取成功率。论文为此专门设计了“问题”（Issue）和“场景”（Scenario）两级抽象，把电信客服的操作手册拆解成17个可复用Issues，再组合成34个覆盖不同复杂度组合的Scenarios。

图4：τ²-bench Telecom多轮结果：1.7B模型微调后直接超越Qwen2.5-32B-Instruct

这张表信息量巨大。Qwen2.5-32B-Instruct的基座成绩是27.4%，而Turnstile微调后的Qwen3-1.7B达到31.1%，直接超越了这个19倍大的模型。0.6B的小家伙也把7.3%的基座拉到了24.6%，翻了3倍多。更牛的是，论文还实验了给工具调用Token加5倍损失的加权SFT，最高能到38.8%。论文明确指出，0.6B加了加权SFT后为24.6%，效果接近不加权的1.7B的27.2%。需要注意的是，表4里的Qwen3-32B是16.2%，这一行和Qwen2.5-32B（27.4%）都是零样本基线的参考上限，真正要看的对比是横向加权的SFT增益。此外，论文中还给出了no-think模式的SFT结果，即使完全不用思维链，1.7B也能到16.0%，说明Turnstile数据单靠监督信号就能内化多轮工具调用的策略。

开源福利：1000+API、10万+交互的数据集直接带走

最让龙哥觉得良心的是，论文把整个框架和生成的数据集都开源了。这个名为Synthetic Domains的数据集包含约10万个Turnstile生成的交互样本，覆盖超过1025个API、50多个领域（金融、天气、地图、电商等），每条样本都带有详细的CoT推理轨迹。单独用这个数据集微调Qwen3-0.6B，BFCL准确率达到67.4%——比直接用开源数据的55.1%高出一大截，甚至超过了0.6B基座开思维链的效果。论文还找了两名标注员对100条随机样本从正确性、自然度、接地气三个维度打分，满分5分的情况下分别拿到了4.4、3.8、4.5的高分，证明生成质量确实能打。

图5：关键数据集统计：Turnstile生成的数据在角色数、API调用数和Token数上都显著高于开源数据集

更妙的是，这个框架本身是模型无关的。论文团队用的是开源的Qwen2.5-32B-Instruct作为生成模型，跑在一台8卡H100机器上，完全不需要调用商业API。对于没有这么多GPU的团队，也可以用更小的模型配合重试机制凑合着跑。这就把高质量函数调用数据的生成能力从大厂“下放”到了社区手里——龙哥认为这是这篇论文最大的行业价值所在。论文对错误率做了详细的拆解分析，比如单轮、并行、多轮各自的失败率梯度，让使用者能评估生成成本。开源地址为github.com/amazon-science/data-turnstile，数据和权重也有公开下载。

总结与展望：数据质量才是小模型的胜负手

回头看这篇论文，龙哥觉得最有价值的地方不是具体的数据指标，而是它验证了一个核心判断：小模型的性能瓶颈不在模型的参数量，而在训练数据的质量。过去大家默认“小模型就是不如大模型”，但Data Turnstile用实际结果说明：只要数据足够干净、足够多样，参数量小7倍、19倍甚至53倍的模型也能在特定任务上追平甚至反超大模型。

这对边缘计算和端侧AI的意义是巨大的。未来手机、智能音箱、车载系统上跑的智能体，不需要再依赖云端大模型，一个经过高质量数据微调的小模型就能胜任大部分工具调用任务。这也意味着数据生成方法论将成为AI竞争的新前沿——谁能高效产出高质量的训练数据，谁就能让小模型发挥出远超其体量的实力。

当然，龙哥也要客观指出：论文的实验主要在Qwen3系列模型上验证，对于其他架构的SLM（比如Llama系列）的泛化效果尚未验证；Telecom领域的评估虽然结果亮眼，但仅覆盖一个领域（电信），扩展到金融、零售、航空等场景的效果还有待探索。不过这些都不影响Data Turnstile作为一套可落地的数据生产工具的价值。任何团队都能用这套开源框架，为自己的API体系定向生产高质量训练数据——这或许是这篇论文最重要的贡献。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

问题1：Data Turnstile与之前的ToolBench、APIGen等方法相比，到底赢在哪里？ToolBench采用单次生成整段多轮对话的方式，虽然成本低，但长对话质量失控，经常出现格式错乱、参数幻觉、对话不自然等问题。APIGen通过实际执行API来验证正确性，但要求API有可执行后端，很多真实API做不到。Turnstile的“角色化DAG”方案则结合了两者的优势：不需要执行环境，但能通过分步生成和验证保证质量；同时每一步的生成任务被大幅简化，连Qwen2.5-32B这种级别的模型都能可靠完成，无需依赖前沿闭源模型。

问题2：BFCL和τ²-bench分别考什么？BFCL是伯克利函数调用排行榜，重点考察单轮场景下模型能否从给定工具列表中选择正确的API并生成规范的调用参数。τ²-bench是多轮智能体对话基准测试，模拟真实客服场景，用户会持续追问、给不完整信息、甚至制造突发状况，模型必须遵循政策文档、做多步推理、学会失败恢复——复杂度远高于BFCL。两者互补，一个考“会不会选对工具”，一个考“能不能在复杂对话中用对工具”。

问题3：什么是DAG模板？为什么用它来表示生成过程？DAG是有向无环图（Directed Acyclic Graph），由节点和有向边组成，不存在回路。在Data Turnstile中，每个节点是一个“角色”生成步骤，边表示依赖关系。比如“API CALL”必须在“USER”之后、“API OBS”之前。这个结构可以精准控制生成顺序，确保每一步只依赖前序步骤的信息；同时它也是一个可编程的抽象，想增加一种新场景（比如“让用户追问信息”），只需给DAG增加节点和边，不需要重写整体逻辑。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

将对话生成拆分为DAG角色化流程，每步独立验证重试，系统性解决合成数据质量问题，思路清晰、工程实现完整。

实验合理度：★★★★★

BFCL和τ²-bench双基准、三个模型规模、四组消融实验，对比严谨，还加入了Tool-call加权SFT的额外对照，结论扎实可信。

学术研究价值：★★★★☆

验证了“数据生成方法论优先于模型能力”的路线，为SLM工具调用研究开了一条新路，对智能体数据合成方向有很强的借鉴意义。

稳定性：★★★★☆

框架设计中有明确的质量校验和重试机制，生成失败率可控，稳定性良好。但依赖生成模型本身的上下文推理能力，在小模型上是否依然稳定有待验证。

适应性以及泛化能力：★★★★☆

框架本身是API无关的，能适应任意API集合；实验覆盖单轮、多轮、策略文档遵守等场景。但只在Qwen系列和电信领域做了验证，跨架构和跨领域泛化尚未充分证明。

硬件需求及成本：★★★☆☆

框架本身用32B模型+8张H100生成数据，训练微调也需要一定的GPU资源；不过生成模型可以向下替换，且生成是离线的、成本可控。整体属于离线训练成本，不属于实时运行成本。

复现难度：★★★★☆

框架代码和数据均已开源，依赖的LLM也是可下载的开源权重（Qwen2.5-32B），复现路径清晰。但完整复现BFCL实验需要生成数百小时GPU时间。

产品化成熟度：★★★☆☆

框架和工具链已具备产品级可用性，但输出模型在真实生产环境的长尾鲁棒性、安全性等尚未验证，需要结合具体场景再做评测。

可能的问题：论文主要验证了BFCL和Telecom两个场景，扩展到其他领域的效果存疑；Qwen3系列在训练数据中的潜在泄漏也可能高估结果，需要更多验证。

主要参考文献

[1] G. Ramakrishnan, M. Sharma. Data Turnstile: A Scalable Open Framework for Function-Calling Data Generation. arXiv preprint, 2026.

[2] Qwen3 Technical Report. arXiv preprint, 2025.

[3] BFCL: Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

[4] τ²-bench: Evaluating Conversational Agentic Tool Use. https://github.com/sierra-research/tau2-bench

[5] ToolBench: Open LLM Tool-Use Learning Benchmark. https://github.com/OpenBMB/ToolBench

[6] APIGen: Automated API Data Generation. https://github.com/SalesforceAIResearch/AgentGen

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

0.6B小模型都能靠好数据逆袭，你的论文输入质量跟上了吗？🤔 欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如大模型+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群，等你一起来讨论更多高质量论文！
wechat_helper