GraphRAG

1. 项目/产品概览

2. 它主要能做什么

GraphRAG 的核心使命是解决传统向量 RAG 的本质性局限：向量检索只能返回与问题语义相似的文本片段，但无法理解片段之间的关系，更无法回答"需要纵览全体数据才能回答"的宏观问题。

核心创新：知识图谱 + RAG

传统向量 RAG 的流程：

文档 → 文本分块 → 向量嵌入 → 余弦相似度检索 → 丢给 LLM 生成

GraphRAG 的流程：

文档 → TextUnit 切分 → LLM 实体/关系抽取 → 知识图谱构建 → Leiden 社区检测 → 层次化社区摘要 → LLM 生成

两者的本质区别在于中间表示：向量 RAG 把文档变成"一堆数字"，GraphRAG 把文档变成"一张有结构的关系网"。前者只能回答"哪段文字和你的问题最像"，后者能回答"整个数据集讲了什么、实体之间如何关联"。

四种搜索模式（v3.x 完整版）

索引 Pipeline 详解

GraphRAG 的索引过程是其最核心也最昂贵的部分：

1. TextUnit 切分：将原始文档切分为可分析单元（TextUnit），作为后续处理的粒度单位，同时提供输出中的细粒度引用
2. 实体/关系抽取：LLM 自动从每个 TextUnit 中识别实体（人物、组织、地点、概念等）和它们之间的关系。这是成本最大的环节——每一块文本都需要多次 LLM 调用
3. 知识图谱构建：实体作为节点，关系作为带类型的边，构建全局知识图谱
4. Leiden 社区检测：对图谱进行层次化聚类——每个圆圈代表一个实体，大小表示度数，颜色表示所属社区。生成多层级的社区结构
5. 社区摘要生成：自底向上为每个社区生成自然语言摘要。底层社区描述细节，上层社区描述更宏观的主题

文本输入 → [实体抽取] → 实体/关系 → [图构建] → 知识图谱
                                                    ↓
查询输出 ← [LLM 生成] ← 检索上下文 ← [查询引擎] ← 社区摘要 ← [层次化摘要] ← 社区结构

Prompt Tuning（提示词微调）

微软强烈建议在使用 GraphRAG 时进行 Prompt Tuning——系统提供自动化的提示词微调机制，根据你的数据特征调整实体抽取、社区摘要等环节的 prompt。开箱即用的默认 prompt 在特定领域可能效果不佳。

3. 适用场景

4. 不太适合的场景

5. 核心能力清单

5.1 索引层能力

5.2 查询层能力

5.3 集成与生态

6. 架构/部署/集成方式

安装方式

# 从 PyPI 安装
python -m pip install graphrag

# 初始化项目
graphrag init

部署模式

LLM 集成

• 直接支持：OpenAI API（GPT-4o、GPT-4.1 等）、Azure OpenAI（含 Managed Identity 认证）
• 可配置接入：任何兼容 OpenAI API 格式的服务（如 Ollama 本地模型、DeepSeek、通义千问等）
• 嵌入模型：OpenAI text-embedding-3-small/large 或 Azure OpenAI 嵌入
• 关键提示：不同 LLM 对实体抽取质量影响很大，微软推荐使用 GPT-4 级别模型以保证图谱质量

配置文件（settings.yaml）

安装后自动生成 settings.yaml，控制所有索引和查询参数：

• LLM 模型选择与参数（chat model + embedding model）
• 文本分块大小与重叠度
• 实体/关系抽取的 prompt 模板
• 社区检测的 Leiden 参数
• 输出格式（Parquet 文件）

7. 怎么用

完整示例：从安装到查询

Step 1：环境准备与安装

# 创建项目空间
mkdir graphrag_demo && cd graphrag_demo
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate

# 安装 GraphRAG
python -m pip install graphrag

Step 2：初始化项目

graphrag init

此时会在当前目录生成：

• input/ — 放入待索引的文本文件
• .env — 填入 GRAPHRAG_API_KEY=<你的OpenAI或Azure API Key>
• settings.yaml — 索引和查询的配置
• prompts/ — 各环节的 prompt 模板

Step 3：准备数据并索引

# 下载示例文本（狄更斯《圣诞颂歌》）
curl https://www.gutenberg.org/cache/epub/24022/pg24022.txt -o ./input/book.txt

# 执行索引（注意：会消耗 LLM API 额度！）
graphrag index

索引完成后，output/ 目录下会生成一系列 Parquet 文件，包含实体表、关系表、社区表、社区报告表、文本单元表等。

