共同演化陷阱：AI 功能的成功如何正在悄悄破坏其评估体系

你的 AI 功能上线了。它运行良好。用户正在使用。满意度评分在上升。你回头运行了原始的评估套件——依然是绿灯。六个月后，某些事情悄然出了问题，但你的仪表盘还没有显示出来。

这就是协同演化陷阱（co-evolution trap）。在你的 AI 功能部署的那一刻，它就开始改变使用它的用户。他们调整工作流、措辞和预期。这种适应使得你的功能实际处理的输入分布与发布时测量的分布产生偏离。评估套件保持绿灯，是因为它停留在部署前的世界。现实世界的表现以评估套件从未捕捉到的方式发生了漂移。

行业数据为这一现象提供了数字佐证：91% 的 ML 模型随着时间的推移显示出可衡量的退化，32% 的生产评分流水线在最初六个月内经历了分布偏移。较少被讨论的是，这种偏移中有多少是用户诱导的，而不是自然的数据漂移。你的功能不只是遇到了一个变化的世界——它还帮助改变了它所运行的世界。

为什么成功会加速这一陷阱

协同演化陷阱是反直觉的，因为它是由成功而非失败驱动的。一个无人使用的功能不会与用户共同演化。而一个用户喜爱并集成到工作流中的功能则会。

以代码补全工具为例。部署前，你根据完全由人类编写的真实代码库对其进行评估。它表现良好。部署后，开发者在没有完全理解的情况下接受 AI 建议。他们的编码风格发生了变化。他们编写更符合 AI 建议的代码，避开补全效果变差的模式。今天从同一个开发团队构建的代码库，在结构上与训练数据看起来截然不同。

同样的动态也发生在推荐系统、搜索自动补全、写作助手和内容审核中。每类功能都有一个机制，通过该机制，用户行为会针对模型产生的内容做出反应并发生改变。推荐系统制造了过滤气泡，表达出的偏好随着时间的推移而收窄。搜索自动补全训练用户以引擎能很好处理的方式来组织查询。写作助手改变了人们认为可以接受的文本分布。

残酷的转折点在于，数据飞轮——AI 产品团队依靠它来不断改进功能的机制——反而会加速这一陷阱。更多的用户参与产生更多的训练数据，这本应让模型变得更好。但当用户已经根据模型的怪癖调整了行为时，新的训练数据反映的是他们调整后的行为，而非底层任务。飞轮在旋转，但它是在错误的表面上磨光模型。

只听好话的评估套件

古德哈特定律（Goodhart's Law）——“当一个衡量指标变成目标时，它就不再是一个好的衡量指标了”——通常被用在团队博弈基准测试的语境中。但更危险的形式是这种被动的：你的评估套件并没有被博弈，它只是过时了。

发布当天的评估套件是你的功能存在之前用户需求的快照。它捕捉了原始任务的分布：在没有辅助、未接触过 AI 建议、使用没有考虑到你的功能而开发的工作流的情况下。十二个月后，那个快照描述的是一个已不存在的人群。你的用户已经使用你的功能运行了一年。他们的行为变了。

这种区别之所以重要，是因为它对大多数监控设置是不可见的。标准的模型漂移检测寻找输入统计属性的变化：协变量偏移（特征分布变化）或概念漂移（特征与正确输出之间的关系变化）。这两个框架都隐含地假设“真实”分布是稳定的，而模型正在偏离它。

用户诱导的分布偏移颠倒了这一逻辑。模型并没有偏离真实分布。真实分布正在向模型的行为漂移——而原始评估套件仍在测量那个已不存在的适应前分布。

结果就是评估与部署之间的鸿沟（eval-deployment gap）：评估是绿灯，现实世界的性能却在下降，并且没有信号能将两者联系起来。

检测实际上是什么样的

弥合这一鸿沟需要重新思考你衡量的内容和时机。

先细分，再聚合。 聚合指标隐藏了退化的形态。用户诱导的分布偏移往往具有队列特异性：使用该功能时间最长的早期采用者，将显示出与原始评估分布最大的漂移。新用户的行为则更接近发布当天的基准。如果你只跟踪群体层面的指标，早期采用者的信号会被看起来正常的新用户所稀释。按使用时长区分队列并独立跟踪。

为你的输入建立行为指纹。 不要只监控原始输入特征，要跟踪行为标记：用户在查询中使用的词汇量、他们将功能的输出链入后续输入的模式、接受与拒绝建议的比率。当这些标记发生偏移时，你就有了用户适应的证据，而不仅仅是统计漂移。

