702 篇博文 含有标签「llm」

企业团队基于基准测试和演示选择LLM供应商，然后在生产环境中才发现SLA实际保障的内容——通常远低于预期。你费力谈下来的99.9%可用性保证并不涵盖延迟。法务团队签署的数据处理协议，除非明确添加了相关条款，否则并不禁止供应商用你的输入数据进行训练。而没有人量化的供应商集中风险，在某次遥测部署级联影响Kubernetes控制平面导致核心产品中断四小时后，会以最惨烈的方式暴露出来。

这不是采购问题，而是采购单独无法解决的工程问题。构建AI系统的工程师需要理解这些合同实际说了什么——以及没说什么。

在 2024 年底，OpenAI 的 o3 系统在 ARC-AGI 基准测试中获得了 75.7% 的分数——这是一个专门为抵抗优化而设计的测试。AI 研究界欢欣鼓舞。但从业者仔细观察后发现：o3 使用了该基准测试 75% 的公开训练集进行训练，且最高算力配置使用的资源是基准线的 172 倍。这并不是伪装成分数的能力突破，而是伪装成能力突破的分数。

这就是评估悖论（Evaluation Paradox）。一旦某个基准测试成为团队优化的目标，它就不再能衡量其最初设计的目的。古德哈特定律（Goodhart's Law）——“当一个衡量指标变成目标时，它就不再是一个好的指标了”——虽然是在 20 世纪 70 年代的经济政策中提出的，但它却极其精准地描述了 AI 基准测试的现状。

当一名律师在联邦备案文件中引用不存在的法庭案例时，这一事件被广泛报道为“ChatGPT 产生了幻觉”。当一家咨询公司的政府报告中包含虚假脚注时，复盘报告写道“AI 伪造引文”。当一个医疗转录工具在医疗笔记中插入暴力语言时，解释仅仅是“模型产生了幻觉”。在每一个案例中，代价昂贵的失败都被归结为一个由三个词组成的根本原因，这使得修复变得不可能。

“模型产生了幻觉”在 AI 领域等同于在堆栈跟踪中写下“未知错误”。它描述了发生了什么，却没告诉你为什么发生或如何修复。每一次幻觉都有一个可诊断的原因——通常属于四个类别之一——且每个类别都需要不同的工程响应。理解这种区别的团队能够交付可以优雅降级的 AI 系统。而不理解的团队则在不断地通过提示词玩“打地鼠”游戏。

你将昂贵的 LLM 换成了更快、更便宜的蒸馏模型。延迟增加了，成本上升了，质量下降了。你感到困惑并回滚了版本，因为你刚刚花了三周时间做的优化工作反而让一切变得更糟。

这并非假设。这是生产环境 AI 系统中最常见的失败模式之一，它源于一个诱人但错误的心理模型：优化某个组件就能优化整个系统。

你正在运行一个由 LLM 驱动的应用，你的 p99 延迟为 4 秒。你已经优化了提示词，减少了输出长度，并切换到了流式传输。但这个数字几乎没变。问题不在于你的代码——而是在你无法控制的黑盒内部运作的物理学和排队论。

每个推理服务商在你的第一次 API 调用之前，就已经通过数十项架构决策决定了你应用的性能上限。KV 缓存淘汰策略、连续批处理（continuous batching）调度、分块预填充（chunked prefill）块大小——文档中没有提到这些，你也无法配置，但它们决定了你不得不面对的延迟和成本曲线。

这篇文章将解释推理基础设施内部究竟发生了什么，为什么它会产生不可避免的延迟底线，以及你真正能做的少数几件事。

周一你的提示词还运行正常。周三，用户开始抱怨响应感觉不对劲——答案变短了，下游的 JSON 解析时不时崩溃，原本准确率 94% 的分类器现在徘徊在 79% 左右。你没有部署任何新代码，配置文件里调用的模型名称还是那个。但某些东西变了。