Step 4：查询

# 全局查询 — 询问整个数据集的主题
graphrag query "What are the top themes in this story?"

# 局部查询 — 询问特定实体的详细信息
graphrag query "Who is Scrooge and what are his main relationships?" --method local

# DRIFT 搜索 — 结合局部和全局上下文
graphrag query "What is the significance of the Ghost of Christmas Past?" --method drift

# 基础搜索 — 传统向量检索模式
graphrag query "What year was this story published?" --method basic

Python API 示例：

import asyncio
from graphrag.api import build_index
from graphrag.query.context import set_context
from graphrag.query.engine import QueryEngine

async def main():
    # 执行索引（从配置文件读取参数）
    await build_index(root_dir="./graphrag_demo")

    # 设置查询上下文并加载索引
    await set_context(root_dir="./graphrag_demo")

    # 创建查询引擎
    engine = QueryEngine()

    # 全局搜索
    result = await engine.global_search("这个数据集涵盖了哪些主要主题？")
    print(result)

    # 局部搜索
    result = await engine.local_search("主角与哪些角色有重要关系？")
    print(result)

asyncio.run(main())

成本警告：以上示例使用的《圣诞颂歌》约 3 万词，用 GPT-4o 索引大约花费 $0.3~0.5。如果用 GPT-4 Turbo 索引一本 3.2 万词的书籍，社区实测花费约 $6~7。建议从最小数据集开始验证效果。

8. 售前可以怎么讲

8.1 一句话定位

"GraphRAG 用知识图谱重新定义了 RAG——让你的 AI 不仅能'查'到相关信息，更能'理解'信息的全局结构和关联关系。"

8.2 客户痛点 → 解决方案

8.3 差异化卖点

vs 传统向量 RAG（Haystack、LlamaIndex 等）：

• 向量 RAG 是"像不像"的匹配，GraphRAG 是"什么关系"的理解——回答的质量层次不同
• 向量 RAG 适合事实型问答（"章程第几条规定了什么"），GraphRAG 适合分析型问答（"公司各部门之间的协作关系如何"）
• 向量 RAG 索引成本极低（只需一次嵌入），GraphRAG 索引成本高 10~100 倍，但回答质量在宏观问题上高出一个数量级
• GraphRAG 的 Basic Search 模式就是回归到向量 RAG，可以混合使用

vs LightRAG（香港大学，2024 年 10 月）：

• LightRAG 放弃了社区检测和层次化摘要（GraphRAG 最昂贵的部分），改用图嵌入 + 低层/高层双检索
• LightRAG 索引成本约为 GraphRAG 的 1/100，查询速度快得多，且支持真正的增量更新
• 但 LightRAG 缺乏全局社区级理解能力——它只能找到相关实体和关系，无法生成"整个语料的主题概览"
• GraphRAG 的 Global Search 是真正的"俯瞰全局"，LightRAG 做不到
• 评估对比：GraphRAG 在 Contextual Summarize 类任务上优势明显（64.40 vs LightRAG 的 48.85，来自 GraphRAG-Bench 数据）
• 售前结论：如果需要宏观主题分析，选 GraphRAG；如果需要低成本、高频更新的实体级问答，选 LightRAG

vs LazyGraphRAG（微软自身，2024 年 11 月）：

• LazyGraphRAG 是微软自己推出的轻量变体，索引成本降至标准 GraphRAG 的 0.1%
• 代价是将大量 LLM 工作推迟到查询时，查询延迟更高
• 适合"偶尔需要全局理解，但日常查询以局部为主"的场景
• 这是客户最容易接受的切入点：先用 LazyGraphRAG 验证价值，再根据需求升级到完整版

vs 纯知识图谱方案（Neo4j + Cypher）：

• GraphRAG 自动从非结构化文本构建图谱，无需人工设计本体（Ontology）
• 传统知识图谱需要领域专家手工定义 schema，成本高、灵活性差
• GraphRAG 的图谱是 LLM 生成的，质量取决于 LLM 能力，可能存在抽取错误
• 对于已有结构化数据的客户，传统图数据库查询更精确、延迟更低

8.4 客户价值故事线

1. 切入："你们目前的 RAG 系统能回答'公司所有项目之间的依赖关系是怎样的'这种问题吗？不行对不对？因为传统 RAG 只擅长'找相似段落'，不擅长'理解全局关系'。"

