1. 98.7%这个数字到底在说什么
先把结论摆在前面：PageIndex 那个 98.7% 的准确率，不是"随便问什么都能答对"的意思，它是在特定评测集、特定任务形态下测出来的一个数字。我见过太多人拿着一个漂亮的百分比就去跟老板汇报"我们的 RAG 准确率能到 98%"，结果上线之后被真实用户的问题按在地上摩擦。所以这篇东西我想干的事，是把 PageIndex 这套无向量树索引 RAG 的里子翻出来，讲清楚它凭什么能做到这个数、这个数在什么条件下成立、以及你把它搬到自己业务里之后大概率会在哪里翻车。
如果你正在做 RAG 知识库、正在纠结要不要上向量数据库、或者已经被"召回不准、答非所问、切片切得稀碎"这些问题折磨过，那这篇内容应该对你有用。我会尽量少讲空话，多讲机制、多讲边界、多讲我自己踩过的坑。核心关键词就几个：PageIndex、无向量树索引、RAG、向量检索、大模型。这几个词之间的关系，就是整篇文章的主线。
先说一个反直觉的点：PageIndex 最核心的主张，恰恰是"不用向量检索"。这在当下这个向量数据库满天飞、embedding 模型卷到飞起的环境里，听起来像是开倒车。但它背后的逻辑其实很朴素——向量检索本质上是在做"语义相似度"的近似匹配，而很多真实问题需要的不是"相似"，是"精确命中某一段结构化的内容"。这两件事的差别，就是 98.7% 和 70% 的差别来源之一。
2. 无向量树索引到底把文档变成了什么
2.1 从"切成一堆碎片"到"长成一棵树"
传统 RAG 的文档处理流程，你闭着眼睛都能背出来：把 PDF 或网页读进来，按固定 token 数或者按段落切开，每块丢给 embedding 模型算一个向量，存进向量库。检索的时候把用户问题也转成向量，算余弦相似度，取 Top-K。这套流程的问题在于，切片这个动作本身就是有损的。你把一份有层级结构的文档（比如一份技术规范、一份财报、一份法律合同）硬生生切成 500 token 一块，块与块之间的逻辑关系就断了。模型拿到的是碎片，它只能靠碎片里的字面信息去猜上下文。
PageIndex 走的是另一条路。它不切碎，而是把文档解析成一棵有层级的树。你可以理解成：它先识别出文档的标题层级（一级标题、二级标题、三级标题），然后把每个章节的内容挂到对应的节点上，形成一个类似目录树的结构。每个节点保留自己的标题、正文摘要、以及它在整棵树里的位置路径。检索的时候，不是去比对向量，而是在这棵树上做导航——先定位到最相关的章节，再往下钻到具体的段落。
这个思路的关键在于：它保留了文档的原始结构信息。一份文档里，"第三章第二节讲的什么"这个信息，在向量切片方案里是丢失的，但在树索引里是天然存在的。这就是为什么它在处理结构化文档时，准确率能拉开差距。
2.2 树节点里到底存了什么
很多人以为树索引就是存了个目录，其实不是。一个设计良好的树节点，通常包含这么几层信息：
- 节点标题：这一节的标题原文，这是最强的语义锚点。
- 节点摘要：对这一节内容的浓缩，通常由大模型生成，用于快速判断相关性。
- 原始正文：这一节的完整内容，命中后直接喂给大模型。
- 路径信息：从根节点到当前节点的完整路径，比如"技术规范 > 数据安全 > 访问控制"。
- 子节点列表：它的下一级章节。
检索的时候，系统可以先用标题和摘要做粗筛，锁定几个候选分支，再往下逐层细化。这个过程很像人翻书——先看目录找到大概章节，再翻到那一页找具体段落。它模拟的是人的阅读导航行为，而不是机器的向量距离计算。
提示：树索引的效果高度依赖文档本身的结构质量。如果原始文档是一坨没有标题层级的纯文本，那树就退化成了链表，优势基本消失。这一点后面会专门讲。
2.3 为什么"无向量"反而可能是优势
向量检索有个绕不开的毛病：语义相似不等于答案正确。用户问"2023 年 Q3 的营收是多少"，向量检索可能召回一堆讲"营收""季度""财务"的段落，但就是没召回那个具体数字所在的表格。因为那个表格里的文字可能压根没出现"营收"这个词，它可能写的是"营业收入"或者干脆是个数字矩阵。
树索引在这种情况下靠的是结构定位 + 关键词锚定。它知道财务数据在"财务报表"这个分支下，直接钻进去找，命中率自然高。而且无向量意味着不需要维护 embedding 模型、不需要向量数据库、不需要担心向量维度爆炸，整个链路的工程复杂度大幅下降。对于中小团队来说，这是个很实际的诱惑。
当然，无向量也有它的死穴——它对付不了"语义漂移"严重的查询。用户用一个完全不同的说法问同一个问题，树索引如果只靠字面匹配，就可能找不到。所以现实中纯无向量的方案很少，通常是树索引为主、关键词或轻量语义为辅的混合策略。PageIndex 的 98.7% 大概率也是在这种混合配置下测出来的。
3. 98.7% 是在什么条件下测出来的
3.1 评测集的选择决定了数字的上限
任何准确率数字，第一件要问的事就是：在什么数据上测的。如果评测集是结构清晰、标题规范、问题指向明确的文档（比如技术手册、产品文档、学术论文），那树索引方案确实能打到很高的分数。因为这类文档天然适合树形解析，问题也往往是"某章节某概念是什么"这种可以直接定位的类型。
但如果评测集换成聊天记录、会议纪要、手写笔记这种结构混乱的文本，98.7% 基本不可能。树索引的准确率和文档的结构化程度是强正相关的。我自己的经验是：结构良好的文档，树索引能比向量检索高出 15 到 25 个百分点；结构混乱的文档，两者差不多，甚至树索引更差，因为它连树都建不起来。
所以看到 98.7% 这个数，你第一反应应该是：它测的是什么类型的文档、什么类型的问题。这两个变量一定，数字才有意义。
3.2 问题类型的分层
RAG 的问题大致可以分成几层，不同层级的难度天差地别：
| 问题类型 | 例子 | 树索引表现 | 向量检索表现 |
|---|---|---|---|
| 定位型 | "第三章讲了什么" | 极强 | 一般 |
| 事实型 | "X 参数的默认值是多少" | 强 | 中 |
| 推理型 | "根据 A 和 B 能推出什么" | 中 | 中 |
| 跨文档型 | "对比文档 A 和 B 的观点" | 弱 | 中 |
| 开放型 | "这份文档整体质量如何" | 弱 | 弱 |
98.7% 这种数字，通常是在定位型和事实型问题上测出来的。这两类问题占了企业知识库查询的大头，所以这个数字有实际参考价值，但它不代表推理型和跨文档型也能到这个水平。你在做技术选型的时候，一定要先搞清楚自己的业务问题主要落在哪一层。
3.3 大模型在其中的角色
树索引负责"找到正确的段落"，但最终答案是大模型生成的。所以 98.7% 这个数字里，有一部分功劳要归给大模型的阅读理解能力。如果检索到的段落是对的，但大模型读错了、答偏了，那准确率照样上不去。
这就引出一个很重要的实践点：树索引方案对检索精度的要求更高，因为它把更多压力转移给了大模型。向量检索召回一堆相关段落，大模型还能从里面挑；树索引如果定位错了分支，大模型拿到的就是完全无关的内容，神仙难救。所以树索引的调优重点，往往不在生成端，而在树的质量和导航策略上。
4. 自己动手搭一套树索引 RAG 的关键步骤
4.1 文档解析：先把结构抠出来
第一步是把文档变成结构化的树。这一步的难点在于不同格式的文档，解析难度完全不同。
- Markdown / HTML：最友好，标题层级天然存在，直接解析标签就行。
- Word / PDF（带样式）：可以通过样式信息（Heading 1/2/3）还原层级，但 PDF 的样式信息经常丢失，需要靠字号、加粗、缩进来猜。
- 扫描件 / 图片 PDF：得先做 OCR，OCR 出来的文本往往没有层级信息，需要靠规则或大模型来重建结构。
- 纯文本：最难，只能靠正则匹配"第X章""1.1""一、"这类模式来猜层级。
我自己的做法是：优先用文档自带的样式信息，样式缺失时用大模型辅助判断层级。具体来说，可以把文档的前若干段喂给大模型，让它输出一个层级结构建议，然后人工校验一遍。这一步看起来麻烦，但它是整个链路的地基，地基歪了后面全白搭。
# 一个简化的层级识别思路（伪代码） def build_tree(blocks): tree = [] stack = [(0, tree)] # (level, parent_list) for block in blocks: level = detect_level(block) # 靠样式或正则判断层级 node = {"title": block.text, "children": [], "content": ""} while stack and stack[-1][0] >= level: stack.pop() stack[-1][1].append(node) stack.append((level, node["children"])) return tree这段逻辑的核心是用栈来维护层级关系。遇到更高级别的标题就压栈，遇到同级或更低级别就弹栈。这是构建树结构最经典的写法，理解了这一层，后面就好办了。
4.2 节点摘要生成：给每个节点配一个"索引卡"
树建好之后，每个节点需要一份摘要。这份摘要的作用是在检索时快速判断这个节点相不相关，避免每次都把整节内容读一遍。
摘要生成有几个要点：
- 长度控制在 100 到 200 字，太短信息不够，太长检索时开销大。
- 必须包含该节的核心实体和关键概念，这些是检索时的匹配锚点。
- 保留层级上下文，比如"本节属于数据安全章节，主要讲访问控制"。
- 用大模型批量生成，但要抽样人工检查，因为大模型有时候会漏掉关键信息或者编造内容。
注意：摘要生成是一次性成本，但它的质量直接决定检索上限。我见过有人为了省 token 用规则截取前 200 字当摘要，结果检索效果惨不忍睹。这一步别省。
4.3 检索导航：怎么在树上找路
检索阶段是整个方案的核心。一个可用的导航策略通常分三步：
- 粗筛：用用户问题的关键词，在节点标题和摘要里做匹配，选出 Top-N 个候选节点。这一步可以用 BM25 或者简单的关键词命中率。
- 细化：对候选节点，如果它有子节点，继续往下钻，直到找到最细粒度的相关节点。
- 组装：把命中节点的正文按路径顺序拼起来，加上路径信息作为上下文，喂给大模型。
这里有个很关键的工程细节：导航深度要设上限。如果树很深，一路钻下去可能钻到很细的节点，反而丢失了上下文。我的经验是最多钻三层，且每层保留父节点的标题作为上下文。这样既保证了精度，又不丢全局信息。
def navigate(tree, query, max_depth=3): candidates = rank_by_keyword(tree, query) # 粗筛 results = [] for node in candidates: drill(node, query, results, depth=0, max_depth=max_depth) return assemble(results) def drill(node, query, results, depth, max_depth): if depth >= max_depth or not node["children"]: results.append(node) return best_child = pick_best_child(node["children"], query) if best_child: drill(best_child, query, results, depth + 1, max_depth) else: results.append(node)4.4 混合策略：什么时候该把向量加回来
纯树索引在遇到"用户换个说法问同一个问题"时会失灵。这时候加一层轻量语义匹配能明显改善。具体做法有两种：
- 节点级向量：只给节点摘要算向量，不给正文算。这样向量库很小，检索时先用向量粗筛，再用树导航细化。
- 查询改写：用大模型把用户问题改写成几个关键词变体，再拿这些变体去做树导航。
我个人更推荐第二种，因为它不引入向量库的运维成本，而且改写这一步本身对大模型来说很便宜。实测下来，查询改写能把树索引的召回率提升 10 到 15 个百分点，性价比很高。
5. 真实落地时最容易翻车的几个地方
5.1 文档结构比你想的烂得多
这是最普遍的问题。你在 demo 阶段用的是自己精心准备的 Markdown 文档，效果拔群。一上生产，用户传上来的是扫描件、是带水印的 PDF、是排版混乱的 Word，树根本建不起来。
我的应对策略是分级处理：
- 结构良好的文档，走完整树索引。
- 结构一般的文档，走"伪树"——用大模型重建层级，允许一定误差。
- 结构极差的文档，退回向量检索或者全文检索，别硬上树。
不要指望一套方案吃所有文档，这是不现实的。承认这一点，你的系统反而更稳。
5.2 标题党文档会骗过导航
有些文档的标题起得很泛，比如"概述""说明""其他"，这种标题在导航时几乎没有区分度。如果一份文档里全是这种标题，树索引的导航就会失效。
解决办法是在摘要生成阶段强制补充区分性信息。比如让大模型在摘要里明确写出"本节实际讲的是 XX 的具体配置方法"，把泛标题的语义补全。这一步能救回不少文档。
5.3 大模型的上下文窗口不是无限的
树索引命中一个节点后，如果这个节点内容很长，直接塞给大模型可能超窗口。这时候需要在节点内部再做一次切分，只把最相关的部分喂进去。
但这里有个矛盾：切分又会丢失上下文。我的做法是保留节点标题和前后各一段作为上下文，中间只取最相关的段落。这样既控制了长度，又保住了语义连贯性。
5.4 评测不能只看一个数字
98.7% 这种单一数字很容易误导人。真正靠谱的评测应该分维度：
| 评测维度 | 说明 | 目标 |
|---|---|---|
| 召回率 | 正确段落是否被找到 | > 90% |
| 精确率 | 找到的段落是否都相关 | > 85% |
| 答案正确率 | 最终答案是否正确 | 看业务 |
| 拒答率 | 不知道时是否老实说不知道 | 关键指标 |
| 响应延迟 | 端到端耗时 | 看场景 |
拒答率这个指标特别容易被忽略，但在企业场景里极其重要。一个 RAG 系统如果不知道答案却硬编一个，比直接说"没找到"危害大得多。树索引方案因为定位明确，其实更容易实现"找不到就拒答"，这是它的一个隐性优势。
6. 树索引和向量检索，到底该怎么选
6.1 一张决策表
| 你的情况 | 推荐方案 |
|---|---|
| 文档结构清晰、问题以定位型为主 | 树索引优先 |
| 文档结构混乱、问题开放 | 向量检索优先 |
| 两者都有 | 混合，树索引做粗定位，向量做兜底 |
| 团队没有向量库运维经验 | 树索引起步，成本低 |
| 需要处理多模态（图、表） | 向量 + 多模态模型，树索引辅助 |
| 对延迟极敏感 | 树索引（无向量计算，更快） |
6.2 我的实际选择
我自己做项目时，默认从树索引起步。原因是它的工程链路短、调试直观、出问题容易定位。向量检索虽然通用性强，但它的黑盒性质让调优变得很玄学——召回不准的时候，你很难说清是切片问题、embedding 问题还是距离度量问题。
树索引的好处是每一步都可解释：为什么这个节点被选中？因为它的标题命中了关键词。为什么那个节点没被选中？因为它的摘要里没有相关概念。这种可解释性在排查问题时价值巨大。
当然，当业务发展到一定规模，问题类型变复杂之后，加一层向量兜底是必然的。但那是后话，起步阶段别把自己搞太复杂。
7. 几个容易被忽略的实操细节
7.1 树的粒度要匹配问题粒度
树建得太粗，导航定位不准；建得太细，节点太多，检索开销大。我的经验是以"一个自然段或一个小节"为最细节点，再细就没必要了。因为再细的粒度，大模型自己也能从段落里挑出来。
7.2 路径信息要精简
路径信息作为上下文喂给大模型时，不要给完整路径，给最近的两三级就够了。完整路径又长又占 token，而且深层路径对当前问题的帮助有限。
7.3 定期重建树
文档更新后，树需要重建。不要做增量更新，因为层级结构可能变化，增量更新容易把树搞乱。全量重建虽然成本高，但胜在稳定。如果文档量大，可以按文档分片重建，避免一次性压力过大。
7.4 给导航加个"兜底分支"
在树的根节点下，可以挂一个"未分类内容"分支，把所有解析不出层级的内容都塞进去。这样即使结构解析失败，内容也不会丢，检索时还能靠关键词命中。这是个很实用的保险措施。
8. 关于 98.7% 的最后几句实话
这个数字我信，但它是有条件的信。在结构良好的文档上、在定位型和事实型问题上、在检索和生成都调优到位的前提下，树索引方案确实能打到这个水平。但如果你拿它去测聊天记录、测跨文档推理、测开放型问题，数字会掉得很厉害。
我写这篇东西的目的，不是让你去追这个数字，而是让你理解这个数字背后的机制和边界。RAG 这个领域现在很卷，各种新框架、新名词层出不穷，但底层的东西没怎么变：把对的内容找出来，喂给对的模型，让它生成对的答案。树索引只是"找内容"这件事的一种更贴近文档本质的做法。
如果你正在做 RAG 项目，我的建议是：先用树索引把链路跑通，把文档解析和导航这两块打磨好，再根据实际badcase决定要不要加向量。别一上来就堆技术栈，那样你连问题出在哪都找不到。踩过几次坑之后你会发现，最朴素的方案往往最稳，而 98.7% 这种数字，看看就好，真正重要的是你自己的业务数据上跑出来是多少。
