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的博客