RAG、LLM Wiki与 Ontology：三种架构，各管一段

先把结论摆出来：LLM Wiki、RAG、Ontology 不是三选一的关系，它们是三种处理知识的方式，各自擅长一段。选型的真正分界线是三个朴素问题：知识是文档还是事务？你要的是洞察还是动作？知识多久变一次？

RAG 不是被替代的对象，它是这套组合里不可缺的一块。下面把三者放在一起说清楚。

三种架构，本质是"什么时候干活"的差别

先看 RAG 和 LLM Wiki。这两者最本质的区别，在于什么时候干活。

RAG 是典型的"查询时做功"。文档进来的时候，它只做最机械的活——切片、向量化，往库里一扔。真正的理解、推理、归纳，全等到用户提问那一刻才发生。同一个问题问 100 次，系统就得重复 100 遍"检索-拼接-推理"，算力成本跟着提问次数往上涨。更尴尬的是，它不长记性——第 100 次回答的质量，和第 1 次一模一样。

LLM Wiki 把这套逻辑翻了过来：摄入时就编译。文档一进来，大模型先通读一遍，做语义理解、提炼要点、分类归档，生成结构化的 Wiki 页面，主题单独成页，页面之间建好内链。用户提问时，直接定位到对应页面读现成的。新资料进来不是简单加几个向量，而是可能更新好几个已有页面、补上新关联、标出前后矛盾——知识一点点攒起来，越用越厚。

Ontology 干的是第三件事。如果说 RAG 管"找到相关段落"、LLM Wiki 管"沉淀综合知识"，那 Ontology 管的是业务世界的语义和动作。它不只定义业务对象，还定义这些对象之间的逻辑、状态怎么流转、能执行什么动作。它通常分三层：语义层定义对象、属性和关系；数据流转层定义操作、动作和流程；智能决策层定义规则、权限和模型怎么绑定。

三种架构，一个管即时检索，一个管知识沉淀，一个管业务执行。它们处理的是不同层面的问题，不是同一条赛道上的竞争对手。

各自的适用边界

把三者放进同一张表，各自的站位很清楚：

• LLM Wiki 占左下角：知识相对稳定、只需洞察归纳。它的"一次编译、多次复用"在这里最能发挥成本优势。

• RAG 占右下角：知识多变、查询长尾。它每次临时拼凑是"笨"，但胜在灵活、可追溯、更新即时，知识一天变三回也不怕。

• Ontology 管的是"要执行动作"这一整行——不管知识稳不稳定，只要需要执行动作，它都是底座。它不挑知识变不变，只挑你要不要动作。

这个站位说明了一件事：Ontology 的适用面最宽，RAG 最灵活，LLM Wiki 最挑场景。三者不是谁替代谁，是不同抽象层级的互补件。

三个容易说满的地方

第一，"LLM Wiki 比 RAG 更省 Token"是有前提的。 知识稳定、查询高频时确实省。但知识要是一天变三回，编译成本反复发生，反而可能比按需检索的 RAG 更贵。而且 Wiki 编译质量高度依赖大模型的归纳能力，信息损耗、错误固化都是真实风险。RAG 的灵活、可追溯、更新即时，正是它不可被替代的理由。跨论文综合任务上 LLM Wiki 确实赢单轮 RAG，但在逐条声明的引用支持上，RAG 的分解-检索变体把差距缩小了不少。两者是各有主场，不是一边倒。

第二，"Ontology 消除幻觉"这话太满了。 它确实能约束大模型的输出空间、把幻觉概率压下去，但"消除"做不到。本体建模有遗漏、映射有错，或者自然语言转本体查询那一环出岔子，照样出问题。可追溯性也取决于工程实现，不是本体一建就自动带上。Palantir 自己在 Foundry 里的说法就很克制：AI 不读"原始的、杂乱的"数据，只读严格定义好的"名词"和"动词"，幻觉和上下文污染被"限制到最低"——是限制到最低，不是消除。

第三，场景归属不是二选一。 科研机构也要做项目管理、实验流程自动化，Ontology 照样有用；企业也要做竞争情报、法规解读，LLM Wiki 照样有价值；而几乎所有场景都会遇到长尾查询，RAG 总有用武之地。真正的分界线是知识形态、输出类型、变化频率这三个维度的组合。

真到企业里，三者得搭着用

大型企业级应用里，这三种架构正在往一块儿走。合理的分工是：

RAG 负责精准召回。 它是那层"随时能查"的灵活检索，应对长尾、多变、临时的查询需求。知识一天变三回，RAG 也不怕，因为它的理解发生在查询那一刻。

LLM Wiki 负责知识沉淀。 把每次阅读和分析的成果固化下来，让稳定的、高频的知识不用反复推理，一次编译、多次复用，知识越攒越厚。

Ontology 负责业务底座。 定义业务世界里的实体、关系和约束，让 AI 在明确的规则下参与决策和执行。

具体怎么搭？企业的数据仓库、业务数据库、上万份文档、几百个 API，不需要全塞进 Wiki。订单流水还在数据库里，实时库存还归业务系统管。知识库保存的是这些数据的语义抽象、使用规则和来源指针——这张表代表什么、字段按什么口径算、实体之间怎么关联、哪个工具能查、结果有没有权限限制。RAG 在这之上做精准召回，LLM Wiki 把高频稳定的部分编译固化，Ontology 兜住业务规则和动作。

Gartner 的分析也指向同一个方向。Google Cloud Next 2026 传出来的核心信号是：Agent 失败往往不是模型不行，而是数据上下文差、语义不一致、集成太脆。企业在语义治理和元数据管理上的投入，得跟工具投入一样重。治理跟不上，Agent 扩展生产力的速度，还赶不上它扩展歧义和不信任的速度。

一句话收尾

RAG、LLM Wiki、Ontology 三者，一个管即时检索，一个管知识沉淀，一个管业务执行。

• RAG 适合知识多变、查询长尾的场景，价值在于灵活、即时、可追溯，是那层随时能查的兜底检索。

• LLM Wiki 适合知识稳定、要深度综合和复用的场景，价值在于把知识处理的成本从查询时挪到摄入时，让知识真正攒得起来。

• Ontology 适合业务逻辑复杂、要跨系统协同和自动执行的场景，价值在于搭起统一的业务语义层，让 AI 在明确规则约束下参与决策和执行。

选型别看行业，看这三样：知识更新频率、输出是洞察还是动作、合规要求有多硬。未来的主流打法是三者结合——RAG 负责精准召回，LLM Wiki 沉淀非结构化文档知识，Ontology 搭核心业务的规则底座，拼出一个既懂知识又懂业务的 AI 系统。