传统 RAG 擅长寻找相似段落，但面对跨文档关系、复杂事件链和全库主题总结时，经常出现“每一段都找到了，却没有把它们连起来”的问题。GraphRAG 与 LightRAG 都试图解决这个缺口，但两者并不是同一个方案的轻重版本。
图 1：传统向量 RAG 能找到相关片段，但不天然具备关系路径和全局结构。
一、为什么普通 RAG 会在复杂问题上失灵
向量检索的核心是“语义相似”。问题与某个文本块越像，这个文本块越容易被召回。对于产品手册、FAQ、制度条款等直接问答，这种方式非常有效。问题在于，复杂答案往往不是藏在某一个段落里，而是分散在多个文档、多个时间点和多个实体之间。
多跳问题：需要沿着“甲公司 → 乙公司 → 丙项目 → 新规”连续追踪关系。
全局问题：例如“整个知识库的主要矛盾和趋势是什么”，不存在一个与问题高度相似的单独片段。
关系问题：向量能判断两段话像不像，却不直接表达“谁投资谁、谁依赖谁、谁在什么时间改变了什么”。
长文档问题：Top-K 只取少量块，容易把上下文切碎；扩大 K 又会带来噪声和上下文膨胀。
图 2：传统 RAG、Microsoft GraphRAG 与 LightRAG 的核心结构差异。
二、GraphRAG：先把文档读成一张“分层地图”
Microsoft GraphRAG 是一种结构化、分层式的 RAG 方法。它不只保存文本块和向量，还从原始文本中抽取实体、关系与关键声明，构建知识图谱；随后对图做社区发现，并为不同层级的社区生成摘要。查询时，系统根据问题类型选择社区摘要、实体邻居、原始文本或它们的组合。
| 微软官方把 GraphRAG 的主要价值概括为两类：一是“连接分散的信息点”，二是“从大型语料中形成整体理解”。 |
- 离线阶段：从 TextUnit 到社区摘要
图 3：GraphRAG 的典型离线索引链路。
索引通常包含五个关键动作：先把文档切成 TextUnits，再抽取实体、关系和声明；接着使用 Leiden 等社区发现算法把紧密关联的节点聚成层级社区；最后由模型从底层到高层生成社区摘要。
这也是 GraphRAG 的成本来源。传统 RAG 主要承担文档解析、Embedding 和向量写入，而 GraphRAG 需要大量结构化抽取与摘要调用。微软项目仓库明确提醒：索引可能是一项昂贵操作，应从小数据集开始验证。
图 4：社区层级让 GraphRAG 可以从局部实体逐步上升到全局主题。
- 在线阶段：Global、Local、DRIFT 与 Basic
图 5：GraphRAG 的查询方式并不是一个固定的“图搜索”。
Global Search 主要利用社区摘要回答宏观、跨文档的问题；Local Search 从具体实体出发，向邻居、关系和相关文本扩展；DRIFT Search 在局部扩展的基础上加入社区信息；Basic Search 则退回普通的向量 Top-K。
| GraphRAG 的关键不是“图数据库”，而是“实体图 + 社区层级 + 社区摘要 + 多种查询策略”。只把文档写进 Neo4j，并不等于实现了 Microsoft GraphRAG。 |
- GraphRAG 适合什么，不适合什么
适合：跨文档主题分析、研究报告归纳、事件脉络、组织关系、舆情全景、复杂调查与知识发现。
不一定适合：简单 FAQ、单文档定位、实时高并发客服、频繁更新但没有关系推理需求的知识库。
主要代价：构图与社区摘要成本高，索引耗时长；实体与关系抽取错误会在后续层层放大。
工程要求：需要针对领域定制实体类型、关系类型、抽取 Prompt、别名消歧和引用映射。
三、LightRAG：图谱和向量一起工作
LightRAG 不是简单删减 GraphRAG 流程。它把图结构引入文本索引，同时保留向量表示，并用双层检索同时覆盖具体实体和高层关系。其论文强调三点：图结构与向量表示结合、低层与高层双层检索、以及可增量更新的数据组织。该工作后来发表于 EMNLP 2025 Findings。
图 6：LightRAG 同时维护文本向量与实体关系图。
- 低层检索与高层检索
图 7：低层检索解决具体事实，高层检索解决主题与关系。
低层检索以实体、属性、局部关系和相关文本块为中心，适合“某个对象是什么、做了什么、与谁有关”；高层检索则围绕关系链、主题和跨文档依赖组织上下文，适合趋势总结与复杂关联问题。
- 五种查询模式
图 8：LightRAG 当前实现提供 local、global、hybrid、naive 和 mix 五种模式。
local 聚焦实体与局部事实，global 关注宏观主题与深层关系，hybrid 合并两者；naive 退回普通文本块向量检索；mix 则把 local、global 与 naive 结果一起组合。当前官方仓库把 mix 作为默认模式，但生产系统仍应基于问题类型、时延和成本动态选择。
- 增量更新与四类存储
图 9：LightRAG 的增量更新思路。
LightRAG 对新增数据生成局部图，再与已有图合并，从而避免每次重建整个全局索引。对于政策、新闻、研究资料和企业知识库等持续变化的数据，这种设计更容易形成日常增量流水线。
图 10：LightRAG 的四类后端存储。
官方实现将存储拆为 KV、Vector、Graph 与 Doc Status 四类。它们分别承载缓存和抽取中间结果、文本与实体关系向量、知识图谱本体，以及文档处理状态。工程选型时要看这四类存储是否都能满足一致性、备份、权限与扩缩容要求。
- 当前工程能力的变化
LightRAG 的当前 v1.5 系列已经扩展到多模态文档处理，可通过 MinerU、Docling 和 Native 等解析引擎提取文本、表格、公式与图片，并支持跨模态实体关系映射。官方还引入了 EXTRACT、QUERY、KEYWORDS 与 VLM 四类模型角色，建议为抽取和关键词步骤使用更快、更便宜的非推理模型，把更强模型留给最终回答。
| 这意味着 LightRAG 的主要挑战已从“能不能跑起来”，转向“解析质量、模型角色分工、并发、存储和版本治理是否可靠”。 |
四、GraphRAG 与 LightRAG 到底有什么区别
图 11：三种方法在复杂问题上的定性成本与能力变化。
图 12：传统 RAG、GraphRAG 与 LightRAG 的选型矩阵。
GraphRAG 更强调对整个语料建立层级化的“全局认知”，社区摘要是其核心资产；LightRAG 更强调图与向量的组合、双层检索和增量更新。GraphRAG 的 Global Search 对全库主题和宏观总结更有针对性；LightRAG 则提供更灵活的 local、global、hybrid、naive 与 mix 模式，更适合需要快速迭代和混合问答的工程场景。
五、如何选型：先看问题，而不是先看框架热度
图 13：GraphRAG、LightRAG 与普通 RAG 的选型决策树。
场景一：FAQ、制度条款、产品手册
优先使用传统 RAG，并把精力放在解析、切分、混合检索、重排、引用和评测上。关系图谱可能增加成本，却未必提升直接事实问答。
场景二：全库主题、宏观趋势、复杂调查
优先评估 GraphRAG。它的社区层级和预生成摘要，正是为“整套语料在讲什么、不同主题如何关联”这类问题设计的。
场景三：既有事实问答，又有多跳关系，并且知识持续更新
优先评估 LightRAG，或采用传统 RAG 与图检索结合的混合架构。其增量更新和多查询模式更适合持续演进的知识库。
场景四：问题类型混杂、并发和成本敏感
图 14：通过查询路由，让简单问题走简单链路。
生产系统不应让所有请求都走图检索。可先用规则或轻量模型判断问题是否包含多个实体、跨文档、多跳、趋势总结等特征；简单问题走普通 RAG，实体关系问题走 LightRAG local 或 mix，全局问题再走 GraphRAG Global Search。
六、落地时最容易踩的坑
图 15：图 RAG 常见失败模式。
- 抽取质量决定图谱上限
实体类型太泛、关系类型不清、结构化输出不稳定，都会造成图谱噪声。应先建立小规模人工标注集，评测实体覆盖、关系准确率和别名合并率，再扩大索引规模。
- 文档解析和去噪比图数据库品牌更重要
页眉、页脚、参考文献、导航栏、免责声明和 OCR 错字都可能被抽成节点。对于论文、合同和操作手册，应保留章节结构、页码、表格与图片关系，并过滤低价值尾部内容。
- 权限必须进入检索层
企业知识库通常存在部门、项目和用户级权限。不能先召回全部实体关系，再在答案阶段隐藏；权限过滤应同时作用于文本块、实体、关系和社区摘要。
- 图上的关系必须能回到原文
每个实体、关系和声明都应保存来源文档、文本块、页码或时间戳。最终答案不仅要引用文本块，还要能解释关系链由哪些证据支持。
七、评测：把图谱、检索和答案拆开
图 16：GraphRAG 与 LightRAG 的三层评测框架。
图谱质量：实体覆盖率、关系 Precision/Recall、别名合并率、孤立节点率、错误边比例。
检索质量：证据召回、路径召回、社区命中率、上下文冗余率、检索延迟。
答案质量：事实忠实度、完整性、引用准确率、多跳推理正确率、拒答质量。
工程指标：单文档索引成本、增量更新时间、P95 查询延迟、缓存命中率、存储增长速度。
| 不要只用“回答看起来不错”评测图 RAG。图谱可能是错的，但模型凭常识碰巧答对；也可能检索正确，却在生成阶段遗漏关键证据。 |
八、企业级架构与实施路线
图 17：企业级 GraphRAG / LightRAG 生产架构。
阶段一：先证明普通 RAG 的瓶颈
准备一组必须跨文档、跨实体或做全局总结的问题，与现有 RAG 对比。如果失败原因只是切分、Embedding 或重排，先修基础链路。
阶段二：在小语料上验证图谱质量
选一个业务边界清晰的数据集，定义实体和关系类型，建立人工标注集，完成抽取、别名消歧、来源追踪和小规模问答评测。
阶段三：建立动态路由和发布门禁
加入查询复杂度分类、成本预算、超时降级、索引版本、灰度发布和回滚；只有复杂问题才启用图链路。
阶段四：持续修图，而不是只调 Prompt
把失败样本回流到解析、实体抽取、关系抽取、别名合并、社区摘要和检索配置中，形成可定位、可修复的闭环。
图 18：上线前检查清单。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
