553 篇博文 含有标签「ai-engineering」

这种场景每次都如出一辙。你的智能体正在预订酒店房间，支付API调用返回200后、确认信息存储之前发生了网络超时。智能体框架发起重试，支付再次执行，客户被扣了两次款。支持团队升级处理，某位高管说AI"幻觉出了重复扣款"——这种说法是错的，但听起来有道理，因为没人愿意承认他们的重试逻辑从一开始就是坏的。

这不是AI问题，而是分布式系统问题——被AI层全盘照搬，却没有带来分布式系统工程师几十年苦心钻研出的应对之道。标准的智能体重试逻辑假设操作是幂等的，而大多数工具调用并非如此。

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

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

一家医疗公司每天用 GPT-4 处理 10,000 份文档，年度账单高达 5 万美元。在用前沿模型的输出对一个 270 亿参数的开源模型进行微调后，相同的工作量仅需 5,000 美元——节省了 90%。这个小模型在他们的特定任务上还比前沿模型高出 60%，因为它已经见过数千个完全正确行为的示例。

这就是现代形式的知识蒸馏：你一次性支付前沿模型 API 费用来生成训练数据，然后永远运行一个小型专用模型。这个算法之所以成立，是因为当你拥有权重时推理成本很低，而且在有足够示例的情况下，特定任务的模型能在窄任务上胜过通用模型。

但"收集输出、微调、上线"并不是完整的方案。大多数尝试蒸馏的团队都会遇到三堵隐形墙之一：劣质的合成数据导致学生学到错误行为，缺乏可靠信号来判断学生何时真正就绪，或者生产环境中出现无声的质量崩溃，直到用户抱怨才被发现。本文涵盖决定蒸馏是否成功的流程决策。

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

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

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

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

在AI工作中遇到困难的工程师，最常见的问题不是缺乏技术知识，而是他们一直在问错误的问题。他们想知道的是："这能用吗？"但他们真正应该问的是："这个系统的失败率是多少，这个失败率对于这个使用场景来说是否可以接受？"

这一转变——从二元正确性转向可接受的失败率——是有经验的AI工程师思考问题的核心差异。听起来简单，其实不然。由此延伸的一切都是不同的：你如何调试、如何测试、如何部署、监控什么、以什么为信心基础。没有完成这一转变的工程师会一直在与工具对抗并且不断失败。

你六个月前部署的模型在日历上已有一个日落日期。你可能没有标注它。你的值班轮换也不知道这件事。积压工作中没有对应的工单。当提供商最终拔掉插头时，你会在最糟糕的时刻收到生产环境中的 404 Model not found 错误，而且没有准备好的回滚方案。

这是大多数使用托管LLM的工程团队的标准故事。模型弃用被归类为供应商问题，而非运营问题——直到它变成一场事故的那一刻。

大多数在大语言模型（LLM）之上构建 SaaS 产品的团队都是通过惨痛的教训才发现多租户问题的：他们利用单一的共享提示词配置快速出海，然后惊恐地发现一个客户的系统提示词泄露到了另一个客户的响应中，或者某个企业级客户耗尽了所有人的速率限制，亦或是当月 AI 账单寄来时，根本无法确定是哪个客户造成了 40% 的支出。这种失败模式并非停留在理论层面——NDSS 2025 的一篇论文证明，vLLM、SGLang、LightLLM 和 DeepSpeed 中的前缀缓存（prefix caching）可以被利用，仅通过时间信号和精心构造的请求，就能以 99% 的准确率重建另一个租户的提示词。

构建多租户 AI 基础设施与传统数据库的多租户化并不相同。共享组件——推理服务器、KV 缓存、嵌入流水线、检索索引——每一个都面临独特的隔离挑战。这篇文章涵盖了你实际必须解决的四个问题：隔离、定制、成本归因以及单租户质量追踪。

大多数构建AI智能体的团队在投产三个月后都会发现同一个问题：他们精心设计的评估套件——围绕文本输入和JSON输出构建——当智能体遇到模糊的发票、扫描合同或从未见过的UI截图时，毫无参考价值。纯文本评估通过了，但用户提交了工单。

多模态输入不仅仅是另一种需要接入的模态，它们引入了一类截然不同的故障，需要不同的架构决策、不同的成本模型和不同的评估策略。将视觉能力视为对现有文本智能体的即插即用扩展的团队，无一例外地低估了所需的工作量。

大多数采用多模态AI的团队都会犯同样的错误：他们在精心策划的基准数据集上评估模型，并假设生产性能会与之相符。然而现实并非如此。视觉模型在MMMU基准上取得高分，与同一模型在生产中可靠地从发票中提取结构化数据之间，存在足以葬送产品发布的巨大差距。视觉编码器增加了基准排行榜上无法体现的延迟。空间推理在用户实际发送的图表类型上失效。在干净语音上表现良好的音频模型在真实世界的噪声下土崩瓦解。而多模态真正优于纯文本的任务类别，比供应商所暗示的要窄得多。

本文是关于这一差距的实战指南——它在哪里出现，为什么存在，以及哪些部署模式能在生产负载下保持稳定。

你的 AI 功能发布时准确率为 92%。团队举杯欢庆。三个月后，进展陷入停滞 —— 尽管投入了更多数据、更多算力和两次模型升级，错误率却不再下降。听起来很熟悉吗？

这就是 “90% 可靠性之墙”，这并非巧合。它源于三种力量的交汇：边际准确率提升的指数级成本、可消除误差与结构上不可避免误差之间的区别，以及生产环境中故障的复合放大效应 —— 而这些是基准测试永远无法捕捉到的。不了解自己正在与哪种力量对抗的团队，将会浪费数个季度的时间去试图解决那些根本无法解决的问题。

凌晨两点，你被告警叫醒。延迟上升，错误率飙升。你 SSH 进去，查看日志——什么都没有。没有指向错误部署的堆栈跟踪，没有第 247 行的空指针异常。只有一串模型输出，这些输出在细微之处、以不可预测的方式出了问题——只有当你连续读了 50 条之后，才能意识到这一点。

这就是 LLM 驱动系统中故障的样子。而传统的"告警-分类-修复"循环根本不是为此而生的。

标准值班手册有三个前提假设：故障是确定性的（相同输入，相同的错误输出）、根因是可定位的（某段代码改了，某项资源耗尽了）、回滚是直接的（还原部署，搞定）。这三点在随机 AI 系统中都不成立。同一个提示词会产生不同的输出。根因通常是一个概率分布，而不是某行代码。而且，你根本无法"回滚"一个第三方提供商昨晚悄悄更新的模型。