426 篇博文 含有标签「llm」

一个批量推理任务在六分钟后完成。网络在返回响应时发生了抖动。你的重试逻辑开始介入。两分钟后，任务再次完成——而你的账单也翻了一倍。这只是将传统的幂等性思维应用于 LLM 流水线而不根据随机系统进行调整时，所发生的最温和的情况。

大多数生产团队都是通过惨痛的教训才发现这个问题的：本意是为了从瞬时错误中恢复的重试，却触发了第二次付款、发送了重复的电子邮件，或者在数据库中写入了相互矛盾的记录。解决方案不是更好的重试逻辑，而是一个全新的心智模型——当你的核心组件是概率性的时，幂等性究竟意味着什么。

你构建了一个 AI 功能。你跑了评估。你在测试集上看到了 95% 的准确率。你上线了。六周后，用户对它深恶痛绝，你的团队正在悄悄计划回滚。

这就是最后一公里可靠性问题，它很可能是当今生产环境中 AI 功能失败最常见的原因。这与你的模型不好无关，而与平均准确率指标如何掩盖失败分布有关——以及某些失败无论其统计频率如何都会带来高昂代价。

你的用户没有秒表，他们只有感觉。而这些感觉与时钟现实的偏差，对你构建AI界面的方式至关重要。一个逐字出现、持续三秒的响应，用户普遍感觉比一秒后突然全部出现的批量响应更快——尽管批量系统在客观上更快。这不是非理性的，也不是人类认知的缺陷，而是一种有据可查的感知现象。如果你在构建AI产品时没有考虑这一点，你就是在为错误的指标做优化。

本文将剖析延迟感知背后的心理学、真正预测用户满意度的指标、利用这些感知特性的前端模式，以及何时流式传输会带来比价值更多的复杂性。

有一种故障模式会在团队解决了幻觉过滤、输出解析、重试逻辑等较容易的问题之后反复出现：模型给出听起来很自信的错误答案，基于置信度的路由逻辑信任了这些错误答案，系统在生产中悄无声息地出现异常，而评估仪表板看起来一切正常。

这不是提示词问题，而是校准问题，它根植于现代LLM的训练方式之中。

一个团队发布了一款支持聊天机器人。在测试阶段，每月账单看起来还在可控范围内——工程团队演示期间仅花费了几百美元。上线三周后，发票寄到了：4.7 万美元。没人虚报 Token 数量，也没人算错账。生产环境的工作负载与他们模拟的完全不是一回事。

这种模式在不断重复。团队估算 LLM 成本的方式就像估算数据库查询成本一样——通过测量一个典型的请求并乘以预期访问量。这种思维模型在 LLM 上彻底失效了，因为两个最大的成本驱动因素（输出 Token 长度和工具调用开销）是在推理阶段决定的，其行为在设计阶段无法完全预测。

本文讨论的是如何在发布前进行更好的预测，而不是在账单到期后如何优化。

当你的团队决定从 Claude 3.5 Sonnet 升级到 Claude 3.7，或者从 OpenAI 迁移到自托管的 Llama 部署时，直觉通常是将其视为一次库升级：更改 API 密钥，更新模型名称字符串，进行快速的健全性检查，然后发布。这种直觉是错误的，那些遵循这一做法的团队会在第二周的凌晨 2 点发现原因——当时客服代理开始以完全不同的格式生成响应：技术上有效，语义上却是灾难性的。

切换 LLM 提供商或模型版本在结构上与数据库模式迁移（database schema migration）完全相同。两者都涉及更改系统中应用其余部分具有隐式契约的行为。两者可能在第一天看起来没问题，但在第十天发生灾难性的失败。两者都需要双重运行（dual-running）、金丝雀发布（canary deployment）、回滚标准和迁移方案（migration playbook）——而不是修改配置后发一条 Slack 消息。

这个方案听起来很诱人：将遗留记录输入 LLM，描述目标 Schema，让模型自行找出字段映射。无需手写解析器，无需数月的转换逻辑，也不依赖领域专家。已有团队实践后，在传统 ETL 所需时间的一小部分内达到了 70–97% 的准确率。问题在于，剩余 3–30% 的失败不像失败——它们看起来像是正确的数据。

