907 篇博文 含有标签「insider」

你的应用程序使用与你认为的提供商所使用的相匹配的分词器（tokenizer）库在本地计算 token 数量。SDK 在每次调用前报告“预计 4,200 个 token”。你的预算逻辑通过了该请求。然而，提供商的账单显示相同的负载为 6,800 个 token。将这 60% 的差距乘以每月数百万次的调用，财务团队无法根据你的日志核对的这一项开支，看起来就不再是四舍五入的误差，而是一个架构错误。

错误并不在于本地分词器是错的。错误在于将本地分词器视为一种契约，而不是一种猜测。Token 化（Tokenization）是提供商在其服务栈内部完成的事情——你的库只是该过程的一个模型，而非过程本身，而且两者会产生偏差：这种偏差在每次调用中虽然微小，但在你实际进行的总体调用量中却具有结构性。

发布说明只有两行。“改进了多语言分词（Tokenization）。模型输出无破坏性变更。”一共不到二十个字。你的评估（Evals）确认了这一点：相同的提示词，相同的生成内容，相同的评分。你的平台团队在周五下午批准了升级。到了周二早上，你的缓存命中率从 80% 下降到 4%，每日推理费用翻了两番，而凌晨 6 点把你叫醒的轮值工程师在你的代码里找不到任何一行改动。

你的代码确实没有任何改动。但服务商发布了一个新的分词器，它对某个 Unicode 字符的一个字节划分与旧版本不同。你系统中每个缓存的前缀现在都是基于一个已不再存在的 Token 序列生成的指纹。模型的表现完全一致 —— 这确实是事实。但发布说明中未曾提及的缓存层，却为此付出了全额代价。

一名后端工程师将参数从 user_id 重命名为 account_id，因为两者在半年前就不再是同一个东西了，而且一个支持工单终于让这种歧义变得无法忍受。JSON schema 在发布重命名的 pull request 中得到了更新。该工具的文本描述——即模型实际阅读以决定是否调用该工具以及如何调用的那个段落——却存在于另一个代码库中，由另一个团队负责，通过工单队列更新，并且仍然写着“传递 user_id 以查找账户”。没有人标记出这一点。模型尽职尽责地使用正确的 schema 调用工具，填充正确的字段，并在每一个快乐路径（happy-path）查询中获得正确答案。这个 bug 是隐形的，直到有一天用户输入的内容中，他们经过身份验证的 user_id 与他们询问的 account_id 是两个不同的实体，而智能体自信地返回了别人的数据。

一名用户反馈 Agent 回答正确，但数据库从未更新。你打开可观测性工具，搜索用户端对话中标记的 trace ID，发现了一个清晰的树状结构——五次 LLM 调用，四次工具决策，一个最终回答。没有任何错误。接着你搜索负责数据库写入的工具服务，发现了另一个 trace，虽然墙钟时间窗口相同，但 trace ID 不同，根 span 不同，且没有关联回溯。你搜索网关日志。又发现了三个孤立追踪（orphan traces）。在聊天 UI 中看起来像是单次连贯交互的 Agent 运行，在你的追踪后端却分裂成了一片森林。

本应将这一切串联起来的请求头是 traceparent。它是一个 55 字节的 W3C 标准字符串，分布式系统中的每个 span 都用它来识别其父节点。然而，在大多数生产环境的 LLM Agent 技术栈中，它在用户请求与用户真正想要的副作用（side effect）之间，至少会被丢弃一次。

语音智能体有一个门控机制。转录置信度高于 0.85 的任何内容都会直接进入规划步骤；低于该值的内容则会被路由给人工。该阈值是六个月前针对标记的真实客户通话语料库进行调优的，随后被固定在配置文件中并被遗忘。在六个月的时间里，它确实履行了职责。然后，转录服务提供商发布了模型升级——同样的 API、同样的响应形式、同样的延迟范围、同样记录在案的准确率——但在接下来的两周里，该智能体开始向错误的人授权电汇。

“给妈妈转账 50 美元”变成了“给 Tom 转账 5,000 美元”。新的转录结果返回的置信度为 0.91，远高于门控阈值。下游规划器看到了一个置信度很高的转录结果并据此执行。客户的申诉最终暴露了这个 Bug，但到那时，支持队列已经将一周内类似的事件作为欺诈纠纷过滤掉了。复盘分析将差距追溯到团队从未明确做出的一个决定：旧模型的 0.85 和新模型的 0.85 是同一个数字。

你的聊天产品已经在 1.5 秒的 p99 延迟 SLO 下平静地运行了数月。请求率平稳，prompt 大小平稳，模型也未曾改变。接着，在某个周二下午，p99 突然飙升至 4.8 秒并保持在那里。值班排查发现聊天路径（chat path）没有任何异常：同样的每分钟请求数，同样的中位 prompt 长度（约 800 token），SDK 的重试行为也完全一致。聊天服务当天的部署日志为空。故障持续了六个小时。

原因出在另一个团队的代码库中。那天早上，一个长文本摘要功能上线了，使用的是同一个组织密钥（organization key），其平均 prompt 为 12,000 token。他们的请求率并不高 —— 每分钟仅几百次 —— 但每次调用消耗共享的每分钟 token（TPM）预算的速度比你的快 15 倍。供应商的限流在聊天路径上触发了，因为聊天路径与摘要团队共用同一个刚刚被掏空的“桶”。没人动过你的代码，没人超出计划的容量，而你的 SLO 现在却成了你的团队从未读过的工作负载的函数。

