907 篇博文 含有标签「insider」

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

当一个评估准则同时被两个群体——人类和 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 分值来衡量这些句子，而他们的团队现在正用违约代价来衡量。

邮件是在周二发出的。你那两个最重要的功能所依赖的 Checkpoint 进入了 90 天的下线期。你的工程团队正处于为了另一个发布而进行的协同代码冻结（Freeze）的第二周。等到冻结解除时，你将只有不到三十天的时间来针对新模型重新验证两个生产环境的功能——这里的“重新验证”意味着重建评估集、运行影子流量、获得产品负责人签字，并在一个没人关注的 Feature Flag 之后发布，因为发布团队还在忙着处理代码冻结原本针对的那个项目。

这种冲突并不少见。主要供应商发布废弃周期的频率是以月为单位的，每个在托管模型上运行的团队现在都经历过至少一个周期。团队尚未吸收的教训是，供应商的废弃并不是像库升级那样的工程事件——它是一个运行在你无法控制的时钟上的排程事件，任何没有预留预算的路线图都会将这笔成本视为一场意外。

用户在你的智能体授权页面上点击一次“授权”。当会话结束时，该智能体已经链式调用了 11 个工具，协商了 3 次提权授权，现在拥有了它所触及的每个工具的权限并集。用户只记得授权了一件事。你的审计日志却显示它拥有半个账户的读写权限。OAuth 标准说一切都在按设计运行，而这恰恰就是问题所在。

经典的 OAuth 授权模型是为“一个应用与一个 API 通信”的世界构建的。智能体在两年前打破了这一假设，而标准在实践中尚未跟上，即使规范已经更新。其结果是一类无人刻意发布的静默权限提升——它随着每一次工具注册而累积，而你的安全审查却一直在盯着前门。

AI 平台团队有四名工程师。他们七个月前发布的内部 Agent 现在每天为 200 名员工回答问题。在第一个月，创始工程师亲自处理了每一个 Slack 消息——周二晚上 11 点，周日上午，甚至公司团建的晚上。随后，她因推动采用率方面的贡献而晋升为资深工程师（Staff Engineer），三周后，她在下午 6 点后就不再查看频道了，因为那是资深工程师该做的。原本打算取代她的值班轮换（on-call rotation）从未正式化，因为运营模式总是打算在“试点之后”再解决。

当 Agent 针对四分之一的用户静默降级的那天——一个悄然落后的检索索引，或者改变了拒绝行为的模型版本切换，或者是架构轮换后现在返回空数组的工具——投诉并不会降临到平台团队的传呼机（pager）上。它们落在帮助台队列中，由那些无法访问 Agent 追踪（traces）、不知道什么是系统提示词（system prompt）、并且被 IT 部门告知该 Agent “由 AI 团队负责”的人员处理。从第一个用户投诉到第一位工程师查看 trace，中间过去了 16 个小时。平台团队没有人玩忽职守；只是根本就没有人在执勤。