OpenKB：开源 LLM 知识库——无向量检索的长文档处理新范式

项目概览

OpenKB（Open LLM Knowledge Base）是一个 2026 年 4 月刚刚发布就登上 GitHub Trending 的开源项目，截至 4 月 29 日已收获 851 Stars 和 81 Forks。它将自己定位为"Scale to long documents • Reasoning-based retrieval • Native multi-modality • No Vector DB"的知识库系统——没有向量数据库，是它最显著的区别于传统 RAG（Retrieval-Augmented Generation）方案的特性。

传统 RAG 系统依赖 Embedding 模型将文本切块后映射为高维向量，通过向量相似度检索相关内容。OpenKB 则完全抛弃了这条路，选择了 Andrej Karpathy 多次在公开演讲中提到的思路：让 LLM 自主阅读文档，生成摘要、提炼概念、建立交叉引用，最终构建出一个自我维护的维基百科式知识网络。

用一句话总结：OpenKB 不是在问"哪些文档片段与问题相似"，而是在问"关于这个主题，知识库里有什么概念和关系"。

核心理念：为什么放弃向量检索

向量检索的核心局限在于它是一种"浅层匹配"。Embedding 模型将文本映射为向量时，丢失了语义层级、逻辑关系和领域知识结构。同样一段关于"注意力机制"的文字，在一篇论文里是作为核心贡献出现的，在另一篇里是作为背景知识一笔带过的，向量相似度无法区分这种差异。

更关键的是，向量检索无法回答需要多步推理的问题。当你问"这篇论文的方法相比基线有哪些改进，在哪些任务上提升最显著"时，简单的向量检索只能返回包含相关关键词的片段，你需要自己拼凑答案。而 OpenKB 的思路是：文档已经被编译成了一张由概念和关系构成的知识网，检索本身就是一次"在知识图谱中导航"的过程。

OpenKB 的核心理念来自 Karpathy 的一个观点：LLM 有能力理解文档的语义层级（哪些是核心概念、哪些是子主题、概念之间如何关联），我们应该让 LLM 做这件事，而不是简单地把文档切成块然后做最近邻搜索。

系统架构

OpenKB 的处理流程分为四个核心阶段：

原始文档 → markitdown 解析 → PageIndex 构建 → LLM 知识编译 → wiki 知识库

第一阶段：markitdown 文档解析

markitdown 是 OpenKB 自研的文档解析工具，专门处理 PDF、Word、Markdown、PPT、HTML、Excel、text 等多种格式。它将这些格式统一转换为结构化的 Markdown，保留文档的层级结构（标题、段落、列表、表格、图片）。多模态内容（图片、图表）以 Markdown 图片引用的形式嵌入，表格则转为 Markdown 表格格式。

markitdown 的设计目标是最大程度保留原始文档的结构信息，为后续的 PageIndex 构建提供可靠的输入。

第二阶段：PageIndex 树形索引

PageIndex 是 OpenKB 最核心的技术创新，也是它能做到"No Vector DB"的关键。

传统 RAG 需要将文档切分成固定大小的块（通常 512~1024 tokens），每个块独立生成 Embedding 向量并存入向量数据库。问题在于：这种切分是机械的，不考虑语义边界。一个完整的论证段落可能被从中切断，两段讨论同一主题的分散内容也可能被分到不同的块里。

PageIndex 的做法是构建一棵文档结构树。对于每一个原始文档，它不是先切块再索引，而是先解析文档的逻辑结构——章节、段落、图表位置、引用关系——然后将这棵树作为检索的基本单位。检索时，系统在树中寻找与查询最相关的路径，而不是在扁平化的向量空间中做最近邻搜索。

具体来说，PageIndex 为每个文档维护：

• 页面节点：文档的每个自然阅读单位（可以是章节或页面）
• 结构边：节点之间的层级关系（父子、兄弟）
• 内容摘要：每个节点的简短描述，供上层索引使用

这棵树使得 OpenKB 能够在不同粒度上进行检索：既可以返回整个文档的概览，也可以深入到特定章节甚至段落级别。

第三阶段：LLM 知识编译

解析完文档结构之后，OpenKB 调用 LLM 对内容进行知识编译。这个过程是自动化的，由 LiteLLM 提供统一的多模型调用接口，支持 OpenAI、Anthropic、Claude、DeepSeek 等主流模型以及本地部署的模型。

