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

一个团队利用 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 模型当时忙着生成它想象中的查询，而不是用户实际发送的查询。

这是 2026 年微调工作流中最常见的隐性失败模式之一。团队执着地迭代输出质量——更好的推理链、更广的主题覆盖、更丰富的政策遵循——却让输入分布停留在 Teacher 模型第一次采样时的状态。基准测试分数上升了，客户体验却下降了。这两个数字衡量的是不同的群体。

合成数据包含两种分布，而非一种

大多数团队在进行微调时的思维模型是：数据集是一个通过抽样并询问“答案看起来好吗”来评分的东西。这评估的是输出分布，却对输入分布只字未提。而生产环境的差距正源于输入分布。

一个合成数据集内置了两种分布：

• 输入 (inputs)：模型在训练期间看到了哪些查询？它们的长度、意图数量、标点模式、拼写错误率、语码转换行为、表情符号密度、片段结构如何？
• 输出 (outputs)：给定一个输入，模型产生了什么样的推理和响应？

当你进行微调时，模型学习的是从它观察到的输入空间到它观察到的输出空间的映射。如果训练期间的输入空间是“简洁、完整、拼写正确、单一意图、标点正确且符合 Teacher 模型被要求编写的语言”的请求，那么模型在该子空间上会有精准、自信的映射，而对该空间之外的一切则映射不明。生产环境的输入不断落入这个范围之外。模型开始临场发挥，而微调模型的临场发挥往往看起来就像是退化到了训练前就已经具备的基准水平。

行业报告将其称为“分布漂移 (distribution drift)”或“协变量偏移 (covariate shift)”，但这些术语低估了问题的严重性。这并不是分布在训练和生产之间发生了漂移，而是训练分布从一开始就不是生产分布。Teacher 模型被给定了一个主题和一个任务，而不是一个经过测量的形态，于是 Teacher 模型根据其自身的先验知识填充了形态。

Teacher 模型的先验知识是如何潜入的

每个 Teacher 模型都有自己的写作风格。如果你要求 GPT-5 或 Claude Opus 生成一千个客服查询，你得到的并不是客服查询经验分布的样本。你得到的是 Teacher 模型关于“根据我的预训练和指令微调，客服查询应该长什么样”的分布样本。

这种分布具有明显的“教师气 (teacherly)”。最近关于单 Teacher 偏见 (single-teacher bias) 的文献记录了单个生成器如何在整个合成语料库中留下风格不变性：如果 Teacher 模型啰嗦，语料库就啰嗦；如果 Teacher 模型喜欢模棱两可，语料库就模棱两可；如果 Teacher 模型倾向于正式语体，语料库就正式。2026 年一项关于 Teacher-Student 分歧的研究将其定性为 Teacher 生成的 Token 与 Student 需要建模的分布之间的风格鸿沟——这一鸿沟如此之大，以至于一些训练方案现在通过交替使用 Teacher 和 Student 的生成内容来弥合它。

同样的效果也出现在输入端，而且更难察觉。团队审查了一百个采样输入，认为“这些看起来很真实”，然后发布。“真实”是根据评审员对客户查询的直觉来评分的，而不是根据真实流量的测量特征。Teacher 模型和评审员共享相同的先验知识。微调学习了这种先验。而生产环境的用户并不符合这种先验。

一个有用的诊断方法：调取一千个真实的生产查询和一千个合成查询，然后计算基础的汇总统计数据——每条消息的平均 Token 数、至少包含一个拼写错误的比例、每条消息包含多个意图的比例、包含表情符号的比例、少于 20 个字符的比例、语码转换率。如果这两个直方图在任何轴线上看起来有显著差异，那么模型在推理时就会感受到这种差异。

证实了错误结论的评估数据

合成测试集评估（synthetic-test-split eval）是最容易操纵，也最容易让你产生错觉的数字。你预留了 10% 的合成数据集，对其运行微调，得到了 94% 的准确率，并称之为性能提升。而你实际测量的，是模型在教师模型已经生成的输入分布内进行泛化的能力。

这并不是你需要回答的问题。真正的问题是：“微调后的模型在生产环境输入上表现更好吗？”合成测试集无法回答这个问题，因为它共享了教师模型的输入先验。高合成评估分数与停滞不前的生产环境指标并存，是输入分布不匹配（input-distribution mismatch）的典型特征，而这通常被误读为“离线-在线差距（offline-online gap）”——这个短语已经成了所有没有更好名称的方法论失败的统称。

