PageIndex：不用向量库的 RAG，3.5 万星背后是真突破还是换了个地方花钱

by Mycelium Protocol

---

项目地址：https://github.com/VectifyAI/PageIndex 文档：https://docs.pageindex.ai Show HN 讨论（2025-08-27，192 赞）：https://news.ycombinator.com/item?id=45036944 授权：MIT

---

一句话结论

PageIndex 不建向量库、不切 chunk，改成给文档生成一棵「树状目录索引」，让 LLM 像人翻书一样在树上推理着找答案。 项目 2025 年 4 月创建，到现在 35354 星、3115 fork，8 月还在持续发版本（本月刚上线本地 SDK 模式和秒级建树的 PageIndex Flash），不是昙花一现的 Show HN 项目。它的核心主张很尖锐：相似度不等于相关性——向量检索找的是”语义像”的段落，但专业文档里真正该被找到的往往是”语义不像但确实相关”的那一段，这正是向量 RAG 在财报、法律合同、技术手册这类长文档上经常翻车的原因。

解决的问题：相似度 ≠ 相关性

传统 RAG 的流程是切 chunk → 建 embedding → 存向量库 → 查询时算相似度取 top-k。这套流程的隐含假设是”语义相似的段落就是该被检索出来的段落”，但 PageIndex 的作者（受 AlphaGo 的树搜索启发）认为，专业文档需要的是推理，不是匹配——一份年报里”2023 年营业利润率”这个问题的答案，可能藏在一段完全没提”利润率”三个字、语义上跟问题不那么”像”的表格附注里，向量相似度天然找不到,只有理解文档结构、顺着目录往下翻的推理过程才能找到。

机制：建树索引 + LLM 推理检索

PageIndex 的检索分两步：

1. 建树索引：从 PDF 的排版结构里直接抽取目录层级（不需要 LLM），LLM 只用来给每个节点写摘要、做树结构优化。这一步叫 PageIndex Flash，是 2026 年 8 月刚上线的能力，几秒到几分钟就能建完一份文档的树。
2. 树上推理检索：LLM 沿着这棵树”agentic 搜索”，像人打开一份长报告先看目录、再翻到具体章节一样，而不是拿 query 的 embedding 去数据库里捞最近邻。

生成出来的树长这样，是给 LLM 用的”目录”，带页码范围和摘要：

{
  "title": "Financial Stability",
  "node_id": "0006",
  "start_index": 21,
  "end_index": 22,
  "summary": "The Federal Reserve ...",
  "nodes": [
    {
      "title": "Monitoring Financial Vulnerabilities",
      "node_id": "0007",
      "start_index": 22,
      "end_index": 28,
      "summary": "The Federal Reserve's monitoring ..."
    }
  ]
}

最小可用示例：

from pageindex import PageIndexClient

client = PageIndexClient(index="gpt-5.6-luna", chat="gpt-5.6-sol")
doc_id = client.submit_document("report.pdf")["doc_id"]
answer = client.chat("2023 年营业利润率是多少，出自哪一页？", doc_id=doc_id)

答案自带可追溯的页码引用，而不是向量 RAG 常见的”检索了但说不清依据”。

和向量 RAG 的对比

	向量 RAG	PageIndex
索引	向量嵌入	树结构
检索单元	固定大小 chunk	文档自然章节
检索方式	语义相似度搜索	LLM 在树上推理
结果可追溯性	不透明，“跟着感觉走的检索”	可精确追溯到页码/行号
上下文利用	只有 query 的 embedding	对话历史、领域知识都能带进推理
单次检索延迟	毫秒级	秒级到分钟级（多次 LLM 调用）
建索引成本	一次性 embedding 计算，便宜	本地建树约 $0.001/页，也是一次性

官方给出的基准是在 FinanceBench（财务文档问答基准）上跑出 98.7% 准确率，对比向量 RAG 约 50%，这个结果来自他们自己的 Mafin 2.5 评测项目。同时 VectifyAI 另开了一个更中立一点的 PageIndex-OSS-Benchmark，用 MMLongBench-Doc-V2 里 34 篇 PDF（1945 页）的 62 道题，跑的就是开箱即用的本地模式，没有额外优化。

HN 上的争议：技术圈没有一边倒地叫好

这个项目 2025 年 8 月 27 日在 Hacker News 上以「Show HN: PageIndex – Vectorless RAG」发布，拿到 192 个赞（用 Algolia API 核实过的真实数字，网上有文章把这个数字写成 432+，是错的）。评论区的技术质疑集中在四点，值得写出来，不然这篇就是单方面转述官方通稿：

