第10章知识图谱与图RAG传统向量RAG通过文本分块与稠密向量检索为大型语言模型提供外部知识，在点对点的事实型问答场景

传统向量RAG通过文本分块与稠密向量检索为大型语言模型提供外部知识，在点对点的事实型问答场景中表现优异。然而，当面对需要多跳推理、全局主题理解或复杂关系梳理的查询时，纯向量检索往往力不从心。知识图谱（Knowledge Graph）以其结构化的实体-关系-实体三元组表示，天然擅长建模事物之间的关联与层次结构，恰好弥补了向量检索在关系推理上的短板。将知识图谱与RAG深度融合，催生了图RAG（Graph RAG）这一重要技术方向。

本章将从知识图谱的核心概念出发，深入解析微软GraphRAG、LightRAG等代表性架构的原理与实现，系统梳理基于实体链接、图遍历和混合检索的多种KG-RAG路径，并探讨知识图谱的构建与维护策略。最后，通过对比分析与实战代码，帮助读者掌握知识图谱增强RAG检索的关键技术。

10.1 知识图谱基础与RAG的契合点

10.1.1 知识图谱的核心概念

知识图谱是一种以图结构组织知识的语义网络，其基本组成单元是三元组（Triple），即"主语-谓语-宾语"（Subject-Predicate-Object）形式的断言。例如，"（爱因斯坦，出生于，乌尔姆）"就是一个典型的三元组，其中"爱因斯坦"和"乌尔姆"是实体（Entity），"出生于"是关系（Relation）。实体可以拥有属性（Attribute），如爱因斯坦的出生年份为1879年。大量三元组通过共享实体相互连接，形成一张大规模的语义网络。

从技术架构来看，知识图谱通常包含两个核心层次。模式层（Schema Layer）定义了本体（Ontology），即实体类型、关系类型及其约束规则，相当于图谱的"数据字典"。数据层（Data Layer）存储具体的实例数据，是三元组的大规模集合。在工业实践中，知识图谱的存储与查询通常依赖图数据库（Graph Database），如Neo4j、NebulaGraph、TigerGraph等，它们提供原生的图遍历与模式匹配能力，支持属性图模型（Property Graph Model）或资源描述框架（RDF）。

知识图谱的概念最早可追溯至2012年Google发布的Knowledge Graph，随后在搜索引擎、智能问答、推荐系统等领域获得广泛应用。在学术界，知识图谱的构建方法经历了从手工构建到半自动抽取，再到大语言模型驱动的高质量抽取的演进。2024年以来，随着GPT-4、Claude等大模型在信息抽取任务上的能力飞跃，基于LLM的知识图谱构建已成为主流范式，大幅降低了构建成本并提升了抽取质量。

10.1.2 知识图谱如何弥补向量检索的不足

向量检索的核心机制是将文本映射到高维稠密向量空间，通过余弦相似度或最大内积搜索（MIPS）找到语义最近的文本片段。这一机制在处理单一事实查询时效率很高，但存在几个根本性的局限。

第一，向量检索难以处理多跳推理（Multi-hop Reasoning）。当用户询问"A公司的CEO的母校位于哪个城市"时，需要沿着"公司-CEO-母校-城市"的关系链进行推理，而向量检索只能找到语义上与整个问题最相似的文本块，无法显式地沿着关系路径进行跳转。知识图谱通过图遍历可以精确地沿着关系链路导航，天然支持多跳查询。

第二，向量检索缺乏对全局主题的理解能力。传统RAG的检索结果取决于单个文本块与查询的相似度，无法从全局视角把握数据集的整体结构和主题分布。当用户提出"这份财报中反映的核心趋势是什么"这类全局性问题时，向量检索往往只能返回若干局部相关的片段，难以给出全局性的综合回答。知识图谱通过社区检测和层次化摘要，能够从宏观层面组织信息，为全局问答提供结构化支撑。

第三，向量检索的关系隐含性导致可解释性不足。在向量空间中，实体间的关系被压缩为隐式的向量距离，无法明确表达"A投资了B"或"C是D的子公司"这类结构化关系。知识图谱以显式的关系边记录实体间的语义关联，不仅支持精确的关系查询，还提供了清晰的推理路径，增强了系统的可解释性与可信度。

第四，向量检索在处理实体消歧（Entity Disambiguation）时容易出错。同名实体（如"苹果"可能指水果或公司）在向量空间中可能被映射到相近的位置，导致检索结果混淆。知识图谱通过唯一的实体标识符和类型约束，能够有效区分同名但不同含义的实体，提升检索精度。

