578 篇博文 含有标签「insider」

一位拥有 8 年事故响应经验的平台工程师打开了一条凌晨 2 点的报警信息：“AI 助手性能下降 —— 错误率 12%”。她检查了模型延迟仪表盘：绿色。检查了模型 API 状态页：绿色。检查了部署日志：过去 72 小时内没有任何变更。她做了任何称职的值班人员接下来会做的事 —— 呼叫 AI 团队。AI 工程师醒来，打开了平台工程师甚至不知道存在的追踪 (trace) 仪表盘，发现一个检索工具在过去 4 小时内一直超时，原因是一个下游搜索索引丢失了一个副本，并在 11 分钟内解决了事故。AI 工程师在凌晨 3:14 重新入睡。第二天早上的复盘记录写道：“AI 功能故障，由 AI 团队解决”。没有人写下真正的教训：如果这位值班工程师曾被教导过 AI 功能的故障面 (failure surface) 长什么样，她本可以在 5 分钟内完成分流 (triage)。

这是 AI 功能在过去两年中，向我合作过的每一个工程团队悄悄征收的“轮换税”。曾经完美适用于无状态服务堆栈和几个数据库的共享值班轮换，在其中一个“服务”变成由 LLM 驱动的功能时就会崩溃。你的 SRE 团队通过十年的事故复盘建立的值班手册，是为一个“某处出错了”可以分解为 CPU、内存、网络、部署和依赖超时的世界而校准的。AI 功能增加了三个维度 —— 模型、提示词 (prompt)、检索管道 —— 以及四种值班人员从未接受过识别培训的故障形态，这些故障不会出现在他们习惯查看的仪表盘上。

上一季度发布的端侧 AI 演示在单台测试手机上运行了一个 4-bit Llama 变体，表现出色。六个月后，同样的功能却收到了一连串的一星差评，用户抱怨发热、耗电，或者更糟糕的是——无声的质量下降，用户只觉得“老手机上的 AI 变傻了”。模型没变，但机群（fleet）变了。那些原本以为是在交付模型的团队后来才发现，他们交付的其实是一个机群。

这就是导致大多数端侧 AI 发布失败的鸿沟：策略是围着选择“那个”模型转，而真正的难点在于如何为每类设备交付“合适的模型”，观察其运行情况，并在出问题时回滚。弥合这一鸿沟的学科更像是 CDN 运营，而非 ML 研究——清单驱动（manifest-driven）的交付、按分群的遥测、解耦的发布渠道，以及能从一个训练好的检查点生成 N 个量化分级的模型变体流水线。大多数团队并不具备这些，他们只有一个模型卡（model card）和一个构建产物。

一个新的嵌入模型发布了。基准测试数据提升了 4 %。一位 Staff 工程师提交了一个工单：“将 embedding 升级到 v3。”两周后，索引已完成重新嵌入，别名已切换，团队通过特性标志（feature flag）发布了变更。六周后，支持工单堆积如山。搜索结果“感觉不对劲”。复盘会召开了。没人能解释为什么出现了退化，因为没有系统崩溃，每个仪表盘显示的都是绿色。

问题不在于模型的更换。问题在于向量存储根本不知道哪些向量来自哪个模型。数据库里没有这一列。没有用于追踪哪些记录已回填的迁移表。没有 alembic_version 行，没有 schema_migrations 表，也没有先前状态的 pg_dump。团队将 embedding 升级视为一次简单的配置切换，而向量存储在模式（schema）层面缺乏能阻止他们犯错的概念。

Embedding 迁移需要数据库迁移二十年来一直依赖的相同产物：写入每个向量、在每次查询时检索、并作为切换和回滚准入准则的单条记录版本标签。这是大多数团队最容易忘记添加的一列，而后期补救的成本远高于前期添加。

系统提示词（system prompt）上一个四个词的修改——用 "respond using clean JSON"（使用干净的 JSON 响应）替换 "output strictly valid JSON"（输出严格有效的 JSON）——在评估（eval）中一度没有引起任何波动。它在周四发布，却在周五凌晨 4 点被回滚，因为结构化输出的错误率从 0.3% 飙升到了 11%。提示词并没有变糟。它只是变得“不同”了，而下游解析器在无人察觉的情况下，已经固化（pinned）在了 "strictly valid" 这个词组上。

这是大多数提示词工程（prompt-engineering）团队尚未建立工具来应对的失效模式：提示词被视为作者拥有的文本，而实际上它是与作者从未见过的消费者之间的一份合约。这些消费者中，有些是逐字引用原句的其他提示词；有些是 JSON 模式（JSON schema）字段锚定在特定形容词上的工具描述；有些是其评分标准（rubrics）要求裁判（judge）检查“严格有效格式”的评估（evals）；还有一些是解析器——最脆弱的一类——其正则表达式是根据模型输出的精确前导语（preamble）进行校准的。

