PageIndex源码实测：所谓Vectorless RAG，核心不是“去向量”，而是“先结构后检索”

先说结论：PageIndex 不是“无成本RAG捷径”。
它做的是把传统“切块+向量召回”的前置步骤，换成“目录树抽取+页码对齐+推理式定位”。

关键词就八个字：结构优先，推理检索。

……

一、从源码看，它不是一句口号

我按主链路看了 page_index.py / page_index_md.py / utils.py，流程大致是：

1. 文档解析（PDF/MD）  
2. 目录检测（有TOC和无TOC两条路径）  
3. 结构树生成（章节节点、范围、摘要）  
4. 页码与 physical index 对齐  
5. verify_toc 做抽样校验  
6. 发现偏差后进入重试修复（例如 fix_incorrect_toc_with_retries）

这不是“绕过工程”，恰恰是另一套更重的工程。

二、它为什么在长文档上有优势

传统向量召回在专业长文档里常见痛点是：

• • 语义相似但问题不相关
• • 溯源解释弱（为什么召回这段）
• • 多章节推理容易断链

PageIndex 的打法是先建立章节树，再在树上做定位。

好处是：

• • 引用更可追踪（章节/页码）
• • 检索路径更可解释
• • 对财报、制度、技术手册这类“结构化长文档”更友好

三、代价同样很真实

别被“no vector DB”误导成“更便宜更快”。

它的成本转移到了：

• • 结构抽取和纠错的 token 消耗
• • 多轮校验带来的时延
• • 对模型稳定性的依赖

所以更准确的说法是：
去掉了向量库运维成本，但增加了结构推理成本。

四、到底什么时候该用

适合：

• • 报告/白皮书/法务文本/审计文档
• • 对可解释检索和可追溯引用有硬要求

不适合：

• • 噪声极高、结构很烂的碎片语料
• • 对毫秒级延迟极敏感的在线接口

一句话：如果你的痛点是“召回不准且没法解释”，PageIndex 这路子值得上；如果你只追求最低时延，它不一定是答案。

快问快答

Q：这是不是向量RAG的替代者？
A：更像补充路线，不是一刀切替代。

Q：会不会成为主流？
A：在高价值长文档场景，概率很高；在通用低成本场景，未必。

Q：落地第一步做什么？
A：先拿你们最痛的3份长文档做AB测试：准确率、可解释性、时延、成本四项一起看。