向量数据库 (Vector DB) 还没学明白？2026 年面试已经开始考“图向量数据库 (GraphRAG)”了

随着大语言模型应用架构的极速演进，RAG 技术栈正经历着一场从“概率性模糊匹配”向“确定性结构化认知”的深刻变革。当绝大多数开发者仍沉浸在优化 Embedding 模型或调整切片策略的局部细节时，技术风向标已悄然转向能够处理复杂逻辑与全局信息的 GraphRAG 架构。这一转变的底层逻辑在于，传统的向量数据库虽然在“寻找相似点”上表现卓越，却在“连接离散点”上存在天然的架构缺陷，导致其在面对需要跨文档多跳推理（Multi-hop Reasoning）或进行宏观全局摘要（Global Summarization）时往往显得力不从心。GraphRAG 并非单纯的工具迭代，而是一种工程范式的重构：它通过引入知识图谱技术，利用 LLM 在索引阶段进行高成本的实体关系抽取，并结合 Leiden 社区发现算法预先生成层级化的社区摘要，从而让系统具备了能够穿透碎片化信息的“上帝视角”。这意味着 RAG 的重心正从查询时的轻量级检索，转移到了离线阶段重型的 ETL 数据流水线构建上。对于渴望在 2026 年技术浪潮中站稳脚跟的架构师与高级工程师而言，深入理解 GraphRAG 如何通过结构化索引解决 Vector RAG 的“推理缺失”与“盲目飞行”问题，已不再是选修课，而是从单纯的“调包侠”晋升为复杂数据链路设计者的核心分水岭。

为什么 GraphRAG 突然成为面试和架构的新热点？

在 2024 年至 2025 年的技术面试中，面试官逐渐从单纯考察“如何优化 Embedding 模型”转向了更深层次的架构问题：“当单纯的向量检索无法回答跨文档的全局性问题时，你该怎么办？”

GraphRAG（Graph-based Retrieval-Augmented Generation）之所以迅速成为架构新热点，并非因为它是单纯的新概念，而是因为它精准解决了标准 Vector RAG 在生产环境中遇到的“点连接（Dot Connection）”瓶颈。简单来说，向量数据库擅长找到点（Find Dots），而图数据库擅长连接点（Connect Dots）。

核心痛点：向量检索的“局部性”与“推理缺失”

传统的基于向量数据库的 RAG（Vector RAG）本质上是一个概率性的“最近邻搜索”系统。它将文本切块（Chunking）并转化为向量，然后根据余弦相似度召回最相关的片段。

这种架构在处理“事实查证”类问题时表现出色，但在面对以下两类场景时往往会失效，而这正是企业级应用最急需的能力：

1. 多跳推理（Multi-hop Reasoning）：问题需要跨越多个文档才能得出结论。例如，“A 公司的供应商 B 最近的财务危机是否会影响 A 公司下个季度的产品发布？”向量检索可能分别找到关于 A 公司和 B 公司的文档，但很难自动推导出它们之间的因果链条。
2. 全局摘要（Global Summarization）：例如“这个数据集主要讨论了哪些宏观趋势？”向量数据库只能检索出 top-k 个具体片段，无法“阅读”整个语料库来归纳全貌。

正如 FalkorDB 的基准测试 所指出的，在涉及 KPI 追踪、战略规划等强 Schema 依赖的查询中，如果缺乏实体对齐（Entity Alignment），传统的向量 RAG 往往“盲目飞行”，准确率甚至可能接近于零。

GraphRAG 是什么？一个工程化的定义

GraphRAG 并不是要取代向量数据库，而是通过引入“结构化知识”来增强检索层。它将非结构化文本转化为知识图谱，使 LLM 能够理解实体之间的关系。

一个标准的 GraphRAG 工作流通常包含以下四个关键步骤，这也是面试中定义该技术的标准答案：

1. 源文本切分（Source Text Chunking）：与传统 RAG 类似，将文档切分为处理单元。
2. 元素抽取（Element Extraction）：利用 LLM 识别文本中的实体（Entities）（如人名、组织、概念）和关系（Relationships），并生成结构化的三元组（Subject-Predicate-Object）。
3. 图构建与社区聚类（Graph Construction & Clustering）：将提取的数据构建为图谱，并使用 Leiden 算法 等技术检测“社区（Communities）”，即紧密相关的实体群组。
4. 增强查询（Augmented Querying）：在检索时，不仅利用向量相似度，还利用图的拓扑结构（如社区摘要、路径遍历）来生成答案。

