本体论语义建设新思路：另类RAG来解决检索问题

时间：2026-07-04 08:46:53 编辑：袖梨来源：一聚教程网

用结构化聚合图SAG解决本体论语义建设难题，实现多跳问答精准检索。
核心内容：
1. SAG将RAG思想应用于本体论，建立轻量索引
2. 通过事件、实体、关系三重结构弥补向量检索不足
3. 结合MySQL精确查询与ES向量搜索，优化多跳问答性能

有没有想过一个问题，本体论有一半的篇幅在讨论如何定义标准数据和数据间的关系，之所以要这么做，就是需要为所有的分析和Action提供精准的上下文。所以，这实质上是一个高纬度的RAG问题。只不过普通RAG搜索的目标大多包含大量的文本对象，而Ontology操作的目标倾向于数据库对象。这就意味着，我们可以参照为RAG设计的系统实现来设计Ontology的数据层面。比如，这次介绍的SAG(Structured Aggregated Graph)就是一个很好的参考。

在回答复杂问题时，通过向量匹配搜索出来的chunk往往是不够的，因为有很多隐含条件并没有体现在字面上，所以我们需要relation来进行关联查找字面上没有的实体。SAG通过relation和向量结合的方式进行召回和rerank，在多跳问答的数据集验证里取得了炸裂的成绩。核心是，不维护重型知识图谱，而是建立三种轻量索引（chunk → event、event ↔ entities、chunk → entities），用"双存储协同 + 多跳扩展"弥补单靠向量检索无法覆盖的多跳场景。

索引方式SAG将一个chunk拆成了三个部分：事件、实体和关系。事件是对chunk的摘要，实体是从事件中提取出的主体，关系则是事件与实体间建立的联系。

对于每一个chunk，让LLM提取事件和实体，并且建立联系。

这就类似于一个图，两个事件之间如果存在相同的实体，这两个事件便产生了关联。

进行索引的是一个五步流程：

chunks → processor(LLM调用) → filter(过滤) → parser(解析) → saver(持久化)

每个 chunk 经一次 LLM 调用，融合成恰好一个自包含事件 + 若干实体。这与传统"一句一三元组"完全不同。对chunk的提取产生了两大种类的成果，结构化数据和向量化数据。

MySQL: 通过event和entity的id进行关联，负责精确关系遍历，用于Step3 通道1（entity→event）、Step5 多跳扩展、Step8 chunk 回溯；

ES: 存储event向量，负责模糊语义召回 + 打分，用于Step2 实体召回、Step3 通道2、Step6 粗排。

结构化数据存储在MySQL中，通过id记录了event/entity之间的关系，可以通过entity_id进行精确的关联查询：

stmt = select(EventEntity.event_id).where(EventEntity.entity_id.in_(entity_ids)   # 精确 JOIN
).join(SourceEvent...).where(source_config_id.in_(...))

向量化数据存储在ES中，供向量搜索用：

ES 索引	向量来源	用途
`event_vectors`	事件标题、`title+content` 分别 embed	事件语义召回
`entity_vectors`	`entity.name` embed	实体向量召回（NER 命中后找相似实体）
`event_entity_vectors`	`EventEntity.description` embed	关联关系检索

检索：8 步pipline的逐层职责

步骤	职责	存储	关键参数
Step1 NER	query → 实体名	LLM（multi）/ BM25（multi_es）	—
Step2 实体召回	实体名 → entity_ids	ES `entity_vectors`	top_k=20, 阈值 0.9
Step3 双通道召回	召回初始事件	MySQL JOIN + ES kNN	k=20（入口窄）
Step4 事件详情	取 content + 关联 entities	MySQL / ES	—
Step5 多跳扩展	沿实体图遍历补全桥梁 doc	MySQL JOIN / ES 反查	max_hops=1（默认）
Step6 粗排	向量相似度去噪打分	ES kNN	max_events=100（5倍冗余）
Step7 LLM 精选	多跳推理选 top_k	LLM	top_k=5/10，不看分数
Step8 chunk 回溯	event → 原始 chunk	MySQL	chunk_id 去重

多跳扩展解决"语义断裂"问题多跳问答里，答案 doc 与 query 可能语义不相关（query 里没有答案实体的字面）。纯向量检索召回不到这类 doc。Step5 多跳扩展沿 entity↔event 关系图遍历，把"图可达但语义远"的 doc 拉进候选池。

基于真实 MuSiQue 4 跳样本的验证：

hop	gold doc 的 query 语义相关性	召回方式
hop1（query 含实体）	高	Step3 向量直接召回
hop2（中间桥梁）	极低（主题域不交叉）	只能靠 Step5 图遍历
hop3-4	中-高	向量 + 图遍历互补

