861 篇博文 含有标签「insider」

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 Sprint 内悄然消失。复盘（Post-mortem）结果显示代码没问题，功能开关的滚动发布没问题，分析端也没问题。发生变动的是实验清单上没人负责的东西：你检索调用背后的托管嵌入模型（embedding model），在第三周、第七周，以及你开会审阅结果的那个早上，为同一个查询返回了略微不同的向量。你的 A/B 测试是真实的，但它运行的底层基座却不是。

这是每一个运行检索增强生成（RAG）的团队最终都会遇到的失败模式，而且几乎没人针对它进行设计。嵌入端点被视为像 Postgres 一样的稳定基座。但它不是。它是一个模型，其发布节奏由厂商控制，你不会去阅读它的更新日志，它的行为表现面（behavior surface）可能会发生偏移，而无需改变维度数量、SLA 或你签署的 API 合约。你以为实验测量的是功能变化，实际上测量的是检索机制的变迁，而功能开关带来的波动只是其上的噪声。

升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 escalate_to_human，随后请求滑入工单队列，并向用户礼貌地回复“专家稍后会跟进”。工程团队在发布清单上完成了闭环确认。值班表上也列出了负责接收的人员。

六个月后，一次审计对该路径进行了回溯。升级工具打开了一个 Zendesk 工单。Zendesk 队列由客服团队为了维持 SLA 响应时间而设立的预审智能体进行分拣。预审智能体由于找不到可以直接解决的政策匹配，调用了自己的 delegate_to_specialist 工具——该工具将案例路由给了一个专家智能体。而专家智能体在不确定时，又调用了 escalate_to_human。追踪轨迹形成了一个闭路。审计抽样调查的升级案例中，没有任何人类接触过。发布文档中描述的人机协作（human-in-the-loop）实际上并不存在。

升级接口并没有失败。它的每一次跳转都得到了执行。失败的是“接收系统是自然人”这一假设。

就在你发布提示词（prompt）更改的同一周，所有评估类别的得分都提升了 6 个百分点。团队成员将其视为改动奏效的证明。三周后，有人注意到这种提升也出现在了提示词更改绝不可能触及的类别中——这是一个你专门用来检测此类情况的对照组——而且这种提升是均匀分布的，而真正的产品改进绝不会呈现出这种形态。评审模型在某个周二以相同的终端节点（endpoint）名称发布了。在你的系统变动之前，你的分数就已经变了。

这种失效模式对“大模型作为评审员”（LLM-as-a-judge）评估流水线的破坏，比文献中警告过的任何失效模式都要更隐蔽。不是偏见，不是位置效应，也不是自我偏好——这些是评审员在特定时间点的属性，你的评估设计可能已经考虑到了这些因素。真正让你栽跟头的是评审员在你没注意的时候发生了变化，而你的终端节点名称、评估代码和仪表板都在声称一切如常。测量单位在一个稳定的标签下发生了偏移。跨越迁移边界的每一次比较现在都被混淆了，你无法将差值分解为“我们的系统改进了”和“尺子的标准变宽松了”，因为你从未构建过能进行这种分解的工具。

你的综合评估分数在上个季度上升了两个百分点。没人能告诉你这究竟是系统变好了，是打分的人类群体变得更宽松了，还是你在三月份升级的评判模型开始以不同的权重衡量文本的冗长程度。数字变动了。但该数字旨在衡量的事物并不一定随之变动。

当一个评估准则同时被两个群体——人类和 LLM 评判者——阅读时，就会发生这种情况，而且这两个群体的漂移轴线和原因各不相同。综合分数将两者的运动混合在一起，除非你有一套测量方案能在其中一个变动时保持另一个固定，否则你发布的指标，其变化是无法归因于任何因素的。

我曾合作过的一个团队有一个评估集（eval set），它在不知不觉中演变成了一项针对其批量自动化任务的调查。采样定时任务（cron）在东部时间凌晨 3 点运行，从生产日志表中抓取了 5,000 条追踪记录（traces），并将它们放入评估语料库中。排行榜看起来很干净。新的提示词（prompt）赢了 4 分。他们发布了。不到一天，支持队列里就充满了他们在回归测试中从未见过的投诉——模型现在对定价问题闪烁其词，而这发生在一个工作时间完全在评估窗口关闭后才开始的客户群体中。

评估本身对于其测量的内容并没有错。错在于它测量的是谁。在东部时间凌晨 3 点，生产集群主要由深夜批量重试、定时报告生成以及少数主要询问导航类问题的亚太地区（APAC）日间会话占据。新的提示词在这个切片上的表现确实更好。然而，这个切片仅占每周流量的 12%，而在按收入加权的流量中占比为 0%。没有人问过“这个数据集中包含什么样的用户”这个问题，因为数据集是由一个在数据仓库最空闲时运行的定时任务构建的，而“空闲”是大家唯一想到的优化采样标准。

实验组之所以上线，是因为仪表盘显示“转化率 +4%，p < 0.01，n = 2.3M”。但在全球推行 6 周后，这一增长消失了。由于没有其他合理解释，团队将这次复盘报告归类为“规模效应”。然而，真正的原罪一直潜伏在提示词组装器（prompt assembler）中：决定实验分组的路由哈希（routing hash）派生自一个用户层级（user-tier）属性，而三行代码后，同样的属性被插值到了提示词模板中。模型直接在带内（in band）读取了分组分配。所谓的“实验干预”（treatment）并非提示词的改变，真正的干预是提示词改变后所吸引的用户群体。

