LightRAG 是一种专为资源受限环境设计的简单高效的检索增强生成（RAG）系统。它通过双层实体-关系提取和基于知识图谱（KG）的检索机制，实现低延迟和高准确性的信息检索，而无需复杂的优化或大量依赖。这使得它特别适合边缘设备或计算资源有限的场景，例如移动应用或小型服务器部署。与传统 RAG 系统相比，LightRAG 在基准测试中表现出色，例如在综合性、多样性和赋权性指标上优于 NaiveRAG 和 GraphRAG，平均胜率超过 60%。
LightRAG 的核心管道分为索引和检索两个主要阶段。在索引阶段，首先对输入文档进行分块处理，每个块的最大 token 数默认为 1200，重叠 token 数为 100，以确保上下文连续性。分块后，使用 LLM 进行实体提取：从每个文本块中提取本地实体，形成初步的 KG 节点。随后，通过全局摘要机制合并这些实体，生成关系描述。这里的双层提取是关键——第一层聚焦局部实体，第二层通过 LLM 总结跨块关系，避免了冗余和噪声。证据显示，这种方法在小模型如 Qwen2-7B 上也能提取准确率达 80% 以上，尤其在处理长文档时效率更高。图构建使用 NetworkX 或 Neo4J 等存储，将实体作为节点、关系作为边，支持权重和关键词标注。
在检索阶段，LightRAG 支持多种模式：local 模式聚焦实体上下文，global 模式遍历整个图谱，hybrid 模式结合向量搜索和图检索，提供最全面的响应。查询时，首先通过嵌入模型（如 BAAI/bge-m3）生成查询向量，在 NanoVectorDB 或 Faiss 中检索 top_k（默认 60）相关实体/关系。然后，动态控制 token 预算：实体上下文上限 6000 tokens，关系上限 8000 tokens，总预算 30000 tokens，确保 LLM 输入高效。混合模式下，启用 reranker（如 BAAI/bge-reranker-v2-m3）对检索块重排序，提升相关性 20-30%。实验证据表明，在法律和农业数据集上，hybrid 模式在全面性上胜出率达 84.8%。
要落地实现 LightRAG 核心管道，以下是关键参数和配置清单。首先，环境准备：使用 uv 或 pip 安装 lightrag-hku，支持 Ollama 或 Hugging Face 模型。LLM 要求至少 32B 参数、32K 上下文（如 Llama-3.1-8B），嵌入模型固定为 1536 维（如 text-embedding-3-large）。初始化 LightRAG 实例时，指定 working_dir 为持久化目录，embedding_func 和 llm_model_func 注入自定义函数。索引参数：chunk_token_size=1200, chunk_overlap_token_size=100, entity_extract_max_gleaning=1（控制提取循环）。存储选择：开发用 JsonKVStorage + NanoVectorDBStorage + NetworkXStorage；生产用 PostgreSQL（统一 KV、向量、图）或 Neo4J（高性能图查询）。插入文档时，使用 rag.insert(texts, file_paths) 支持多格式（PDF、DOC 等 via textract），并启用 llm_cache 以加速重复提取。
查询配置清单：QueryParam(mode="hybrid", top_k=60, chunk_top_k=20, enable_rerank=True, max_total_tokens=30000)。对于流式响应，设置 stream=True。监控点包括：token 使用（via TokenTracker），检索延迟（目标 <500ms），KG 节点数（<10k 以防膨胀）。回滚策略：若提取准确率低，切换更大 LLM；若延迟高，降低 top_k 或使用 Faiss 加速向量搜索。风险控制：定期 clear_cache(modes=["hybrid"]) 避免缓存污染；删除文档时用 adelete_by_doc_id 自动重建共享实体。
在资源受限环境中，LightRAG 的最小依赖设计（如无外部服务）确保部署简单：Docker 镜像支持一键启动，Ollama 集成允许本地运行。实际参数调优：对于低 RAM GPU（<8GB），用 gemma2:2b 模型，num_ctx=26k，处理 200 实体只需 6GB。测试中，它在混合查询上 rerank 后准确率提升显著，适合实时 Q&A 系统。
资料来源：主要基于 LightRAG GitHub 仓库（https://github.com/HKUDS/LightRAG）和相关 EMNLP 2025 论文描述。