GraphRAG 为什么比传统 RAG 准? 从分块检索到知识图谱增强的工程实践
如果你在企业里落地过 RAG 系统大概率踩过这个坑知识库里明明有答案但 AI 给的要么不完整要么牛头不对马嘴。根本原因不是模型不够强而是传统分块检索天然有信息断裂的问题。这篇文章讲清楚这件事的来龙去脉以及知识图谱增强检索GraphRAG是怎么解决它的。一、传统RAG的核心缺陷分块之后上下文断了标准 RAG 流程大家都熟悉把文档切成 chunk向量化存进向量数据库查询时计算相似度取 Top-K 片段拼进 prompt让模型生成答案。这个流程在文档结构简单、问题直接的场景下工作得还不错。但企业文档不是这种· 一份合同可能在第 3 条定义了某个术语但在第 17 条才用到它——两者切成了不同 chunk检索时只拿到了第 17 条模型不知道定义· 物业手册里「报修流程」分散在工单流程、部门职责、响应时效三个章节——向量相似度只能找到其中一个· 财务规定里「报销上限」依赖「员工级别」的定义但两段物理位置相距很远这就是「分块检索导致的上下文断裂」问题。本质原因是向量相似度衡量的是语义接近但文档中大量知识依赖的是结构关系和逻辑引用向量检索对这类关系是盲的。二、GraphRAG的思路把关系显式存储出来知识图谱增强检索的核心思想很简单在文档解析阶段不只做向量化同时自动抽取实体和实体之间的关系构建成图谱结构存储。以物业手册为例图谱抽取后大概长这样节点报修申请 → 工单创建 → 维修部门 → 响应时效边报修申请 --触发-- 工单创建工单创建 --分派给-- 维修部门工单类型:水电 --对应响应时效-- 4小时工单类型:电梯 --对应响应时效-- 2小时维修部门 --负责人-- 张工检索的时候不只是向量相似度匹配还会沿着图谱的边做「图遍历」找到「报修」节点之后自动沿边拉取「工单创建」「响应时效」「负责部门」等关联节点的内容。即使这些内容在原文里物理位置相距很远依然能被完整召回。三、工程实现要点3.1 实体抽取与关系识别实体抽取可以用 NER 模型也可以用大模型few-shot prompt 结构化输出。对于企业文档推荐用大模型原因是企业专有术语多通用 NER 模型识别率差。# 用大模型做实体关系抽取的 prompt 示意EXTRACT_PROMPT 从以下文本中抽取实体和关系以 JSON 格式输出格式{entities: [{name: str, type: str}],relations: [{from: str, to: str, label: str}]}文本{text}3.2 图谱存储方案选型图谱存储有几个主流选择·Neo4j生产级图数据库Cypher 查询语言社区成熟适合关系复杂的场景。缺点是运维成本相对高·NebulaGraph分布式图数据库性能好适合大规模节点。社区相对小·轻量方案如果图谱规模不大 百万节点直接用 NetworkX 在内存里跑也够用存储用 SQLite 持久化3.3 混合检索向量 图遍历GraphRAG 不是替换向量检索而是在向量检索之上加一层图遍历。典型流程def hybrid_retrieve(query, top_k5):# Step 1: 向量检索找相关 chunkvector_results vector_store.search(query, top_ktop_k)# Step 2: 从命中 chunk 中识别实体entities extract_entities(vector_results)# Step 3: 在图谱中以这些实体为起点做 N 跳遍历graph_context graph_store.traverse(start_nodesentities,max_hops2,relation_filter[触发, 分派给, 对应])# Step 4: 合并去重按相关性排序return merge_and_rerank(vector_results, graph_context)四、实际效果对比传统分块 RAG问「电梯故障报修后多久有人来」答「请提交报修工单工作人员会及时处理。」没拿到响应时效GraphRAG 增强检索问「电梯故障报修后多久有人来」答「电梯类故障响应时效为 2 小时工单派发至电梯维护组负责人张工。」完整在我们实际测试中针对关联型问题需要跨段落推理的问题GraphRAG 相比纯向量检索召回率从约 70% 提升到 99% 。当然这个数字依赖文档质量和图谱构建的准确率。五、适用场景与不适用场景GraphRAG 不是银弹有它适合的场景· 流程类文档SOP、合同、规章制度——关系密集图谱能发挥最大价值· 多文档关联查询需要跨多个文档找到一致答案的场景· 实体属性查询「XX 负责人是谁」「XX 政策适用于哪些部门」不适合的场景· 非结构化的长文本理解如文学分析——关系稀疏图谱收益低· 实时性要求极高的场景——图谱构建有额外延迟· 文档规模极小 50 页——直接全文塞进 context 更省事延伸阅读GraphRAG 的概念由微软研究院在 2024 年的论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》中正式提出。原始实现见 github.com/microsoft/graphrag。本文介绍的是适合企业实际落地的轻量化版本与原论文侧重点不同。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2433345.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!