25 篇博文 含有标签「machine-learning」

几乎在每一个 AI 产品团队中都会出现这样一种模式：团队发布了初始模型，用户开始与之交互，接着有人在回复底部添加了一个“点赞/点踩”小部件。他们称之为反馈闭环。三个月后，模型并没有任何改进。团队纳闷为什么飞轮没有转起来。

问题不在于执行，而在于显式评分并不是反馈闭环——它们只是调查问卷。只有不到 1% 的生产环境交互会产生显式用户反馈。而那 99% 从未点击任何按钮的用户正在向你发送远为丰富的信号；你只是没有收集它们。构建真正的反馈闭环意味着通过系统埋点来捕获行为轨迹，在大规模场景下高效地标注它们，并将其导回训练和评估流程中，从而实现随时间推移的复利增长。

你的模型表现不佳，于是你开始深入审查训练数据。审查到一半时，你发现两位标注员对同一个边界案例给出了截然相反的标签——而两人都在遵循规范，因为规范本身存在歧义。你修正了规范，重新标注了受影响的样本，重新训练，找回了几个 F1 分数点。两个月后，同样的事情又发生了，只是换了一位标注员和另一个边界案例。

这不是标注供应商的问题，也不是数据质量工具的问题。这是一个基础设施问题——而你还没有把它当作基础设施问题来对待。

大多数工程团队处理标注的方式，就像处理会议室预订系统一样：采购工具、编写规范、雇几名外包人员、交付数据。当你只需要一次性标注数据集时，这套模式还算管用。但一旦标注成为持续驱动线上生产模型的活动——对于几乎所有从原型走向生产的团队而言，这已经是常态——这套模式就会彻底崩溃。

一个团队花了六个月时间训练一个情感分类器。留出集（holdout set）上的准确率看起来很稳健。他们发布了它。三个月后，一项审计显示，该模型一致地将非英语母语者的产品投诉评价为比母语者的相同投诉更负面——即使文本表达的意思完全相同。根源不在于模型架构，不在于训练过程，而在于标注团队：十二名身处同一个时区的英语母语者，没有人注意到某些表述在翻译后的文本中承载着不同的情感权重。

模型学到的是标注者的盲点，而非真实的信号。

这就是实践中的标注者偏差（annotator bias）。它不会自我宣告，而是表现为你信任的评估分数、看起来合理的基准排名，以及在未经过仔细测试的子组上表现怪异的已部署系统。基准真相（Ground truth）的污染处于机器学习流水线中所有其他环节的上游——而这是大多数团队发现得太晚的问题。

有一种特定的失败会在 AI 功能有机会证明自己之前就将其扼杀。这看起来不像是技术故障——模型架构是合理的，评估分数也不错，功能也发布了。但采用率停滞不前，用户流失，六个月后团队悄悄降低了该功能的优先级。复盘时的诊断是：“数据不足”。

这就是冷启动陷阱。AI 功能随着参与数据的增加而改进，但用户在功能好到足以产生用处之前不会参与。这种循环依赖不是一个可以解决的数学问题——它是一个伪装成工程问题的产品设计挑战。大多数团队都带着同样的错误计划跳了进去：先收集数据，后发布机器学习。

你的发票解析器可能运行得不错。给它一个来自世界 500 强供应商的清晰、数字化的 PDF —— 结构化的行、一致的列宽、机器生成的文本 —— 它就能以近乎完美的准确度提取行项目。但当有人上传一份来自区域供应商的多页合同、一份带有手写修改的扫描表格，或者一份表格标题在第 3 页而数据行延续到第 6 页的财务报表时，提取器就会悄无声息地失败，返回部分数据，或者自信地生成结构化输出，而这些输出的错误方式是任何下游校验都无法捕捉到的。

这是企业级文档智能的核心问题：使你的系统崩溃的文档并不是边缘案例。它们往往是具有最高业务价值的文档。

这条流水线在纸面上看起来很合理：你有一个目标任务，没有人工标注样本，但有一个能力强大的大模型可用。于是你用该模型生成标签，再用这些标签微调一个更小的模型。发布，重复。

没有人足够重视的问题是：当你的标注模型和目标模型在同一批互联网数据上训练时会发生什么？而如今，它们越来越多地确实如此。

