RAG vs 微调 vs 本体

企业知识管理三条路，该走哪条？

RAG微调本体论Ontology企业AI知识管理GraphRAGFine-tuning

一、一个几乎所有企业都在面对的选择

企业AI项目启动之后，迟早会撞上同一道墙：怎么让AI"懂"你的业务知识？

这道墙面前摆着三条路。

第一条路叫 RAG——检索增强生成。把企业文档丢进向量数据库，用户提问时先搜出相关段落，再塞给大模型生成回答。快、便宜、不改模型，几乎是所有企业的默认选项。

第二条路叫微调——拿企业数据对大模型做二次训练，把知识"烧"进模型参数里。听起来更彻底，但代价也不小。

第三条路叫本体——不存文档、不烧参数，而是把企业的实体、关系、约束和动作建模成一个可执行的知识结构。这条路最重，但解决的是前两条路根本够不到的问题。

三条路不是互斥的。但在实践中，大多数企业的选择路径惊人地相似：先用 RAG，半年后发现差点意思，再试图修补，然后意识到问题可能不在技术实现上，而在于选错了路。

这篇文章想做的事很简单：把三条路各自解决什么问题、各自够不到什么问题，一次说清楚。

二、RAG：找到知识，但不理解知识

RAG 的核心逻辑可以用一句话概括：把知识当"文档库"，用的时候搜出来塞进 prompt。

这个逻辑在企业场景里极其有效——如果你要解决的问题确实是"找到"。员工手册里年假怎么算？合同模板在哪里？某个产品的技术参数是什么？这些问题的答案存在于某段文本里，RAG 能把它搜出来，交给大模型组织成自然语言，完事。

但企业真正卡住的，往往不是"找到"的问题。

片段化问题

一家制造企业的采购经理问AI："A 供应商的交付风险有多大？"

RAG 会怎么做？它在向量数据库里搜索"A 供应商"，找到三段文本：一段来自供应商资质文件，一段来自历史交付记录，一段来自最近的质量事故报告。然后它把这三段拼在一起，交给大模型生成回答。

但问题在于，这三段文本在原始文档里从来就不是在一起写的。它们分属不同的系统、不同的部门、不同的时间。RAG 把它们"拼"在了一起，但拼出来的不是全貌，是三个碎片。

采购经理真正需要的不是三段摘要的拼接，而是一个完整的判断：这家供应商的资质等级是什么，近12个月的准时交付率是多少，有没有质量事故，这些因素综合起来意味着什么风险等级。这个判断需要的是结构化的推理链，而不是文本片段的检索。

关系盲区

RAG 能找到"A 是什么"和"B 是什么"，但找不到"A 和 B 之间的约束关系"。

比如一家金融企业，客户问："我的信用额度能不能提到 500 万？"这个问题不只是关于这个客户本身，它还涉及：这个客户所在行业的风险等级是否允许、他的集团关联客户是否已有大额授信、最近一次信用评估的结果是什么。

这些信息分布在客户档案、行业分类表、集团关系图谱、风控评估报告里。RAG 能分别搜到它们，但它不知道它们之间存在约束关系——"行业风险等级约束了信用额度上限""集团关联授信需要合并计算"。这些关系不是写在某段文本里的，而是业务规则本身。

执行断链

RAG 只负责"找到"，不负责"做事"。

还是那个信用额度的例子。AI 搜到了所有相关信息，给出了一个分析："根据当前行业风险等级和集团关联授信情况，建议额度调整为 350 万。"然后呢？

然后客户经理需要手动登录授信系统，手动填写调整申请，手动提交审批流程。AI 帮你"看"了，但没法帮你"做"。

这就是为什么很多企业部署了 RAG 之后，员工的感觉是"有个很聪明的搜索框，但还是得自己干"。

GraphRAG 的修正

微软在 2024 年推出的 GraphRAG，本质上是在 RAG 上面加了一层知识图谱结构。它先把文档中的实体和关系抽取出来，构建图谱，再基于图谱做检索和聚合。

GraphRAG 部分解决了片段化问题——它可以沿着图谱路径做跨文档的推理，而不是纯靠向量相似度搜索。但它仍然停在"检索"层面。图谱描述的是"什么和什么有关系"，但不定义"这个关系意味着什么约束、触发什么动作"。

换句话说，GraphRAG 是 RAG 的升级版，但升级的方向是"更精准的检索"，不是"从检索到执行的跨越"。

