PageIndex：無需向量資料庫的推理式 RAG 革命

前言：當相似性不等於相關性

想像一下，你正在分析一份 200 頁的財務報告，需要找出「2023 年遞延資產的總價值」。你使用了最先進的 RAG 系統，它迅速返回了幾個包含「遞延資產」關鍵字的段落。看起來很完美，對吧？

但當你仔細檢查時，你發現這些段落只是提到了遞延資產的變化，而真正的總價值數據其實藏在「附錄 G」的一個表格中——而這個表格與你的查詢在語義上幾乎沒有相似性，傳統的向量檢索完全錯過了它。

這就是傳統 RAG 系統的根本問題：語義相似性（Semantic Similarity）≠ 真正的相關性（True Relevance）。

本週，一個名為 PageIndex 的開源專案在 GitHub 上獲得了 4,300+ stars，並在財務文件分析基準測試 FinanceBench 上達到了 98.7% 的準確率（SOTA），遠超傳統向量 RAG 約 50% 的表現。更令人驚訝的是，它完全不使用向量資料庫、不做 embedding、不進行語義相似度搜尋。

PageIndex 代表了一種全新的範式：從被動檢索（Passive Retrieval）到主動導航（Active Navigation）。本文將深入探討這個創新架構如何顛覆我們對 RAG 系統的理解。

一、RAG 的困境：為什麼向量檢索總是差那麼一點？

1.1 傳統向量 RAG 的工作原理

讓我們先快速回顧傳統 RAG 的標準流程：

預處理階段：

1. 將文件分割成固定大小的 chunks（例如 512 或 1000 tokens）
2. 使用 embedding 模型將每個 chunk 轉換為向量
3. 將向量存入向量資料庫（Chroma、Pinecone、Weaviate 等）

查詢階段：

1. 將使用者查詢轉換為向量
2. 在向量資料庫中搜尋語義相似的 chunks
3. 取回 top-k 結果
4. 將這些 chunks 餵給 LLM 生成答案

這個流程簡單、高效，在很多場景下運作良好。但在專業文件分析（財報、法律合約、技術規格書）場景中，它面臨五大根本性限制。

1.2 五大根本性限制

限制 1：查詢-知識空間不匹配（Query-Knowledge Mismatch）

向量檢索假設：「與查詢最相似的文本就是最相關的」。但這個假設經常不成立。

案例：

• 查詢：「2023 年 EBITDA 調整項目有哪些？」
• 向量檢索返回：所有提到 「EBITDA」 的段落
• 實際需要：定義 EBITDA 計算方式的特定章節，而不是所有提到這個詞的地方

問題在於，查詢表達的是意圖（intent），而不是內容（content）。多個章節可能用幾乎相同的措辭提到 EBITDA，但只有一個章節定義了精確的計算方式、調整項目或報告範圍。

限制 2：語義相似性 ≠ 真正的相關性

在專業領域文件中，許多段落共享近乎相同的語義，但在相關性上有天壤之別。

實際案例（來自 FinanceBench）：

查詢："What is the total value of deferred assets in 2023?"

向量 RAG 返回（高相似度但不相關）：
"The deferred assets increased by $2.3M compared to 2022..."

正確答案所在位置：
Appendix G, Table 5.3 → "Total deferred assets: $45.7M"

附錄 G 的表格與查詢語義相似度很低（只是一堆數字），但它才是真正的答案。向量檢索因為依賴語義匹配，直接跳過了這個關鍵資訊。

限制 3：硬分塊破壞語義完整性（Hard Chunking）

文件被強制切成固定大小的塊（例如 512 tokens），這經常在句子、段落或章節中間切斷，破壞了語義和上下文的完整性。

問題：

• 一個完整的論述被切成兩個 chunks
• 表格被切斷，失去行與列的對應關係
• 章節標題與內容分離，失去結構資訊

後果：LLM 收到的是碎片化的上下文，無法理解完整的邏輯流。

