摘要：普通知识库擅长从少数文档中找答案，却经常答不好“过去三年最常见的质量问题是什么”这类跨文档问题。GraphRAG通过实体关系图、社区聚类和分层摘要补上全局理解能力，同时带来索引成本、实体治理与持续维护压力。
**摘要：**企业知识库经常出现一种反差：询问某份制度中的具体条款，系统能迅速定位原文；询问过去三年反复出现的质量问题，回答就开始零散。后一个问题要求系统覆盖大量文档，识别实体与关系，再对主题和趋势做归纳。GraphRAG为这类任务建立了实体关系图、社区层级和预生成摘要。它能提高全局问题的覆盖度，也会增加索引、实体消歧、权限继承和持续更新的工作量。
很多企业已经做过RAG知识库。制度、合同、产品手册、会议纪要和维修记录被切成小段，生成向量，再交给大模型回答问题。
演示阶段通常很顺利。用户问一个具体条款，系统找到相似片段，答案附着引用。进入日常使用后，管理者会提出另一类问题：五百份故障报告里有哪些共同原因，客户投诉在半年内发生了什么变化，多个部门的项目记录透露出哪些系统性风险。
其中一个常见短板是检索结构。向量检索适合定位局部证据，却不擅长完整覆盖语料库。数据缺失、切块质量、时间字段和查询路由也会影响结果，单纯扩大上下文窗口很难把这些问题一起解决。
局部事实与全局归纳使用不同的检索逻辑
假设一家制造企业积累了五年的设备故障报告。
“3号产线去年7月停机时，变频器报了什么故障码？”包含设备、时间和故障码等清晰线索。相关报告与问题语义接近，向量检索容易命中。
“过去五年哪些原因最常导致非计划停机，它们集中在哪些设备和班组？”需要统一设备别名与故障分类，再比较年份、产线和班组。答案分布在大量报告中，没有一份文档会直接给出完整结论。
微软GraphRAG文档把前者称为局部问题，后者称为全局问题。局部问题围绕具体实体、事件或事实展开；全局问题关心整个语料库的主题、结构、共同原因和变化趋势。
向量RAG按照语义相似度选取少量文本块。面对“最常见原因”时，它可能找回几篇恰好出现“重复故障”字样的报告，却漏掉大量采用其他表述的记录。增加Top-K和上下文长度能扩大样本，覆盖仍然取决于排序结果，Token与延迟也会一起上升。
GraphRAG怎样建立语料地图
GraphRAG的索引过程可以概括为三个阶段。
第一阶段处理文本与实体。文档被切成可追溯的文本单元，大模型从中抽取人员、部门、设备、零件、项目、事故等实体，同时记录实体之间的关系和可选声明。每一条抽取结果保留原文位置，便于回答时回溯证据。
第二阶段完成实体消歧和建图。同一台设备可能被写成“冲压机3号”“3#冲床”或内部资产编号，系统需要判断这些名称是否指向同一个对象。错误合并会把不同设备拼在一起，漏合并又会把同一对象拆成多个节点。领域词典、主数据和稳定ID会直接影响图的质量。
第三阶段进行社区聚类与摘要。微软GraphRAG采用Leiden等社区发现方法，把关系紧密的实体组织成层次结构。高层社区覆盖较宽主题，低层社区保留更细的局部关系。模型为各层社区生成报告，概括核心实体、事件和联系。
全局问题到来时，系统已有一组覆盖不同主题的社区摘要，可以按层级和预算选取材料。它不必临时从海量文本中只靠相似度抽样。
四种查询模式各有用途
Local Search从问题中的实体出发，扩展到邻居实体、关系、声明、社区报告和原始文本。它适合追踪某台设备、某个客户或某项决策的上下游联系。
Global Search按照社区层级和上下文预算选取社区报告，再通过map-reduce式流程生成答案。各批报告先形成局部观点并评分，系统随后汇总高价值内容。它适合处理主要风险、共同主题和长期变化。
DRIFT Search先利用社区信息形成较宽的理解，再生成后续问题，沿实体与证据继续深入。它用于同时需要全貌和具体出处的探索式查询。微软项目页提供了单独的DRIFT技术说明。
Basic Search仍然保留普通Top-K向量检索。具体条款、明确事实和单文档问答没有必要经过更复杂的图查询。成熟系统会先判断问题类型，再选择检索路径。
原始研究给出了怎样的结果
微软论文在约100万Token量级的新闻与播客语料上测试了全局摘要问题。不同配置与数据集的比较中，GraphRAG在完整性指标上的胜率约为72%至83%，答案多样性指标上的胜率约为62%至82%。根层社区摘要把查询上下文Token压缩了97%以上。
这些数字支持一个有限结论：在“整套资料主要讲了什么”这类任务中，GraphRAG比基线向量RAG覆盖得更完整。实验主要由方法提出方完成，评审环节使用了大模型判断，企业不能直接把论文胜率当成自身项目的生产指标。
图结构也不会自动提高每条事实的准确率。实体可能漏抽或错连，社区摘要可能省略细节，来源文档之间也可能互相矛盾。原始研究报告了更好的全面性和多样性；引用结构便于回到原文，无法据此推导“图谱已经消除幻觉”。
企业评测需要继续检查引用是否对应原文、实体是否合并正确、时间关系是否合理，以及答案是否把不同权限范围的信息混到一起。
成本来自哪里
普通向量RAG通常只需文档切块和嵌入计算。GraphRAG还要抽取实体与关系、合并描述、构建图、聚类并生成社区摘要。这些步骤会产生大量模型调用。语料规模和实体密度上升后，索引费用也会明显增加。
知识图谱还是一种派生数据。新文档持续进入后，实体描述会变化，关系会增加，社区边界可能重新划分。高频更新的工单、日志和新闻语料，需要增量索引、定期重建和版本回滚。
查询成本取决于模式。Local Search只读取有限实体邻域，通常较可控；Global Search要处理多份社区报告，细粒度层级会引入更多报告，随之增加Token和延迟。简单问题若都被送进Global Search，系统会花更多钱得到相同答案。
微软后来提出LazyGraphRAG，以低成本索引配合查询时的迭代检索。在微软特定实验中，它的索引和全局查询成本都显著低于标准GraphRAG。实际效果仍受语料规模、查询难度和配置影响。选型应按更新频率、全局查询量和延迟要求实测。
哪些企业问题值得使用
跨文档主题分析是最直接的场景。维修单、退货原因、客服记录和质检报告分散在不同系统，管理者关心问题与产品型号、供应商、批次和地区之间的共同模式。GraphRAG可以把这些对象和事件放进同一张关系图。
实体关系追踪也很合适。研发资料、专利、实验记录和项目报告中存在作者、材料、方法、指标和引用关系；大型软件系统则包含服务、模块、负责人、事故和架构决策。图检索可以沿着关系追踪来源与影响。
政策研究属于另一类典型应用。同一个产业会出现在资金、土地、人才、数据、能源和采购政策中。建图时必须保留发文机关、发布日期、有效期和废止状态，否则旧政策和现行政策会被混在一起。
结构化统计通常应交给数据库。按产品型号计算故障率、统计每月投诉数量，SQL和BI系统更准确，也更便宜。GraphRAG适合处理关系与语义归纳，不能替代已有的数据仓库。
文档量很小、答案集中在明确条款中，普通向量RAG已经够用。缺少统一设备编码、客户ID或产品主数据时，也应先治理数据。实体基础不稳，大图会放大错误合并和关系污染。
落地前先过三道门槛
项目团队先收集一批真实问题，标注局部事实、跨文档归纳和结构化统计。问题清单比技术架构图更能说明GraphRAG有没有必要。
随后选择一个边界清楚的语料集，例如一条产线一年的故障报告，同时建立向量RAG和GraphRAG。用同一批问题比较答案完整性、引用正确率、实体合并质量、延迟和成本。
最后再设计混合路由：具体事实走向量检索，结构化指标走SQL，全局主题走GraphRAG，实时内容接搜索。没有必要让所有问题穿过同一套昂贵流程。
权限继承也要在试点阶段验证。社区摘要可能汇总来自多个文档的信息，系统必须保证用户对摘要内容和引用原文都具有访问权限。节点、关系、报告和原始文本的授权规则需要保持一致。
先用真实问题对照测试向量检索、SQL和GraphRAG，再决定哪些查询值得承担图索引与治理成本。
主要参考
- Microsoft Research：GraphRAG: Unlocking LLM discovery on narrative private data。
- Microsoft GraphRAG Documentation：Welcome to GraphRAG。
- Microsoft Research：Project GraphRAG。
- Darren Edge等：From Local to Global: A Graph RAG Approach to Query-Focused Summarization，arXiv:2404.16130。
- Microsoft Research：Introducing DRIFT Search。
- ByteByteGo：GraphRAG: How AI Answers Questions Hidden Across Many Documents。