[[GraphRAG]] 的核心动机，是弥补传统向量 [[RAG]] 在跨文档关系和全局分析上的不足。传统 RAG 把文档切成一个个 chunk，再用向量相似度找相关片段；它做事实问答很有效，但每个 chunk 基本是独立的，实体之间的关系、文档之间的联系没有显式建模。所以遇到“这个行业有哪些主要趋势”“A 公司和哪些机构有间接关系”这类问题，单纯向量检索就比较吃力。
GraphRAG 的做法是先把文本变成图。流程一般是：文档清洗和[[分块]]之后，用模型抽取实体，比如人、公司、产品、概念；再抽取实体之间的关系，比如投资、隶属、竞争、因果、引用。抽完以后要做实体消歧和合并，比如“OpenAI”“Open AI”“这家公司”可能指同一个实体。最后把实体作为点，关系作为边，构建属性图，并保留来源文档、时间、关系置信度这些信息。
在微软 GraphRAG 那类方案里，还会做社区检测，比如用 Leiden 算法把联系紧密的实体聚成社区，然后对每个社区生成摘要。社区可以分层，底层是局部实体关系，上层是更宏观的主题摘要。这样系统不仅能查某个实体附近的关系，还能回答更全局的问题。
检索时主要有两种模式。第一种是 local search，适合具体实体问题。比如问“公司 A 投资过哪些项目”，系统先识别实体“公司 A”，再沿着图里的投资关系做一跳或多跳遍历，把相关节点和证据文档拿出来给模型。第二种是 global search，适合宏观总结。比如问“这些研报反映出哪些行业趋势”，系统会先查社区摘要，再逐层下钻到相关社区和原文证据。
和向量检索相比，GraphRAG 的优势是关系显式、路径可解释、跨文档聚合能力更强。向量检索擅长找“语义相似的文本块”，GraphRAG 擅长找“实体之间怎么连接、主题之间怎么聚合”。但它的代价也很明显：构建成本高，要抽实体关系、做消歧、做社区摘要；更新也更复杂，新文档进来不只是加向量，还要更新图结构和摘要。
所以我不会把 GraphRAG 当成传统 RAG 的替代品。简单事实问答、数据频繁更新的知识库，用向量检索加 [[BM25]] 加 reranker 往往更务实；关系密集、相对静态、需要分析报告或关联挖掘的场景，GraphRAG 更有价值。
真正落地时，我会关注两个风险：一个是抽取错误会污染整张图，必须有置信度和人工质检；另一个是社区粒度，如果分得太粗，摘要空泛；分得太细，又失去全局视角。这两个点通常决定 GraphRAG 的实际效果。