限制 4：無法整合對話歷史

每個查詢被獨立處理。檢索器不知道之前問過什麼、回答過什麼。

案例：

User: "What were the financial assets in 2023?"
System: [檢索並回答]

User: "What about liabilities?"
System: [重新獨立檢索，可能去錯章節]

理想情況下，系統應該知道繼續在同一份財報的相同部分尋找負債資料，而不是重新全域搜尋。

限制 5：無法處理文件內引用（In-Document References）

專業文件充滿內部引用：「見附錄 G」、「參考表格 5.3」、「如第 3.2 節所述」。

傳統向量 RAG 無法理解這些引用，因為：

• 引用文本（"see Appendix G"）與被引用內容（表格數據）語義不相似
• 沒有結構化的文件導航能力

除非進行額外的預處理（例如建立知識圖譜），否則這些關鍵連結會被錯過。

二、PageIndex 核心技術：推理式檢索的三大支柱

PageIndex 的核心洞察是：文件檢索應該是導航問題，而不是搜尋問題。

2.1 設計哲學：模擬人類專家的閱讀方式

當人類專家需要從長文件中找資訊時，他們不會：

1. ❌ 線性掃描每個段落
2. ❌ 計算每段與查詢的語義相似度
3. ❌ 取回 top-5 最相似的片段

他們會：

1. ✅ 查看目錄（Table of Contents），理解文件結構
2. ✅ 根據查詢意圖，推理哪個章節可能包含答案
3. ✅ 導航到該章節，提取相關資訊
4. ✅ 如果資訊不足，迭代到下一個相關章節
5. ✅ 遵循文件內引用（例如「見附錄 G」）

PageIndex 讓 LLM 複製這個過程。

2.2 支柱一：JSON 樹狀索引（Tree Index）

PageIndex 不使用向量資料庫，而是建立一個層次化的 JSON 樹狀結構來表示文件的「目錄」（Table of Contents）。

樹狀索引結構

{
  "id": "chapter_1",
  "title": "財務摘要",
  "description": "2023年整體財務表現概覽，包含資產、負債和現金流",
  "metadata": {
    "type": "chapter",
    "page_range": "1-15"
  },
  "children": [
    {
      "id": "section_1_1",
      "title": "資產概覽",
      "description": "流動資產與非流動資產的詳細分析",
      "metadata": {
        "type": "section",
        "page_range": "3-7"
      },
      "children": [
        {
          "id": "page_5",
          "title": "遞延資產明細",
          "description": "包含遞延資產總價值和年度變化",
          "metadata": {
            "type": "page",
            "page_number": 5
          },
          "content_reference": "page_5_content"
        }
      ]
    }
  ]
}

關鍵特性：

• 層次化：chapter → section → page，保留文件的邏輯結構
• 語義化：每個節點包含 description，幫助 LLM 理解內容概要
• 可導航：children 欄位允許遞迴遍歷
• 連結原始內容：content_reference 指向實際的文本/表格/圖片

2.3 支柱二：In-Context 索引（In-Context Index）

這是 PageIndex 與傳統向量 RAG 的根本差異。

In-Context Index 的優勢：

• LLM 可以「看到」整個文件結構
• 可以進行上下文推理（"這個查詢通常在財報的哪個部分？"）
• 可以動態調整導航策略（"這章節資訊不足，去附錄看看"）

2.3 支柱三：推理式迭代檢索流程

PageIndex 使用一個迭代推理循環來檢索資訊：

1. 讀取目錄（ToC）
   ↓
2. 根據查詢意圖，推理最可能包含答案的章節
   ↓
3. 導航到該章節，提取相關資訊
   ↓
4. 評估：資訊是否充分？
   ├─ 否 → 回到步驟 1，選擇下一個章節
   └─ 是 → 進入步驟 5
   ↓
5. 生成完整答案

關鍵點：