LLM 的工作包括三个层面：

1. Summary（摘要）：为每个页面节点生成一段精炼的摘要，概括该节点的核心内容。
2. Concepts（概念）：从文档内容中提取关键概念，生成概念页面。每个概念对应一个以实体为核心的 Markdown 文件。
3. Cross-links（交叉引用）：分析不同概念之间的关系，自动在概念页面之间插入 [[wikilinks]] 双向引用。

编译完成后，原始文档被转化为一组结构化的 Markdown 文件：主摘要页面、多个概念页面、以及一个交叉引用网络。

第四阶段：Wiki 知识库输出

最终产出的知识库是一个标准的 Markdown 文件集合，天然支持 Obsidian 等基于纯文本的知识管理工具。每个概念页面都是独立的 .md 文件，页面之间通过 [[wikilinks]] 语法互联。这意味着一旦编译完成，你完全可以脱离 OpenKB，直接在 Obsidian 或任何兼容的工具中浏览和维护这个知识库。

知识编译流程详解

OpenKB 的知识编译并不是一次性完成的，而是有一个精心设计的增量维护机制：

初始编译

当你首次向 OpenKB 添加一组文档时，它会依次执行：

1. 文档解析：用 markitdown 将所有原始文档转为结构化 Markdown。
2. PageIndex 生成：为每个文档构建 PageIndex 树，记录文档的逻辑结构。
3. LLM 概念提取：对每个页面节点调用 LLM，提取关键概念并生成摘要。
4. 交叉链接建立：分析概念之间的语义关系，自动插入双向引用。
5. Wiki 输出：将编译结果写入 output/ 目录（默认），生成 Obsidian 兼容的 Markdown 文件集。

增量更新

OpenKB 支持 Watch 模式（后文详述），能够监控原始文档目录的变化。当文档发生修改、添加或删除时，系统会识别受影响的概念页面，仅重新编译变更部分，保留未变化的内容和已有的交叉引用关系。

这解决了传统 RAG 系统的一个核心痛点：当知识库中某篇文档更新时，必须重新对整个语料库做 Embedding——这在文档量大的场景下成本很高。OpenKB 的增量机制使得维护成本与变更规模成正比，而非与总文档量成正比。

Lint 健康检查

编译后的知识库可能存在以下问题：

• 孤立页面：概念页面存在但没有被任何其他页面引用，也没有引用任何其他页面。
• 陈旧内容：原始文档已更新，但对应概念页面未同步。
• 矛盾信息：两个相关概念页面的表述相互冲突。
• 引用缺失：页面提到了某个概念但没有建立双向链接。

openkb lint 命令会对整个知识库做全面检查，标记出上述问题并给出修复建议。这个功能让知识库从"建起来"变成"健康地运转"。

安装与快速开始

OpenKB 通过 pip 安装，依赖 Python 3.10+：

pip install openkb

安装完成后，通过以下步骤初始化一个知识库项目：

# 创建新项目
openkb init my-knowledge-base

# 进入项目目录
cd my-knowledge-base

# 添加原始文档（支持 PDF、Word、Markdown 等）
openkb add ./raw/my-paper.pdf
openkb add ./raw/research-notes.md

# 编译知识库
openkb build

# 查询知识库
openkb query "这篇论文的主要贡献是什么？"

# 启动交互式聊天
openkb chat

# 开启 Watch 模式（监控 raw/ 目录变更）
openkb watch

# 健康检查
openkb lint

项目初始化后，目录结构如下：

my-knowledge-base/
├── raw/              # 原始文档存放目录
├── output/           # 编译后的 wiki 知识库
├── cache/            # PageIndex 缓存和中间结果
└── openkb.yaml       # 项目配置文件

核心命令详解

openkb init

初始化一个新的知识库项目，生成基础目录结构和配置文件。

openkb init my-kb

会创建 my-kb/ 目录及子目录 raw/、output/、cache/，并生成 openkb.yaml 配置文件。

openkb add

将原始文档添加到 raw/ 目录，并立即解析文档结构。

openkb add ./documents/research-paper.pdf
openkb add ./notes/ --recursive

支持单个文件或目录递归添加。add 命令只做文档解析和 PageIndex 生成，不触发 LLM 编译。

openkb build

执行完整的知识编译流程：

openkb build

系统会依次执行：文档解析 → PageIndex 构建 → LLM 概念提取 → 交叉链接建立 → Wiki 输出。编译过程支持断点续传：如果上次编译中断，已经处理过的文档不会重复编译。

可以通过 --force 参数强制全量重建：

openkb build --force

openkb query

在已编译的知识库上执行自然语言查询：

openkb query "注意力机制在 Transformer 中的作用"

OpenKB 会先在 PageIndex 中定位最相关的文档节点，然后在对应的概念页面中检索答案，以结构化的方式返回结果。

openkb chat

启动交互式多轮对话，与知识库进行持续交流：

openkb chat

对话历史会被持久化存储在 cache/ 目录中。不同会话之间相互独立，你可以针对不同主题开启多个聊天会话。

openkb watch

监控 raw/ 目录的文件系统变更，自动触发增量编译：

openkb watch

当检测到新文件、文件修改或文件删除时，系统会自动更新 PageIndex 并触发受影响概念的重新编译。这个模式适合持续积累知识库的场景——只需把文档丢进 raw/，剩下的交给 OpenKB。

openkb lint

对已编译的知识库进行健康检查：

openkb lint

输出包括：孤儿页面列表、陈旧内容警告、矛盾检测结果、引用缺失建议。--fix 参数可以自动修复部分问题（如删除孤儿页面）。

Obsidian 集成

OpenKB 编译输出的 output/ 目录是标准的 Obsidian 知识库格式：

• 每个概念对应一个 .md 文件
• 页面之间使用 [[wikilinks]] 双向链接
• 目录结构就是 Obsidian 的库目录

这意味着你可以：

1. 直接用 Obsidian 打开 output/ 目录，在 Obsidian 的图谱视图中浏览概念之间的关联。
2. 继续手动维护：在 Obsidian 中补充笔记、添加标签、建立新的双向链接，OpenKB 的增量编译会保留这些手动编辑。
3. 利用 Obsidian 插件生态：如 Dataview、 Templater、Graph Analysis 等插件可以直接作用于 OpenKB 生成的维基知识库。

OpenKB 和 Obsidian 的关系可以被理解为"编译器"和" IDE"：OpenKB 负责从原始文档自动化地构建知识网络，Obsidian 则提供知识网络的交互式浏览和手动补充能力。两者天然互补，不存在厂商锁定。

适用场景与优势

适合的场景

• 长文档知识提取：当你有大量长篇论文、技术报告、书籍需要系统化管理时，OpenKB 的 PageIndex 能够完整保留文档结构，而非机械切分。
• 多文档关联分析：当需要理解多篇文档之间的概念交叉和依赖关系时，OpenKB 的交叉链接机制比向量检索更有效。
• 增量知识积累：持续有新文档加入的知识库场景，Watch 模式确保知识网络始终与原始文档同步。
• 多模态文档处理：PDF、Word、PPT 等包含图表的文档，markitdown 的解析器能够保留多模态内容的上下文关系。

相比传统 RAG 的优势

局限性

OpenKB 并非银弹，以下场景可能不太适合：

• 超大规模语料库：PageIndex 的树形结构在文档数量极大时，索引构建和检索的效率需要实际验证。
• 实时性要求极高：每次文档变更都需要 LLM 调用，编译过程本身有延迟。
• 简单查询场景：如果你的需求只是"在文档中找一个答案片段"，向量检索反而更快。

结语

OpenKB 代表了一种新兴的知识管理思路：不再依赖向量相似度做"大海捞针"式的检索，而是让 LLM 真正理解文档的结构和语义，将原始资料编译成一张活的知识网络。这条路是否会成为主流还需要时间来验证，但从目前的 GitHub 趋势和技术思路来看，它解决的是真实存在的痛点——传统 RAG 在长文档、多文档、跨文档场景下的局限性。

如果你正在寻找一种更智能、更可维护的知识管理方案，OpenKB 值得关注。作为一个 4 月刚发布就登上 Trending 的年轻项目，它的社区正在快速成长，现在参与进来既能获得一手经验，也有机会影响项目的发展方向。

项目地址：https://github.com/VectifyAI/OpenKB

Star：851 | Fork：81 | License：MIT