VectifyAI/PageIndex 是一個很有意思的 RAG 專案。它不從「再建一個向量庫」開始，而是把長文件先整理成類似目錄的樹狀結構，再讓 LLM 沿著這棵樹做推理式檢索。

專案地址：VectifyAI/PageIndex

截至本文整理時，GitHub 頁面顯示專案約有 31.8k stars、2.7k forks，授權為 MIT。README 給它的定位是：Vectorless, Reasoning-based RAG，也就是無向量庫、基於推理的 RAG。

它想解決什麼問題

傳統 RAG 的常見路徑是：切塊、向量化、寫入向量資料庫，再用相似度搜尋召回片段。這套方法簡單、通用，也很成熟，但在長篇專業文件裡容易遇到幾個問題：

• 相似度不等於真正相關。
• 文件結構被切塊打散，章節關係丟失。
• 召回結果可解釋性弱，很難說明為什麼命中這一段。
• 對財報、監管文件、法律文書、技術手冊這類材料，問題往往需要跨章節推理。

PageIndex 的思路是反過來：先把文件組織成語義樹，再讓模型像人類讀目錄、翻章節、逐層定位一樣查找相關內容。

PageIndex 的基本工作流

README 裡把 PageIndex 的檢索分成兩步：

1. 為文件生成類似 Table-of-Contents 的樹狀結構索引。
2. 透過樹搜尋做 reasoning-based retrieval。

這棵樹不是簡單的檔案目錄，而是面向 LLM 使用的文件結構。節點裡會有標題、頁碼範圍、摘要、子節點等資訊。這樣模型在回答問題時，不必一開始就面對大量零散 chunk，而是可以先判斷應該進入哪個章節，再繼續向下搜尋。

這種方式更適合結構清晰但內容很長的文件，例如：

• 金融報告和 SEC filings。
• 監管材料和合規文件。
• 學術教材和論文。
• 法律文件。
• 技術手冊和產品文件。
• 超過模型上下文視窗的大型 PDF。

和傳統向量 RAG 的差異

PageIndex 的主要賣點可以概括成五點。

第一，不需要 Vector DB。它依賴文件結構和 LLM 推理來定位內容，而不是只做向量相似度搜尋。

第二，不做傳統 chunking。文件會按自然章節組織，而不是被切成固定長度片段。

第三，可解釋性更強。檢索路徑可以對應到頁碼、章節和樹節點，比「向量相似度命中某段文字」更容易追蹤。

第四，檢索是上下文感知的。問題、對話歷史、領域背景都可以影響樹搜尋路徑。

第五，更接近人類專家讀文件的方式。人通常不是把整份文件切成小塊再算相似度，而是先看目錄，再定位章節，最後讀細節。

這並不意味著向量庫沒有價值。更準確的說法是：PageIndex 適合那些「語義相似不夠，需要結構和推理參與」的長文件場景。

本地怎麼跑

README 提供了本地自託管方式。先安裝依賴：

1

pip3 install --upgrade -r requirements.txt

然後在專案根目錄建立 .env，寫入 LLM API key。專案透過 LiteLLM 支援多模型：

1

OPENAI_API_KEY=your_openai_key_here

對 PDF 生成 PageIndex 結構：

1

python3 run_pageindex.py --pdf_path /path/to/your/document.pdf

也可以處理 Markdown：

1

python3 run_pageindex.py --md_path /path/to/your/document.md

常見可選參數包括：

1
2
3
4
5
6
7

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

README 裡也提醒，本地開源版本使用標準 PDF 解析。如果是複雜 PDF，專案方的雲服務會提供增強 OCR、樹構建和檢索流程。

Agentic Vectorless RAG 示例

專案還提供了一個 agentic vectorless RAG 示例，使用自託管 PageIndex 和 OpenAI Agents SDK。安裝可選依賴後執行：

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

這個示例的價值在於，它把 PageIndex 從「生成文件樹」推進到「讓 Agent 使用文件樹檢索」。如果你正在做企業知識庫、財報問答、法規問答或技術文件 Agent，這個示例比單純看 README 更值得跑一遍。

雲服務、MCP 和 API

PageIndex 不只是一個 GitHub repo。專案頁面還給了幾類入口：

• 自託管：用開源程式碼本地執行，適合試驗和可控部署。
• Chat Platform：類似 ChatGPT 的文件分析平台。
• MCP / API：方便接入現有 Agent 或自動化流程。
• Enterprise：面向私有化或本地部署。

這說明它的定位不是單純的 demo，而是想把「推理式文件檢索」做成一套可整合的文件智能基礎設施。

適合哪些場景

PageIndex 比較適合這些任務：

• 長 PDF 問答。
• 財報、年報、招股書、監管文件分析。
• 法律和合規文件檢索。
• 技術手冊問答。
• 多章節教材或論文檢索。
• 需要可解釋檢索路徑的企業知識庫。
• 給 Agent 提供結構化文件上下文。

如果你的材料本身很短、結構不明顯，或者只是普通 FAQ，傳統 embedding + vector DB 可能已經夠用。PageIndex 的優勢更容易出現在長文件、強結構、專業領域和需要推理的問題裡。

需要注意什麼

第一，PageIndex 仍然依賴 LLM。樹構建、摘要和檢索品質會受模型能力、提示詞、文件解析品質影響。

第二，本地版本使用標準 PDF 解析，複雜掃描件、圖表密集型 PDF、版式混亂材料可能需要 OCR 和更強的預處理。

第三，無向量庫不等於零成本。樹構建本身也會消耗模型呼叫和時間，尤其是大規模文件庫。

第四，它更像是文件結構索引和推理檢索框架，不是直接替代所有 RAG 技術棧。實際生產裡，也可能和向量檢索、關鍵字檢索、權限控制、快取、稽核系統一起使用。

小結

PageIndex 的有趣之處在於，它把 RAG 的重點從「文字相似度召回」轉向「文件結構 + LLM 推理」。對於長文件和專業文件，這個方向很值得關注。

如果你正在做企業文件問答、金融報告分析、法規檢索或技術手冊 Agent，可以把 PageIndex 當成一個新的 RAG 架構參考：先讓文件有結構，再讓模型沿著結構推理，而不是一開始就把所有內容切碎丟進向量庫。

參考來源：

• GitHub：VectifyAI/PageIndex