【图数据库内核】选型与 GraphRAG 接口：边语义分级，何时必须原生图

本系列从邻接代价走到 store、expand、锁与排障。收束只回答两件事：什么时候值得上原生图引擎；GraphRAG / 向量检索要的「图」是不是同一种边。检索管线、社区检测与 prompt 工程已在 db-frontier GraphRAG 与 llm-infra RAG；本篇只钉存储与一致性接口。

本文是「图数据库内核」系列第 16 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 14–15 篇 · 对照 / 排障	地图与 runbook
第 16 篇 · 选型与接口	决策树 + 边语义分级

版本与分工：机制回指本系列 01–15（Neo4j Ops/Cypher Manual 锚定见各篇）。GraphRAG 动机与管线以站内 db-frontier 文为准，并回指 Edge et al., arXiv:2404.16130（预印本，作问题定义非性能排名）。不写 Aura 定价、不写跨引擎延迟榜。

一、系列已经钉死的命题（选型前提）

选型前先承认这些不变量，避免用营销句覆盖机制：

1. 代价中心是边的局部性，不是「点的个数」口号（第 02 篇）。
2. 索引找起点，expand 付拓扑账；二者乘积是经典事故（第 07、09–10 篇）。
3. dense / 超节点改写 I/O 与锁；引擎缓解 ≠ 建模免责（第 04–06、11、15 篇）。
4. 默认隔离多为 RC 一类故事；集群 bookmark 解决的是跨副本可见，不是把隔离升成 Serializable（第 11–12 篇）。
5. 全文/向量是旁路（常 Lucene + OS 缓存），不是第二套邻接（第 08 篇）。
6. 外置图层 / 四元组 / PG 表映射 / MPP 原生是分叉，不是同一 store 的皮肤（第 13–14 篇）。

若业务问题能在边表 + 浅递归 CTE 的 \(\mathrm{Cost}_{\mathrm{edge}}\) 内闭环，不上图引擎是合法答案。

二、何时必须（或强烈倾向）原生图

用决策树收束第 14 篇排除法。这里的「原生图」指：邻接为一等布局、运维面主要在图引擎内（Neo4j store、TigerGraph GSE、Memgraph 内存图等），对照 AGE/边表/JanusGraph 图层。

flowchart TD
  Start["多跳或关系谓词是一等负载？"] -->|否| VecSQL["向量 / SQL / 文档检索即可<br/>见 llm-infra / vector-engine"]
  Start -->|是| Deep{"跳数与扇出是否经常让 JOIN/CTE 痛？"}
  Deep -->|否或不确定| Pilot["先 AGE 或边表试点<br/>用第 02/15 篇计量"]
  Deep -->|是| Tx{"边更新需要引擎内事务<br/>与审计级不变量？"}
  Tx -->|弱 / 可重建| Soft["抽取图可批处理重建<br/>GraphRAG 索引图也可"]
  Tx -->|强| Native["倾向原生图引擎"]
  Soft --> Ops{"已有宽表集群且愿付 RPC？"}
  Ops -->|是| JG["JanusGraph 图层可论证"]
  Ops -->|否| Native2["仍倾向原生或托管图"]
  Native --> Lang{"主负载是选择性 OLTP<br/>还是全图迭代分析？"}
  Lang -->|OLTP 多跳| Neoish["Neo4j 族 / 托管同类"]
  Lang -->|BSP 全局迭代| TG["TigerGraph 等 MPP 叙事"]
  Pilot -->|试点失败| Native

2.1 倾向原生图的充要组合（工程判断）

同时满足越多，越难用「Postgres 顶住」糊弄：

2.2 可以先不上原生图的情形

「必须」的硬标准：不是品牌，而是失败模式——CTE/JOIN 已证明尾延迟或正确性（事务边）不可接受，且图层的远程常数不可接受。

三、GraphRAG 接口：边语义分级