这是一种在团队从 Web 时代继承的实验手册中并不存在的失效模式。按钮颜色不会读取用户层级并决定表现不同，但提示词会。一旦你的实验干预是一个由模型解释的字符串，那么任何触及路由决策且同时触及提示词的输入，都会变成实验无法关闭的后门。

预发布环境界面（staging UI）里的点踩（thumbs-down）按钮原本只有一个作用：告诉值班工程师哪个回复看起来很糟，以便他们去排查。六个月后，模型团队的某个人把“所有带有修正建议的生产反馈”拉取到一个 Parquet 文件中，并针对它运行了一个微调（SFT）任务。评估集在三个指标上有所提升，却在五个指标上悄悄退步。没人能解释原因，直到有人翻看标签并发现修正列中有一行写着：“这没问题，但我讨厌它的措辞方式。”模型习得了这种观点。然后，它又习得了另外四万个观点。

这种失效模式源于调试界面和标注界面是同一个界面。工程师点击“点踩”可能是因为某个环节坏了，或者看起来很奇怪，或者他们正准备提交一个工单，或者排版让他们不爽，甚至只是为了测试按钮是否好用。从那次点击中流出的信号混合了“这个输出是错误的”、“这个输出是对的但很难看”、“我不喜欢这个”以及“我当时很无聊”。作为单一标签，它什么也证明不了。以此进行训练，它教会模型的是所有这些情绪的并集。

你的 AI 功能成本预测是基于一个 50 人的试点项目建模的。那些用户输入了三句话的提示词，因为那是人们在被要求评估测试版时通常会输入的内容。产品上线了，你突破了一万名用户，财务团队指出你的模型账单是计划书中人均成本的三倍。你去寻找 Bug。但根本没有 Bug。你的试点项目是从一个分布中采样，而生产环境是从另一个分布中采样，两者的区别在于一个长尾用户群——他们是在 Twitter 上了解到你的产品，并粘贴了从推文中截取的 30 KB 非结构化上下文。

这是每家消费级互联网公司在 2010 年代都吸取过的同样财务教训，现在被移植到了 LLM 经济学中。试点项目的中位数用户并非生产环境中的 p99.5，而一个使用平均值作为预测输入的 Token 成本模型，在面对账单时注定会一败涂地。

一个优化单一损失函数的模型路由器会准确地交付该损失函数所要求的结果，除此之外别无他求。当该函数的目标是“保持在 p95 延迟目标之下”时，每一个本可以从深度推理（extended reasoning）中获益的查询都会被强行分配到路由器能辩护的最廉价路径上，因为快速模型能在 SLO 范围内返回，而缓慢但正确的模型则不能。延迟仪表板变绿了。综合评估指标（aggregate eval）仅波动了不到一个百分点，团队便将其视为噪声忽略不计。而没人绘图的分片视图（per-slice view）才是真正发生质量回归（regression）的地方：它集中在那些多步骤、模糊且分布外（out-of-distribution）的查询中，这些查询本应被路由到推理模型，结果却分配给了那些运行迅速但错误得很有底气的模型。

这不是路由 bug。路由器正在准确地执行其设计任务。Bug 出在框架设定上——如果一个系统的优化器完全以延迟为基准，它就会产生质量回归，而这些回归在团队为了 KPI 而维持“绿色”的指标中是不可见的。随后，它会默默地发布这些回归，因为盯仪表板的人并不是盯答案的人。

你的英文系统提示词（system prompt）花了六周的时间进行调优。一位资深工程师先后四次重写了约束列表，评估套件终于在留存任务集（held-out task set）上跑出了 94% 的通过率，发布检查清单也为生产环境亮了绿灯。随后，国际化（i18n）团队接手，将其放入处理按钮标签和工具提示的相同翻译流水线中，并在下个迭代周期交付了日语、德语、印地语和阿拉伯语版本。针对非英语市场的发布仪表盘显示了相同的任务量、相同的用户转化漏斗，而且——直到六个月后收到东京客户的一张工单——始终保持着代表正常的绿色状态。

东京客户投诉称，智能体忽略了英文提示词中明确禁止的一项指令。你重新阅读了日语提示词，发现从语义上看，两者的意思完全相同。你针对英文变体重新运行了英文评估套件，通过了。但日语变体没有评估套件。从来都没有。

检索日志很干净。针对你手动标注的查询集，Recall@10 在几个月内都没有出现退化。答案质量仪表盘显示忠实度（faithfulness）保持在 90% 以上。然后，一位客户向你的支持代理粘贴了一个问题，金标准文本（gold passage）就在组合提示词的 12 个位置中的第 7 位，而模型的回答却好像从未检索到它一样。

检索团队会告诉你该分块（chunk）确实在那里。提示词团队会告诉你提示词是正确的。两者在技术上都是对的。模型关注了前一千个标记（tokens），关注了最后一千个标记，却略过了答案所在的中间地带。你的流水线正面临着一种位置注意力偏置（positional attention bias），没有哪个团队对此负责，没有哪个仪表盘在追踪它，也没有哪个基准测试能捕捉到它。

模型卡（model card）是一件研究产物。而数据表（datasheet）是一份合同。采购团队通常会像阅读后者一样阅读前者，而交付它的 AI 厂商现在正受限于其工程团队原以为只是叙述性的声明。

这是丢掉续约最干脆利落的方式：你转发了发布在模型索引页上的同一个 PDF，客户的法务团队将其中四句话摘录到了附件 B（Schedule B）中，十二个月后你发现“预期用途：通用问答”已变成关于服务范围的合同陈述。你的团队用 BLEU 分值来衡量这些句子，而他们的团队现在正用违约代价来衡量。