LightRAG 作为高效的图增强 RAG 框架，其查询融合蒸馏管道是核心创新。通过双层图索引（本地实体与全局关系），结合多关键词查询融合与 LLM 精炼描述蒸馏，实现对复杂查询的高效处理，避免传统 RAG 的碎片化召回问题。这种管道不仅将 LLM 调用量降低约 50%，还显著提升召回精度与响应速度，特别适用于大规模动态知识库。
LightRAG 的双图索引机制是管道的基础。系统首先将文档分块（chunk_token_size=1200，overlap=100），利用 LLM 提取实体（节点，如 “养蜂人”）与关系（边，如 “观察蜜蜂”）。随后，通过 LLM Profiling（P (・) 函数）为每个节点 / 边生成键值对：键为检索关键词（实体名为单一 low-level key，关系附加 high-level 主题关键词），值为精炼摘要描述。这种 “蒸馏” 过程浓缩上下文，过滤噪声，仅需 summary_context_size=10000 tokens 与 summary_max_tokens=500，避免冗长原始文本注入 LLM。
在查询阶段，管道启动查询融合。首先，LLM 从用户查询提取 low-level keys（具体实体）和 high-level keys（抽象主题），生成多查询变体。例如，对 “气候变化对蜜蜂影响？” 提取 “蜜蜂”（low）与 “气候变化影响”（high）。然后，双层检索：local mode 匹配实体向量（top_k=60，cosine_better_than_threshold=0.2），global 匹配关系；hybrid/mix mode 融合两者，并扩展 1-hop 邻居实体，形成全面上下文。该融合使用 reranker（如 bge-reranker-v2-m3）重排序 chunk_top_k=20 块，确保高相关性。“LightRAG 采用双层检索，提升对复杂查询的理解。” 最终上下文 token 预算 max_total_tokens=30000（实体 6000、关系 8000），远低于 GraphRAG 的百万级。
蒸馏管道的关键在于增量优化与参数调优。索引时启用 llm_cache 与 entity_extract_max_gleaning=1 循环，减少重复调用；查询时 llm_model_max_async=4 并行，embedding_batch_num=32。去重（D (・)）合并同义实体，避免图冗余。新文档仅局部处理后 union 入主图，无需重建。监控要点：追踪 cosine_threshold（默认 0.2，提升召回调低至 0.15），top_k（全局 60→40 防噪声），RAGAS 评估 context_precision。风险：提取噪声用 enable_rerank=True 缓解；回滚：清 cache（aclear_cache (modes=["hybrid"])）或重置存储。
落地清单：
- 初始化：LightRAG(working_dir="./rag_storage", embedding_func=openai_embed, llm_model_func=gpt_4o_mini_complete)，await initialize_storages()。
- 索引参数：chunk_token_size=1200/800（长文调小），max_parallel_insert=4。
- 查询阈值：QueryParam(mode="mix", top_k=50, enable_rerank=True, max_entity_tokens=5000)。
- 存储选型：小规模 NetworkX；生产 Neo4J/PG（env NEO4J_URI=...），vector Qdrant/Milvus。
- 监控 / 警报：Langfuse tracing（[observability]），token_tracker 超 10k 告警；A/B 测试 hybrid vs naive。
- 部署：lightrag-server + Docker，Ollama 兼容 WebUI。
实际测试显示，LightRAG mix mode 在农业 / 法律数据集召回胜 GraphRAG 10-20%，响应延迟 <2s（异步）。相比 baseline，赋能性提升 57%，成本降至 1/10。该管道适用于企业 KG-QA、报告分析等。
资料来源：HKUDS/LightRAG GitHub（README & examples），arXiv:2410.05779。