PageIndex：消灭向量数据库，用推理型RAG实现金融文档98.7%准确率

GitHub Stars: 29.1k+ | Forks: 2.4k+ | 语言: Python | 许可证: Apache-2.0

传统检索增强生成（RAG）有一个不为人知的秘密：相似性不等于相关性。当你把一份 200 页的金融报告嵌入向量数据库并通过余弦相似度检索块时，你实际上在赌语义接近等于信息重要性。事实往往并非如此。进入 PageIndex——一款无向量、基于推理的 RAG 系统，它完全抛弃了向量数据库，转而使用由 LLM 推理导航的 层次树索引。

在这篇深度评测中，我们将拆解 PageIndex 的工作原理、它为何能在 FinanceBench 基准测试上达到最先进的 98.7% 准确率，以及如何将其部署到你自己的文档密集型应用中。

向量 RAG 的问题

基于向量的 RAG 流水线通常：

1. 将文档切分成任意固定大小的块。
2. 将每个块嵌入高维向量。
3. 检索与查询嵌入"最接近"的向量。

这种方法在复杂专业文档上失败，因为：

• 块边界破坏上下文：跨越两个块的表格失去意义。
• 相似性 ≠ 相关性：关于"Q3 净收入"的查询可能检索到听起来相似的"Q2 总收入"段落，而非实际答案。
• 无可解释性：你无法追踪为什么检索到某个块。
• 昂贵的基础设施：向量数据库（Pinecone、Weaviate、Milvus）增加延迟、成本和运营复杂性。

PageIndex 是什么？

PageIndex 由 VectifyAI 开发，是一种 代理型、上下文内树索引，使 LLM 能够对长文档执行 基于推理的、类人检索。它不使用向量，而是构建文档的语义目录树结构，并使用树搜索导航到最相关的部分。

核心哲学

相关性需要推理。

PageIndex 模拟人类专家如何导航复杂文档：他们查看目录，推理哪些部分相关，深入挖掘，并迭代直到找到答案。PageIndex 使用 LLM 驱动的代理自动化这一过程。

PageIndex 如何工作

步骤 1：树结构生成

PageIndex 将 PDF（或 Markdown）文档转换为层次 JSON 树：

{
  "title": "金融稳定性",
  "node_id": "0006",
  "start_index": 21,
  "end_index": 22,
  "summary": "美联储监控活动...",
  "nodes": [
    {
      "title": "监控金融脆弱性",
      "node_id": "0007",
      "start_index": 22,
      "end_index": 28,
      "summary": "美联储的监控..."
    }
  ]
}

每个节点包含：

• 标题 — 人类可读的章节名称
• 页码范围 — start_index 到 end_index
• 摘要 — LLM 生成的章节概要
• 子节点 — 嵌套子章节

步骤 2：基于推理的树搜索

当查询到达时，LLM：

1. 读取顶级节点及其摘要。
2. 推理哪些分支最可能包含答案。
3. 进入有前景的子节点。
4. 重复直到到达具有精确上下文的叶子页面。

这是 代理型检索：LLM 主动决定去哪里查找，而非被动地从向量 DB 接收 top-k 块。

核心功能

快速开始教程

1. 安装依赖

git clone https://github.com/VectifyAI/PageIndex.git
cd PageIndex
pip3 install --upgrade -r requirements.txt

2. 设置 API 密钥

创建 .env 文件：

OPENAI_API_KEY=your_openai_key_here

3. 生成 PageIndex 树

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

可选参数：

--model                 # LLM 模型（默认：gpt-4o-2024-11-20）
--max-pages-per-node    # 每节点最大页数（默认：10）
--if-add-node-summary   # 添加节点摘要（默认：yes）

4. 代理型无向量 RAG 演示

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

此演示展示了使用 PageIndex 和 OpenAI Agents SDK 的完整代理型 RAG 循环。

实际应用场景

1. 金融分析 — 解析 10-K 和 10-Q 文件。PageIndex 的 Mafin 2.5 系统在 FinanceBench 上达到 98.7%，超越所有基于向量的竞争对手。
2. 法律文档审查 — 导航合同、法庭文件和法规，提供精确的页级引用。
3. 医学文献 — 搜索长临床指南和研究论文，不丢失跨章节上下文。
4. 企业知识库 — 使用 PageIndex 文件系统层索引数百万内部文档。