你的团队花了三个迭代周期标注了5万条领域样本。你在前沿模型上运行了LoRA微调。评估指标提升了。然后一位同事稍微改变了提示词的措辞，模型又回到了你以为已经抑制的行为。这不是数据集问题——这就是预训练的阴影。

实践者不断重新发现的核心洞察是：微调教会模型如何在新语境中说话，但无法改写模型根本知识或倾向。在预训练期间编码的行为、偏见和事实先验是一个引力场——微调只能在其周围轨道运行，很难真正逃脱。

大多数决定微调模型的团队在写下第一行训练代码之前，都会花上几周时间争论该使用哪种方法。这种争论很少触及核心问题。真正的问题不是 “SFT 还是 DPO？”，而是 “我试图缩小什么样的差距？”

有监督微调（SFT）、人类反馈强化学习（RLHF）和直接偏好优化（DPO）并不是解决同一个问题的竞争性方案。每种方法针对的是不同的失败模式。在 SFT 足以解决问题时选择 RLHF 会浪费数月时间。而当问题实际上是偏好不匹配时选择 SFT，则会产生一个表达流利但在生产环境中暴露问题之前很难察觉到错误模型。

这篇文章提供了一个决策框架。它将每种方法映射到其解决的具体问题上，解释了哪些信号预示着哪种方法将占主导地位，并提供了一套诊断方法论，帮助你在开始训练之前识别出实际存在的差距。

你的模型在留存测试集上达到了 91% 的准确率。p95 延迟低于 200ms。与之前的规则系统相比，错误率降低了 40%。从每一个技术指标来看，这个项目都是成功的。六个月后，领导层取消了它。

这不是假设。80% 的 AI 项目未能实现预期的商业价值，而这些失败的大多数并不是由于模型性能不足。它们源于工程师所衡量的内容与决策者所能理解的内容之间的鸿沟。技术团队使用的语言，高管无从评估——在缺乏可理解信号的情况下，领导层默认持怀疑态度。

指标翻译问题并非沟通软技能，而是一门工程纪律，而大多数团队把它当作可选项，直到融资审查前夕才想起来。

你构建了一个个性化功能，将其接入应用，然后发布上线。第一周到了。系统尽职尽责地为每个新用户推送同样的几个全局热门内容——你的 AI 号称智能，却连按字母排序的列表都不如。参与度指标几乎没有变化。团队得出结论：模型需要更多调优。其实不然。模型完全按设计运行。问题在于，你要求它在没有任何可学习内容之前就开始学习。

这就是冷启动问题，它摧毁的 AI 功能比糟糕的模型多得多。

核心矛盾是循环的：行为机器学习系统需要用户交互才能产生有用的预测，但它需要产生有用的预测才能获得用户交互。某大型电商平台记录显示，冷启动影响了超过 60% 的新用户——这些用户收到了明显失准的推荐，可测量地损害了转化率。在整体指标中，这一信号几乎不可见，因为活跃用户掩盖了损失。

每一项微调工作最终都会达成同样的直觉：更好的数据意味着更好的模型，而更好的数据意味着更高质量的样本。因此，团队会构建复杂的标注流水线，以过滤掉平庸的输出，只保留金标准回复，并基于让他们引以为傲的数据集进行训练。然而，由此产生的模型在那些最初推动项目启动的具体用例中表现不佳。这种失败如此普遍，以至于值得拥有一个专属名称：课程陷阱（curriculum trap）。

这个陷阱在于 —— 仅策划你最好、最自信、最权威的输出并不能教会模型变得更好。它教会模型的是无论是否合理都要表现出自信。你创造出的东西在演示中看起来令人印象深刻，但在生产环境中却漏洞百出，因为生产环境充满了你的策划过程系统性排除掉的混乱边缘情况。

2024 年初，Open LLM 排行榜的榜首几乎被一种从未经过训练的模型全面占领——它们是合并而来的。各团队将两三个基于 Mistral-7B 微调的变体，用一个 YAML 配置文件对权重进行平均，便以极低的计算成本超越了专门训练的模型。从外部看，这项技术简单得近乎可笑：把一些张量加在一起，除以二，就可以发布了。但现实远比这复杂——如果你不理解其背后的原理，那些锋利的故障模式足以让一个生产部署翻车。

这是一份面向希望在生产中使用模型合并的 ML 工程师的实践指南：各方法在数学上到底做了什么、何时有效、何时会悄然降级，以及如何针对给定的候选模型选择正确的工具。