结构化索引:当 RAG 必须跨文档、跨章节、跨实体时

RAG ENGINEERING · CHAPTER 03

结构化索引

当 RAG 必须跨文档

跨章节、跨实体时怎么办？

RAPTOR · GRAPHRAG · KNOWLEDGE FILESYSTEM

索引之前，先把知识整理一遍。面对跨文档、跨章节、跨实体的问题，结构决定了 RAG 能否找到完整答案。

SERIES NOTE

本系列文章为《AI Agents in Depth》（李博杰著）的个人读书心得体会和 Agent 工程经验分享。

原书在线版：bojieli.github.io/ai-agent-book/

本文看点

做 Agent 评审这几年，我越来越不愿意只听团队说“我们用 RAG 了”。一聊检索质量，十个项目里有八个会卡在同一类问题上——跨文档综合、多跳关系、宏观到细节的层层递进。稠密检索 + 稀疏检索 + 重排序的三件套打得很整齐，命中率也漂亮，可一旦用户问的不是“哪段写过退款政策”，而是“SSE 指令集和 AVX 指令集在架构上有什么本质区别”，三件套就集体失灵。问题不在检索器本身，而在被检索的对象——索引之前，原始知识根本没有被结构化。

这是我观察下来最普遍也最容易低估的一步：索引之前，先把知识整理一遍。结构化索引的代价是在构建和查询时都多调用几次 LLM，但它解决的是另一类问题——把“一堆扁平片段”升级成“一个能跨章节导航的知识体”。本篇按 RAPTOR、GraphRAG、文件系统范式三条路展开，讲清什么时候值得做结构化、做到什么程度就够。

把第 5 篇和第 6 篇放在一起看，稠密嵌入擅长语义、稀疏嵌入擅长关键词、神经重排序擅长把两者排序到一起。这套流水线对“找到包含某信息的文档片段”已经足够。但面对另外两类查询，它的盲区立刻暴露。

第一类叫跨文档综合。用户问“SSE 和 AVX 在架构上的区别”，答案散落在 Intel SDM 手册的好几章里，且每一章只描述其中一个侧面。稠密检索召回的是若干独立片段，模型必须自己把它们拼起来——一旦片段之间的指代关系（“这种指令”“该寄存器”）断裂，生成出来的答案就开始含糊甚至矛盾。

第二类叫多跳关系推理。用户的医生所在医院的地址是什么？这是一条“用户 → 医生 → 医院 → 地址”的关系链。即使每一步都能命中，扁平化的向量检索也要把它拆成三次独立检索、再由 LLM 拼接，效率低且容易断链；而只要链路中任何一段指代出错（“该医生”指代两位同名医生之一），整个回答就垮掉。

RAPTOR 的全名是 Recursive Abstractive Processing for Tree-Organized Retrieval，思路非常朴素——自底向上，递归抽象。

第一步，把长文档切成小文本块作为叶子节点；第二步，用嵌入相似度把语义相近的叶子聚类到同一组；第三步，对每一组调用 LLM 生成一段更高级的摘要作为父节点；第四步，把父节点当作新的叶子，重复前两步，直到树的深度达到设定值。最终形成的结构是一棵从具体细节（叶子）到高度概括（根）的知识树。

检索时，RAPTOR 在多个抽象层次并行搜索。如果用户问“什么是 SSE 指令集”，可能先在高层的“x86 SIMD 指令集各代演进”摘要节点命中，再沿树向下钻到“SSE2 支持 128 位整数运算”这样的叶子节点。这种“宏观先命中，再下沉细节”的路径特别适合从概念逐步深入细节的查询。

我在做 RAG 评估时观察到一个现象：纯扁平检索面对“概述—细节”型问题时，往往把宏观点和细节点混在同一个召回池里，模型必须自己判断哪些是宏观哪些是细节，于是常出现“答得太细”或“答得太泛”两种失真。RAPTOR 的多层次结构相当于把这种判断从生成阶段挪到了索引阶段，模型只负责按需逐层取。