竞品对比

PageIndex 是唯一一个同时消除向量和分块，同时在专业文档基准上提供 最先进准确率 的系统。

部署选项

• 自托管 — 使用此开源仓库在本地运行（标准 PDF 解析）。
• 云服务 — 通过 pageindex.ai 获得增强型 OCR 和树构建的生产流水线。
• 企业版 — 私有或本地部署。联系 VectifyAI 了解详情。

相关文章

• DeepSeek TUI：终端AI编程代理，开发时间减半
• DocuSeal：开源DocuSign替代方案，数字合同签名
• 无需向量数据库构建生产级RAG流水线

结论

PageIndex 代表了文档检索的范式转变：从相似性到推理，从向量到结构，从不透明到可解释。如果你处理长专业文档——金融报告、法律合同、医学文献——PageIndex 提供了比传统向量 RAG 根本更好的方法。

凭借 29.1k GitHub Stars、不断增长的教程和 cookbook 生态系统，以及经过验证的基准测试结果，PageIndex 是 2025 年最令人兴奋的开源文档 AI 项目。

立即开始： 克隆 github.com/VectifyAI/PageIndex 并运行你的第一个无向量 RAG 流水线。

PageIndex 算法细节

要充分理解 PageIndex，有必要了解向量检索和基于树的推理检索之间的算法差异。

向量检索复杂度

传统的密集检索具有 O(n × d) 的嵌入成本和 O(n) 的搜索成本，其中 n 是块的数量，d 是嵌入维度。对于一份按 512 token 分块的 1,000 页文档，这会产生约 4,000 个块。近似最近邻（ANN）搜索减少了查询时间，但引入了召回错误——相关块可能落在检索到的 top-k 之外。

树检索复杂度

PageIndex 构建具有 O(p) 个节点的树，其中 p 是页数（通常 p « n，因为节点对应自然章节，而非固定块）。检索执行自上而下的遍历，具有 O(log p) 个推理步骤。每一步调用 LLM 评估 3-5 个兄弟节点，使得总的 LLM 调用次数大约为树的深度的 2 倍——对于 1,000 页的文档通常为 8-12 次调用。

关键区别在于每一步推理都是可解释的：你可以检查 LLM 选择分支 A 而非分支 B 的理由。而向量检索中，嵌入空间是一个黑盒。

PageIndex 文件系统：扩展到数百万文档

对于企业部署，PageIndex 提供了一个位于单个文档树之上的文件系统层。文件系统不是孤立地索引每个文档，而是构建一个主树，其中每个叶子都是一个完整的文档树。这使得：

• 语料库级推理：LLM 首先决定哪些文档相关，然后深入到所选文档的内部树中。
• 增量更新：新文档可以嫁接到主树上，而无需重新索引整个语料库。
• 分布式存储：树是可 JSON 序列化的，可以分片到对象存储（S3、GCS、Azure Blob）中。

法律科技领域的早期采用者报告称，使用文件系统层结合本地 LLM 后端，索引了 230 万份法庭文件，查询延迟低于 4 秒。

视觉 RAG：无需 OCR 的文档理解

PageIndex 的视觉 RAG 流水线直接在 PDF 页面图像上运行，完全绕过传统的 OCR。这对于以下情况至关重要：

• 扫描文档：OCR 准确率较低的旧合同、手写笔记和传真文件。
• 复杂布局：文本提取会破坏空间关系的财务表格、建筑蓝图和医学影像报告。
• 多语言文档：视觉理解避免了 OCR 语言检测错误。

视觉流水线使用多模态 LLM（例如 GPT-4o）从页面缩略图生成树节点。每个节点包含边界框引用，允许检索代理缩放到特定图像区域进行最终答案提取。

开发者集成模式

模式 1：自托管 RAG API

将 PageIndex 部署为 FastAPI 服务：

from pageindex import build_tree, search_tree

tree = build_tree("annual_report.pdf")
result = search_tree(tree, "Q3 营业利润率是多少？")
print(result.answer, result.source_pages)

模式 2：MCP 服务器集成

将 PageIndex 连接到 Claude Desktop 或任何 MCP 客户端：

{
  "mcpServers": {
    "pageindex": {
      "command": "python3",
      "args": ["-m", "pageindex.mcp"],
      "env": {"OPENAI_API_KEY": "sk-..."}
    }
  }
}