这就是隐形模型漂移：LLM 供应商在不作任何公告的情况下推送静默的、未记录的行为变更。这是 AI 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。

一个拥有 7.7 亿参数的模型在它擅长的任务上击败了一个拥有 5400 亿参数的模型，这听起来似乎是不可能的。但这正是经过蒸馏的 T5 模型在对抗 few-shot PaLM 时所取得的成就——仅使用了 80% 的训练样本，模型尺寸缩小了 700 倍，且每次推理成本仅为几分之一美分，而不再是数美元。这其中的秘诀并非更好的架构或更巧妙的训练方案。而是利用大模型生成标注数据，并用这些数据来训练小模型。

这就是知识蒸馏（Knowledge Distillation）。而且，你并不需要通过微调教师模型来使其生效。

在一个运行时间足够长的 AI 项目中，几乎都会出现一种模式。团队构建了一个原型，演示效果看起来不错，但在生产环境中，输出结果不够一致。有人建议切换到最新的前沿模型——用 GPT-4o 代替 GPT-3.5，用 Claude Opus 代替 Sonnet，用 Gemini Ultra 代替 Pro。有时这会有所帮助，但最终这种方法会不再奏效。团队发现，他们为每次推理支付了 5-10 倍的费用，延迟增加了一倍，而任务准确率仍然停留在 78%，而不是他们需要的 90%。

这就是潜在能力上限（latent capability ceiling）：即你所使用的语言模型的原始规模不再是限制因素的临界点。这是一个有经验数据支持的真实现象，大多数团队在遇到它时却浑然不觉——因为“使用更大的模型”这一反射动作成本低、速度快，并且在项目早期往往非常有效。

每个事件流系统最终都会将同一条消息投递两次。网络抖动、Broker 重启、偏移量提交失败——至少一次投递不是 Bug，而是契约。传统消费者能够优雅地处理这种情况，因为它们是确定性的：处理同一事件两次，得到相同的结果，写入相同的记录。第二次写入是一个空操作（no-op）。

LLM 不是确定性处理器。相同的提示词加上相同的输入，每次运行都会产生不同的输出。即使设置了 temperature=0，浮点运算、批次组合效应以及硬件调度的差异也会引入方差。针对"确定性" LLM 设置的研究发现，在自然发生的多次运行中，准确率差异高达 15%，最优与最差性能之间的差距甚至达到 70%。至少一次投递加上非确定性处理器，并不会给你带来至多一次的行为，只会带来不可预测的行为——这是一场蓄势待发的生产环境危机。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。

一个团队在 GPT-4 上构建了一个生产环境功能。几个月后，出于成本考虑，他们决定评估 Claude。他们花了两周时间进行“迁移”——但核心的 API 替换只花了一个下午。剩下的十天都花在了修复损坏的系统提示词（system prompts）、重新测试拒绝服务的边缘情况、调试由于意外文本而崩溃的 JSON 解析器，以及重新调整在不同供应商之间表现迥异的工具调用模式（tool-calling schemas）。原本以为只是简单的连接器更换，结果迁移预算膨胀成了多层重构。

这就是现实中的 LLM 供应商锁定问题。那些受挫的团队并不是因为选错了供应商——而是因为他们没有意识到锁定存在于多个维度，且每个维度都有不同的风险画像。

当一个用户的 80 轮支持对话突然开始与其 60 轮前的建议相矛盾时，团队最初将其归咎于 Bug。其实并没有 Bug，只是模型“迷失”了。在所有主流的前沿模型中，多轮对话在相同任务上的表现平均比单轮交互下降了 39%。大多数团队从未衡量过这一点。他们假设上下文窗口的效力大致等同于其 Token 限制所暗示的程度，并据此构建产品。

这种假设在无声无息中出现了错误。长会话不仅仅是变得更慢或更昂贵 —— 它们变得不可靠，而这种不可靠性在用户感到沮丧之前几乎无法被察觉。