具象化对比：从“Apple”看两者区别

为了向非技术利益相关者或在面试中清晰阐述两者的区别，可以使用以下对比：

• Vector RAG（寻找相似）：当你查询“Apple”时，系统会检索出所有包含“Apple”、“iPhone”或“MacBook”关键词的高相似度文档片段。它回答的是“有哪些关于 Apple 的资料？”
• GraphRAG（理解关系）：系统不仅知道“Apple”是一个公司，还通过图谱知道“Foxconn”是其“供应商”，“芯片短缺”是当前的“市场趋势”。当你问“市场趋势如何影响 Apple 的产能？”时，GraphRAG 能沿着 Apple -> Supplier -> Market Trend 的路径进行推理。它回答的是“Apple 与外部因素是如何关联的？”

PuppyGraph 的技术分析 很好地总结了这一点：GraphRAG 将焦点从“哪个文档提到了 X？”转移到了“X 是如何与 Y 产生关联的？”。这种从局部匹配到全局理解的跨越，正是架构师和高级工程师在面试中需要展现的思维深度。

核心架构拆解：GraphRAG 是如何工作的？

要真正理解 GraphRAG，首先需要打破对传统 RAG 的固有认知：GraphRAG 不仅仅是一个查询时的检索策略，它本质上是一个重型的离线数据处理流水线（Data Pipeline）。

在标准的向量 RAG 中，架构相对简单：文档 -> 切片 -> 向量化 -> 存入向量库。这是一个线性的、“懒惰”的处理过程，大部分智能工作留给了查询时的 LLM。

相比之下，GraphRAG 的架构则是一个复杂的 ETL（Extract, Transform, Load）过程。在这个架构中，LLM 并不是在最后回答问题时才介入，而是在索引阶段就已经深度参与。它不再只是“阅读”文本，而是被用作一个“结构提取器”，负责将非结构化的文本转化为结构化的知识图谱。

从高层架构来看，GraphRAG 的工作流可以抽象为以下三个核心步骤：

1. 源数据处理与提取（Indexing Phase）：
   这是 GraphRAG 最具差异化的部分。系统首先将文本切分为更细粒度的单元（Text Units），然后利用 LLM 遍历这些单元，提取出实体（Entities）、关系（Relationships）以及协变量（Covariates）。这些提取出的信息不再是孤立的向量，而是构成了图谱中的节点和边。
2. 图谱构建与社区摘要（Graph Construction & Summarization）：
   数据不再以扁平的方式存储。系统会基于提取出的实体关系构建知识图谱，并利用算法（如 Leiden 算法）识别出不同层级的“社区”（Communities）。更为关键的是，系统会预先为每个社区生成自然语言摘要。这意味着系统在用户提问之前，就已经“预读”并总结了数据集中的主要主题和宏观结构。
3. 增强查询（Augmented Querying）：
   当用户发起查询时，系统不再仅仅依赖向量相似度检索（Vector Search），而是结合了图谱遍历和社区摘要。这种机制允许系统在回答“这个数据集主要讲了什么？”这类全局性问题（Global Search）时，能够直接调用预先计算好的社区摘要，或者在回答具体细节问题（Local Search）时，沿着图谱关系进行多跳推理。

简而言之，GraphRAG 的核心架构是从“基于统计的检索”向“基于结构的认知”的转变。接下来的部分，我们将深入拆解这个流水线中最关键的两个阶段：索引构建与查询执行。

阶段一：索引构建与 Leiden 社区发现

与传统向量数据库仅需“切片（Chunking）+ 嵌入（Embedding）”的轻量级索引过程不同，GraphRAG 索引构建是一个计算密集型的离线数据处理流水线（Pipeline）。在这个阶段，系统不仅仅是“存储”数据，而是利用 LLM 主动“理解”并重构数据结构。

整个索引过程可以拆解为以下三个核心步骤，其中实体提取与社区发现是区别于传统 RAG 的关键技术壁垒。

1. 实体与关系提取 (Element Extraction)

