考察点
「为什么要用到图数据库」是 2026 面经 RAG 部分原题。面试官在探你的技术视野边界：知不知道纯向量检索的能力天花板在哪，了不了解微软 GraphRAG 这类新范式。能讲清「什么问题向量做不了、图能做」就算过关，能讲成本权衡的是加分项。注意别吹成银弹。
参考答案
向量检索的两个结构性盲区
向量检索的基本假设是「答案就在某一段文本里，语义相近就能捞到」。但有两类问题违反这个假设：
- 关系推理型：「A 公司的供应商里，哪些也给 B 供货？」答案分散在几十段文本里，没有任何一段单独包含答案，需要顺着「供应」关系走多跳。向量检索只能捞到各跳里语义最像的几段，链条一断就答错。
- 全局总结型：「这份几千页的招标文件整体有哪些风险点？」问题不指向任何具体段落，需要对全语料的宏观理解。Top-K 检索注定只见树木不见森林。
这两类是图结构的主场。
GraphRAG 的核心流程
微软 2024 年开源的 GraphRAG 给出了完整范式，离线侧三步：
- 实体与关系抽取：用 LLM 从每个 chunk 里抽出实体（人、公司、产品、概念）和关系（任职、供应、引用），形成三元组。这是成本大头——全语料过一遍 LLM，百万字文档的抽取成本要几千元级 API 费用。
- 建图：实体做节点、关系做边，存入图数据库（Neo4j、Nebula）。同名实体要消解合并（「腾讯」「腾讯公司」「Tencent」是同一个节点），这一步质量直接决定图的价值。
- 社区检测与摘要：用 Leiden 等社区发现算法把图聚成层级社区，让 LLM 给每个社区生成摘要。社区摘要就是「全局视角」的载体。
在线侧两种查法：局部查询（问具体实体）从实体节点出发做子图遍历，取多跳邻域进 Prompt；全局查询（问整体总结）走 Map-Reduce——各社区摘要先分别作答，再汇总成终稿。
和传统 RAG 的关系：补盲不是替代
GraphRAG 没有取代向量检索，它是多路召回里新增的一路。实战架构是：向量路处理常规事实问答（占 80% 流量），图谱路处理关系推理，社区摘要路处理全局问题，前面加一个查询路由器按问题类型分流。我的项目里图路只承接约 15% 的查询，但这 15% 恰好是传统 RAG 答一题错一题的部分。
冷静的成本账
GraphRAG 不是免费的：抽取成本高、实体消解难（消错了图就是脏的）、图谱要随文档更新增量维护、工程链路比向量 RAG 长一倍。文档之间关系密集、查询有大量多跳推理的场景才值得上——企业知识图谱、法律案例引用网、供应链关系。如果知识库是一堆彼此独立的 FAQ 和产品手册，老实做向量 RAG，上图是过度设计。
轻量替代方案也值得一提：不做完整图谱，只做「实体索引」——抽出实体建倒排，检索时实体命中的 chunk 加权。花 20% 的成本拿到图 50% 的收益，适合大多数想试试水的团队。
可能的追问
Q：实体消解怎么做？ 三层：字面归一（大小写、全半角、常见别名表）；向量相似度聚类候选；边界 case 让 LLM 判断两个实体描述是否指向同一对象。消解开人审队列，错误消解比不消解危害大。
Q：图数据库选型？ 中小规模 Neo4j 够用（Cypher 生态成熟）；亿级边以上看 NebulaGraph。量级再小（十万节点内）甚至不用图数据库，NetworkX 内存里跑都行——别为用图而用图。
Q：文档更新了图怎么维护？ 增量管道：变化文档重新抽取，新三元组写入前做实体对齐；被删除文档的三元组标记失效而非物理删除，定期合并。全量重建每月一次兜底。