夜雨聆风
RAG新范式——把网页当成截图来索引和搜索。
听起来有点离谱对吧？我第一次看到也觉得这是什么野路子。但看完论文和数据，我得承认，这事儿比表面看起来要有道理得多。
问题的根源： RAG 在第一步就瘸了
RAG 现在是大模型知识更新的标准方案——模型不懂的，就从外部数据库里搜一段相关文本喂给它。
这个链条上有一个环节，从来没人质疑过：网页是怎么变成文本的。
答案是用工具解析 HTML 。把标签剥掉，把表格转成纯文本，把侧边栏的信息框拆成无序的字符串，然后一股脑塞进索引。
听着很合理对吧？合理到没人觉得这有什么问题。
但 PixelRAG 的团队做了一个错误分析，结果让整个行业有点坐不住。
他们把传统文本 RAG 的回答错误拆成了三块：
解析损失占 36.6%。 答案明明在网页上，但一步转换，信息就丢了。表格散了，布局平了，信息框里的结构化数据变成了一堆乱七八糟的字符串。这不是模型答错了——是它根本就没"看到"正确答案。荒不荒唐？
排序损失更夸张， 55.2%。 答案其实被提取出来了，但没排到前面。问题出在 Wikipedia 的信息框（ infobox ）上——这东西关键词密度极高， 75.9% 的查询里它排第一，真正包含答案的段落排到第 20 开外。在视觉上， infobox 是侧边的一个补充模块，人类扫一眼就知道该忽略它。但在文本世界里，它成了最大的噪声源。
读取损失 8.2%， 内容到了但模型在扁平文本里找不到归因。
三块加起来，几乎 92% 的错误都跟"把网页变成文本"这件事有关。
换句话说，文本 RAG 的准确率天花板，在第一步就被 HTML 解析焊死了。 不管你后面用 GPT-5 还是 Claude ，输入是残缺的，后面再强也是抓瞎。
这个洞察，比 PixelRAG 这个项目本身要有价值得多。
项目标语也挺狂："The end of web parsing. The beginning of scalable pixel-native search." ——网页解析的终结，可扩展像素级搜索的开端。一开始我觉得这就是个口号，看完数据之后发现，人家确实有点底气。
像素级检索到底怎么玩的
PixelRAG 的思路简单到有点粗暴：不解析了，直接截图。
技术流程三步走。
第一步，渲染。 用 Playwright 把网页在一个 875px 宽的虚拟浏览器里打开，截屏，然后按 1024px 高度切成图块。 Wikipedia 的 828 万篇文章，一共切出了大约 3000 万个图块。
第二步，索引。 每个图块用阿里 Qwen3-VL-Embedding-2B 模型编码成 2048 维的向量，存进 FAISS 索引。整个索引大约 120GB——不算小，但也不是不能接受。
有意思的是训练这一步。团队用合成对比数据对检索模型做了 LoRA 微调，大约 4 万对正负样本，在单张 H100 上 3 小时就跑完了。成本并不高。用他们自己的话说——"we're not training foundation models, we're just teaching an existing visual model what a good web page tile looks like"。调完之后的 Qwen3-VL-Embedding-2B 在检索质量上有了明显提升。
第三步，检索+阅读。 用户输入查询后，从 FAISS 里召回最相关的图块，直接扔给 Qwen3-VL-4B 级别的视觉语言模型去"看图说话"。
支持文本查，也支持以图搜图——你可以拿一张截图去找长得像的截图。这个有点意思。
整个项目已经开源，代码仓库在：https://github.com/StarTrail-org/PixelRAG/tree/main
然后一行命令就能把网页渲染成截图图块：
pixelshot https://en.wikipedia.org/wiki/Python --output ./tiles 连 API 都搭好了。https://api.pixelrag.ai 上有 828 万 Wikipedia 页面的预构建索引，不用 API Key ， curl 就能查：
curl -X POST https://api.pixelrag.ai/search \ -H "Content-Type: application/json" \ -d '{"queries": [{"text": "法国首都是什么？"}], "n_docs": 5}' 还能作为 Claude Code 的插件用，装一个叫 pixelbrowse 的技能， Claude 就能通过截图"看"网页。
数据不会说谎，但会说打脸的话
那效果到底怎么样？
论文在 6 个基准上做了全面评测，我挑两个最有说服力的。
SimpleQA——1000 道 Wikipedia 事实问答。文本 RAG 准确率 71.6%， PixelRAG 干到 78.8%。
表格类查询差距： 42.5% vs 48.8%。
但让我最惊讶的不是绝对数字，而是这个提升的来源——它不是因为用了更大的模型或者更好的排序算法，单纯是因为输入格式没丢信息。 一个这么简单的改变，带来了接近两成的提升。
这说明什么？说明整个行业过去几年在 RAG 上的优化，大部分都集中在检索算法、排序策略、分块技巧上——优化了那么多东西，结果最大的瓶颈是最没人在意的那个第一步。
成本方面的数据更狠。
团队让 AI Agent 执行一系列需要查网页的任务，分别用文本 RAG 和 PixelRAG 做后端。
文本 RAG 消耗了 3750 万 prompt tokens 。 PixelRAG 只用了 360 万。将近 10 倍的差距。
道理很简单。传统做法是把整篇文章的文字都塞进 prompt——一篇 Wikipedia 就是几千词。 PixelRAG 只传回来几张截图图块，模型一眼扫过去就知道答案了。不需要读完几千个 token 的文字。
换算成钱： GPT-4o 每百万 token 约 2.5 美元。 3750 万是 93.75 美元， 360 万是 9 美元。做 AI 应用的一看就懂——在规模化场景下，这就是能烧和不能烧的区别。
VentureBeat 还补充了个细节：图块还能再压缩，省 1/3 的传输量。成本还有下降空间。
当然也有质疑的声音。 Reddit 和 Hacker News 上讨论不少，核心质疑集中在两个点上：一是截图方案在动态页面（ JS 渲染、个性化内容）上的一致性怎么保证，二是版权问题——把别人的网页截图存进索引，在法律上有多大风险？这些问题目前还没有很好的答案。
但事情确实没那么简单
如果说 PixelRAG 要替代文本 RAG ，那还差得远。差得不是一星半点。论文自己也没藏着掖着，不足之处列了一堆。我挑几个最要命的说说。
先聊钱的问题。光 Wikipedia 的原始截图就要 5.6TB 。 5.6TB 啊。虽然论文提了"按需渲染"可以省掉持久化存储，但向量索引 120GB 是跑不掉的。跟文本索引比，不是一个量级。小团队基本不用想。
然后是延迟。截图编码加 VLM 推理，比纯文本检索慢得多。网页更新了？重新截图，重新编码。不像文本索引可以增量更新那么优雅。高实时场景基本告别。说实话这挺让人失望的——一个看起来很美的方案，一到工程落地就露馅。
分块也是个老大难。文本 RAG 可以按段落切、按主题切、按语义切。 PixelRAG 目前是按 1024px 高度硬切。一个表格如果横跨两个图块？腰斩。论文原文："visual chunking remains an open problem"——说得挺客气，但确实是硬伤。
模型依赖也是个问题。需要 Qwen3-VL-4B 以上级别才能体现出优势。换成小模型，比文本检索还差 12.5 个百分点。这意味着如果你跑不起大 VLM ，这个方案对你就没意义。这就很尴尬了——你又得强又得贵，两头都占了。
还有可解释性。像素级检索，你很难解释"为什么搜到了这个结果"。搜错了你也说不清它在哪张截图、哪个像素上犯了错。在金融、医疗这些需要审计的行业？直接劝退。连解释的机会都没有。
那到底意味着什么
说了这么多，我觉得 PixelRAG 最有价值的部分不是它本身，而是它证明了一件事：
HTML→文本预处理，是 RAG 体系里被低估的损失环节。
这个认知挺重要的。也挺讽刺的——过去两年大家都在卷模型、卷检索算法、卷分块策略，好像谁把 recall 提两个点就能封神。结果呢？最大的瓶颈在第一步，在一个人人都知道但人人都不当回事的预处理环节上。
一个第三方的验证： VB Pulse 的调研显示，愿意采用混合检索（文本+视觉并行）的企业占比，从今年 1 月的 10.3% 涨到了 3 月的 33.3%。一个季度翻了三倍。
混合方案可能确实是当前最务实的路径——简单文本走传统 RAG ，复杂布局（表格、图文混排、多栏）触发视觉检索。上层做个路由。没必要非黑即白。
项目已经开源在 GitHub 上，搜索 StarTrail-org/PixelRAG 就能找到。论文在 arXiv （ 2506.05209 ），官网是 pixelrag.ai ，有在线 Demo 可以玩。
最后说句实在的。如果你做 RAG 系统，在复杂页面上反复翻车——表格读不出来、排版错乱、关键数字永远漏掉——别急着换模型或者调参数。看看你的 pipeline 的第一步，那个你从来没怀疑过的 HTML 解析器。
你觉得截图检索这条路能走通吗？还是说这只是一次学术上的行为艺术？评论区聊聊。