PageIndex 0.2.19 教程：先用本地模式检索一份长 PDF

PageIndex 把文档组织成层级树，再让模型沿树寻找相关页面。它没有向量数据库和 embedding 流程，但仍会调用 LLM 写节点摘要、搜索树并回答问题。

1. Flash 到底省掉了什么

传统流程通常要切块、生成 embedding，再部署向量存储。PageIndex 的 Flash 引擎从 PDF 布局统计和可信书签取得树结构，这一步本身不调用 LLM。随后它仍要让模型写节点摘要；默认的 optimize="full" 还会并发扩展树。把它称为“完全不使用模型的索引”是不准确的。

查询时，模型阅读树节点并逐层判断相关分支，最后返回页面内容并生成答案。这个设计更看重章节关系和推理导航，而不是向量相似度。

2. 本地模式的安装条件

官方 pyproject要求 Python 3.10 及以上，并声明支持 3.10 到 3.13。创建隔离环境后安装：

python3 -m venv .venv
source .venv/bin/activate
pip install -U pageindex

随后配置所选模型服务的 API key。v0.2.19 的本地模式不需要 PageIndex API key、PageIndex server 或向量数据库；这不等于不需要模型凭据。

3. 最小本地流程

官方 SDK 为本地路径提供 PageIndexLocalClient(storage_path=...)。实际试验应选择一份可以公开处理、文字可复制、答案能人工核对的 PDF。流程是：

1. 创建本地客户端并指定索引目录。
2. 提交 PDF，保存返回的 doc_id。
3. 使用同一客户端和 doc_id 提问。
4. 保存回答、页级引用、索引时间和模型费用。
5. 打开原 PDF，逐项检查引用页是否真的支持回答。

索引模型可以选较轻的模型；负责树搜索和回答的 chat 模型会更直接影响准确度。不要只看最终文字是否通顺。

4. 本地与 Cloud 的边界

官方能力表把本地路径定位为文本型 PDF、本地目录存储和页级引用。扫描件、图片丰富文档、OCR、图像理解、block citation、文件夹和面向大量文档的 File System 属于 Cloud 能力。

因此“支持百万文档”不能直接套到本地 SDK。要把文档传给 Cloud 时，还要单独评估数据位置、保留期限、访问控制和组织合规要求。

5. 成本和官方 benchmark 怎么看

官方给出 Flash 索引成本、耗时和 FinanceBench 准确率等结果。这些数字来自项目方自己的模型选择和测试环境。本地评估至少记录四项：引用页命中率、问题答案正确率、每份文档模型费用、索引与查询耗时。文档结构、页数和模型变化都会改变结果。

6. 商业化判断

PageIndex 确实推广 Cloud、企业部署和预约演示，但 v0.2.19 的 MIT 本地 SDK 有独立可用路径，不需要 PageIndex 账号、充值或订阅额度。当前没有把开源安装强制导向付费结账，所以保留本页，同时把云端专属能力明确标出来。

7. 和 LightRAG 对比

LightRAG同时维护知识图谱、向量嵌入以及 KV、vector、graph 存储，支持多种切块策略、增量更新和多种生产后端。PageIndex 的本地路线不建向量库，重点是单份文档树上的推理导航。

需要跨语料实体关系、增量维护和成熟存储后端，可以评估 LightRAG；主要处理结构清楚的长文档，希望减少存储组件，可以先用 PageIndex 做小样本对照。

常见问题