861 篇博文 含有标签「insider」

你的 AI 功能成本是一个分布，而不是一个数字。挂在研发财务作战室墙上的仪表盘显示，上个月支出了 187,000 美元，并按功能、模型和区域进行了细分。然而，这些视图都无法回答 CFO 真正想问的问题：“谁每月付给我们 40 美元，却消耗了我们 4,000 美元的成本？”当你按 customer_id 而不是功能进行排序时，原本平稳的柱状图会变成一条曲棍球棒曲线，而那些针对平均用户进行设计的团队会发现，他们在一个季度里一直在默默地为长尾头部的用户提供补贴。

这种模式是如此一致，以至于完全可以被称为定律。在生产环境的 LLM 工作负载中，前 1% 的用户通常驱动了 30–50% 的 token 支出，而在排名前 0.1% 和 0.01% 的用户中也会出现类似的分布形状。这并非某个产品的特例 —— 当你发布一个边际成本可变且定价统一的功能时，这必然会发生。平均用户的利润率看起来不错，中位数用户的利润率看起来非常好。但重尾部分的积分才是季度预算的真正去向。

当一个多租户 SaaS 团队在其系统提示词（system prompt）中添加第三个 if tenant_industry == "healthcare" 分支时，那一刻他们其实已经在不经意间为自己聘请了一位编译器工程师。没有人申请过这个人头（headcount），也没有人事先规划过这项工作。团队以为自己在交付一个功能，实际上交付的是一套构建系统，而这套系统仅靠 f-strings 勉强维系。

任何试图将 AI 功能推广到具有哪怕轻微差异的客户群体的团队，最终都会撞上同一堵墙。租户 A 属于医疗行业，需要符合 HIPAA 标准的回答框架。租户 B 属于法律行业，需要严格的引用规范。租户 C 是购买了自定义安全准则的大型企业。租户 D 是免费层级用户，使用默认设置。最直觉的做法是用运行时条件语句（runtime conditionals）处理差异，这些条件不断嵌套，直到除了作者之外没人能读懂这个提示词。第二种直觉——也是大多数团队在撞墙后得出的方案——是提示词编译（prompt compilation）：规范的“提示词”不再是一个字符串，而是一个源码产物（source artifact），最终触达模型的则是编译后的输出。

大多数生产环境中的 AI 团队谈论提示词（prompt）的方式就像初级交易员谈论股票一样：总觉得存在一个“最好的”，而工作就是把它找出来。于是他们不断迭代——一个 Slack 线程，几行评估数据，产生一个新的赢家，推送到主分支，如此循环。其结果是一个承载了产品全部意图解析覆盖面的单一制品（artifact），针对一个固化的评估集进行了优化，而它距离 P1 级事故往往只差一次令人遗憾的修改。

错误在于“单一”这个词。提示词不是一种证券，而是一种配置（allocation）。同一个用户意图可以由几个变体很好地服务，每个变体都有自己的置信区间、各细分领域的性能以及对模型和语料库偏移的敏感度。正确的心理模型不是“找到最好的提示词”，而是“管理一篮子提示词，其构成本身就是产品”。量化金融在五十年前就弄明白了这一点，而其运营机制几乎可以直接无缝迁移。

一位资深工程师将 Prompt 的更改通过 10% 的灰度发布（canary）推送到生产环境。到了第二天早上，灰度组的有用性评分（helpfulness score）下降了四个点，值班人员发现了这一点，团队做了每个团队都会做的事情——撤回提交（revert commit）并重新部署。仪表板没有恢复。第二天也没有恢复。三天后，一份复盘报告显示，看到糟糕 Prompt 的那一组用户仍然在看到退化的输出，因为他们的对话历史中现在包含了由已撤回的 Prompt 生成的助手回复，而模型正基于这些回复进行预测。提交已经消失了，但损害仍在。

这是 LLMOps 中“像对待代码一样对待 Prompt”这一建议悄悄跳过的部分。代码回滚是文本替换，用于恢复确定性的过去状态。Prompt 回滚必须处理一系列副作用——缓存、历史记录、评估基准、实验分组、下游契约——这些都是糟糕的 Prompt 已经印刻在生产环境中的。git revert 翻转了文本，但它没有翻转后果。