Step3（k=20）与 Step6（max=100）的 5 倍冗余

Step3 入口窄（k=20，严苛语义筛选）
    ↓
Step5 多跳注入（绕过相似度，图可达性注入）
    ↓
Step6 缓冲池宽（max=100，5倍冗余给注入doc留存活空间）
    ↓
Step7 LLM 不看分数（候选池内一律平等，靠推理选）

其实相当于，在做向量搜索时用K=20限制了向量召回的数量，把一部分空间留给了用MySQL做精确关联的event。然后再将双搜索召回的event放到一起做rerank。

这里做rerank也很有意思，用的LLM，而非简单的reranker。

Step7 用 LLM 而非 reranker，是任务定义不同

方面	传统 reranker	SAG Step7
任务	query-doc 语义匹配度	doc 对多跳推理链的贡献度
能力	相似度打分	理解 "First find X, then find Y"
成本	毫秒级	秒级（万 token 量级）

Reranker 无法识别"跟 query 不像但是推理链必经桥梁"的 doc，LLM 能。简单的说，就是把这100条召回的event依次再让LLM判断一遍，哪个event对回答问题更有作用。当然，也提供了fast 模式（multi_es）用数值公式替代 LLM，用来节约时间和成本。

在RAG上存在的问题文档格式强依赖SAG 的 Load 模块只接受 markdown，且 heading_strict 切分强依赖 ATX 风格标题（#）定义 chunk 边界。无标题、非 markdown 格式（PDF/Word/HTML）会致命。甚至可以说，SAG的Load就只能处理结构清晰的数据，否则很容易GG。

benchmark 数据集 corpus 是干净的（title/text 齐全），回避了生产场景的格式预处理问题。真实部署需要额外的格式转换层。

图遍历与向量打分的固有张力多跳扩展靠图可达性召回，Step6 靠向量相似度排序——这两者之间可能根本不相关。深跳（3-4 跳）的答案可能在向量上几乎不相关，于是在 Step6 被 100 名截断淘汰的可能性也大。这是 SAG 架构的固有代价，也是 MuSiQue（48% 是 3-4 跳）比 HotpotQA 更难的根本原因。

只说三件事：成本、成本，还**是成本抽取和检索数据时都需要调用LLM，产生的成本是普通RAG的数倍。

阶段	每次 input token 量级
抽取	每个 chunk ~500-2000 token + system prompt + few-shot
检索	NER 较小；rerank 100 候选 × ~200 token = ~20000 token

基于SAG的语义层？如果我们用图数据库来定义本体间关系，常见的就是将两张表定义为两个本体，然后用某种关系相连接。但是，在两个本体间可能有多种关联关系。

从数据上，可能有外键进行关联；从其它方面，可能会有某些维度字段进行关联，比如城市、商品类目。正常情况下，使用图数据库建模都不建议在两个节点中直接定义多个关系，要么通过造出中间节点进行处理，要么通过专门的查询条件避免笛卡尔积。

而参考SAG的构建方式，每条数据我们认为是一个chunk/event，关联字段是SAG中的实体，那么就可以自然的建立多种关系。

但是！注意我们不能采用LLM来处理数仓中的每一行数据，那样token的费用可能比整个数据团队的工资还高。

经过取舍和测试，我推荐一种结合wiki和cube的方式进行多层结构混合存储与检索，描述如下：

为每张表建立一个wiki，详细的描写表的内容、业务含义、适用场景、可能的关联关系等；
这个wiki作为一个chunk，提取其event和entity，入MySQL和ES；
按照cube的标准，定义关联字段、视图等；
使用SAG的检索流程，进行相关表检索；
综合表、wiki、cube定义，生成一个/多个SQL语句，进行查询和聚合，并且生成答案。

简答的是说，就是：

用户 query
    ↓
查询意图分类（LLM）
    ├── 明细查询 → SAG 检索（召回行）
    ├── 聚合查询 → CubeSQL（生成 SQL）
    └── 混合查询 → SAG 召回 + SQL 聚合

但是在工程实践中，还有很多落地的方面需要进行处理，比如多个表的同义entity如何保证，如果分解query需求，解答用户或者其它系统问题时是否采用ReAct模型多步检索等等。

登录查看剩余 70% 内容

推荐专题

最新下载

热门教程

本体论语义建设新思路：另类RAG来解决检索问题

相关文章

热门栏目

php教程

asp.net教程

手机开发

css教程

网页制作

办公数码

jsp教程