OpenKB：把文件編譯成 wiki 的 LLM 知識庫，與 PageIndex 樹索引的搭配
OpenKB: Open LLM Knowledge Base
秒懂
- 它是什麼？
- OpenKB 以 CLI 形式把原始文件編譯成互連的 Markdown wiki，長文件走 PageIndex 的樹索引而非向量資料庫。它適合文件量大、需要跨文件綜合的團隊，但成敗取決於 LLM 品質與編譯成本，導入前應先驗證編譯產物的可用性。
- 適合誰用？
- OpenKB 適合手上已累積大量 PDF 與簡報、且需要跨文件綜合而非單篇問答的個人或小組；若你的檢索需求只是關鍵字查找、或無法承擔每次編譯的 LLM 費用，它會是過重的工具。導入前先確認三件事：長文件是否真的觸發 PageIndex 的樹索引路徑（PDF 頁數門檻約 20 頁）、你選用的 provider/model 在 LiteLLM 下能否穩定回傳結構化輸出、以及 wiki/ 目錄產出的 Markdown 是否達到你要的粒度。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 56 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
OpenKB 想解決的是「每次查詢都重新推導」這件事
傳統 RAG 的流程是：文件切塊、嵌入、存進向量資料庫，查詢時取出相似片段交給 LLM 生成答案。問題在於這個過程沒有累積。同一個問題問十次，系統就從零檢索十次，跨文件的矛盾不會被記錄，概念之間的關聯也不會留下。OpenKB 的 README 把這件事講得很直接：傳統 RAG 每次查詢都重新發現知識，什麼都不會沉澱。
它的做法是把知識編譯一次，存成持久存在的 wiki，之後只做維護。README 引用 Andrej Karpathy 描述的一個概念：由 LLM 生成摘要、概念頁與交叉引用，全部自動維護，知識隨時間累積。目標讀者因此不是「想問一份 PDF 一個問題」的人，而是手上有一批文件、需要反覆在同一批材料上做綜合的人。
這個定位有代價。編譯是一次性的前置成本，文件越多、越長，成本越高；而如果查詢模式其實是低頻的單點問答，這筆前置成本就白付了。判斷是否適合，關鍵在於你的問題是不是反覆落在同一批材料上。
兩層架構：wiki 基礎層與 generators 輸出層
OpenKB 的架構分成兩層。底層是 wiki foundation，負責編譯與維護知識；上層是 generators，把 wiki 轉成實際產出，README 點名的是 query、chat 與 Skill Factory。這個分層決定了它的擴充方向：新增的產出形式接在 generators 上，而不是改動底層的編譯流程。
編譯流程依文件長度分成兩條路徑。短文件走 markitdown 轉成 Markdown，由 LLM 讀取全文；長文件（README 寫的是 PDF 大於等於 20 頁）走 PageIndex，產生樹狀索引與摘要，LLM 讀的是文件樹而不是全文。圖片在短文件路徑下由 pymupdf 內嵌擷取，長文件路徑則交給 PageIndex。兩條路徑的最終產物相同：摘要加概念頁。
這個分流是整個設計裡最值得注意的地方。把長文件壓成樹，等於用結構化摘要換取可處理的上下文長度，代價是細節在索引階段就被丟掉一部分。README 沒有說明樹的深度、摘要的粒度或節點如何切分，這部分要實際編譯一份長 PDF 才看得出是否合用。
wiki 本身是純 .md 檔加交叉連結，README 明確說它相容 Obsidian，可以直接開來看 graph view。這也意味著你可以用 git 管理這批檔案，或用任何 Markdown 工具檢視，不必被綁在 OpenKB 的介面裡。
編譯產物的三種形態：摘要、概念頁、實體頁
README 列出 wiki 由 LLM 編譯出的幾種頁面：摘要、概念頁、實體頁，以及交叉連結。實體頁對應的是人物、組織、地點與產品，README 說它們是自動擷取並保持同步的獨立 wiki 頁面。
這個設計的實際意義是：當同一家公司出現在五份不同文件裡，它會收斂到一個頁面，而不是散在五段不相關的檢索結果中。跨文件的矛盾之所以能被標記，前提就是這種收斂。
README 也提到 wiki 頁面遵循 Google Open Knowledge Format（OKF）規範，用於知識分享。這對需要把知識庫輸出給其他系統的團隊有用，但 README 沒有給出 OKF 欄位的具體對應或驗證方式，實際互通程度要看產出的 Markdown 結構。
需要注意的界線是：這些頁面由 LLM 生成，不是人工審核過的。README 描述的「自動維護」與「保持同步」是機制上的說法，並不保證正確性。把它當成一份持續更新的草稿庫比較實際，而不是當成權威事實來源。
從安裝到第一次查詢的實際指令
安裝用 pip：pip install openkb。README 另外提供兩個選項，從 GitHub 安裝用 pip install git+https://github.com/VectifyAI/OpenKB.git，從原始碼開發安裝則是 git clone 之後 pip install -e .。
基本流程是五步。先建立目錄並初始化：mkdir my-kb && cd my-kb，接著 openkb init。然後加入文件，openkb add 接受單一檔案（openkb add paper.pdf）、整個目錄（openkb add ~/papers/），也接受 URL（openkb add https://arxiv.org/pdf/2509.11420）。查詢用 openkb query "..."，互動對話用 openkb chat。
LLM 設定在 openkb init 時指定，或寫進 .openkb/config.yaml，格式是 LiteLLM 的 provider/model，例如 anthropic/claude-sonnet-4-6；OpenAI 的模型可以省略前綴，例如 gpt-5.4。API key 放在 .env 檔的 LLM_API_KEY。README 提到透過 OAuth device flow 認證的訂閱制 provider（例如 chatgpt/*、github_copilot/*）不需要 API key，OpenKB 對這類 provider 會跳過缺少金鑰的警告。README 也註明 LiteLLM 釘在一個安全版本上，並連到 2026 年 3 月的安全更新公告。
輸出層的指令有三個：openkb skill new my-expert "..." 產生可攜的 agent skill，openkb visualize 產生互動知識圖，openkb deck new my-deck "..." 產生單檔 HTML 簡報。
Web UI 要另外裝：pip install "openkb[web]"，然後執行 openkb-web，服務在 http://127.0.0.1:7566/。README 說預設不驗證（local-first），要對外暴露前應設 OPENKB_API_TOKEN 要求 bearer token。前端開發用 cd frontend && npm install && npm run dev，它會把 /api 代理到執行中的 openkb-web。
向量庫拿掉之後，換來的是編譯期的成本與不確定性
OpenKB 的賣點之一是 No Vector DB。少了嵌入模型與向量庫，部署確實少一層依賴，也不必處理索引重建與維度遷移。但這不等於沒有成本，只是把成本移到編譯期。
每次 openkb add 都會呼叫 LLM 產生摘要、概念頁與交叉連結。文件越多，這筆費用越線性成長，而且是在你還沒問任何問題之前就先付。長文件走 PageIndex 路徑，多了一層樹索引與摘要生成，前置作業更重。README 沒有提供任何成本估算或 token 用量數字，這部分只能自己用一份代表性文件實測。
第二個限制是品質完全綁在 LLM 上。編譯產物的好壞取決於模型能否穩定產出結構化的頁面與連結。README 沒有描述 schema 驗證、重試機制或編譯失敗的處理方式。如果模型輸出的格式不穩，wiki 的交叉連結就可能斷裂，而這類問題不會在指令層級報錯，只會反映在查詢結果裡。
第三個限制是維護語意不明。README 說實體頁「auto-extracted and kept in sync」，但沒有說明同步是增量更新、整批重編，還是需要手動觸發。當底層文件被替換或刪除時，舊的 wiki 頁面會怎麼處理，README 沒有交代。這是評估時最該追問的一點。
最後是適用邊界。如果你的需求是精確的字串查找、法規條文的逐字引用，或需要可審計的來源標註，編譯式 wiki 這種「摘要再摘要」的產物並不適合，它天生會丟失細節。
與傳統向量 RAG 的差別不只是檢索方式
拿 OpenKB 和 LlamaIndex、LangChain 這類框架相比，差異不在功能多寡，而在知識的生命週期。
框架型的向量 RAG 是查詢時組裝：你定義 loader、splitter、embedding、retriever，每次查詢即時拼出一條 pipeline。知識本身不落地，只存在於向量庫的片段裡。要跨文件綜合，得靠 retriever 撈出足夠多的片段，再讓 LLM 在單次上下文裡拼湊。
OpenKB 反過來，先把知識編譯成有結構的頁面，查詢時讀的是已經整理好的 wiki。跨文件的關聯在編譯階段就建立了，不必每次靠檢索碰運氣。代價是這批知識是 LLM 的二次加工，原始文本的細節可能已經被摘要掉。
長文件的處理方式差異更大。向量 RAG 對長 PDF 的標準做法是切塊，切塊會切斷章節結構與表格語意。OpenKB 改用 PageIndex 的樹索引，README 的說法是「vectorless, reasoning-based retrieval」，檢索靠推理而非向量相似度。這條路線在需要理解文件結構的場景下合理，但它依賴 PageIndex 這個獨立專案，等於多了一層外部依賴。
如果你的團隊已經有一套運作良好的向量 RAG，而且問題主要是單點查找，換到 OpenKB 的收益有限，還要承擔重新編譯全部文件的成本。
授權、版本節奏與升級時要看的東西
OpenKB 採用 Apache-2.0 授權，允許商用與修改，條款細節請自行閱讀授權全文，本文不構成法律意見。需要留意的是它依賴 LiteLLM 與 PageIndex 這兩個獨立專案，各自的授權與更新節奏不受 OpenKB 控制。
版本節奏可以從 release 看出輪廓：v0.4.4 在 2026-07-10，同日稍早有一個 v0.4.4-rc1，v0.4.5 在 2026-07-20。這種 rc 先行的做法說明維護者會在正式版前先發候選版。目前仍在 0.4.x，屬於頻繁變動的階段，升級時不能假設設定檔與 CLI 參數向後相容。
升級前值得先確認的是 .openkb/config.yaml 的欄位有沒有變動，以及 wiki/ 目錄的既有產物是否需要重新編譯。README 沒有提供遷移指南或版本相容性說明，這表示跨版本升級要靠 changelog 與實際測試。
另一個要追蹤的點是 LiteLLM 的版本。README 明確說它釘在一個安全版本上並連到安全公告，這通常意味著歷史上曾出現相關問題。如果你的環境有供應鏈審查流程，這個釘版策略是正面的，但也代表 provider 支援會落後於 LiteLLM 上游。
編輯結論
OpenKB 適合手上已累積大量 PDF 與簡報、且需要跨文件綜合而非單篇問答的個人或小組；若你的檢索需求只是關鍵字查找、或無法承擔每次編譯的 LLM 費用，它會是過重的工具。導入前先確認三件事：長文件是否真的觸發 PageIndex 的樹索引路徑（PDF 頁數門檻約 20 頁）、你選用的 provider/model 在 LiteLLM 下能否穩定回傳結構化輸出、以及 wiki/ 目錄產出的 Markdown 是否達到你要的粒度。若這三項都通過，再考慮把 openkb-web 暴露到內網；否則先在單一目錄試編譯一份文件，看產物再決定。
社群筆記