生产级 AI 系统不能只靠 RAG

RAG（检索增强生成）已经成为几乎所有企业 AI 问题的默认答案。

需要一个内部聊天机器人？加上 RAG。

想做一个面向文档的 AI 助手？加上 RAG。

正在构建客服 Agent？使用 RAG。

RAG 如此流行是有原因的。它解决了大语言模型最突出的局限之一：模型可以检索相关信息，而不必完全依赖训练期间学到的知识。

但许多工程团队在第一个系统上线后，都会发现一个问题：

出色的检索，并不会自动造就出色的产品。

聊天机器人即使找到了正确的文档，仍然可能给出错误答案。

AI 助手即使能够访问数千页资料，面对需要审批、业务规则或实际操作的工作流时，仍然可能失败。

生产环境中的 AI，并不只是检索问题。

真正重要的是设计出这样的系统：它能够理解上下文、与其他软件交互，并在真实业务条件下安全运行。

到了这个阶段，许多 AI 项目面对的就不再是机器学习挑战，而是工程挑战。

RAG 为什么会成为标准方案

在 RAG 出现之前，开发者只有两个糟糕的选择。

要么每当公司知识发生变化时就重新微调模型，要么接受模型在回答无法验证的问题时产生幻觉。

RAG 改变了这一局面。

开发者不必重新训练模型，而是可以从向量数据库中检索相关文档，并在推理期间将它们作为上下文提供给模型。

这样做立刻带来了好处。

回答变得更有事实依据。

知识库可以持续更新。

幻觉减少了。

公司的私有信息仍然保留在基础模型之外。

对于许多使用场景来说，这正是团队所需要的。

直到应用变得更加复杂。

生产环境中的问题很少像 Demo 那么简单

Demo 通常遵循一套简单的流程。

用户提出问题。

应用检索几份文档。

模型生成答案。

生产系统很少如此简单直接。

客户询问订单情况。

答案取决于库存。

库存取决于 ERP 数据。

ERP 中的信息已经过时。

物流数据来自另一个服务。

客户还希望修改配送地址。

这时，AI 已经不再只是回答问题。

它正在参与一套工作流。

检索文档只是这套工作流的一部分。

上下文不只是检索到的文档

AI 架构中一个非常普遍的误区，是把上下文当成一组文档。

上下文远不只是知识，还包括：

• 之前的对话
• 当前的工作流状态
• 组织政策

设想两名员工提出完全相同的问题：

“哪些发票已经逾期？”

财务经理得到的回答，应该与客服人员得到的回答截然不同。

尽管检索到的文档可能完全相同。

优秀的生产系统能够理解这种区别。

检索无法取代系统设计

许多工程团队都会犯一个错误：以为更好的 embedding 能够解决架构问题。

即使是质量最高的检索管线，也无法决定：

• 是否应该批准某张发票；
• 是否可以暴露客户数据；
• 某项操作是否需要经理批准；
• 是否应该执行某个 API 调用；
• 多个系统是否需要保持同步。

这些决策属于应用架构。

语言模型应该参与工作流，而不是让它自己成为整个工作流。

缺失的一层：编排

现代 AI 应用很少只涉及一次模型调用。

相反，它们需要协调多个组件。

一项用户请求可能会触发：

• 生成通知；
• 生成最终回复。

LLM 成为更大系统中的一个参与者。

这个编排层决定了信息如何在工具、模型和业务系统之间流动。

缺少这一层，AI 应用往往会变得难以调试，并且几乎无法扩展。

为什么无状态 AI 会失效

传统 API 天生是无状态的。

每个请求都包含服务器所需的一切信息。

但业务运作并不是这样。

项目会在数周内持续演进。

客服对话会跨越多个渠道延续。

审批会流经多个部门。

客户可能在几天甚至几个月后再次回来。

应用需要记忆。

不只是对话历史，还需要运营记忆。

在决定今天应该做什么之前，它需要理解昨天发生了什么。

这种记忆不应该完全存在于 prompt 中。

它应该属于经过精心设计的应用架构。

AI Agent 改变了讨论方向

这也是 AI Agent 获得广泛关注的原因之一。

Agent 不只是回答孤立的问题，还可以执行结构化任务。

在必要时请求批准。

持续执行，直到工作流完成。

请注意，这段描述中没有提到什么。

它并没有假设语言模型无所不知。

相反，模型成为一个推理层，负责协调企业现有的业务能力。

这才是看待企业 AI 更切实际的方式。

人工审批仍然是优秀架构的一部分

人们对 AI Agent 存在一种误解，认为它们应该完全自主运行。

在生产系统中，这通常并不是理想选择。

医疗建议。

这些操作通常需要人工监督。

设计良好的架构允许 AI 完成前期准备工作，同时由人类审批敏感决策。

这种方式可以在不牺牲问责机制的前提下提升系统效率。

许多成功的企业平台都采用了这种模式，因为它在自动化与运营控制之间取得了平衡。

可观测性比大多数团队预想的更加重要

传统软件出现故障时，工程师会检查日志。

AI 系统出现故障时，排查过程会复杂得多。

一系列问题很快就会浮现：

• 检索到了哪些文档？
• 使用的是哪个版本的 prompt？
• 哪个模型生成了这份回答？
• 为什么检索系统把某份文档排在另一份文档之前？
• 哪个外部 API 超时了？

如果没有完善的可观测性，就很难复现故障。

生产环境中的 AI，需要具备与分布式系统相同的工程严谨性。

这些能力已经不再是可选项。

RAG 仍然是现代 AI 工程中最有价值的技术之一。

但生产环境中的 AI，需要的不只是语义搜索。

它需要能够理解工作流的系统。

能够协调工具的应用。

可靠的运营数据。

结构化的权限体系。

以及能够随业务变化持续演进的架构。

这正是工程领域的讨论逐渐从单个模型转向完整 AI 系统的原因。

计划部署生产系统的团队，通常应该在编写代码之前，先记录这些架构决策。《AI-Native Product Playbook》探讨了一套从概念验证走向生产环境的实用方法，其核心是不把 AI 当成一项孤立的功能。

同样，可靠的检索始于一个为 AI 准备好的数据基础，而不是简单地再增加一个向量数据库。干净、互联的数据，仍然是预测 AI 能否成功落地的最重要因素之一。

最后，生产部署要想取得成功，背后必须有扎实的产品工程实践作为支撑，包括可观测性、可扩展架构、集成模式以及长期可维护性。

RAG 解决了一个重要问题。

通过将语言模型与外部知识连接起来，它大幅提升了语言模型的实用性。

但企业软件从来都不只是信息检索。

企业依靠流程运转。

下一代 AI 应用的胜负，不会取决于谁能检索到最好的文档。

而会取决于谁能围绕这些文档构建出最好的系统。

这正是令人惊艳的 Demo 与上线后仍能持续创造价值的软件之间的区别。

如果需要采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。