• 推理驅動：LLM 不只是匹配，而是思考「哪裡最可能有答案」
• 迭代式：如果一次檢索不夠，可以繼續導航
• 上下文感知：整合對話歷史，知道之前查詢過什麼

三、技術實作：快速上手 PageIndex

3.1 安裝與基本設置

# 安裝 PageIndex
pip install pageindex

# 或從源碼安裝
git clone https://github.com/VectifyAI/PageIndex.git
cd PageIndex
pip install -e .

3.2 建立文件索引

from pageindex import PageIndexBuilder

# 初始化索引建構器
builder = PageIndexBuilder()

# 從 PDF 建立索引
doc_index = builder.build_from_pdf(
    file_path="financial_report_2023.pdf",
    extract_tables=True,  # 提取表格
    extract_images=False,  # 不提取圖片
    chunk_strategy="section"  # 按章節分塊，而非固定大小
)

# 儲存索引
doc_index.save("financial_report_index.json")

索引建構策略：

• chunk_strategy="section"：按語義完整的章節分塊，而非任意切割
• extract_tables=True：保留表格結構，這對財務文件至關重要
• 自動生成每個節點的 description（使用 LLM 總結）

3.3 推理式檢索與查詢

from pageindex import PageIndexRetriever
from openai import OpenAI

# 載入索引
doc_index = PageIndex.load("financial_report_index.json")

# 初始化檢索器
retriever = PageIndexRetriever(
    index=doc_index,
    llm=OpenAI(api_key="your-api-key"),
    max_iterations=5  # 最多迭代 5 次
)

# 執行查詢
query = "What is the total value of deferred assets in 2023?"

result = retriever.retrieve(
    query=query,
    return_reasoning_path=True  # 返回推理路徑
)

# 檢視結果
print("Answer:", result.answer)
print("\nReasoning Path:")
for step in result.reasoning_path:
    print(f"  → {step.node_title} (confidence: {step.confidence})")
print("\nRetrieved Content:")
print(result.content)

輸出範例：

Answer: The total value of deferred assets in 2023 is $45.7M.

Reasoning Path:
  → Chapter 1: Financial Summary (confidence: 0.85)
  → Section 1.2: Deferred Assets Overview (confidence: 0.92)
  → Reference: See Appendix G, Table 5.3 (confidence: 0.95)
  → Appendix G: Statistical Tables (confidence: 0.98)

Retrieved Content:
[Page 5] Deferred assets increased by $2.3M...
[Appendix G, Table 5.3]
| Year | Deferred Assets |
|------|-----------------|
| 2023 | $45.7M          |
| 2022 | $43.4M          |

3.4 處理對話歷史

# 初始化對話
conversation = PageIndexConversation(retriever=retriever)

# 第一輪查詢
response1 = conversation.query("What were the financial assets in 2023?")
print(response1.answer)

# 第二輪查詢（系統知道上下文）
response2 = conversation.query("What about liabilities?")
# 系統會自動在同一章節或相關區域尋找負債資料

# 檢視完整對話歷史
print(conversation.get_history())

四、深度分析：PageIndex vs 傳統 RAG

4.1 FinanceBench 基準測試：98.7% vs 50%

FinanceBench 是專門測試財務文件理解能力的基準測試，包含複雜的多跳推理（multi-hop reasoning）任務。

測試案例：

Document: Federal Reserve Annual Report (200+ pages)
Question: "What is the total value of deferred assets?"

挑戰點：
- 主要章節只提到"變化量"（$2.3M增長）
- 總價值在 Appendix G 的表格中
- 文本中有引用："See Appendix G for detailed information"

結果對比：

為什麼 PageIndex 成功了？

1. 讀取引用：看到 "See Appendix G"
2. 理解意圖：需要的是總價值，不是變化量
3. 導航到附錄：使用樹狀索引找到 Appendix G
4. 提取表格數據：從 Table 5.3 取得正確數字

