从单跳召回到多跳关系推理一文讲清 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 的老婆是 BB 在 Tencent 上班。这就是图数据库增强 RAG 的关键把需要推理的路径先查出来再让大模型做表达而不是让大模型在缺证据的情况下“脑补”。七、GraphRAG 的查询流程可以这么写下面是一个简化的伪代码真实项目中会把实体识别、权限过滤、路径过滤、重排、证据融合拆成多个模块。def graph_rag_answer(question: str, user_id: str):# 1. 理解问题抽取实体、关系意图、跳数范围query_planparse_query(question)# 2. 向量检索找到相关文档和候选入口实体chunksvector_search(queryquestion,top_k20,user_iduser_id,)entry_entitiesentity_link(question, chunks)# 3. 图遍历沿着业务允许的关系扩展pathsgraph_traverse(start_nodesentry_entities,rel_typesquery_plan.allowed_relations,max_hopsquery_plan.max_hops,user_iduser_id,)# 4. 证据融合文本片段 图路径 来源信息contextmerge_evidence(chunks, paths)# 5. 生成答案要求模型引用路径不允许无证据猜测answerllm_answer(question, context)returnanswer注意这里的图遍历也必须做权限过滤。如果用户只能访问某些部门文档那么图谱里的节点和边也必须按权限裁剪否则会出现“文本检索没越权图遍历却把关系泄露出去”的问题。八、哪些场景真的值得上图数据库判断一个 RAG 系统是否需要图数据库不看技术先进程度而看业务问题是否高频出现“多实体 多关系 多跳推理”。最典型的场景是金融投资、企业关系、医疗知识图谱、代码依赖、供应链溯源和企业内部系统关系。它们都有一个共同特征答案不是单个文档片段而是一条关系路径。九、什么时候不值得上图数据库图数据库不是免费的。它需要抽取关系、维护 Schema、处理实体消歧、做增量更新还要评估路径质量。如果你的问题大部分是“某个概念是什么”“某个功能怎么用”“报错怎么处理”向量检索 混合召回 Rerank 往往已经够了。一个简单判断标准如果用户主要在问描述性内容用向量检索。如果用户偶尔问关系题用 Query Decomposition 多次检索先兜底。如果用户高频问多个实体之间的关系链用图数据库。如果还需要语义召回和关系遍历同时工作用混合 GraphRAG。十、生产落地建议别只看能不能查到要看证据链是否可信图数据库增强 RAG 的最终目标不是“查出更多东西”而是“查出可验证的证据链”。生产中建议重点关注以下几点。Schema 先行先定义实体和关系类型不要让模型随意造图。实体链接别名、缩写、历史名称、同名实体都要归一。边要有来源每条关系边要保存来源文档、时间、置信度。路径要能解释回答里最好能返回 A→B→C 这种证据链。权限要一致文档权限、节点权限、边权限必须统一。评测要覆盖多跳不要只看答案正确率也要看路径召回率和证据完整率。十一、面试或文章里可以这样总结当问题只是查某段描述性内容时向量检索就够了当问题涉及多个实体之间的关系推理时图数据库可以补上向量检索的短板。实际系统里两者不是替代关系而是组合关系向量检索找入口图数据库沿关系链多跳遍历最后把文档片段和图路径一起交给 LLM 生成答案。所以图数据库增强 RAG 的本质不是“更高级的检索”而是把业务里的关系结构显式化让模型有路可走、有证据可查、有边界可控。