什么场景下会用图数据库增强向量检索？

先这样答

判断标准是问题类型。用户问「退款政策是什么」，语义相近就能召回，向量检索够用。但问「这个供应商的下级经销商里谁有资质」「这个故障影响了哪些依赖它的服务」，答案要沿着实体关系走多步，每一步都是精确的结构化事实，不是语义相似度能猜的——这时候纯向量检索会把每一跳都变成猜测，图数据库的遍历是精确的。

实际架构通常是组合而非替代：向量检索做语义入口，把问题定位到具体实体；图数据库做关系扩展，从命中的实体出发沿边遍历多跳；生成层把两边的结果合并作答。图管结构化关系，向量管模糊语义，各干各的强项。

增量更新是工程关键：实体和边的变更要设计成事件驱动，变更进来先做实体对齐（同一个实体不同叫法要合并），再增量写入图，避免全量重建。这套维护成本是引入图的主要代价，值不值取决于多跳问题在你的场景里占比多高。

面试官会怎么追问

• 「为什么不直接让 LLM 多调几次向量检索来模拟多跳？」 可行但每跳都有召回错误率，多跳之后误差连乘；图遍历每跳都是确定的，且路径可以解释、可以审计。
• 「图里的实体从哪来？」 从文档里做实体抽取和关系抽取（规则加模型），抽取的一致性是最大难点，同名不同实体、异名同实体都要消歧。
• 「和 GraphRAG 什么关系？」 GraphRAG 是这套思路的完整化：图谱构建加社区发现加层次摘要，专门补全局性问题上局部检索答不了的短板。

回答的坑

把图数据库说成向量检索的替代品。绝大多数场景两者是互补，纯图方案连语义入口都做不了。

只讲架构不讲代价，实体消歧和增量维护的成本说不出来，会被判定没落地过。