针对固定的预部署输入保留集定期运行盲测。 这是实时评估套件无法提供的硬关卡。保留一份发布前收集的、带有经过人工标注的真值（ground truth）的冷冻输入样本，并每季度针对当前模型运行一次。该分数与实时评估分数之间的差值可以告诉你差距拉大了多少。一个在单季度内损失了 8 个百分点的信用风险模型，在标准漂移指标上看起来可能依然正常，直到队列层面的业务结果显现出来。

测量不同查询类别的差异化退化。 并非所有输入都会同等程度地漂移。映射到用户适应模式的查询看起来会很好；而代表原始分布边缘的查询退化得更快。按查询类型索引你的评估失败，并跟踪失败模式分布是否正在改变。如果一种查询类型在发布时产生了 5% 的失败，但六个月后上升到了 25%，那么这就是协同演化压力集中的地方。

构建保持诚实的评估体系

检测能告诉你差距的存在。要防止这种差距变得不可见，就需要构建能够自我更新的评估基础设施。

将评估语料库视为一个动态的制品，而不是一个静态文件。 按照固定的节奏（至少每季度一次），对实际的用户交互进行采样，进行人工标注（或参照人工标注校准后的 LLM 评判），并将其添加到评估语料库中。淘汰最早一批的交互数据，以防止语料库完全变成对“已适应用户”群体的重构。你需要的是一个滚动样本，涵盖从新用户（适应前的基准）到老用户（完全适应后的行为）的范围。

构建评估更新的触发条件。 不要只是等待日历提醒来强制复查，而是要为行为指纹指标设置阈值。当当前输入与发布日输入之间的词汇差异超过阈值时，触发评估更新。这样可以在业务指标显现问题之前，将行为信号与评估周期联系起来。

在评估套件中将准确性与鲁棒性分开。 即使对原始分布的鲁棒性已经崩溃，在已适应分布上的准确性看起来可能仍然很稳定。运行这两个切面。已适应输入上的准确性与原始分布输入上的准确性之间的差距，直接衡量了你的评估覆盖范围缩减了多少。

跟踪用户不再发送的内容。 用户引发的分布偏移部分体现在用户停止提交的内容上。如果某类输入以前经常出现，而现在很少出现，这可能意味着该功能处理得非常好，以至于用户不再需要操心——或者可能意味着用户已经学会了不提交它，因为该功能处理得很糟糕。按类型统计查询量，并使用稳定的类别标签进行长期跟踪，可以揭示表面准确性指标所忽略的“抑制模式”。

技术陷阱背后的组织陷阱

协同进化陷阱具有政治维度，这使得它比纯粹的技术漂移更难解决。当一个 AI 功能取得成功时——采用率高、满意度得分强——机构内部就会有一种维持现状的压力。重新评估一个成功的功能感觉就像是在寻找可能不存在的问题。

这种压力在协同进化陷阱最严重的时刻往往也是最强大的。一个上线两年且采用率很高的功能有充足的时间与用户协同进化。它原始的评估套件已经严重过时。而运行全面重新评估来验证这一点的动力却是最低的，因为该功能“显然运行良好”。

评估套件变成了一份记录过去成功的文档，而不是对当前性能的衡量。继续运行它会提供虚假的安慰：它的设计初衷是验证最初的设计决策，而不是追踪用户今天的需求与模型交付内容之间的差异。

打破这一局面需要将评估的及时性视为一等公民的工程义务——而不是某人有空时才进行的调研练习。适用于依赖更新和安全补丁的纪律同样适用于这里：评估语料库也有生存时间 (TTL)，超过期限而不更新就是带有复利的技术债。

前瞻

协同进化陷阱并不是避免部署 AI 功能的理由。它是将部署视为评估义务的开始，而非终结的理由。

在发布时评估的模型捕获的是功能存在之前用户需求的快照。而在六个月、一年或两年后评估的模型，则需要捕获用户在已经使用你的功能并产生适应的世界中真正的需求。这是两种不同的分布，将它们混为一谈会产生最阴险的虚假信心：那种由全绿仪表盘支撑的信心。

最容易陷入这个陷阱的功能正是用户最喜欢的功能。这就是征兆。当用户参与度很高且评估结果为绿色时，不应该停止观察，而应该询问评估是否仍在衡量正确的事情。