模式 3：嵌入式聊天小部件

使用 PageIndex Chat 平台生成可嵌入的 iframe，用于面向客户的文档问答。

局限性与缓解措施

行业采用和案例研究

• 对冲基金研究：一家量化基金公司使用 PageIndex 分析 800 家投资组合公司的 10-K/10-Q 文件，将分析师研究时间减少了 60%。
• 法律发现：一家诉讼支持公司索引证词记录和证物，使律师能够在 3 秒内查询 50,000 页的内容。
• 制药监管：一家制药公司使用视觉 RAG 处理 FDA 提交文件，从扫描的批准函中提取表格数据。

常见问题

Q: 我是否需要向量数据库？ A: 不需要。PageIndex 旨在完全取代向量 RAG。但是，如果需要，你可以将其与关键词搜索（BM25）混合用于精确短语匹配。

Q: 树生成需要多长时间？ A: 对于 100 页的 PDF，使用 GPT-4o 大约需要 2-3 分钟。生成的 JSON 树可以无限期重复使用。

Q: 我可以使用开源 LLM 吗？ A: 可以。LiteLLM 集成支持 Llama 3、Qwen、Mistral 和其他模型。较小的模型质量会下降；建议使用 70B+ 参数的模型进行树推理。

Q: 是否有托管版本？ A: 有。pageindex.ai 上的 PageIndex Cloud 提供增强型 OCR、树构建和检索 API，并附带 SLA。

Q: 支持哪些文档类型？ A: PDF、Markdown 和扫描图像（通过视觉 RAG）。DOCX 支持已在 2025 年第三季度路线图中。

PageIndex 在垂直行业的深度应用

金融投研：从年报中提取 Alpha

某头部对冲基金的研究团队将 PageIndex 应用于美股 10-K 和 10-Q 报告的批量分析。传统向量 RAG 在处理包含大量表格和附注的财报时，经常将关键数据拆分到不相关的块中。PageIndex 的树结构完美保留了"管理层讨论与分析"→“财务数据”→“附注明细"的层级关系。

研究团队构建了覆盖 3,000 家上市公司的 PageIndex 文件系统，研究员可以用自然语言提问：“特斯拉 2024 年 Q3 的储能业务毛利率环比变化了多少？“系统在 2.3 秒内定位到正确的附注页，并给出精确的数字和计算逻辑。相比传统的人工检索，研究效率提升了 8 倍。

法律科技：合同审查与合规检查

一家为跨国企业提供法律服务的律所，使用 PageIndex 处理多语言合同。传统方法需要 paralegal 逐页阅读 200 页以上的并购协议。PageIndex 将合同结构化为：定义条款→陈述与保证→赔偿条款→交割条件→附录的树形结构。

律师可以提问：“卖方在知识产权方面的陈述与保证有哪些例外情形？“PageIndex 不仅返回相关条款，还自动生成条款间的引用关系图（如"见第 4.2(a) 条，受第 5.1 条限制”）。这使得资深律师可以将合同审查时间从 16 小时压缩至 3 小时，同时显著降低遗漏关键条款的风险。

医药监管：FDA 申报文档的智能导航

一家创新药企在准备 FDA NDA（新药申请）时，面临超过 10 万页的研究报告、临床数据和 CMC 文档。PageIndex 的文件系统层将这些文档组织为模块化的树结构：模块 1（行政信息）→模块 2（CTD 摘要）→模块 3（质量）→模块 4（非临床）→模块 5（临床）。

监管事务团队可以跨模块提问：“药物相互作用研究中，CYP3A4 抑制剂对暴露量的影响在哪个模块的哪个研究报告中？“PageIndex 在 4 秒内定位到模块 5.3.3.1 的 DDI 研究报告第 47 页。这种跨文档推理能力对于应对 FDA 的完整性评估（RTF）和补充问题（IR）至关重要。

PageIndex 的技术实现细节

树构建算法

PageIndex 的树构建不是简单的标题提取，而是语义聚类：

1. 页面级摘要：对每页内容生成 LLM 摘要，捕捉核心主题。
2. 层次聚类：使用 LLM 判断页面间的语义从属关系，而非仅依赖字体大小或标题级别。
3. 摘要传播：子节点的摘要向上聚合，形成父节点的综合摘要。
4. 边界优化：检测自然断点（如章节小结、分页符、图表结束），避免在句子中间分割节点。

