向量不再是唯一答案：Tree‑Based RAG 讓長文件檢索更精準
欸，你有看到那個叫 PageIndex 的新玩意兒嗎？它用樹狀推理取代向量搜尋，讓長文件檢索更精準且可解釋。
有看到那個叫 PageIndex 的新玩意兒嗎？
最近在 Slack 裡偶然看到同事貼出 VectifyAI/PageIndex 的 repo，說它用「樹狀推理」取代向量搜尋，直接把長 PDF 當成一本書翻。我的第一反應是：哇，這樣真的能解決金融報告、法律條款那種千頁巨檔的痛點嗎？
為什麼傳統向量 RAG 在長文件上會掉分
向量檢索的核心是把整篇文件切成 chunk、embed 進向量 DB，然後靠相似度找最接近的片段。這套流程在短問答或 FAQ 裡跑得不錯，但一旦碰到 200 頁的年報，切塊的邊界常會把關鍵上下文割裂。結果是模型會抓到看起來相似的句子，卻找不到真正的條款位置，準確率直接「掉」到 70% 以下。
我在實驗中也遇過：把一段關於「資產減值」的條款丟給向量 RAG，回覆卻只給了「減值測試」的那段說明，根本沒有指向正確頁碼。
Tree‑Based RAG 的運作方式
PageIndex 的做法是先讓 LLM 把文件轉成階層樹狀索引，像是自動生成的目錄，每個節點帶有標題、頁碼範圍，甚至簡短摘要。查詢時不再是「哪個向量最近」，而是讓模型從根節點開始，一層層判斷哪條分支可能相關，逐步深入到最終頁面。
這樣的好處有兩點：
- 保留文件結構：模型能『看到』章節層級，避免跨章節的語意斷裂。
- 可解釋性提升：每一步推理路徑都可以記錄，之後檢查時能說『我為什麼先選了第 3 章』。
根據 當RAG告別向量資料庫的報導，在 FinanceBench 基準上，這套系統跑出 98.7% 的正確率，遠超過大多數向量方案。
實際使用感受與限制
我親自跑過一次 demo：先 pip install pageindex，放入一份 150 頁的財報 PDF，給它一個 OpenAI API key，然後用 query("公司2022年營業收入變化原因")。結果不只給出正確段落，還回傳了『從第 1 章 → 第 4 章 → 第 12 節』的推理路徑。
缺點也很明顯：
- 目前只能呼叫 OpenAI（或兼容的 API），離線模型支援還沒落實。
- 每一次查詢都要消耗較多 token，算是「推理成本」的另一種形態。
- 樹的建構需要一次性讀完整文件，對超大檔案的記憶體需求不小。
不過，對於不想再維護向量 DB、或是對可解釋性有硬性需求的團隊來說，這樣的 trade‑off 還是值得玩。
未來的 RAG 版圖會怎樣？
從我看到的趨勢來看，向量、樹、知識圖、甚至純 Agent 記憶體都在同台競技。像 PageIndex：無向量、推理驅動的RAG框架深度解析 這篇文章提到，樹狀結構其實是把「人類翻書」的行為抽象化，對於醫療、金融這類需要逐層剖析的領域特別有用。
如果未來 LLM 能直接在本地跑推理樹，或是把樹的建構交給更小的專用模型（例如 LLaMA 7B），我們可能會看到「向量+樹」的混合方案，兼顧速度與解釋性。
你有沒有在長文件上被傳統 RAG 卡住過？不妨試試這個 vectorless 的方式，或許會有意想不到的驚喜。
延伸閱讀
結論：向量不再是唯一的選項，樹狀推理讓長文件檢索變得像有人在旁邊指路。
