720 篇博文 含有标签「llm」

你的支付服务拥有 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 边界传播，主流编排框架也没有任何一个让截止时间传播变得容易。结果是一类看起来像延迟问题、实则是上下文传播问题的故障。

你的 AI 编码智能体刚刚生成了一个拉取请求。代码看起来没问题，编译通过，测试也过了。你合并了它。两天后，预发布环境的 CI 流水线开始抛出 AttributeError: module 'openai' has no attribute 'ChatCompletion'。智能体使用了一年前已被废弃、并在最新主版本中彻底移除的 API 模式。

这就是废弃 API 陷阱，它坑害团队的频率远比那些聚焦 AI 代码质量的会议分享所描述的要高得多。一项对七个前沿 LLM 进行评估、覆盖 145 个 API 映射的实证研究发现，大多数模型在主流 Python 库上的 API 使用合理性（AUP）低于 30%。当被明确给出废弃上下文时，所有被测模型的废弃 API 使用率高达 70–90%。这个问题是结构性的，与特定模型或特定库无关。

一份干净的 PDF、一个强大的 LLM、三十行代码。演示成功了。你提取出了发票总额、合同日期、患者诊断。利益相关方印象深刻。然后你推向生产，不到一周，流水线就在 15% 的文档上静默地返回错误数据——而没有人知道。

这就是文档 AI 的陷阱。失败模式不是崩溃或异常，而是一条在生成垃圾数据的同时仍然报告"成功"的流水线。构建生产级文档提取，与构建一个演示，是完全不同的问题——而大多数团队直到已经上线才意识到这一点。

大多数团队在做“云端 vs. 边缘”的决策时往往凭直觉：因为云端更简单，所以他们默认选择云端。直到 HIPAA 审计来袭，或者延迟 SLO 下降了 400 ms，亦或是收到了当月的账单。只有到那时，他们才会反思是否某些推理本来就应该在本地完成。

答案几乎永远不会是“全云端”或“全边缘”。大规模运行生产级 AI 的团队已经达成共识，采用了分层架构：由设备端或本地模型处理大部分请求，而云端前沿模型则负责处理小模型无法应对的情况。正确处理这种路由是一个工程决策，而不是一种直觉。

这就是进行严谨决策的决策框架。

大多数 AI 团队把通过评估套件视为系统正常运行的信号。但事实并非如此——至少不全是。一个稳定得分 87% 的套件只做了一件事：告诉你系统在套件恰好覆盖的那 87% 的场景中表现良好。如果这套测试是六个月前手工整理的，基于团队能想到的示例，从未用真实流量更新过，那它正在以越来越高的置信度测量错误的东西。

这就是评估覆盖率问题。它与你的评估器是否准确无关——而是关于你测试集中的查询分布是否与用户实际发送的查询分布相匹配。当这两种分布出现偏差时，你会得到一个比评估失败更糟糕的结果：一个通过的评估，背后却是悄然劣化的产品。

你的模型是基于去年的数据训练的。它在两个月前进行了内部评估，并在一个月后正式发布。当你得知用户遇到故障时，你已经落后于模型运行所需的现实世界六个月了。这种差距并非部署问题，而是反馈循环的问题。大多数团队不仅没有闭合这个循环，甚至根本没有对其进行衡量。

当模型表现不佳时，本能反应往往是归咎于模型架构或训练数据。但更深层次的问题通常在于反馈系统的延迟。从用户经历故障到该故障影响你的模型，这中间需要多长时间？大多数团队如果说实话，其实并不知情。行业分析表明，如果模型在六个月或更长时间内没有获得针对性更新，其在面对新数据分布时的错误率会上升 35%。原因并非模型本身在衰减——而是世界在前行，而模型却停滞不前。

几乎在每一个生产环境的 AI 系统中都会出现这样一种模式：团队从一个精简的系统提示词（system prompt）开始，发布功能，然后不断迭代。出现了一个新的边缘案例，于是他们添加一条规则。又来了一个工单，再加一条规则。六个月后，系统提示词已经增加到了 2,000 个 token，涵盖了 20 个不同的行为要求。对于大多数请求，AI 听起来依然连贯。但微妙的合规性失败已经潜伏了数周——这里忽略了格式，那里跳过了语气要求，一条升级规则被悄悄绕过。没有人发现，因为没有哪个单独的失败严重到需要触发警报。

这不是模型质量问题。这是基于 Transformer 的语言模型处理指令的一种基本架构特性，大量的实证研究使得这些失败模式变得可预测。理解这一点将改变你编写系统提示词的方式。