ColParse：文件檢索儲存量砍 95%，效果還更好

做過 RAG 的人大概都碰過這個問題：文件不只有文字，還有表格、圖表、多欄排版，你的 retrieval 系統真的「看懂」這些版面了嗎？Multi-vector retrieval（像 ColPali 那類方法）確實能處理視覺文件，但存儲成本是個大坑。一頁文件可能要存上千個 embedding token，規模一放大就爆掉了。港科大和阿里雲的團隊提出了 ColParse，用一個很直覺的想法把儲存需求砍掉超過 95%，而且效果還變好了。

🔍 Multi-vector 的兩難

Visual Document Retrieval（VDR） 這個領域目前的主流架構是 multi-vector，也就是一頁文件不是編成一個向量，而是編成一組向量，每個 patch 或 token 都有自己的 embedding。這樣做的好處是能捕捉到細粒度的視覺和文字資訊，在 retrieval 準確度上很強。

問題是：一頁文件動輒產生數百到上千個向量，儲存成本直接起飛。

現有的優化方案大概分三條路：embedding merging（合併相鄰向量）、pruning（丟掉不重要的向量）、abstract tokens（用少量 learnable token 做壓縮）。但這三條路都有同一個毛病，壓縮的時候沒考慮文件的版面結構。你把一個表格的向量跟旁邊段落的向量合在一起，語義就混掉了。

🛠️ ColParse 的核心設計

ColParse 的想法其實很直覺：既然文件有明確的版面結構（標題、段落、表格、圖片），為什麼不直接按照 layout 來切，每個區塊各自生成一個 embedding？

具體做法分三步：

• 第一步，用 document parsing model 把頁面切成幾個語義區塊（sub-images）。這不是隨便切 grid，而是根據版面分析結果來切，所以一個表格就是一個區塊，一段文字就是一個區塊。
• 第二步，每個 sub-image 各自通過 vision encoder 生成 embedding。因為區塊數量很少（通常就幾個到十幾個），向量數量直接從上千降到個位數。
• 第三步，再加一個全頁面的 global embedding 來捕捉整體語境，最後把 sub-image embeddings 跟 global embedding 融合成一組 compact multi-vector representation。

這個設計最聰明的地方在於：它不是在壓縮後的向量空間裡做近似，而是在壓縮之前就用 layout 資訊決定了「什麼該跟什麼放在一起」。語義邊界是由 document parser 定義的，不是由數學方法硬湊的。

💡 數字說話和工程考量

儲存需求降低超過 95%

這個數字在多個 benchmark 和不同 base model 上都成立，不是只挑一個最好的 case 報。而且在大多數 benchmark 上，ColParse 的 retrieval 效果不只沒掉，還有明顯提升。

我覺得這很合理。原本的 multi-vector 方法把每個 patch 都當獨立單位編碼，其實引入了大量冗餘（一段純白背景也要編碼）。ColParse 等於是做了一次「語義感知的降維」，留下的都是真正有資訊量的區塊。

不過有幾個工程面的考量值得注意：

• 它依賴 document parsing model 的品質。如果版面分析切錯了（比如把表格切成兩半），下游的 embedding 就會出問題。好消息是現在的 document parsing 模型已經相當成熟，但遇到非標準排版（手寫筆記、自由格式的簡報）可能還是會踩坑。
• 多了一個 parsing 的前處理步驟，indexing 的延遲會增加。不過因為這是離線操作，對 query-time 沒影響，而且換來的是 95% 的儲存節省，這筆帳怎麼算都划算。
• 這個方法跟 base model 是解耦的。論文裡用了不同的 vision encoder 都有效，代表你可以隨著模型演進直接換底座，不用重新設計壓縮策略。

對於正在做文件 RAG 的團隊，我覺得 ColParse 提供了一個很有說服力的方向：與其在向量空間裡硬壓縮，不如在輸入端就用結構化的方式減少冗餘。95% 的儲存節省對大規模部署來說是實打實的成本差異，這不是實驗室裡的小優化。

如果你的場景是處理大量版面複雜的文件（合約、財報、學術論文），這篇值得認真看一下。

論文連結