三、微调：记住知识，但知识会过时

微调的核心逻辑同样可以用一句话概括：把知识"烧"进模型参数里，让模型在推理时直接"想起来"，而不是每次从外部检索。

这个逻辑在某些场景下非常有效。

微调最擅长的事

当你需要的是"风格对齐"——让模型像你们行业的人一样说话——微调几乎不可替代。法律文书有法律文书的措辞习惯，医疗报告有医疗报告的表述规范，金融研报有金融研报的框架结构。这些不是知识，是肌肉记忆。微调擅长把这种肌肉记忆写进模型。

同理，格式适配和领域术语学习也是微调的强项。"EBITDA"在财务语境里不需要每次检索定义，"批产"在制药行业里有特定的含义——这些高频、稳定、不需要更新的"知识"，微调处理得很好。

但当你把微调当作"知识管理"方案来用，问题就来了。

知识冻结

微调完成的那一刻，知识就过期了。

这不是夸张。一家银行微调了一个合规助手模型，上线那天它确实掌握了最新的监管政策。但三个月后，银保监发了一份新规。模型知道的是三个月前的旧规。要让它"知道"新规，你需要重新准备训练数据、重新训练、重新评估、重新上线。这个周期少则两周，多则两个月。

而企业知识的更新频率远比大多数人想象的要高。客户信息在变、供应商资质在变、市场价格在变、合规条款在变。用微调来管理这些知识，就像用刻光盘来存储实时数据——介质选错了。

隐性知识不可解释

微调把知识变成了模型参数的分布。人无法打开模型检查"它到底记住了什么"，也无法定位和修正单条错误知识。

一家企业微调了一个内部知识问答模型。上线后发现，它在回答某条人事政策时总是给出错误答案。但工程师找不到这个错误"住"在哪个参数里——你不能像修改数据库记录一样修改模型权重。唯一的办法是重新构造纠错数据、重新训练。而重新训练之后，你也不知道这条改对了没有、别的地方是否被改坏了。

这就是所谓的"灾难性遗忘"：新知识挤掉旧知识，是微调的结构性风险。

多域冲突

一家集团企业同时经营制造、金融和零售三个板块。如果用一个模型微调所有板块的知识，板块之间的边界和约束关系会模糊甚至冲突——"投资"在金融板块和制造板块的含义完全不同，"客户"在零售和金融语境下的属性结构也不一样。

如果用三个模型分别微调，又带来了版本管理、一致性和成本的问题。

四、本体：理解知识之间的关系，并基于关系执行

先说清楚一件事：本体不是另一种"让AI记住更多知识"的方案。

RAG 解决的是"找到知识"，微调解决的是"记住知识"，它们都在"知识的量"这个维度上做文章——更多文档、更准检索、更深的参数记忆。

本体换了一个维度。它解决的不是"知识的量"，而是"知识的结构"。

在 Ontology 里，一个供应商不是三段文本的拼接，而是一个 Object Type——它有资质等级、合同记录、交付历史、风险标签，这些属性通过 Link 连接到其他 Object Type：客户、产品、工厂、物流线路。这些连接不是隐含在文本里的，而是显式定义的。

更重要的是，这些连接上可以挂 Action。当供应商的风险等级从"低"变为"高"，一个 Action 可以自动触发：通知采购经理、暂停未执行合同、启动替代供应商评估流程。

这就是从"检索"到"执行"的跨越。

对应 RAG 的三个盲区

整体性：当你问"A 供应商的交付风险有多大"，Ontology 不是去搜三段文本拼在一起，而是沿着 Object Type 的属性和 Link 做结构化查询。你得到的不是碎片摘要，而是一个从资质到交付到质量事故的完整链条。

关系显性化：客户-行业-风险等级的约束关系，不是写在某段文本里等 AI 去"理解"的，而是在建模时就定义好的 Link 和 Constraint。当信用额度查询触发时，这些约束是直接可用的，不需要每次从文档中推断。

可执行：Ontology 上的 Action 可以直接触发业务流程。合规检查通过后自动推进审批，风险等级变更后自动触发预警。AI 不只是"回答了问题"，而是"把事情做了"。

代价

本体的建设成本远高于 RAG 和微调。它需要业务建模——把企业的实体、关系、约束、动作从文档和人脑里提取出来，变成结构化定义。它需要数据接入——把散落在不同系统里的数据汇聚到 Ontology 上。它需要持续维护——业务在变，模型就得跟着变。

