你的标注流水线才是 AI 产品的真正瓶颈

每个开发 AI 产品的团队最终都会发布一个反馈组件。点赞、点踩、或者星级评分，又或者是修正字段。组件上线了，数据流转了，但随后几周甚至几个月，模型却没有任何改变——而团队仍然坚信他们拥有一个有效的反馈闭环。

组件只是简单的部分。其背后的标注流水线（annotation pipeline）才是 AI 产品真正陷入停滞的地方。

这通常不是工具问题或资源问题，而是一个基础设施的优先级排序问题（infrastructure sequencing problem）。团队首先构建数据捕获层，因为它可见且易于演示。而下游机制——Schema 版本控制、标注者间一致性（inter-annotator agreement）跟踪、路由、队列管理、重训练触发器——则由于在出问题前不可见，而在一个又一个 Sprint 中被降低优先级。等到团队意识到反馈在数据库中过期未用时，数周甚至数月的生产信号已经变得无关紧要。

捕获与改进之间的鸿沟

考虑一个典型的轨迹。一个团队发布了一个 LLM 功能。他们添加了点赞/点踩组件并进行了仔细的埋点。一周内，他们收到了数千个负面信号。六周后，模型依然没有变化。

这期间发生了什么？通常情况是这样的：一位数据科学家将反馈导出到电子表格中，发现标签定义模糊（点踩是指“事实错误”还是“不符合我的需求”？），在 Slack 中发起了讨论，接着被卷入其他工作，讨论便冷了下去。数据在那儿积压。新的反馈在旧反馈之上堆积。最终有人提出了标注 Schema，但第一个 Schema 与原始反馈的存储方式不兼容，导致历史数据无法使用。循环重新开始。

这种模式具有可衡量的成本。研究一致表明，91% 的 ML 模型性能会随着时间的推移而下降，而陈旧的标注——即在不同的数据分布下或针对早期标签 Schema 收集的标注——在三到六个月内会变得对模型质量产生实质性损害。在该窗口期内未被路由、审核和合并的反馈不仅是被浪费了，甚至可能会降低它本应改进的模型的性能。

为什么标签 Schema 版本控制会破坏下游的一切

标注 Schema 是人类反馈与模型训练之间的契约。当它发生变化时——在快速更迭的产品中，这种情况经常发生——每一个依赖旧 Schema 的下游系统都必须进行协调。

问题在于，Schema 的更改几乎从未像代码更改那样被严格跟踪。一个标签从二元（“有用 / 无用”）变为四级量表；季度中期增加了一个新的意图类别；一个边缘案例被重新分类。这些变化中的每一个都会在标注历史中产生分叉：更改前收集的数据与更改后收集的数据不具有直接可比性。

管理得当的团队会像对待代码一样对待标签 Schema。他们使用版本标识符，维护可以将历史标注根据新定义重新解释的迁移脚本，并在开启任何新的标注批次前强制执行 Schema 兼容性检查。像 Databricks MLflow 3 这样的平台现在为标注 Schema 提供类似 Git 的版本控制，正是因为这种需求无处不在。Snorkel 的编程式标注（programmatic labeling）方法——将标签定义编码为可执行函数而非自然语言指南——使得追溯性重新标注变得可行：更新标注函数，在历史语料库上重新运行，你就能在无需人工重新标注的情况下获得一份协调一致的数据集。

不这样做的团队会发现自己无法整合跨不同产品版本收集的反馈，这实际上意味着每当产品演进时，他们的训练数据都会“清零”。

标注者间一致性（Inter-Annotator Agreement）不是一次性检查

大多数标注工作流仅在初始设置阶段计算一次标注者间一致性（IAA），作为健全性检查（sanity check）。这是错误的频率。

IAA 衡量人类标签的一致性——即两个独立的标注者对相同输入达成一致的频率。Cohen's Kappa 修正了两个标注者之间的随机一致性，适用于二元和定类标签。Krippendorff's Alpha 则能同时处理多个标注者，并适用于定序和定距数据，使其更适合主观质量评分。这两个指标现在都已内置在 Prodigy 和 Datasaur 等标注平台中。

问题不在于计算 IAA，而在于是否持续计算。随着标注队列的增长，新标注者的加入，指南因非正式解读而产生偏差，以及输入分布的变化。一个在第一个月测得 0.82 Kappa 的团队，到第四个月可能在不知情的情况下仅以 0.58 Kappa 的水平运行。这种退化的症状表现出来的不是标注错误，而是模型不稳定、无法解释的性能倒退，以及训练运行无法收敛到明显的改进上。

补救措施是每周使用共享校准集（calibration set）进行 IAA 检查：每周让所有标注者独立标注一组固定的输入样本。分歧会触发标注者与工程团队之间的同步会议。这听起来成本很高，但它远比调试一个基于静默退化标签训练的模型要便宜得多。

无人谈论的路由问题

即使反馈被捕获且标签保持一致，数据通常也无法到达能够对其采取行动的人手中。这就是路由问题，它加剧了 Schema 和 IAA 问题。

在大型产品中，反馈涉及多个模型组件。一次简单的用户交互可能包含检索步骤、摘要步骤和格式化步骤，每个步骤由不同的团队负责。对最终输出的“点踩”可能意味着其中任何一个层级出现了故障。如果没有路由——即把反馈信号映射到负责的模型组件的逻辑——反馈就会进入一个无人感到需要负责的通用队列。

有效的路由需要两样东西：一套映射到所有权的失败模式分类体系，以及针对该分类体系对传入反馈进行分类的自动分拣系统。在大规模生产环境下，这绝非人力所能及。运行成熟标注流水线的团队使用分类器模型来路由反馈：一个在过去标记样本上训练的轻量级模型，它学会了区分“这是检索失败”、“这是生成失败”还是“这是格式化失败”。每个类别都会路由到相应模型团队的标注队列中。

在底层模型变好之前，这听起来需要构建大量基础设施。这正是重点所在。推迟建设这些基础设施的团队会将时间花在错误的改进上——当问题出在检索器时，他们却在优化生成器，反之亦然。

加载中…