一次“小小的措辞清理”会悄无声息地破坏解析器、导致裁判校准偏移，并使数周的评估运行失效。这些失败都不会在 PR（拉取请求）中显示出来，而是在一周后作为“偏移”（drift）出现在仪表盘上。

隐私审计员在 SOC 2 续期前两天提出了一个问题：“为什么你入门引导提示词示例中的电子邮件字段是一个真实客户的地址？”产品团队在脑海中回溯了整个流程。一年前，当他们发布 AI 摘要功能时，有人需要为 few-shot 模板找一个“看看它是如何工作的”示例。他们从预发布环境（staging）中选取了一条具有代表性的客户记录，清理了明显的字段——姓名、账户 ID、电话——并提交了文件。该客户在六个月后流失了。根据数据保留政策，他们的记录已从数据库中删除。但该记录并没有从提示词模板中删除，而该模板已发布到了生产环境中的每一个租户。

团队曾像大多数团队一样，认为隐私边界就是数据库。提示词模板是代码。代码要经过评审。评审并不会标记 PII（个人身份信息），因为评审人员不会在标记为 example_input: 的 YAML 字符串中寻找它。能在 Slack 消息和邮件附件中捕捉 PII 的 DLP（数据泄露防护）扫描器不会扫描提交的代码，即使扫描，它也不会将部分清理过的客户记录识别为个人数据，因为它知道要查找的字段已被移除。剩下的所有内容——公司规模、行业、稀有的职位名称、特定的城市——都是扫描器没有规则去处理的数据。

评估套件在凌晨 2 点运行。流量很低。缓存是冷的，但队列是空的。供应商的连续批处理程序有空闲插槽，并将以接近其 TTFT（首 Token 延迟）底线的水平处理每个请求。延迟分布很紧凑，评测模型分数稳定，仪表盘显示一片绿色。团队发布上线。

六个小时后，太平洋时间上午 8 点，同样的 Prompt 在美国早高峰期间进入生产环境。p95 延迟是评估报告的 2.4 倍。相当一部分请求从一个供应商那里收到了 529 错误，并回退到另一个供应商的较小路由层级。流式传输的节奏更加断断续续。评测模型（当天晚上对生产环境追踪样本进行重新运行）给出的中位数得分比凌晨 2 点给出的相同 Prompt 的得分低了半分。代码库没有变化。Prompt 没有变化。只是挂钟时间变了。

必须意识到的架构真相是：LLM 调用不是其输入 Token 的纯函数。它是一个随机分布式系统调用，其输入包括挂钟时间、供应商集群的负载、Prompt 缓存的状态、当前解码批次的大小，以及供应商负载均衡器在你的请求到达的那一毫秒所做出的路由决策。在凌晨 2 点运行评估的团队，是在一种用户永远无法体验到的条件下校准仪器。

打开你的结构化输出仪表盘。它自豪地显示着类似 “98.4% 的 Schema 合规率” 这样的数字。这就是成功率——即第一次尝试就生成有效 JSON 对象的请求比例。团队为剩下的 1.6% 构建了一个重试封装器（retry wrapper），发布上线，然后就没再管了。两个季度后，推理费用增长了 15%，而请求量仅增长了 4%。首席财务官（CFO）想要个解释。工程师们给不出解释，因为跟踪结构化输出成功率的仪表盘并不跟踪结构化输出的成本。

仪表盘隐藏的部分在于：失败路径并非只有一次重试。第一次重新提示（re-prompt）修复了缺失的 enum 字段，但引入了一个格式错误的嵌套数组。第二次重新提示修复了数组，但丢掉了一个必填键。第三次尝试终于通过了验证，但到那时，该请求已经消耗了四次完整的推理调用加上最初的生成过程，而你的单次请求 Token 计数器显示的是 总和，而不是循环过程。从计数器的角度来看，这是一个昂贵的请求。从成本线的角度来看，这是一个你从未定价的随机循环。

这篇文章将探讨该循环究竟对你的算力预算产生了什么影响，为什么你现有的观测能力（observability）无法察觉到它，以及哪些规范可以使其变得可见且可控。

你的可持续发展仪表盘报告显示：“本季度 AI 能耗：2.3 GWh，同比下降 4%”，这张幻灯片在 ESG 评审中得到了礼貌性的认可。六个月后，CFO 走出分析师电话会议，向平台负责人提出了一个听起来很简单的问题：“我们的每瓦特 Token 数（token-per-watt）是多少？与竞争对手相比如何？”仪表盘无法回答。这并不是因为数据缺失——仪表盘里堆满了数据——而是因为它将推理视为单一的条目，将任务视为产品概念，而 AI 可持续性唯一真实的单位存在于这两者的交汇点。