這是傳統向量檢索無法做到的，因為它不理解文件結構和引用關係。

4.2 技術 Trade-offs 分析

PageIndex 的優勢

PageIndex 的限制

4.3 與其他 RAG 方案的對比

五、台灣應用場景與實踐建議

5.1 高價值應用場景

1. 財務報告分析

• 痛點：上市公司年報動輒 100-300 頁，分析師需快速定位關鍵財務指標
• PageIndex 優勢：準確追蹤表格數據、遵循附錄引用、理解會計結構
• 台灣案例：證券分析、投資研究、財務顧問

2. 法律合約審閱

• 痛點：合約條款互相引用（"如第 3.2 條所述"），需理解條款間的邏輯關係
• PageIndex 優勢：追蹤條款引用、保留合約結構、可審計推理路徑
• 台灣案例：法律事務所、企業法務、合規審查

3. 技術規格書與專利文件

• 痛點：技術文件高度結構化，圖表、公式、附錄密切關聯
• PageIndex 優勢：保留技術文件的層次結構、連結圖表與說明
• 台灣案例：半導體產業、製造業、研發部門

4. 醫療病歷與臨床指南

• 痛點：病歷結構複雜（主訴、病史、檢查、診斷、治療），需精準定位
• PageIndex 優勢：理解醫療文件結構、追蹤檢查報告引用
• 台灣案例：醫院資訊系統、臨床決策支援

5.2 中文文件處理注意事項

PageIndex 原生支援多語言，但處理繁體中文時需注意：

# 使用支援中文的 LLM
retriever = PageIndexRetriever(
    index=doc_index,
    llm=OpenAI(model="gpt-4"),  # 或 Claude, Gemini
    language="zh-TW"  # 指定繁體中文
)

# 建立索引時優化中文分塊
builder = PageIndexBuilder(
    tokenizer="cl100k_base",  # OpenAI tokenizer，支援中文
    chunk_strategy="semantic",  # 語義分塊優於固定長度
    min_chunk_tokens=200,  # 中文字元密度高，可降低門檻
    preserve_structure=True  # 保留中文標點符號的段落結構
)

5.3 實務建議：何時使用 PageIndex？

使用 PageIndex 的場景

✅ 文件特徵：

• 長文件（50+ 頁）
• 高度結構化（有清晰的章節層次）
• 包含大量表格、圖表、附錄
• 有內部引用（"見第 X 章"、"參考附錄 Y"）

✅ 任務特徵：

• 需要精準答案（錯誤成本高）
• 多跳推理（需要整合多個章節的資訊）
• 需要可審計性（說明答案來源）
• 重複查詢（同一份文件會被多次分析）

不使用 PageIndex 的場景

❌ 文件特徵：

• 短文件（<10 頁，可直接放入 context window）
• 無結構（如聊天記錄、社群貼文）
• 純語義搜尋（找相似內容，而非精準答案）

❌ 任務特徵：

• 跨大量文件的廣泛搜尋（數百份文件）
• 延遲敏感（需要毫秒級回應）
• 成本敏感（無法負擔多次 LLM 調用）

混合架構建議

對於大型系統，可以組合多種技術：

階段 1：跨文件檢索（向量 RAG）
  → 從 1000 份文件中找出最相關的 3 份

階段 2：單文件精準分析（PageIndex）
  → 對這 3 份文件分別進行推理式檢索

階段 3：結果綜合（LLM）
  → 整合多份文件的精準答案

六、RAG 演進趨勢：從被動檢索到主動推理

6.1 RAG 架構的三個時代

6.2 Agentic RAG：LLM 掌控檢索過程

PageIndex 是 Agentic RAG 運動的一部分。我們已經在程式碼領域看到這個趨勢：

• Claude Code：不使用向量檢索，而是讓 LLM 使用工具（grep, find, llms.txt）主動探索程式碼庫
• Cursor：類似的 agentic 方法，LLM 決定要讀哪些檔案
• PageIndex：將這個概念推廣到通用文件檢索

