PageIndex on KnightLi的博客

PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析

Wed, 20 May 2026 23:51:37 +0800

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

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

它想解決什麼問題

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

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

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

PageIndex 的基本工作流

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

為文件生成類似 Table-of-Contents 的樹狀結構索引。
透過樹搜尋做 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`

常見可選參數包括：

--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

OpenKB：把文件編譯成可持續更新的 LLM 知識庫

Sun, 17 May 2026 17:15:08 +0800

OpenKB 是 VectifyAI 開源的 LLM 知識庫工具。

它不是傳統意義上「把文件切塊、向量化、查詢時再拼上下文」的 RAG 系統，而是把原始文件先編譯成一個結構化 wiki：有文件摘要、有概念頁、有交叉引用，也有後續查詢和 lint 檢查。換句話說，它更像是一個會持續整理資料的知識庫 CLI。

專案地址：https://github.com/VectifyAI/OpenKB

先說結論

OpenKB 值得關注的地方有三點：

它把知識庫輸出成普通 Markdown 文件，而不是鎖在某個專用資料庫裡。
它用 PageIndex 處理長 PDF，主打無向量資料庫的長文件檢索。
它強調「知識編譯」，讓 LLM 生成摘要、概念頁和交叉連結，而不是每次提問都從零檢索。

這讓 OpenKB 更適合長期累積資料的場景，比如論文閱讀、專案文件、公司內部資料、技術規範、產品調研和個人知識庫。

它也不是萬能替代品。如果你需要高併發線上問答、複雜權限管理、Web 管理後台、企業級審計和大規模多租戶能力，OpenKB 現在更像一個開發者工具和知識庫原型，而不是完整企業知識平台。

OpenKB 是什麼

OpenKB 的全名是 Open Knowledge Base。

它以 CLI 形式工作，把放進知識庫的原始文件轉換、整理、總結，並生成一套 wiki 文件。官方 README 的描述很直接：OpenKB 會用 LLM 把原始文件編譯成結構化、互相連結的 wiki 風格知識庫，並透過 PageIndex 支援無向量資料庫的長文件檢索。

支援的輸入格式包括：

PDF
Word
Markdown
PowerPoint
HTML
Excel
純文字
其他可由 markitdown 轉換的格式

生成後的知識庫位於 wiki/ 目錄，主要包括：

index.md：知識庫總覽
log.md：操作時間線
AGENTS.md：知識庫結構和維護說明
sources/：轉換後的原文
summaries/：每份文件的摘要
concepts/：跨文件概念頁
explorations/：保存的查詢結果
reports/：lint 檢查報告

這個設計最大的好處是透明。你可以直接打開 Markdown 文件查看知識庫，而不是只能透過一個黑盒檢索介面拿答案。

它和傳統 RAG 有什麼不同

傳統 RAG 常見流程是：

把文件切塊。
生成 embedding。
存進向量資料庫。
查詢時召回相關片段。
把片段塞給 LLM 生成答案。

這個流程很成熟，也很適合問答系統。但它有一個問題：知識本身沒有真正沉澱。每次提問都在重新找片段、重新拼上下文、重新生成答案。

OpenKB 的思路更偏「先整理，再問答」：

文件進入 raw/。
短文件透過 markitdown 轉成 Markdown。
長 PDF 透過 PageIndex 生成樹狀索引和摘要。
LLM 生成文件摘要。
LLM 讀取已有概念頁，建立或更新跨文件概念。
知識庫索引、日誌和交叉連結同步更新。

這樣做的結果是，新增一份文件不只是多了一個可檢索文件，而是可能更新十幾個 wiki 頁面。知識會被寫進概念頁裡，並和已有資料發生連結。

這更像人類維護知識庫的方式：新資料進來後，不只是存檔，還要更新主題頁、總結差異、補充引用。

PageIndex 解決什麼問題

長文件一直是 RAG 和 LLM 知識庫裡的難點。

如果直接把長 PDF 切成很多 chunk，容易遇到幾個問題：

章節關係丟失。
表格、圖片和註腳難處理。
檢索片段過碎，答案缺少全局結構。
上下文視窗再大，也不適合把整份文件塞進去。
摘要鏈路過長時，細節容易被壓掉。

OpenKB 使用 PageIndex 來處理長 PDF。按專案說明，PageIndex 會為長文件建立樹狀索引和摘要，讓 LLM 在文件樹上推理，而不是直接讀取整篇長文件。

這條路線的重點不是「向量相似度最高的幾段文字」，而是讓模型利用文件層級結構找到相關內容。對於研究報告、論文、說明書、招股書、合規文件這類長材料，這個思路很有意義。

OpenKB 預設可以使用開源版 PageIndex 本地運行；如果需要 OCR、複雜 PDF 處理或更快結構生成，也可以配置 PAGEINDEX_API_KEY 使用 PageIndex Cloud。

安裝和快速開始

OpenKB 可以直接透過 pip 安裝：

`1`	`pip install openkb`

也可以安裝 GitHub 最新版本：

`1`	`pip install git+https://github.com/VectifyAI/OpenKB.git`

