如果你做过 RAG(检索增强生成),一定踩过这个坑:PDF 里的表格被解析成一坨乱码、网页里的信息图直接消失、图文混排的布局被拆得七零八落。传统 RAG 的第一步——文本提取——恰恰是信息丢失最严重的环节。
UC Berkeley、Princeton、EPFL 和 Databricks 的研究团队最近开源了一个叫
PixelRAG 的项目,彻底抛弃了”先提取文字再检索”的流水线,转而直接对网页截图做嵌入和检索。在覆盖全维基百科的 3000 万张截图瓦片上测试,它在六个基准上比传统文本 RAG 准确率最高提升 18.1%,同时把 AI Agent 的 token 生成成本砍掉 10 倍。

PixelRAG 网站截图
核心洞察:文档是视觉的,检索也应该是
PixelRAG 的出发极其朴素:人类阅读网页时,看的是排版、表格、图片和样式,而不只是纯文本。 传统 RAG 把 HTML/PDF 解析成字符串,等于把一份设计精良的报纸强行打成流水账——表格被压扁、布局被销毁、视觉上下文全部丢失。而研究表明,正是这第一步的转换,导致了 RAG 系统绝大多数的错误答案。
PixelRAG 的解法简单粗暴:既然文档是视觉的,那检索也应该直接在像素层面进行。
四步流水线:从网页到答案
整个系统分为四个环节,全部围绕”像素”而非”文字”展开:
1. Render(渲染) 用 Playwright CDP 把网页渲染成截图瓦片(tiles),PDF 也走同样的路径。不解析 DOM,不提取文本,不做 OCR,原封不动保留页面的视觉呈现。
2. Embed(嵌入) 使用 Qwen3-VL-Embedding 把截图瓦片编码成 2048 维的向量。Qwen3-VL 是阿里开源的视觉语言模型,具备强大的文档理解和视觉感知能力,原生支持 256K token 上下文,可扩展至 100 万 token。
3. Index(索引) 向量存入 FAISS IVF 索引,规模达到 214 GB。目前索引覆盖了 828 万篇维基百科文章,生成 2810 万张截图瓦片。
4. Serve(检索) 通过 FastAPI 提供搜索服务,支持文本查询和图像查询两种模式。用户输入问题后,系统检索最相关的视觉瓦片,直接交给视觉语言模型阅读器生成答案。
为什么”像素级 RAG”更准?
传统文本 RAG 的信息损失发生在三个层面:
-
结构损失:表格被展平后,行列关系消失
-
视觉损失:图表、信息图、颜色编码的含义被丢弃
-
上下文损失:图文混排时的空间邻近关系被破坏
PixelRAG 通过保留原始视觉布局,让 VLM 阅读器同时获取文本和视觉信号。比如问”某张图表中 2023 年的增长率是多少”,传统 RAG 可能根本找不到这张图表,而 PixelRAG 直接检索到包含该图表的截图瓦片,VLM 可以”看到”图表并读取数据。
在六个问答基准上,PixelRAG consistently 击败文本 RAG,准确率增益高达 18.1%。更重要的是,由于检索到的视觉瓦片信息密度高、上下文完整,下游 VLM 生成答案所需的 token 数大幅减少,成本降低最高达 10 倍。
与 VisRAG、ColPali 的关系
PixelRAG 并非孤例。2024 年清华和阿里团队提出的 VisRAG 也走”直接嵌入文档图像”路线,在端到端任务上比传统文本 RAG 提升 20-40%。而 ColPali 则用 PaliGemma VLM 生成文档页的上下文视觉嵌入,通过 Late Interaction 机制实现高效检索。
PixelRAG 的独特之处在于:
局限与适用边界
PixelRAG 不是银弹,它的边界很清晰:
-
纯文本场景无优势:如果文档就是纯文字(如小说、论文正文),视觉检索的 overhead 不值得
-
需要 GPU 资源:Qwen3-VL 的嵌入计算和 VLM 阅读器都需要显卡
-
索引体积庞大:214 GB 的 FAISS 索引对存储和内存都是挑战
-
实时性受限:网页渲染+视觉嵌入的速度比纯文本解析慢
所以最适合的场景是:富含表格、图表、信息图、复杂布局的文档库——如金融报告、产品手册、维基百科、学术论文等。