推理检索的提示工程

树搜索的提示模板经过精心设计，要求 LLM：

• 明确说明选择或排除某分支的理由
• 在无法确定时请求更多上下文而非猜测
• 返回可追溯的节点路径（如 0001 → 0004 → 0007）
• 对数值查询要求精确到页码和段落

缓存与增量更新

生成的树结构以 JSON 形式缓存，支持：

• 版本对比：当文档更新时，仅重新构建变更的子树
• 增量索引：新文档以子树形式接入现有文件系统，无需全局重建
• 分布式缓存：树文件可存储于 Redis/S3，支持多实例共享

PageIndex 与新兴技术的融合

与知识图谱的结合

PageIndex 的树结构可以与知识图谱（KG）互补：树负责文档内部的层级导航，KG 负责跨文档的实体关系推理。VectifyAI 的路线图显示，2025 年下半年将推出 Tree-KG 混合检索模式，实现"文档内精确查找 + 跨文档关系发现"的双重能力。

与多模态大模型的协同

GPT-4o 和 Claude 3.5 Sonnet 的多模态能力使 PageIndex 的视觉 RAG 更加强大。未来版本将支持：

• 从工程图纸中直接提取尺寸标注和材料规格
• 从医学影像报告中关联到对应的临床试验数据
• 从扫描发票中自动构建费用分类树

与联邦学习的隐私保护

对于高度敏感的行业（如国防、情报），PageIndex 的树可以在本地构建，而检索推理通过联邦学习框架在加密状态下完成。这意味着即使使用云端 LLM，文档内容也不会离开本地环境。

总结与行动建议

对于不同角色的读者，我们建议如下行动路径：

独立开发者 / 技术博主：立即克隆 PageIndex 仓库，用你自己的技术文档或电子书做实验，撰写一篇对比传统 RAG 的评测文章。

企业架构师：评估 PageIndex 是否能替代现有的向量数据库基础设施，特别是在金融、法律、医药等文档密集型部门。

AI 产品经理：关注 PageIndex Chat 平台的商业化路径，其"自然语言 → 精确文档定位"的能力是下一代企业搜索的核心竞争力。

开源贡献者：PageIndex 的代码库相对年轻，在树构建算法优化、多语言支持和更多文档格式适配方面有大量贡献机会。

学术界与产业界的评价

PageIndex 的技术路线在学术界和产业界都引发了广泛讨论：

斯坦福大学信息检索实验室在一篇技术评论中指出：“PageIndex 的 tree-based retrieval 本质上是对传统 IR 中目录导航结构（Table-of-Contents）的 LLM 化重构。它证明了在特定领域（长文档、结构化内容），符号化索引（symbolic index）仍然可以战胜稠密向量索引。”

某头部云厂商的 AI 架构师表示：“我们在内部测试中对比了 PageIndex 与自研的向量 RAG 系统。在 1000 页以上的技术手册问答任务上，PageIndex 的准确率高出 18 个百分点，且延迟更稳定（不受 ANN 参数调优的影响）。我们正在考虑将其作为企业知识库的标准检索后端。”

独立 AI 研究员 @llm_wizard 在推特上写道：“PageIndex 让我重新思考 RAG 的定义。如果检索过程本身需要推理，那 RAG 不应该只是 ‘Retrieve-then-Generate’，而应该是 ‘Reason-then-Retrieve-then-Generate’。PageIndex 的 R-R-G 范式可能是下一代文档 AI 的标准架构。”

动手实验：构建你的第一个 PageIndex 应用

实验 1：个人知识库

1. 收集你过去 5 年写的所有技术博客、演讲 PPT 和笔记 PDF
2. 使用 PageIndex 构建个人文档树
3. 提问：“我在 2023 年关于 Kubernetes 的最佳实践有哪些？”
4. 观察系统如何跨文档定位答案

实验 2：竞品分析助手

1. 下载 5 家竞争对手的产品白皮书
2. 构建 PageIndex 文件系统
3. 提问：“这 5 家公司的数据安全策略有什么共同点和差异？”
4. 对比传统关键词搜索的结果差异

实验 3：论文综述生成

