PixelRAG 不替代文本 RAG：它补上视觉证据这一层

视觉 RAG 的真正问题不是“文本还是图片”二选一，而是不同证据类型该走哪一条检索路径。PixelRAG 提供了一个清晰的工程分界：页面中的文字、表格和图形都可以作为视觉对象被召回，但文本索引仍然适合精确过滤、权限控制和低成本更新。

按问题类型分路由

“某文档何时发布”“包含哪个 API 名称”适合文本检索；“第二列最高值是多少”“图中蓝线代表什么”“这个说明属于左栏还是右栏”需要像素上下文；跨两类证据的问题则先由文本层缩小候选，再用像素层确认版式。路由器可以依据查询中是否出现表格、图、列、颜色、位置等信号，也可以通过小型评测集学习。

像素层保留了什么

截图瓦片保留行列关系、字体层级、图例、箭头和邻近模块，因此视觉模型看到的是读者实际看到的证据。PixelRAG 使用 Qwen3-VL-Embedding-2B，并用截图数据 LoRA 让检索空间对视觉文档更敏感。它不是 OCR 的替代品：像素召回后仍需要视觉语言模型读数，低分辨率、遮挡和动态页面仍然会造成错误。

混合召回的一个实用形态

query
  ├─ text retriever: title / body / date / access filter
  ├─ pixel retriever: table / chart / layout evidence
  └─ reader: merge top tiles + text context, answer with page references

实际落地时，两个召回器不要各自给出一串无法比较的分数。可以在离线集上校准分数，按查询类型设置权重，保留每个证据块的来源 URL、页码、瓦片坐标和索引版本。答案生成器只引用被召回并重新读取过的证据，避免模型把相似页面当成原文。

成本和数据治理

每个像素瓦片都比一段文本占空间，embedding 也更重；网页重渲染还会受到动态内容和字体差异影响。官方示例中的基础 FAISS 索引约 217G，评测数据和瓦片规模更大。涉及内部 PDF 时，还要确认截图是否包含个人信息、商业机密或不可外发的图表，并在日志中避免保存原图和查询内容。

适合从哪里开始

最适合的试点不是“把所有知识库视觉化”，而是一个证据结构明确、错误代价可量化的集合：财务报表、实验记录、设备面板或带图表的技术文档。用同一组问题比较文本、像素和混合方案，分别统计命中、读数、引用和成本，结果会比单看 demo 更接近真实决策。