这是索引构建中最昂贵但也最具价值的步骤。系统将原始文本切分为 Text Units 后，并非直接存入向量库，而是通过 LLM 并行处理这些切片。

• 提取逻辑：LLM 被要求识别文本中的所有实体（Entities，如人名、机构、专有名词）以及实体之间的关系（Relationships）。
• 结构化输出：输出结果通常是三元组（Triples）形式，例如 (Entity A, Relationship, Entity B)，并附带由 LLM 生成的简短描述。
• 工程挑战：正如 DataCamp 的分析 所述，extract_graph 阶段占据了绝大部分的 LLM 调用成本。为了处理大规模语料，通常需要设计精细的 Prompt 策略以减少幻觉并合并重复实体（Entity Resolution）。

2. 图构建与拓扑生成

一旦提取完成，系统会利用 NetworkX 或类似的图算法库，将上述三元组构建为一个巨大的无向图。此时，原本分散在不同文档切片中的信息，通过共享的实体节点被物理连接起来。这解决了传统 RAG 的“碎片化”问题——即便两个相关的论点相隔数千页，只要它们涉及同一个实体，图结构就能将它们关联。

3. Leiden 算法与分层社区发现 (Hierarchical Community Detection)

这是 GraphRAG 实现“全局概览”能力的核心算法。在构建好的图谱上，系统应用 Leiden 算法来进行社区检测。

• 为什么是 Leiden？ 相比传统的 Louvain 算法，Leiden 算法在处理大规模网络时能生成连接更紧密、且数学上保证连通性的社区（Community），避免了图分割中的断连现象。
• 分层结构：算法会递归地执行，生成多层级的社区结构：
• • Level 0：微观社区，可能仅包含 5-10 个紧密相关的实体（例如“特定 API 的错误处理模块”）。
  • Level 1/2：中观社区，聚合了相关的微观社区（例如“整个后端架构”）。
  • Level 3+：宏观社区，代表数据集中最高层级的主题（例如“系统稳定性与性能优化”）。

4. 生成社区摘要 (Community Summaries)

这是 GraphRAG 索引构建的最后一步，也是其“预计算（Pre-computation）”思想的体现。系统会针对每一个检测到的社区，再次调用 LLM 生成一份社区摘要（Community Report）。

这些摘要不仅仅是数据的压缩，而是对该社区内所有实体和关系的“高维解读”。当用户后续提问“这份文档主要讲了什么？”时，系统实际上是在检索这些预先生成的社区摘要，而非遍历原始文本。这种机制使得 GraphRAG 能够极其高效地回答全局性问题（Global Search），填补了向量数据库在宏观理解上的空白。

阶段二：全局检索 (Global) vs 局部检索 (Local)

在 GraphRAG 的架构设计中，构建好图谱仅仅是第一步。面试官考察的核心往往在于：面对不同类型的用户 Query，系统是如何利用图结构来检索答案的？ 这里的关键分水岭在于“局部检索”与“全局检索”。

许多开发者容易陷入误区，认为 GraphRAG 只有一种“顺藤摸瓜”的查找方式。实际上，为了解决向量数据库在“跨文档归纳”能力上的短板，现代 GraphRAG（特别是参照 Microsoft 架构的实现）引入了基于社区摘要（Community Summaries）的全局检索模式。

1. 局部检索 (Local Search)：顺藤摸瓜

这是最直观的图检索方式，类似于传统的图数据库查询。

• 机制：从 Query 中提取实体（Entity），在图谱中定位这些起点，然后通过关系边（Edges）向外进行 K-hop（多跳）遍历，获取相邻的实体和关系描述。
• 适用场景：针对特定的实体或具体细节的查询。
• 用户意图映射：当用户问 "谁是 X？" 或 "A 和 B 之间有什么关系？" 时，系统使用的是局部检索。
• 优势：精度极高，能发现向量相似度无法捕捉的隐式连接（例如：A 控股 B，B 投资 C，Vector DB 很难直接关联 A 和 C，但图查询可以）。

2. 全局检索 (Global Search)：上帝视角

这是 GraphRAG 区别于传统 RAG 的杀手锏。向量检索擅长找“相似”，但在面对“全库归纳”类问题时往往束手无策（因为答案分散在成千上万个切片中，无法一次性召回）。