站内 GraphRAG 文指出：向量相似度是语义邻近，多跳需要结构可达；图提供 evidence path，且自动抽取图不追求 Schema 级严谨。这与本系列「生产属性图 + 事务边」不是同一约束集。选型错误常来自把二者捆成一种存储。

3.1 四级边（建议显式标注）

GraphRAG 默认产出大量 L0–L1。把 L0 边写进 L3 集群、或反过来用向量库冒充 L3 权限边，都会在排障时表现为「随机错误」而非单纯慢查询。

3.2 推荐拼法（接口契约）

flowchart LR
  Docs["语料 / Chunks"] --> Emb["Embedding"]
  Docs --> Extract["LLM 抽取 L0/L1"]
  Emb --> Vec["向量引擎 / Lucene VECTOR"]
  Extract --> Gidx["图索引存储"]
  Biz["业务系统"] --> Gbiz["L2/L3 图或约束表"]
  Q["在线 Query"] --> Vec
  Q --> Gidx
  Q --> Gbiz
  Vec --> Ctx["Context 组装"]
  Gidx --> Ctx
  Gbiz --> Ctx
  Ctx --> LLM["生成 + 引用"]

契约句：

1. 向量召回回答「语义近」；图 expand 回答「结构可达」——分数不可横比硬加（第 08 篇）。
2. Local Search 式「实体 → \(k\)-hop → chunk」：hop 落在 Gidx/Gbiz 的哪一层，决定要不要 bookmark、要不要事务快照。
3. Global / 社区报告：计算偏分析；宜与 L3 写路径隔离（批作业、只读副本、或独立分析库），避免第 10 篇式行流打爆 OLTP heap。
4. 实体对齐（canonicalization）失败是 GraphRAG 上限问题（db-frontier）；图引擎不能用「加 page cache」修复错边。

3.3 「GraphRAG 是否需要强一致图库？」

本系列立场：按边分级，不一刀切。这与第 01 篇开放争论表一致。

四、和站内系列如何接线

反接线：不要在 GraphRAG 文里期待 block 格式细节；不要在本系列里期待 Ragas 评估曲线。

五、产品族速选（仍非延迟排名）

在第 14 篇五轴表之上，用「默认假设」帮读者落点：

选定后立刻做第 15 篇的一次真实慢查询归因（或 CTE 基线），再决定是否迁移——避免「先买图库再找负载」。

六、开放问题（系列级）

1. GQL 与存储分叉：查询表面收敛后，邻接是否一等布局仍会分裂产品。
2. 向量边与拓扑边的统一索引：多模态库愿景（db-frontier）与 Lucene 旁路现实之间，事务快照如何定义仍开放。
3. 抽取图的增量社区检测：索引新鲜度与 Leiden 级全局重算的矛盾，会倒逼 L1 存储选「易重建」而非「强一致」。
4. 幂律上的基数估计：计划层系统偏差未消；选型期的 POC 必须带真实度数分布，不能只用玩具图。

谱系收束：Angles & Gutierrez 把图模型从关系旁路出来；工业原生图把邻接写进磁盘格式；GraphRAG（Edge et al.）又把图拉回检索系统当 evidence path。三条线交汇处的工程问题不是「要不要图」，而是哪一种边、哪一种一致、哪一种 hop 预算。

七、来源与实验台账（本篇）

八、小结（系列收束）

1. 原生图在「深多跳 × 邻接局部性 × 事务边」重合时最有说服力；否则 AGE/边表/图层/向量是正经选项。
2. GraphRAG 的边多为 L0–L1；L3 权限/审计边不要默认塞进可脏抽取图，也不要用 ANN 替代。
3. 接口：向量管语义，图管可达；生成层融合两种证据；排障用第 15 篇三轴。
4. 最小复习路径：01 → 02 → 03 → 04 → 05 → 09 → 16；深挖再补 06–08、10–15、13–14。

→ 系列目录 · 上一篇：生产排障 · 返回数据库索引