從原始碼開發安裝：

1
2
3

git clone https://github.com/VectifyAI/OpenKB.git
cd OpenKB
pip install -e .

建立一個知識庫目錄：

1
2

mkdir my-kb && cd my-kb
openkb init

新增文件：

1
2

openkb add paper.pdf
openkb add ~/papers/

提問：

`1`	`openkb query "What are the main findings?"`

進入互動聊天：

`1`	`openkb chat`

如果你想讓知識庫自動處理新文件，可以使用 watch 模式：

`1`	`openkb watch`

之後把文件放進 raw/，OpenKB 會自動更新 wiki。

LLM 配置

OpenKB 透過 LiteLLM 支援多種模型供應商，包括 OpenAI、Claude、Gemini 等。

初始化時可以設定模型，也可以在 .openkb/config.yaml 裡配置：

1
2
3

model: gpt-5.4
language: en
pageindex_threshold: 20

模型名稱遵循 LiteLLM 的 provider/model 格式。OpenAI 模型可以省略 provider 前綴，例如：

`1`	`model: gpt-5.4`

Anthropic、Gemini 這類模型通常寫成：

`1`	`model: anthropic/claude-sonnet-4-6`

`1`	`model: gemini/gemini-3.1-pro-preview`

API key 放在 .env：

`1`	`LLM_API_KEY=your_llm_api_key`

如果啟用 PageIndex Cloud，再補充：

`1`	`PAGEINDEX_API_KEY=your_pageindex_api_key`

常用命令

OpenKB 的命令很適合開發者使用：

openkb init：初始化知識庫。
openkb add <file_or_dir>：新增文件或目錄。
openkb remove <doc>：移除文件，並清理相關 wiki 頁面、圖片、註冊表和 PageIndex 狀態。
openkb query "question"：對知識庫進行一次性提問。
openkb chat：進入多輪對話。
openkb watch：監聽 raw/ 目錄並自動更新。
openkb lint：檢查知識庫結構和內容健康狀態。
openkb list：列出已索引文件和概念。
openkb status：查看知識庫統計資訊。

其中 openkb chat 比 openkb query 更適合連續探索。它支援會話恢復、會話列表和刪除，也支援在聊天中使用 slash commands，比如 /status、/list、/add <path>、/save、/lint。

為什麼 Markdown wiki 很重要

很多知識庫工具的麻煩在於遷移成本。

一旦資料進入專有資料庫、專有索引或專有格式，你就很難直接審查、修改、備份和遷移。OpenKB 把結果寫成普通 Markdown，這讓它天然適合和現有工具配合。

最直接的用法是用 Obsidian 打開 wiki/ 目錄：

摘要頁可以直接閱讀。
概念頁可以用 [[wikilinks]] 互相連結。
圖譜視圖可以看到知識之間的關係。
查詢結果可以保存到 explorations/。
AGENTS.md 可以定義知識庫維護方式。

這讓 OpenKB 不只是一個問答工具，也可以變成個人或團隊的知識整理流水線。

適合哪些場景

