跳到主要内容

用户侧概念漂移:当你的提示词依然奏效,但用户已经变了

· 阅读需 11 分钟
Tian Pan
Software Engineer

大多数团队都在契约的错误一端设置了漂移监控(drift monitoring)。他们盯着模型——当供应商发布新的 checkpoint 时发生的性能偏移、提示词重写后的输出分布变化,或是预示着安全过滤器重新调整的拒绝率激增。仪表板非常详尽,告警已接入 PagerDuty,团队也准备好了针对“模型变了”的运维手册。然而,当模型没变而仪表板依然报红时,这些都无济于事,因为真正发生偏移的是你的用户。

用户侧概念漂移是几乎所有评估流水线(eval pipeline)都会忽略的一种问题。你的提示词、模型和工具与发布当天完全一致。你的黄金测试集(golden test set)依然保持 91% 的通过率。但在第一周达到 91% 的提示词,在第三十周的实际效果可能只有 78%,因为底层的输入分布已经发生了变化——用户了解了产品并改变了提问方式、词汇发生了演变、出现了季节性的任务类型、竞争对手重新定义了品类,或者某个热门帖子教给用户一种表达相同意图的新方式。模型和提示词稳住了,契约也稳住了,但契约所针对的那个世界变了。

这类回归(regression)之所以如此容易被忽视,是因为评估集本身就是盲点。一个包含 200 个查询的静态黄金集,在筛选之初是生产环境的一个代表性切片。六个月后,它就成了博物馆里的陈列品。它的分数依然很高,因为提示词正是为了在这个集合上拿到高分而调优的。评估报告显示一切正常(green)。用户满意度 NPS 却在每个季度悄然下降两个百分点。团队将其归咎于“感觉(vibes)不对”或“用户期望值升高”,针对同样的陈列品发布了一些提示词微调,却从未察觉陈列品本身才是问题所在。

为什么用户漂移能躲过内部评估

这种病理是结构性的。黄金集是根据时间点 T 的生产环境快照筛选出来的。针对该黄金集不断迭代提示词,直到获得高分。然后两者都被冻结。从那一刻起,“提示词表现良好”实际上意味着“提示词在处理时间点 T 常见的查询时表现良好”。此后的每一个生产环境查询,都是从一个正在悄然偏离 T 的分布中提取的样本,而你的黄金集没有任何机制来察觉这一点。

更糟糕的是,团队的直觉强化了这种错觉。工程师在排查生产环境故障时,观察单个案例并认定每个案例都是“边缘案例(edge case)”,因为没有人绘制边缘案例随时间变化的频率。黄金集的总分一直显示健康,因此没有顶层指标(top-line metric)来强制启动这一讨论。等到有人用新鲜样本测试提示词并发现分数下降了 15 分时,漂移已经累积了数月之久。

这在结构上与模型漂移不同。模型漂移通常会自我宣告——输出模式(schema)崩溃、拒绝率跳升、延迟情况改变。用户漂移则无声无息。模型正在做它一直在做的事情,系统是健康的,契约只是不再匹配用户的需求。

三种具体的漂移机制

用户侧漂移并非单一现象。它至少包含三种形式,具有不同的特征和解决方法。

词汇演变(Vocabulary mutation)。 随着产品的普及,用户针对同一意图所使用的术语会发生变化。六个月前,你的支持团队所理解的“Agent”与现在的含义可能大不相同。“总结这个”曾经意味着一段话;在竞争对手发布了一个能生成结构化行动项的功能后,现在有一半的用户在输入“总结”时,实际指的是行动项。意图分布是稳定的,但表象形式已经发生了偏移。一个依赖特定措辞进行模式匹配的提示词,性能会悄然退化。

任务组合偏移(Task-mix shift)。 用户发现了一些最初没怎么使用的功能,或者停止使用某些功能。一个发布初期主要处理代码补全请求的编程助手,在用户发现它能胜任解释代码后,其“解释代码库”的需求会缓慢增加,随着解释结果建立起信任,“寻找 Bug”的需求也会随之上升。提示词是在 80% 的流量都是代码补全时调优的。它处理补全依然没问题,但现在占流量 30% 的解释和调试需求正由同样的提示词处理,质量正在悄悄下降。

品类重塑(Category reframing)。 外部事件——竞争对手发布产品、法规变化、另一个供应商的新模型爆火——都会重塑用户对整个产品品类的期望。在重塑发生后加入的用户带着不同的心理模型而来,他们会提出形式不同的问题,且对你的系统基于旧有模式给出的答案感到不满。这是仅凭内部数据最难检测的一种变体,因为变化是在你的漏斗之外触发的。

这三者往往混合在一起。一个为期六个月的漂移可能是 50% 的词汇演变、30% 的任务组合偏移和 20% 的品类重塑。每种情况都需要不同的干预措施。如果将它们简单归类为“用户满意度下降”,将无法找到切入点进行解决。

在偏移加剧之前进行检测

能够经受住生产环境考验的检测方法包含三个层级,其中任何一层都不依赖于人工发现问题。

