164 篇博文 含有标签「production-ai」

一个令人不安的事实：80% 的 AI 项目未能提供业务价值，但团队却一直在追求最复杂的解决方案。一个具备工具调用、记忆检索和自主规划的多 Agent 编排系统可以做一个引人入胜的演示。而一个将客户支持工单路由到正确队列的简单 Prompt，在第一年就能为你公司赚到 200 万美元。这两种结果的可能性并不相等，普遍程度也不同，而行业一直在做出错误的选择。

这种模式是可预测的。一个工程团队构建了一些令人印象深刻的东西，向领导层演示，获得发布批准——然后眼睁睁地看着它在生产环境中悄无声息地退化。与此同时，竞争对手悄悄部署了一个封装了分类器的两百行 Python 脚本，从未进行过演示，却在每一项重要的业务指标上都超越了他们。

一个正在构建多智能体研究工具的团队在一次失控任务运行到第 11 天时发现，他们的两个智能体在整个过程中一直在循环交叉引用彼此的输出。账单金额：47,000 美元。没有人类看到过结果。没有触发任何警报。系统只是在持续运行，并确信自己正在取得进展，因为架构中没有任何环节提出这样一个问题：当一个任务确实无法完成时会发生什么？

消息队列在几十年前就通过死信队列 (DLQ) 解决了这个问题。一条超过投递重试限制的消息会被路由到一个暂存区，操作员可以在那里检查它、修复根本原因，并在系统准备就绪时重新播放。这种模式简单、经过实战检验，但在当今的生产级智能体系统中几乎完全缺失。

你的流式传输正常工作。你的重试逻辑正常工作。你的安全过滤器正常工作。你的个性化功能也正常工作。但当你将它们部署在一起时，奇怪的事情发生了：流式传输中途出现的速率限制错误导致用户看到的是一段被截断的响应，而系统却将其记录为成功。重试机制触发了，但流式传输已经结束。个性化层提供了一个定制化的响应，而安全过滤器本应拦截这个响应——除非过滤器看到的是 Prompt 的脱敏版本，而不是个性化层所处理的那个版本。

每一个功能都通过了你编写的各项测试。然而系统还是让用户失望了。

这就是功能交互故障（feature interaction failure），它是当今 AI 系统中最容易被误诊的生产环境 Bug。

你的智能体已经与同一个用户对话了400次。六个月前她说她更喜欢Python。三个月前她的团队迁移到了Go。上周她提到了一个新的TypeScript项目。这三个事实现在都存储在你的向量数据库中——语义相似、时间顺序混乱、权重相同。下次她请求代码帮助时，你的智能体会同时检索到这三条信息，将这团矛盾的内容递给模型，然后自信地为TypeScript场景生成带有Go风格的Python代码。

这就是幽灵上下文：那些永不消亡的过时信念，与其替代版本一同被检索，悄然腐蚀智能体的推理。

这个问题之所以被低估，是因为它不会产生可见错误。智能体不会崩溃，不会拒绝响应，而是生成流畅自信的输出——只是微妙地、代价高昂地出错了。

你的 SRE 团队非常擅长运行微服务。他们精通蓝绿部署、金丝雀发布、分布式链路追踪、SLO 消耗率告警以及复盘文化。接着，有人发布了一个由 LLM 驱动的功能，不到一周就发生了一起上述实践都无法处理的故障：模型开始生成听起来很合理但结构错误的内容，没有日志报错，没有健康检查失败，用户在任何人注意到之前已经默默地接收了四个小时的垃圾信息。

这不是技能差距，而是架构差距。运行 LLM 服务是一门与运行微服务截然不同的运维规范。如果你不明确地识别出那些无法迁移的实践，它们将会让你的团队陷入困境。

当你编写系统提示时，脑海中有一个预设的用户形象。也许是一位用简洁英语提出有针对性问题的专业人士，也许是发送简短、范围明确、完全符合提示假设的请求的人。你针对看似具有代表性的示例进行测试，调整直到输出效果令人满意，然后上线。

然后你看到了生产流量。