正是这些互补特性，使得知识图谱与向量检索的融合成为RAG技术发展的重要方向。图RAG并非要取代向量RAG，而是在向量检索的基础上引入结构化知识，形成"向量+图谱"的双通道检索架构，从而兼顾语义匹配的灵活性与关系推理的精确性。

10.2 GraphRAG的原理与实现

10.2.1 微软GraphRAG架构解析

微软GraphRAG是由Darren Edge等人于2024年提出的一种基于图的检索增强生成方法，其核心论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》系统阐述了如何通过知识图谱与社区结构实现对私有数据集的全局性问答。与传统RAG仅在局部文本块上进行检索不同，GraphRAG在索引阶段构建完整的文档知识图谱，并通过社区检测算法发现文本中的主题社区，最终为每个社区生成层次化摘要。

GraphRAG的处理流程分为索引（Indexing）和查询（Querying）两个阶段。索引阶段首先对输入文档进行文本分块，然后利用大语言模型从每个文本块中抽取实体与关系，构建以实体为节点、关系为边的文档级知识图谱。接着，使用Leiden等社区检测算法对图谱进行层次化聚类，将紧密相连的实体划分为不同层级的社区。最后，为每个社区生成自然语言摘要，形成从局部实体到全局主题的多层次知识表示。

查询阶段提供两种检索模式。局部搜索（Local Search）从用户查询中识别相关实体，在图谱中检索其邻域子图，结合文本块与实体描述生成回答，适用于需要具体细节的场景。全局搜索（Global Search）则利用社区摘要构建层次化的中间表示，通过map-reduce策略对社区摘要进行聚合推理，生成覆盖全局主题的回答，适用于需要宏观理解的问题。

flowchart TD
    A[输入文档] --> B[文本分块]
    B --> C[LLM实体与关系抽取]
    C --> D[构建知识图谱]
    D --> E[Leiden社区检测]
    E --> F[层次化社区结构]
    F --> G[社区摘要生成]
    G --> H[索引完成]
    I[用户查询] --> J{查询类型}
    J -->|局部搜索| K[实体识别与邻域检索]
    J -->|全局搜索| L[社区摘要聚合推理]
    K --> M[结合文本块生成回答]
    L --> M

GraphRAG的架构设计体现了"先理解全局，再回答局部"的理念。通过在索引阶段预先计算社区结构及其摘要，GraphRAG将复杂的全局推理问题转化为对预计算摘要的检索与聚合问题，显著降低了对大模型上下文窗口的压力，同时提升了回答的全局一致性和主题覆盖度。

10.2.2 社区检测与层次化摘要

社区检测（Community Detection）是GraphRAG架构中的关键环节，其目标是在知识图谱中发现内部连接紧密、外部连接稀疏的实体集群。微软GraphRAG采用Leiden算法作为默认的社区检测方法，该算法是Louvain算法的改进版本，能够产生连通性更好且质量更高的社区划分。

Leiden算法基于模块度（Modularity）优化原理。模块度衡量的是社区内部边数与随机图期望边数之间的差异，模块度越高说明社区划分质量越好。算法从每个节点独立成社区开始，通过迭代地将节点移动到能最大化模块度增益的邻居社区，逐步优化社区结构。在层次化场景下，算法可以在不同分辨率参数下运行，生成从细粒度到粗粒度的多层社区结构。

在社区检测完成后，GraphRAG为每个社区生成自然语言摘要。摘要生成采用层次化策略：首先为最底层的叶节点社区生成摘要，描述该社区涉及的核心实体、关键关系和主要事件；然后将子社区摘要作为输入，为上层社区生成更高层次的概括性摘要。这种自底向上的摘要生成方式确保了每个层级的摘要都能准确反映其所辖范围的核心内容，同时避免了将所有信息压缩到单一摘要中导致的信息丢失。

层次化摘要的价值在于，它为全局搜索提供了一种高效的"中间表示"。当用户提出全局性问题时，系统不需要遍历所有原始文本，而是从高层社区摘要开始，逐步下钻到与问题最相关的子社区，在有限的上下文窗口内实现高效的全局推理。这种设计在处理大规模文档集时尤为重要，因为它将查询时的计算复杂度从与文档量线性相关降低为与社区层级深度相关。

