面试题
Q1：GraphRAG 解决了向量 RAG 的什么问题？为什么不能通过"调大 top-k"解决？
向量检索的单元是 chunk，它无法回答两类问题：多跳推理问题（答案需要串联多个 chunk 中的事实，没有任何一段自足）和全局概览问题（相关性分布在几乎全部语料上，top-k 机制系统性以偏概全）。调大 k 只能线性增加召回的噪声：多跳问题的中间事实段在问题下语义相关性低（"A 的核心技术"这段对最终问题的直接相似度并不高），全局问题则根本没有"更相关"的段可选。GraphRAG 把语料预消化成实体关系图与社区摘要，多跳问题变成图上的路径查找，全局问题变成对社区报告的 map-reduce——结构变化，而非参数变化。
Q2：描述 GraphRAG 索引构建的完整流水线，成本集中在哪里？
切分文本单元（约 300 token）→ LLM 抽取实体/关系（含 gleaning 补抽轮）→ 实体解析归并 → Leiden 层次化社区检测 → 对每个社区 map-reduce 生成报告（层级自底向上合成）。成本集中在两处：LLM 抽取（单元数 × 轮数 × 单元 token）与社区报告生成（报告数 × 报告 token）。社区数随语料规模增长，因此摘要成本在大语料下会超过抽取。
Q3：Local search 和 Global search 的区别？为什么全局检索不能"检索 top-k 社区报告"完事？
Local 从问题实体出发取图上邻域 + 关联原文，回答具体事实问题；Global 对所有社区报告做 map-reduce，回答语料级概览问题。全局检索看起来可以"向量检索 top-k 报告"，但有两个理由不够：其一，全局问题的相关性高度分散，"最相关的几个社区"往往就是"全部社区"，预计算的报告本来就是为了让全量 map-reduce 成本可控（报告是浓缩的）；其二，LazyGraphRAG 路线恰恰证明了反过来更划算——不做预计算、按需生成少量报告的摘要。
Q4：Leiden 相比 Louvain 的优势是什么？为什么 GraphRAG 选它？
Louvain 的两个已知缺陷：模块度的分辨率极限（社区粒度受度数分布扭曲）与不连通社区（算法输出的"社区"内部可能不连通，是合并过程的伪产物）。Leiden 在聚合前加 refinement 阶段，保证每个社区内部良连通，实践中模块度更高、速度也更快。社区摘要是给 LLM 读的整体输入，一个不连通社区的报告在语义上根本写不成句，所以连通性保证是硬需求。
Q5：LazyGraphRAG 的核心思想是什么？数据支撑是什么？
把社区摘要的生成从索引阶段延迟到查询阶段：索引只做抽取（和轻量的社区结构计算），查询时只对相关社区即时生成摘要。微软官方口径：索引成本约为完整 GraphRAG 的 0.1%（约千倍降低），全局查询成本约降为 1/700；在其基准（5590 篇 AP 新闻、100 个合成全局问题）上对向量 RAG、GraphRAG 各模式、RAPTOR、LightRAG、TREX 取得 96 场对比全胜（95 场统计显著）。注意这是官方未独立复现的结果，且优势区间主要落在全局查询上。
Q6：LightRAG 的"双层检索"是怎么设计的？为什么不依赖社区摘要？
LightRAG 对实体和关系分别生成描述并做 embedding。查询时用 LLM 把问题展开为高低两层关键词：低层用关键词向量检索命中实体（取点及其一跳关系），高层直接检索关系（取边及其上下文），合并后加 naive 向量检索融合。它放弃了社区结构，换来三点：索引成本降一个数量级、增量更新天然友好（新文档只需增量抽图 + 增量向量插入）、工程组件少。代价是全局概览能力弱——它的 global 模式只是实体/关系描述的聚合，没有真正的社区报告。
Q7：HippoRAG 为什么用 Personalized PageRank 做检索？比"迭代式多跳检索"好在哪里？
PPR 从问题实体（种子）出发做带重启的随机游走，一轮迭代就把"图上与种子 1-3 跳内、路径越短越重要"的节点全部打分完成。传统迭代式多跳（检索→生成中间答案→再检索）每一步都依赖 LLM 的中间推理，误差逐轮累积、延迟逐轮叠加，且每轮向量检索的 top-k 可能丢掉中间事实段（它对最终问题的相似度低）。HippoRAG 的检索把图得分传播到节点关联的 passage 再与向量分融合排序，兼顾"图上相关"与"原文可答"。
Q8：GraphRAG 的索引成本为什么高？列举四个降本手段并说明适用条件。
高在三处：全语料逐单元 LLM 抽取、gleaning 多轮、每社区 LLM 报告（层级合成）。降本手段：(1) 抽取/摘要用小模型、回答用大模型——抽取是格式任务，小模型足够；(2) Lazy 式延迟摘要——适合全局查询低频、更新频繁的语料；(3) 谓词归一与实体类型收紧——减少图膨胀与社区碎片化，摘要更短；(4) verb 级缓存与增量索引——迭代调优与日常更新只重算变化部分。
Q9：实体解析（Entity Resolution）不做会怎样？生产上怎么做？
逐单元独立抽取必然产生"OpenAI/openai/Open AI"多个节点，图碎成孤岛，社区检测碎成小簇，社区报告失去语义完整性，全局检索质量崩塌。生产做法三层：名称归一（大小写、别名表）→ 描述 embedding 相似度合并（灰区进人工队列）→ 图结构反馈（合并杠杆最高的节点通常是高中心性节点，人工审前几百个即可）。LightRAG Server 一类运维界面把节点合并/拆分做成专家可操作的入口。
Q10：删除一篇文档，GraphRAG 系统里要级联更新什么？
四层：向量库删 chunk 嵌入；图库删该文档贡献的三元组（带引用计数——一条边可能来自多篇文档，weight 归零才物理删）；受影响的 Level 0 社区结构重算；相关分支的上层社区报告重生成。实现前提是维护"文档 → 三元组 → 社区 → 报告"的反向索引。LightRAG 自 2025.08 起官方支持文档删除并重建受影响 KG 子图，自建系统需要实现等价机制。
Q11：如何评估一个 GraphRAG 系统的效果？向量 RAG 的评估方法能直接用吗？
不能直接搬，因为 GraphRAG 服务两类异质问题要分开评：局部/多跳问题用多跳基准（HotpotQA、2WikiMultihopQA、MuSiQue），检索侧 recall@k 与生成侧 F1/EM 分开报；全局问题用 GraphRAG 论文的三维 LLM 评审（全面性/多样性/可行动性）或 BenchmarkQED 流程。基准的防污染检查不可省（多跳基准训练泄漏严重）。最关键的评估动作其实是上线前的查询分桶 A/B：图检索的收益高度任务相关，GraphRAG-Bench 的结论是在简单事实检索上经常打不过调好的向量检索——只对理论优势桶上图。
Q12：KAG 和 GraphRAG 的抽取路线有什么不同？各自的适用域？
GraphRAG 是 schema-free OpenIE：LLM 自由决定实体类型与谓词，零前期成本、任意领域可用，代价是谓词噪声与类型漂移。KAG 是 schema 约束抽取：领域专家预定义本体（概念、属性、关系类型、层级），LLM 在约束下抽取并做概念语义对齐，输出可以直接映射为逻辑形式参与推理。前者适合开放语料与快速验证，后者适合法务、医疗、政务等有本体积累的强专业域——schema 的构建成本在那里能被复用摊薄。
Q13：生产上为什么推荐"图 + 向量 + BM25"混合而不是纯图检索？
两者是互补的精确符号与连续语义：图边是离散符号（精确、可遍历），向量是语义近似（抗表述变化）。抽取永远有遗漏——漏掉的边图上不存在，但向量相似度能兜住；开放语义问题（没有明确实体的问题）向量/BM25 天然更强。RRF 合并各路 top-k 是稳妥默认，各路分数分布不同也不需要归一化。工程上图索引因此应作为检索增强支线存在，而不是单点替换。
Q14：DRIFT search 是什么？解决什么问题？
DRIFT（Dynamic Reasoning and Inference with Flexible Traversal）是微软 GraphRAG 2025 年新增的官方查询模式，定位在 local 与 global 之间：先用问题与 top-K 社区报告比对生成初步答案与跟进问题（primer），再对每个跟进问题跑 local search 逐步下钻，置信度控制扩展轮数，输出按相关度排序的问题-答案层级树。解决的问题：local 太窄（复杂问题覆盖不全）、global 太贵且不能下钻细节，DRIFT 用"全局打底 + 局部迭代求精"换折中成本。
Q15：给你一个新语料库（如 10 万篇技术博客），设计 GraphRAG 落地路径。
四步：(1) 查询日志分桶——抽样标注多跳/全局/事实/开放语义占比，确认图检索的理论优势桶值得投入；(2) 小样本判别实验——用 LightRAG（工程成本最低）抽 5000 篇试点，跑 2WikiMultihopQA 风格的多跳集 + 20 个真实全局问题，与调优后的向量 RAG 对比；(3) 决策：多跳桶收益显著则扩展并引入图存储（PG + 向量扩展起步），全局桶有需求则评估 GraphRAG 全量索引成本或 Lazy 方案；(4) 生产化——混合路由 + RRF、抽取审计门禁、级联删除、分环节成本看板。全程记住一条纪律：图检索是混合架构里的增强支线，评估不过就降级为纯向量，不动主链路。