202 篇博文 含有标签「production」

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

你的模型说“我非常有信心”，但 40% 的时间都是错的。这不叫幻觉——这是校准失败，而且在生产环境中，这是一个更难检测、衡量和修复的问题。

幻觉占据了所有媒体头条。但过度自信的错误答案往往更危险：模型以极高的表达置信度生成一个看似合理、流利的回答，而下游消费者完全收不到任何异常信号。幻觉检测器、RAG 依据性检查和事实核查流水线都有助于处理凭空捏造的内容。但对于模型知道事实却对其确定性存在系统性错误校准的情况，这些手段几乎无能为力。

大多数发布基于 LLM 功能的团队都将置信度视为事后才考虑的事情。这篇文章将探讨为什么校准会失败、如何衡量它，以及在生产环境中真正能改善这一指标的设计模式。

检查你代码库中每一次 LLM 调用里的 max_tokens 参数。如果你和大多数团队一样，这个参数要么没设置，要么设成了模型的最大值，或者是半年前随便选的一个像 4096 这样的整数，之后就再也没动过。它是 API 请求中一个显眼的预算旋钮，却在默默地为你从未使用过的冗余买单。

在中等商业模型上，输出 token 的成本大约是输入 token 的四倍，而在昂贵模型上甚至高达八倍。生成步骤的经济效益完全是失衡的：你在 max_tokens 中留下的每一分未使用的余量，都是你可能需要支付的成本；而且由于解码是顺序进行的，你生成的每一个 token 都会线性地增加你的 P50 延迟。然而，大多数生产系统都将此参数视为安全阀——设置得高高的，然后忘掉它，继续开发。

一个团队花了三周时间集成一个基础模型，将收到的支持工单分类到不同的路由类别中。该模型在测试中达到了 87% 的准确率。他们发布了。六个月后，一名工程师注意到 70% 的工单在主题行中包含产品名称，而一个简单的查找表就能以 99% 的准确率处理这些工单。LLM 正在处理那困难的 30%，而在其余时间里则在胡言乱语。

这并非一个少见的故事。之所以会发生这种情况，是因为团队将“使用 LLM”作为首选的实现方案，而不是最后的手段。解决方法是设立一个强制性的关卡：在被允许构建 AI 版本之前，你的 AI 功能必须先输给一个笨规则。

2026 年 1 月，OpenAI 仅提前两周通知便将若干 GPT 模型从 ChatGPT 中退役——而就在此前不久，其 CEO 刚刚在公开场合承诺在此次退役后会"提前充分通知"。对于那些已将工作流构建在这些模型之上的团队而言，这份公告无异于周五下午收到的一条页面报警。那一次 API 未受波及，但下一次未必如此。

你当前调用的每一个模型都有弃用日期。部分日期已列在供应商的文档页面上，另一些尚未宣布。操作层面的问题不是你的生产模型是否会被退役，而是你能否在问题发生前及时收到通知并从容应对，还是在用户开始遭遇故障后手忙脚乱地迁移。

大多数 LLM 工程经验 —— 缓存提示词、调整温度、控制 token 预算 —— 都假设输入是文本、输出也是文本。一旦加入图像、PDF 或音频，这些经验几乎全部失效。预处理方式不同，故障模式不同，成本模型也不同。而你为文本流水线构建的评估套件，根本发现不了新出现的问题。

企业知识中约有 50% 存储在非文本格式中：PDF、幻灯片、扫描表单、产品图像。当团队尝试处理这些数据时，他们会发现，引入多模态不仅仅是增加一种模态 —— 而是增加了一个全新的工程复杂度层面。

当你的 LLM 功能上线后，监控面板可能会追踪准确率、延迟和错误率。但几乎可以肯定，它不会追踪方差——即同一个提示每次输出差异有多大。这个盲区，正是生产环境 AI 功能悄然崩溃的地方。

方差决定了你的产品是让用户感觉可信赖还是喜怒无常。一个在评估套件中得分 88% 的功能，如果 40% 的时候返回两句话、60% 的时候输出十个段落，其对用户信任的侵蚀速度，会比一个得分 80% 但表现一致的功能快得多。只优化准确率的团队，解决的是可靠性问题的错误一半。