交付 “面向欧盟客户的 AI” 的团队通常只交付一种驻留控制：锁定在欧盟地区的推理端点。采购团队拿到 DPA，架构图在 “模型托管在法兰克福” 旁边打上绿色对勾，接着发布。架构图中没显示的是：客户的原始查询在前往模型的途中被美国托管的嵌入 API 向量化；查询与之匹配的向量存储的运维平面位于 us-east-1；重排序模型是部署在供应商自选地区的第三方 SaaS；提示词缓存在命中的情况下是按地区键入的，而在未命中的情况下则是全局的；记录检索块的追踪存储有一个 30 天的保留期存储桶，并为了冗余进行跨区域复制。

推理层遵守了驻留规定。而检索流水线甚至不知道自己也是参与者。

这就是大多数 “符合 GDPR” 的 RAG 部署在面临团队甚至没意识到会到来的审计时失败的缺口。修复方案不是针对模型调用增加另一个控制 —— 而是意识到数据驻留是客户字节所接触的每个组件的属性，并且拥有 “LLM” 的团队最多只拥有涉及到的六个表面中的一个。

故障始于 14:03，服务商返回了 429 错误，并带有一个 JSON 响应体，内容为 {"status": "ok", "data": null}。这个客户端库是六个月前由一个被坑过两次的人匆忙写成的——一次是因为网关返回了带有 error 字段的 HTTP 200，另一次是因为服务商在请求实际成功时返回了 HTTP 500。所以，这个库学会了信任响应体，而不是状态码。状态码要求限流，响应体却说继续。客户端相信了响应体，发出了下一个请求，又得到了一个带有 ok 的 429，再次发送，到 14:11 时，服务商的熔断器已将该账户在该小时的剩余时间内列入了黑名单。

服务商并没有完全撒谎。429 是真实的。但在响应流水线的某个环节，一个默认的封装层覆盖了限流负载——这是一个来自包装服务的通用 {"status": "ok"}，用于填充缺失字段，并应用在了一个该包装服务无法识别的错误之上。状态码是正确的，请求头是正确的，响应体是错误的，而响应体正是客户端读取的部分。

我曾合作过的一个团队发布了一次 prompt 变更，将输出 token 减少了 22%。实验仪表盘上一片绿意——方差极小，p 值非常清晰，外推后的成本节省每年高达六位数。两周后，一位研究转化漏斗的产品分析师指出，在同一时间段内，下游任务完成率下降了 11%。较短的输出省略了一个澄清步骤，而用户一直默默依赖该步骤来了解下一步该点击哪里。

实验平台没有撒谎。它报告的正是团队配置的核心指标，而且该指标确实朝着正确的方向移动了。问题在于，该指标衡量的是团队实际上并不关心的东西。Token 统计成本低，实验基础设施对其有现成的集成，而衡量结果却很难——因此团队选择了平台提供的便捷方案。结果是仪表盘上的完胜，却是产品层面的退化。

在部署后的一个季度，AI 团队报告单次 API 调用平均成本降低了 25%。支持团队报告 AI 分流工单的平均处理时间从 4 轮增加到了 7 轮。这两个数字都是正确的。两个团队都在测量他们被要求优化的系统。夹在中间的财务团队无法核对仪表盘，因为这两个指标都不是以客户实际支付的东西来衡量的：一个已解决的工单。单次调用成本下降了，而单次任务解决成本上升了 40%。由于没有团队负责这个指标，所以没人注意到它的变动。

这是我在智能体（agentic）部署中见到的最常见的单位经济效益（unit-economics）失败，而且这不是一个测量上的 Bug，而是一个定义上的 Bug。供应商的价格页面展示了单次调用成本，因为这是他们计费的单位。由于电子表格的单元格刚好放得下，这个单位就被继承到了表格中。工程团队针对给定的单位进行优化。等到 API 经济与业务经济之间的鸿沟变得清晰可见时，这种影响已经累积了一个季度，而智能体整个时间都在基于错误的损失函数（loss function）被悄悄训练。

客户将智能体的回答粘贴到支持聊天中，并要求人工代表进行确认。代表看着同一款产品，却给出了相反的说法。那天，客户并没有对智能体失去信心。他们是对公司失去了信心，因为公司的两个部门在同一个小时内告诉了他们两件截然不同的事情。

一切都没有出错。AI 团队在周二通过特性标志（feature flag）发布了一个提示词更改，到周四已推行至 100%，然后便继续下一项工作了。客户成功（CS）团队的赋能周期是按月进行的 —— 以前每个产品特性都是这样落地的，而且没人针对 AI 重新协商这一流程。CS 代表队列中的宏（macro）和公共网站上的 FAQ 文档描述的仍然是之前的行为。智能体是对的。代表根据他们掌握的文档也是对的。但公司表现得各说各话。

事后分析报告（post-mortem）会说“我们发现安全问题太晚了”。但实际的调查结果应该是：安全团队发现你的时间很准时，是你的流程发现安全问题太晚了。

这是一个在 1 月份就通过了预算审批的 AI 功能，因为 CTO 和 CFO 都认为公司需要一个“AI 高光时刻”。3 月份它通过了初步的法务审查，因为当时还只是一个原型。整个第二季度，工程团队都按照商定的规范进行开发。7 月底，发布前的安全审查启动了，结果第一天威胁模型（threat model）就反馈了阻碍性问题：身份验证范围（auth scopes）、数据泄露路径、模型供应商的数据驻留（residency）政策，以及提示词注入（prompt-injection）的攻击面。团队整个季度的时间现在都花在了重新架构上，以解决那些本该在最初规范中就被明确的问题。两个季度的进度延迟，一份关于“流程改进”的高管备忘录，以及在下一个规划周期中悄然决定“降低 AI 深度集成的优先级”。

发布失败并不是因为安全团队动作慢，而是因为安全团队在功能形态已经固化之后才介入。