第一种是生产查询与评估集(eval set)之间的滚动嵌入聚类(embedding-cluster)对比。为两者计算嵌入向量,将生产环境的嵌入向量聚类为 K 个语义组,并计算每个组在评估集中的占比。当某个生产集群在评估集中的占比为零或趋于零时,该集群对你的评估来说是不可见的——根据定义,你并没有在测量该部分的质量。将该占比作为一个顶级指标进行追踪。当它超过阈值(例如,10% 的生产流量处于评估集覆盖率低于 5% 的集群中)时,这就是偏移(drift),此时你的评估集正在误导你。

第二种是查询类别的新颖率(novelty rate)。使用轻量级分类器或基于 prompt-only 模型的 few-shot 提示词,将每个进入的生产查询分配到固定分类体系(taxonomy)中(该体系应与评估集分层所用的体系一致)。追踪随时间变化的“分类体系外”分类的比率。新颖率的上升是一个领先指标,表明用户的任务组合正在向你的评估集未涵盖的内容偏移。这个指标通常比任何输出质量信号提前几天或几周发生变动,而这正是你所需要的预警时间。

第三种是针对近期流量,对比“冻结提示词”(frozen prompts)与“生产提示词”的胜率。定期抽取近期生产查询的样本(过去 7 天,按类别分层),并针对这些查询运行两个版本的提示词:发布时表现良好的冻结版本,以及随后的任何修订版本。让裁判模型(judge model)或人工标注环节对输出进行两两对决(head-to-head)打分。如果冻结提示词在近期流量上的胜率下降,但在黄金集(golden set)上的胜率保持稳定,这不属于提示词退化(regression),而是真实世界已经偏离了黄金集。针对实时生产流量的影子评估(Shadow evaluation)——在不影响用户的情况下,对复制的请求运行候选提示词——是大多数团队采用的操作模式,因为它能在不让用户承担风险的情况下提供统计效力。

孤立地看,这些信号中的任何一个都可能带有噪声。但如果其中两个同时触发,则是一个强烈的信号,表明偏移已从理论层面转变为代价昂贵的实际问题。

评估集是易耗品,而非权威标准

更深层次的组织转变在于团队如何看待评估集本身。大多数团队将他们的黄金集视为一种权威的人造资产——就像他们对待生产数据库 Schema 一样。它被签入代码库,受代码审查保护,破坏性变更需要正当理由。这种心智模型是错误的。黄金集不是 Schema。它是一种易耗品,保质期以月为单位;你的产品增长越快,保质期就越短。

一个实用的操作规则是为黄金集中的每一行设定明确的过期日期。当一个数据行被添加时,它是对某些真实生产查询的忠实呈现。一年后,它可能依然如此,但也可能变成了一件“博物馆陈列品”。如果制定一项过期政策,规定除非根据近期生产流量重新验证,否则 90 天后将该行标记为陈旧,这将产生一种强制机制:必须有人查看这一行,确认它仍然符合真实流量特征,然后要么重新批准,要么将其替换。

第二条规则是按固定频率更新评估集——在经历过此类问题的团队中,最常见的频率是每季度一次——通过对近期生产流量进行采样,按原始集合中使用的相同分类体系进行分层,对失败案例进行过采样(oversampling),并用新鲜示例替换掉集合中表现最差的四分之一。集合规模保持不变,但其代表性得到了更新。

第三条规则是显式地对评估集进行版本管理,并同时报告当前版本和前一个版本的得分。如果 v3 版本的得分跃升但在 v2 上无法复现,这表明提示词是在针对新的评估集进行微调,而非真正的质量提升。如果 v2 的得分跃升但在 v3 上无法复现,则是更糟糕的情况——提示词在处理过去的问题上变得更强,但在处理现状时却在悄无声息地变差。

关键在于围绕评估集构建成熟团队在特征存储(feature stores)或训练数据上已经建立的那套机制:血缘追踪、过期管理、版本控制和偏移监控。评估集就是数据,而数据是会腐烂的。

组织失效模式及其应对策略

最常见的组织失效模式是:负责评估集的团队与负责生产流量的团队不是同一个,且双方都没有动力去检测评估集是否已经陈旧。评估团队的指标是“我们是否运行了评估并报告了得分”。产品团队的指标是“用户是否完成了任务”。当两者之间的差距拉大时,没有人会被呼叫(paged),因为没有人的指标是“这两者是否仍在测量同一件事”。

解决方案是结构性和操作性并举的。将评估集的新鲜度作为一级指标——与通过率(pass rate)并列。在仪表盘上将嵌入聚类覆盖率和新颖率作为评估得分旁边的面板进行展示。为“评估集是否仍具有生产代表性”定义红黄绿状态。让负责提示词质量的轮值人员(on-call rotation)同时也负责该代表性信号。成本很低;但不这样做的代价是,大家以为正在捍卫的质量标准其实正在缓慢瓦解。

前瞻性的转变在于,停止将评估视为一个固定的参考点,而是将其视为一种持续更新的测量手段,用以衡量系统能力与用户实际需求之间的差距。系统能力并没有退化——而是标准在移动。最先注意到这一点的团队,才是那些仍在监控标准的团队。

References:Let's stay in touch and Follow me for more thoughts and updates