Palantir 的 OAG：AI 找到了文档，但不知道能干什么

栏目：AI 落地观察 · 概念判词
状态：初稿 v1（2026-09-24）

AI 客服翻完了公司的退款政策文档，一字不差地引用了第三条。然后呢？它不知道自己有没有权限发起退款，不知道退款要谁审批，更不知道退完这笔要不要留痕。文档找到了，事情没办成——这不是检索的问题，是 AI 拿到的那份「世界说明书」里只有知识，没有动作。

OAG 解决的不是「AI 找不到知识」，是「AI 不知道自己能对知识做什么」。 这句话是本文的全部，往下是证据。

● ● ●

一个比 ChatGPT 还早两年的词

「OAG」这个词被反复讲成大模型时代的新发明。翻 Palantir 官网会看到另一回事：ontology-augmented generation 的文档页 2021 年 6 月就存在了，比 ChatGPT 早了一年半。那会儿别说企业 AI，连通用 AI 助手都还是科幻。

所以这个词的真实出生顺序是反的：Palantir 先有一套跑了多年的企业本体（Foundry Ontology），2023 年生成式 AI 爆发后，把 LLM 接到本体上，顺手给这套打法起了名。「从 RAG 到 OAG」作为对比叙事，是 2023 年 12 月博客系列才立的框——先有的孩子，后起的名字。

一条时间线上还有两个后来者：2025 年学术界补上了同行评审证据（微软 OG-RAG，EMNLP 2025），2026 年中国企业软件接盘（用友 BIP 6 的 YonOnto，官网 9 月发文标题就是《从 RAG 到 OAG》）。一个概念从造词到补证到东渐，走了五年——比大多数 AI 风口的整个生命周期都长。

OAG 概念五年时间线

● ● ●

OAG 不是「检索更好的 RAG」

RAG 的五类失败在四家互不相干的材料里收敛成了同一张清单（Palantir 工程文、用友官网文、Atlan 行业综述、一个法律检索实验）：

• 时态盲
  ：有效裁决和被推翻裁决的 embedding 几乎相同，余弦相似度都很高——RAG 分不清现行制度和三年前的废案；
• 关系盲
  ：跨三跳的关系（供应商→事故→客户区域）被拆成几份分散文档，LLM 得在上下文里自己拼图；
• 指代盲
  ：文档里的「客户」「甲方」「采购方」是不是同一对象，RAG 靠模型猜；
• 语义无约束
  ：这段内容在业务里代表什么、能不能动、谁能动——完全超出「找文本」的范围;
• 计算不可靠
  ：预测和优化类计算，LLM 本来就不擅长。

前四条都能靠「把知识结构化」缓解。最后一条和整张清单的落点，指向的都是同一件事：OAG 给 AI 的，是一个有结构、有约束、有动作的业务世界模型——检索再花也补不出这个。Palantir 官方把这套东西拆成三件套：

数据工具——LLM 通过本体拿到带类型、带关系、带动作的真实对象（一个真实的物料编号，而不是一坨相似的文本）；

逻辑工具——确定性计算外挂：预测交给 Prophet，路径优化交给优化器，「像教新分析师一样给 LLM 写步骤说明」；

动作与治理——写操作必须过治理校验，关键动作强制人审。

OAG 三件套架构

第三件是分水岭。检索只解决「知道」，动作才解决「能做」。有两句 Palantir 官方文档的原话值得原样记下：一句是「本体不是语义层」——语义层为查询而生，本体为推理与动作而生，理论目标就不一样；另一句是「OAG 降低但不消除幻觉，关键动作强制 human-in-the-loop」——连造词方都不许你写「消灭幻觉」，写了就是假话术。

用友的 YonOnto 是这条思路在中国的第一个公开落点。它的本体建模对象里明确包含「事件、动作」，执行层 YonWork 的流程是：理解意图（身份/权限/本体关系/历史记忆）→ 任务拆解 → 多智能体调度 → 需审批动作转人工 → 结果回写 → 全程记录轨迹与审计。结构和 Palantir 同构。更难得的是那篇官网文里的自限：「简单问答场景未必需要完整本体建设」「生成式 AI 无法保证 100% 准确」——厂商把边界说到这个份上，在中文企业软件文里少见。当然也要记一笔：全文没有客户案例、没有指标、没有第三方评测，方向可信，效果待验。

● ● ●

学术证据：OG-RAG 把本体做进了检索

工程界的故事讲完了，证据呢？微软的 OG-RAG（EMNLP 2025 正刊）是目前最硬的一份。

