你有没有想过，RAG 最大的敌人不是向量检索精度不够，而是在信息进入向量数据库之前，就已经被糟蹋得七七八八了？

伯克利最新开源的 PixelRAG，给出了一个让人有点瞠目结舌的答案：既然文本解析这条链路天生有漏洞，那就整条扔掉，直接用截图做检索。

不是”辅助用截图”，是完全替代文本的纯视觉 RAG 方案。它的 Logo 是一只黑猫抱着截图，Slogan 是”Web Screenshots Beat Text”——不是在谦虚。

论文数据：准确率比最强文本 RAG 高 18.1%，Agent 场景下 Token 消耗降到原来的十分之一。

先说结论：这不只是一个工程 trick，它触碰到了一个被绕开太久的底层问题。

传统 RAG 的信息损耗在哪发生的

要搞懂 PixelRAG 为什么有意义，得先把传统 RAG 的信息流仔细看一遍。

标准文本 RAG 的流程是这样：

  1. 拿到页面或文档内容（HTML 源码或 PDF）
  2. 把 HTML/PDF 转成纯文本
  3. 把长文本切块（chunking）
  4. 每块嵌入成向量，存到向量数据库
  5. 检索时向量相似度匹配，返回 topK 块

乍看没毛病，但这条链路在第 2 步就开始漏信息，到第 3 步漏得更猛。

第一个漏洞：文本解析天生丢结构

HTML 转纯文本这件事，从来就不是无损的。

一张表格，在 HTML 里是 <table><tr><td>，嵌套清晰，每个单元格的位置关系一眼就懂。转成纯文本之后，要么挤成一行，要么靠空格对齐。对于大模型来说，一个三列四行的表格，纯文本形式理解起来要比 HTML 形式难得多——更别说人类看起来就是一坨。

流程图更惨，直接蒸发。SVG 里的 <rect>、<path>、<text> 拆成纯文本之后，没有任何人（或大模型）能从那堆坐标数字里还原出「这是一个决策分支」的结构。

排版信息——字体大小、颜色、位置层级——同样消失。但恰恰是这些，构成了一个页面的信息结构。大标题、小标题、强调句、注释、说明性小字——如果全都展平成等宽的纯文本，大模型处理时就失去了大量的结构线索。

PixelRAG 论文里的数据是：平均丢失 40% 以上的关键信息。这个数字很重要——不是说 RAG 答错了 40% 的问题，而是说还没开始回答问题，你的知识库里就有 40% 的信息变成了残骸。

第二个漏洞：不同解析器，结果差异大到影响检索

这个问题很少被讨论，但确实存在。

同一个网页，用 BeautifulSoup 解析和用 Playwright 爬取的文本会不一样。用 Docling 处理 PDF 和用 pdfplumber 处理 PDF，提取的表格文字位置可能差几列。用 unstructured 和 Markdownify 处理同一份 HTML，结构呈现完全不同。

这意味着：你的向量数据库里的内容，不只取决于原始文档，还取决于你某天心情好选的那个解析库。换一个库，同样的知识库重建，检索结果可能剧烈波动——相同的问题，上周能答对，换了解析器就答不上来了。

更麻烦的是：这种不稳定性很难被发现，因为它不是系统性失败，是随机漂移。

切块带来的语义割裂

然后是 chunking 这关。把一篇 2000 字的文章切成 500 字的块，是现在几乎所有 RAG 系统的标配操作。

这个操作有一个隐性代价：语义相关的内容，可能被切到不同的块里。一个在第 800 字提出的问题，答案在第 1300 字，如果切块边界落在 1000 字处，这个问答对就被拆散了。检索时，问题相关的块被捞上来，答案所在的块没有被捞，大模型只好靠其他上下文猜——或者出幻觉。

这三个问题——信息解析丢失、解析器不稳、切块割裂语义——是传统文本 RAG 的结构性缺陷，不是某个具体实现的 bug，是这条链路本身的设计问题。

PixelRAG 的方案：直接看图

PixelRAG 的策略非常直白：既然文本解析会丢信息，那我就不做文本解析，直接用截图做检索。

它的技术流程：

  1. 用 PixelShot 对页面/文档进行截图，切成视觉切片（类似于把文档的每一屏截下来）
  2. 把每张截图用视觉模型编码成图像向量
  3. 建立图像索引
  4. 检索时，把查询也编码成向量，在图像索引里找最相似的截图
  5. 把召回的截图整张送给多模态大模型，让它看图回答

关键在：整个流程里，从没有把图像转成文本。 检索的单位是截图，回答的上下文也是截图。信息一直以视觉形式流转，没有经历过「HTML → 纯文本」这道丢失的门。

表格还是表格，流程图还是流程图，排版还是排版。大模型最终看到的，和人类在浏览器里看到的，是同一个东西。