RAPTOR 的代价也是显性的：每一层聚类都要调用 LLM 生成摘要；构建一遍成本可能比纯嵌入高一个数量级；查询时虽然能加速，但查询本身也要做几次相似度计算。所以它不便宜。

GraphRAG 走的是另一条路——把知识建模成实体—关系三元组（Entity-Relationship Triple）。一条三元组形如（北京，是首都，中国）或（张医生-A，科室，牙科），大量三元组交织在一起，就形成了一张知识之网。检索时，系统不是按相似度召回片段，而是从查询涉及的实体出发，沿关系边遍历，直到把所有相关实体和关系串成一条证据链。

GraphRAG 有两个 RAPTOR 难以替代的能力。第一个是多跳关系推理。“我的医生所在医院的地址”这类查询，沿“用户 → 医生 → 医院 → 地址”的关系链走一遍就出来，无需模型二次拼接。第二个是实体消歧——区分现实中两个同名的人。

注意它和稠密嵌入里的“一词多义”消歧不是同一件事：词义消歧靠上下文嵌入就能解决，而实体消歧（区分两位“张医生”）需要维护关于实体本身的知识。在 Advanced JSON Cards 里靠 person、relationship 等人工字段做这件事；在 GraphRAG 里则成为图结构的原生能力。

不过 GraphRAG 不是万能的。把自然语言转成三元组不可避免地导致语义降级——“如果下周还下雨，我就取消去海边的计划，改成去博物馆”这种带条件判断和时间依赖的句子，被分解后只剩下两条孤立事实，核心的条件逻辑全部丢失。三元组提取的准确性也高度依赖 LLM 的理解能力，错误提取会造成知识污染，越自信的污染越难发现。

RAPTOR 和 GraphRAG 是学术界对知识组织的主要探索。字节跳动火山引擎开源的 OpenViking 提出了第三种哲学——文件系统范式：把所有上下文（记忆、资源、技能）映射为虚拟文件系统中的目录和文件，每个条目拥有唯一 URI。

这套设计的核心是 L0/L1/L2 三层上下文按需加载。资源写入时，系统自动将原始内容提炼为三个抽象层次：L0（摘要）约 100 tokens 的一句话概述，用于快速判断目录相关性；L1（概览）约 2000 tokens 的核心信息与使用场景，供 Agent 规划决策；L2（全文）为完整原始内容，仅在需要深入时按需加载。

这与 Skills 的渐进式披露是同一种思路——先让 Agent 只看到轻量元信息，确有需要时再逐层拉取完整内容。但文件系统范式有一个极其容易被忽视、却直接决定检索成败的前提：文件之间必须建立起链接与索引。

正确做法是把知识库组织得像 Wikipedia——每个条目在提及其他条目时都链接过去，再辅以入口页和索引页，让 Agent 能顺着链接从一个概念走到相关概念。这相当于用轻量文件链接，实现 GraphRAG 实体关系图谱的一部分导航能力。

另一个工程决策是选 Markdown 纯文本而非专用数据库。纯文本可读、可编辑、可 Git 版本控制、可回滚；更重要的是 Agent 拥有 write_file 能力后可在工作分支上自主记录和组织知识，再通过审核流程合入主库。

我评审过几个“过度结构化”的项目，失败原因都出在同一处。

按我这几年看过的项目，给三组可立刻动手的建议。

结构化索引的真正价值，不在于用了哪种花哨算法，而在于把“知识在被使用之前就被整理过”这件事，变成工程上可重复、可追溯、可回滚的流程。能不能把它做扎实，比选 RAPTOR 还是 GraphRAG 更重要。

把索引前先整理一遍，是这一章想强调的最朴素也最容易被跳过的步骤。RAPTOR、GraphRAG、文件系统范式是三种不同的整理哲学，没有绝对优劣，关键是与你的查询类型对齐。下一次我们看一个更现实的问题：当知识库要持续接收新信息时，怎么保证它不被改乱。