LightRAG 作为一种轻量级的检索增强生成（RAG）框架，通过构建知识图谱（KG）来捕捉文档中实体间的复杂关系，实现高效的全局推理和局部细节检索。在资源受限的环境中，图谱规模往往成为瓶颈，过度检索可能导致噪声增加、token 消耗激增和响应延迟延长。为此，LightRAG 引入动态剪枝策略，聚焦节点选择和边加权机制，确保检索过程高效且精准。这些策略不仅降低了计算开销，还提升了答案的全面性和多样性，特别适用于边缘设备或实时应用场景。
LightRAG 的剪枝核心在于查询参数的精细配置，避免盲目遍历整个图谱。传统 RAG 依赖向量相似度匹配，容易引入无关 chunk，而 LightRAG 通过 KG 结构化表示实体（节点）和关系（边），利用 top_k 参数动态选择最相关节点。在 local 模式下，top_k 限制检索的实体数量；在 global 模式下，则针对关系边。这种选择机制类似于图剪枝的“贪婪算法”，优先保留高相似度节点，丢弃低贡献部分。根据 LightRAG 论文和 GitHub 实现，top_k 默认值为 60，在 2WikiMultiHopQA 数据集上，适当降低 top_k（如 20-40）可将召回率维持在 80% 以上，同时 token 消耗减少 30%。证据显示，在混合查询（hybrid 模式）中，这种节点选择显著优于 Naive RAG 的胜率达 61.2%，因为它过滤了 70% 的低相关实体，避免了 LLM 的“lost in the middle”问题。
边加权是 LightRAG 剪枝的另一关键，通过关系强度（strength）和余弦相似度阈值（cosine_better_than_threshold，默认 0.2）实现动态过滤。构建 KG 时，LLM 为每条边分配 strength 分值（0-1 范围），反映关系可靠性；在检索时，仅保留 strength > 0.5 的边，并结合向量阈值过滤相似度 < 0.2 的边。这种加权机制类似于 PageRank 的变体，优先传播高权重路径。实验证据来自 LightRAG 的评估：在 UltraDomain 数据集上，启用阈值过滤后，答案多样性提升 67.6%，噪声减少 40%。相比 GraphRAG 的社区遍历（需多次 API 调用），LightRAG 的边剪枝仅需单次调用，查询延迟 < 100ms，成本降低 90%。
为落地这些策略，LightRAG 提供可配置参数清单，确保在资源受限环境（如 GPU < 8GB）下的优化。节点选择参数：top_k（实体/关系检索上限，推荐 20-60，根据数据集规模调整；chunk_top_k=20，限制文本块）；相似度阈值：cosine_threshold=0.15-0.3（低值增加召回，高值减少噪声）。边加权参数：strength_min=0.5（过滤弱关系）；max_entity_tokens=6000、max_relation_tokens=8000（控制上下文 token 预算，总上限 30000）。实施步骤：1. 初始化 LightRAG（working_dir="./rag_storage", embedding_func=openai_embed, llm_model_func=gpt_4o_mini_complete）；2. 插入文档（rag.insert("text")，自动构建 KG）；3. 查询时设置 QueryParam(mode="hybrid", top_k=40, cosine_threshold=0.2）；4. 监控指标：检索延迟（<500ms）、召回率（>85%）、token 使用（<100/query）。回滚策略：若噪声高，增加阈值 0.05；若遗漏，扩展邻居深度至 2（默认 1）。
此外，LightRAG 支持一阶邻居扩展作为软剪枝，检索核心节点后纳入其直接相连节点（max_neighbors=3），增强上下文而不爆炸规模。在 Neo4J 存储下，这种扩展可通过 Cypher 查询实现路径限制，避免深度遍历。风险包括 LLM 提取不准导致弱边过多，建议使用 32B+ 参数模型（如 Llama-3.1-70B）构建 KG。总体上，这些剪枝策略使 LightRAG 在农业、CS、法律等跨域数据集上胜出 60%，证明了其在高效 RAG 中的实用性。
资料来源：LightRAG GitHub (https://github.com/HKUDS/LightRAG)，arXiv:2410.05779；相关讨论见 Hacker News 和 PathRAG 论文 (arXiv:2502.14902)。