• 机制：在索引阶段，系统利用 Leiden 算法 等社区发现技术将节点聚类，并预先生成每个社区的“总结报告”（Community Reports）。查询时，系统不再遍历具体的点和边，而是直接检索这些高层级的社区摘要，通过 Map-Reduce 的方式生成整体答案。
• 适用场景：针对整个数据集的宏观理解、主题归纳或全貌描述。
• 用户意图映射：当用户问 "总结这份财报的主要风险点是什么？" 或 "这个数据集主要讨论了哪些技术流派？" 时，系统使用的是全局检索。

3. 决策对比表

在实际工程落地或面试回答中，建议使用下表清晰区分两者的应用边界：

面试避坑指南：
不要简单地说“GraphRAG 比 Vector RAG 好”。你应该强调：Vector RAG 在处理 Global Query 时常常失效（因为 Top-K 召回不仅窗口有限，而且容易丢失全局上下文），而 GraphRAG 通过“全局检索”模式，利用图的层级结构（Hierarchical Structure）补齐了这一短板。

Microsoft GraphRAG vs. 通用知识图谱 RAG：别搞混了

在面试中，当面试官问到“你了解 GraphRAG 吗？”时，这通常是一个陷阱题。你需要首先澄清对方指的是 Microsoft 在 GitHub 上开源的 graphrag 库，还是指更广泛的 “知识图谱增强检索” (Knowledge Graph RAG) 这一架构模式。

混淆这两个概念是初学者最容易犯的错误。为了展示你的技术深度，你需要清楚地划定二者的界限，并理解它们在成本、延迟和适用场景上的巨大差异。

1. Microsoft GraphRAG：一种特定的“重”实现

Microsoft 的 GraphRAG 并不是 Graph RAG 的全部，它只是其中一种特定的、高度结构化的实现方案。它的核心卖点在于解决“全局问题”（Global Questions），例如“这就数据集主要讲了什么主题？”。

为了实现这一点，它采用了一套非常“重”的索引流程：

• 社区摘要 (Community Summaries)：它使用 Leiden 算法对图谱进行聚类，并递归地生成各层级社区的自然语言摘要。
• 高昂的构建成本：这种方法在索引阶段就需要消耗大量 Token 来生成摘要。正如行业讨论所指出的，这种架构处理单个文档的成本可能非常高昂，且对于频繁更新的数据集并不友好，因为新数据可能需要触发社区的重新计算。
• 静态性：它更像是一个生成好的“静态知识库”，而不是一个随时可以插入新三元组并立即查询的实时数据库。

面试得分点：指出 Microsoft GraphRAG 在“全库摘要”上的优势，但同时要提及它在增量更新和 Token 成本上的挑战。

2. 通用知识图谱 RAG：一种灵活的架构模式

相比之下，通用的 Knowledge Graph RAG 是一个更广泛的概念，指的是任何利用图结构来增强 LLM 上下文的技术。你完全不需要依赖 Microsoft 的库来实现它。

在通用的工程实践中，GraphRAG 通常指以下轻量级流程：

1. 混合检索：同时检索向量数据库（相似度）和图数据库（邻居关系）。
2. 子图遍历：找到实体后，向外扩展 1-2 跳（Multi-hop），获取关联实体作为上下文。
3. 灵活的技术栈：你可以使用 Neo4j、NebulaGraph 或 Memgraph 配合 LlamaIndex 来构建。

这种方式不需要预先生成昂贵的社区摘要，支持实时数据写入，且延迟更低，非常适合“实体中心”的查询（例如“A 公司和 B 公司的共同股东是谁？”）。

3. 核心差异对比表

在面试中，可以用下表来总结你的理解，展示你具备架构选型的能力：

总结：不要让面试官觉得你只会跑 Demo。你要表达出：虽然 Microsoft 的库在处理宏观摘要时很惊艳，但在大多数企业级实时业务场景（如实时风控、客服问答）中，构建一个基于通用图数据库的轻量级 GraphRAG 往往是性价比更高的选择。

落地实战：开源方案与代码思路 (Hello World)

在面试中，面试官经常会要求：“不要只讲概念，写一段伪代码描述你是如何构建 GraphRAG 的。”

