伯克利开源 PixelRAG：不把文档解析成文字，而是渲染成截图直接搜

在当前的 AI 应用生态中，为大模型提供外部知识检索已经是非常成熟的技术范式。在标准的 RAG（检索增强生成）流程中，文档解析是必不可少的一环：无论是网页还是 PDF，都需要先被解析成纯文本，然后进行切块、向量化、存储检索。然而，这一步骤存在一个被长期忽视的问题——文档中的表格、图表、排版结构等关键信息，在文本化的过程中往往会被「碾平」甚至完全丢失。

概述

Berkeley 团队近日开源的 PixelRAG 项目，尝试从根源上解决这一痛点。其核心思路非常直观：既然解析成文字会丢失信息，那就不解析了——直接把文档渲染成截图，对图片进行检索。这条技术路径的改变，使得所有原本长在版面上的信息都能完整保留，检索返回的是原始截图，而非被解析破坏的文字片段。

技术实现原理

PixelRAG 的技术链路分为索引构建和查询两个阶段。在索引构建阶段，文档（网页或 PDF）首先通过 Chrome/Playwright 渲染为截图切片，然后使用 Qwen3-VL-Embedding-2B 视觉编码模型将图片转化为向量。为了适应截图数据的特性，作者对基座模型进行了 LoRA 微调。最终，向量存储在 FAISS（默认）或 Qdrant 中。在查询阶段，问题同样被编码为向量，在图片向量空间中进行相似度匹配，返回最相关的截图而非文字段落，由多模态模型直接从图片中读取答案。

以图搜图的潜力

由于查询向量和图片向量处于同一向量空间，PixelRAG 天然支持「以图搜图」功能。用户可以直接提交一张图片作为查询条件，系统会返回语义或视觉相似的其他截图。此外，项目还提供了预构建的 828 万个维基百科页面截图索引（约 217GB），托管在公共 API 上，用户可以直接调用而无需自行渲染和建库。

实践要点与局限

部署方面，PixelRAG 需要 Python 3.10+ 环境，以及系统中的 Chrome/Chromium（可由 Playwright 自动安装）。在 Apple Silicon Mac 上可通过 MPS 加速，Linux 环境则需要 CUDA 支持。根据官方测试，一份示例 PDF 的建索引时间在 M 系列芯片上约 3 分钟，GPU 环境下约 1 分钟。值得注意的是，由于检索返回的是截图而非文字，负责生成答案的后端模型必须具备多模态能力，纯文本模型无法直接接入。

如有侵权，请联系删除。