提示熵预算正是填补这一空白的概念：一种结构化的方法，用于衡量、预算和控制模型在相同输入下的输出分布——就像你在 SLO 框架中对待 p99 延迟或错误预算一样。

你会通过一张截图发现它。

客户会把它发出来，记者会引用它，或者团队里的某个人会在晚上 11 点在 Slack 上给你发个链接。你的 AI 系统言之凿凿地给出了错误的答案 —— 错到滑稽，或者错到可能伤及他人 —— 而且现在已经公开了。

大多数工程团队花费数月时间强化他们的 AI 流水线以防这一时刻的到来，却发现他们从未计划过一旦这一时刻到来该怎么办。他们知道如何迭代评估（evals）和调整提示词（prompts）。他们不知道该由谁来发布回复推文，该回复应该说些什么，或者如何区分是一次性的倒霉样本，还是已经在生产环境中运行了数周的潜在故障模式。

这就是针对那一刻的应对指南。

大多数团队引入护栏的方式，和引入日志一样随意：直接挂上去，以为代价很小，然后继续往下走。但代价并不小。一次内容审核检查要花 10–50ms，再加上 PII 检测，又是 20–80ms；再叠上输出 schema 校验和毒性分类器，在第一个 token 到达用户之前，串行开销就已累积到 200–400ms。加上 500ms 的模型响应，你那个"快速"的 AI 功能现在给人的感觉就是迟钝。

把锅甩给 LLM 是错的。护栏才是瓶颈。解决方案不是去掉安全措施，而是停止把安全检查当成一堆无差别的任务，改用架构思维来对待它。

有一个快速测试，可以告诉你当前的 AI 技术栈是否能部署在受监管环境中：对于模型上周二做出的任何决策，你能否准确回答——运行的是哪个模型版本、输入了哪些数据、输出了什么、是谁发起的请求，以及为什么该输出在给定输入下是正确的？如果答案涉及"我们需要查一下 CloudWatch"或"我觉得用的是我们一直在用的那个模型"，那你就不合规。你距离被审计卡死只有一步之遥。

正在为金融科技信用评分、医疗临床决策支持和保险核保构建 AI 的团队正在痛苦地发现这一点。默认的 AI 技术栈——云端 LLM API、应用层日志、隐私政策附录——无法满足 HIPAA、GDPR、SOX 或欧盟 AI 法案的技术要求。差距不在法律层面，而在架构层面。受监管 AI 的合规是一个工程问题，解决方案更像是分布式系统工程，而非法律文书。

Spider 基准测试看起来很棒。GPT-4 在数百个测试查询中的 text-to-SQL 转换得分超过 85%。团队看到这些数字，配置好 LangChain 的 SQLDatabaseChain，然后上线“询问你的数据”功能。两周后，一位分析师关于按地区划分收入的无心提问触发了全表扫描，导致报表系统宕机 30 分钟。

基准测试数字是真实的。问题在于，基准测试不使用你的模式 (schema)。

Spider 1.0 在包含 5–30 个表和 50–100 个列的数据库上测试模型。而你的生产数据仓库有 200 个表、700 多个列，根据你查询的系统有三种 SQL 方言，以及在四年前编写代码的工程师看来有意义，但对其他任何人来说都毫无意义的列名。当研究人员推出 Spider 2.0——一个具有企业级规模 schema 和现实复杂性的基准测试时——GPT-4o 的成功率从 86.6% 下降到 10.1%。这种断崖式下跌才是生产环境的真实写照。

大多数工程师在生产中而非设计评审时发现他们的会话架构是错误的。演示运行良好：你用五条消息进行了测试，对话历史可以放入内存，LLM 也能连贯地响应。然后你上线了，在第一批千个并发会话与第一次部署滚动之间，用户开始遇到上下文遗忘、部分响应或会话无故重置的问题。让聊天功能原型设计变得简单的内存模式，正是使其在运营中变得脆弱的根源。

这并不是一个微妙的架构错误。对话状态与请求状态有着本质区别。请求状态只存活数毫秒；对话状态必须能够在 Pod 重启、水平扩展、部署周期和移动网络中断中存活——持续数分钟、数小时或数天。建立在错误抽象上的系统会产生可靠性债务，随着对话长度增长和用户负载增加而累积。