但这个代价是一次性的结构投资，而不是 RAG 那样每换个场景就要重新调检索策略的持续试错。

五、三条路的交汇——以及为什么大多数企业会走到第三条

三条路不是互斥的，而是分层的：

很多企业的真实演进路径是这样的：RAG 先行，因为最快。半年后发现知识是找到了，但回答总是差点意思——缺上下文、缺关联、缺执行。于是开始往 RAG 里面加东西：加 rerank、加知识图谱、加 Agent 工具调用。加着加着，发现自己在造一个低配版的 Ontology。

这不是偶然的。RAG 的三个结构性盲区——片段化、关系盲区、执行断链——不是靠更好的检索算法能解决的。它们是"把知识当文档"这个底层假设的必然结果。

GraphRAG 是这个方向上最有意义的修正。微软用知识图谱结构增强检索，确实缓解了片段化问题。但 GraphRAG 和 Palantir Ontology 之间有一个关键差异：GraphRAG 的图谱是"描述性"的——它告诉你"什么和什么有关系"；Ontology 的模型是"规范性"的——它定义"这个关系意味着什么约束、触发什么动作"。

描述性的图谱可以帮你更好地检索，但只有规范性的模型才能帮你执行。

六、怎么选：一个简单的决策框架

不需要纠结。问自己三个问题：

第一，你的知识更新频率高吗？

如果高——政策经常变、客户数据每天更新、市场行情实时波动——微调可以直接排除。你不可能每周重新训练一次模型。

反过来，如果你的知识更新频率很低——比如法律条文、行业标准的解释框架、固定的临床诊疗指南——微调是可以考虑的。但要注意，"更新频率低"在企业场景里是个稀有属性。大多数企业知识每天都在变。

第二，你的决策依赖跨实体的关系推理吗？

如果是——"这个客户的信用额度受行业风险等级约束""这批物料的交付时间受供应商产能和物流线路共同影响"——纯 RAG 就不够了。RAG 能找到每个实体的信息，但拼不出实体之间的约束逻辑。

一个简单的判断方法：如果你的业务人员回答问题时，经常需要说"根据XX和YY的情况综合考虑"，那大概率存在关系推理需求。RAG 擅长回答"XX是什么"，不擅长回答"XX和YY放在一起意味着什么"。

第三，你需要 AI 自动执行业务动作吗？

如果是——合规检查通过后自动推进审批、风险变更后自动触发预警——那就必须引入本体。RAG 和微调都停留在"生成文本"的层面，只有本体的 Action 机制能实现从"回答问题"到"执行业务"的跨越。

如果你的需求暂时只到"辅助决策"这一步——AI 给建议，人来拍板和执行——那 RAG 或 RAG + 知识图谱可能就够了。但这个"暂时"往往不会太久。一旦业务方体验到了 AI 的分析能力，下一个问题几乎一定是"能不能直接帮我办了"。

三个组合策略

如果只选一条路，大概率是不够的。更现实的做法是组合：

RAG + 微调：适合"知识更新快、但表达风格稳定"的场景。比如客服——产品信息用 RAG 实时检索，但客服话术用微调对齐。这是目前最成熟的组合，也是部署门槛最低的。

RAG + 本体：适合"知识有结构、需要推理和执行"的场景。比如合规审核——业务规则和实体关系用本体建模，文档资料用 RAG 补充。这是企业 AI 从"聊天工具"进化到"业务系统"的关键组合。如果你的企业正在做穿透式监管、内控体系建设，这个组合尤其值得认真看。

三者结合：适合"既要风格对齐、又要知识实时、还要执行闭环"的场景。比如企业级 Agent——微调负责让 Agent 像你的员工一样说话，RAG 负责补充实时文档信息，本体负责提供结构化的业务知识和可执行的动作。这也是 Palantir AIP 正在走的方向：Ontology 提供业务模型和 Action，AIP 的自然语言界面让用户用对话方式操作这些 Action，微调则让 AIP 的交互风格贴合不同企业的习惯。

一张表总结

三条路，三个层次。大多数企业卡在第一层，不是因为 RAG 不够好，而是因为第一层解决不了第二层和第三层的问题。

选对路的关键，不是看哪条路最火，而是想清楚你的问题到底出在哪一层。