10.2.3 全局问答与局部问答

GraphRAG的双模式查询机制是其区别于传统RAG的核心特征。局部问答（Local Search）的工作流程与传统RAG较为相似，但引入了图谱结构作为检索增强。系统首先从用户查询中提取关键实体，然后在知识图谱中检索这些实体的邻域子图，包括直接关联的实体、关系和对应的原始文本块。这些图谱上下文与文本上下文共同构成检索结果，送入大语言模型生成最终回答。局部问答特别适合"某实体的具体属性是什么"这类聚焦型问题。

全局问答（Global Search）则采用完全不同的策略。它不依赖实体级别的精确匹配，而是利用社区摘要的层次化结构进行map-reduce式推理。在map阶段，系统将用户查询与所有社区摘要进行匹配，为每个社区生成一个部分回答；在reduce阶段，系统将所有部分回答进行聚合，生成最终的全局性回答。为了控制计算成本，GraphRAG通常只对高层社区摘要执行map操作，并根据需要递归地下钻到更细粒度的社区。

在实际应用中，全局问答在以下场景中展现出显著优势：对长篇报告进行主题性总结、分析跨文档的人物关系网络、梳理事件的时间线与因果链、以及回答"整体趋势如何"等宏观问题。Edge等人的实验表明，在全局理解类任务上，GraphRAG的回答质量显著优于传统的向量RAG，尤其是在回答的全面性（Comprehensiveness）和多样性（Diversity）两个维度上。

值得注意的是，GraphRAG的索引成本较高，因为需要调用大量LLM进行实体抽取和社区摘要生成。针对这一问题，微软在2025年推出了LazyGraphRAG，将社区摘要的生成延迟到查询时进行，使索引成本降至完整GraphRAG的0.1%，代价是每个查询增加2至8秒的延迟。这一改进使GraphRAG更适合成本敏感或数据频繁更新的场景。

10.3 KG-RAG的多种实现路径

10.3.1 基于实体链接的KG-RAG

基于实体链接（Entity Linking）的KG-RAG是最直接的图谱增强检索方式。其核心思路是：先将用户查询中的 mentions（提及串）链接到知识图谱中的实体节点，然后以这些实体为锚点，检索其关联的子图信息作为上下文，最后送入大语言模型生成回答。

实体链接通常包含两个步骤。实体识别（Named Entity Recognition, NER）负责从查询文本中识别出实体提及，如从"苹果公司2024年的营收是多少"中识别出"苹果公司"。实体消歧（Entity Disambiguation）则将识别出的提及映射到知识图谱中的唯一实体节点，需要结合上下文语义和实体类型信息进行判断。在大模型时代，实体识别和消歧可以通过prompt工程统一完成，让LLM直接输出查询中涉及的实体及其图谱标识符。

在检索阶段，系统以链接到的实体为中心，沿着知识图谱中的关系边进行一跳或多跳扩展，收集相关实体的属性和关系描述。这些结构化信息被序列化为自然语言文本，与原始文档片段一起构成增强上下文。例如，当查询涉及某公司时，系统可以自动检索其创始人、总部所在地、主要产品线、竞争对手等关联信息，即使这些信息分散在不同的文档中。

基于实体链接的KG-RAG实现相对简单，与现有RAG管道的兼容性好，适合在已有知识图谱的企业中快速落地。其主要局限在于：对查询中未明确提及的实体无法主动发现，且实体链接的准确性直接影响检索质量。在实践中，通常需要结合模糊匹配（Fuzzy Matching）和实体别名表（Entity Alias Table）来提升链接的召回率。

10.3.2 基于图遍历的KG-RAG

基于图遍历（Graph Traversal）的KG-RAG利用图数据库的原生查询能力，通过模式匹配和路径搜索在知识图谱中进行结构化检索。与实体链接方法不同，图遍历方法不局限于从特定实体出发，而是可以根据查询意图在图谱中灵活导航，发现更深层的关系路径。

图遍历的核心操作包括：邻域查询（Neighborhood Query），获取某节点的直接邻居；路径查询（Path Query），寻找两个实体之间的最短路径或所有路径；模式匹配（Pattern Matching），查找符合特定拓扑结构的子图。在Cypher查询语言（Neo4j的原生查询语言）中，这些操作可以通过声明式的图模式表达，例如 MATCH (a:Person)-[:WORKS_AT]->(c:Company)-[:LOCATED_IN]->(city:City) WHERE a.name = '张三' RETURN city.name。

