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 在這套知識上工作。

參考連結：

OpenKB on KnightLi的博客