【图数据库内核】选型与 GraphRAG 接口：边语义分级，何时必须原生图
内容提要
本文总结图数据库选型与接口设计：何时用原生图引擎、GraphRAG边语义分级（L0-L3）及存储建议。核心观点：深多跳、邻接局部性、事务边场景倾向原生图；GraphRAG边多为可重建的L0-L1，权限审计边需强一致存储。向量管语义，图管可达，按边分级选型，避免一刀切。
延伸解读
边语义分级：避免“随机错误”的关键
文章提出将图边按语义分为L0到L3四级，从可错可漏的检索边到强一致的审计/权限边。GraphRAG默认产出大量L0-L1边，若误将L0边写入L3集群，或反之用向量库冒充L3权限边，排障时会出现“随机错误”而非单纯慢查询。这提醒选型时需显式标注边的级别，匹配存储与一致性要求。
原生图引擎的适用条件：深多跳×邻接局部性×事务边
文章强调，原生图引擎并非万能，其优势集中在“深多跳、邻接局部性、事务边”三者重合的场景。若跳数浅、度数受控或SQL生态沉没成本高，边表+递归CTE或Apache AGE即可满足。选型应基于失败模式（如CTE/JOIN尾延迟不可接受）而非品牌偏好，避免“先买图库再找负载”。
GraphRAG接口契约：向量管语义，图管可达
文章指出，向量召回回答“语义近”，图expand回答“结构可达”，两者分数不可横比硬加。Local Search的hop落在哪一层决定是否需要bookmark或事务快照；Global/社区报告宜与L3写路径隔离。多数文档问答无需强一致图库，向量+L0/L1足够；答案依赖L2/L3时才需强一致，混合场景可双库融合。
Q&A
什么时候应该选择原生图数据库而不是关系数据库或图图层？
当在线路径需要2-3跳以上且扇出不可忽略、热查询依赖邻接局部性、边是业务不变量需要事务语义、团队需要Cypher/GSQL且存储同栈排障时，倾向原生图。若跳数浅、度数受控、SQL生态沉没成本高，或图主要服务RAG离线索引可脏可重建，则可不上原生图。
GraphRAG中的边语义分级L0-L3分别代表什么？
L0是检索边，如LLM抽取的共现关系，可错可漏，最终一致，适合向量库旁路；L1是索引边，如GraphRAG社区/报告依赖的拓扑，索引延迟分钟到小时，适合轻量图库或只读副本；L2是业务拓扑边，如产品关系，需要OLTP，适合原生图或AGE；L3是审计/权限边，需要强提交语义，适合原生图或成熟RDBMS约束表。
GraphRAG是否一定需要强一致图库？
不一定。多数文档问答不需要，向量+L0/L1足够；当答案依赖L2/L3业务边时则需要；混合场景可双库或双图，查询时应用层融合。
向量检索和图数据库在GraphRAG中分别扮演什么角色？
向量检索回答语义相近的问题，图数据库回答结构可达的问题，两者分数不可横比硬加。生成层融合两种证据。
如何根据业务场景选择具体的图数据库产品？
若需深挖页、指针、Cypher计划选Neo4j；需Gremlin可移植且已有宽表选JanusGraph；需GSQL/全图迭代选TigerGraph；必须进Postgres选AGE/边表；云托管少碰盘选Neptune；内存优先选Memgraph。
GraphRAG中Local Search的hop落在不同层级时，对事务和一致性有什么要求？
Local Search的hop落在哪一层决定是否需要bookmark或事务快照。若hop落在L0/L1索引图，通常不需要强一致；若涉及L2/L3业务边，则可能需要事务快照或bookmark保证一致性。
为什么L3权限/审计边不应该默认放进可脏抽取图？
因为L3边需要强提交语义和可追溯性，而可脏抽取图是最终一致、可重建的，无法保证权限和审计的严格一致性，会导致随机错误而非单纯慢查询。