做法分三步：领域本体（类 + 关系词表）接地；文档事实聚成超图（一条完整事实是一个超边）；查询时抽实体和值，在超图上做贪心覆盖——拟阵约束下可证最优——选出最小超边集，拼成紧凑上下文喂给 LLM。

数字（4 个模型：GPT-4o / 4o-mini / Llama-3.1-8B / 70B；农业专家文档 85 篇 + 新闻 149 篇）：

OG-RAG 五项指标提升

效率侧同样可观：News 语料预处理 655 秒，GraphRAG 同规模要一天以上；查询只比朴素 RAG 慢两秒以内。代码开源（github.com/microsoft/ograg2）。

但论文自己交代的边界比数字更有信息量：农业本体是专有模块生成加专家审校出来的——本体本身仍是人工产物；部分任务上回答相关性反而低于基线，因为检索上下文过宽引入了噪声。还有一个单作者对照实验给出了刺眼的反例：在脏的真实数据上，精心设计的本体没有带来任何提升。理论和数据在这里顶牛，而真实企业语料更接近脏数据那一头。

● ● ●

真瓶颈不在模型，在知识工程

把三线材料叠起来看，OAG 落地慢的原因浮出来了：瓶颈不在算法，在本体工程的人力。

Atlan 的行业综述把话说得很直：「指标定义与本体工程是根本不同的学科」——数据团队普遍不具备本体建模能力，把专家脑子里的隐性知识（怎么判断、怎么决策、什么能碰什么不能碰）一条条挖出来编码成本体，才是 context graph 的真正成本。这解释了为什么 Palantir 的本体要养一整个 Foundry 生态，为什么 OG-RAG 的本体要专家审校，为什么用友要建「设计器/模板/实体消歧/事实融合/质量评分」一整层构建平台。

图是导航层，不是大脑。这句批判线的话应该贴在每个 OAG 项目启动会的墙上。

● ● ●

我用 Rust 写了个最小 OAG

道理讲完，做个东西验一下。我的项目 entia 是个 Rust 本体引擎，上周刚把「动作」这个平面补上——正好凑齐 Palantir 说三件套的最小版本：对象（数据）、公理（逻辑）、动作（actions）。我用它搭了个医疗域的 demo，跑给你看。

场景是 OMOP CDM（医疗数据的标准公共数据模型）的一个子集：患者、就诊、诊断、标准概念，四类对象。两条动作：给诊断打「需复核」标记（纯审计），和把患者纳入研究队列（写库，必须审批）。下面是今天实跑的完整输出，一条没删：

== 5. action: flag-condition (audit-only) ==
✅ logged action 'flag-condition' with 2 arg(s)

== 6. action: enroll-cohort (approval gate) ==
❌ action error: action 'enroll-cohort' requires approval — refusing to execute
gate fired as designed

== 7. gate lifted (clinician approves out-of-band) ==
✅ set 'p1.cohort_status' = String("enrolled")

-- audit trail --
[1] executed — flag-condition (logged action 'flag-condition' with 2 arg(s))
[2] blocked_approval — enroll-cohort (action requires human approval; approve out-of-band and re-run with --approved)
[3] executed — enroll-cohort (set 'p1.cohort_status' = String("enrolled"))

看点在第 2 条：AI（或任何调用方）请求把患者 p1 入组，引擎查了动作声明，发现它带 requires_approval 门，拒绝执行，store 一个字节没动——但这次被拒绝的尝试照样进了审计日志。医生在系统外批准后重放，写入落地，第 3 条记录「executed」。三条审计记录跨进程单调递增，谁在什么时候想动什么、动没动成，全在。

这就是 actions 平面和「检索」的本质区别：检索给 AI 的是「世界长什么样」，动作平面给 AI 的是「你能做什么、做了会留什么」。前者出错顶多是答错话，后者出错是合规事故——后者必须是一门工程，不能是一个 prompt。

这套东西代码稍后开源，demo 在 examples/omop/ 一键可跑。

● ● ●

回到开头

AI 客服的问题现在有答案了：它需要一份「能动什么」的说明书——哪些对象存在、什么关系成立、什么动作可执行、哪个动作要谁批、每次执行留什么痕。文档库再全，也只是这份说明书里最薄的一页。

Palantir 用五年把这个概念做成了工程，学术界刚补上证据，用友们刚开始接盘。对企业来说，接下来要算的账很实在：本体不是买来的，是养出来的——养一个能回答「这个客户能不能动这笔订单」的本体，要挖多深的专家知识、留多少人在长期维护，才是决定 OAG 在你那落不落地的那道题。

你觉得你的业务里，哪类决策最需要先写进「动作」平面？评论区聊聊。