核心原則：

不要預計算「什麼與什麼相似」，而是讓 LLM 在推理時決定要去哪裡找。

6.3 向量資料庫的未來角色

PageIndex 的成功不代表向量資料庫已死，而是它們的定位會改變：

未來趨勢：向量資料庫會從「LLM 的預設資料庫」變成「特定場景的專用工具」。

七、總結與行動建議

7.1 關鍵 Takeaways

1. 核心洞察：語義相似性 ≠ 真正的相關性，推理式檢索在專業文件上大幅優於向量檢索
2. 技術創新：樹狀索引 + In-Context 推理 + 迭代導航 = 模擬人類專家閱讀方式
3. 適用場景：長文件、高結構化、高錯誤成本、多跳推理、可審計需求
4. 限制認知：延遲高、成本高、不適合大規模跨文件語義搜尋
5. 產業影響：Agentic RAG 趨勢正在興起，LLM 從被動接收轉向主動導航

7.2 給台灣開發者的建議

短期行動（立即可做）

1. 實驗評估：

   • 在你的專業文件場景（財報、合約、規格書）測試 PageIndex
   • 與現有的向量 RAG 系統對比準確率
   • 使用 FinanceBench 或自建測試集評估

2. 混合架構：

   • 不要完全拋棄向量 RAG
   • 設計兩階段檢索：向量初篩 + PageIndex 精準分析

3. 中文優化：

   • 測試繁體中文文件的索引品質
   • 調整分塊策略以適應中文語義單位

中期規劃（3-6 個月）

1. 專業領域定制：

   • 針對你的產業（金融、法律、醫療）優化索引結構
   • 建立領域特定的描述生成提示詞
   • 累積高品質的測試集

2. 成本優化：

   • 實驗更便宜的模型（GPT-4o-mini, Claude Haiku）
   • 設計索引快取機制，避免重複建構
   • 混合使用：高價值查詢用 PageIndex，簡單查詢用向量

3. 產品整合：

   • 將 PageIndex 整合進現有的分析工具
   • 設計使用者介面展示推理路徑（增強可解釋性）

7.3 延伸資源

官方資源

• GitHub: https://github.com/VectifyAI/PageIndex
• 官方部落格: https://pageindex.ai/blog
• FinanceBench 基準測試: https://github.com/patronus-ai/financebench

學術論文

• ICLR 2026 論文（關於推理式檢索的理論基礎）
• Mafin 2.5 系統論文（98.7% 準確率的完整技術細節）

相關工具

• Claude Code: https://docs.anthropic.com/claude/docs/claude-code
• Graph RAG (Microsoft): https://github.com/microsoft/graphrag
• LlamaIndex (傳統 RAG): https://www.llamaindex.ai

台灣技術社群

• AI Taiwan (Facebook 社團)
• TWLLM (台灣大型語言模型討論群)
• g0v 零時政府（開源文件分析專案）

結語

PageIndex 不只是一個技術創新，它代表了我們思考 AI 系統的範式轉移：從工具使用者（Tool User）到主動推理者（Active Reasoner）。

當我們給 LLM 更多的結構化上下文、更清晰的導航能力，它們就能展現出接近人類專家的文件理解能力。這不是簡單的準確率提升，而是系統能力的質變。

對於台灣的技術社群來說，這是一個絕佳的機會：

• 金融科技可以建構更可靠的財報分析工具
• 法律科技可以開發精準的合約審閱系統
• 醫療資訊可以實現更安全的臨床決策支援

RAG 的下一個十年，將是推理的十年。PageIndex 只是開始。

關鍵字：RAG, PageIndex, 向量資料庫, LLM, 推理式檢索, AI 系統, 文件檢索, 機器學習, Agentic RAG, 財務分析

字數統計：約 9,500 字

授權：本文基於 MIT 授權的 PageIndex 專案撰寫，遵循開源精神