VectifyAI 開源的 PageIndex 在 2026 年 10 月 22 日累積三萬九千餘顆星標，主要語言為 Python，採 MIT 授權。它對檢索增強生成提出另一條路線：不建向量索引、不切分區塊，而是為每份文件生成階層樹，讓模型沿樹枝推理，找出應讀章節。
PageIndex 是什麼？
PageIndex 是 VectifyAI 開源的檢索框架，以階層樹狀索引取代向量資料庫，讓模型沿目錄推理定位章節，並提供本地與雲端兩種模式。
專案的自我定位寫得相當直接：一套「無向量、以推理為本」的檢索框架，不依賴向量資料庫，不做固定長度切塊，檢索結果可追溯至明確章節。這三個特徵構成它與主流方案的差異邊界。
開發團隊為 VectifyAI，儲存庫建立於 2025 年 4 月，官方網站為 pageindex.ai。專案在 2025 年 9 月發表技術文章，並以 Mafin2.5 之名在金融文件問答基準測試中提交成績；同一團隊亦公開 Mafin2.5-FinanceBench 的完整評估資料。這種把評估過程一併開源的做法，讓外部研究者可以複核數字，而不是只接受宣傳頁上的結論。
目標受眾相當明確：手上有一批長篇專業文件的團隊，例如財務報告、法律合約、監管申報、技術手冊、醫學文獻與教科書。這些文件的共同點是結構嚴謹、章節分明，但單份長度往往超出模型一次可讀的範圍。
PageIndex 為何捨棄向量資料庫？
向量檢索按語意相似度排序，但相似不等於相關。專業文件需要依上下文與領域知識判斷，PageIndex 改用推理替代相似度，避免取回語意接近卻答不上問題的段落。
專案文件把問題講得很清楚：向量式檢索以語意相似度作為排序依據，而檢索真正需要的是相關性，相關性則需要推理。在需要上下文理解、領域專業與多步推斷的專業文件上，相似度搜尋會漏掉那些相關但不相似的段落，同時取回一堆相似卻無用的段落。
這個批評並非空泛。固定長度切塊會切斷表格、註腳與跨頁論證；嵌入模型只保留語意向量，丟棄章節層級與位置資訊；top-k 取回之後，模型拿到的是一堆彼此無關的片段，只能憑片段拼湊答案。當問題涉及「第三季毛利率相對前一年同期變化」這類需要跨章節比對的查詢，片段化檢索的失敗率明顯上升。
PageIndex 的替代方案是把文件的結構保留下來。它假設長篇專業文件本身已有目錄與層級，這層人為結構正是人類專家檢索時使用的路徑；與其用向量壓縮掉結構，不如把結構顯式化，讓模型的推理沿著它走。
PageIndex 的樹狀索引如何運作？
流程分兩段：先為每份文件生成階層樹狀索引，節點對應章節與頁碼；檢索時模型在樹上逐步推理，選定分支後才讀取內容，因此結果可追溯至具體章節。
第一階段是索引。系統從文件版面抽取標題層級、段落歸屬與頁碼對應，建立樹狀結構；官方強調這一步主要依賴版面解析而非語言模型，索引模型只負責摘要與修飾節點描述。這解釋了為何索引階段可以用較便宜的模型而不明顯損害品質。
第二階段是檢索。使用者提出問題後，模型不是搜尋向量空間，而是在樹上做選擇：先判斷哪個章節標題與問題相關，進入該分支後再判斷子章節，直到抵達足以回答問題的葉節點，然後讀取原文作答。官方把這個過程類比為 AlphaGo 在搜尋樹上權衡路徑，只展開值得展開的分支。
由於每次只讀取推理實際走過的路徑，上下文用量不隨文件長度線性增長。這也是後續成本比較能夠成立的技術前提：索引建立一次可重複使用，每次提問只支付走過那條路徑的費用。
2026 年 8 月加入的 PageIndex Flash 進一步壓縮索引時間，並成為 SDK 本地模式下處理文字型 PDF 的預設方法。同一時期推出的檔案系統層，則把單文件樹擴展為語料層級的樹，讓檢索可以在整個文件庫上推理，而非局限於單一檔案。
PageIndex 的檢索成本與準確度表現如何？
官方在 FinanceBench 錄得 98.7% 準確率。本地索引成本約每頁 0.001 美元；420 頁文件的單次提問，比原生 PDF 輸入便宜十六點六倍。
索引成本的量測涵蓋 9 頁至 1,098 頁共九份 PDF。以 gpt-5.6-luna 建立索引，平均每頁約 0.001 美元，偏離參考線的幅度主要來自文字密度而非文件長度；索引耗時由約 13 秒至 4.5 分鐘，與頁數呈可預測的增長關係。對一本千頁教科書而言，一次性投入略高於一美元與數分鐘，之後每次提問都重用同一棵樹。
檢索成本的比較基準是「把整份 PDF 直接交給模型」。在兩條路線得出相同答案的文件上，原生 PDF 輸入在 52 頁時貴 2.1 倍，85 頁貴 3.4 倍，198 頁貴 7.8 倍，420 頁貴 16.6 倍；到 805 頁，文件本身已超出模型的上下文窗口，比較無從成立。這個數列清楚說明優勢來源：PageIndex 的成本取決於推理路徑長度，而非文件總長度。
準確度方面，專案在 FinanceBench 取得 98.7% 的成績，並把向量式 RAG 的約 50% 並列對照。另一組公開測試 PageIndex-OSS-Benchmark 使用 62 條查找型問題、34 份 PDF 共 1,945 頁，題目答案均為正文直接陳述的事實，因此答錯可歸因於檢索或閱讀失敗，而非推理能力不足。這種刻意限制題型的設計，讓測試指向框架本身而非模型能力。
如何快速開始使用 PageIndex？
安裝 pageindex 套件後，以客戶端指定索引與對話模型，提交文件取得編號即可提問。持有 Claude 訂閱者可加 claude-code 前綴免 API 金鑰。
本地模式的入門路徑只有三個步驟：安裝套件、建立客戶端、提交文件。官方範例以 gpt-6-luna 建立樹狀索引，以 gpt-6-sol 負責檢索與作答，提交後取得文件編號，之後每次提問都帶上該編號。
import os
from pageindex import PageIndexClient
os.environ["OPENAI_API_KEY"] = "your-openai-key"
client = PageIndexClient(
index="gpt-6-luna",
chat="gpt-6-sol",
)
doc_id = client.submit_document("report.pdf")["doc_id"]
answer = client.chat("What was the 2023 operating margin?", doc_id=doc_id)
print(answer)
模型選擇的策略值得注意。官方建議索引階段用基本模型即可，因為樹狀結構來自版面解析，索引模型只做摘要修飾；對話階段則應該用能力範圍內最好的模型，因為檢索決策的品質直接決定答案品質。這種不對稱配置，讓整體成本壓在索引便宜、提問精準的組合上。
另一個差異化設計是訂閱整合。持有 Claude 訂閱的使用者可安裝 pageindex[claude] 擴充，並在模型名稱前加 claude-code 前綴，例如以 claude-code/haiku 建立索引、以 claude-code/opus 檢索，用量計入既有方案而不需另外申請 API 金鑰。對於已經為訂閱付費的個人開發者，這條路徑把試驗成本降到接近零。
雲端模式則把索引與儲存搬到 PageIndex 的服務端，處理掃描檔與圖文混排文件，並提供區塊級引用、中繼資料、資料夾與 MCP 伺服器。切換方式僅是把索引參數改為 cloud 並設定服務金鑰，檢索層仍可沿用使用者原本的模型供應商。這種分離設計讓團隊可以只把重活外包，同時保留對答案生成的控制權。
PageIndex 與向量式 RAG 有何分別？
兩者在索引、檢索與可追溯性三個層面不同：向量式建立向量索引並以相似度搜尋，結果不透明；PageIndex 建立樹狀索引並以模型推理檢索，可回溯至明確章節與頁碼。
索引層的差別最根本。向量式方案把文件切塊後轉為嵌入向量，原始結構在轉換中流失；PageIndex 保留章節層級，節點本身承載語意標籤與位置資訊。前者是壓縮，後者是提綱。
檢索層的差別在決策方式。相似度搜尋是一次性排序，檢索過程沒有中間判斷；樹上推理則是多步決策，每一步都可以根據已讀內容調整方向。官方把後者的輸出形容為可追溯至明確引用，因為模型必須指出它選擇了哪個節點，而非只回傳一串相似度分數。
上下文層的差別體現在個人化程度。向量檢索的輸入基本上只有查詢向量，對話歷史與領域知識難以介入排序；樹上推理則可以把對話脈絡、使用者背景與領域假設一併納入判斷，這也是官方所稱「完整上下文」的含義。
值得注意的是，兩條路線並非互斥。實務上常見的折衷，是以關鍵詞或向量先做粗篩，再用樹狀推理做精讀；PageIndex 的節點描述本身也可作為嵌入對象。專案文件並未主張全面取代向量資料庫，而是主張在長篇專業文件這一類場景，推理式檢索的邊際效益更高。
PageIndex 有哪些實際應用場景？
適用於財務報告、法律文件、監管申報、技術手冊、醫學文獻與學術教科書等長篇專業文件，特別是問題需要跨章節比對、且答案必須附上明確出處的場合。
財務分析是最直接對應的場景。年報與季報的關鍵數字散布在管理層討論、附註與財務報表之間，單一問題往往需要跨三個章節才能回答；FinanceBench 的成績正是針對這類查詢。對需要標示數據來源的分析工作，可追溯的引用比答案本身更重要。
法律與合規領域的需求類似，但更重視引用精度。合約審閱要回答的是「這條條款在哪些文件出現過、上下文如何」，樹狀索引的節點與頁碼對應，讓每一次引用都可以回到原文核對。監管申報的解讀亦同，條文之間的層級關係本身就是答案的一部分。
技術手冊與醫學文獻則受益於結構穩定。手冊通常有清楚的章節與索引，醫學文獻有固定的摘要、方法、結果分段，兩者都適合直接轉為樹狀結構。學術教科書的優勢在於一次性索引成本可被長期分攤，一本千頁教材索引成本約一美元，之後所有提問共用。
至於聊天型應用，專案的定位較為保守。它解決的是「在長文件中找到正確段落」的問題，而非「與文件對話」的體驗設計；後者需要額外的對話管理與答案組裝層，官方把這部分留給 SDK 與整合方處理。
PageIndex 有哪些限制？
本地模式僅支援文字型 PDF，掃描檔需改用雲端；檢索品質高度依賴對話模型能力，弱模型會在樹上走錯分支；專案貢獻者僅十六人，長期維護與企業級支援仍需觀察。
第一項限制是輸入格式。本地模式處理文字型 PDF，掃描檔、圖表密集文件與 Office 格式需交由雲端模式，才能取得 OCR 與圖像理解能力。引用粒度亦有差異：本地為頁級，雲端為區塊級。
第二項限制是模型依賴。索引階段可以用便宜模型，但檢索階段的能力直接影響路徑選擇；官方在基準測試中把不同模型畫成近乎垂直的推理強度階梯，跨越一個模型等級就換來一個數量級的成本變化。對預算受限的團隊，這意味著要在準確度與每次提問成本之間明確取捨。
第三項是專案治理。儲存庫目前有 151 個待處理議題與十六位貢獻者，核心團隊規模小，商業模式依賴雲端服務與企業部署。MIT 授權讓程式碼可以自由使用與分支，但授權並不包含支援承諾；把這套框架放進生產流程的團隊，需要自行承擔版本跟進與問題修補的工作。
出處連結有哪些？
本文資料來源為 VectifyAI 的 PageIndex 儲存庫、官方文件與技術文章，以及團隊公開的 FinanceBench 評估資料。
- GitHub 儲存庫：https://github.com/VectifyAI/PageIndex
- 官方網站：https://pageindex.ai
- 開發者文件：https://docs.pageindex.ai
- FinanceBench 評估：https://github.com/VectifyAI/Mafin2.5-FinanceBench
- OSS 基準測試：https://github.com/VectifyAI/PageIndex-OSS-Benchmark
總結：PageIndex 適合什麼團隊？
適合手上有大量長篇專業文件、需要可追溯引用的團隊，例如財務分析、法務合規與技術文件管理。若文件以掃描檔為主或需要企業級支援，則應先評估雲端方案與維護成本。
PageIndex 的價值不在於否定向量資料庫，而在於指出一個長期被忽略的維度：檢索的本質是判斷相關，而非計算相似。當文件長度增長到數百頁，切塊與嵌入所流失的結構資訊，會成為答案品質的天花板；把結構保留為樹，並讓模型在樹上推理，是一條成本可控的替代路徑。
三萬九千餘顆星標與穩定的每兩週版本節奏，說明這條路線已獲得開發者社群認可。2026 年 10 月 19 日發布的 0.4.4 版把「比向量索引便宜」與「可用 Claude 訂閱執行」寫進版本說明，等於把成本與門檻兩個障礙同時處理。
真正需要評估的是適用邊界。若檢索對象是新聞、論壇或短篇網頁，向量方案成熟且生態完整；若對象是動輒數百頁的專業文件，且答案必須附上可核對的出處，樹狀推理的優勢才成立。對正在為長文件問答苦惱的團隊，這個專案值得排進評估清單。
