[Feature Request]:借鉴 Hyper-RAG 优化实体与关系抽取的效率

[ruanjunmin]

Do you need to file a feature request?

• I have searched the existing feature request and this feature request is not already filed.
• I believe this is a legitimate feature request, not just a question or bug.

Feature Request Description

目前 LightRAG 在处理文档时，实体和关系的抽取是一个关键环节。为了进一步提升处理效率，特别是针对复杂或长篇文档，建议研究并借鉴 Hyper-RAG 项目 (https://github.com/iMoonLab/Hyper-RAG) 中可能存在的、用于加速实体和关系抽取的有效方法或架构设计。
具体而言，希望 LightRAG 能够：

1. 评估 Hyper-RAG 在实体/关系抽取方面的性能优势（如果存在）。

2. 探索是否可以将 Hyper-RAG 中的相关技术（例如，可能的并行处理、优化的索引或超图构建方法）集成或适配到 LightRAG 的流程中。因为该项目声称：
   ➊处理性能比 Graph RAG 和 Light RAG 高出 6.3% 和 6.0%；
   ➋在九个不同的数据集上，Hyper-RAG 基于选择评估，比 Light RAG 提高了 35.5% 的性能。

3. 最终目标是显著提高 LightRAG 在从文档中提取实体及其相互关系时的速度和效率，减少处理时间，提升用户体验。

Additional Context

Hyper-RAG 项目地址：https://github.com/iMoonLab/Hyper-RAG
Hyper-RAG 项目在其介绍中可能包含关于高效处理文档和构建基于超图知识图谱的技术细节。研究这些细节可能为 LightRAG 的性能优化提供有价值的参考。提升抽取速度对于需要快速处理大量文档或实时性要求较高的 RAG 应用场景尤为重要。

[TonicZhang]

@ruanjunmin 你自己跑过吗？我也看到了这个论文，但还没自己实测过。超图理论上更复杂，运行速度反而更快，有点怀疑……

[ruanjunmin]

@ruanjunmin 你自己跑过吗？我也看到了这个论文，但还没自己实测过。超图理论上更复杂，运行速度反而更快，有点怀疑……

跑过了，圣诞颂歌的示例文本，用免费的智谱API（glm-4-flash-250414）跑用了6分52秒，速度上确实比lightRAG快。

回答也还行
naive回答：

hyper回答：

hyper-lite回答：

[danielaskdd]

超图的Super edge可能社区总结的效果，回答全局和抽象问题的能力可能会更强。对于事实的挖掘能力如何有待评估。希望各位多反馈一些比较数据和使用上的体会。

[ruanjunmin]

希望取其精华，去其糟粕

[TonicZhang]

最近也试了试Hyper-RAG，代码基本上是借用的lightRAG，只做了一些简化实现，还是有一些小bug，比如log，抽取的结果过长容易超过最大token数等。
效果方面，在细节和多关联的回答上，虽然期待比较高，但暂时没有体现出优势。可能超图的作用比较依赖entity type和example的配置，可能要自己重新适配一下，到时候再评估。
速度方面，index阶段略微快一点，最主要还是它的实现是全部抽取后存储到内存上，再一次性持久化。其中hyperdb速度确实比较快，比networkx性能好。