graph database for rag

你已经有一套能跑的向量检索 RAG，但一遇到「谁和谁有关系」「跨三跳才能答上来」的问题就开始胡诌，于是有人提议上图数据库。这篇不吹概念，只讲三件事：什么信号出现才值得上图、图检索和向量检索怎么拼在一起、选型时先量哪几个数，最后给一份接入顺序和回滚清单。

你已经有一套能跑的向量检索 RAG，回答事实类问题还行，但一遇到「谁和谁是什么关系」「跨三跳才能拼出答案」的题目就开始编。有人提议上图数据库，也有人劝你别折腾。这篇不聊概念，只讲三件事：什么信号出现才值得上图、图检索和向量检索怎么拼、选型时先量哪几个数，最后给一份能照着走的接入顺序和排查清单。

先明确一点：图不是向量检索的替代品。绝大多数能跑起来的方案，是向量负责「找相关内容」，图负责「补关系链路」。谁兜底、谁增强，在动手之前就要想清楚，不然后面出问题连该关哪个开关都不知道。

先判断：什么时候值得上图，什么时候纯属加料

问自己三个信号：第一，用户问题是否天然要求多跳关联，比如「跟这个项目相关的人里谁负责过采购」；第二，答案是否需要汇总一整片实体的关系，而不是命中一段文字；第三，同一份资料上的关系查询是否反复出现。三条都不中，先别上，向量检索调调切分和召回往往更划算。

• 语料本身是零散问答对，句式五花八门，抽取出来的关系大概率是噪声，上图只会把错误包装得更权威
• 实体识别准确率不稳，同一个人在不同段落里有不同叫法，图里会散成好几个节点，查询时对不上
• 关系抽取的维护成本没人接手，做一次全量之后再没更新，图会慢慢和真实语料脱节

把图接进检索链路的三种接法

第一种是旁路增强：向量召回之后，按命中的实体名去图里补一跳邻居，拼进上下文再交给模型。改动最小，适合先验证收益，也最容易回滚。缺点是只能补一跳，复杂关系还是接不住。

第二种是双路召回后融合：图检索和向量检索各出一批候选，再统一重排。工程量大，但对多跳问题更稳。重排这一步很关键，两路结果的打分口径不一样，直接拼在一起会让排序失真。

第三种是查询改写驱动：先让模型把自然语言问题拆成「实体 + 关系路径」，再决定这次走向量还是走图。灵活，但模型猜错路径时会退化成乱查，必须加校验和兜底——比如路径里的实体在图里不存在，就退回向量检索，而不是硬查。

三种接法怎么选

旁路增强

改动最小、验证快，适合先证明图到底有没有用；只能补一跳，复杂关系接不住

双路融合

多跳问题更稳，但要有重排能力和双份召回成本，适合问题复杂度已经稳定下来之后

查询改写驱动

最灵活，也最依赖模型的路径猜测，必须配兜底，否则错误会以「看起来很确定」的形式输出

选型清单：先量数据形状，再看产品

选型最容易犯的错，是先看产品清单再倒推需求。顺序应该反过来：先量清楚你的数据形状，再看哪类产品对得上。要量的就三件事——实体和关系的规模量级、单次查询平均跳数、写入与更新频率。这三项基本决定了你该看哪一类方案。

• 把候选方案放进同一张对照表，比四件事：查询语言熟悉度、是否原生支持向量字段、增量更新的代价、运维方式
• 如果你的查询跳数很低，不少向量库已经带了关系过滤或轻量图能力，用它可能比新引入一个独立图库更省事
• 图谱构建本身就是一次抽取任务，抽取质量决定答案上限，抽取成本决定你能不能持续更新
• 先在小样本上跑通全流程，包括抽取、入库、查询、回滚，再考虑全量

横向看方案时，别只盯单点能力，要看它在你的查询跳数下是否真的需要。目录类页面适合做初筛，最终判断还是要落到你自己的数据形状上。

接入顺序与出问题时的排查顺序

1. 小样本抽关系挑几十份有代表性的资料，跑一遍关系抽取，先看能不能抽出东西。抽不出来，后面都别谈。
2. 人工抽查准确率抽一批节点和边人工核对，重点看同一实体有没有被拆成多个节点。准确率不达标就先调抽取，别急着接检索。
3. 离线对比有图无图用同一批多跳问题跑两个版本，比较答案质量。没有提升就停在这一步，省下后面的维护成本。
4. 灰度放量先放一小部分流量，盯住延迟和错误率。图查询超时要有降级逻辑，不能直接把请求卡死。
5. 保留关掉图的开关线上始终留一个能单独关掉图查询的配置项，出问题先关它，而不是回滚整个服务。

• 先确认图里到底有没有这条关系，别一上来就怀疑模型
• 再看查询语句本身对不对，实体名是否和图里的写法一致
• 然后看超时和返回条数，是不是被上限截断了
• 最后才怀疑模型没有用上检索结果，或者上下文拼接时把它挤掉了

把每次检索的召回来源、跳数、耗时都记进日志。没有这些字段，出问题只能靠猜，排查一遍比写十行日志贵得多。评测集也要固定：同一批多跳问题反复跑，别拿一次主观感受就决定要不要长期维护这张图。