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

用结构化聚合图SAG解决本体论语义建设难题，实现多跳问答精准检索。

核心内容：
SAG将RAG思想应用于本体论，建立轻量索引
通过事件、实体、关系三重结构弥补向量检索不足
结合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之间的关系，可以通过entityid进行精确的关联查询：stmt = select(EventEntity.eventid).where(EventEntity.entityid.in(entity_ids) # 精确 JOIN

).join(SourceEvent…).where(sourceconfigid.in_(…))
向量化数据存储在ES中，供向量搜索用：

检索：8 步pipline的逐层职责

多跳扩展解决"语义断裂"问题

多跳问答里，答案 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% 内容](javascript:void (0);)

rag技术rag技术框架rag技术实现

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