• 规模上不去的担忧：有工程师直接说”我有一个 1 万+文档的知识库，我不觉得这套技术能撑住”；另一条评论指出，树结构理论上是对数级扩展，但实际上”文档结构一旦逼近 LLM 的上下文上限，规模就会出问题”。
• 成本和延迟只是换了个地方：向量库是毫秒级检索、查询成本几乎为零；PageIndex 每次检索都要 LLM 反复调用做树搜索，延迟是秒级到分钟级。官方自己的立场也是”这适合准确率比速度重要的场景”，本质上是一笔用延迟和 token 成本换准确率的交易，不是免费午餐。
• “无向量”这个说法本身被挑战：有评论直言”这本质上就是用递归的 LLM API 调用去生成结构化 JSON，我没看出 PageIndex 比这多做了什么”——树的生成、摘要、检索每一步都靠 LLM，“vectorless”准确说是”不用向量数据库”，而不是”不依赖 embedding 类模型的判断”。
• 缺第三方基准：有做检索方向的工程师指出，公开材料里”明显缺少在标准 RAG/QA 基准上的表现，除了他们自家高度调优过的 Mafin2.5”——FinanceBench 98.7% 这个数字目前主要来自 VectifyAI 自己的评测，还没看到独立第三方复现。

对比向量 RAG 之外的路线，评论区也提到：GraphRAG 是把实体抽取的成本预先花在建索引阶段,PageIndex 是把成本推迟到查询时——只是换了个地方付费，不是更便宜；也有人建议与其整套换成 PageIndex,不如先把向量检索和 BM25 这类传统排序做好混合调优,很多”向量 RAG 不准”的抱怨其实是没调好,而不是向量这条路线本身走不通。

这些质疑不构成”这个项目不值得用”,但构成了”别只看 98.7% 这一个数字就下场”的理由。

本地版 vs Cloud 版

能力	本地（这个仓库，开源）	Cloud（需要 API key）
适合场景	纯文字 PDF、本地工作流	扫描件、图片密集型文档、大规模文档集合
建索引	本地跑	云端跑，带生产级 OCR 和图片理解
存储	本地	PageIndex 托管
引用粒度	页级	行级
图片理解	无	有
多文档规模	手动管理	PageIndex File System（跨文档级树索引）
MCP server	无	有

谁该看这个

适合：手里有大量财报、法规文件、技术手册、医学文献这类长且结构清晰的专业文档，愿意为准确率多付一点延迟和 token 成本，且检索量不算特别大（不是每秒几百次查询那种在线服务场景）的团队。

不适合 / 需要留意：文档集合到万级规模、或者对检索延迟有硬性要求（在线客服、实时问答）的场景，目前公开信息里还没有令人信服的证据证明它能扛住；98.7% 这个亮眼数字来自厂商自评，评估自己的技术选型时最好用自己的文档跑一遍 PageIndex-OSS-Benchmark 这类相对中立的测试集，而不是直接照单全收。

---

© 2026 Author: Mycelium Protocol. 本文采用 CC BY 4.0 授权——欢迎转载和引用，须注明作者姓名及原文链接，不得去除署名后以原创发布。

TL;DR

PageIndex skips vector databases and chunking entirely, generating a tree-structured table of contents for each document instead and letting an LLM reason through that tree the way a person flips through a report. Created in April 2025, the project now has 35,354 stars and 3,115 forks, with releases still shipping in August (a local SDK mode and PageIndex Flash, seconds-fast tree generation, both landed this month) — this isn’t a flash-in-the-pan Show HN project. Its core claim is sharp: similarity is not relevance. Vector retrieval finds passages that are semantically “similar” to a query, but in professional documents the passage that actually answers the question is often semantically dissimilar yet still relevant — exactly the failure mode vector RAG tends to hit on financial reports, legal contracts, and technical manuals.

The problem: similarity ≠ relevance

The standard RAG pipeline chunks text, embeds each chunk, stores the vectors, and at query time ranks by similarity for top-k. The implicit assumption is that semantically similar passages are the ones worth retrieving. PageIndex’s authors — inspired by AlphaGo’s tree search — argue that professional documents need reasoning, not matching: the answer to “what was the 2023 operating margin” in an annual report might sit in a footnote table that never mentions “operating margin” at all, semantically distant from the query, and vector similarity simply won’t surface it. Only a reasoning process that understands document structure and navigates it like a table of contents will.

The mechanism: build a tree index, then reason your way through it

Retrieval happens in two steps:

1. Build the tree index: the table-of-contents hierarchy is extracted directly from the PDF’s layout (no LLM needed); an LLM is used only to write per-node summaries and refine the tree. This step, called PageIndex Flash, shipped in August 2026 and takes seconds to a few minutes per document.
2. Reason through the tree: an LLM agentically searches the tree — the way a person opens a long report, checks the table of contents, and flips to the right section — instead of embedding the query and pulling nearest neighbors from a vector store.

The generated tree looks like an LLM-friendly table of contents, with page ranges and summaries attached:

{
  "title": "Financial Stability",
  "node_id": "0006",
  "start_index": 21,
  "end_index": 22,
  "summary": "The Federal Reserve ...",
  "nodes": [
    {
      "title": "Monitoring Financial Vulnerabilities",
      "node_id": "0007",
      "start_index": 22,
      "end_index": 28,
      "summary": "The Federal Reserve's monitoring ..."
    }
  ]
}