你的系统提示必须处理的真实查询群体，并非你所设计的中位情形，而是一个分布——有些查询范围狭窄，更多的漫无边际——还有一条长尾，暴露出你指令中每一个隐藏假设。对大多数生产系统而言，15%到30%的真实查询落入提示处理欠佳的类别。令人不安的是：这些失败大多是静默的。系统返回200状态码，用户得到一个看似合理的答案，失败永远不会浮现在你的日志中。

当法务团队问"AI 为什么拒绝了这笔贷款申请？"时，你的思维链追踪并不是正确答案。就算你有 1200 个 token 的逐步推理过程也没用。他们需要的是一句能在庭审中站得住脚的话——而现在，大多数工程团队根本不知道如何生成这样的解释。

这就是利益相关者解释鸿沟：工程师对模型行为的理解，与监管机构、高管和法律团队完成工作所需的信息之间的距离。弥合这一鸿沟需要一个独立的架构层——而大多数生产 AI 系统从未构建过这一层。

思维链提示（Chain-of-thought prompting）本是为了解决语言模型的黑箱问题。展示推理过程，验证每个步骤，理解模型如何得出结论。这个想法直觉上是对的——而这恰恰是问题所在。它感觉太显然正确了，以至于从业者将可见推理链部署到生产系统中，却没有追问一个更难的问题：如果展示推理过程反而让事情变得更糟，该怎么办？

2024年至2026年间的研究已开始系统性地记录这种"更糟"究竟是什么样子。可见推理链导致了两种截然不同的失败模式，在生产环境出现问题之前往往被忽视。第一种是用户侧问题：中间推理步骤会在用户看到最终答案之前，将其锚定于可能错误的结论。第二种是系统层问题：推理追踪制造了审计追踪的假象，而作为模型实际决策过程的解释，它从根本上是不可靠的。

大多数团队将 LLM 质量评估视为部署前的关卡：运行评估套件，检查分数，然后发布。这种方法大约只能捕捉到用户实际会遇到的 40% 的故障。剩下的故障之所以会溜走，是因为生产环境的流量与你的评估集完全不同——不同的查询分布、不同的会话长度、不同的上游数据，以及并发负载下不同的模型行为。等到用户投诉出现时，问题往往已经发生了好几天。

解决办法不是在部署前增加更多评估，而是针对实时流量进行持续评估。这种评估是基于这样一个现实设计的：你在推理时没有标准答案（ground truth）标签，并且你需要在几分钟内（而不是几周后）获得可操作的信号。

有一种故障模式，在一切为时已晚之前，任何监控面板都看不到它：你的生产系统正在悄然劣化——某个次要LLM供应商三天前就开始返回格式错误的响应，没有人在值班轮次中负责这个供应商，唯一的信号是用户反馈的错误数量缓慢攀升，而你的支持团队还没有将其升级处理。你得知这件事，是因为一位客户取消了订阅。

这不是模型质量问题，而是运维规范问题。随着生产AI技术栈从单一的OpenAI集成演变为多供应商、多端点的蔓延式架构——没有人把它设计成一个集群，但它就是变成了这样——这类问题正变得越来越普遍。

大多数关于上下文窗口（context windows）的讨论都集中在模型能“容纳”什么。更难的问题是模型如何“处理”它所容纳的内容——具体来说，它如何追踪对话者不断演变的目标。

意图并非一成不变。用户从模糊的描述开始，通过迭代不断细化，有时会自相矛盾、离题或修正。他们在第 40 条消息时真正的需求，未必是他们在第 2 条消息中所表达的内容。如果一个智能体将上下文视为扁平的追加日志，它会堆积所有信息——但仍然会误判当前的意图。

这是一个在生产环境中比任何人愿意承认的更频繁出现的场景。用户询问 AI 助手当前的利率政策。你的 RAG 系统获取了一份高度相关的美联储文件——语义相似度评分高达 0.91——模型自信地返回了答案。但这个答案已经过时六个月了。RAG 索引上次刷新是在十月份。参数化知识则更为陈旧。一次实时 API 调用本可在 400 毫秒内返回正确的当前数据，但没有人在路由逻辑中加入这样的判断：这个问题的答案允许有多旧？

这种失败不是检索失败，而是时序路由失败。系统在其技术栈的某处确实能够获取正确信息，只是将查询发送到了错误的层级。