前八篇是在造船，这篇终于要出海了如果你一路读过来，此刻脑子里应该存着一张清单：第 03 篇：AST 函数级分割 + 向量检索，Recall@5 = 0.958，是文本方案的天花板第 05 篇：图检索救出 Q8，但 BFS 噪声拖垮了 Q1——向量和图是"一换一"的买卖第 06、07 篇：结构感知 embedding 和混合检索都没能真正弥合这道裂缝第 08 篇：三路正交，向量管语义、图管结构、符号管精确——分开部署，按查询意图路由这些都是在一个 30 个函数的"玩具"代码库上跑出来的。玩具很诚实，但它也是玩具。今天换个场地。LightRAG 是目前 GitHub Star 数最多的开源知识图谱 RAG 框架之一，代码库已经用codebase-memory-mcp完整索引：20,674 个节点、94,517 条边，覆盖 409 个 Python 文件外加 101 个 TypeScript 文件（Web UI）。这个规模放到真实工程场景里只能算中型项目，但已经足够让前几篇实验里的所有结论在真实战场上接受检验了。这篇文章的任务很简单：拿三个真实问题，分别调用三条检索路径，把返回结果原样摊开，让你看清楚每路能给什么、给不了什么。先把地图看一眼在开始查询之前，先对着整体架构做一次定向。LightRAG 这个名字很容易让人以为它只是一个 RAG 工具库，但实际的代码结构远比"一个检索工具"复杂。运行get_architecture后，最重要的信息不是文件列表，而是层次划分：entry layer: kg/, chunker/ ← 入口：存储适配器、分块器 core layer: base, api, parser ← 核心：抽象基类、REST API、文档解析 internal: examples/, tests/ ← 内部：示例、测试（对外不暴露）这张图立刻告诉你：如果你想理解"LightRAG 怎么处理一个文档"，主战场在lightrag/目录，入口在lightrag.py，底层存储实现在kg/下（支持 Neo4j、MongoDB、Qdrant、Milvus、PostgreSQL 等 10 余种后端）。现在开始真正的检索。第一路：向量路径——用自然语言问"怎么检索"问题：LightRAG 支持哪些检索模式，每种模式分别适合什么场景？这是一个典型的"功能查询"——提问者不知道函数叫什么，只知道自己想了解什么。这正是向量路径最擅长处理的类型。工具：search_graph（BM25 + 向量双索引）query: "query search hybrid retrieval mode" label: Method limit: 5返回结果（节选最关键的一条，其余是测试文件）：QueryParam (lightrag/base.py, line 83) "local": Focuses on context-dependent information. "global": Utilizes global knowledge. "hybrid": Combines local and global retrieval methods. "naive": Performs a basic search without advanced techniques. "mix": Integrates knowledge graph and vector retrieval. "bypass": ...一条查询命中了这个：classQueryParam:"""Configuration parameters for query execution in LightRAG."""mode:Literal["local","global","hybrid","naive","mix","bypass"]="mix"6 种检索模式直接在QueryParam类里。这个类的 docstring 把每种模式解释得很清楚：
前八篇是在造船，这篇终于要出海了如果你一路读过来，此刻脑子里应该存着一张清单：第 03 篇：AST 函数级分割 + 向量检索，Recall@5 = 0.958，是文本方案的天花板第 05 篇：图检索救出 Q8，但 BFS 噪声拖垮了 Q1——向量和图是"一换一"的买卖第 06、07 篇：结构感知 embedding 和混合检索都没能真正弥合这道裂缝第 08 篇：三路正交，向量管语义、图管结构、符号管精确——分开部署，按查询意图路由这些都是在一个 30 个函数的"玩具"代码库上跑出来的。玩具很诚实，但它也是玩具。今天换个场地。LightRAG 是目前 GitHub Star 数最多的开源知识图谱 RAG 框架之一，代码库已经用codebase-memory-mcp完整索引：20,674 个节点、94,517 条边，覆盖 409 个 Python 文件外加 101 个 TypeScript 文件（Web UI）。这个规模放到真实工程场景里只能算中型项目，但已经足够让前几篇实验里的所有结论在真实战场上接受检验了。这篇文章的任务很简单：拿三个真实问题，分别调用三条检索路径，把返回结果原样摊开，让你看清楚每路能给什么、给不了什么。先把地图看一眼在开始查询之前，先对着整体架构做一次定向。LightRAG 这个名字很容易让人以为它只是一个 RAG 工具库，但实际的代码结构远比"一个检索工具"复杂。运行get_architecture后，最重要的信息不是文件列表，而是层次划分：entry layer: kg/, chunker/ ← 入口：存储适配器、分块器 core layer: base, api, parser ← 核心：抽象基类、REST API、文档解析 internal: examples/, tests/ ← 内部：示例、测试（对外不暴露）这张图立刻告诉你：如果你想理解"LightRAG 怎么处理一个文档"，主战场在lightrag/目录，入口在lightrag.py，底层存储实现在kg/下（支持 Neo4j、MongoDB、Qdrant、Milvus、PostgreSQL 等 10 余种后端）。现在开始真正的检索。第一路：向量路径——用自然语言问"怎么检索"问题：LightRAG 支持哪些检索模式，每种模式分别适合什么场景？这是一个典型的"功能查询"——提问者不知道函数叫什么，只知道自己想了解什么。这正是向量路径最擅长处理的类型。工具：search_graph（BM25 + 向量双索引）query: "query search hybrid retrieval mode" label: Method limit: 5返回结果（节选最关键的一条，其余是测试文件）：QueryParam (lightrag/base.py, line 83) "local": Focuses on context-dependent information. "global": Utilizes global knowledge. "hybrid": Combines local and global retrieval methods. "naive": Performs a basic search without advanced techniques. "mix": Integrates knowledge graph and vector retrieval. "bypass": ...一条查询命中了这个：classQueryParam:"""Configuration parameters for query execution in LightRAG."""mode:Literal["local","global","hybrid","naive","mix","bypass"]="mix"6 种检索模式直接在QueryParam类里。这个类的 docstring 把每种模式解释得很清楚：