这就是”Web Screenshots Beat Text”这句 Slogan 的字面意义：截图，确实比解析出来的文本信息量更大。

技术核心：PixelShot + 微调 Qwen3-VL-2B

PixelRAG 的技术栈由两个核心模块构成。

PixelShot：负责把页面渲染成截图，再进行切片。听起来简单，实际上要处理一堆工程问题——页面懒加载、动态内容、PDF 多页渲染、不同屏幕尺寸下的布局差异。切片的粒度也要仔细设计：切太大，每张图信息量太多，向量无法准确表达”这张图包含的主要信息是 X”；切太小，一个完整的表格或流程图被切碎，语义又丢了。

微调 Qwen3-VL-2B：这是整个方案的技术核心。Qwen3-VL 是阿里通义千问的视觉语言模型，3B 参数的版本——不是特别大，但 PixelRAG 团队在海量截图数据上对它进行了专项微调，让它专门擅长「给你两张截图/一张截图和一个文字查询，判断相关性」这件事。

为什么用 3B 的小模型而不用更大的？因为这是检索环节，要实时跑数百到数千次对比，大模型撑不住延迟。Qwen3-VL-2B 微调后，在截图检索这个特定任务上的准确率已经够用，延迟控制得住。

训练数据：论文里提到，在 700 万条维基百科截图 + 60 万条新闻语料截图上训练，覆盖了大量有表格、信息框、多列排版的内容——这些正是文本解析最容易出问题的场景。

数字背后的意义

说三个关键数字，每个数字背后都是一个设计决策。

18.1%：准确率提升

这不是跟随机猜比，是跟”最强文本 RAG”比。最强文本 RAG 在这里指的是用效果最好的解析器、最好的 embedding 模型、最好的 chunking 策略组合出来的系统。PixelRAG 在它之上再提升 18.1%，意味着视觉检索的信息保留优势，在最终的回答准确率上已经超过了文本 RAG 里所有工程优化的累积收益。

这个数字的意义是：即便你把文本 RAG 调到最好，也不如直接不做解析。

1/10：Token 消耗降低

这个数字比准确率更出乎意料。

直觉上，截图比文本大多了，Token 消耗应该更高才对。为什么反而降到十分之一？

原因在于：文本 RAG 的 topK 检索，每次返回多个文本块，每块几百个 Token，拼起来的上下文很长。PixelRAG 返回的是截图，但视觉模型理解一张截图的信息量远超纯文本的 Token 数——一张 1024×768 的截图，里面可能包含等价于 2000 个 Token 的信息，但传给多模态模型作为图像处理，Token 消耗只有 256-512 个视觉 Token 左右（取决于模型的图像压缩策略）。

结果就是：每次检索，PixelRAG 传给大模型的上下文，信息密度更高，Token 数更少。

可溯源

这个不是数字，但很重要。PixelRAG 的检索结果是完整截图——这意味着大模型的答案，可以直接定位到”是哪张截图的哪个位置”。不像文本 RAG，回答是某几段拼凑出来的，追溯起来需要反查原文档再重新定位。

截图本身就是证据，溯源的心智负担降到接近零。

视频的文案是怎么做的

拆完技术，再来看这条视频本身的内容结构，值得学。

钩子（前 3 秒）：星空背景 + 黄色大标题「伯克利最新项目要颠覆传统 RAG？」——用问号钩住想法，「颠覆」这个词激活好奇心，「伯克利」给权威背书，三元素在三秒内全部到位。不是”某个新工具做了什么”，是”一件打破你认知的事可能要发生了”——从注意力争夺的角度，这是正确的起手式。

人设与声音：无真人出镜，但作者账号 EasyShip.AI 的风格是「技术深度 + 工具拆解」，用图表+字幕代替真人讲解——降低出镜门槛，放大内容密度。对没有真人出镜条件的账号是个值得借鉴的路线。

信息密度节奏：91 秒的视频，分了五个段落：传统 RAG 流程 → 三个问题 → PixelRAG 方案 → 四个优势 → 技术背书 + 展望。每个段落大约 15-20 秒，切换点有画面切换强化。节奏感强，不拖沓，像一篇结构清晰的技术 Blog 被压缩成了短视频。

讲解结构：标准的「问题-方案-价值」三段式。先挖坑（传统 RAG 有问题），再填坑（PixelRAG 怎么解决），最后拔高（数字 + 论文 + 未来展望）。这个结构在技术科普内容里几乎是万能的，因为它遵循了认知路径：先让人知道为什么有问题，再告诉他解法，最后告诉他为什么值得信。

金句：「纯视觉原生 RAG，不依赖 HTML 文本解析，直接用截图完成检索。」——这句话有三个并列的否定和肯定，节奏感强，适合截图传播。「Web Screenshots Beat Text」的 Slogan 也是这个逻辑，简洁、有对立感、易记。

