先说一个在教育学里做过很多次的实验。
1960 年代，心理学家 David Ausubel 研究了一个问题：为什么学生能背出课本里所有的定义，但遇到新题目还是不会做？他的结论是，记住知识的表述和真正理解知识的结构，是两件不同的事。他把这个区别叫做"机械学习"和"有意义学习"，前者是把新信息挂在记忆里，后者是把新信息嵌入已有的概念网络，知道它和其他东西的关系。
这个区分在今天看来显而易见，但它精确地描述了 RAG 在"教 AI 操作业务系统"这件事上遇到的困境。
RAG 是做什么的
RAG（Retrieval-Augmented Generation）的基本思路是：AI 回答问题时，不只靠训练时学到的知识，还可以从外部文档库里实时检索相关片段，把它们拼进上下文，再生成回答。用检索来增强回答的效果，缩写为 RAG。
这个思路在知识问答场景里有真实价值。比如公司内部的规章制度问答，把所有制度文件向量化存起来，用户提问时检索最相关的几段，AI 基于这几段回答——结果的准确性和可追溯性都比纯靠模型记忆要好得多。
问题出在当你想用 RAG 来"教会 AI 操作业务系统"的时候。
操作手册喂进去，然后呢
一个直觉上很合理的做法：把系统的操作手册、接口文档、字段说明全部向量化，存进知识库。当 AI 需要调用系统时，先检索相关文档，再根据文档生成调用方式。
比如，把波音 737-800 的飞行操作手册交给你，你能开飞机吗？
手册里确实写了起飞程序：推油门到 N1 转速达到某个值，松刹车，速度到 V1 之后不能中断起飞，到 VR 拉杆，到 V2 保持爬升姿态。步骤写得很清楚。但手册默认你已经知道一些它不会解释的事，比如地速和空速的区别。地速是飞机相对于地面的速度，空速是飞机相对于气流的速度。产生升力的是空速，不是地速。逆风起飞时，地速 130 节但空速可能已经 150 节，飞机已经可以离地；顺风起飞时，同样的地速，空速更低，需要跑更长的距离才能起飞。手册里标注的 V 速（V1、VR、V2）是空速，不是地速。如果你不理解这个区别，手册上的数字对你来说是没有意义的。
再比如襟翼。手册里有一张表，列出不同起飞重量下建议使用的襟翼档位（Flaps 1、5、10、15……）。但手册不会告诉你为什么：襟翼增大了机翼的弯曲弧度和面积，在低速时提供额外升力，代价是增加阻力。档位越大，起飞速度越低，但加速也越慢，适合跑道短的机场；档位小，起飞速度高，但阻力小，适合长跑道高温高原场景。这些权衡关系是航空领域的领域知识，不是飞机操作手册的内容。手册假设你已经理解了这一层，只告诉你结论。
用 RAG 把操作手册喂给 AI，AI 得到的是手册里写了的东西，比如步骤、参数、数值。但它得不到手册默认你已经知道的那一层，概念之间的物理关系、约束来自哪里、在什么条件下哪个参数的优先级更高。没有这一层，AI 拿着手册也只是在做文本匹配，碰到稍微偏离手册描述的情境就会失效。
业务系统的情况完全类似。
切片之后，上下文断了
RAG 的工作方式是把文档切成片段，每个片段单独向量化存储。检索时，根据问题找到最相关的若干片段，拼进上下文。
对于知识问答，这个切法是够用的。"年假政策是什么"这个问题，对应的答案通常在文档的某一段里，检索到那段就行。
但业务系统的操作不是这样的。考虑一个"创建采购订单"的操作：
- 接口文档里写了这个服务端命令的名称和参数列表
- 参数里有一个
供应商ID字段，具体的供应商 ID 需要先查供应商表 - 供应商表的结构在另一个文档里
- 创建之后还需要触发审批流，审批流的规则在第三个地方
这四段信息分散在不同文档的不同位置，切片之后大概率不会同时出现在检索结果里。即便每一段都被正确检索到，把它们拼成一个连贯的调用链路，需要 AI 自己完成跨片段的推理——而这个推理所依赖的"概念关系"，恰好没有被任何片段显式地表达出来。
AI 知道有一个"创建采购订单"的命令，知道有一个"供应商"的概念，但它不知道这两者之间的调用依赖关系，因为这个关系没有出现在任何一段文本里——它存在于系统的数据结构里，不在文档里。
Ausubel 的问题在这里重演了
回到开头的实验。学生能背出定义但不会解题，原因是他们掌握的是孤立的知识点，而不是知识点之间的关系网络。
RAG 做的事，本质上是给 AI 提供了一批"可以背出来的知识点"——接口名叫什么、参数有哪些、返回值是什么。但它没有告诉 AI 这些知识点之间的结构关系：这个接口依赖哪个实体，这个实体有哪些属性，哪些操作会影响哪些数据。Ausubel 把他的解法叫做"先行组织者"（Advance Organizer）——在学习具体内容之前，先给学习者提供一个高层次的概念框架，让新知识有地方挂载。实验证明，有先行组织者的学习组在迁移测试上的表现，显著优于直接学习具体内容的对照组。这个思路用在 AI 身上，对应的就是在让 AI 接触具体接口文档之前，先给它一个结构化的概念图，这个系统里有哪些实体，实体之间是什么关系，每个实体上有哪些动作，动作之间的依赖是什么。
这不是文档，是一个显式的知识结构。RAG 给的是前者，本体给的是后者。
另一个角度：程序性知识和陈述性知识
认知心理学有一对区分：陈述性知识（declarative knowledge）和程序性知识（procedural knowledge）。
陈述性知识是"知道某件事是什么"，如波音 737 有两台发动机，起飞推力各为 27000 磅。程序性知识是"知道怎么做某件事"，在什么状态下推油门推到什么位置，然后拉杆，然后检查哪些仪表。
操作系统手册里绝大多数内容都是陈述性知识，字段叫什么、参数类型是什么、返回格式是什么。RAG 能有效传递的也主要是陈述性知识，它能回答"这个字段是什么意思"，但很难回答"要完成这个业务目标，应该按什么顺序调用哪些接口"。后者需要的是程序性知识，而程序性知识的特点是它依附于结构——只有当你知道实体之间的关系，才能推断出正确的操作顺序。
这正是本体论切入的位置。本体不是一堆文档，而是一个显式的关系图。这个概念属于哪个实体，这个动作作用于哪个实体，这两个实体之间有什么依赖。有了这个关系图，AI 面对一个新的业务目标时，能够推导出完成这个目标所需的操作链路，而不只是检索出一批相关的文档片段。
RAG 在哪里仍然有用
说了这么多，RAG 在业务系统场景里并不是没有价值，只是它的价值位置不同。
用 PPT 里的三层框架来说：整个 Agent 执行过程分为"构建上下文"、"执行动作"、"分析结果"三个环节。RAG 的价值在第一个环节，帮 AI 在执行任务之前，补充业务规则、历史数据、领域知识。比如，AI 要生成一份采购建议，RAG 可以帮它找到相关的供应商评级规则、历史合同条款、价格波动记录。这些是辅助判断的背景知识，而不是驱动调用的结构信息。
调用正确接口、传正确参数、理解返回结果，这些事需要的是结构化的本体约束，而不是向量检索。
两者不是替代关系，是分工关系。混淆这个分工，把 RAG 用在它不擅长的位置，是很多企业 AI 项目走弯路的原因之一。
本文是"企业AI落地"系列的第6篇。下一篇讨论模型微调这条路：为什么把业务知识"烧入"模型是一个听起来彻底、但成本结构很不划算的选择。
