在传统 RAG 系统中，文档被切分为固定大小的文本块后直接存入向量数据库，检索时依赖语义相似度匹配。这种方式虽然实现简单，但在处理需要多跳推理的复杂问题时往往力不从心 —— 用户提问涉及多个相互关联的概念时，单一文本块的局部信息无法支撑完整答案的生成。LightRAG 通过引入知识图谱索引范式，将文档内容抽象为实体与关系的结构化表示，使得系统能够沿着图谱中的边进行遍历推理，从而解锁了跨文档、跨段落的多跳检索能力。

图索引工作流拆解

LightRAG 的索引流程并非简单地将文本向量化，而是首先调用大语言模型从原始文档中抽取实体及其关联关系。系统将文档拆分为约 1200 个 token 的块（默认值，可通过 chunk_token_size 配置），相邻块之间保留 100 token 的重叠以保证语义连续性。随后，LLM 会对每个文本块进行分析，识别出其中的实体节点（如人物、地点、组织、事件）以及实体之间的关系边。每个实体被赋予描述性文本，每个关系被标注为三元组形式 —— 源实体、目标实体以及关系类型。这种结构化输出的生成依赖模型对上下文的理解能力，因此 LightRAG 对 LLM 的要求高于传统 RAG 系统：官方建议索引阶段使用至少 32B 参数的模型，且上下文窗口不低于 32KB。

抽取得到的实体和关系随后存入图存储后端。LightRAG 支持多种图数据库作为存储后端，默认使用 NetworkX 内存图，便于快速原型开发；生产环境推荐切换到 Neo4J 以获得更好的持久化能力和查询性能。此外，系统还会为每个实体和关系生成向量嵌入，存入向量存储以便支持基于语义相似度的检索。这一步使用 node2vec 算法将图结构信息编码为稠密向量，使系统既能通过图遍历进行推理，也能通过向量相似度进行匹配。

六种检索模式的工程选择

LightRAG 提供了六种检索模式，每种模式对应不同的信息获取策略，开发者需要根据实际查询特征选择合适的模式。

局部模式（local） 聚焦于与查询词直接相关的实体及其邻接关系。系统首先通过向量相似度定位最相关的实体节点，然后沿着这些实体的边向外扩展一圈，收集相邻实体、关系以及关联的原始文本块。这种模式适合需要深入了解某个具体实体详细信息的查询，例如查询某个角色的背景故事或某个地点的历史事件。由于只遍历有限步数，局部模式的计算开销较低，响应速度快。

全局模式（global） 则从整个知识图谱的宏观视角出发，通过关系匹配定位与查询相关的所有实体和关系，不受局部邻域限制。这种模式利用图谱的全局连通性，能够捕获分散在不同文档段落中的相关信息，特别适合需要综合总结的主题性查询，例如 “这部小说的主要主题是什么” 或 “该技术的发展历程”。全局模式能够跨越多个实体和关系进行信息聚合，但相应地需要更多的计算资源和 token 预算。

混合模式（hybrid） 顾名思义，是局部模式与全局模式的结合。系统并行执行两种检索策略，然后对结果进行合并去重。混合模式能够在保持全局覆盖的同时确保局部细节不丢失，是大多数场景下的默认选择，尤其适用于复杂的多方面查询。LightRAG 在 2025 年 8 月引入了 reranker 机制后，混合模式进一步增强了文本块的重排序能力，已成为官方推荐的默认查询方式。

朴素模式（naive） 是最基础的向量检索，绕过知识图谱直接对文本块进行相似度搜索。这种模式保留了传统 RAG 的简单性，适合快速验证或对图索引不熟悉的开发者进行调试。当系统图谱尚未充分构建或索引数据量较小时，朴素模式可以作为兜底方案。

混合检索模式（mix） 与 hybrid 不同，它将知识图谱检索与向量检索的结果进行更细粒度的融合，而非简单合并。系统会根据实体相关性和文本块相关性分别计算得分，然后加权求和后排序输出。这种模式在处理同时需要精确实体信息和丰富上下文内容的查询时表现出色。