一个自托管 LLM 团队将生产模型从 fp16 量化为 int4。内存占用降低了 4 倍，吞吐量几乎翻倍，GPU 账单大幅缩减，团队重新运行了曾用于 fp16 发布把关的同一套评估组件。MMLU-Pro 保留了基准测试的 98.1%。综合质量看起来不错。他们发布了。

六周后，一名支持工程师注意到数学辅导功能悄悄变差了。合规团队标记了在对抗性提示下违反政策的补全次数有所增加。结构化输出的重试率从 1.4% 攀升至 6.8%。这些都没有出现在评估仪表盘上，因为评估仪表盘是为了验证另一个模型而构建的——那个虽然共享相同权重文件，但每个激活值背后都有四倍比特位的模型。

这就是量化漂移（quantization slippage）。成本分析只计算了内存和延迟方面的收益，却没有计算这次替换在无形中要求的评估重新锚定。而针对 fp16 分布进行校准的评估套件，现在正用错误的准则对错误的模型进行评分。

价格页面上最便宜的那一行很少是发票上最便宜的一行。团队选择主力模型（Workhorse model）——Sonnet、Haiku、Flash、GPT-mini——是因为每 token 的计算方式很友好。上线功能后，看着成本控制面板报告了一个季度的单位经济效益（unit-economics）好消息。然后长尾效应跟了上来：主力模型处理不了一部分请求，开始重试，接着是部分回答，最后升级到人工审核，每个功能的损益表（P&L）不再像每次调用的仪表盘那样好看了。

这里的套利在于，针对这些困难请求，团队永远不会作为默认选项的推理模型（Reasoning model）——Opus、o3，这类缓慢昂贵的模型——通常在第一次尝试时就能给出答案。一次 0.50 美元的推理调用总成本，胜过五次 0.05 美元的主力模型调用加上升级队列，以及周一调试失败的工程师成本。采购问题（哪个模型每 token 最便宜？）和架构问题（哪个模型解决每个请求最便宜？）是不同的问题，将两者混为一谈的团队正在支付这两者之间的差价。

当 AI 功能表现异常时，大多数工程师做的第一件事就是再次点击“运行（run）”。这种思路认为，模型是具有随机性的，所以这次运行可能只是运气不好。当第二次尝试产生看起来合理的结果时，工单就被关闭了。团队继续前进。而真正的 Bug——过期的工具响应、检索缺失、仅在包含特定 token 的输入时才触发的系统提示词冲突——仍然完好无损地留在生产环境中，等待下一个用户触发它。

这就是“重跑反模式（rerun antipattern）”，它是 AI 团队从聊天机器人时代继承下来的最昂贵的调试习惯。它看起来很严谨，因为模型确实是非确定性的。它看起来像是一种方差探测。但几乎没有人在重新运行之前写下假设，没有人预先决定多少次运行才算证据，也没有人考虑 token 的成本。正在发生的事情更接近于“老虎机式调试”：你不断拉动杠杆，直到红灯停止闪烁，然后你走开，并确信机器没问题。

一个团队将自我批判循环（self-critique loop）投入生产，因为基准测试数据看起来令人无法拒绝：Self-Refine 报告称在七项任务中平均提升了 20% 的绝对性能，Chain-of-Verification 在问答任务中将幻觉减少了 50% 到 70%，而在一篇被广泛引用的论文中，反思提示词（reflection prompts）将数学方程的准确率提高了 34.7%。一个月后，财务审查揭示了账单。产品的单次请求成本大约增加了三倍，p99 延迟增加了三倍，而实际在生产流量中表现出的质量提升更接近 3% 而非 30%。自我批判循环确实做到了它宣传的效果，只是团队从未计算过它的代价。

这就是自我批判税：一种在 PPT 上看起来像是免费提升质量，但在发票上却表现为结构性成本增加的可靠性模式。模式本身是合理的——在某些实际情况下，“生成并验证”确实是正确答案。失败的原因在于将其作为默认配置而非经过校准的干预手段进行部署，并在季度的错误时间点发现“模型检查自己的工作”实际上是一项采购决策。