在 2026 年的技术栈中，有两种特定模式让情况变得更糟：

• 模板化的评估提示词。 最近的评估研究表明，仅更换少样本示例（few-shot examples）之间的一个分隔符，就能让基准测试准确率产生足以改变排行榜名次的波动。如果你的评估提示词模板过于僵化，而生产环境提示词随用户而异，那么甚至在考虑输入分布问题之前，你测量的范围就已经比你想象的要窄了。
• 教师评分的评估。 如果由教师模型生成数据，并由同系列模型对评估进行评分，那么生成器和裁判都共享相同的先验。裁判会自信地证明学生模型匹配了教师模型。但两者都不知道用户真正是什么样子的。

解决方法不是“一个更好的裁判”。解决方法是在一个形态与生产环境一致的数据切片上测量离线性能。

生产环境形态的微调流水线是什么样的

那些能够弥合微调中“评估到生产环境差距”的团队，通常都会做以下几件相同的事情。归根结底，这些做法都是强制将输入分布作为流水线测量和限定的属性，而不是让其成为教师模型从先验中继承的属性。

以下五种实践方案始终会出现：

• 计算生产环境输入指纹（fingerprint）。 采样 5,000 到 20,000 条真实用户输入，并计算各维度的分布：长度、拼写错误率、意图数量、语码转换率（code-switching rate）、缩写密度、表情符号流行度、碎片化比例、标点符号模式。这个指纹是一个交付物，与数据集一起进行版本控制，并定期更新，因为用户行为是会漂移的。
• 从真实的生产示例中提取种子进行生成，而非主题列表。 在 2026 年的合成数据指南中反复出现的“150 到 200 个涵盖任务类型和边缘情况的人写示例”模式，只有在这些种子是从生产流量中采样，而不是由数据团队在会议中编写的情况下才有效。教师模型基于种子进行泛化；因此，种子必须看起来像用户。
• 对合成输入进行对抗性扰动处理。 在教师模型生成干净的输入后，进行第二次处理，注入生产级的噪声以匹配指纹特征：遗漏标点、小写归一化、常见拼写错误、多意图复合、缩写以及平台特定特征（如短信截断、语音转文字错误、手机自动纠错的怪癖）。目标不是破坏数据，而是使其形态与模型实际看到的输入保持一致。
• 利用生产环境回放构建评估集。 离线评估集必须从带有事后生成标签的真实流量中采样，而不是从合成集中预留。两套评估集是很有用的：一套针对教师模型风格上限的“干净”数据集，以及一套用于实际向领导层汇报的“生产”数据集。生产环境的数据才是能预测上线效果的。
• 混合教师模型并针对风格进行限定。 通过使用两到三个不同能力层级的教师模型，并显式地在生成提示词中根据指纹的风格属性进行限定（例如：“作为一个习惯输入短句且不写标点符号的用户来编写此查询”），可以减轻单一教师模型的偏差。这样，教师模型必须针对特定风格进行生成，而不是根据其默认状态生成。

这些做法都不昂贵。计算指纹只需要一天的 Notebook 工作。对抗性处理只是一个小脚本。生产环境评估集是你的团队能组装的最廉价的数据，因为它已经存在于你的日志中了。昂贵的是在意识到差距之前上线三次微调模型，以及随之而来的返工周期。

架构层面的认知

合成数据集不是一个语料库（corpus）。它是一个受提示词约束的生成器输出，而该提示词是你微调过程中最重要的超参数。如果提示词说“生成真实的客户问题”，教师模型会生成它认为真实的输入。如果提示词说“生成符合此长度、拼写错误率、意图数量和语体指纹的客户问题”，教师模型就会生成看起来像用户的输入。

那些将“更多数据”与“更好数据”混为一谈的团队，不断扩大合成语料库的规模，假设数量可以弥补差距。事实并非如此。来自同一个教师模型先验的一百万个合成输入，只是在模型已经覆盖的维度上重复了一百万次而已。与生产环境的差距是由先验决定的，而不是数量。

一个可落地的认知重构：将输入分布视为数据与产品之间的契约。产品定义了真实用户的发送内容。数据团队必须根据该契约进行生成、测量合规性，并在训练前进行拦截。针对一个不存在的群体进行微调的团队，并不是练错了模型——他们是针对一个与实际发布的产品完全不同的产品，训练了一个极其正确的模型。模型没问题，数据集才是那个 bug。