LightRAG 作为 EMNLP 2025 收录的核心技术方案，针对传统 RAG 在低资源环境下的检索碎片化和上下文丢失问题，提出了一种简单高效的图蒸馏融合机制。通过双层图结构（实体图与关系图），LightRAG 实现向量检索与知识图谱的无缝融合，确保在 CPU 或边缘设备上也能达到基准级性能。这种设计特别适合资源受限的部署场景，如移动端知识库或小型服务器，避免了 GraphRAG 等方案的高 token 消耗和重建开销。
LightRAG 的核心在于其图索引构建与双层检索范式。首先，在索引阶段，将文档分块后利用 LLM 提取实体（如人名、地点）和关系（如“属于”“影响”），生成键值对描述（键为关键词，值为摘要文本），并通过去重机制合并重复节点，避免图谱膨胀。其次，双层检索区分低层（local，精确实体匹配）和高层（global，主题聚合），使用局部/全局关键词在向量数据库中匹配实体/关系，再扩展邻接节点，形成高阶上下文。这种“图边蒸馏”过程将原始文本浓缩为结构化知识，仅需少于 100 个 token 和单次 API 调用即可完成检索，远优于传统方法的扁平片段召回。
在低资源 RAG 部署中，LightRAG 的调优参数至关重要。核心配置包括：COSINE_THRESHOLD=0.2（余弦相似度阈值，过滤低相关 chunk）；TOP_K=40（图中实体/关系检索上限，平衡召回与速度）；CHUNK_TOP_K=10（向量 chunk 召回数，适用于内存 <4GB）；MAX_ENTITY_TOKENS=10000 / MAX_RELATION_TOKENS=10000（发送给 LLM 的实体/关系 token 上限，防止溢出）；RELATED_CHUNK_NUMBER=5（每个实体关联 chunk 数，控制 rerank 时间）。这些参数可通过 .env 文件微调，例如在 Ollama 本地模型下设置 OLLAMA_EMULATING_MODEL_NAME=lightrag 和 MAX_ASYNC=4（并发上限），实现单机部署。安装流程简化为：pip install "lightrag-hku[api]"，复制 env.example 为 .env，运行 lightrag-server，支持 Docker Compose 一键启动 Web UI & API。
工程实现上，LightRAG 提供完整管道：初始化 LightRAG(working_dir="./rag_storage", embedding_func=openai_embed, llm_model_func=gpt_4o_mini_complete)，调用 await rag.initialize_storages() 和 await initialize_pipeline_status()，然后 rag.insert("文档内容") 构建图谱。查询时使用 QueryParam(mode="hybrid") 执行混合检索，支持流式输出。EMNLP 基准测试显示，在多跳 QA 和总结任务上，LightRAG 胜率超 GraphRAG 达 70%以上，尤其在动态数据集增量更新场景（无需重建 KG，仅合并新实体）。例如，在法律文档 5GB 索引中，LightRAG 成本仅为 GraphRAG 的 10%，响应延迟 <1s。
为确保生产稳定性，监控要点包括：日志级别 LOG_LEVEL=INFO，启用 ENABLE_LLM_CACHE=true（缓存 LLM 响应，减流式开销）；RERANK_MODEL=jina-rerank-v2（可选重排，提升精度）；MAX_GRAPH_NODES=1000（WebUI 图可视化上限）。回滚策略：若新文档引入噪声，设置 FORCE_LLM_SUMMARY_ON_MERGE=6（重复实体达 6 次触发重摘要）；异常时 fallback 到 naive 向量检索（mode="vector"）。低资源极限下，优先 CPU 嵌入模型如 bge-m3（EMBEDDING_DIM=1024），并限制 MAX_PARALLEL_INSERT=2。
部署清单：
LightRAG 通过上述机制，将复杂图 RAG 工程化为即插即用管道，完美契合低资源需求。实际项目中，先小规模测试图构建质量（可视化 graph_chunk_entity_relation.graphml），渐进上线。
资料来源：