PageIndex on KnightLi的博客

PageIndex 是什么？不用向量库的推理式 RAG 文档索引解析

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex 是一个很有意思的 RAG 项目。它不从“再建一个向量库”开始，而是把长文档先整理成类似目录的树状结构，再让 LLM 沿着这棵树做推理式检索。

截至本文整理时，GitHub 页面显示项目约有 31.8k stars、2.7k forks，许可证为 MIT。README 给它的定位是：Vectorless, Reasoning-based RAG，也就是无向量库、基于推理的 RAG。

它想解决什么问题

传统 RAG 的常见路径是：切块、向量化、写入向量数据库，再用相似度搜索召回片段。这套方法简单、通用，也很成熟，但在长篇专业文档里容易遇到几个问题：

相似度不等于真正相关。
文档结构被切块打散，章节关系丢失。
召回结果可解释性弱，很难说明为什么命中这一段。
对财报、监管文件、法律文书、技术手册这类材料，问题往往需要跨章节推理。

PageIndex 的思路是反过来：先把文档组织成语义树，再让模型像人类读目录、翻章节、逐层定位一样查找相关内容。

PageIndex 的基本工作流

README 里把 PageIndex 的检索分成两步：

为文档生成类似 Table-of-Contents 的树状结构索引。
通过树搜索做 reasoning-based retrieval。

这棵树不是简单的文件目录，而是面向 LLM 使用的文档结构。节点里会有标题、页码范围、摘要、子节点等信息。这样模型在回答问题时，不必一开始就面对大量零散 chunk，而是可以先判断应该进入哪个章节，再继续向下搜索。

这种方式更适合结构清晰但内容很长的文档，例如：

金融报告和 SEC filings。
监管材料和合规文档。
学术教材和论文。
法律文件。
技术手册和产品文档。
超过模型上下文窗口的大型 PDF。

和传统向量 RAG 的差异

PageIndex 的核心卖点可以概括成五点。

第一，不需要 Vector DB。它依赖文档结构和 LLM 推理来定位内容，而不是只做向量相似度搜索。

第二，不做传统 chunking。文档会按自然章节组织，而不是被切成固定长度片段。

第三，可解释性更强。检索路径可以对应到页码、章节和树节点，比“向量相似度命中某段文本”更容易追踪。

第四，检索是上下文感知的。问题、对话历史、领域背景都可以影响树搜索路径。

第五，更接近人类专家读文档的方式。人通常不是把整本文档切成小块再算相似度，而是先看目录，再定位章节，最后读细节。

这并不意味着向量库没有价值。更准确的说法是：PageIndex 适合那些“语义相似不够，需要结构和推理参与”的长文档场景。

本地怎么跑

README 提供了本地自托管方式。先安装依赖：

`1`	`pip3 install --upgrade -r requirements.txt`

然后在项目根目录创建 .env，写入 LLM API key。项目通过 LiteLLM 支持多模型：

`1`	`OPENAI_API_KEY=your_openai_key_here`

对 PDF 生成 PageIndex 结构：

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

也可以处理 Markdown：

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

常见可选参数包括：

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

README 里也提醒，本地开源版本使用标准 PDF 解析。如果是复杂 PDF，项目方的云服务会提供增强 OCR、树构建和检索流程。

Agentic Vectorless RAG 示例

项目还提供了一个 agentic vectorless RAG 示例，使用自托管 PageIndex 和 OpenAI Agents SDK。安装可选依赖后运行：

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

这个示例的价值在于，它把 PageIndex 从“生成文档树”推进到“让 Agent 使用文档树检索”。如果你正在做企业知识库、财报问答、法规问答或技术文档 Agent，这个示例比单纯看 README 更值得跑一遍。

云服务、MCP 和 API

PageIndex 不只是一个 GitHub repo。项目页面还给了几类入口：

自托管：用开源代码本地运行，适合试验和可控部署。
Chat Platform：类似 ChatGPT 的文档分析平台。
MCP / API：方便接入现有 Agent 或自动化流程。
Enterprise：面向私有化或本地部署。

这说明它的定位不是单纯的 demo，而是想把“推理式文档检索”做成一套可集成的文档智能基础设施。

适合哪些场景

PageIndex 比较适合这些任务：

长 PDF 问答。
财报、年报、招股书、监管文件分析。
法律和合规文档检索。
技术手册问答。
多章节教材或论文检索。
需要可解释检索路径的企业知识库。
给 Agent 提供结构化文档上下文。

如果你的材料本身很短、结构不明显，或者只是普通 FAQ，传统 embedding + vector DB 可能已经够用。PageIndex 的优势更容易出现在长文档、强结构、专业领域和需要推理的问题里。

需要注意什么

第一，PageIndex 仍然依赖 LLM。树构建、摘要和检索质量会受模型能力、提示词、文档解析质量影响。

第二，本地版本使用标准 PDF 解析，复杂扫描件、图表密集型 PDF、版式混乱材料可能需要 OCR 和更强的预处理。

第三，无向量库不等于零成本。树构建本身也会消耗模型调用和时间，尤其是大规模文档库。

第四，它更像是文档结构索引和推理检索框架，不是直接替代所有 RAG 技术栈。实际生产里，也可能和向量检索、关键词检索、权限控制、缓存、审计系统一起使用。

小结

PageIndex 的有趣之处在于，它把 RAG 的重点从“文本相似度召回”转向“文档结构 + LLM 推理”。对于长文档和专业文档，这个方向很值得关注。

如果你正在做企业文档问答、金融报告分析、法规检索或技术手册 Agent，可以把 PageIndex 当成一个新的 RAG 架构参考：先让文档有结构，再让模型沿着结构推理，而不是一开始就把所有内容切碎丢进向量库。

参考来源：

GitHub：VectifyAI/PageIndex

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 在这套知识上工作。

参考链接：