AI

PageIndex：不用向量資料庫的 RAG，讓 LLM 像翻目錄一樣「推理」找到答案

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

傳統 RAG 的流程大家都很熟：把文件切成小塊、轉成向量、存進向量資料庫，查詢時找出「語意最相近」的幾塊交給 LLM。問題是，相似不等於相關——在一份兩百頁的年報裡問「去年的營業利益率是多少」，向量檢索可能找到十段都提到「營業利益」的文字，卻漏掉真正有答案的那張表。PageIndex（VectifyAI/PageIndex）的做法是完全拿掉向量：先替文件建立一個像目錄一樣的樹狀索引，再讓 LLM 像人一樣「翻目錄、找章節、讀那一頁」。專案目前約 39.9k stars，出現在 10 月 26 日的 AI 開源趨勢報告中。

1. 專案背景與定位

PageIndex 由 VectifyAI 開發，MIT 授權，以 Python 套件 pageindex 發佈，官方描述是「為無向量、基於推理的 RAG 而設計的文件索引」。README 說它的靈感來自 AlphaGo：與其靠一次相似度比對，不如讓模型在結構化的搜尋空間中逐步推理。

它鎖定的是長篇專業文件：財務報告、法律文件、法規申報、技術手冊、醫學文獻與教科書——也就是傳統切塊式 RAG 最容易出錯的場景。

2. 技術架構與核心設計

  • 兩步驟流程：
    1. 為每份文件產生階層式的樹狀索引（類似一份詳細的目錄）
    2. 由 LLM 以 agentic 的方式推理搜尋這棵樹，決定要深入哪個章節
  • 可追溯：答案可以對應到明確的章節與頁面，而不是一堆相似度分數。
  • 模型分工：index= 用來建立索引（基本模型即可），chat= 用來推理回答（官方建議用預算內最強的模型）；也支援透過 Claude 訂閱使用（pageindex[claude]）。
  • 本機與雲端兩種模式：
    • 本機模式：處理文字型 PDF，預設使用快速建樹的 PageIndex Flash
    • 雲端模式（index="cloud"）：加上 OCR、圖片理解、區塊級引用、資料夾與 metadata、MCP Server，以及可跨整個文件庫推理的 PageIndex File System
  • Agent 整合：提供 OpenAI Agents SDK 與 Claude Agent SDK 的整合文件。
  • 10 月新功能：Page Search API 宣稱約一秒內找到含答案的頁面，並可大幅降低文件問答的 token 成本。

3. 社群熱度與生態採用

約 39.9k stars、3.4k forks、558 commits。README 公布的數據：

  • FinanceBench：PageIndex 98.7% 準確率，對照圖中的向量 RAG 為 50%
  • 建索引成本：本機模式約每頁 0.001 美元，1,000 頁教科書約一美元多；建索引時間約 13 秒到 4.5 分鐘（9 到 1,098 頁）
  • 自建財務問答基準：19 個 LLM、34 種設定、100 題、8 家公司的 40 份 10-K 年報
  • 與直接把 PDF 丟給模型相比：52 頁時查詢成本約高 2.1 倍、420 頁時約高 16.6 倍；到了 805 頁，文件已超過 context window——這組數據說明了 PageIndex 的取捨。

4. 局限性與潛在風險

  • Benchmark 需謹慎解讀：98.7% 是官方自行公布的結果，對照組「向量 RAG」的實作細節會大幅影響差距；建議用自己的文件與問題重新驗證。
  • 查詢成本與延遲：每次查詢都要讓 LLM 逐層推理，比向量檢索更慢、更貴；官方數據也顯示在中等長度文件上，查詢成本可能高於直接把 PDF 放進 context。
  • 本機模式功能有限：只處理文字型 PDF；掃描檔、圖片多的文件、區塊級引用與 MCP Server 都需要雲端模式。
  • 雲端模式的資料外流：財報、合約、醫療文件這類敏感資料上傳到雲端前，必須確認資料處理與保留政策；官方另有專屬 VPC 或地端部署選項。
  • 適用範圍：樹狀索引適合結構清楚的長文件；對大量短文件、聊天紀錄、或結構鬆散的內容，傳統向量檢索可能仍更合適。
  • 品質取決於模型：推理品質直接受 chat= 模型影響，弱模型可能走錯分支、漏掉答案。

5. 應用價值與適用場景

最適合「答案藏在長文件特定位置、而且必須可追溯」的工作：財務分析師查年報數據、法務比對合約條款、法遵人員查詢法規、工程師在數百頁的技術手冊中找規格。這些場景對準確度與出處的要求，遠高於對回應速度的要求。

也可以和向量 RAG 混合使用：用向量檢索先挑出可能相關的文件，再用 PageIndex 在單一長文件內精準定位。

Monday 的觀點與架構建議

  • PageIndex 代表 RAG 的一個重要轉向：從「相似度檢索」到「推理式導航」。這和月初介紹的 Graphify（用結構化圖譜取代向量）是同一股趨勢——當模型的推理能力夠強，結構化的索引往往比向量更可靠。
  • 導入前建議做一次小型 A/B：用自家的 20–50 個真實問題，比較向量 RAG、PageIndex、以及直接放入長 context 三種做法的準確率、成本與延遲。
  • 處理機密文件時，優先使用本機模式或地端部署；若必須用雲端，確認資料保留期限與存取控管。
  • 長期來看，「文件該怎麼被 AI 讀」正在變成一個獨立的基礎設施問題。索引的形式會越來越接近人類閱讀文件的方式：先看目錄、再翻章節、最後讀細節。

參考來源