这种错位并不是报告中的 Bug。这是一个分类错误，现有的碳核算指南（为基于 CPU 小时和每台虚拟机 kWh 的云工作负载而完善）无法独自解决。推理并不是一种具有稳定能量特征的工作负载。每 Token 的瓦特数会根据响应请求的模型层级（model tier）产生 30 倍的变化，根据调用时的批处理大小（batch size）产生 4 倍的变化，并根据前缀缓存（prefix cache）是否命中而产生另一个数量级的差异。将这些汇总成一个单一的 GWh 数字，就像在包含踏板车、轿车和 18 轮大卡车的车队中报告“平均汽车燃油效率”一样——在最无用的层面上，它是准确的。

智能体用 400 毫秒回答了一个简单的问题，然后因递归限制错误（recursion-limit error）崩溃。Trace 显示了 25 次工具调用。从上到下阅读 Trace，工程师会得出结论：智能体糊涂了 —— 以略有不同的顺序反复调用那几个工具，始终无法收敛。这个结论是错误的。智能体并没有糊涂。它陷入了一个死循环：工具 A 调用了模型，模型选择了工具 B，工具 B 的实现再次调用模型来格式化其输出，而格式化程序又选择了工具 A。Trace UI 将四个嵌套调用渲染为扁平列表中的四个兄弟调用，导致唯一能发现问题的开发者也无法察觉这个循环。

这就是工具重入（tool reentrancy），这是一种你的函数调用层几乎肯定没有建模的 Bug 类别。并发安全的代码对此已有数十年的原语支持：记录同一线程嵌套获取次数的重入互斥锁（reentrant mutexes）、语言层面的递归限制、堆栈检查 API，以及一种文化共识：任何回调运行时的函数都需要一个明确的契约，规定允许何种重入。工具调用层默认采用“发后即忘”（fire-and-forget）模式。运行时没有可供检查的调用栈，调度前没有循环检测器，工具定义上没有重入属性，Trace UI 的形式像日志而非图。结果就是，任何超过十几个条目的工具目录都会悄悄变成框架无法察觉的递归。

你智能体代码库中最昂贵的一行，就是从现有的 OpenAPI 规范中自动生成工具 Schema（tool schemas）的那一行。这看起来是一个利落的工程选择——单一事实来源、无重复、每次 API 变更时自动同步。但这也是为什么你的智能体在应该选择 searchUsersV3 时却选择了 searchUsersV2，因为你的规范示例中写了 limit=20 于是它就填了 20，并且悄无声息地丢掉了 tenant_id，因为它被埋在第七个参数槽位里。

单元测试中不会显现任何这类迹象。Schema 是有效的。端点（endpoint）是存在的。智能体的调用是格式正确的 JSON。然而，模型每次都会用错工具，且是以你的 QA 流水线永远察觉不到的方式，因为 QA 测试的是 API，而不是智能体对 API 的理解。

这个 Bug 是观念性的。OpenAPI 的设计初衷是向编写 SDK 代码的人类描述 API；而工具 Schema 则是作为 Prompt 的一部分，在每次调用时由 LLM 读取。将它们视为同一种产物，就好比根据数据库列名自动生成面向用户的文案一样，犯了同类型的错误。

一个多语言发布版本，如果只是将英文提示词翻译成 N 种语言，并将英文评估集也翻译成同样的 N 种语言，那它并没有发布一个真正的多语言产品。它只是将同一个产品发布了 N 次，并让所有的失败模式在它自己的仪表盘上变得不可见。该系统虽然表达流畅，但在文化层面上显得格格不入，而团队优化的指标——翻译质量——并不是衡量用户反应的正确维度。

发布当天的明显缺陷通常很小。一位日本用户收到的回复虽然语法正确，但显得生硬无礼。一位印度尼西亚用户发现助手以一种欢快直接的语体说话，听起来却很不礼貌。一位韩国用户收到的建议是围绕个人选择展开的，而提示词其实是关于家庭决策的。这些都不是翻译错误。它们是文化语体（cultural-register）错误，翻译无法修复，且经过翻译的评估也无法检测出来。

周二早上收到了一张支持工单：一名客户收到了关于退款期限的、言之凿凿的错误回答。工程团队调取了追踪记录，发现模型识别错了意图。产品 PM 查看仪表板，发现上个迭代发布的“极速退款”入口触发了一个 Prompt 从未针对其进行过调优的意图。平台 PM 指着评估套件（eval suite）说，测试全是绿色的。两人在技术层面都是正确的。但客户得到的回答依然是错的。

这就是“两个 PM 问题”，大多数 AI 团队都存在这个问题，只是没有给它命名。产品 PM 负责面向用户的界面——意图、成功指标、支持升级路径。平台或 ML PM 负责 Prompt、模型选择、评估套件和成本上限。两者的路线图在季度规划层面是协调的，但在每周发布层面却在背道而驰，因为两个 PM 在不同的仪表板上针对不同的指标进行优化，且有着不同的变更控制流程。

这种有趣的失效模式并不是因为两个 PM 意见不合，而是因为他们都在各自的职责范围内正确地完成了发布，却共同导致了一个无人负责的退化（regression）。