702 篇博文 含有标签「llm」

一个运行多智能体市场调研流水线的团队花了 11 天时间观察他们的系统正常运行——绿色的仪表盘、零错误、正常的延迟——而 4 个 LangChain 智能体却在无限循环中互相博弈。等到有人扫了一眼账单仪表盘时，这一周 127 美元的预估成本已经变成了 47,000 美元。这些智能体从未崩溃。API 从未返回过错误。每一个基础设施告警都保持沉默。

这就是 AI Oncall 的核心问题：你的系统在运维层面可以显示为绿色，但在其本应完成的任务上却发生了灾难性的失败。传统的监控旨在检测崩溃、延迟飙升和错误率。AI 系统可以在满足所有基础设施 SLO 的同时，悄无声息地产生错误输出、无限期地循环执行任务，或者在不产生任何有用结果的情况下消耗数千美元的计算费用。错误代码的缺失并不代表结果的正确。

METR 于 2025 年发布的一项研究，邀请 16 位经验丰富的开源开发者预测 AI 工具能让他们效率提升多少。他们猜测会快 24%。该研究随后对 246 个真实任务（包括修复 bug、开发功能、代码重构）进行了测量，这些任务被随机分配到"允许使用 AI"和"禁止使用 AI"两组。结果是：使用 AI 的开发者实际上慢了 19%。研究结束后，参与者再次接受调查。他们仍然认为 AI 让自己效率提升了 20%。

这种感知生产力与实测生产力之间的差距，并非某项研究的特例。这是大多数团队目前衡量 AI 功能时所面临的核心问题。那些看起来像成功的信号，在很多情况下衡量的是工具的新鲜感，而非其实用价值。而上线后的头 30 天，是最不适合观察的时间窗口。

当团队第一次将 LLM 接入日志管道时，演示效果非常惊人。你只需粘贴一段堆栈跟踪（stack trace），GPT-4 就能用通俗易懂的语言解释根本原因。因此，接下来的自然选择显而易见：将其自动化。将所有日志都发送给模型，让它寻找问题。

这就是你每月烧掉 125,000 美元，并用“幻觉”来骚扰值班工程师的方式。

计算过程简单而残酷。一个中型生产系统每天产生大约十亿行日志。按每条日志条目大约 50 个 token 计算，每天就是 500 亿个 token。即使按照 GPT-4o 折扣后的每百万输入 token 2.50 美元计算，在不计算输出成本、重试或推理开销的情况下，你每天也要支付 125,000 美元。对流式日志进行实时的前沿模型分析不是一个优化问题 —— 而是架构选型错误。

构建生产级 AI 系统的团队往往通过同一种方式发现“对齐税”：有人投诉延迟，另一个人将其追踪到审核流水线，于是原本隐性的成本项突然变得显而易见。到那个阶段，安全层已经层层堆叠 —— 拒绝分类器、输出过滤器、毒性评分器、人力介入队列 —— 却没有任何人对它们进行过单独测量。拆解它们是痛苦、昂贵且在政治上充满争议的，因为现在看起来你是在反对安全。

更好的路径是从第一天起就将安全开销视为一等公民的工程指标。对齐税是真实的，它是可衡量的，并且具有复利效应。150 ms 的防护栏检查听起来还可以，直到你在智能体工作流中将三个检查串联在一起，并纳闷为什么你的 P95 延迟达到了 4 秒。

你的内容审核服务返回 {"severity": "MEDIUM", "confidence": 0.85}。下游计费系统将 severity 解析为枚举值 ["low", "medium", "high"]。一次模型更新后，服务偶尔开始返回首字母大写的 "Medium"。没有任何部署发生，没有 schema 变更。集成在生产环境中悄然崩溃，整整六天无人察觉——因为所有 HTTP 状态码都是 200。

这是 LLM 支撑服务 API 契约的根本问题：表面看起来像 REST API，但底层行为是概率性的。标准契约工具假设确定性。当这个假设被打破时，它是悄无声息地崩溃的。

你的 /v1/summarize 端点在 18 个月里运行得非常完美。然后你升级了底层模型。输出格式没变，JSON schema 完全一致。但你的下游消费者开始提交 bug：摘要“太随意了”，要点“详细得诡异”，边界情况下的拒绝响应“变得不同”。从传统意义上讲，一切都没坏；但在 AI 的语境下，一切都坏了。

这是 REST 和 GraphQL 从未被设计用来解决的版本控制问题。传统的 API 合约假设确定性：相同的输入总是产生相同的输出。而 AI 端点的合约是概率性的——它包括语气、推理风格、输出长度分布以及拒绝阈值，当你更换或更新底层模型时，所有这些都可能发生漂移。对于以数据库为支撑的 API 有效的技术，对于以 AI 为支撑的 API 是必要但不充分的。

