861 篇博文 含有标签「insider」

针对付费用户群追踪数据进行模型优化的团队，其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品，是因为产品中的某些特质证明了刷信用卡付费的合理性，这意味着当他们进入评估集（eval set）时，已经学会了哪些提示词（prompts）有效，哪些功能给力，以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的，通常带有对抗性，且往往是非英语母语者，正在用第二语言对产品进行压力测试，他们触发了评估集从未涵盖的长尾失败模式。

这种不对称性正悄无声息地吞噬着每一个免费增值（freemium）AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注，从未进行回归测试，也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好，但在决定免费用户是否升级的分布上却慢慢变差。

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。

你智能体系统提示词中的工具描述是一个六个月前的评估产物（eval artifact）。它说 search_pricing 返回“带有结构化定价的最新库存数据”，规划器（planner）对此深信不疑，因为自描述调优的那天起，提示词中的任何内容都没有更新过。而实际上，在过去的 40 分钟里，search_pricing 端点的 p95 延迟一直保持在 11 秒，因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具，只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing，因为描述读起来仍和评估时一样，且规划器没有任何关于目前调用这两个工具成本的信号。

这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题，而等待成本正是你的提示词模板所看不见的东西。

六周前，你将 get_user_email 重命名为 lookup_contact。新名称已发布，旧的处理程序已移除，变更日志记录了这一点，你的评估集也通过了。然而上周二，一位客户支持工程师联系了你：智能体在上周的大约 3% 的工具调用中返回了错误——tool_not_found: get_user_email。那个已被重命名的名称。那个在实时系统中已经不再对外公开的名称。

先验知识（Prior）具有粘性。你的智能体正在与之对话的模型是在一个语料库上训练的，在这个语料库中，get_user_email 是询问“这个人的电子邮件是什么”的绝大多数规范方式。即使你在推理时传递的 tools 数组中仅列出了 lookup_contact，模型偶尔——在特定的上下文条件下，特别是长追踪（long traces）或错误恢复状态下——仍会退回到它记忆中的名称。直接切换并不能消除长尾效应；它只是将软故障变成了硬故障。

每次模型升级都会被当作一种简单的“替换”推销给团队：一行配置更改、在延迟、成本或质量上可衡量的提升，以及几天用于吸收新模型怪癖的提示词微调。采购方案展示了每 token 的差值，工程工单列出了发布阶段，FP&A 团队预记了季度节省。接着，评估分值出炉，却没人认得出来。质量在理应提升的地方毫无波动。曾经达成一致的两个评分员现在分歧达 10 分之多。快照套件显示为红色，但差异看起来只是措辞调整。站会上有人提出了那个本应从迁移计划第一天就该出现的问题：模型到底是在针对什么评分？

这是第二张账单 —— 评估重锚税 (eval re-anchoring tax) —— 且它往往比第一张更昂贵。人工标注的参考分数锚定在旧模型的输出分布上。作为评委的 LLM 评分器针对旧模型的失败模式进行了校准。快照固定装置捕捉的是旧模型的措辞。团队对“优质输出”的直觉是基于旧模型的风格特征训练出来的。在模型替换中，这些都无法完好无损地保留下来。

我上个月交流过的一位 AI 初创公司 CTO 打开她的笔记本电脑，给我看了一个数字：47。那是目前在生产环境中运行的独立系统提示词（System Prompt）的数量，每个企业客户或每个逻辑分组各占一个。基础提示词在第四个月为一家需要更温和拒绝态度的医疗客户派生（Fork）了一次。然后为一家需要引用的法律客户又派生了一次。接着是为一家金融服务客户派生的，因为他们的合规团队有一份违禁词清单。当时，这些看起来都不是什么大事。每一个都是独立批准的小需求，让大客户经理团队能够顺利签下订单。

两年后，模型提供商宣布了她那些针对旧版本调优的提示词的切换截止日期。她的工程团队直觉反应是对新模型运行评估套件（Eval Suite）。评估套件仅针对基础提示词。基础提示词仍在为 0 号客户提供服务，该客户没有任何覆盖配置，且约占收入的 9%。

一位产品经理在 Slack 上私聊你，询问当客户要求助手取消订阅时会发生什么。你开始凭记忆输入答案，然后又自我怀疑，于是打开系统提示词读了 30 秒。你粘贴回一份摘要。他们向你道谢后继续忙别的了。三小时后，支持团队问了同样的问题。到了周四，合作伙伴负责人把提示词的截图贴进了交易审查中。

这就是“提示词即文档”（prompt-as-documentation）反模式。当你第一次意识到这种情况发生时，感觉会很棒。你花了六个星期调优的制品，现在成了产品功能的权威真理来源。产品经理在读它，支持团队在读它，销售团队在读它，甚至某个角落的设计师也在读它。你的工作成了支柱，这在以前的服务层代码中从未有过。你可以通过计算有多少不相干的人能凭记忆调出这个文件来证明这一点。

