有没有想过一个问题，本体论有一半的篇幅在讨论如何定义标准数据和数据间的关系，之所以要这么做，就是需要为所有的分析和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模型多步检索等等。
粤ICP备14082021号
免费POC，
零成本试错
