LightRAG 通过双图结构（实体节点与关系边图）实现知识蒸馏式压缩与融合检索，避免传统 RAG 的扁平向量表示导致的上下文丢失与高延迟问题。这种设计观点的核心在于：将冗余文本“蒸馏”为结构化图边，实现低资源下的快速全局/局部知识检索，特别适用于动态更新场景。
证据显示，LightRAG 先对文档分块（chunk_token_size=1200, overlap=100），用 LLM（如 gpt-4o-mini）提取实体（节点，如“养蜂人”）与关系（边，如“观察蜜蜂”），生成键值对（P(·)），并去重（D(·)）后向量化存储（NanoVectorDB 默认）。图存储用 NetworkX，支持 Neo4j 等扩展。检索分双层：低层（local）匹配实体向量（top_k=60），高层（global）遍历关系边（max_relation_tokens=8000），hybrid/mix 模式融合 reranker（如 bge-reranker-v2-m3），token 消耗 <100 vs GraphRAG 的 61k，效率提升 99.98%。实验在 Legal 等数据集上胜率超 GraphRAG 54.3%，更新仅增量 union 操作，成本降 80%。
落地参数清单：
- 初始化：embedding_func=openai_embed (dim=1536, batch=32, async=16)，llm_model_func=gpt_4o_mini_complete (max_async=4)，chunk_token_size=1200。
- 查询：QueryParam(mode="hybrid", top_k=60, chunk_top_k=20, max_entity_tokens=6000, max_total_tokens=30000, enable_rerank=True)，cosine_better_than_threshold=0.2。
- 存储调优：低资源用 JsonKVStorage + NanoVectorDB + NetworkX；生产用 PGVectorStorage + Neo4JStorage (URI=neo4j://host:7687)，vector_db_storage_cls_kwargs={"cosine_better_than_threshold":0.3}。
- 部署：uv sync --extra api（推荐），lightrag-server，env 配置 LLM_API_KEY/Ollama，监控 RAGAS/Langfuse (LANGFUSE_ENABLE_TRACE=true)，多租户 workspace="prod"。
- 低延迟策略：enable_llm_cache=True，embedding_cache_config={"enabled":True,"similarity_threshold":0.95}；增量 insert(ids=["doc1"]) + adelete_by_doc_id；Docker compose up。
回滚：若实体提取弱，切换 LLM (llm_model_name="qwen2.5-7b") 或 entity_extract_max_gleaning=2；超时用 llm_model_max_async=2。风险：Embedding 模型变更需重建向量表。
资料来源：