这种不对称性——错误输出在结构上是合法且合理的——才是让 LLM 驱动的数据迁移在没有正确验证架构时真正危险的根源。本文介绍了那些成功落地的团队实际构建了什么：LLM 在流水线中的适用场景、它静默出错的地方，以及能捕获传统工具无法发现的错误的验证层。

模型卡显示代码生成准确率为 89%。你的团队在实际代码库上只得到了 28%。模型卡显示有 100K token 的上下文窗口。而在你的文档工作负载下，性能在 32K 时就大幅下降。模型卡通过了红队安全评估。但在上线后的 72 小时内，针对用户的提示词注入攻击就出现了。

这种差距并不罕见。这已成为常态。在 2025 年对 1,200 个生产部署的分析中，42% 的公司在生产集成阶段放弃了他们的 AI 计划 —— 高于前一年的 17%。他们中的大多数都仔细阅读过模型卡。

问题不在于模型卡撒谎。而在于它们衡量的内容与你需要了解的内容不同。准确理解这一差距 —— 并构建内部基准测试套件来弥补它 —— 是交付可靠 AI 的团队与交付懊悔的团队之间的分水岭。

你接手了一个基于 GPT-4-turbo 构建的 AI 功能。该模型即将被弃用。你的经理希望通过切换到更新、更廉价的模型来降低成本。你快速跑了一遍测试，指标看起来还过得去，于是就上线了——结果一周后，核心用例的准确率下降了 22%。支持工单不断攀升。你现在面对的是一场危机式迁移，而非有计划的操作。

这就是模型可移植性税：每当你将应用逻辑与某个特定基础模型紧耦合时，就会累积的隐性工程成本。每个团队都在为此买单，大多数人直到账单到来时才意识到数字有多大。

你的 LLM 通过了你投喂的所有评估。延迟很稳定，准确率看起来不错，团队充满信心。然后一个开罗的用户提交了一个 bug：结构化提取返回了格式错误的 JSON。首尔的一名开发者注意到，助手在几轮对话后就开始忽略复杂的指令。孟买的一名产品经理意识到，聊天机器人的摘要是完全错误的——虽然微妙，但始终是错误的。

这些都没有在你的基准测试中显现出来，因为你的基准测试是用英语进行的。

这就是多语言质量悬崖：一种剧烈的、系统性的性能下降，而且对于发布 AI 产品的团队来说，这种下降几乎普遍是不可见的。差距并不微小。在长多轮对话中，阿拉伯语和韩语用户在任务中的准确率约为 40.8%，而英语用户则为 54.8%——这 14 个百分点的差距会随着每一轮对话而叠加。对于结构化编辑任务，同样的差距会扩大到灾难性的程度：32–37% 的准确率，而英语表现则是可接受的。用户能感觉到这一点。你的仪表盘却感觉不到。

大多数构建 AI Agent 的团队都在花数周时间调整 Prompt 和评估（evals）、基准测试模型选择以及微调 Temperature —— 而他们真正的瓶颈其实在更深的一层：那个为人类开发者而非 Agent 设计的数据访问层。

这种失配并非细微。像 Hibernate、SQLAlchemy 和 Prisma 这样的 ORM，结合返回分页、单实体响应的 REST API，产生的数据访问模式对自主 AI Agent 来说完全是错误的。其结果是 Token 浪费、速率限制失败、级联的 N+1 数据库查询，以及 Agent 因为无法负担加载所需上下文的成本而产生幻觉。

本文将探讨这一结构性问题，以及一个针对 Agent 优化的数据层究竟是什么样的。

当团队部署 AI 安全过滤器时，对话几乎总是集中在它拦截了什么。它是否拦截了越狱攻击？它是否标记了仇恨言论？它能检测提示词注入吗？对于召回率（Recall）来说，这些都是正确的问题。但它们几乎从未与另一个同样重要的问题挂钩：它错误地拦截了哪些不该拦截的内容？

答案通常是：很多。由于大多数团队在发布时都使用供应商的默认阈值，并且从未在生产环境中对误报（False Positives）进行监测，他们直到用户开始抱怨时才会发现——或者直到用户停止抱怨，因为他们已经停止使用该产品了。