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

大多数智能体系统在构建时都基于一个隐含的架构假设：LLM 在同一次推理调用中同时处理规划和执行。要求它完成一个包含十个步骤的任务，模型会决定做什么、去执行、检查结果、再决定下一步做什么——这一切都在一个连续的 ReAct 循环中完成。这看起来很优雅。但在实际工作负载下，它会以一种难以诊断的方式崩溃，因为其失败模式看起来更像是模型质量问题，而非设计问题。

智能体规划模块——即纯粹负责任务拆解、依赖建模和排序的组件——是大多数从业者都会跳过的接缝。只有当事情变得困难到无法忽视时，它才会显现出来。

当多智能体流水线（multi-agent pipeline）开始输出垃圾内容时，人们的直觉往往是归咎于模型。推理能力差、上下文错误、幻觉。但在实践中，很大一部分多智能体系统的失败源于更乏味的原因：智能体之间无法进行可靠的通信。格式错误的 JSON 虽然通过了语法验证，但无法通过语义解析。编排器（orchestrator）发送了一个状态为 "partial" 的任务，而下游智能体将其理解为已完成。由于缺少幂等键（idempotency key），重试操作触发了两次。

这些不是模型故障，而是接口故障。它们比模型故障更难调试，因为日志中没有任何信息会告诉你序列化契约（serialization contract）已经断裂。

你的代码通过一个流程发布：特性分支 (feature branch) → 合并请求 (pull request) → 自动化测试 → 预发布 (staging) → 生产环境 (production)。每一步都有门槛。如果没有通过你定义的检查，任何东西都无法到达用户手中。这种“枯燥”正是它最好的地方。

现在想象你需要更新一个系统提示词 (system prompt)。你在仪表盘中编辑字符串，点击保存，更改立即生效 —— 没有测试，没有预发布，版本控制中没有 diff，除了手动改回去之外没有回滚的方法。这就是大多数团队的运作方式，也是提示词更改成为 LLM 应用非预期生产事故主要原因的原因。

挑战不在于团队粗心大意。而在于持续交付 (continuous delivery) 的规范是为确定性系统构建的，而 LLM 并非确定性的。整个思维模型需要从头重建。

你的向量搜索在基准测试中表现出色，但用户依然感到沮丧。

失败模式非常微妙：用户询问“我们的哪些供应商卷入了影响与 Martinez 账户所在地区相同客户的事件？”你的嵌入模型检索到了事故记录。它们检索到了供应商合同。它们检索到了客户账户。但它们是以相互孤立的文档形式检索出来的，LLM 必须在上下文中理清这些关系——而这些关系横跨了实体图（entity graph）中的三个跳数（hops）。当每个查询涉及五个或更多实体时，如果没有关系结构，准确性会降至接近零。而有了关系结构，性能则保持稳定。

这正是知识图谱增强检索——GraphRAG——旨在解决的瓶颈。它不是向量搜索的直接替代品。它是一个具有不同成本结构、不同失败模式、以及在特定类别查询中具有压倒性优势的不同系统。

当 Gemini 1.5 Pro 发布并具备 1M token 的上下文窗口时，一波工程师宣布 RAG 已死。这种论点看似无懈可击：既然你可以把整个知识库直接丢进提示词（Prompt）中让模型自己去处理，为什么还要构建一个包含分块器（chunkers）、嵌入（embeddings）、向量数据库和重排序器（re-rankers）的检索流水线呢？

这种论点在生产负载下会分崩离析。Gemini 1.5 Pro 在“大海捞针”（needle in a haystack）基准测试（即隐藏在文档中的单个事实）中实现了 99.7% 的召回率。但在现实的多事实检索场景中，平均召回率在 60% 左右。这 40% 的遗漏率并非基准测试的偏差；而是你的系统在静默状态下未能向用户展示的事实。而且，一个 1M token 请求的延迟比 RAG 流水线慢 30–60 倍，而单次查询成本约为其 1,250 倍。

长上下文模型是强大的工具。它们只是不适合大多数生产环境的检索工作负载。

当 LLM 在单次响应中返回三个工具调用时，最显而易见的方法是并行运行它们。你会想到 asyncio.gather()，分发调用，收集结果，然后将它们返回给模型。代码在测试中运行正常，在预发环境中也表现良好。但在生产环境运行六周后，你开始注意到应用程序持有本应释放的 HTTP 连接。Token 配额的消耗速度快于使用指标所显示的。偶尔，一个发送电子邮件的工具会触发两次。