控制面板上的对话情况看起来很健康。每次调用的平均 token 数合理，p50 输入长度舒适地处于缓存前缀（cached prefix）之内，供应商的发票按照财务部门批准的速度增长。然后，有人导出了一个包含 200 轮对话的单次编程会话，该用户的单项支出就超过了团队其余成员每日流量的总和。控制面板没有撒谎 —— 它只是在算平均值。账单来自于长尾（long tail），而长尾并不会随着轮次增加而线性增长。

每一个多轮对话的 AI 功能最终都会遇到这种“惊喜”。每次调用的 token 数是一个错误的衡量单位，因为 30 轮对话的成本不是单次调用的 30 倍 —— 而是 50 倍到 200 倍之间，这取决于历史记录的结构方式、提示词缓存（prompt cache）的衰减情况，以及一旦输入超过 200K token 后请求所处的计费层级。根据单次调用数据为功能定价的团队，实际上是在为他们从未建模过的长尾风险承保。

六个月的绿色 CI 掩盖了一个事实：大约 40% 的评估集（eval set）已不再代表用户在产品中的实际行为。测试套件仍在运行，裁判（judge）仍在打分，仪表盘依然闪烁着绿光。但这些案例是针对查询分布、语料库、工具界面和监管文本编写的，而这些内容早已发生了变化——现在的绿色运行意味着“昨天的产品在昨天的现实中依然有效”，而这并不是你付费让 CI 回答的问题。

这就是“快照评估退化”（snapshot eval decay），它是 AI 评估中最缓慢、最昂贵的失败模式。说它缓慢，是因为套件从未失败——陈旧性表现为无法区分模型优劣，而不是构建变红。说它昂贵，是因为当有人意识到评估通过的模型切换导致了生产环境回归时，团队已经建立了一年之久的“评估通过即发布”的肌肉记忆，而这一记忆是建立在一个早已悄然失效的资产之上的。

打开一个日益成熟的 AI 产品的生产环境系统提示词（system prompt），向下滑过角色描述，你几乎总能看到一个标有 # Examples 或 ## Few-shot demonstrations 的部分。这些示例非常出色——它们很具体，具有领域针对性，且精准地匹配了上季度评估集（eval set）中表现不佳的失败模式。但在仔细观察后，你发现它们其实也是真实的客户数据。来自真实账户的真实工单 ID。从支持会话中原封不动摘录的措辞模式。某个租户使用的内部产品代码，而其他客户群从未听说过。

把这些示例放进去的团队并不是粗心大意。这些示例进入提示词的方式与好示例一贯进入提示词的方式相同：有人从生产环境的追踪（traces）中挖掘出模型处理不佳的案例，挑选出最干净的现成示例，将其粘贴到系统消息中，看着评估分数上升，然后发布。这条从生产环境追踪到系统提示词的流水线，是现代 LLM 工程中最可靠的提示词改进闭环。但这也是团队在不知不觉中构建的一个结构性跨租户数据泄露渠道，而系统提示词已悄然变成了一个数据处理协议（DPA）从未涵盖的多租户数据存储库。

你的可观测性技术栈中的单工具仪表盘讲了一个令人宽慰的谎言。search_listings 的成功率是 96%，显示为绿色。book_appointment 是 95%，也是绿色。而连续调用这两个工具的智能体（agent）三周以来的成功率一直只有 78%，却没人能解释原因。原因不在任何一个工具内部，而是在它们之间的缝隙里——那个没有任何仪表盘面板覆盖的地方。

组合不是加法。当工具 A 的输出流入工具 B 的输入时，故障面并不是 B 对“有效调用”的狭隘定义下的 1 - (0.96 × 0.95)。它是 A 在 B 的标准下所有微妙偏差方式的完整笛卡尔积：A 返回的日期格式是 MM/DD/YYYY，而 B 期望的是 ISO 8601；返回的价格单位是分，而 B 解析的是元；分页游标指向了最后一个结果之后的一项；或者上游服务昨天重命名了一个实体 ID。这些情况都能顺利通过 A 自身的契约测试（contract tests），但每一个都会导致 B 崩溃。团队的单工具可靠性指标永远看不到这一点，因为按各自的标准来看，每个工具都运行良好。