循序渐进 · 教学 · 本体增强生成 Ontology-Augmented Generation

不止 RAG：把「本体对象」喂给大模型

本体增强生成（Ontology-Augmented Generation, OAG）讲的不是怎么调 LLM，而是怎么把最相关的业务上下文找出来、再喂给它。这一篇梳理从基础语义搜索到进阶检索（HyDE、关键词排名、混合搜索）的整套打法。

全部目录 ← 上一篇本体增强生成下一篇 →

原文 Ontology augmented generation 预计阅读 12 分钟 含 互动演示 + 6 道测验

本文来源 · Source 内容整理自 Palantir Foundry 官方文档：
https://www.palantir.com/docs/foundry/ontology/ontology-augmented-generation/
原始标题：Ontology augmented generation

★

一句话速览

不止 RAG：把「本体对象」喂给大模型：本体增强生成（Ontology-Augmented Generation, OAG）讲的不是怎么调 LLM，而是怎么把最相关的业务上下文找出来、再喂给它。

1 这一篇在讲什么

大语言模型（LLM）一旦配上业务专属上下文，威力巨大

2 真的还需要检索吗

原文给了一个常被忽略的提醒：随着新一代模型上下文长度变长，你可能根本不需要语义搜索，而是直接把完整上下文塞进 prompt

3 四步走

原文给出的「基础语义搜索」落地步骤很朴素

4 四种提效手段

原文观察到：如果你的 AIP 工具答不出本该在语料里找到的问题，多半是「检索」这步没把最相关上下文捞上来

这一篇在讲什么？

OAG 的核心难题不是「生成」，而是「找到对的上下文」。

大语言模型（LLM）一旦配上业务专属上下文，威力巨大。但原文一开篇就指出：面对一个任务， 第一步几乎总是找到该交给 LLM 的相关上下文——而这一步，往往是设计检索增强生成（Retrieval-Augmented Generation, RAG）系统里最难的部分。

Finding the relevant context is often the most challenging part of designing a retrieval augmented generation system. 找到相关的上下文，往往是设计检索增强生成系统里最具挑战性的一步。

这一篇给出若干「上下文检索」的常见思路。原文特别强调：没有唯一的最优解，最佳方案高度依赖你的数据特点；但下面这些主题是个不错的起点，可以按需组合、裁剪。

为什么放在「本体」系列里：OAG 的「对象」指的就是本体（Ontology）里的对象类型（object type）与属性—— 把检索结果挂到对象上，工作流才能直接用。这正是前面几篇铺垫的闭环。

先问一句：真的还需要检索吗？

上下文够短，直接整段塞进 prompt 反而更简单。

原文给了一个常被忽略的提醒：随着新一代模型上下文长度变长，你可能根本不需要语义搜索，而是直接把完整上下文塞进 prompt。

With new model generations' increased context lengths, you may not need to use semantic search at all and can instead pass the full context in the prompt. For example, GPT-4o's 128k context window corresponds to 300+ pages of text. 随着新一代模型上下文长度增加，你可能完全不需要语义搜索，而可以直接把完整上下文放进 prompt。例如 GPT-4o 的 128k 上下文窗口相当于 300 多页文本。

所以原文的实用建议是：如果你的应用的完整上下文落在窗口上限之内，优先从「不搜索」开始。只有当内容多到放不下、或需要精准定位某段时，才引入语义搜索与下面的进阶技巧。

基础语义搜索：四步走

分块 → 建带媒体引用的对象 → 做语义搜索 → Workshop 里看 PDF。

原文给出的「基础语义搜索」落地步骤很朴素：

步骤 1定一个分块（chunking）策略
把长文档切成合适的块
块太长会超出模型 token 限制；块太碎又会丢上下文。分块策略直接决定下游检索质量（呼应文档处理那一篇）。
步骤 2建 chunk 对象，带 media reference 属性
每个块对应一个本体对象，并挂上媒体引用
用 media reference（媒体引用）属性，让 chunk 能回溯到原始 PDF 的对应位置——方便后面在 PDF Viewer 里高亮。
步骤 3作为语义搜索工作流的一部分去检索 chunk
把 chunk 接入语义搜索
具体怎么生成嵌入、怎么写检索函数，留给本系列后面的「用官方模型 / 自定义模型做语义搜索」两篇展开。

步骤 4：在 Workshop 里使用 PDF Viewer 组件，并配置好相应选项，让检索结果能直接定位到原文。

进阶检索：四种提效手段

当基础方案答不上来时，从这四个里挑着加。

