GraphRAG 精准召回三大依赖

我觉得这道题问的其实是：当你用图来增强检索时，怎么确保召回的不是一堆边边角角，而是用户真正想要的结构化信息。说白了，就是怎么让图结构本身和查询意图对齐。

先说图构建。实体和关系抽出来只是第一步，真正决定召回质量的，是 [[实体链接]]的准确度。比如用户问「苹果公司最新财报」，如果实体链接把「苹果」链到了水果，那后面所有匹配都白搭。所以我会特别关注 Entity Linking 这一步，它决定了后续所有路径的起点质量。[[关系抽取]]也一样，不光要抽显式的「任职于」「收购」，还得能挖出隐式关联，比如「A 和 B 是竞争对手」这种语义关系。社区聚类这块，我常用 Leiden 算法，目的是把密集子图聚成语义社区，然后生成层级摘要。但这里有个坑：社区划分的粒度太粗，摘要就泛泛而谈；太细，又失去了全局视角。

再讲匹配层。自然语言查询怎么映射到图上？一种做法是把查询转成 Cypher 或者子图模式，但这对复杂问题不太够。实际落地我倾向用 [[混合检索]]，就是 Hybrid Search 把向量检索和结构检索结合起来。举个例子，电商退款场景，用户问「退款超过3天没到账」，向量部分抓语义相似的退款流程片段，图结构部分沿着「订单-退款-状态」的拓扑关系找到关联实体，两者融合排序。光靠向量容易语义漂移，光靠图结构又太刚性，合在一起才稳。

还有个关键点是全局和局部的联合召回。全局层用社区摘要回答「这家公司整体怎么样」这种宏观问题，局部层用具体实体关系回答「某个部门的预算细节」。实际系统里，我会根据查询意图自动选层：如果用户问得很泛，就走全局摘要；如果问得很细，就下钻到局部子图。但这里有个前提， 社区划分的粒度必须和查询意图匹配。如果社区太大，局部细节就丢了；太小，全局概括又不够。

最后说一下落地的风险。首先，实体链接不准，整个召回起点就歪了，常见失败场景是同名不同义、指代消解失败。其次，社区划分的粒度要是没调好，全局摘要要么太笼统要么太碎片。上线前我会拿一批历史 query 做回放，看 Recall@K 和响应时间，确保社区划分和实体链接的精度在可接受范围内。

说到社区划分，其实有个延伸点：社区粒度怎么影响全局摘要的概括性和精确性？比如电商场景，一个大的社区可能覆盖「退款全流程」，但用户只问「退款超时」，这时候社区摘要就太宽泛了；反过来，社区分得太细，用户问「所有退款相关规则」，又得拼凑多个社区。这个平衡怎么做，我一般从数据分布和查询频次来调。

所以整体上，我会把 [[GraphRAG]] 的结构化召回看成 图结构精度 和 的博弈，没有银弹，只能根据业务场景做取舍。