做過 RAG 的人大概都碰過這個問題：文件不只有文字，還有表格、圖表、多欄排版，你的 retrieval 系統真的「看懂」這些版面了嗎？Multi-vector retrieval（像 ColPali 那類方法）確實能處理視覺文件，但存儲成本是個大坑。一頁文件可能要存上千個 embedding token，規模一放大就爆掉了。港科大和阿里雲的團隊提出了 ColParse，用一個很直覺的想法把儲存需求砍掉超過 95%，而且效果還變好了。

🔍 Multi-vector 的兩難

Visual Document Retrieval（VDR）這個領域目前的主流架構是 multi-vector，也就是一頁文件不是編成一個向量，而是編成一組向量，每個 patch 或 token 都有自己的 embedding。這樣做的好處是能捕捉到細粒度的視覺和文字資訊，在 retrieval 準確度上很強。

問題是：一頁文件動輒產生數百到上千個向量，儲存成本直接起飛。

現有的優化方案大概分三條路：embedding merging（合併相鄰向量）、pruning（丟掉不重要的向量）、abstract tokens（用少量 learnable token 做壓縮）。但這三條路都有同一個毛病，壓縮的時候沒考慮文件的版面結構。你把一個表格的向量跟旁邊段落的向量合在一起，語義就混掉了。

🛠️ ColParse 的核心設計

ColParse 的想法其實很直覺：既然文件有明確的版面結構（標題、段落、表格、圖片），為什麼不直接按照 layout 來切，每個區塊各自生成一個 embedding？

具體做法分三步：

第一步，用 document parsing model 把頁面切成幾個語義區塊（sub-images）。這不是隨便切 grid，而是根據版面分析結果來切，所以一個表格就是一個區塊，一段文字就是一個區塊。

第二步，每個 sub-image 各自通過 vision encoder 生成 embedding。因為區塊數量很少（通常就幾個到十幾個），向量數量直接從上千降到個位數。

第三步，再加一個全頁面的 global embedding 來捕捉整體語境，最後把 sub-image embeddings 跟 global embedding 融合成一組 compact multi-vector representation。

這個設計最聰明的地方在於：它不是在壓縮後的向量空間裡做近似，而是在壓縮之前就用 layout 資訊決定了「什麼該跟什麼放在一起」。語義邊界是由 document parser 定義的，不是由數學方法硬湊的。

💡 數字說話和工程考量

儲存需求降低超過 95%

這個數字在多個 benchmark 和不同 base model 上都成立，不是只挑一個最好的 case 報。而且在大多數 benchmark 上，ColParse 的 retrieval 效果不只沒掉，還有明顯提升。

我覺得這很合理。原本的 multi-vector 方法把每個 patch 都當獨立單位編碼，其實引入了大量冗餘（一段純白背景也要編碼）。ColParse 等於是做了一次「語義感知的降維」，留下的都是真正有資訊量的區塊。

不過有幾個工程面的考量值得注意：

第一，它依賴 document parsing model 的品質。如果版面分析切錯了（比如把表格切成兩半），下游的 embedding 就會出問題。好消息是現在的 document parsing 模型已經相當成熟，但遇到非標準排版（手寫筆記、自由格式的簡報）可能還是會踩坑。

第二，多了一個 parsing 的前處理步驟，indexing 的延遲會增加。不過因為這是離線操作，對 query-time 沒影響，而且換來的是 95% 的儲存節省，這筆帳怎麼算都划算。

第三，這個方法跟 base model 是解耦的。論文裡用了不同的 vision encoder 都有效，代表你可以隨著模型演進直接換底座，不用重新設計壓縮策略。

對於正在做文件 RAG 的團隊，我覺得 ColParse 提供了一個很有說服力的方向：與其在向量空間裡硬壓縮，不如在輸入端就用結構化的方式減少冗餘。95% 的儲存節省對大規模部署來說是實打實的成本差異，這不是實驗室裡的小優化。

如果你的場景是處理大量版面複雜的文件（合約、財報、學術論文），這篇值得認真看一下。

論文連結：https://arxiv.org/abs/2603.01666

#GenAI #RAG #DocumentRetrieval #Vision #MultiVector #ColPali