OpenKB 特別適合這些場景：

論文和技術報告閱讀。
專案文件整理。
產品調研資料庫。
開源專案原始碼之外的文件知識庫。
公司內部規範、會議紀要和說明文件整理。
個人 Obsidian 知識庫自動維護。
長 PDF、PPT、Word 和網頁資料的結構化沉澱。

如果你經常面對一堆文件，卻不只是想「問一句得到答案」，而是希望資料能逐步變成可瀏覽、可復用、可追蹤的知識庫，OpenKB 的方向就很對。

使用時要注意什麼

第一，OpenKB 依賴 LLM 品質。

摘要、概念頁和交叉連結都由模型生成。模型越強，知識編譯品質越穩定；模型能力不足時，概念抽取、衝突識別和跨文件綜合都會打折扣。

第二，成本要提前估算。

如果一次性匯入大量長文件，LLM 調用成本可能不低。建議先用小規模資料集測試，確認輸出結構和品質，再擴大匯入範圍。

第三，生成的 wiki 仍然需要人工審閱。

OpenKB 可以整理資料，但不等於自動保證事實完全正確。重要知識庫仍然需要人工檢查摘要、概念頁和引用關係。

第四，敏感資料要謹慎。

如果使用雲端 LLM 或 PageIndex Cloud，就要注意文件裡的隱私、商業機密和合規要求。內部資料最好先確認模型供應商、資料保留策略和存取邊界。

第五，它目前更偏 CLI 工具。

專案路線圖裡提到未來會有 Web UI、資料庫儲存、大規模集合支援和層級概念索引。但在目前階段，如果團隊成員不熟悉命令列，使用門檻仍然存在。

和 Obsidian、NotebookLM、企業 RAG 的關係

OpenKB 和 Obsidian 的關係更像「自動整理層」和「閱讀編輯層」。

Obsidian 適合人來寫、改、瀏覽和建立連結；OpenKB 適合把原始文件批量整理成可以進入 Obsidian 的 wiki。

OpenKB 和 NotebookLM 的關係則更偏「本地可控」和「開放文件形態」。

NotebookLM 使用體驗更直接，適合把資料丟進去快速問答和生成摘要；OpenKB 更適合開發者把整理結果留在本地目錄裡，用 Markdown 繼續維護。

OpenKB 和企業 RAG 的關係不是替代，而是補位。

企業 RAG 更看重權限、審計、服務化、權限隔離、監控和穩定吞吐。OpenKB 更適合構建一個可讀、可改、可長期沉澱的知識層。未來如果要做線上問答，也可以把 OpenKB 生成的 wiki 作為更高品質的語料來源。

一個推薦工作流

如果你想試 OpenKB，可以按這個順序來：

新建一個測試知識庫目錄。
先放 3 到 5 份同一主題的文件。
運行 openkb add。
打開 wiki/ 查看摘要和概念頁。
用 openkb query 問幾個具體問題。
用 openkb lint 檢查知識庫健康狀態。
用 Obsidian 打開 wiki/，看連結圖譜是否有意義。
確認品質後，再匯入更大的文件集合。

不要一上來就把幾百個文件全丟進去。先看它對你的資料類型是否理解得好，尤其是表格、圖片、長 PDF 和多文件概念合併效果。

總結

OpenKB 的價值在於，它把 LLM 知識庫從「查詢時臨時拼上下文」往前推了一步：先把資料整理成 wiki，再在 wiki 上問答、聊天、檢查和繼續維護。

這條路線不一定適合所有問答系統，但很適合需要長期沉澱的知識工作。Markdown 文件、Obsidian 相容、PageIndex 長文件處理、多模型支援和 CLI 工作流，組合起來就是一個很適合開發者和研究型使用者的知識庫工具。

如果你手上有大量 PDF、報告、網頁、論文和專案文件，OpenKB 值得試一下。它未必能馬上替代成熟企業知識庫，但可以成為一個很實用的資料整理入口：先把文件變成可讀、可連結、可追蹤的知識，再讓 LLM 在這套知識上工作。

參考連結：