一份三百页年报里，问题问的是“公司为什么提高库存减值准备”。向量检索返回了十段都含有“库存”和“减值”的文字：会计政策、风险提示、历史数据、附注定义。它们语义相似，却没有一段真正回答“为什么提高”。
这类失败不是 topK 调得不够大，而是检索目标错了。相似度擅长寻找“像这句话的内容”，专业文档问答需要寻找“能支撑这个结论的证据”。
PageIndex 抓住的正是这条缝隙。它最值得关注的地方，不是“无向量”这个标签，而是把检索路径从一次近邻搜索改成沿文档结构逐层判断。
它把文档先变成一张可阅读的地图
PageIndex 的公开实现先为 PDF 或 Markdown 构建层级树。节点包含标题、起止页或索引、摘要和子节点，形态接近目录，但信息是为模型检索准备的。
查询到来后，Agent 不必立即扫描所有段落，而是先判断哪些顶层章节可能相关，再进入子节点，最后读取候选页面或自然段落。简化后是两步：
text文档 -> 语义目录树 问题 -> 树上推理 -> 候选章节 -> 原文证据
这与固定长度切块、计算 embedding、向量 topK 的典型 RAG 链路不同。结构先缩小搜索空间，模型再利用问题、对话历史和领域线索作判断。
“No Chunking” 应该怎样理解
项目把 “No Vector DB, No Chunking” 写在首页。这里的 no chunking 更准确地说，是不把文档预先切成一批彼此独立、固定长度的检索块。
系统仍然需要节点边界、页码范围和候选章节，否则无法定位原文。区别在于这些边界尽量服从文档的自然结构，而不是让每 500 个 token 都成为一个失去上下文的孤岛。
因此，PageIndex 不是取消分段，而是把“分段”从机械预处理提升为结构建模。这个差异比宣传口号更重要。
它可能在哪些问题上胜出
树式检索最适合同时具备三个条件的材料。
第一，文档有稳定层级。财报、法规、产品手册、教材和技术规范本来就按章节组织，目录本身携带大量先验。
第二，问题需要上下文判断。比如“某项政策何时适用”通常要同时读取定义、适用范围和例外条款，单句相似不等于答案完整。
第三，结果需要追溯。树节点保留标题和页码，系统更容易说明走过哪些章节、证据落在哪里。
如果数据是短 FAQ、松散消息流或大量彼此独立的知识点，树结构的价值会下降。高并发、低延迟场景也未必愿意为多轮 LLM 判断支付成本。
真正的上限在索引，而不在检索器
树是一张地图，地图画错了，推理越认真越可能走进错误章节。落地时至少要检查：
- 标题层级是否正确恢复；
- 表格、脚注和跨页段落是否被完整保留；
- 节点摘要有没有遗漏限定条件；
- 文档更新后，节点 ID 与引用是否仍然稳定。
项目 README 也明确区分了开源自托管与云服务：开源包使用标准 PDF 解析，复杂版面则由项目方的云端 OCR 和建树管线提供更强处理。评估时不能把云服务 demo 的结果直接当成开源版本的能力。
Benchmark 先看归属，再看数字
PageIndex 项目方报告其系统在 FinanceBench 上达到 98.7% 准确率。这个数字值得作为试验线索，但它来自项目方维护的结果与文章，不应自动视为独立复现。
在自己的业务里，更有价值的评估不是只看最终答案是否“像对的”，而是分层测量：
- 正确证据是否进入候选节点；
- 引用页码与原文是否一致；
- 多跳问题是否覆盖全部必要章节；
- 单次查询的模型调用、token 与尾延迟是多少；
- 索引失败和检索失败分别占多少。
把“答案准确率”拆开，才能知道系统是读错地图、走错路径，还是拿到证据后生成错了。
不必把它和向量检索对立
在大规模语料库里，先找文档、再找章节通常比让一个 Agent 从数百万文件开始推理更现实。一个可行的混合架构是：
text元数据 / 向量检索 -> 候选文档 PageIndex 树检索 -> 候选章节 生成与校验 -> 带页码的答案
向量检索负责便宜的粗召回，树检索负责结构化深挖。是否需要两层，取决于文档数量、查询复杂度和延迟预算，而不是技术立场。
我的判断
PageIndex 的价值不在于证明向量数据库过时，而在于提醒 RAG 团队：长文档不是一堆无序 chunk。章节、页码、标题和引用关系本身就是检索信号。
如果问题需要跨章节推理和可追溯证据，先让模型看见文档地图，再决定读哪里，确实更接近专家的工作方式。但这条路线把成本和风险从向量召回转移到了建树质量与推理路径上。它值得评估，不值得神化。