很多候选人卡在这里，因为目前市面上缺乏统一的“Hello World”标准。微软的 GraphRAG 库虽然强大，但过于复杂且封装较深。为了展示你对原理的掌控，建议从通用的 GraphRAG 开源方案（如 LangChain + Neo4j/NebulaGraph + LLM）切入，描述一个“最小可行性系统”（MVP）。

一个完整的 GraphRAG 落地逻辑通常包含四个核心步骤：结构化抽取、图谱构建、混合检索、生成回答。

1. 结构化抽取 (Extraction Chain)

这是 GraphRAG 与传统 RAG 最大的区别。你不能直接存文本块（Chunk），必须先将非结构化文本转化为结构化的“三元组”（实体-关系-实体）。

这是成本最高的一步，极其依赖 Prompt Engineering。你需要定义一个 LLM Chain，要求它输出严格的 JSON 格式。

# 伪代码逻辑：定义抽取结构
class KnowledgeTriple(BaseModel):
    subject: str
    predicate: str  # 关系，如 "WORKSFOR", "LOCATEDIN"
    object: str

# 核心难点：Prompt 必须限制 LLM 不产生幻觉，并进行实体消歧
extractionprompt = """
分析以下文本，提取实体及其关系。
输出格式必须为 JSON 列表：[{"subject": "...", "predicate": "...", "object": "..."}]
文本内容: {textchunk}
"""

# 运行抽取链
# 实际生产中常用 LangChain 的 LLMGraphTransformer 或类似工具
triples = llmchain.run(prompt=extractionprompt, textchunk=rawtext)

2. 图谱构建与入库 (Upsert to Graph Store)

拿到三元组后，不能直接插入，必须处理实体对齐（Entity Resolution）。例如，“Elon Musk”和“Musk”应该是同一个节点。

在这一步，你需要强调对数据库约束（Constraints）的理解，这是生产环境稳定性的关键。正如 Sunil Kumar Goyal 的实践分享 中指出的，必须在图数据库中预先创建唯一性约束（Unique Constraints），防止节点重复。

// Cypher 伪代码：使用 MERGE 保证幂等性（存在则更新，不存在则创建）
MERGE (s:Entity {name: subject})
MERGE (o:Entity {name:object})
MERGE (s)-[r:RELATIONSHIP {type: $predicate}]->(o)

同时，为了支持后续的混合检索，你通常还需要将实体的描述文本或原始文本块向量化，并存储在图数据库的向量索引中（如 Neo4j Vector Index），或者关联到一个独立的向量库 ID。

3. 混合检索 (Hybrid Retrieval)

这是面试的加分项。不要只说“查询图谱”，要展示“向量 + 图”的组合拳。

逻辑流程如下：

1. 向量检索 (Vector Search)：用用户的 Query 向量化，在图数据库中找到最相似的 Top-K 个“锚点节点”（Anchor Nodes）。
2. 图遍历 (Graph Traversal)：从这些锚点出发，向外跳跃 1-2 跳（Multi-hop），获取关联的上下文。

def hybridquery(userquery):
    # 1. 向量检索找到入口节点
    anchornodes = vectorindex.similaritysearch(userquery, k=5)

contextlist = []
    for node in anchornodes:
        # 2. 图遍历：获取该节点周围的邻居信息 (Cypher)
        # 意图：不仅知道“它是谁”，还知道“它和谁有关”
        graphcontext = graphdb.query(
            "MATCH (n {id: $id})-[r]->(m) RETURN n, r, m LIMIT 10", 
            params={"id": node.id}
        )
        contextlist.append(graphcontext)

return context_list

4. 生成回答 (Generation)

最后一步回归传统的 RAG 逻辑。将检索到的“图谱结构化文本”与“原始文档片段”拼接，喂给 LLM。

技术陷阱提示（E-E-A-T 关键点）：
在面试中，除了展示代码逻辑，务必提及落地成本。

• Token 消耗：GraphRAG 的抽取过程会消耗大量 Token，构建成本通常是普通 RAG 的 10 倍以上。
• 延迟问题：实时图遍历（Graph Traversal）比纯向量检索慢，因此在 Neo4j 的 RAG 教程 等最佳实践中，常建议限制遍历深度（通常 1-2 跳即可），避免“图爆炸”导致上下文窗口溢出。

