初步本地跑通RAG知识库（三）GraphRAG与LightRAG
前言
我阶段性放弃折腾RAG了。
在研究GraphRAG过程中，我发现：
- 传统RAG已经相当传统了。
- GraphRAG也基本烂大街了，正确率能做到95%。
技术成熟，看起来正是我这种小白入场偷师的好时候——但没有这么简单！
RAG本质上是为了帮助模型精准回答需要的信息，基于此下游涌现各种解决方案——比方从训练模型本身开始，直接拉大上下文窗口，优化索引能力；比方使用外部的上下文管理手段，外挂知识库/记忆。中间有各种各样的实现方式——但都无外乎上下文管理。
但当前的各种方案都只能算是宏大目标下的阶段性的突破，算是经典的interesting but not exciting。也不算我这种技术力低但期望值高的业余选手的入场的甜点区。且夫这个大领域进步的速度甚至远超用户深度体验一遍的速度，还有其他更加fancy、更加有性价比的课题等着我呢。说不定等我正式研究完，会有船新的实现思路与技术革命。
而我今天看到的文字，开了思路，也给了我信心：
长对话/长任务不是未来。 「上下文工程」也不会永远存在。 …… 我们总是习惯用隐喻，把模型想象成被压抑的火种，被工程系统限制的力量。但也许问题没有那么戏剧化。模型并没有被囚禁。它只是被我们误用在一种错误的组织方式里。 任务出现，构造上下文，完成任务，结束。 下一轮重新开始。 当我们停止把系统建立在“延续状态”之上，很多复杂度会自然消失。 ——被缚的普罗米修斯
总之来都来了，先梳理下理解吧。
概述
GraphRAG则是一开始通过结构化数据整理所有文档的信息（提取、整合发现），同时概括性整合为“社区摘要”。
而LighrRAG直接掠过最耗资源的社区摘要，只保留整理的结构化数据（也就是谱图）。
传统 RAG（Naive RAG / 基础 RAG）传统在哪里？
传统RAG主要是利用embedding、reranker给文档向量化、分析问题与文档哪里最相关，然后排序，把评分最高的喂给LLM参考。但这也意味着——它先天就没有整合理解文档本身这一环！
也就是说，它基于一定语义理解能力哼哧哼哧挨个看文档哪里和问题相关，但至于文档之间的关联性就不在他的考虑范围内。如果统一目标信息的不同字元素散布在不同切片中，即便会因为信息相关而被索引到，也可能会因为排序靠后而被割舍。
Microsoft GraphRAG本质是什么？
GraphRAG可以近似理解为雇佣一个LLM提前重工整理知识库的笔记：提取所有关键节点、整理关联1，再高屋建瓴地写个“社区摘要”，存成格式化数据。这样就能同时应对宏观问题和微观问题。
等用户来提问，这个雇佣兵就会按图索骥找到相关片段喂给模型。和Naive RAG差不多，都是前人种树，后人乘凉，只是种树策略和成本不同。
如下问GraphRAG工作流水线： 原始文档 -> LLM 提取实体/关系 -> 构建图谱 -> 分层生成社区摘要 -> 用户提问 -> RAG的检索组件根据问题层级，智能选择：宏观问题直接调取摘要，微观问题顺着图谱下钻找切片 -> 喂给 LLM 生成答案。
LightRAG优化在哪里？
它直接掠过最耗资源的社区摘要，只保留整理知识图谱和原始文档切片。知识图谱中，它会以文本形式串联实体和关系，以此代替成本更高的社区摘要。这下来计算成本节省了，也能同时应对宏观问题和具体问题2。
本质上是 “用算法换算力” 。重点在于不用社区摘要，直接用高效的检索算法从庞大知识图谱中索引相关片段，省去了昂贵的预计算成本。
还有其他方案吗？
有的兄弟，有的。比方说fusiongraphrag、Small-to-Big / Parent-Document Retrieval。但感觉玩过酒馆的（？）都会觉得他们大同小异，我就不在此过多研究了。
