今天是2024年11月27日，星期三，北京，天气晴。
我们今天继续来看GraphRAG的最新进展，可以可以回顾下Graphrag(ms版本)的路程：GraphRAG第一版本2024年4月份，主打global/local search；2024年11月初，搜索优化引入Drift_search动态搜索（https://microsoft.github.io/graphrag/query/drift_search) ；2024年11月底，在drift_search基础上，抛弃KG抽取并作rank优化，推出lazygraphrag(https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)。
其实，问题还是回归了，场景的问题，GraphRAG适合需要全面分析和复杂查询的场景，但成本较高。LazyGraphRAG在保持高质量答案的同时，要想兼备具有显著的成本优势，适合快速查询和资源有限的应用。是两个配置。所以，这个lazygraphRAG确实是取得很有信息量，足够lazy。
结起来就是LazyGraph不要entity/relationship这些kg包袱，更直白的keywords/noun-phrase，降低构建成本，KG其实是烫手山芋；查询阶段不要那么多，走优先遍历，减少上下文。所以，这是GraphRAG在KG上的退化（退化至与朴素RAG接近）。
我们可以从中找到一些思路，多思考，多总结，多实践；
一、先从GraphRAG的发展说起
从GraphRAG到LazyGraphRAG，其实我们可以很真实的感受到，大道至简，正如在之前《GraphRAG系列范式冷思考：GraphRAG、KAG框架思考及E2E-AFG自适应过滤端到端思路》(https://mp.weixin.qq.com/s/kYlGAwAFayySnszwZ1g8Og)中所说的，当前阶段无论是Graph，还是KG，应该跟RAG浅结合，把收益最大化。
GraphRAG（by Microsoft，https://github.com/microsoft/graphrag）的思想是，利用LLMs构建基于实体的知识图谱，增强查询重点摘要（QFS）任务。该系统通过预生成相关实体群体的社区摘要，捕获文档集合内的局部和全局关系；
全局搜索（Global search）处理跨越整个数据集的查询。这种场景综合了来自不同底层来源的信息，以回答需要对整个语料库有广泛理解的查询。例如，在一个关于科技公司研究努力的的数据集中，一个全局查询可能是：“过去五年中，在多个组织中出现了哪些AI研究趋势？”虽然连接分散信息很有效，但全局搜索可能是资源密集型的。
局部搜索（Local search）针对目标查询进行了优化，从与用户输入紧密匹配的文件的一个小子集中提取信息。当答案位于少数文本单元中时，这种模式效果最好。例如，一个查询询问：“微软的Cosmos DB团队在10月4日发布的新功能和集成有哪些？”
但是成本太高，所以后续的lightRAG(https://github.com/HKUDS/LightRAG，https://lightrag.github.io/，https://arxiv.org/pdf/2410.05779，https://microsoft.github.io/graphrag/)来对比，其来自于nano-graphra(https://github.com/gusye1234/nano-graphrag)，其实就是微软Graph的简化版本，将社区、社区宅摘要这些环节做了去除，这种去除是好的，不会太重，对于知识更新也更快；
后面，搜索优化引入Drift_search动态搜索（https://microsoft.github.io/graphrag/query/drift_search) ，但并没有对索引的部门进行优化，依旧成本居高不下。
所以，到后面，Lazy版本的GraphRAG就出来了。而在本质上说，GraphRAG和LazyGraphRAG是两种不同的图增强检索与生成（RAG）方法，在数据处理和查询性能上有显著区别：
在数据处理方面，GraphRAG使用大LLM提取和描述实体及其关系。对每个实体和关系的所有观察进行总结。使用图统计优化实体图并提取层次社区结构。但LazyGraphRAG使用NLP名词短语提取概念及其共现关系。使用图统计优化概念图并提取层次社区结构。延迟LLM的使用，直到查询时才进行相关处理。
在查询机制方面，全局搜索上，GraphRAG在使用社区结构确保考虑整个数据集的广度，而LazyGraphRAG全局搜索上通过迭代加深的方式结合最佳优先搜索和广度优先搜索。在局部搜索上，GraphRAG直接使用原始查询，而LazyGraphRAG通过文本块嵌入和社区关系进行排序，并使用LLM进行相关性评估。
所以可以看到，在成本上，GraphRAG数据索引成本较高，因为需要进行复杂的LLM处理和社区结构提取。 LazyGraphRAG的数据索引成本与向量RAG相同，远低于完整GraphRAG。查询成本低，适合一次性查询和流数据处理。
二、GraphRAG引入DRIFT推理**
这个月初，GraphRAG微软版本更新0.4.0，引入DRIFT推理（https://github.com/microsoft/graphrag/releases/tag/v0.4.0，https://github.com/KylinMountain/graphrag-server，http://uncharted.software/，https://github.com/microsoft/graphrag），其中的重点模块是graph reasoning query module(https://www.microsoft.com/en-us/research/blog/introducing-drift-search-combining-global-and-local-search-methods-to-improve-quality-and-efficiency)，其核心叫做DRIFT Search: A step-by-step process，一步步来，可以自行体会下。
一个完整的DRIFT搜索层次结构如上，三个阶段。
A (Primer)：当用户提交查询时，将其与最相关的K个社区报告进行比较。这会产生一个初始答案以及几个后续问题，这些问题作为全局搜索的轻量级版本。为此，使用假设文档嵌入（HyDE）扩展查询，以增加敏感性（召回率），嵌入查询，与所有社区报告对照查询，选择顶部K个，然后使用这些顶部K个尝试回答查询。
B (Follow-Up)：使用局部搜索来精炼查询，产生额外的中间答案和后续问题，增强特定性，这里默认迭代两次。
C (Output Hierarchy)：最终输出是一个按相关性排名的问题和答案的层次结构，使结果具有适应性和全面性。
总的来说，DRIFT推理，这个是在检索阶段做的一个优化，但实际上效率可能会降低，因为引入了迭代搜索，但看其效果还不错。
三、LazyGraphRAG简化索引、弱化KG
LazyGraphRAG(https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)的一个关键优势在于它在成本和质量方面的固有可扩展性，根据其博客介绍。在一系列方法（标准向量RAG、RAPTOR、GraphRAG本地搜索、全局搜索以及DRIFT搜索机制）中，LazyGraphRAG 在成本-质量上，表现不错。
不同的设定条件，这些参数设置，其实也是在实际过程中用到的思路。
对比效果如下，结论均来自于博客。
具体如下：
LazyGraphRAG的数据索引成本与向量RAG相同，仅为完整GraphRAG成本的0.1%。
在与向量RAG相当的查询成本下，LazyGraphRAG 在local查询上的表现优于其他方法，包括长上下文向量RAG、GraphRAG DRIFT搜索以及GraphRAG local搜索。
同样的LazyGraphRAG配置，在Global Search方面，其答案质量与GraphRAG Global搜索相当，但查询成本低超过700倍。
以GraphRAG Global搜索查询成本的4%，LazyGraphRA在local和global查询类型上表现不错，包括C2级别的GraphRAG全局搜索（推荐用于大多数应用的社区层次结构的第三级）。
所以，可看看做的具体优化操作，LazyGraphRAG在构建索引、匹配查询和映射答案等方面采用了更复杂的方法，而GraphRAG则相对简单直接。
在Build index方面，GraphRAG通过大模型（LLM）提取和描述实体及其关系，总结每个实体和关系的所有观察结果，并利用图统计优化实体图，提取层次化的社区结构。LazyGraphRAG利用自然语言处理技术（NLP）提取名词短语，识别概念及其共现情况，再通过图统计优化概念图，提取层次化的社区结构。
在Summarize index方面，GraphRAG利用LLM总结各个社区内的实体和关系。LazyGraphRAG采用“懒惰”策略，不预先生成概述，而是在查询时动态调用LLM进行处理。
在Refine query方面，GraphRAG直接使用原始查询，不做额外处理。LazyGraphRAG利用LLM识别相关的子查询，并将其重组为一个扩展查询，通过概念图中的概念进一步细化子查询。
GraphRAG不进行特殊处理，采用广度优先的方式，使用所有社区的摘要来响应查询。LazyGraphRAG针对每个子查询q，首先根据文本块嵌入和块-社区关系按相似性排序查询，接着根据前k个文本块的排名对社区进行排序（最佳优先）。使用基于LLM的句子级相关性评估器对未测试的前k个文本块的相关性进行评分，并按排名顺序从社区中选取文本块（广度优先）。如果连续z个社区没有产生相关文本块，则递归地进入子社区进行搜索，或者在达到相关性测试预算/q时停止（迭代加深）。
在Reduce answers方面，GraphRAG利用LLM根据随机批次的社区摘要并行地回答原始查询。LazyGraphRAG针对每个子查询q（通常3-5个），构建相关文本块的概念子图，根据概念的社区分配将相关块分组。使用LLM从相关块组中提取与子查询相关的声明，确保只关注相关内容。最后，对提取的声明进行排序和过滤，以适应预定义的上下文窗口大小。
所以，总结起来就是，不要抽实体、抽关系，抽名词短语，找共现就好了。社区上，延迟LLM的使用，直到查询时才进行相关处理，这样减少索引构建时间，查询时间上，通过迭代加深的方式结合最佳优先搜索和广度优先搜索，然后进行排序，减少上下文长度，加速推理；查询时间上，通过迭代加深的方式结合最佳优先搜索和广度优先搜索，然后进行排序，减少上下文长度，加速推理；
总结
本文主要回顾了Graphrag(ms版本)的路程：GraphRAG第一版本2024年4月份，主打global/local search；2024年11月初，搜索优化引入Drift_search动态搜索（https://microsoft.github.io/graphrag/query/drift_search) ；2024年11月底，在drift_search基础上，抛弃KG抽取并作rank优化，推出lazygraphrag(https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/)。
这一路走来，其实都是在面向落地而做的优化或者简化，其目的是为了更加轻量以让大家更好的用起来。这其实也是目前很多框架所需要考虑的点。
大道至简，各位共勉。
