在这个信息爆炸的时代，我们每天都被大量的数据和信息所包围。对于企业和研究人员来说，如何从这海量的信息中迅速地找到自己需要的针对性数据，已经成为了一个亟待解决的问题。幸运的是，香港大学的研究团队最近推出的LightRAG系统，为我们提供了一个新的解决方案。

LightRAG系统是基于RAG（Retrieval-Augmented Generation）的开源技术，它通过引入先进的双层检索范式和基于图的数据结构，大大提升了信息检索的全面性和效率。更为重要的是，它能够快速适应新数据，这在今天这个信息快速更新换代的时代尤为关键。

核心创新：基于图的数据结构

与传统的RAG系统相比，LightRAG的一个显著优势在于其基于图的数据结构。这种结构能够有效地捕捉数据中实体之间的复杂关系，从而使检索结果更加精确。举个例子，在医学领域，LightRAG能够识别“心脏病”与“心内科医生”之间的关系，这种精准度是传统方法难以实现的。

LightRAG 增强了分段检索系统 将文档转换为更小、更易于管理的片段。此策略允许快速 识别和访问相关 信息，而无需分析整个文档。接下来，我们利用LLMs 来识别和 提取各种实体（例如 名称、日期、位置和事件）以及它们之间的关系。这通过此收集的信息进程将用于创建一个全面的知识图谱，该图谱突出显示跨整个文档集合。基于图形的文本索引中使用的函数 paradigm 的描述如下：

高效与经济兼备

在检索效率和资源消耗上，LightRAG同样表现出色。它通过减少不必要的计算和API调用，有效应对大量的信息查询请求，同时保持资源使用的经济性。在实际应用场景中，这意味着LightRAG能够快速更新并保持高效，即使是在资源受限的情况下也能够稳定运行。

灵活适应动态数据

LightRAG的设计还巧妙地解决了如何适应快速变化的外部数据库的问题。通过增量更新机制，系统只需对新增数据进行索引和合并，避免了对整个数据库的重新处理。这一策略不仅提升了系统的灵活性，也使得LightRAG能够在各种动态环境中稳定运行。

实验验证：超越现有模型

研究团队对LightRAG进行了详尽的实验评估，结果显示，在全面性和多样性等多个维度上，LightRAG显著优于目前主流的RAG模型。这一结果不仅验证了图结构在信息检索中的有效性，也为未来开发更多强大的AI模型提供了有力的参考。

简单尝鲜

安装

源码安装（推荐）：

cd LightRAG
pip install -e .

通过PyPI安装：

pip install lightrag-hku

准备工作

因为我使用的是OpenAI, 所以设置对应的环境变量export OPENAI_API_KEY="sk-..."，

这里我的测试集用的是西游记的节选，地址是：https://libart.lyu.edu.cn/2010/1202/c1449a24647/page.htm

样例代码

lightrag目前支持4种查询模式：

1. naive
2. local
3. global
4. hybrid

import os
from lightrag import LightRAG, QueryParam
from lightrag.llm import gpt_4o_mini_complete, gpt_4o_complete

#########
# Uncomment the below two lines if running in a jupyter notebook to handle the async nature of rag.insert()
# import nest_asyncio 
# nest_asyncio.apply() 
#########

WORKING_DIR = "./books"


if not os.path.exists(WORKING_DIR):
os.mkdir(WORKING_DIR)

rag = LightRAG(
working_dir=WORKING_DIR,
llm_model_func=gpt_4o_mini_complete# Use gpt_4o_mini_complete LLM model
# llm_model_func=gpt_4o_complete# Optionally, use a stronger model
)

with open("./book.txt") as f:
rag.insert(f.read())

# Perform naive search
print(rag.query("What are the top themes in this story?", param=QueryParam(mode="naive")))

# Perform local search
print(rag.query("What are the top themes in this story?", param=QueryParam(mode="local")))

# Perform global search
print(rag.query("What are the top themes in this story?", param=QueryParam(mode="global")))

# Perform hybrid search
print(rag.query("What are the top themes in this story?", param=QueryParam(mode="hybrid")))

当然，你也可以选择本地model, 比如使用Hugging Face的模型：

from lightrag.llm import hf_model_complete, hf_embedding
from transformers import AutoModel, AutoTokenizer

# Initialize LightRAG with Hugging Face model
rag = LightRAG(
working_dir=WORKING_DIR,
llm_model_func=hf_model_complete,# Use Hugging Face model for text generation
llm_model_name='meta-llama/Llama-3.1-8B-Instruct',# Model name from Hugging Face
# Use Hugging Face embedding function
embedding_func=EmbeddingFunc(
embedding_dim=384,
max_token_size=5000,
func=lambda texts: hf_embedding(
texts,
tokenizer=AutoTokenizer.from_pretrained("sentence-transformers/all-MiniLM-L6-v2"),
embed_model=AutoModel.from_pretrained("sentence-transformers/all-MiniLM-L6-v2")
)
),
)

或者使用Ollama模型：

from lightrag.llm import ollama_model_complete, ollama_embedding

# Initialize LightRAG with Ollama model
rag = LightRAG(
working_dir=WORKING_DIR,
llm_model_func=ollama_model_complete,# Use Ollama model for text generation
llm_model_name='your_model_name', # Your model name
# Use Ollama embedding function
embedding_func=EmbeddingFunc(
embedding_dim=768,
max_token_size=8192,
func=lambda texts: ollama_embedding(
texts,
embed_model="nomic-embed-text"
)
),
)

LightRAG的优缺点

1、解决的问题：

• 全面信息理解：通过多跳子图的全局信息提取，能在多领域复杂查询中表现出色。

• 检索效率高：相比传统文本分块遍历方法，利用图和向量的集成，大幅减少检索时间和计算开销。

• 快速适应新信息：增量更新算法使系统能及时整合新数据，保持实时性和有效性。

2、缺点：

• 检索方式：无法自动判断query为细节问题或抽象性问题，只有使用LLM才能做出自动化判断。
  

3、与GraphRAG的不同点：

• 架构设计：LightRAG专注于图结构的向量化实现，避免了GraphRAG的社区遍历。
• 检索方式：LightRAG采用双层检索框架，通过向量化的关键词匹配，实现局部和全局信息的高效整合，降低了计算和存储开销。

总结

LightRAG和GraphRAG都利用图结构来增强RAG的效果，但它们在实现方式、检索策略和适用场景上有显著差异。GraphRAG采用模块化社区结构和分层回答策略，更适合于全局性理解和多层次的复杂问题分析；而LightRAG则侧重于向量化图索引和增量更新机制，适用于高效、动态的数据环境。用户可以根据具体的应用需求选择合适的架构，以实现最优的检索和回答效果。

在实验中，微软开源的GraphRAG表现出较低的效率，正如论文中所提到的，它需要大量资源，难以支持大型知识库的工程应用，且检索速度较慢。而LightRAG的资源消耗较少，检索效率相对更高，尽管两者的检索效果可能相差不大，但LightRAG在实际工程中更具实用性。

但是个人觉得，RAG在实际应用中仍需根据情况不断优化，完全依赖LightRAG也存在局限性。关键在于借鉴LightRAG的优化思路，并将其灵活应用于实际场景。