跳到主要内容

7 篇博文 含有标签「synthetic-data」

查看所有标签

输入分布与用户实际输入不匹配的合成训练样本

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个团队利用 80,000 个合成示例微调了一个客服模型。Teacher prompt 设定得很得体:“生成关于退货、退款和物流的真实客户问题。”Teacher 模型照办了。它生成了简洁、完整、拼写正确、每条消息只有一个意图、语气礼貌且语体一致的查询。在预留的合成验证集上的离线评估达到了 94%。于是团队发布了。

生产环境的表现差了 20 个百分点。团队花了一个 Sprint 的时间争论模型是否“不擅长客服”。事实并非如此。模型在客服方面表现良好。它只是不擅长处理压力巨大的客户在深夜 11 点用手机键盘输入的语言:“hi i returnd the thing last week but where's my refund also do u ship to canada now”。模型在训练过程中从未见过这种形式的输入,因为 Teacher 模型当时忙着生成它想象中的查询,而不是用户实际发送的查询。

你的合成训练数据正在向均值坍缩

· 阅读需 9 分钟
Tian Pan
Software Engineer

你需要更多的训练数据,于是你生成了它们。模型编写了几千个例子来填补数据集中的空白——边缘案例、代表性不足的意图,以及你真实日志从未涵盖的长尾数据。你抽检了一个样本。每个例子看起来都不错:语法正确、符合主题、标签准确。你将这一批数据加入到微调集中,然后继续工作。

三轮迭代之后,你的模型在那些你特意生成数据来覆盖的案例上表现反而变差了。并不是灾难性的变差——只是悄无声息地、均匀地变得平庸。以前偶尔能奏效的稀有意图现在完全失效了。用户实际输入的措辞被误读。而你的质量检查中没有任何一项发现异常,因为你生成的每一个独立案例确实都很正常。

失败不在于任何单个案例,而在于分布。合成数据在没有现实锚点的情况下被生成和反复生成,会向均值收缩——而长尾部分,即你求助于合成数据的根本原因,是首先消失的部分。

当 LLM 为自己批改作业:打破 AI 评估中的反馈循环

· 阅读需 11 分钟
Tian Pan
Software Engineer

这是一个大多数 AI 团队都不愿面对的发现:在一项生成了超过 150,000 个评估实例、涵盖 22 个任务的大规模研究中,大约 40% 的 LLM 作为裁判(LLM-as-judge)的对比显示出可衡量的偏见。这种偏见并非随机噪声,而是系统性的、可复现的,并且与模型的训练方式相关。当你使用一个模型来生成评估集,然后使用同一个模型(或其近亲)来对其进行评分时,你测量的并不是质量,而是一个系统与其自身的一致程度。

合成评估数据之所以成为标准实践,是有充分理由的。人工标注速度慢、成本高且难以规模化。LLM 生成的测试用例让团队能够在夜之间生成数千个示例。问题出现在生成器和裁判拥有共同祖先时——在 2025 年,这几乎是常态。结果是一个评估流水线在自信地报告高分的同时,却隐藏了你构建它原本想要捕捉的失败模式。

合成种子数据:在首批千名用户到来之前启动微调

· 阅读需 10 分钟
Tian Pan
Software Engineer

有数据时,微调模型很容易。残酷之处在于产品诞生之前的那个时刻:你需要个性化来吸引用户,但又需要用户才能积累个性化数据。大多数团队要么完全跳过微调("以后再加"),要么花数周手工收集标注样本。两种方式都行不通。前者产出一个用户一眼就能看穿的通用模型,后者慢到等你有了数据,任务早已演变。

合成种子数据能解决这个问题——但前提是你必须清楚它在哪里会失效。

不会崩溃的合成数据管道:大规模生成训练数据

· 阅读需 10 分钟
Tian Pan
Software Engineer

用模型自身的输出训练模型,再用该模型的输出训练下一个模型,三代之内你就构建了一台逐渐变笨的机器。这就是模型崩溃——一个退化过程,其中每一代合成训练数据都会缩窄分布,直到模型遗忘罕见但重要的长尾模式。Nature 上的一项里程碑式研究证实了从业者的经验观察:即使微小比例的合成数据污染(低至千分之一的样本)也会引发词汇、句法和语义多样性的可测量退化。

然而合成数据并非可选项。真实世界的标注数据昂贵且在专业领域稀缺,在前沿模型所需的规模下日益枯竭。2025-2026 年成功交付微调模型的团队并非在回避合成数据——他们正在设计管道架构以确保生成过程不会崩溃。一个高效管道与一个自我中毒管道之间的区别在于多样性保持、验证循环以及知道何时该停下来。

合成训练数据质量崩溃:反馈循环如何摧毁你的微调模型

· 阅读需 12 分钟
Tian Pan
Software Engineer

你使用 GPT-4 生成了 50,000 个合成的指令遵循示例,在这些示例上微调了一个较小的模型并将其部署,结果看起来非常棒。六个月后,你的团队重复了这一过程——只不过这次为了节省成本,你使用微调后的模型来生成示例。第二个模型的评估结果略低,但在噪声范围内。你以同样的方式微调了下一个版本。到第四次迭代时,你的模型输出呈现出一种奇怪的同质化。用户反馈它听起来像机器人。它在处理任何不符合狭窄模板的内容时都显得很吃力。你最强大的微调模型已经变成了最糟糕的一个。

这就是模型崩溃(model collapse)——当大语言模型(LLM)使用其他 LLM 生成的数据进行训练时,会发生渐进式的、自我强化的退化。这并非理论上的风险。它是一种有据可查的故障模式,具有可衡量的机制,并且越来越有可能影响那些在没有仔细思考反馈动态的情况下就将合成数据生成常态化的团队。

领域特定 LLM 微调的合成数据流水线

· 阅读需 11 分钟
Tian Pan
Software Engineer

你在合成数据上微调的模型在内部评估中得分 95%。然后你部署了它,它却自信地编造出不存在的药物相互作用,引用了案件编号错误的法律先例,并幻觉出名称听起来很合理的 API 端点。模型的流畅度没有退化——它以一种流畅度指标完全无法察觉的方式变得更糟。研究人员称之为知识崩溃 (knowledge collapse):事实准确性下降,而表面连贯性完好无损。这是合成数据训练中较为隐蔽的失败模式之一,通常发生在工程师构建流水线却未考虑到这一点时。

对于在特定领域微调 LLM 的团队来说,合成数据生成已变得不可避免。大规模的人工标注不仅昂贵、缓慢,且对于需要专业知识的任务来说是不可能的。由能力强的教师模型生成的合成数据可以廉价地填补这一空白。但流水线并不只是“向 GPT-4 索要示例,然后训练你的模型”那么简单。细节决定了你得到的是一个在特定领域表现优于通用模型的专业系统,还是一个流畅但事实漏洞百出的系统。