一位资深工程师向 planner 提示词（prompt）提交了一个只有四个单词的修改——“if uncertain, ask first”（如果不确定，先询问）。Planner 自身的评估集（用于评分计划是否合理）提升了 0.5 分。他们合并了代码。两周后，verifier 的评估显示通过率出现了 3 个百分点的回归，且没人能复现。根本原因在于：planner 现在会提出更多澄清性问题，executor 在第二轮收到的任务描述变短了，而 verifier 的评分准则（rubric）是针对之前 executor 较长的输出进行隐式调优的。一个没人标记为高风险的修改，一次性改变了下游的三个分布。

当你把智能体（agent）内部的提示词看作一个扁平的文件文件夹，而不是一个带有“边”（edges）的图（graph）时，就会发生这种情况。提示词有负责人，但它们之间的“边”却无人看管。

弃用通知邮件在一个周二的下午寄达。你的计费流水线赖以生存了 14 个月的模型现在进入了 60 天的倒计时。提示词是由一名在 3 月离职的工程师调优的。评估套件自发布以来从未重新设定基准。客户成功团队正在询问为什么两个企业账户的“AI 感觉不一样了”。没有人把这件事列入路线图，也没有人能清爽地接手，因为在你组织的心理模型中，这是一个一次性项目 —— 尽管这已经是今年的第四次了。

每个在生产环境中运行 AI 功能的团队在 18 个月内都会得出同样的感悟：基础模型提供商正以团队未曾预料的频率弃用模型，而团队的迁移应对措施始终是由于收到通知邮件而触发的被动仓促应对。解决方法不是为下一次迁移准备一个更好的操作手册 —— 这类手册已经很多了，你的团队可能也写过一个。解决方法是停止将迁移视为一个项目，而是将其视为一个经常性的运营原语。把它排进日历。

团队像规划服务一样规划评估集（eval suite）：梳理失败模式、起草评分标准（rubric）、争论样本量大小、安排评判员校准（judge calibration）时间表。然后，他们把评测员产能（rater capacity）当作脚注——“我们会让标注团队每周评测几百条”——然后就发布了剩下的部分。六周后，评测员队列堆积了 4,300 个条目，评估速度坍缩到每月仅一次评判员校准周期，在一次规划评审会上，有人道破了那个大家都心照不宣的事实：没有人对人力进行过产能规划。

在任何严肃对待人工评分的 AI 系统中，评测员吞吐量都是评估速度的约束性瓶颈。将标注视为 SRE 问题而非招聘问题的准则，才是产品发布的关键。一名人类评审员在专家难度下每小时处理 50–100 个样本，而一名专家标注员每周的上限约为 500–1,000 个样本——这些数字不是通过增加人头就能蛮力解决的招聘问题。它们是评估系统的运行属性，必须像建模数据库 IOPS 一样对其进行建模和预算编制。

用户打开你的聊天窗口，提了一个问题，得到一个评估套件打分为 4.6（满分 5 分）的回答。接着，他们换了一种说法问了同样的问题。同样的回答，同样的分数。他们又试了一次，这次用了人们在怀疑机器没在听时常用的套话——“我实际上想做的是……”——然后他们关闭了标签页。从模型的视角来看，这是三个干净的问答轮次。从仪表盘的视角来看，这是一个活跃的会话。但从用户的视角来看，这是一个连续三次失败的产品，而且以后再也不会打开了。

这就是“单轮评估”（per-turn evaluation）无法察觉的失效模式。孤立来看，每一轮对话似乎都是正确的。裁判（Judge）给了赞。幻觉检测器保持沉默。相关性评分很高。然而，整个对话作为整体并没有解决任何问题——而这正是用户真正评估你的单位。

我最近交流过的一个团队向一家财富 500 强公司的内部法务办公室出售了他们的法律 AI 产品，并在系统提示词中增加了一行：“每一个事实性陈述必须包含对检索源的内联引用。”产品路线图为这种新行为分配了 5% 的 Token 预算缓冲。在该受监管租户上线 60 天后，财务部门标记了每月推理支出激增了 34%。没有人搞坏产品。没有人发布新功能。这项促成交易的合规要求，也悄然改写了其背后的单位经济效益。

这就是检索引用税，几乎每个服务于受监管行业——法律、医疗、金融、有审计约束的企业——的 RAG 系统最终都要支付这笔费用。这笔税收是结构性的，而不是 Bug。它源于引用纪律迫使模型进入了一种不同的生成模式，而且它在客户签署的采购规范中无处可寻。