从单跳召回到多跳关系推理，一文讲清 Graph DB 在 RAG 中的真正价值

一、图数据库不是替代向量检索，而是补“关系推理”短板

普通 RAG 的第一反应是“把问题向量化，然后去向量库里找最相似的文档片段”。这个思路解决概念解释、FAQ、说明书问答很有效。但一旦用户问的是多个实体之间的关联，比如“公司 A 的投资方和公司 B 有什么交集”“A 的老婆在哪里上班”“某个接口的间接依赖里有哪些高危漏洞”，答案就不一定在某一段文档里，而是藏在一条关系链上。

图数据库的价值就在这里：它把“实体”和“关系”显式存起来，让系统可以从一个节点出发，沿着边一跳一跳地追踪证据。向量检索像是在海量文档中定位入口，图数据库像是顺着地图找路线。两者组合起来，才是更适合复杂业务的 RAG。

二、向量检索为什么会在多跳问题上失效？

向量检索的核心能力是“语义相似”。用户问“什么是 Transformer”，向量库可以召回与 Transformer 解释最接近的 Chunk。这个问题是一跳问题，答案通常在某个文档片段里。

但多跳问题不是这么工作的。比如：

“小米的竞争对手的 CEO 是谁？”需要先找到竞争对手，再找到竞争对手的 CEO。

“A 的老婆在哪里上班？”需要先找到 A 的配偶，再找配偶的任职公司。

“这个接口间接依赖的第三方包有哪些漏洞？”需要沿着调用链和依赖链展开。

这些问题的共同点是：答案不一定直接出现在用户问题附近，而是分散在多个实体和多条关系上。纯向量 TopK 只能告诉你“哪些片段看起来相似”，却不知道“下一跳应该沿着哪条关系走”。

三、图数据库到底存的是什么？

图数据库的基本模型很简单：节点表示实体，边表示关系，属性表示补充信息。Neo4j 的属性图模型里，节点可以有标签，关系有方向和类型，节点与关系都可以带 key-value 属性。

可以把它理解成下面这张表：公司、人、产品、供应商都是节点；“投资”“任职”“供应”“竞争”是边；时间、金额、来源、置信度是属性。

节点：公司 A、张三、产品 X、药物 Y、函数 foo()。

关系：投资、任职、供应、依赖、治疗、竞争。

属性：发生时间、金额、来源文档、抽取置信度、权限范围。

路径：从一个节点沿着若干条边走到另一个节点形成的证据链。

四、图数据库和向量库怎么配合？

实际落地时，不建议把图数据库和向量库看成二选一。更合理的方式是混合检索：

先用向量检索做入口定位，找到与问题相关的文档片段和候选实体。

再做实体链接，把文本里的实体映射到图数据库中的节点。

然后用图遍历沿着指定关系扩展 1~3 跳，拿到路径证据。

最后把文档片段、图路径、来源信息合并交给 LLM 生成答案。

这套架构的好处是：向量检索负责模糊语义，图数据库负责精确关系。用户问题不一定写得很规范，向量检索可以兜住表达差异；关系路径必须可信，图数据库可以把每一跳的证据返回出来。

五、从文档到图谱：真正难的是抽取和维护

很多人以为接入图数据库就是“把 Neo4j 连上就行”。其实难点在前面：非结构化文档要先变成结构化图谱。这个过程一般包括文档清洗、Chunk 切分、实体抽取、关系抽取、Schema 校验、入图、建向量索引、增量更新。

这里一定要避免一个坑：让大模型自由抽三元组。它可能会抽出一堆看起来合理但业务不可控的关系，最后图谱越来越脏。生产中更建议先定义 Schema，例如只允许 Company、Person、Product、Drug、Function 这些实体类型，以及 INVESTED_IN、WORKS_AT、DEPENDS_ON、TREATS 这些关系类型。

六、用一个 Cypher 例子看清多跳查询

假设有这样一个问题：A 的老婆在哪里上班？我们先把已知事实建成图。

建图示例：

CREATE (a:Person {name: "A"});
CREATE (b:Person {name: "B"});
CREATE (c:Company {
  name: "C",
  alias: "Tencent"
});
 