旁路模式（bypass） 则完全跳过检索阶段，直接将原始查询作为上下文发送给 LLM，适用于无需检索的纯对话场景或系统异常时的降级策略。

关键参数配置清单

在实际工程部署中，以下参数的配置直接影响检索效果与系统性能。

token 预算控制 是最关键的调优点之一。LightRAG 提供了三级 token 分配机制：max_entity_tokens（默认 6000）控制实体上下文上限，max_relation_tokens（默认 8000）控制关系上下文上限，max_total_tokens（默认 30000）控制整个查询的总 token 消耗。在实际应用中，需要根据 LLM 的上下文窗口大小和查询复杂度动态调整这些值 —— 如果答案频繁出现截断或信息不完整，应适当提高总 token 预算；如果延迟过高，则需要收紧各分项上限。

top_k 参数 控制检索返回的候选数量。entity 相关的 top_k（默认 60）决定了局部模式中每个查询词返回的实体数量，chunk_top_k（默认 20）决定了向量检索阶段返回的文本块数量。增大 top_k 能提高召回率，但会显著增加后续处理（如 reranking）的计算开销和最终 prompt 的长度。建议在生产环境中通过监控 precision@K 和 recall@K 指标来迭代调整。

实体抽取迭代次数 由 entity_extract_max_gleanning 参数控制，默认值为 1。对于语义复杂或实体嵌套程度高的文档，可以尝试将该值提高到 2-3，使系统能够基于前一轮抽取结果进行二次校正，从而提高实体识别的完整性和准确性。但需要注意的是，每次迭代都会额外消耗 LLM 调用配额和 token 成本。

并行处理配置 在大规模文档索引阶段尤为重要。max_parallel_insert 参数控制同时处理的文档数量，默认值为 2。对于索引性能要求较高的场景，可以将该值提高到 4-8，但不宜超过 10，因为此阶段的性能瓶颈通常在 LLM API 的调用延迟和速率限制，而非 CPU 或 IO。

存储后端选型建议

LightRAG 的四类存储（KV 存储、向量存储、图存储、文档状态存储）均支持多种后端实现，选择时需要权衡部署复杂度、查询性能和运维成本。

向量存储层面，Milvus 和 Qdrant 在大规模向量场景下性能优于 Postgres 提供的 pgvector，特别是在需要高并发检索的生产环境中。图存储层面，Neo4J 经过官方测试验证，在生产环境中的查询性能和稳定性优于 PostgreSQL 搭配 AGE 插件的方案。对于已有统一数据库基础设施的团队，使用 Postgres 同时承载 KV、向量和图存储可以简化运维，但需要接受一定的性能折衷。MongoDB 作为全栈存储方案在文档型数据场景下表现出色，2025 年 2 月的官方更新使其成为一站式部署的便捷选择。2026 年 3 月新集成的 OpenSearch 则提供了企业级的全文搜索与向量搜索统一能力，适合已有 Elastic 技术栈的团队。

需要特别注意的是，embedding 模型必须在文档索引之前确定，并在查询阶段保持一致。切换 embedding 模型会导致向量维度变化，对于某些存储方案（如 PostgreSQL 向量表）需要删除原有表结构后重建。

总结

LightRAG 通过将非结构化文档转化为实体 - 关系图谱，为 RAG 系统赋予了结构化推理能力。其六种检索模式覆盖了从细节探查到全局汇总的不同需求，token 预算和 top_k 等关键参数提供了细粒度的效果 - 性能调优空间。在工程落地时，开发者应根据查询特征选择合适的检索模式，并根据 LLM 能力和数据规模调整 token 分配策略，同时结合团队现有的基础设施选择合适的存储后端。

资料来源：LightRAG 官方 GitHub 仓库（https://github.com/HKUDS/LightRAG）