Minimal usage:

from pageindex import PageIndexClient

client = PageIndexClient(index="gpt-5.6-luna", chat="gpt-5.6-sol")
doc_id = client.submit_document("report.pdf")["doc_id"]
answer = client.chat("What was the 2023 operating margin, and where is it stated?", doc_id=doc_id)

Answers come with traceable page-level citations, instead of vector RAG’s common “it retrieved something, but I can’t tell you why.”

Compared to vector RAG

	Vector RAG	PageIndex
Index	Vector embeddings	Tree structure
Retrieval unit	Fixed-size chunks	Natural document sections
Retrieval method	Semantic similarity search	LLM reasoning over the tree
Traceability	Opaque, “vibe retrieval”	Traceable to page/line references
Context used	Query embedding only	Conversation history and domain knowledge can feed in
Per-query latency	Milliseconds	Seconds to minutes (multiple LLM calls)
Indexing cost	One-time embedding pass, cheap	~$0.001/page locally, also one-time

The headline benchmark is 98.7% accuracy on FinanceBench (a financial-document QA benchmark), versus roughly 50% for vector RAG — a result from VectifyAI’s own Mafin 2.5 evaluation. Separately, they published a more neutral PageIndex-OSS-Benchmark, running the out-of-the-box local mode against 62 questions over 34 PDFs (1,945 pages) drawn from MMLongBench-Doc-V2, with no extra tuning applied.

The Hacker News reception wasn’t unanimous applause

The project launched on Hacker News on August 27, 2025 as “Show HN: PageIndex – Vectorless RAG,” landing 192 points (verified against the Algolia API — some secondary write-ups online quote this as 432+, which is wrong). The technical pushback in the comments clusters around four points, worth including here rather than just repeating the vendor’s own framing:

• Scale concerns: one engineer said flatly, “I have a RAG built on 10,000+ docs knowledge base… I can’t see this tech scalable.” Another noted that while tree traversal is theoretically logarithmic, in practice “scaling will become problematic as the doc structure approaches the context limit of the LLM doing the retrieval.”
• Cost and latency didn’t disappear, they moved: vector databases retrieve in milliseconds at near-zero marginal query cost; PageIndex calls an LLM repeatedly during tree search, pushing latency to seconds or minutes. Even the creators frame this as a trade for “accuracy matters more than speed” use cases — it’s a real trade of latency and token spend for accuracy, not a free lunch.
• The “vectorless” framing was directly challenged: one commenter wrote, “Add structure with recursive LLM API calls… I don’t see where PageIndex is doing more than this” — every step, tree generation, summarization, and retrieval, still runs on an LLM. “Vectorless” more precisely means “no vector database,” not “no dependence on embedding-style models.”
• Missing third-party benchmarks: a retrieval-focused engineer flagged “a suspicious lack of any performance metrics on the many standard RAG/QA benchmarks… except for their highly fine-tuned MAFIN2.5 system” — the 98.7% FinanceBench figure currently comes primarily from VectifyAI’s own evaluation, with no independent third-party reproduction found so far.

Beyond vector RAG, commenters also weighed in on adjacent approaches: GraphRAG front-loads expensive entity extraction at index time, while PageIndex defers cost to query time — a different trade-off, not obviously a cheaper one. Others argued that many “vector RAG isn’t accurate” complaints trace back to poorly tuned hybrid setups (vector search plus BM25-style ranking) rather than a fundamental flaw in the vector approach itself.

None of this means the project isn’t worth using — it means the 98.7% headline number shouldn’t be the only thing you evaluate it on.

Local vs. Cloud

Capability	Local (this repo, open source)	Cloud (requires an API key)
Best for	Text-heavy PDFs, local workflows	Scanned, image-heavy, and large document collections
Indexing	Runs locally	Runs in PageIndex Cloud with production-grade OCR and image understanding
Storage	Local	Managed by PageIndex
Citation granularity	Page-level	Line-level
Image understanding	None	Yes
Multi-document scale	Manual	PageIndex File System (cross-document tree indexing)
MCP server	None	Yes

Who should look at this

Good fit: teams sitting on large volumes of long, structurally clear professional documents — financial reports, regulatory filings, technical manuals, medical literature — willing to trade some latency and token cost for accuracy, at a query volume that isn’t a high-throughput online service (hundreds of queries per second).

Not a fit / worth noting: collections in the tens of thousands of documents, or scenarios with hard latency requirements (live customer support, real-time Q&A), don’t yet have convincing public evidence that this approach holds up. The 98.7% headline number is a vendor self-evaluation — before committing to this as your retrieval architecture, run your own documents through something closer to neutral, like the PageIndex-OSS-Benchmark, rather than taking the number at face value.

---

© 2026 Author: Mycelium Protocol. Licensed under CC BY 4.0 — free to share and adapt with attribution. You must credit the author and link to the original; removing attribution and republishing as original is not permitted.