跳到主要内容

你的 Agent 学会了致敬的那个错别字

· 阅读需 11 分钟
Tian Pan
Software Engineer

某家保险公司用一整年的客服对话记录微调了一个支持模型。上线不到一周,合规审查员就发现了怪事:这个机器人一直把 "deductible"(免赔额)写成 "deductable"。不是偶尔出错——而是每八条出现该词的消息里,大约都会有一条这样写。模型并没有自己发明这个拼写错误。它继承了这个错误。一小撮一线客服两年来一直这么打字,而语料库忠实地反映了他们打的内容,不是字典里的内容。

这就是在运营数据上做监督式微调最令人不安的地方:模型并不是在学习你的领域,它是在学习你的语料库。这两者有重叠,但并不等同,而那道缝隙正是每一个本可预防的行为缺陷藏身的地方。训练数据里的频率并不是正确性的信号,它只是一个信号——告诉你你的团队恰好做某件事做得够多,多到模型愿意模仿。

错别字是最容易识别的情形。难的是那些没人愿意写成规则的部分,因为大家都默认模型会学到工作的"专业"版本,而不是工作被实际执行的样子。

为什么频率不等于正确性

预训练模型自带一个先验。在开放网络上,字典拼写远多于常见拼写错误,大致就跟细心编辑远多于忙乱客服的比例差不多,所以基础模型不假思索地写出 "deductible"。微调会把这个先验拉向你给它看的任何东西。给模型在匹配上下文中看几百次 "deductable",新的后验就会塌缩到语料库频率给出的答案,而不是字典给出的答案。

关于数据质量的文献令人不安地清晰地揭示了这种效应的量级。真实世界的数据集普遍带有 7%–50% 的标注噪声。最近一项关于涌现式失准阈值的研究发现:至少需要 50% 的正确数据,领域特定性能和道德对齐才能可靠地恢复——而即使在 90% 正确率下,微调后的模型也常常无法匹敌其基础模型的鲁棒性。模型没有信号去区分"语料库经常做的事"和"语料库正确做的事"。它只看到频率,而频率会赢。

这一点在语料库感觉最干净的地方反而最要紧。客服对话、临床记录、销售通话纪要、代码评审评论——这些都是专业人士做真实工作时写下的内容,读起来很有权威感。它们同时也充斥着特立独行的缩写、内部黑话、复制粘贴的模板、反复出现的错别字,以及某个人的口头禅通过引用回复链条传染开来。这些东西没有任何一项会被标注员标出来,因为它们相对工作本身并没有"错"。它们就是工作本身——包括那些不应当被建模的部分。

从个人习语到品牌语调的流水线

deductable 这个例子很温和,因为它显而易见。同样的机制会产生任何拼写检查器都抓不到的效果。

想象一位一线客服,大约三分之一的回复都以 "honestly, I think this might be the issue"(说实话,我觉得问题可能在这儿)开头。这是个语言习惯。它柔化了一个其实他自己挺确信的建议。它同时也是这一位客服的声音,不是公司的声音。在一整年的高频对话之后,这位客服的聊天记录主导了语料库中模板化最严重的那部分——升级确认、问题假设、后续建议。在这个语料库上微调,"honestly, I think this might be the issue" 就成了你那个面向客户的 AI 的风格指纹。每位客户都看到同样的犹豫语气,在同样的位置,带着同样的虚假亲近感。

把这种事乘以一个客服团队一年里做出的上千个小决定。那位总在确认资格之前就发优惠券的客服。那位用三句话清脆节奏回答账单问题的客服。那位每次诊断不出 UI bug 时就习惯性地承诺"我会让工程团队的人联系你"的客服。语料库不会把这些标注成习惯——它们看起来就是答案。微调会把它们当作模板原样照搬下来。

最近的研究证实这种风格迁移有多廉价。2025 年的一项研究发现:在仅仅 100 段模拟对话上微调一个模型,就足以盖过基于提示词的语气指令。机制很直接——在窄分布上对少量样本进行的梯度更新,会盖过一段长长的系统提示,而解码器本来就会部分忽略后者。反过来说,100 条误导性样本也就够了。意外继承某种风格事故的门槛低得惊人。

大多数团队跳过的那道整理工序

修复方法并不奇特。它就是那道在微调之前要做一次的预处理步骤:对语料库里每个反复出现的模式问一个非常具体的问题——这是一个值得保留的领域惯例,还是一个值得规范化的风格事故?

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates