Graph RAG落地：向量库之外还要补什么
很多RAG项目的问题，并不出在“有没有召回”。日志里常常能看到，系统已经找到了几段看起来相关的文档，大模型最后却把因果关系说反，或者把两个相邻但无关的事实拼在一起。
这类问题很难只靠调Embedding参数解决。传统RAG主要依赖文本匹配和语义相似度，擅长回答“这段资料里有没有类似说法”，但遇到实体关系、上下游链路、责任归属时就容易露出短板。李乾坤在《RAG与知识图谱》中用了一个很直观的比喻：只把一堆文件扔给学生，却不教他分析框架，学生未必能找到真正的答案。
Graph RAG要补的就是这张“分析框架”。它把知识图谱引入RAG：实体可以是产品、客户、合同、部门，关系可以是属于、购买、依赖、导致、关联。向量库继续负责语义召回，图谱负责把“谁和谁有什么关系”交代清楚。
向量检索卡住的地方
基础RAG通常会把文档切成片段，再转成向量，存进Milvus、Chroma一类向量数据库。用户提问后，系统用相似度找回若干文本片段，再交给LLM生成回答。
这条链路很适合处理 FAQ、制度查询、产品说明这类问题。比如“报销需要哪些材料”，只要制度文档里写过，向量检索大概率能找回来。
麻烦出在另一类问题上：
- “A产品最近投诉增加，可能和哪些供应商有关？”
- “这份合同里的违约责任，和历史纠纷中的哪几类条款相似？”
- “某部门业绩变化，和人员、订单、交付之间有没有关联？”
这些问题不只是找相似文本，还要沿着实体关系往外查。向量检索能召回“投诉”“供应商”“合同条款”等片段，却未必知道它们之间的方向、层级和约束。经济部产业技术司在“科技新知”中也提到，LLM通过语义匹配预测下一个词，并非真正理解语言背后的含义；训练数据还存在时间范围和领域限制。企业内部知识库一旦涉及实时数据和业务关系，单靠模型记忆更不稳。
图谱补的是关系，不是装饰
知识图谱的价值在于把文本里的实体和关系显式化。
举个常见的企业场景：售后工单里出现“设备A过热”“部件B更换”“供应商C批次异常”。如果这些信息只散落在PDF、邮件和工单备注里，向量检索只能按相似度捞文本。图谱化之后，系统可以把它们整理成类似这样的关系：
- 设备A — 使用 — 部件B
- 部件B — 来自 — 供应商C
- 设备A — 出现 — 过热故障
当用户追问“哪些供应商可能和设备A故障有关”，Graph RAG可以先沿图谱找路径，再把相关工单、合同或质检记录作为上下文交给模型。回答不再只依赖几段相似文本，而是带着关系链路。
Datawhale 的 all-in-rag 文档也指出，传统RAG虽然缓解了知识陈旧和幻觉问题，但依赖非结构化文本向量检索，在复杂查询中难以捕捉实体间的深层关系。这正是Graph RAG适合切入的地方。
一条更稳的检索链路
实际工程里，Graph RAG通常不会替代向量检索，而是和向量检索并行工作。
用户输入问题后，系统先做查询理解：识别问题里的实体、关系词和意图。比如“某客户最近投诉是否和某产品版本有关”，这里至少有客户、投诉、产品版本三个实体方向。
接下来走两条检索路径。
一条是向量路径。系统在向量库里找语义相近的文档片段，例如投诉记录、产品发布说明、客服纪要。
另一条是图谱路径。系统在图数据库中查实体关系，比如客户购买了哪个产品、产品对应哪个版本、版本关联了哪些已知问题、投诉记录是否指向同一类故障。
最后再做重排序和上下文组装。重排序可以把不相关但“看起来相似”的片段压下去；上下文组装则要把文档片段和图谱路径一起放进Prompt。模型看到的不只是“某段文字提到投诉”，还包括“客户—产品—版本—问题”这样的结构关系。
这一步很关键。很多RAG幻觉并不是模型完全没资料，而是上下文给得太碎。Graph RAG把碎片之间的连接补上，模型生成时更容易守住边界。
先把Schema想清楚
Graph RAG的难点往往不在调用API，而在Schema设计。
53AI关于“知识图谱+向量数据库”的材料里，示例代码先定义了collection_name、dim，并以OpenAI embedding维度1536为例创建集合。这类向量侧配置相对清晰：字段、向量维度、主键都能按工程规范处理。
图谱侧更麻烦。你必须先决定系统到底关心哪些实体、哪些关系。比如做企业知识库，可以从这些对象开始：
- 产品
- 客户
- 订单
- 合同
- 工单
- 部门
- 员工角色
关系也要收窄：
- 客户购买产品
- 产品关联订单
- 工单指向产品
- 合同约束订单
- 部门负责产品线
如果一开始就想抽取所有实体、所有关系，图谱很快会变成一团难以维护的网。更稳的做法是先选一个业务问题，例如“产品故障归因”或“客户投诉追踪”，只围绕这个问题设计实体和关系。
从文档到三元组，中间有很多脏活
把非结构化文档变成图谱，通常要经过清洗、切分、实体抽取、关系抽取、去重和校验。
合同、PDF、客服记录、会议纪要都可能成为输入。LLM可以辅助抽取“甲方”“乙方”“违约责任”等实体，也可以把一段文字转成三元组。但抽取结果不能直接入库，至少要处理几类问题：
- 同一个实体有多个写法，比如公司全称和简称；
- 关系方向容易出错，比如“供应商供货给客户”和“客户采购自供应商”；
- 文档里有历史状态，不能和当前状态混在一起；
- 敏感实体需要脱敏或权限控制。
图谱质量差，Graph RAG只会把错误放大。向量检索召回错了，可能只是多给一段无关文本；图谱关系错了，模型可能沿着错误路径推理出一整套看似严密的结论。
不要把图谱做成第二个数据仓库
很多团队落地Graph RAG时，会不自觉地把目标做大：既想覆盖客户，又想覆盖供应链，还想覆盖财务、合同、人事。结果是图谱建设周期拉长，业务侧迟迟看不到效果。
更可行的路线是从高频、强关系、可验证的场景开始。
比如“产品—故障—工单”图谱。它的实体边界相对清楚，问题也容易验证：系统回答的故障原因、相关批次、涉及产品，能不能被工单或质检记录支持。
再比如“客户—投诉—合同条款”图谱。它适合客服、法务、销售协同查询，但必须把权限边界提前设计好。哪些人能看客户信息，哪些人只能看脱敏关系，图谱入库前就要定规则。
Graph RAG不适合用来证明“我们也有图谱”。它更适合解决普通RAG说不清关系的那一小块问题。
延迟、更新和权限，都是上线前的问题
Graph RAG一旦进生产环境，工程问题会很快出现。
首先是更新。企业数据不是静态百科，订单、工单、合同状态会变化。图谱如果更新滞后，系统可能拿旧关系回答新问题。比较稳的做法是建立增量更新管道，把业务数据库、文档系统和图数据库之间的同步机制设计清楚。
其次是延迟。一次查询如果同时走向量召回、图谱遍历、重排序，再让LLM生成，响应时间会明显增加。常见做法是限制图谱扩展深度，对高频子图做缓存，并把不必要的关系排除在查询外。
还有权限。图谱天然会把分散数据连接起来，这也意味着它可能暴露原本不容易被发现的敏感关联。涉及客户、员工、合同、交易记录时，需要遵守数据权限和个人信息保护要求。Graph RAG让系统更会“联想”，也要求企业更清楚哪些关系不能被随意联想。
适合Graph RAG的，不是所有RAG项目
如果业务问题主要是制度问答、文档检索、知识库摘要，基础RAG加上更好的切分、召回和引用约束，可能已经够用。
如果问题经常涉及多实体、多跳关系、因果链、归属关系，Graph RAG才值得投入。它的收益来自关系结构，而成本也来自关系结构：Schema要设计，实体要对齐，图谱要更新，权限要重做。
向量库解决“这段话和问题像不像”。知识图谱进一步回答“这些事实之间怎么连”。企业RAG要走到复杂业务查询，迟早会碰到这个分界线。
