PixelRAG：当网页表格是证据，RAG就不能只看纯文本

网页 RAG 最容易被低估的损失，不是少抓了几个段落，而是把答案赖以成立的版式一起删掉了。财报表格、产品对比、地图、流程图和多栏文档在 HTML 中有结构，在抽取后的纯文本里却经常只剩下一串相邻的词。PixelRAG 的判断很明确：当证据依赖页面长相时，检索对象应当是页面渲染出来的像素，而不是文本解析器的副产品。

它修复的是证据链，不只是表格识别

传统 RAG 通常经历 HTML 解析、正文清洗、切块、文本向量化和召回。每一步都可能保留语义，却破坏关系：表头与单元格分离，脚注跑到下一块，图例和颜色编码消失，左右栏被拼成上下文。模型面对“第三季度毛利率是多少”时，未必没有数字，而是没有数字与行列位置之间的证据。

PixelRAG 官方仓库把文档、网页和 PDF 先渲染为截图瓦片，再直接对图像做检索。论文 PIXELRAG 的核心实验也不是给 OCR 加一个更大的模型，而是让检索阶段保留视觉输入，命中瓦片后交给视觉语言模型阅读。

两条管线：pixelshot 与视觉向量

第一段是 pixelshot：借助 CDP/Playwright 把网页或 PDF 变成可定位的图像瓦片，并记录来源与 manifest。第二段是视觉嵌入：项目采用 Qwen3-VL-Embedding-2B，并提供针对截图数据训练的 LoRA，使查询与包含文字、图表、布局的页面图像落到可检索的向量空间。默认本地索引是 FAISS，规模化场景可以接 Qdrant。

pip install pixelrag
pixelshot https://example.com/report -o ./tiles
pip install "pixelrag[index]"
pixelrag index build
pixelrag serve --index-dir ./my_index --port 30001

为什么不能只把文本 RAG 换成像素 RAG

像素检索不是文本检索的普遍替代品。纯文字政策、源码和长篇说明书在文本索引上更容易过滤、引用和做精确匹配；截图需要更高的存储和推理成本，也会让精确的字符串检索、权限过滤和增量更新更复杂。更稳妥的架构是双层索引：文本层负责标题、段落、时间和权限过滤，像素层负责表格、图示、版式和视觉证据，召回后再合并。

先用一个可验证的问题试点

不要从全站重建开始。选一批会损失版式的 PDF 或网页，准备一组带标准答案的问题，分别跑文本、像素和混合三条链路。记录命中页、答案正确性、延迟、索引大小以及引用是否能回到原始页面。只要业务问题主要是“表里某项是多少”“图中哪条线最高”“这个字段属于哪一列”，像素层才有明确的投入理由。

资源账单必须写进方案

官方仓库给出的本地流程支持 Apple Silicon/MPS、Linux/CUDA 和 CPU fallback，但完整向量索引并不轻。README 以约 217G 的基础 FAISS 索引作为下载示例；评测目录还列出更大的索引、瓦片和模型数据规模。托管 API 适合验证想法，自建则要提前规划磁盘、显存、瓦片回源和增量重建。

判断标准

PixelRAG 最有价值的地方，是把“模型看不懂表格”改写成“检索阶段没有保留表格证据”。如果页面关系本身决定答案，它值得成为混合 RAG 的视觉分支；如果资料天然是线性文字，先把解析、切块和引用做稳，通常比直接上像素索引更划算。