基于图遍历的KG-RAG在处理多跳推理问题时表现尤为出色。例如，当用户询问"投资了某创业公司的知名投资人还有哪些投资项目"时，系统可以在知识图谱中沿着"投资人-投资-公司-被投资"的关系路径进行多跳遍历，发现隐藏在文档中的间接关联。这种能力是纯向量检索无法实现的，因为向量相似度无法精确捕捉多跳关系链。

图遍历方法的挑战在于查询路径的组合爆炸问题。当知识图谱规模较大时，两跳以上的遍历可能产生大量候选路径，需要引入路径排序（Path Ranking）机制来筛选最相关的路径。常见的排序策略包括：基于路径频率的统计排序、基于语义相关性的向量排序，以及基于大模型的路径相关性打分。2025年以来，一些研究工作将图神经网络（Graph Neural Network, GNN）引入路径排序环节，通过学习实体和关系的嵌入表示来提升排序质量。

10.3.3 混合向量-图谱RAG

混合向量-图谱RAG（Hybrid Vector-Graph RAG）是将向量检索与图谱检索相结合的统一架构，旨在同时发挥两种检索方式的优势。LightRAG是由Guo等人于2025年提出的一种轻量级混合检索框架，其核心创新在于双层检索范式（Dual-level Retrieval Paradigm），能够在不同抽象层次上高效检索信息。

LightRAG的索引阶段从文档中抽取实体和关系，构建知识图谱，并为每个实体和关系生成向量嵌入。与微软GraphRAG不同，LightRAG不需要预先进行社区检测和摘要生成，因此索引成本显著降低。在查询阶段，LightRAG从用户问题中提取高层关键词（如主题、概念）和低层关键词（如具体实体名），分别对应全局主题检索和局部实体检索。高层检索通过实体和关系的向量相似度找到相关主题的子图，低层检索通过精确实体匹配找到具体的事实信息，两种检索结果融合后送入大语言模型生成回答。

flowchart LR
    Q[用户查询] --> K[关键词提取]
    K --> H[高层关键词<br/>主题/概念]
    K --> L[低层关键词<br/>具体实体]
    H --> VS[向量相似度检索<br/>全局主题子图]
    L --> EM[实体匹配检索<br/>局部事实信息]
    VS --> F[结果融合]
    EM --> F
    F --> G[大语言模型生成回答]

下表对三种KG-RAG实现路径进行了系统对比。

维度	基于实体链接	基于图遍历	混合向量-图谱
核心机制	实体识别与消歧	图模式匹配与路径搜索	向量检索+图谱检索双通道
检索粒度	单实体邻域	多跳路径与子图	多层次（主题+实体）
多跳推理能力	弱（依赖预设规则）	强（原生支持路径遍历）	中等（向量辅助路径发现）
索引成本	低	中等	中等
查询延迟	低	中等（路径搜索耗时）	低至中等
适用场景	事实型问答、属性查询	关系推理、多跳问答	通用场景、主题与事实混合查询
代表系统	SPARQL-based KG-RAG	GraphQA、GremlinRAG	LightRAG、HippoRAG

混合架构的另一个重要实践方向是检索结果重排序（Re-ranking）。在初步检索阶段，向量通道和图谱通道分别返回候选结果集，然后通过交叉编码器（Cross-encoder）或大模型打分对合并后的候选集进行精排。这种"粗排+精排"的两阶段检索策略在2025年已成为企业级RAG系统的标准配置，能够显著提升最终检索结果的相关性和多样性。

10.4 知识图谱的构建与维护

10.4.1 从非结构化文本构建知识图谱

从非结构化文本中自动构建知识图谱是KG-RAG系统的基础环节，其核心任务是从自然语言文本中抽取实体、关系和事件，并将其组织为结构化的三元组。传统方法依赖命名实体识别（NER）、关系抽取（RE）等独立的自然语言处理流水线，需要针对每个任务训练专门的模型，且各任务之间的错误会级联传播。

大语言模型的出现彻底改变了知识图谱构建的范式。基于LLM的抽取方法通常采用prompt驱动的策略，让模型在一次或少量调用中同时完成实体识别、关系分类和三元组生成。例如，可以通过如下prompt模板指导LLM从文本中抽取知识："请从以下文本中抽取所有实体及其关系，以JSON格式输出三元组列表。实体类型包括人物、组织、地点、时间、事件。"这种方法的优势在于无需训练专门的抽取模型，且能够利用LLM的通用语言理解能力处理多样化的文本风格和领域术语。

