先说几个核心判断：RAG（检索增强生成）技术已经证明了自己是LLM落地中不可或缺的一环，但大多数实现方案都卡在了一个共同的瓶颈上——检索能力本身的“天花板”。即便我们使用了最高效的向量数据库、绞尽脑汁优化了分块和排序策略，一种典型的问题依然存在：当用户的查询与源文档不是简单的“语义匹配”关系时，常规的基线RAG就无能无力了。更别提回答那些全局性的、需要推论的高级问题，以及理解数据实体之间关系的深层含义了。

大多数RAG的变体都聚焦于解决语料库超出LLM上下文窗口时该怎么办，而更高级的RAG系统引入了预检索和后检索策略，以及像查询扩展这样的技术来优化给定的查询。但所有这些方案，仍是在“检索”这个基本动作上进行修修补补。这恰恰是微软推出的GraphRAG试图切入的痛点——它要解决的不只是检索，更是

• 理解和连接。

  本文会带大家聊聊什么是知识图谱，它是如何一路演变而来的，以及为什么今天的RAG系统里越来越离不开它。为了讲清楚这件事，我们用阿瑟·柯南·道尔爵士的小说《巴斯克维尔的猎犬》作为测试用例，分别跑一遍基线RAG和GraphRAG，并对比结果看看到底哪种策略性能更好。最后，再来聊聊使用GraphRAG时需要注意哪些坑，以及它目前还存在的短板。

  什么是RAG

  RAG，检索增强生成，是一种通过整合外部来源的相关信息来增强LLM响应的技术。它借助外部知识的“外设”，让模型不用重新训练就能回答更准确、更具体的问题。

  **基线RAG** 以下代码演示了基线RAG的实现。一个嵌入模型先把小说转为向量存进Azure向量搜索，然后通过混合搜索为查询找到语义上最相关的top k (＝3)个结果，最后把这些结果连同查询一起扔给LLM，让它生成最终回答。 （代码块，略） 关于RAG基础，有需要的可以看之前那篇RAG 101的介绍文章。

  搜索引擎的演变

  任何RAG方法都离不开两步：检索和生成。生成这一步所有方法都差不多，无非是用LLM总结拿到的数据，而真正的差异全在于检索。这一步太关键了——如果喂给LLM的文档不合适，后面的生成也就跟着跑偏了。所以检索做得怎么样，直接决定了RAG整体效果的好坏。 检索本质上就是在文档里搜索，搭建的本质上就是一个针对私有数据的搜索引擎。因此，它的演进路径也跟传统搜索引擎惊人的相似。 * **关键词搜索** ——最早期的方案，在数据里匹配关键词的精确出现。同义词或变体都不认，搜索文本必须与语料库里的单词完全一致。倒排索引就是为这种策略服务的核心数据结构。 * **最佳匹配算法** ——这类排序算法通过词频、文档频率和文档长度来计算文档得分。BM25是其中最常用的，它解决了一些关键词搜索的固有缺陷，让检索质量明显提升。 * **PageRank** ——Google开发的那套，根据传入/传出链接和内容质量为每个页面打分。虽然上下文相关性略有折扣，但面对数百万文档的排序，它依然是重要的利器。文档排序和重排序也是增强基线RAG检索效果的常用手法。 * **语义搜索** ——从这一步开始，搜索不再只盯着“词”，而是真正去理解用户意图，考虑词语之间的关系。现在的搜索索引器几乎都同时支持纯关键词、语义搜索和混合搜索。 * **知识图谱** ——知识图谱在搜索之前就已经存在了几十年，但搜索的发展本质上也一直在向着“构建一个连接的图”靠近。PageRank和语义搜索背后都依赖类似图的数据结构。即使是Google在搜索结果中使用的知识图谱，也被表示为有向标记图，节点代表实体，边代表节点之间的关系。 所以，RAG的检索步骤演进到知识图谱阶段，几乎是水到渠成的事。

  什么是知识图谱

  知识图谱是两个实体之间关系的语义表示。它为非结构化数据提供了结构，让机器能够理解实体之间怎么互相关联。所有实体都是节点，关系就是边。节点可以是一个人、一个地点、一家组织或一个事件；边则反映它们之间的任何属性。 **使用LLM构建知识图谱** 传统上构建知识图谱是件费时费力的手工任务，需要主题专家和数据科学家反复核对数据来理清实体关系。但随着LLM的出现，几乎整个流程都可以自动化。我们可以写一个简单的提示来提取名称、地点、组织，甚至事件。 **提取实体及其关系** 来看一个基本提示，用于从文本中提取名称、地点、组织和事件。最终，我们希望用户可以自定义他们的实体类型——因为领域的特异性很强，这会明显提升提取效果。 （代码块，略） 用小说的第一段作为输入，输出如下： （输出结果，略） 对一个基础提示来说，效果还不错。接下来还可以把entity_types作为一个变量加入，并提供一些指定结构的少量示例来获得需要的输出格式。这就是GraphRAG目前的做法。从GraphRAG的代码可以看出，它是用一个统一的提示来提取实体及其关系的。 （代码块，略，含完整的提示示例） 最终，我们得到的是结构化格式的结果： （输出结果，略）

  使用GraphRAG

  为了展示GraphRAG的真正价值，我们把这本书的最后两章删掉，然后分别用基线RAG和GraphRAG来回答问题。要启用GraphRAG，先用CLI命令把书索引成parquet文件，再加载到内存中。 （代码块，略） **使用GraphRAG需要注意的几点** 1. 虽然默认提示能提取人物、地点和组织这样的基本实体，最好还是为自己所在的领域提供一些少量示例，以提取更贴合业务的其他实体。 2. GraphRAG的论文提到，提示会先判断“是/否”再识别缺失的实体，但即使是更长的上下文，也不能保证LLM能把所有实体都识别出来，尤其是那些非名词或由多个单词组成的复合实体。 3. 没有明确的实体去重步骤。就算一个实体被误解并复制为独立的节点，它们也相对靠近彼此，且连接紧密。加上GraphRAG生成社区摘要，LLM最终会理解这点并产生合理的摘要。 4. 为了在整个图中分发信息，GraphRAG会随机化社区报告（删除权重为0的报告，再按相关性分数排序）。只取适合上下文窗口的前n个报告，但不能保证每次出现完全相同的报告；即使结论相同，来源报告也可能完全不一样。 **GraphRAG的局限性** 1. **成本很高** ——无论索引阶段还是查询阶段，它对LLM的调用次数都远高于基线RAG。简单来说，就是花钱更多。 2. **RBAC（基于角色的访问控制）变得复杂** ——常规做法是在元数据上应用过滤器，排除用户无权访问的文档。但在GraphRAG里，究竟哪些实体、关系或社区报告需要设置访问权限，以及怎么为不同角色构建图，都会更复杂。 3. **结果不确定性增加** ——嵌入文本后，基线RAG对同一查询总是给出相同答案，因为检索器始终返回固定文档。但GraphRAG依赖LLM的输出做实体识别、关系标注、社区摘要和报告生成，同一语料库上重新生成图，就可能给相同查询带来不同的答案。