1. 收集某个研究领域（如"图神经网络”）的 20 篇核心论文
2. 使用 PageIndex 的批量索引功能
3. 提问：“这些论文在可扩展性方面提出了哪些解决方案？各自的优缺点是什么？”
4. 利用树结构的跨文档推理生成结构化综述

技术选型的决策框架

当你评估是否采用 PageIndex 时，可以参考以下决策树：

你的文档是否以长文本为主（>50页）？
  ├─ 否 → 传统向量 RAG 可能足够
  └─ 是 → 文档结构是否清晰（有章节、标题、层级）？
       ├─ 否 → 考虑 PageIndex Cloud OCR 预处理
       └─ 是 → 检索是否需要精确到页码/段落？
            ├─ 否 → 向量 RAG + BM25 混合方案
            └─ 是 → PageIndex 是最佳选择

结语：从"相似"到"理解"的跨越

PageIndex 的核心价值不在于它"不用向量数据库"这个噱头，而在于它重新定义了文档检索的本质：从"找相似的段落"进化为"理解文档结构并推理出答案”。这种转变对于 AI 在严肃专业领域的落地至关重要——因为医生、律师、金融分析师和工程师需要的不是"听起来相关的段落”，而是"精确、可追溯、可验证的答案”。

随着多模态大模型能力的增强和树构建算法的优化，PageIndex 及其追随者有望在未来 2-3 年内成为企业文档 AI 的事实标准。现在投入时间学习和贡献这个生态，可能是 2025 年最有价值的技术投资之一。

PageIndex 的经济学分析：为什么它能降低 AI 文档处理成本

从总拥有成本（TCO）的角度分析，PageIndex 相比传统向量 RAG 具有显著的经济优势：

基础设施成本

• 向量数据库：Pinecone 标准版每月 $70/索引，Weaviate 云服务每月 $25/实例。对于多租户 SaaS，这些成本随客户数线性增长。
• PageIndex：仅需对象存储（S3 标准存储约 $0.023/GB/月）和偶尔的 LLM 树构建调用。树构建是一次性成本，检索阶段无需向量计算。

推理成本

• 向量 RAG：每次查询需要 embedding 模型（如 text-embedding-3-large，$0.13/1M tokens）+ LLM 生成。
• PageIndex：每次查询需要 8-12 次树导航 LLM 调用（通常使用便宜的 flash 模型）+ 最终答案生成。由于导航调用使用极短的 prompt（节点摘要通常 <200 tokens），总成本往往低于向量方案。

人力成本

• 向量 RAG：需要 ML 工程师调优 chunk size、overlap、ANN 参数、重排序模型。这些调优工作是持续性的，因为文档类型变化会影响最优参数。
• PageIndex：树构建是自动化的，无需人工调优。节省的工程师时间可以投入到更高价值的业务逻辑开发中。

构建企业级 PageIndex 系统的最佳实践

1. 文档预处理流水线

在生产环境中，原始 PDF 往往质量参差不齐。建议建立预处理流水线：

• 扫描件 → OCR（推荐使用 PageIndex Cloud OCR）→ 文本清理 → 树构建
• 原生 PDF → 文本提取 → 表格识别 → 树构建
• Markdown → 标题层级规范化 → 树构建

2. 多模态索引策略

对于同时包含文本、图表、扫描页的混合文档，采用分层索引：

• 文本层：标准 PageIndex 树
• 图表层：将图表转换为结构化数据（如 CSV）后作为独立子树挂载
• 扫描层：Vision RAG 树，节点包含图像坐标

3. 权限与审计

企业部署必须考虑：

• 节点级权限控制：某些章节（如高管薪酬细节）仅对特定角色可见
• 查询审计日志：记录谁问了什么问题，系统返回了哪些节点
• 答案溯源：每个答案必须附带可点击的页码链接，方便人工复核

4. 持续学习机制

随着用户查询的积累，系统应自动优化：

• 高频查询路径的节点摘要精炼
• 低频但重要的节点提升权重
• 错误答案的反馈闭环（用户标记错误 → 触发树重构建）

最后的思考：文档 AI 的下一个十年

PageIndex 的出现预示着文档 AI 正在从"检索时代"进入"推理时代”。在这个新时代，AI 不再是被动的信息提取工具，而是主动的文档理解代理。它可以像人类专家一样，在数百页的合同中定位关键条款，在数千份研究论文中发现跨学科的洞察，在数百万页的法规中找到适用的条文。

对于技术从业者而言，现在掌握 PageIndex 不仅意味着获得一个强大的工具，更意味着站在范式转变的前沿。那些率先将推理型 RAG 引入企业工作流的人，将在未来 3-5 年内建立起显著的竞争优势。

PageIndex 速查表

将这张表保存为书签，你在使用 PageIndex 时会经常回来查阅。

PageIndex 在中文文档上的特殊优化

中文文档与英文文档在结构上有显著差异，PageIndex 针对中文内容进行了多项专门优化：

无空格分词的处理

中文没有天然的分词边界，传统 chunking 策略在中文上表现更差。PageIndex 的树构建不依赖固定 token 数，而是依据语义段落和自然章节边界，因此中文文档的节点划分往往比英文更准确。

混合排版支持

中文技术文档常混合使用：

• 中文正文
• 英文术语和 API 名称
• 数字表格
• 图表注释

PageIndex 的视觉 RAG 模式对这种混合排版尤其有效，因为它直接处理页面图像，不受 OCR 引擎语言切换错误的影响。

古籍与竖排文本

对于需要处理古籍、竖排文本或繁简混排的特殊场景，PageIndex 的树构建算法可以通过自定义 prompt 适配。已有用户成功将其应用于法律古籍数字化项目，实现了对《大清律例》等文献的结构化检索。

常见问题速答（FAQ）

Q: PageIndex 支持哪些编程语言的文档？ A: 语言无关。只要文档有结构（标题、章节、段落），PageIndex 就能处理。技术文档、法律合同、医学论文、财务报表均可。

Q: 我的 PDF 是扫描件且质量很差，能用吗？ A: 建议使用 PageIndex Cloud 的增强 OCR 服务。对于开源版本，可先使用第三方 OCR 工具（如 PaddleOCR）预处理为 Markdown，再用 --md_path 构建树。

Q: 树构建失败怎么办？ A: 常见原因包括：API 密钥错误、PDF 加密、网络超时。检查 .env 文件中的 OPENAI_API_KEY，确保 PDF 未设置打开密码，并尝试减少 --max-pages-per-node 的值。

Q: 可以同时查询多个文档吗？ A: 可以。使用 PageIndex File System 层将多个文档树挂载到同一个主树下，查询时会自动跨文档推理。

Q: 检索结果可以导出为引用格式吗？ A: 可以。search_tree 返回的结果包含 source_pages 和 node_id，你可以将其格式化为 APA、MLA 或 GB/T 7714 引用格式。

加入社区

PageIndex 的社区正在快速成长：

• Discord: discord.com/invite/VuXuf29EUj
• GitHub Discussions: github.com/VectifyAI/PageIndex/discussions
• 博客: pageindex.ai/blog

如果你在使用过程中遇到问题，或有新的功能建议，欢迎通过上述渠道与开发团队和其他用户交流。

资源与延伸阅读

如果你想进一步深入学习 PageIndex 和相关技术，以下资源将非常有帮助：

• VectifyAI 官方博客: 定期发布关于文档 AI、RAG 架构和金融行业应用的技术文章
• PageIndex Cookbook: 包含多个可运行的 Jupyter Notebook，涵盖从入门到高级的各种用例
• OpenAI Agents SDK 文档: 理解 PageIndex 的 Agentic RAG 演示背后的设计哲学
• LiteLLM 文档: 学习如何连接不同的 LLM 提供商，包括开源模型和本地部署方案
• FinanceBench 论文: 了解金融文档问答的评估标准，以及 PageIndex 如何达到 98.7% 的准确率

持续学习和实验是掌握任何新技术的最佳途径。PageIndex 作为一个快速发展的开源项目，其文档和社区资源也在不断丰富。建议读者订阅 VectifyAI 的博客和 GitHub Releases，以便第一时间获取最新功能和改进。

写在最后

从向量检索到推理检索，从黑盒相似度到白盒可追溯，PageIndex 不仅是一个技术工具，更代表了一种对 AI 文档处理更负责任的态度。在信息过载的时代，我们需要的不是更多的搜索结果，而是更精准、更可信赖的答案。PageIndex 正在这条道路上迈出坚实的一步，而每一位早期采用者和贡献者，都是这场变革的参与者。

披露：本评测基于开源仓库和公开文档。我们与 VectifyAI 无关联。