工程现实：GraphRAG 的落地成本与致命缺陷

在面试中，如果你只能复述 GraphRAG “能够捕捉全局信息”和“解决多跳推理”的优点，只能说明你读过论文；但如果你能一针见血地指出其构建成本（Cost）、延迟（Latency）和维护难度（Maintenance），则证明你有真实的工程落地视角。

GraphRAG 并非 Vector DB 的简单替代品，而是一个在特定场景下不得不接受的“昂贵妥协”。以下是资深工程师必须直面的三个现实痛点。

1. 惊人的索引成本 (Token Cost)

传统的 RAG 索引过程极其廉价：将文本切片，通过 Embedding 模型（如 OpenAI text-embedding-3-small）转化为向量，存入 Milvus 或 Pinecone。这个过程的计算量很小，且 Embedding 模型的单价通常远低于生成模型。

相比之下，GraphRAG 的索引过程是一个Token 焚烧炉。

• 全量 LLM 处理：系统必须使用 LLM（通常是 GPT-4o 或同等级别模型）读取每一个文本切片，从中提取实体（Entities）、关系（Relationships）和声明（Claims）。
• 社区摘要生成：在图构建完成后，还需要对生成的社区（Communities）进行多轮摘要生成。

根据 arXiv 上的最新研究，基于 LLM 的图构建成本极高，有估算显示，仅索引 5GB 的法律文档，成本可能高达 33,000 美元。这种对 LLM 的重度依赖使得 GraphRAG 在大规模数据集上的冷启动成本远超传统向量方案 10 倍甚至 100 倍。

2. 难以忽视的查询延迟 (Latency)

在向量数据库中，ANN（近似最近邻）搜索通常在毫秒级完成。而在 GraphRAG 中，查询延迟是工程落地的最大阻碍之一，具体取决于查询模式：

• Local Search（局部搜索）：虽然可以利用索引加速，但仍需遍历图结构并组合上下文，速度慢于纯向量检索。
• Global Search（全局搜索）：这是 GraphRAG 的核心卖点（如“总结全库内容”），但其原理本质上是一个 Map-Reduce 过程。系统需要并行生成数十甚至上百个社区的回答，最后由 LLM 进行汇总。这导致端到端延迟往往在 10秒甚至分钟级，完全无法满足 C 端用户“秒开”的实时交互需求。

3. “增量更新”的维护噩梦

这是面试官最喜欢追问的深水区：“如果我新加了一个文件，或者修改了某段话，GraphRAG 怎么更新？”

在向量数据库中，你只需 Upsert 几个向量即可。但在 GraphRAG 中，数据的互联性导致了牵一发而动全身：

1. 社区聚类漂移：新加入的实体可能会改变原有的社区结构（Leiden 算法聚类结果变化），导致之前生成的社区摘要（Community Reports）失效。
2. 冲突处理：如果旧文档说“天空是蓝色的”，新文档说“天空是红色的”，图结构如何处理这种矛盾？GitHub 社区讨论 指出，目前的 GraphRAG 实现对增量更新（Incremental Updates）的支持并不像向量库那样平滑，往往需要重新计算受影响的子图甚至全量重建索引。
3. 静态摘要的局限：正如 Weaviate 的技术分析 所述，LLM 生成的静态摘要很难实时捕捉新数据带来的细微变化，这迫使工程团队必须在“数据新鲜度”和“重构成本”之间做艰难的权衡。

总结：工程决策对照表

在设计系统架构时，建议参考以下对比来决定是否引入 GraphRAG：

结论：除非业务场景明确需要“跨文档的全局概括”或“深层关系推理”，否则不要为了技术时髦度而盲目上 GraphRAG。大多数情况下，一个优化良好的混合检索（Hybrid Search, 关键词+向量）依然是性价比最高的选择。

面试通关指南：面试官会怎么考 GraphRAG？

在 2026 年的技术面试中，GraphRAG 不仅仅是一个“加分项”，它正在迅速演变为考察候选人系统设计能力和工程权衡思维的核心考点。面试官不再满足于你能够调用 LangChain 或 LlamaIndex 的接口，他们更关注你是否理解从“向量检索”到“图检索”的范式转变，以及在生产环境中如何处理高昂的成本与延迟。