原文观察到：如果你的 AIP 工具答不出本该在语料里找到的问题，多半是「检索」这步没把最相关上下文捞上来。可选手段有四种：

手段	解决什么
HyDE 假设文档嵌入	不直嵌查询，而是先让 LLM 生成一段「假设答案」，再嵌入它——结构上更接近真答案，检索更准。
关键词排名搜索 Ranked keyword	领域语料上通用嵌入模型常水土不服；用 Object Storage v2 自带的「相关性」做排名搜索更稳。
查询增强 Query augmentation	把用户问题交给 LLM 预处理：去掉停用词、补同义词（enriching），或抽取核心诉求（extraction）。
混合搜索 Hybrid search	用 RRF（倒数排名融合）把「向量搜索」与「关键词搜索」的结果融合成一张列表。

HyDE 长什么样？

原文举例：用户问「如何处理动物碰撞（animal collisions）理赔？」先让 LLM 产出一段假设章节，例如：

Animal Claims Management: General Terms: Animal collision is commonly insured in fully comprehensive packages...

因为这段「假设答案」在结构上已经离真答案很近，它的嵌入也就更接近真正包含答案的那个 chunk—— 于是语义搜索命中率更高。代码上，就是「先 GPT_4o.createChatCompletion 生成假设段，再 TextEmbeddingAda_002.createEmbeddings 嵌入，最后做 nearestNeighbors」。

RRF 怎么融合两个列表？

RRFscore(d) = Σ 1 / (k + r(d)) k 是正则项：k 越大，文档「出现在列表里」比「排第几」更重要。 r(d) 是文档在某列表中的排名。把多列得分相加即为总得分。

动手演示：一次提问背后检索了哪些对象

选一个问题，逐步展开 OAG 的检索流水线。

下面把「一次提问 → 拿到答案」拆成几步。点一个问题，再点「下一步」，看每一步背后到底在动哪些对象、做什么事。这正对应原文说的——难点在检索，不在生成。

动手试试 · 提问背后的检索流水线

选一个问题，看 OAG 背后分几步检索并组装上下文。

说明：这是教学化的流水线示意（真实代码见原文 HyDE / 混合搜索示例）。重点是体会「检索相关对象 → 组装上下文 → 生成」这条主线。

该从哪开始？原文的建议

先跑通基础版，缺什么补什么，别一上来就全上。

面对这么多手段，原文的态度很务实：

Our recommendation would be to start with the basic implementation, and then add features as it becomes necessary. 我们的建议是先做基础版本，然后在确有必要时再加功能。

先从基础四步跑通一个能用的搜索。
如果发现答不出本该能答的问题，先排查「检索」是否漏掉了相关上下文。
再按需叠加：比如只加 HyDE + 语义分块就够，其余先不动。
领域语料水土不服时，先用关键词排名搜索（简单、开箱即用），再考虑微调自定义模型。

对应到本系列：基础四步用到的「生成嵌入 / 写检索函数」会在下两篇（官方模型、自定义模型做语义搜索）具体落地；这里你只需先建立「检索是难点、按需叠加」的大局观。

一页带走

① 难点在检索

OAG 的核心是把最相关上下文找出来，再喂给 LLM。

② 够短就不搜

上下文放得进窗口（如 128k≈300+页），优先直塞 prompt。

③ 四步打底

分块→带媒体引用的对象→语义检索→PDF Viewer。

④ 按需叠加

HyDE/关键词排名/查询增强/混合搜索，缺啥补啥。

延伸阅读 · 相关页面

按主题横向跳转，不必顺着目录一篇篇读。

常见问题速答 · FAQ

关于「不止 RAG：把「本体对象」喂给大模型」，读者最常问的几个问题。

这一篇在讲什么？

大语言模型（LLM）一旦配上业务专属上下文，威力巨大。但原文一开篇就指出：面对一个任务，第一步几乎总是找到该交给 LLM 的相关上下文——而这一步，往往是设计检索增强生成（Retrieval-Augmented Generation, RAG）系统里最难的部分…

先问一句：真的还需要检索吗？

原文给了一个常被忽略的提醒：随着新一代模型上下文长度变长，你可能根本不需要语义搜索，而是直接把完整上下文塞进 prompt。

基础语义搜索：四步走是什么？

原文给出的「基础语义搜索」落地步骤很朴素。

进阶检索：四种提效手段是什么？

原文观察到：如果你的 AIP 工具答不出本该在语料里找到的问题，多半是「检索」这步没把最相关上下文捞上来。可选手段有四种。

全部目录 ← 上一篇：多模态与嵌入下一篇：用官方模型做语义搜索 →