大多數 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 是一種形態；向量是另一種。