收尾 CTA：「随着 VLM 的发展，PixelRAG 能力会不断提升」——是一个隐性 CTA，不是让你去点赞，而是「这个方向值得关注，我会继续跟踪」，在技术账号的语境下，这种收尾比直接喊「双击点赞」更可信，用户会主动 follow。

可复制骨架：

【现有方案】存在【核心问题列表】→ 【新方案】通过【技术路径】解决了这些问题 → 实测数据：【A 提升 X%、B 降低 Y 倍、C 能力新增】→ 底层依赖【技术模块】→ 随着【趋势】，能力还会继续提升。

这个骨架适合任何「新 AI 工具 vs 旧方案」类内容，换上不同的技术词就能直接套用。

四角度反思

对我们做的事：如果你在做任何涉及知识库的 AI 产品，文本解析这个环节是值得重新审视的。不是说今天就要迁移到 PixelRAG，而是要清楚知道：你当前的解析链路，在哪一步丢了多少信息，用户感知到的回答质量下降，有多少是这个原因导致的。针对性地补视觉检索能力（比如对含有大量图表的 PDF，可以考虑截图+视觉模型作为补充链路），而不是继续在 chunking 策略和 reranking 上无止境调参。

对橙子自己的能力：橙子目前在帮老大做知识库检索（~/chengzi-memory 底座 + FTS5 + sqlite-vec 向量）。这套方案的检索对象是纯文本的 Obsidian 笔记，丢失信息相对有限。但如果未来知识库里有大量图文混排内容、报表截图、飞书文档里的多维表格，那 PixelRAG 的思路就有直接的应用价值——不是替换现有方案，而是在特定类型内容上加一个视觉检索的补充层。

对老大机构业务：做带货/内容电商，知识库里大量内容是产品图、带货截图、商品详情页的信息——这些天然是视觉结构的内容，文本解析对它们效果极差。如果有需求做”从历史带货内容里检索相关案例”这类功能，PixelRAG 的技术路径比传统 RAG 更适合。此外，PixelRAG 的「截图即证据」特性，在教学场景（帮学员在几百个视频截图里找到某个知识点的出处）里也有直接的应用空间。

对未来发展：PixelRAG 现在的准确率优势，很大程度上依赖 VLM 的视觉理解能力。而 VLM 正处于快速迭代期——Qwen3-VL、GPT-4o、Claude Vision 这些模型每隔几个月就有显著提升。这意味着 PixelRAG 这类方案的能力上限在自动上涨，不需要改架构，只需要换更新的 VLM。相反，文本 RAG 的改进空间已经相对收敛——更好的 embedding 模型、更好的 reranker，但底层的信息丢失问题没法靠这些修。这个趋势如果持续，视觉 RAG 对文本 RAG 的优势可能会越来越大。

三条可迁移判断

判断一：信息损耗问题，比检索精度问题更根本

大多数 RAG 项目在出问题时，第一反应是「调 topK、换 embedding 模型、加 reranker」。但如果根本问题是信息在进入向量库之前就丢失了，这些优化都是在一个漏洞上打补丁。PixelRAG 提醒了一件事：把诊断的起点前移到数据预处理阶段，检查信息在你的管道里是怎么流、在哪里掉的，比调检索参数更值钱。

判断二：「原生格式」比「转换格式」保留更多信息

PixelRAG 的核心逻辑是：不要把视觉内容转成文本再处理，直接在视觉格式上处理。这个逻辑可以泛化：处理 PDF，能用 PDF 原生工具就别先转 Word；处理表格，能保留 Excel 结构就别先转 CSV；处理代码，能在 AST 层面操作就别先转成纯文本。格式转换几乎每次都丢东西，能不转就不转。

判断三：多模态模型的成熟，正在让「绕开文本」成为可行路线

PixelRAG 能成立，是因为 Qwen3-VL 这类视觉语言模型已经成熟到可以做特定任务的精准微调，推理速度和成本也到了工程上可接受的范围。这说明：很多过去「被迫先转文本」的场景，今天可以重新用视觉/多模态方案来做——不是因为有了更好的文本处理，而是因为视觉理解能力已经够用了。扫一遍自己的产品，看有没有「本来是视觉内容，为了处理被硬转成文本」的地方，可能都有重新设计的空间。

PixelRAG 的 GitHub 可搜索「PixelRAG berkeley」找到。论文发布了配套的 7M 维基百科截图语料，技术上可以直接复用做微调。代码安装命令是 pip install pixelrag，API 接口支持 curl 调用，工程化落地的门槛不高。

这个方向不会马上取代文本 RAG，毕竟文本内容仍然是绝大多数场景的主力。但对于以视觉结构为主的文档类型（表格密集的报告、含流程图的文档、网页截图知识库），PixelRAG 已经是可以认真评估的选项了。