MATCH (a:Person {name: "A"})
MATCH (b:Person {name: "B"})
MATCH (c:Company {name: "C"})
CREATE (a)-[:MARRIED_TO]->(b),
       (b)-[:WORKS_AT]->(c);

查询时不需要让大模型自己猜，而是让图数据库沿关系链走：

MATCH (:Person {name: "A"})
      -[:MARRIED_TO]->(wife:Person)
      -[:WORKS_AT]->(company:Company)
RETURN wife.name AS wife,
       coalesce(company.alias, company.name) AS workplace;

查询结果是 B 和 Tencent。然后 LLM 只负责把结构化结果说成人话：A 的老婆是 B，B 在 Tencent 上班。

这就是图数据库增强 RAG 的关键：把需要推理的路径先查出来，再让大模型做表达，而不是让大模型在缺证据的情况下“脑补”。

七、GraphRAG 的查询流程可以这么写

下面是一个简化的伪代码，真实项目中会把实体识别、权限过滤、路径过滤、重排、证据融合拆成多个模块。

def graph_rag_answer(question: str, user_id: str):
    # 1. 理解问题：抽取实体、关系意图、跳数范围
    query_plan = parse_query(question)
 
    # 2. 向量检索：找到相关文档和候选入口实体
    chunks = vector_search(
        query=question,
        top_k=20,
        user_id=user_id,
    )
    entry_entities = entity_link(question, chunks)
 
    # 3. 图遍历：沿着业务允许的关系扩展
    paths = graph_traverse(
        start_nodes=entry_entities,
        rel_types=query_plan.allowed_relations,
        max_hops=query_plan.max_hops,
        user_id=user_id,
    )
 
    # 4. 证据融合：文本片段 + 图路径 + 来源信息
    context = merge_evidence(chunks, paths)
 
    # 5. 生成答案：要求模型引用路径，不允许无证据猜测
    answer = llm_answer(question, context)
    return answer

注意这里的图遍历也必须做权限过滤。如果用户只能访问某些部门文档，那么图谱里的节点和边也必须按权限裁剪，否则会出现“文本检索没越权，图遍历却把关系泄露出去”的问题。

八、哪些场景真的值得上图数据库？

判断一个 RAG 系统是否需要图数据库，不看技术先进程度，而看业务问题是否高频出现“多实体 + 多关系 + 多跳推理”。

最典型的场景是金融投资、企业关系、医疗知识图谱、代码依赖、供应链溯源和企业内部系统关系。它们都有一个共同特征：答案不是单个文档片段，而是一条关系路径。

九、什么时候不值得上图数据库？

图数据库不是免费的。它需要抽取关系、维护 Schema、处理实体消歧、做增量更新，还要评估路径质量。如果你的问题大部分是“某个概念是什么”“某个功能怎么用”“报错怎么处理”，向量检索 + 混合召回 + Rerank 往往已经够了。

一个简单判断标准：

如果用户主要在问描述性内容，用向量检索。

如果用户偶尔问关系题，用 Query Decomposition 多次检索先兜底。

如果用户高频问多个实体之间的关系链，用图数据库。

如果还需要语义召回和关系遍历同时工作，用混合 GraphRAG。

十、生产落地建议：别只看能不能查到，要看证据链是否可信

图数据库增强 RAG 的最终目标不是“查出更多东西”，而是“查出可验证的证据链”。生产中建议重点关注以下几点。

Schema 先行：先定义实体和关系类型，不要让模型随意造图。

实体链接：别名、缩写、历史名称、同名实体都要归一。

边要有来源：每条关系边要保存来源文档、时间、置信度。

路径要能解释：回答里最好能返回 A→B→C 这种证据链。

权限要一致：文档权限、节点权限、边权限必须统一。

评测要覆盖多跳：不要只看答案正确率，也要看路径召回率和证据完整率。

十一、面试或文章里可以这样总结

当问题只是查某段描述性内容时，向量检索就够了；当问题涉及多个实体之间的关系推理时，图数据库可以补上向量检索的短板。实际系统里，两者不是替代关系，而是组合关系：向量检索找入口，图数据库沿关系链多跳遍历，最后把文档片段和图路径一起交给 LLM 生成答案。

所以，图数据库增强 RAG 的本质不是“更高级的检索”，而是把业务里的关系结构显式化，让模型有路可走、有证据可查、有边界可控。