1. 共鸣："你们的分析师每天要阅读几百份报告来写总结，RAG 系统只能帮你找段落，最后还是人脑在做连接各个信息点的工作。这根本不是 AI 应该做的事。"

1. 演示：拿出一份客户真实文档（如年度报告集），用 GraphRAG 做 Global Search → 自动生成主题概览、实体关系网络图、关键实体分析。让客户亲眼看到"从几百份文档自动提取出这张关系图"的威力。

1. 进阶：从 LazyGraphRAG 低成本切入点开始 → 验证价值后逐步升级到完整版 → 四种搜索模式按需使用（日常用 Local/Basic，需要宏观分析时用 Global/DRIFT）→ 增量更新保证数据新鲜度。

1. 重磅："微软研究院出品，34,000+ GitHub Stars，MIT 开源协议。论文在 EMNLP 等顶会发表，社区活跃、更新频繁。这不是一个实验性项目，而是已经被 500+ 项目依赖的生产级工具。"

9. 常见客户问题

10. PoC 建议

推荐 PoC 方向：企业文档集宏观主题分析与智能问答

总计：约 4.5 个工作日（不含 LLM API 审批时间）

验证指标：

• Global Search 回答全面性：人工评价 > 4/5 分（传统 RAG 通常只有 2~3/5）
• Local Search 实体关系准确性：> 80%
• 实体抽取精度：抽查 50 个实体，准确率 > 85%
• 索引成本：记录实际 token 消耗，为生产部署做预算参考

成本预估（PoC 阶段）：

• 200 份文档（约 50 万~100 万中文字）用 GPT-4o-mini 索引：约 $1~5
• Prompt Tuning 和反复测试：约 $3~10
• 总计 PoC LLM 成本：约 $5~15（非常可控）

11. 风险和注意事项

12. 我的售前判断

推荐度：特定场景强烈推荐（适合需要"全局理解 + 实体关系分析"的大规模非结构化文档场景）

理由：

1. 方法论领先：GraphRAG 不是向量 RAG 的增量改进，而是从"片段匹配"到"全局理解"的范式跃迁。在需要纵览全貌的业务场景中，它提供的价值是传统 RAG 无法企及的。
2. 微软品牌 + 学术权威：微软研究院出品、顶会论文、34K Stars——信任背书足够强，对技术决策者有说服力。
3. MIT 开源：无商业锁定风险，客户可以自由使用、修改、内部分发。
4. 四种搜索模式灵活：从零成本的 Basic Search 到全功能的 Global Search，按需选择和混合使用。
5. LazyGraphRAG 降低了准入门槛：成本敏感的客户可以从 0.1% 成本的轻量版开始，验证价值后再升级。
6. 生态逐渐成熟：FalkorDB 等厂商已推出生产级 SDK，GraphRAG-Bench 提供标准化评测，社区活跃。

推荐客户画像：

• 研究/情报机构：需要从海量非结构化文本中发现主题、趋势和关联
• 金融/法律/合规：跨文档实体关系分析、尽调、合规审查
• 大型企业知识管理：内部文档的全局理解、跨部门知识关联
• 具备 LLM API 预算（每月数百~数千美元 LLM 费用可接受）
• 技术团队有能力进行 Python 级别的集成和调优

不推荐的情况：

• 核心需求只是简单问答/FAQ（向量 RAG 更高效、更便宜）
• 预算极为有限或对 LLM API 调用成本过敏
• 需要极低延迟的实时对话系统（Global Search 延迟太高）
• 数据量很小（<100 份文档，图谱优势不显）
• 团队缺乏 Python 开发能力（需要代码级集成和调优）
• 需要官方 SLA/商业支持（GraphRAG 是研究项目，非商业化产品）

13. 参考资料

• GitHub 仓库：https://github.com/microsoft/graphrag
• 官方文档：https://microsoft.github.io/graphrag
• 学术论文：https://arxiv.org/pdf/2404.16130
• 微软研究院博客：https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
• PyPI：https://pypi.org/project/graphrag/
• LazyGraphRAG 论文：https://arxiv.org/abs/2411.14743
• LightRAG（竞品对比）：https://github.com/HKUDS/LightRAG
• FalkorDB GraphRAG SDK：https://github.com/FalkorDB/graphrag-sdk
• GraphRAG-Bench 评测：https://graphrag-bench.github.io/
• GraphRAG 成本分析参考：https://aiwiki.ai/wiki/graphrag

分析日期：2026-07-02 | 数据时效：GitHub 信息实时拉取，产品功能基于官方文档 v3.1.0