你的支付服务拥有 99.9% 的可用性 SLA。请求要么成功，要么以文档记录的错误代码失败。当出现故障时，你清楚地知道哪里出了问题。

现在，想象你发布了一个封装了 LLM 的智能发票解析 API。在一个周一早晨，你最大的客户打来电话：“你们的 API 返回了一个有效的 JSON 对象，但在涉及外币的发票中，total_amount 字段的值差了十倍。” 你的服务返回了 HTTP 200。你的可用性仪表板显示绿色。根据每一个传统的 SLA 指标，你都没有违反任何规定。但你确实搞砸了——而且在契约语言中，你甚至找不到词汇来描述到底哪里出了错。

这就是当今大多数 AI API 部署的核心鸿沟。管理你的 API 承诺 的契约为确定性系统而写，而 LLM 并非确定性系统。

大多数 AI 功能的架构都大同小异：用户输入发送到 API，云端 GPU 进行处理，然后响应返回。这种往返过程已经如此常态化，以至于工程师们很少对其产生质疑。但它带有一个隐藏的“税”：每次交互都有 200–800 ms 的网络延迟，API 密钥必须存放在某个可访问的地方（因此容易受到攻击），而且你无法控制系统运行时间的硬性依赖。

通过 WebGPU 实现的浏览器原生 LLM 推理打破了这三个假设。模型在用户的 GPU 上运行，位于浏览器沙箱内，没有网络往返。这并非未来的功能 —— 截至 2025 年末，WebGPU 已在 Chrome、Firefox、Edge 和 Safari 中默认出货，覆盖了全球约 82.7% 的浏览器流量。工程问题已从“我们能做到吗？”转向“它何时能击败云端，以及我们如何在两者之间进行智能路由？”

在生产环境的 AI 部署中，有一种模式反复出现，与用户直觉背道而驰。当模型说"我不确定"时，用户倾向于再次核查；当模型自信地给出答案时，用户则倾向于信任它。问题在于，前沿大语言模型恰恰在最可能出错的领域表现得最为自信。

这并非边缘失效模式。当被要求生成估算任务的 99% 置信区间时，模型实际覆盖真实值的比例仅约为 65%。主要生产模型的预期校准误差（ECE）从 0.108 到 0.726 不等——存在显著的错误校准，且在医疗、法律、金融等高风险垂直领域可量化地更差。危险之处不在于不准确本身，而在于这种倒置关系：同样的模型在通用知识任务上表现出合理的校准，却在错误代价最高的任务上变得自信而系统性地出错。

在43%的测试提示中，GPT-4会在被要求续写给定段落时逐字复现书中原文。2025年的一项研究中，研究人员仅通过持续的前缀喂入循环——无需任何越狱操作——就从一个生产级LLM中近乎完整地提取了一本书的内容。如果你的产品使用语言模型生成内容，版权风险已不是未来的隐患，而是正在你的用户会话中实时发生，而你可能完全没有监测手段。

这不是一篇法律文章，而是一篇关于法律问题的工程文章——工程决策要么制造这个问题，要么遏制它。律师会告诉你什么构成侵权；这套框架告诉你系统在哪里泄漏、如何度量，以及哪些措施真正能降低风险，而不只是看起来有效。

几乎每一个全球部署的 AI 产品中都潜伏着一种隐蔽的失败模式。工程师本地化了 UI 字符串，通过翻译 API 运行模型输出，让母语者抽查几个回复，然后就发布了。该产品在技术上是多语言的，但在文化上并不称职。东京、利雅得和成都的用户收到的输出在语法上是正确的，但在文化上是错误的——这些回复表现出的不尊重、困惑或不信任，是团队在汇总指标中永远无法看到的。

研究结果是明确的：测试的每一个主要大语言模型（LLM）都反映了讲英语的新教欧洲社会的价值观。针对来自 107 个国家的代表性数据进行模型测试的研究发现，没有任何一个模型与非洲、拉丁美洲或中东地区人们建立信任、表达尊重或解决冲突的方式相契合。翻译修补了表面，但底层的校准仍然是西方化的。

大多数构建多步 agent 管道的工程师会在第一次生产故障后约两周发现同一个问题：他们在 API 网关设置了 5 秒超时，但 agent 管道有四跳，而整个系统的行为就好像根本没有超时一样。第三跳的 agent 不知道上游调用方三秒前就已放弃等待，它继续运行、继续调用工具、继续生成 token——而用户早已离开。

这不是配置错误，而是结构性问题。延迟约束默认不会跨 agent 边界传播，主流编排框架也没有任何一个让截止时间传播变得容易。结果是一类看起来像延迟问题、实则是上下文传播问题的故障。