nano-graphRAG 开源repo：https://github.com/gusye1234/nano-graphrag
unsetunsetnano 架构设计unsetunset 该项目是一个号称将微软的graphRAG降本增效至只有800行代码，并在保留核心功能上提高了速度，根据作者提供的benchmark数据，似乎效果确实还不错，该项目的安装与微软一致，为：
#version1:InstallfromPyPi个人比较推荐源码安装，最近好像更新得很频繁，我在记录该模块的同时，去看git说明，发现又冒出来了一堆东西，看future roadmap，作者想要接入HybridRAG，所以不仅仅创建了GraphStorage，还有KVStorage：
这里的入口基本上是从insert出去，代码里有一个Naive_rag的参数，为true的时候，会开启传统召回模式，即除了对chunk做提取生成后续的Entity和Edge，还会存在一个chunks_vdb向量库。另外，可以从上图中看到，使用的是asyncio异步的 always_get_an_event_loop() 来调度和执行异步任务，保证了效率。
后续部分的写入，排除掉最近一段时间基于向量加的一些逻辑操作，主要为NetworkXStorage类，可以理解为图数据库，包含对实体与关系的聚类算法与生成报告业务等一系列操作：
至于graphRAG的Local Search和Global Search能力代码，具体可以看_op.py文件，代码太多我还没看完，大致的所有功能我画为下图：
后续有时间了，并且要二开了，再回头研究研究，这里不管各种功能函数，官方示例调用是非常简单的，即：
fromnano_graphragimportGraphRAG,QueryParam我比较想说明的是leiden算法，流程为：
根据Wikipedia说明，Leiden算法是一种用于社区检测的算法，它是为了解决Louvain算法在社区连接性上的一些限制而提出的。Louvain算法在社区检测中可能会产生连接性不好的社区，甚至可能出现不连通的社区，Leiden算法通过引入一些改进，确保了生成的社区是内部连通的，并且在迭代过程中提供了一些明确的保证和界限。在nano中，该算法大致代码为：
def_cluster_data_to_subgraphs(self,cluster_data:dict[str,list[dict[str,str]]]):这里存在一个问题，当聚类子群比较多，llm模型的输入token是有限的，我看好像没有对这部分做处理，而是直接做了截断，那么对结果将会产生一定影响。
unsetunsetnano 对比实验unsetunset 最后，本来是想像上篇一样，做一个与原方案的对比实验，但看作者好像已经做了，我也没有特别必要的需求，就以作者的benchmark作为说明，实验环境为：
Both GraphRAG andnano-graphraguse OpenAI Embedding and gpt-4o. On the same device and network connection. GrapgRAG Max Async API request: 25 nano-graphragMax Async API request: 16Local Search Results的结果看起来问题不大，Global Search Results的回答就有点出入了。问题为：
"大乔与曹操的关系"
graphRAG的结果为：
###大乔与曹操的关系nano-graphRAG的结果为：
##曹操与大乔的关系那么，曹操对大乔是展现的政治和战略兴趣嘛，换句话说，大乔是一种战略物资或人物嘛，emmm
triplex ?cookbook https://r2r-docs.sciphi.ai/cookbooks/knowledge-graph ?blog https://www.sciphi.ai/blog/triplex ⛳Demo kg.sciphi.ai
unsetunsettriplex介绍unsetunset 如果说上一节是对于庞大的项目框架中提取核心业务作为nano，那么本节算是从成本进行了降本增效。在nano-graphRAG的未来计划中，作者提出了triplex的概念，即Add Sciphi Triplex as the entity extraction model.而在fastChat、camel等llm框架中也有issue问到了加入triplex该项目，包括微软graphRAG，我甚至看到triplex作者亲自跑到graph下提了一个feature request，但被当场给毙了，emmm：
那么triplex是一种什么样的方案？可以从下图知晓：
triplex 全称为Scihpi Triplex模型，是一种开源大语言模型，专注于从非结构化数据中提取知识图谱。它的名字来源于其能够提取文本中的实体、关系和实体类型。这个模型是基于53.8亿参数的语言模型进行微调，旨在创建高质量的知识图谱。它与graphRAG的对比如表格所示：
Advantage Triplex Microsoft GraphRAG Cost 10x cheaper High cost due to token generation Performance Comparable to GPT-4, better efficiency High resource consumption Flexibility Supports diverse and complex inputs Limited by high cost Ease of Use Immediate usage with R2R RAG engine and Neo4J Complex and resource-intensive process Training Data Extensive, from DBPedia, Wikidata, synthetic datasets
这样对比下来，确实很强，于是我准备开始测试。
unsetunsettriplex 部署unsetunset 这里我没有选择直接用openai_key做cloud LLM，因为手上的刚好过期了，暂时不想充钱，所以就用本地部署来调用，官方推荐了两种方式：
Docker：Install and run R2R with Docker Local：Install and run R2R directly on your local system (not recommended). 虽然官方不推荐local，但我看了下toml配置，感觉关联服务不是很多，考虑到某些众所周知的关于docker镜像源的原因，还是一意孤行了，顺带从SciPhi-AI repo中学了下neo4j镜像怎么装，我之前在 基于知识图谱和文档树增强的RAG实验记录 一文中提到需要在启动容器内更改neo4j.conf，不过可以在run的时候直接指定所有参数也行：
dockerrun-d\但这只是local R2R的其中一难，官方文档对于local部分写得不清不楚才是更大的灾难，在我发现issue里甚至没几个本地服务化的，就去找了目前有用的docker加速器转为完全镜像化，于是开始以下的pulling：
2Rnowrunsonport7272bydefault!上述12个容器若状态都为healthy的话，需要再安装一下ollama的模型服务：
ollamapullsciphi/triplexollama非本地ip或11434端口，可在r2r镜像启动时加入环境变量：
OLLAMA_API_BASE=http://your_host:11434r2rserve--docker--config-path=/xxx/local_llm_neo4j_kg.tomlunsetunsettriplex 使用unsetunset 如果是整个服务都启动正常，服务器的7273和7274端口为webui界面，其中7274的邮箱验证对我网易邮箱好像有问题，7273倒是OK的，如下图所示，是一个集成了服务监控、llm聊天、日志收集和展示配置项的web界面：
这里还能对整个流程的所有prompt进行查看和修改：
真正用还是得在代码端或者终端，官方也准备了这两种方式，自我感觉前者更适合个性化，比如我的脚本为：
fromr2rimportR2RClienttriplex支持多文本文件输入，直接用ingest_files进入它的整个pipleline，但过程挺慢的，我是将官方示例的aristotle.txt复制了两份为1.txt和 2.txt，不过我a4000卡的算力太低，我看说明，单文件文档中的说法是不到10s，大概是调用的openai key，本地llama3.1加上我的算力，乘个20吧，emmm。
之后就是照着它文档中的接口案例，一步步去加，hybrid_search_response实验似乎没有什么问题，kg_search_response我一直调用失败，异常为叫我在kg search前做KG enrichment，文档里却没看见介绍这个python的接口，只有命令行，然后命令行也有问题：
r2rcreate-graph--document-ids=9fbe403b-c11c-5aae-8ade-ef22980c3ad1所以，最后我的评价是，文档还能有很大提升空间，pipeline做得太复杂了，额外服务做了太多，建议后续的尝试，可以只用sciphi发布在huggingface上的模型。
itext2KG ?论文名 《iText2KG: Incremental Knowledge Graphs Construction Using Large Language Models》 ?地址 https://arxiv.org/abs/2409.03284 ⛳Official repo https://github.com/AuvaLab/itext2kg
unsetunsetitext2KG 方案说明unsetunset 上一节中的triplex从官方文档中表述是可以与graphRAG做到一样的效果，但它的model不是zero-shot，如果要实现本地化，不用r2r提供的pipeline，而是自己写并且要效果好的话，我感觉也有一定工作量，而本节提出的itext2KG是一种不需要预先定义的本体或大量的监督学习，就能够从原始文档中构建出一致的知识图谱的方案。
论文中提到，当前存在的问题包括：
大多数可用数据是未结构化的，这使得获取有价值的信息变得具有挑战性。 传统的自然语言处理（NLP）方法，如命名实体识别和关系提取，虽然在信息检索中至关重要，但存在局限性，包括依赖预定义的实体类型和需要监督学习。 当前的研究虽然利用了大型语言模型的能力，但在实体和关系的解析中仍然存在未解决的问题，如语义重复和不一致的图谱，这需要大量的后处理。 许多现有方法依赖于特定主题，限制了它们在不同领域的通用性。 而论文的解决方案为：
自动化地从大量自然语言文本中提取和构建知识图谱，以结构化数据并使其可访问。 提供一种无需后处理的增量构建知识图谱的方法，这种方法不依赖于特定主题，可以跨多个领域应用。 通过四个模块（文档蒸馏器、增量实体提取器、增量关系提取器和图谱集成器）来提高实体和关系的解析质量，减少冗余和歧义。 利用大型语言模型的零样本学习能力，提供即插即用的解决方案，减少对大量训练或微调的需求。 这里比较有意思的是module 1到3，算是定义了一种规则，或者说提供了一种范式，我最近刚好想要做这方向上的东西。
文档蒸馏器（Document Distiller） Document Distiller 模块是 iText2KG 方法的一个关键组成部分，它负责将原始文档转换成结构化的语义块，以便后续的知识图谱构建。该模块利用大型语言模型的能力，根据用户提供的 JSON 模式（蓝图）来提取文档中的相关信息。这个过程不仅提高了信息的组织性，还为图谱构建提供了清晰的指导。
我主要想看的就是Distiller 模块下的Schema 规范：
这样做的目的，相当于能引导语言模型在保持其他类别灵活性的同时偏向于特定类别。它的主要目标为：
（a）：通过减少可能用冗余信息污染图谱的噪声来提高信噪比； （b）：使用模式指导图谱构建过程，特别是对于概念键。 a点不用说，b点的意思我举个例子就是，假设我们有一个科学文章的文档，我们想要构建一个知识图谱，其中包括文章的标题、作者、发表年份和关键词等信息。我们可以定义以下 JSON 模式：
{当 Document Distiller 模块处理这个科学文章时，它会使用大型语言模型来识别和填充这个 JSON 模式。模型会根据训练时学到的知识，识别出文档中与这些概念键相关联的文本信息，并将其填充到相应的位置。例如，它可能会从文档中提取出标题 "Deep Learning Approaches" 并将其放入 title 键对应的位置。
增量实体提取器 and 增量关系提取器 作者这里用了两个算法流程图概括了过程：
这两种从本节最开始的4 module的总流程图中可以看到是非常相似的，只是module 3对接module 4的时候，pipeline稍微加了一点步骤，而 增量实体提取器（Incremental Entities Extractor） 的过程为：
全局实体集合初始化 ：首先，从第一个文档（或语义块）中使用大型语言模型（LLM）提取实体，形成全局实体集合。这些实体被认为是彼此独特的。局部实体提取 ：对于后续的每个文档，提取局部实体集合。实体匹配 ：将局部实体与全局实体集合进行匹配。如果找到匹配的实体，则将其添加到匹配集合中。如果没有找到匹配项，但局部实体与全局实体集合中的某个实体足够相似（基于预定义的相似度阈值），则将最相似的全局实体添加到匹配集合中。更新全局实体集合 ：将匹配集合与全局实体集合合并，更新全局实体集合。迭代处理 ：重复上述步骤，直到所有文档都被处理完毕，从而得到一个全面的全局实体集合。
unsetunsetitext2KG 使用与对比unsetunset 作者在论文中介绍完整个框架流程后，就开始了对比实验，测试集为简历、科学文章和网站，这里就不再详述表格数据内容，主要的可视化可以看下图，我感觉效果还不错：
而itext2KG的安装与使用也非常的简单，与graphRAG一样只需要pip install，使用首先需要启用DocumentDistiller：
然后进行提取：
#InitializeiText2KGwiththeOpenAIAPIkey.最后可视化：
fromitext2kg.graph_integrationimportGraphIntegrator写到这里，有openai key的可以尝试一番，因为issue第一条里作者就表示，未来会考虑加入langchain支持的chatglm等大模型api，但目前还是以gpt为主，所以上述的代码我没尝试过，只是将github中的复制了过来，但这种思想还是很有意义的。
