PixelRAG: recuperar información de capturas de pantalla en lugar de texto

Casi todos los sistemas RAG que consultan la web empiezan igual: descargan el HTML, lo convierten en texto, lo trocean y lo indexan. Un grupo de Berkeley (SkyLab, BAIR y Berkeley NLP) propone saltarse ese paso. Su proyecto, PixelRAG, renderiza cada página como imagen, indexa las capturas y deja que un modelo de visión y lenguaje lea la respuesta directamente de los píxeles. El código está en GitHub con licencia Apache-2.0 y el trabajo se describe en el paper «PixelRAG: Web Screenshots Beat Text for Retrieval-Augmented Generation» (arXiv 2606.28344, 1 de junio de 2026).

Qué se pierde al convertir una web en texto

Aplanar HTML a texto descarta justo lo que más cuesta recuperar después: tablas con celdas combinadas, columnas, gráficos, infoboxes, el orden visual de la página. Un fragmento de texto sacado de una tabla puede quedar sin sus cabeceras, y entonces el modelo lector no encuentra la cifra o, peor, la asocia a la fila equivocada. Los PDF y las presentaciones sufren lo mismo.

PixelRAG parte de la idea contraria: si el contenido está pensado para verse, se indexa como se ve.

Cómo funciona

El flujo tiene cuatro piezas:

• Renderizado: la herramienta pixelshot abre la página en Chromium (Playwright/CDP), o rasteriza un PDF, y la parte en tiles, es decir, trozos de captura de tamaño manejable.
• Embeddings: cada tile se convierte en un vector con Qwen3-VL-Embedding, afinado con LoRA sobre capturas de pantalla y datos contrastivos preparados para ello.
• Índice: los vectores van a un índice FAISS. También hay backend de Qdrant, con cuantización y almacenamiento en disco.
• Lectura: las capturas recuperadas pasan tal cual a un modelo de visión y lenguaje, sin ninguna conversión intermedia a texto.

La consulta puede ser texto y, según la documentación del proyecto, también una imagen.

Las cifras, con matices

El resumen que circula por redes habla de «más de 30 millones de capturas» y de «un 18,1 % mejor» que el mejor RAG de texto. Conviene leerlo con el paper delante:

• Escala: el datastore de Wikipedia tiene 30 millones de imágenes (tiles). El índice público alojado en pixelrag.ai cubre 8,28 millones de artículos, así que son dos formas de contar lo mismo. En disco ocupan casi 6 TB de capturas, y el índice FAISS base que se descarga de Hugging Face pesa unos 217 GB.
• Mejora: el 18,1 % es una mejora «de hasta», la máxima observada entre los distintos benchmarks y configuraciones, no una media. Los autores la sitúan frente a baselines de texto en tareas como QA sobre Wikipedia (NQ, SimpleQA), QA multimodal (MMSearch), noticias ruidosas (LiveVQA) y búsqueda con agentes (MoNaCo).
• Ventaja con tablas: es donde más se nota. En la tabla de resultados del paper con un lector Qwen3-VL-4B, la variante afinada obtiene en NQ-Tables un recall de 33,7 frente al 19,3 del mejor extractor de texto probado (Trafilatura).
• Coste: como la resolución de la imagen es un parámetro, bajarla reduce los tokens del contexto de forma proporcional. Los autores hablan de hasta 3 veces menos coste de tokens manteniendo la precisión. Con un agente ReAct basado en GPT-5 sobre MoNaCo, PixelRAG logra el mejor F1 con el menor coste frente a las alternativas de texto y a Google.

Requiere un modelo de visión decente

El rendimiento depende mucho del lector. Según el paper, los modelos pequeños de generaciones anteriores (familias Llama-3.2-Vision y Qwen2-VL) quedan más de 12,5 % por detrás de la recuperación por texto. A partir de Qwen3-VL-8B, el enfoque por píxeles iguala o supera al texto, con ventajas de hasta 5,9 % en esa comparación. Si tu pipeline corre con un modelo ligero y local, el resultado puede ser peor que el de un buen extractor de texto.

Limitaciones reales

• Pérdida de enlaces: una captura no conserva la estructura de hipervínculos, que en texto sirve para razonamiento multisalto y desambiguación. Los autores proponen extraer URL y texto ancla durante el renderizado y guardarlos como campos auxiliares.
• Almacenamiento: unos 6 TB solo para Wikipedia. La mitigación que plantean es renderizar bajo demanda una vez que el índice señala qué páginas interesan.
• El scraping no desaparece: «adiós al webscraping» es una forma vistosa de decirlo. Sigues necesitando un navegador sin interfaz que cargue la página, ejecute su JavaScript y la capture. Lo que cambia es que no hay que escribir ni mantener selectores, parsers ni lógica de limpieza.
• Seguridad: el README advierte de que la imagen Docker se ejecuta como root con el sandbox de Chrome desactivado, así que el único límite es el propio contenedor, y no debe apuntarse a páginas no confiables sin aislarlo.

Probarlo

La instalación es una línea con pip, y renderizar una página o un PDF, otra:

pip install pixelrag

pixelshot https://en.wikipedia.org/wiki/Python --output ./tiles
pixelshot paper.pdf -o ./tiles --dpi 200

Para construir un índice sobre tus documentos basta un fichero pixelrag.yaml con el origen, el modelo (Qwen/Qwen3-VL-Embedding-2B) y el dispositivo, y después pixelrag index build seguido de pixelrag serve. Funciona en Linux con CUDA y en macOS con Apple Silicon. El proyecto también ofrece un endpoint público de búsqueda sobre Wikipedia, sin clave, para probar sin montar nada.

pip install 'pixelrag[index]'
pixelrag index build
pixelrag serve --index-dir ./my_index --port 30001

El plugin para Claude Code

El repositorio incluye un plugin de Claude Code llamado pixelbrowse. En vez de pedir el HTML de una URL, Claude la captura con pixelshot y lee la imagen, de modo que ve gráficos, diagramas y tablas como los vería una persona. No hay servidor MCP ni backend: la skill llama a pixelshot en tu máquina. Se instala así:

uv tool install pixelrag
claude plugin marketplace add StarTrail-org/PixelRAG
claude plugin install pixelbrowse@pixelrag-plugins

Después basta pedirle algo como «captura https://arxiv.org/abs/2404.12387 y explica las conclusiones», o usar /screenshot con una URL en una sesión interactiva. Hay también una versión para opencode en el paquete npm @startrail/pixelbrowse.

Dónde encaja

Tiene más sentido cuando el contenido es visual por naturaleza: documentación con tablas, informes en PDF, páginas con gráficos o interfaces que quieres que un agente entienda sin depender del DOM. Para texto corrido, como artículos de blog o documentación en Markdown, un buen extractor sigue siendo más barato y fácil de operar. El resultado más llamativo del paper es que, incluso en tareas centradas en texto, el enfoque por píxeles no sale perdiendo siempre que el modelo lector sea lo bastante bueno, y eso obliga a replantearse si convertir todo a texto es el paso por defecto que parecía.

Fuentes: repositorio y paper del proyecto, citados arriba.