大多数 RAG pipeline 看起来都一样：把文档切块，给每个 chunk 算 embedding，存向量，查询时给问题算 embedding，然后取 top-k 最相似的 chunk。PageIndex 做的事不一样。它不用向量，而是构建一个镜像文档目录的分层树索引——每个节点有标题、摘要和指向完整章节文本的指针。检索不是相似度搜索，而是 LLM 读这棵树并推理该往哪些节点下钻，然后只去匹配的节点拿完整文本。
架构上的赌注是：一旦查询变复杂，"相似度是相关性的弱代理"。如果你问财报"作者为什么选择 self-attention 而不是 recurrence，复杂度权衡是什么"，向量搜索得找出 embedding 看起来像这个问题的 chunk——这完全可能漏掉跨章节的推理。PageIndex 的例子在原始 Transformer 论文上演示：LLM 看树，识别出动机章节和复杂度分析章节都相关，把两个都取出来，把答案锚定在正确的位置。这种多章节综合，正是向量 RAG 静悄悄失败的地方，用户却以为得到了一个自信的正确答案。
诚实的权衡是成本和结构。每轮检索都要 LLM 读树摘要并推理打开哪些节点——这是每查询多一个 LLM 调用，叠加在生成调用之上。向量搜索一旦索引建好，每查询基本免费；PageIndex 把检索本身变成模型调用。如果你的文档是从网上扒下来的没有清晰层次的扁平 PDF，树帮不上忙。如果你的查询是简单查找（"保修期是多少"），推理开销就是浪费。PageIndex 这篇文章没有给出在 FinanceBench 上对比向量 baseline 的具体数字，没讨论延迟或索引怎么处理文档更新，也没比较每查询成本。这些是任何认真评估都需要的问题。
对于在长结构化文档上工作的开发者——财报、法律合同、研究论文、技术手册——PageIndex 值得对你现有的向量 setup 做一次真正的对比测试。可解释性本身就有价值：当检索失败时，你能看到挑错节点的推理链，而不是盯着不透明的余弦分数。对于其他所有做 chatbot-over-help-docs 的人来说，现有的 embedding stack 可能仍然是正确答案。这里真正有趣的前沿不是把"向量对推理"当宗教战争来打，而是搞清楚什么样的文档形态和查询模式适配什么架构。PageIndex 是一种形态；向量是另一种。