知識庫 on KnightLi的博客

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

參考連結：

RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow 是 infiniflow 開源的 RAG（Retrieval-Augmented Generation，檢索增強生成）引擎。它的目標不是只做一個「上傳文件然後問答」的知識庫外殼，而是把文件解析、切分、檢索、重排、引用溯源、模型配置、Agent 能力和 API 整合放進一套完整工作流裡。

如果你正在做企業知識庫、文件問答、客服助手、內部資料檢索，或者想給 LLM 加一層更可靠的上下文來源，RAGFlow 屬於值得重點看的開源方案。

01 RAGFlow 解決什麼問題

普通 RAG 系統最容易遇到的問題有三個：

文件解析品質不穩定，尤其是 PDF、掃描件、表格、圖片、複雜排版文件。
切分策略不透明，命中結果看起來像是「搜到了」，但上下文並不完整。
回答缺少可靠引用，使用者很難判斷答案來自哪裡。

RAGFlow 的重點正好放在這些地方。專案 README 裡強調了 Deep document understanding、模板化切分、可視化 chunk、引用溯源和多路召回加重排。換句話說，它更關注「高品質資料進入，高品質答案輸出」，而不是只把向量資料庫和聊天框接起來。

02 核心功能

1. 深度文件理解

RAGFlow 支援從複雜格式的非結構化資料中抽取知識。README 中列出的資料類型包括 Word、PPT、Excel、TXT、圖片、掃描件、結構化資料、網頁等。

這對企業知識庫很關鍵。真實資料通常不是乾淨的 Markdown，而是合約、報告、表格、掃描 PDF、產品手冊、截圖和網頁混在一起。如果解析品質不夠，後面的向量檢索和 LLM 回答都會被拖垮。

2. 模板化切分

RAGFlow 提供模板化 chunking。它的價值在於：切分策略不是黑盒，可以根據文件類型選擇更合適的方式。

例如普通文章、論文、表格、問答文件、圖片說明、合約條款，對 chunk 的粒度和邊界要求都不一樣。模板化切分可以減少「句子被切碎」「表格上下文丟失」「標題和正文分離」這類問題。

3. 可追溯引用

RAGFlow 強調 grounded citations，也就是回答要能追溯到來源片段。它還提供 chunk 可視化，方便人工干預解析和切分結果。

這點對生產環境尤其重要。企業內部問答不是只要「看起來像答案」，還要能查證來源。對於政策、合規、財務、技術文件、客戶支持資料來說，引用和溯源幾乎是剛需。

4. 自動化 RAG 工作流

RAGFlow 把 RAG 流程做成相對完整的鏈路：

建立知識庫
上傳或同步資料
解析文件
查看和干預 chunk
配置 LLM 與 embedding 模型
執行多路召回與重排
建立聊天助手
透過 API 整合到業務系統

這讓它更像一個 RAG 平台，而不是單點工具庫。對團隊來說，UI、可視化和 API 都有價值：非研發人員可以維護知識庫，研發人員可以把能力接入既有系統。

5. Agent、MCP 與工作流能力

RAGFlow 的近期更新裡已經包含 Agentic workflow、MCP、Agent Memory、程式碼執行元件等內容。這說明它不只想做傳統知識庫問答，也在向 Agent 場景延伸。

典型方向是：Agent 在執行任務時，可以把 RAGFlow 作為可靠的企業知識上下文層；需要查資料時從知識庫召回，生成回答時保留引用，必要時再組合工具呼叫或工作流。

03 基本使用流程

按照官方快速開始文件，RAGFlow 的常見使用路徑可以概括成下面幾步。

1. 準備執行環境

官方 README 給出的基礎要求是：

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

如果要使用程式碼執行器的沙箱功能，還需要 gVisor。另外要注意，官方 Docker 映像主要面向 x86 平台；如果是 ARM64，需要依照官方說明自行建置映像。

2. 拉取專案

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. 檢查 `vm.max_map_count`

RAGFlow 部署會依賴 Elasticsearch / OpenSearch 這類元件，因此在 Linux 上通常需要確認：

`1`	`sysctl vm.max_map_count`

如果數值低於 262144，可以暫時設定：

`1`	`sudo sysctl -w vm.max_map_count=262144`

如果希望重開機後仍然生效，需要寫入 /etc/sysctl.conf。

4. 使用 Docker Compose 啟動

CPU 模式可以直接啟動：

`1`	`docker compose -f docker-compose.yml up -d`

如果要用 GPU 加速 DeepDoc 任務，README 中給出的方式是在 .env 中啟用 DEVICE=gpu 後再啟動：

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

啟動後查看日誌：

`1`	`docker logs -f docker-ragflow-cpu-1`

看到服務啟動完成後，再透過瀏覽器訪問伺服器地址。預設配置下，通常可以直接訪問：

`1`	`http://IP_OF_YOUR_MACHINE`

5. 配置模型 API Key

RAGFlow 需要配置 LLM 和 embedding 模型。README 提到可以在 service_conf.yaml.template 中選擇預設 LLM factory，並更新對應的 API_KEY。

實際使用時，你需要根據自己的模型供應商配置：

聊天模型
embedding 模型
rerank 模型
多模態模型（如果要理解 PDF / DOCX 中的圖片）

6. 建立知識庫並上傳文件

服務啟動後，典型操作是：

登入 Web UI。
建立 dataset / knowledge base。
上傳文件或配置資料源同步。
等待解析完成。
查看 chunk 結果，必要時人工調整。
建立聊天助手，選擇知識庫。
測試問答效果和引用來源。

如果要接入業務系統，可以繼續使用 RAGFlow 的 API 或 SDK，把知識庫檢索和聊天能力接到自己的應用裡。

04 適合哪些場景

RAGFlow 適合這些需求：

企業內部知識庫問答
產品手冊、技術文件、FAQ 檢索
客服助手和售前支持助手
合約、報告、制度文件的可追溯問答
多格式資料統一整理
需要 UI 維護知識庫，同時又要 API 整合的團隊
想把 RAG 能力作為 Agent 上下文層的系統

它尤其適合文件格式複雜、需要引用溯源、希望人工干預解析結果的場景。

05 使用時要注意什麼

第一，RAGFlow 不是輕量腳本。它對機器資源有要求，官方建議至少 4 核 CPU、16GB 記憶體和 50GB 磁碟。如果只是給少量 Markdown 做問答，可能沒必要上這麼完整的平台。

第二，文件品質仍然重要。RAGFlow 能改善解析和切分，但不能讓低品質、過期、互相矛盾的資料自動變得可靠。真正上線前，知識庫治理仍然要做。

第三，模型配置會直接影響效果。embedding、rerank、聊天模型、多模態模型的選擇，都會影響召回和回答品質。RAGFlow 提供了工作流，但效果仍然要靠資料、模型和參數一起調。

第四，生產環境要關注權限和資料安全。企業知識庫裡往往有內部資料，部署方式、訪問控制、日誌、API Key、模型供應商資料策略都要提前設計。

06 簡短判斷

RAGFlow 的優勢在於把 RAG 裡最麻煩的部分做成了平台化能力：複雜文件解析、可解釋切分、引用溯源、多路召回、重排、模型配置、Web UI、API 和 Agent 擴展。

如果你要做的是可驗證、可維護、可接入業務系統的企業知識庫，RAGFlow 比「向量庫 + 簡單聊天 UI」的方案更完整。反過來，如果只是個人小規模資料問答，或者資料格式非常簡單，輕量 RAG 框架可能更省資源。