以下是 3-4 个高频面试题及其“满分”回答策略，帮助你从架构师的视角应对挑战。

Q1：在什么场景下，你会坚决选择 GraphRAG 而不是传统的 Vector RAG？

考察点： 候选人是否真正理解向量检索的局限性（Connectivity vs. Similarity）。

参考回答策略：
不要只回答“当精度要求高的时候”。你应该从“全局摘要（Global Summarization）”和“多跳推理（Multi-hop Reasoning）”两个维度切入：

“我会基于查询的类型来做决定。传统的 Vector RAG 依赖语义相似度，它非常适合处理局部事实查询（如‘XX 的定义是什么’）。但是，当业务场景涉及以下两种情况时，Vector RAG 会失效，必须引入 GraphRAG：

1. 跨文档的全局性问题：例如‘请总结这 100 份财报中提到的主要风险趋势’。向量检索只能找到零散的片段，无法聚合出宏观的‘社区（Community）’视角。
2. 长链路推理：如果答案需要连接 A->B->C 的关系（例如供应链上下游影响），向量数据库往往会因为丢失结构信息而导致检索中断。根据 Memgraph 的对比分析，GraphRAG 的核心优势在于它检索的是‘连接的上下文’，而不仅仅是孤立的文本块，这对于需要结构化认知的场景至关重要。”

Q2：GraphRAG 的索引成本极高，你有哪些优化方案？

考察点： 考察工程落地经验。面试官知道 GraphRAG 需要 LLM 遍历所有文本进行实体抽取，Token 消耗是巨大的。

参考回答策略：
你需要展示对成本结构的清晰认知，并提出分层优化的方案：

“GraphRAG 的成本瓶颈主要在于图构建阶段的实体抽取。为了优化这一点，我会采取以下策略：

1. 混合检索策略（Hybrid RAG）：并非所有数据都需要进图。对于非核心文档，保留低成本的向量索引；仅对核心知识库构建图索引。研究表明，混合 GraphRAG 在事实正确性上往往优于单一方案，且能平衡成本。
2. 模型降级与蒸馏：在实体抽取（Entity Extraction）阶段，使用更便宜的小模型或经过微调的专用模型（如 7B 参数级别），而不是用昂贵的 GPT-4，只在最终生成的推理阶段使用大模型。
3. 图结构精简：通过限制抽取的实体类型（Schema 约束）或合并低频节点来降低图的密度。正如 FalkorDB 的建议，在查询时可以利用复合索引并推迟属性访问，从而减少不必要的计算开销。”

Q3：请解释“自顶向下（Top-down）”与“自底向上（Bottom-up）”构建知识图谱的区别？

考察点： 考察对数据治理和图谱构建理论的理解。

参考回答策略：

“这取决于我们是否拥有预定义的 Schema：

* 自顶向下（Top-down）：适用于企业内部有明确数据标准的场景（如医疗、金融）。我们需要先定义好 Ontology（本体），规定有哪些实体类型（如‘药物’、‘症状’）和关系，然后让 LLM 按图索骥去抽取。这种方式精度高，噪声少，适合Schema 密集型查询。
* 自底向上（Bottom-up）：适用于探索性场景，如处理海量未知的新闻或情报。我们不预设 Schema，而是使用 Leiden 算法等社区发现技术，让数据自然聚类形成‘社区’。Microsoft 的 GraphRAG 默认就是这种模式，它擅长发现未知的隐藏关系，但可能会引入较多噪声。”

Q4：如果数据源频繁更新，如何维护 GraphRAG 的索引？

考察点： 这是一个“深水区”问题，考察你是否处理过真实的生产痛点。

参考回答策略：

“这是一个复杂的工程难题，因为图结构的改变可能会牵一发而动全身（例如改变社区聚类结果）。

简单的‘增量插入’可能会破坏原有的社区报告（Community Reports）。在实际工程中，我们通常采用‘软更新’策略：新文档暂时只进入向量索引或临时图谱，通过混合检索覆盖最新信息；而在低峰期（如周末），对图谱受影响的子图（Sub-graph）进行局部的重构和社区重新聚类。这是一种在实时性和维护成本之间的折衷。”