RAG 不一定需要向量，但需要更好的文件切割
PageIndex 用結構化索引和推理取代向量化做 RAG，這不是否定向量，而是指出它不總是必要的。
向量化不是 RAG 的必要條件
PageIndex 這個項目的核心主張很直白：你不需要向量數據庫來做 RAG。取而代之，它用結構化的文件索引和推理模型的能力，直接從原始文本中檢索相關段落。
這個想法乍看有點反直覺。過去幾年，向量化幾乎成了 RAG 的標配——把文本轉成高維向量，用相似度搜索找到相關內容。但 PageIndex 的做法是：與其把文本壓縮成向量，不如把文件本身組織得更清楚，讓 LLM 的推理能力直接作用在結構化的索引上。
實際上在解決什麼問題
向量化有幾個隱含的成本：
- embedding 模型的精度瓶頸——某些領域知識，向量相似度捕捉得不夠精確
- 上下文丟失——把文本壓成向量的過程中，細粒度的結構信息會被平滑掉
- 基礎設施複雜度——需要維護向量數據庫、調優 embedding 模型、處理向量的更新
PageIndex 的假設是：如果你用 reasoning-capable 的模型（像 o1、Claude 3.5 Sonnet），它們本身就能理解文件的層級結構和邏輯關係。與其靠向量相似度做近似匹配，不如把文件索引做得足夠清晰，讓模型直接推理。
這個想法的邊界
我看到的限制條件：
- 依賴模型的推理能力——這意味著你需要用相對高端的模型。便宜的小模型可能推理不出來你要的內容。
- 文件結構化的成本轉移了，沒有消失——你不再調 embedding，但你需要把文件切割、標記、組織得更好。如果文件本身混亂，索引也救不了。
- 延遲和成本——推理模型通常比向量搜索慢得多。這對實時性要求高的場景可能是問題。
換句話說，這不是「向量化已死」，而是「向量化不是所有情況下的最優選擇」。
什麼時候值得試
我會在這些情況下考慮 PageIndex 這個思路：
- 文件結構相對規則（論文、報告、代碼文檔）——索引容易建立，推理也容易
- 精度比延遲更重要——你能接受查詢慢一點，但不能接受答案不準
- 領域知識很專業——向量模型可能不夠理解，但推理模型有機會
反過來，如果你的文件是非結構化的雜亂文本、用戶期望毫秒級響應、或者成本是第一考量，向量 RAG 還是更實際的選擇。
值得關注的點
這個項目目前還在早期。GitHub 上的代碼規模和文檔成熟度都還不算很完整。如果你想在生產環境用，需要自己做不少的工程化。但思路本身是清晰的，也指向了一個真實的問題：我們可能過度依賴向量化了。
更有趣的是，這個方向暗示了 RAG 的未來可能不是「更好的向量」，而是「更聰明的文件組織 + 更強的推理模型」的組合。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。