PixelRAG 圖解：為什麼「讓模型看截圖」會比解析文字更準、還更省 token

瀏覽次數: 3

如果你的 RAG（檢索增強生成）系統老是答錯，第一直覺通常是去調 LLM、換 embedding、改 chunk 切法。但來自 UC Berkeley SkyLab / BAIR / Berkeley NLP 的一項研究——PixelRAG（作者群包含 Matei Zaharia、Joseph E. Gonzalez、Sewon Min 等）——指出一個更前面的破口：把文件轉成純文字的那一步，本身就在製造錯誤。

它的主張很直白，一句話講完：

Search any document by how it looks, not just the text it contains.（用文件「長什麼樣子」來檢索，而不只是它的文字內容。）

本文大綱

問題：文字 parser 是 RAG 的隱形破口

傳統 RAG 的第一步，是把 PDF、簡報、網頁、掃描檔轉成純文字，再切 chunk、做向量檢索。問題是——表格的欄列對應、版面的視覺層次、圖表、infographic，這些資訊本來就藏在文件的「長相」裡。一旦壓成一維純文字，這些結構在第一步就流失了。

更麻煩的是：這一步幾乎從不在任何人的 eval 裡。你花大把力氣優化 retrieval recall 和 generation 品質，卻可能從沒量過「parser 解析正確率」這個真正的瓶頸。

解法：別轉文字，直接檢索「截圖」

PixelRAG 的做法是把文件渲染成截圖影像，然後直接在影像上做檢索與閱讀。視覺結構完整保留，閱讀的模型可以「看著圖」回答問題。

整條 pipeline 拆成 5 步：

1. RENDER — 文件 → 截圖 tiles

用官方的 pixelshot 工具（底層是 Playwright / Chrome DevTools Protocol，也支援 PDF）把網頁或文件渲染成截圖，再切成一塊塊 tile。這一步把「解析」換成「拍照」——不丟失任何視覺資訊。

2. EMBED — 截圖 → 向量

關鍵元件在這裡：一個 Qwen3-VL-Embedding-2B 模型，經過 LoRA 微調於截圖資料，把每張頁面影像編碼成向量。這個 embedding 空間讓「文字查詢」也能去比對「影像內容」——這正是視覺檢索能成立的核心。

3. INDEX — 建向量索引

影像向量存進 FAISS 索引。官方直接釋出了一個涵蓋 828 萬篇維基百科頁面的現成索引（base 版本約 217GB），也提供免設定、免 API key 的 hosted 端點可直接打。

4. RETRIEVE — 查詢 → 取回 tile

查詢可以是文字、也可以是圖片，用向量相似度取回最相關的頁面截圖 tile。注意這裡取回的是「影像」，不是文字片段。

5. READ — 視覺語言模型看圖作答

最後把取回的截圖餵給視覺語言模型（VLM），讓它直接從圖上把答案讀出來。表格裡的某個數字、圖表上的某條趨勢，模型是「看到」的，而不是先被 parser 壓成文字再猜。

效果：更準，而且 agent 場景 token 用量降一個量級

根據官方論文與報導的基準結果（這些是研究方回報的數字，非本站實測）：

準確率提升：在多個基準上勝過文字 RAG；即使在 SimpleQA、NQ-Tables 這類純文字 / 文字為主的題目上也更好，最高約 +18.1%。也就是說，視覺路徑不只贏在表格圖表，連傳統文字題都沒輸——這是最反直覺的一點。
token 成本約降 10×：在 agent 檢索場景，一次任務用約 360 萬 prompt token，相較文字檢索的約 3,750 萬——少了約一個量級。

成本真相：那個「降 10×」別誤會

這裡要誠實講清楚，因為很容易被誤讀：VLM 讀一張截圖，單筆 token 其實比讀一段純文字更貴——一張截圖 tile 常是幾百到上千個視覺 token，一段文字 chunk 大多只有 100–500。所以「省 token」絕不是因為「圖比文字便宜」。

那為什麼總量還能降一個量級？因為那是 agent 檢索場景的數字：文字 RAG 在 agentic 迴圈裡很容易過度抓取——多輪檢索、query 擴展、把整頁文字塞進 context，token 就滾到 3,750 萬。PixelRAG 取回的是資訊密度高的整頁截圖，常常一張就含表格＋上下文，用更少筆、更少輪就答完，所以總量低，即使每筆更貴。

一句話：省的是「更少、更密的檢索」，不是「圖比文字便宜」。這個 10× 屬於特定 benchmark，別外推成每個 query 都省 10×。

該用 PixelRAG 嗎？看文件類型

把所有 RAG 一窩蜂換成 PixelRAG 並不合理。理性的分界就一句：轉成文字會不會失真。

適合用（視覺結構＝資訊本身，轉文字會明顯失真）

設計圖、電路圖、格局圖、工程圖
複雜表格、財報、規格書、報表
資訊圖表、簡報、掃描件、版面複雜的 PDF
→ 文字 RAG 本來就會錯、或要塞超大 context 才勉強答對；視覺路徑的準確率增益足以抵掉 VLM 較貴的單筆成本。

先別換（傳統文字 RAG 仍更好）

純文字、無版面的長文（法條、合約、純 prose）——文字 chunk 又便宜又準。
單筆成本 / 延遲極敏感、量大且文件單純的場景。

對工程團隊意味什麼

把「parser 解析正確率」加進你的 eval。 如果你只測 retrieval recall 和 generation 品質，很可能在優化錯的環節。先量出 parser 這層到底吃掉多少準確率。
用文件類型決定路徑，而不是一刀切。 版面/視覺型的文件走 PixelRAG，純文字長文留給文字 RAG——對的工具用在對的地方。

短期內它不會取代所有 text-based RAG，但「文件一定要先轉成文字」這個預設，已經被打破了。

彩蛋：它也是一個 Claude Code 外掛

PixelRAG 的 renderer 同時包成了 Claude Code 外掛 pixelbrowse——讓 Claude 不再抓原始 HTML，而是用 pixelshot 截圖頁面、直接讀圖，於是它能像人一樣看到圖表、版面與表格：

pip install pixelrag
claude plugin marketplace add StarTrail-org/PixelRAG
claude plugin install pixelbrowse@pixelrag-plugins
# 然後：claude -p "screenshot https://news.ycombinator.com and summarize the top stories"

原始碼（主要來源）：github.com/StarTrail-org/PixelRAG ｜線上試用：pixelrag.ai
研究團隊：UC Berkeley、Princeton、EPFL、Databricks 跨單位合作（work done at Berkeley SkyLab / BAIR / Berkeley NLP）。作者 Yichuan Wang、Zhifei Li、Zirui Wang、Paul Teiletche、Lesheng Jin；指導 Matei Zaharia（Databricks CTO）、Joseph E. Gonzalez、Sewon Min。
延伸報導：VentureBeat — PixelRAG beats text parsers on accuracy and cuts AI agent token costs 10x