在实际工程中，基于LLM的知识图谱构建面临几个关键挑战。抽取一致性（Extraction Consistency）是指同一实体在不同文本中可能被识别为不同的名称或类型，需要在后处理阶段进行实体对齐（Entity Alignment）和规范化。关系粒度（Relation Granularity）是指LLM可能生成过于笼统或过于细化的关系类型，需要通过关系类型约束和层次化关系体系来控制。幻觉问题（Hallucination）是指LLM可能生成文本中不存在的事实，需要通过溯源验证（Source Attribution）和置信度评估来过滤低质量三元组。

为了提升构建质量，2025年的最佳实践通常采用"LLM抽取+规则校验+人工审核"的三层质量保障机制。规则校验层通过预定义的本体约束（如"出生日期"的值必须是日期类型、"CEO"关系的主语必须是组织类型）自动过滤明显错误的三元组。对于高风险领域（如医疗、金融），人工审核层对关键实体和关系进行抽样验证，确保知识图谱的准确性满足业务要求。

10.4.2 知识图谱的更新与版本管理

知识图谱不是静态的知识库，而是需要随着新数据的产生持续演化的动态系统。知识图谱的更新策略取决于应用场景的数据特性，主要分为批量更新（Batch Update）和增量更新（Incremental Update）两种模式。

批量更新适用于数据周期性到达的场景，如每日新闻汇总、季度财报更新等。系统在固定时间窗口内收集新文档，执行完整的实体抽取、关系抽取和实体对齐流程，然后将新三元组合并到现有图谱中。批量更新的优势在于可以利用全局上下文进行更准确的实体消歧和关系推理，缺点是更新延迟较高，不适合实时性要求严格的场景。

增量更新适用于数据流式到达的场景，如社交媒体监控、实时新闻推送等。系统对新到达的文档立即执行抽取，并将新三元组实时插入图谱。增量更新的核心挑战在于：新实体可能与已有实体重复，需要高效的在线实体对齐；新关系可能与已有知识冲突，需要冲突检测与消解机制；频繁的小规模更新可能导致图谱碎片化，需要定期的合并与压缩。

知识图谱的版本管理（Version Management）是企业级应用中不可忽视的工程问题。与代码版本控制类似，知识图谱需要记录每次更新的变更内容、时间戳和来源，支持回滚到历史版本。在Neo4j等图数据库中，可以通过时间属性或时态图（Temporal Graph）扩展来支持版本管理。更高级的方案采用"主图谱+变更日志"的架构，主图谱存储当前最新的知识状态，变更日志以追加方式记录所有历史变更，支持任意时间点的图谱状态重建。

2025至2026年的行业实践表明，知识图谱的治理正在向自动化和智能化方向发展。一些领先的系统引入了知识图谱质量监控仪表盘，自动跟踪图谱的覆盖率、一致性、时效性等指标，并在指标低于阈值时触发告警和自动修复流程。此外，基于LLM的知识图谱补全（Knowledge Graph Completion）技术也日趋成熟，能够自动发现图谱中缺失的关系并建议候选三元组，进一步提升图谱的完整性和实用性。

10.5 KG-RAG vs 传统向量RAG的对比与选型

在选择RAG架构时，需要根据业务场景的具体需求在传统向量RAG和KG-RAG之间做出权衡。下表从多个维度对两种架构进行了系统对比。

对比维度	传统向量RAG	KG-RAG
检索机制	稠密向量相似度匹配	图遍历+向量检索
知识表示	隐式语义向量	显式实体-关系三元组
多跳推理	不支持（需依赖模型自身能力）	原生支持（图路径遍历）
全局理解	弱（局限于局部文本块）	强（社区摘要+层次化推理）
可解释性	低（检索过程是黑盒）	高（可追溯推理路径）
索引构建成本	低（文本分块+向量化）	高（实体抽取+图谱构建+社区检测）
查询延迟	低（毫秒级向量搜索）	中等至高（图遍历+摘要聚合）
数据更新	容易（增量添加向量）	较复杂（需维护图谱一致性）
适用查询类型	事实型、单一主题	关系型、多跳、全局主题
技术成熟度	高（生态完善）	中等（快速发展中）
典型工具	LangChain、LlamaIndex	Neo4j、GraphRAG、LightRAG

