这道题其实是在问,当我们需要从大量文档里做复杂推理的时候,光靠找相似文本块够不够,不够的话怎么升级。[[GraphRAG]]的核心思想,就是把非结构化文本先提炼成[[知识图谱]],变成实体和关系的网络,然后在这个网络上做推理检索,而不是直接去匹配原文片段。
具体流程我拆成两步说。第一步是离线构建,用LLM从文档里抽实体,比如人名、组织、概念,再把它们之间的关系也抽出来,形成一个图。然后对这个图做社区检测,比如用Leiden算法,把紧密关联的实体聚成一个社区,再给每个社区生成层级摘要,从局部到全局一层层总结。第二步是线上查询,根据问题类型走不同路径:如果问的是具体实体,比如'张三的合同条款是什么',那就局部搜索,沿着图走到相关实体和关系;如果问的是全局性问题,比如'整个数据集里有哪些主要研究方向',那就聚合社区摘要来做回答。
跟传统[[RAG]]比,本质区别在检索单元。传统RAG拿文本块做向量检索,擅长回答'某一段说了什么'这种点状事实,但遇到跨文档的聚合性问题就吃力,因为每个块是孤立的。GraphRAG把块换成了实体、关系和社区摘要,所以特别适合需要多跳推理或者全局总结的场景。但这里有个边界:传统RAG成本低、构建快,适合高频实时检索;GraphRAG构建成本高,适合静态知识库加复杂分析类查询。真正落地时,我常常是两者混着用,简单事实走传统RAG,复杂推理走GraphRAG。
举个业务场景。比如一个企业内部有几千份合规文档和SOP,员工经常问'针对数据泄露,我们有哪些防控措施',传统RAG可能只返回某份文档里的一段描述,不够全面。如果用GraphRAG,它会先把所有文档里的实体,比如'数据泄露''防火墙''审计流程',和它们的关系抽出来,然后社区摘要会告诉你这些措施分布在哪些环节,甚至能推理出'防火墙和审计流程是互补的'。但前提是文档质量要够好,如果实体抽取不准,图就建歪了,回答反而更差。常见失败场景是领域术语太多,LLM抽出来的实体和关系全是噪声,所以上线前我特别关注实体抽取的准确率,会用少量标注数据做验证。
还有一个有意思的点,就是社区摘要的层级怎么设计。如果层级太少,全局回答会缺失细节;太多又增加成本。我一般会根据文档数量和查询复杂度动态调整层数,但具体怎么做最优,其实跟具体的图结构有关。
所以整体上,我会把GraphRAG看作传统RAG的增强插件,而不是替代品。我更倾向在需要聚合推理的场景里引入它,同时保留传统RAG做快速响应。如果让我选,我会先评估业务里全局性问题占比,超过30%才值得上GraphRAG,否则性价比不高。