本体论语义建设新思路：另类RAG来解决检索问题
作者：袖梨
2026-07-04
用结构化聚合图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向量化数据存储在ES中，供向量搜索用：
).join(SourceEvent...).where(source_config_id.in_(...))
| ES 索引 | 向量来源 | 用途 |
|---|---|---|
event_vectors | 事件标题、title+content 分别 embed | 事件语义召回 |
entity_vectors | entity.name embed | 实体向量召回（NER 命中后找相似实体） |
event_entity_vectors | EventEntity.description embed | 关联关系检索 |
| 步骤 | 职责 | 存储 | 关键参数 |
|---|---|---|---|
| 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 去重 |
| hop | gold doc 的 query 语义相关性 | 召回方式 |
|---|---|---|
| hop1（query 含实体） | 高 | Step3 向量直接召回 |
| hop2（中间桥梁） | 极低（主题域不交叉） | 只能靠 Step5 图遍历 |
| hop3-4 | 中-高 | 向量 + 图遍历互补 |
Step3 入口窄（k=20，严苛语义筛选）其实相当于，在做向量搜索时用K=20限制了向量召回的数量，把一部分空间留给了用MySQL做精确关联的event。然后再将双搜索召回的event放到一起做rerank。这里做rerank也很有意思，用的LLM，而非简单的reranker。Step7 用 LLM 而非 reranker，是任务定义不同
↓
Step5 多跳注入（绕过相似度，图可达性注入）
↓
Step6 缓冲池宽（max=100，5倍冗余给注入doc留存活空间）
↓
Step7 LLM 不看分数（候选池内一律平等，靠推理选）
| 方面 | 传统 reranker | SAG Step7 |
|---|---|---|
| 任务 | query-doc 语义匹配度 | doc 对多跳推理链的贡献度 |
| 能力 | 相似度打分 | 理解 "First find X, then find Y" |
| 成本 | 毫秒级 | 秒级（万 token 量级） |
#）定义 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 |
为每张表建立一个wiki，详细的描写表的内容、业务含义、适用场景、可能的关联关系等；
这个wiki作为一个chunk，提取其event和entity，入MySQL和ES；
按照cube的标准，定义关联字段、视图等；
使用SAG的检索流程，进行相关表检索；
综合表、wiki、cube定义，生成一个/多个SQL语句，进行查询和聚合，并且生成答案。
用户 query但是在工程实践中，还有很多落地的方面需要进行处理，比如多个表的同义entity如何保证，如果分解query需求，解答用户或者其它系统问题时是否采用ReAct模型多步检索等等。
↓
查询意图分类（LLM）
├── 明细查询 → SAG 检索（召回行）
├── 聚合查询 → CubeSQL（生成 SQL）
└── 混合查询 → SAG 召回 + SQL 聚合
登录查看剩余 70% 内容