从选型策略来看，以下场景更适合采用KG-RAG架构。第一，多跳推理密集型场景，如法律条文关联分析、供应链关系追踪、家族谱系查询等，这些场景需要沿着关系链路进行多步推理，向量检索难以胜任。第二，全局理解型场景，如长篇报告的主题总结、跨文档趋势分析、组织架构全景梳理等，这些场景需要对数据集进行全局性的归纳和概括。第三，高可解释性要求场景，如金融风控、医疗诊断辅助等，这些场景需要清晰展示推理过程和知识来源，图谱的显式结构天然满足这一需求。

反之，以下场景更适合继续使用传统向量RAG。第一，简单事实型问答，如"某产品的规格参数是什么"，向量检索已经能很好地处理。第二，数据频繁更新的场景，如实时新闻问答，向量索引的更新成本远低于知识图谱。第三，资源受限的场景，如边缘设备或初创项目，向量RAG的构建和维护成本更低，技术栈更简单。

在实际企业应用中，越来越多的系统选择混合架构（Hybrid Architecture），即同时部署向量索引和知识图谱，根据查询类型动态选择检索通道或融合两种检索结果。这种架构虽然增加了系统的复杂度，但能够在各种查询类型上都获得较好的表现，是当前企业级RAG系统的发展趋势。2026年的行业调研显示，超过60%的大型企业RAG部署已经采用或计划采用向量-图谱混合架构。

10.6 实战：用知识图谱增强RAG检索

本节通过一个完整的Python示例，展示如何使用NetworkX构建轻量级知识图谱，并将其与向量检索结合实现混合RAG。该示例适用于快速原型验证和小规模数据场景，生产环境建议迁移至Neo4j等专用图数据库。

import networkx as nx
from sentence_transformers import SentenceTransformer

# 构建知识图谱
kg = nx.DiGraph()
triples = [
    ("张三", "就职于", "A公司"), ("A公司", "总部位于", "北京"),
    ("A公司", "合作伙伴", "B公司"), ("B公司", "总部位于", "上海"),
    ("张三", "毕业于", "清华大学"), ("清华大学", "位于", "北京"),
]
for s, r, o in triples:
    kg.add_edge(s, o, relation=r)

# 多跳推理：查询与张三有关联的城市
def multi_hop_query(kg, entity, max_hops=2):
    visited = {entity}
    results = []
    for _ in range(max_hops):
        neighbors = set()
        for node in visited:
            for neighbor in kg.neighbors(node):
                if neighbor not in visited:
                    rel = kg[node][neighbor]["relation"]
                    results.append(f"{node} --{rel}--> {neighbor}")
                    neighbors.add(neighbor)
        visited |= neighbors
    return results

# 向量检索补充语义匹配
model = SentenceTransformer("all-MiniLM-L6-v2")
docs = ["张三是A公司的高级工程师，负责AI研发。",
        "A公司与B公司在云计算领域深度合作。"]
doc_embeddings = model.encode(docs)
query_emb = model.encode("张三的工作关联")
scores = model.similarity(query_emb, doc_embeddings)[0]

# 融合图谱推理与向量检索
graph_ctx = multi_hop_query(kg, "张三")
vector_ctx = docs[scores.argmax()]
print(f"图谱上下文: {graph_ctx}\n向量上下文: {vector_ctx}")

上述代码演示了KG-RAG的核心流程。首先，通过三元组列表构建有向知识图谱，每条边携带关系类型属性。然后，multi_hop_query函数从指定实体出发，进行最多两跳的图遍历，收集路径上的实体和关系信息作为图谱上下文。同时，使用SentenceTransformer对文档进行向量编码，通过余弦相似度找到与查询最相关的文档片段作为向量上下文。最终，两种上下文可以一并送入大语言模型，生成融合了结构化关系知识和语义匹配信息的回答。

在扩展到生产环境时，需要关注以下几个关键点。首先，知识图谱的规模可能达到百万甚至千万级节点，此时应使用Neo4j等图数据库替代NetworkX，利用其索引和查询优化能力保证遍历性能。其次，实体抽取环节应引入LLM驱动的自动化流水线，替代手工编写三元组的方式。第三，检索结果的融合策略需要更精细的设计，如基于相关性的加权融合或基于大模型的动态路由。第四，应建立知识图谱的质量监控机制，定期评估抽取准确率、图谱覆盖率和实体一致性等指标。

第10章 知识图谱与图RAG