GraphRAG 如何从文档中抽取实体、关系和社区摘要？
这道题考的是 GraphRAG 的核心——怎么把一堆文档变成可检索的知识图谱。答案就三件事：把关键对象抽出来（实体）、把对象之间的关系理清楚（关系）、把图谱组织成能快速检索的结构（社区摘要）。
板块1：实体抽取——从文档中挖出"业务对象"
实体就是图谱里的节点。GraphRAG 用 LLM 从文本里识别出系统、人、组织、概念、事件这些业务对象。每个实体都会记录 source 字段，方便你追根溯源。
关键难点是同名实体消歧。比如文档里提到"张伟"，可能是三个不同的人，得靠上下文判断。另一个问题是噪声实体——LLM 可能抽出一堆没用的东西。预定义实体类型是个好办法，告诉你家 LLM"这些类型我才要，其他别管"，能省不少后处理的工作。
板块2：关系抽取——GraphRAG 的灵魂所在
关系是图谱里的边，表示依赖、包含、影响、因果这些关联。没有关系抽取，GraphRAG 就只是加了向量检索的普通 RAG。
关系可以带属性，比如时间、版本、置信度。但这里风险也大：方向可能抽反（A依赖B 变成 B依赖A）、类型泛化（具体关系变成泛泛的"相关"）、置信度不足（LLM 瞎编的关系）。预定义关系类型同样重要，告诉 LLM "这种关系我不想要"，它就不会乱抽。
关系就像人际关系网。光知道有哪些人没用，知道谁是谁的领导、谁和谁有矛盾，信息才真正有价值。
板块3：社区发现与摘要——把图谱变成可检索的知识
抽完实体关系，图谱可能乱成一团。社区发现用 Leiden 或 Louvain 算法，把连接紧密的节点聚成小群。有点像把大型社交活动的人分组——"技术部"、"财务部"、"供应商代表"，每个圈子推选一个发言人。
在做社区发现之前，得先做实体消歧和图谱归一化，把重复的实体合并。摘要生成用的是 Map-Reduce 模式：先为每个社区单独生成摘要，这样查询全局问题时，不用把所有原始文档都塞给 LLM，省 token、省钱。
板块4：完整链路——从文档到图谱的8个步骤
整个流程分8步：文档解析→文本切分→实体抽取→关系抽取→图谱归一→社区发现→摘要生成→索引入库。
这里有几个坑要避开：
切分太碎会丢失关系上下文，切分太大又增加成本。图太稀疏的话，社区质量会很差。LLM 生成的摘要可能丢掉约束条件，甚至引入幻觉。
整个过程就像做一桌菜：清洗切配（解析切分）、下锅翻炒（实体关系抽取）、摆盘装盘（图谱归一化）、传菜上桌（索引入库）。
面试怎么答
基础版（直接背）：
GraphRAG 构建知识图谱分三步走。第一步用 LLM 从文档里识别实体，核心挑战是同名消歧，比如"张伟"可能是三个人。第二步抽取实体间的关系，这是 GraphRAG 区别于普通向量 RAG 的关键，表示依赖、因果等关联。第三步用 Leiden/Louvain 算法做社区发现，把紧密连接的节点聚类，再用 Map-Reduce 模式为每个社区生成摘要，这样查询全局问题时不用把所有文档都塞给 LLM。完整流程包含文档解析、文本切分、实体关系抽取、图谱归一、社区发现、摘要生成、索引入库8个步骤。
加分项：
- 强调预定义实体/关系类型的设计价值——告诉 LLM 什么该抽、什么不该抽，降低后处理成本
- 指出 GraphRAG 的风险比向量 RAG 更严重：向量 RAG 顶多找错几段文本，GraphRAG 错误可能是整张关系网方向都错了
- 分析实体消歧的工程成本——需要人工规则+评测体系，是图谱质量的瓶颈
- 点出存储和 Token 消耗是向量 RAG 的 5-20 倍，需评估 ROI 后再选型
一句话总结
GraphRAG 的图谱构建就是：抽实体建节点、拉关系连边、按社区聚类生成摘要，让知识从一堆文档变成一张可检索的网。