根本问题不在于 LLM 或工具 —— 而在于并发原语。asyncio.gather() 并非为多步智能体管道产生的故障模式而设计，将其作为并行工具执行的核心，会产生在问题复合之前难以察觉的问题。

当开发者第一次接入 JSON 模式时，响应结果感觉就像解决了一个大问题。LLM 不再返回 Markdown 围栏、文字道歉或靠近花括号的乱码。输出可以解析了，测试通过了，生产环境上线了。

然而，三周后，一个后台作业悄无声息地失败了，因为模型在 Schema 要求 {"status": "completed"} 时返回了 {"status": "complete"}。由于一个必填字段返回了 null 而不是被省略，数据流水线崩溃了。智能体工具调用循环（agent tool-call loop）提前终止，因为模型在字符串值中嵌入了一个异常换行符，导致下游解析器卡死。

JSON 模式保证了语法上有效的 JSON。它并不保证该 JSON 的含义与你的预期一致，不保证它包含你的应用程序所期望的字段，也不保证在多次请求之间保持语义一致性。这些是不同的问题，需要不同的解决方案。

你部署了一个从支持工单中提取客户意图的流水线。你已经对其进行了广泛测试。它运行良好。发布三天后，一个警报被触发：下游服务因 KeyError: 'category' 而崩溃。模型开始返回 ticket_category 而不是 category —— 提示词（prompt）没有改动，只是你的提供商悄悄推行了一次模型更新。

这就是结构化输出问题。而 JSON 模式并不能解决它。

你的 Datadog 仪表板显示 99.4% 的在线率，低于 500ms 的 P95 延迟，以及 0.1% 的错误率。一切都是绿色的。与此同时，你的支持队列却充满了抱怨 AI 给出了完全错误答案的用户。你毫无头绪，因为每个请求都返回了 HTTP 200。

这是传统可观测性与你在 LLM 系统中真正需要的可观测性之间的本质区别。语言模型可能会以标准 APM 工具无法留下痕迹的方式发生故障：幻觉事实、从错误的产品版本中检索文档、在代码更改修改了系统提示词后将其忽略，或者在模型更新后对特定查询类型静默降级。在你的延迟图表上，这些看起来都一切正常。

大多数生产环境中的 AI 系统在成本管理上都会犯同样的错误：它们上线时仅使用单一的最强模型 (frontier model) 来处理每个请求，眼睁睁看着 API 账单随流量线性增长，然后才手忙脚乱地添加缓存或缩减上下文窗口来补救。真正的解决方法——根据每个查询的实际需求将其路由到不同的模型——事后看来显而易见，但很少能被很好地实现。

数据能够清楚地说明问题。当前的最强模型 (frontier model)，如 Claude Opus，每百万输入 token 的成本约为 5 美元，每百万输出 token 为 25 美元。同系列的高效模型成本分别为 1 美元和 5 美元——比例达 5 倍。使用 RouteLLM 的研究表明，通过合理的路由，你可以在将 85% 的查询路由到更便宜的模型的同时，保持 95% 的最强模型质量，从而根据工作负载实现 45–85% 的成本降低。这不仅仅是边际改进；它改变了大规模部署 AI 的单位经济效益。

大多数构建 LLM 产品的工程团队都遵循相同的路径：提示基础模型，遇到性能瓶颈，然后立即将微调作为解决方案。这种本能反应往往是错误的。

微调是一个强大的工具。它可以释放真实的性能提升，在大规模应用中降低推理成本，并让你对模型行为进行精确控制。但它也带来了隐性成本——在数据、时间、基础设施和持续维护方面——团队通常会系统性地低估这些成本。在许多情况下，提示工程或检索增强（RAG）本可以让他们更快、更便宜地达成目标。

本文为你提供了一个具体的框架，告诉你每种方法在何时胜出，其依据是最近的基准测试和生产经验。

每隔几个月，AI 工程社区就会兴起一股新的“不必费心评估”的浪潮。论点通常是：评估成本太高、过于脆弱、难以定义，对于快速迭代的产品团队来说，最终不值得投入这些额外的负担。不如发布、迭代，并相信你的直觉。

这是一个糟糕的建议，会导致劣质软件。2026 年 LangChain 的一项调查发现，只有 52% 的组织进行离线评估，而只有 37% 的组织针对实时流量运行在线评估——然而，32% 的组织将质量列为他们生产部署的第一大障碍。这并非巧合。