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 支持无向量数据库的长文档检索。
支持的输入格式包括:
- 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 安装:
|
|
也可以安装 GitHub 最新版本:
|
|
从源码开发安装:
|
|
创建一个知识库目录:
|
|
添加文档:
|
|
提问:
|
|
进入交互聊天:
|
|
如果你想让知识库自动处理新文件,可以使用 watch 模式:
|
|
之后把文件放进 raw/,OpenKB 会自动更新 wiki。
LLM 配置
OpenKB 通过 LiteLLM 支持多种模型供应商,包括 OpenAI、Claude、Gemini 等。
初始化时可以设置模型,也可以在 .openkb/config.yaml 里配置:
|
|
模型名称遵循 LiteLLM 的 provider/model 格式。OpenAI 模型可以省略 provider 前缀,例如:
|
|
Anthropic、Gemini 这类模型通常写成:
|
|
|
|
API key 放在 .env:
|
|
如果启用 PageIndex Cloud,再补充:
|
|
常用命令
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 在这套知识上工作。
参考链接: