Introduction : Le défaut fatal du RAG traditionnel
Si vous construisez une base de connaissances d’entreprise, un système de recherche IA ou une application de questions-réponses sur des documents, vous avez certainement rencontré le RAG (Retrieval-Augmented Generation). Tout le monde connaît le flux de travail RAG traditionnel : crawler des pages web → analyser le HTML → découper le texte → vectoriser → récupérer → transmettre au LLM.
Le problème réside dans la deuxième étape.
Imaginez une page Wikipedia avec un tableau de cours boursiers :
| Year | Price |
|---|---|
| 1990 | 12.4 |
| 1991 | 18.7 |
| 1995 | 42.3 |
Un humain peut instantanément voir « le prix le plus élevé avant 1995 était 18,7 ». Mais après qu’un analyseur HTML convertit le tableau en texte brut, l’alignement des colonnes disparaît, et le tableau devient :
Year Price 1990 12.4 1991 18.7 1995 42.3Face à cette chaîne de texte, il est difficile pour un LLM de répondre précisément à « quel était le prix le plus élevé avant 1995 ? ». Pire encore, les graphiques, infographies, mises en page multi-colonnes, les PDF mêlant texte et images — ces informations qui sont purement perdues lors de l’analyse HTML sont précisément les types de contenus que les utilisateurs interrogent le plus fréquemment.
C’est la motivation derrière la création de PixelRAG par l’UC Berkeley : Puisque les pages web sont intrinsèquement visuelles, pourquoi ne pas utiliser des captures d’écran pour la recherche ?
Architecture centrale de PixelRAG : Des pixels aux réponses
Le titre du papier de PixelRAG est sans équivoque — “Web Screenshots Beat Text for Retrieval-Augmented Generation.” Il provient de trois laboratoires de pointe de Berkeley : Sky Computing Lab, BAIR et Berkeley NLP, dirigé par Yichuan Wang, Zhifei Li et d’autres, avec Matei Zaharia (créateur de Spark), Joseph Gonzalez et Sewon Min comme co-directeurs.
Deux composants principaux
1. Le moteur de rendu (pixelshot)
pixelshot est les « yeux » de PixelRAG. Il utilise Playwright + Chrome DevTools Protocol (CDP) pour convertir n’importe quelle page web ou PDF en tuiles de captures d’écran. Chaque tuile est une image de la taille d’une fenêtre d’affichage de la page à la résolution de l’écran.
# Render Wikipedia Python page to screenshot tiles
pixelshot https://en.wikipedia.org/wiki/Python --output ./tilesAvantages clés :
- Contenu rendu par JavaScript — SPAs, données chargées dynamiquement, tout est visible
- Tableaux, graphiques, infographies — structure visuelle complète préservée
- Mises en page multi-colonnes — relations spatiales intactes
- Documents PDF — rendu page par page via poppler
2. Modèle d’embedding visuel
Les tuiles de captures d’écran sont vectorisées à l’aide du modèle Qwen3-VL-Embedding-2B. Ce modèle a été affiné par LoRA sur des données de captures d’écran (le jeu de données d’entraînement et les adaptateurs sont open source), permettant de retrouver les captures d’écran par contenu visuel dans l’espace vectoriel.
Lors d’une requête « Quelle est la capitale de la France ? », le système ne cherche pas par mots-clés textuels — il trouve la tuile de capture d’écran contenant la réponse, avec l’infobox, les tableaux et le contexte qu’un humain peut lire directement.
Flux de travail
Document → pixelshot renders screenshots → Qwen3-VL embedding → FAISS index
↓
Query → Qwen3-VL embed query → FAISS retrieval → return screenshot tiles → VLM reads image for answerRemarque : l’ensemble du pipeline n’a aucune représentation textuelle intermédiaire. Les captures d’écran entrent, les captures d’écran sortent, et les VLMs (comme Claude, GPT-4o, Qwen-VL) lisent les réponses directement à partir des images.
Comparaison avec les frameworks RAG grand public
PixelRAG ne cherche pas à remplacer Firecrawl ou Jina Reader — il résout un problème à un autre niveau. Clarifions leurs relations :
| Dimension | Firecrawl | Jina Reader | RAGFlow | PixelRAG |
|---|---|---|---|---|
| Fonction principale | Crawling web + extraction structurée | Extraction de contenu d’une URL unique | Moteur RAG de bout en bout | Recherche visuelle + lecture de captures d’écran |
| Traitement des données | HTML → Markdown/JSON | HTML → Texte | Analyse multi-format | HTML → Tuiles de captures d’écran |
| Gestion des tableaux | Partiellement préservés | Alignement des colonnes perdu | Dépend de l’analyseur | Entièrement préservés (en image) |
| Gestion des graphiques | Perdus | Perdus | OCR partiel | Entièrement préservés |
| Mise en page visuelle | Perdue | Perdue | Partielle | Entièrement préservée |
| Cas d’usage | Crawling à grande échelle | Extraction rapide de contenu | Q&A documentaire en entreprise | Recherche de contenu structuré |
| Open Source | Oui | Oui | Oui | Oui (Apache 2.0) |
Constat clé : Firecrawl et Jina Reader sont des outils de la couche d’acquisition de données ; PixelRAG est une innovation au niveau de la méthode de recherche. Ils peuvent être complémentaires — utilisez Firecrawl pour le crawling web à grande échelle, et PixelRAG pour la recherche visuelle de contenu structuré.
Benchmarks de performance
Les données expérimentales du papier sont impressionnantes :
| Benchmark | Text RAG (Meilleur baseline) | PixelRAG | Amélioration |
|---|---|---|---|
| SimpleQA | 71.6% | 78.8% | +7.2% |
| NQ-Tables | 42.5% | 48.8% | +6.3% |
| EVQA | 29.6% | 45.1% | +15.5% |
| MMSearch | — | Amélioration significative | — |
| LiveVQA | — | Amélioration significative | — |
| MoNaCo (Benchmark agent) | Baseline | 3x moins de tokens | Gain d’efficacité |
Les gains les plus importants concernent les tableaux et le contenu structuré — EVQA (QA visuel) s’est amélioré de 15,5 points de pourcentage, précisément parce que le RAG textuel traditionnel ne peut pas du tout gérer les informations de graphiques.
Guide d’installation et de démarrage rapide
Installation minimale
pip install pixelragCela vous donne pixelshot (le moteur de rendu) et la bibliothèque de base. Ajoutez les modules fonctionnels selon vos besoins :
pip install 'pixelrag[embed]' # chunk, embed, build-index commands
pip install 'pixelrag[index]' # Full pipeline orchestration
pip install 'pixelrag[serve]' # FastAPI search server
pip install 'pixelrag[pdf]' # PDF rendering support (requires poppler)Expérience sans configuration : API Wikipedia hébergée
Le moyen le plus rapide de l’essayer — l’équipe de Berkeley héberge un index pré-construit de 8,28 millions de pages Wikipedia :
# No installation needed, query directly
curl -X POST https://api.pixelrag.ai/search \
-H "Content-Type: application/json" \
-d '{"queries": [{"text": "What is the capital of France?"}], "n_docs": 5}'Les résultats incluent les tuiles de captures d’écran correspondantes (images encodées en base64) et les métadonnées des documents. Vous pouvez l’essayer directement dans votre navigateur : pixelrag.ai.
Construction d’un index local
Construisez un index pour vos propres documents :
1. Créez le fichier de configuration pixelrag.yaml :
source:
type: local
path: ./my_docs
embed:
model: Qwen/Qwen3-VL-Embedding-2B
device: auto # Automatically selects CUDA on Linux, MPS on macOS
output: ./my_index2. Construisez et démarrez le service :
# Build index (~3 minutes on Apple M-series, ~1 minute on GPU)
pixelrag index build
# Start search service
pixelrag serve --index-dir ./my_index --port 300013. Requête :
curl -X POST http://localhost:30001/search \
-H "Content-Type: application/json" \
-d '{"queries": [{"text": "What is the core principle of PixelRAG?"}], "n_docs": 5}'Cas pratique : Indexation d’un PDF
pip install 'pixelrag[index,pdf]'
# Download sample PDF (the PixelRAG paper itself)
curl -L -o paper.pdf https://raw.githubusercontent.com/StarTrail-org/PixelRAG/main/assets/pixelrag-paper.pdf
# Create configuration
cat > pixelrag.yaml << 'EOF'
source:
type: local
path: ./paper.pdf
embed:
model: Qwen/Qwen3-VL-Embedding-2B
device: auto
output: ./paper_index
EOF
# Build → Serve → Query
pixelrag index build
pixelrag serve --index-dir ./paper_index --port 30001
curl -X POST http://localhost:30001/search \
-H "Content-Type: application/json" \
-d '{"queries": [{"text": "Overview of PixelRAG pipeline diagram"}], "n_docs": 1}'Donner des « yeux » à Claude Code
PixelRAG fournit également un plugin Claude Code pixelbrowse qui permet à Claude de « voir » directement les pages web :
# Install pixelshot CLI
uv tool install pixelrag # or pipx install pixelrag
# Install Claude plugin
claude plugin marketplace add StarTrail-org/PixelRAG
claude plugin install pixelbrowse@pixelrag-pluginsPuis :
claude -p "screenshot https://news.ycombinator.com and summarize the top stories"
claude -p "screenshot https://arxiv.org/abs/2404.12387 and explain the key findings"Claude prend une capture d’écran de la page et lit le contenu dans l’image comme un humain — tableaux, graphiques et mises en page tous visibles en un coup d’œil.
Cas concrets : Recherche dans des tableaux et graphiques complexes
Cas 1 : Tableaux de données financières d’entreprise
Supposons que vous ayez un tableau HTML avec des données financières sur plusieurs années. Après l’analyse par un RAG traditionnel, l’alignement des colonnes est perdu, ce qui rend difficile pour les LLMs de répondre à des questions comme « Quel était le taux de croissance du chiffre d’affaires en glissement annuel pour le T3 2023 ? » qui nécessitent des calculs entre colonnes.
Les captures d’écran de PixelRAG préservent la structure visuelle complète du tableau. Le VLM peut localiser la cellule « T3 2023 » comme un humain, lire la valeur correspondante horizontalement, puis la comparer et calculer par rapport au « T3 2022 ».
Cas 2 : Graphiques de comparaison expérimentale dans des articles académiques
Les diagrammes en barres et graphiques linéaires dans les articles sont complètement perdus lors de l’analyse textuelle. PixelRAG convertit les graphiques en captures d’écran, permettant aux VLMs de lire directement les tendances et de comparer les valeurs à partir des images.
Cas 3 : Pages de comparaison de produits e-commerce
Les tableaux de comparaison de spécifications produits en multi-colonnes voient souvent les paramètres de différents produits mélangés par les analyseurs traditionnels. Les captures d’écran de PixelRAG préservent la disposition spatiale, permettant aux VLMs de distinguer précisément les spécifications de différents produits.
Analyse des cas d’usage
Scénarios fortement recommandés
| Scénario | Raison |
|---|---|
| Base de connaissances d’entreprise | Documents internes remplis de tableaux, organigrammes, formulaires d’approbation |
| Recherche de littérature académique | Données expérimentales, graphiques dans les articles sont des informations centrales |
| Données e-commerce | Tableaux de spécifications produits, comparaisons de prix, captures d’écran d’avis utilisateurs |
| Documents gouvernementaux/juridiques | Tableaux, annexes, sceaux dans les réglementations |
| Analyse de rapports financiers | États financiers, graphiques de visualisation de données |
Scénarios moins adaptés
| Scénario | Raison |
|---|---|
| Articles de blog en texte brut | Le RAG textuel est déjà suffisamment performant ; le RAG visuel ajoute une surcharge inutile |
| Documentation de code | Les blocs de code sont plus précis en représentation textuelle |
| Crawling en temps réel à grande échelle | Le rendu de captures d’écran est beaucoup plus lent que l’extraction de texte |
Limites et orientations futures
Limites actuelles
1. Coûts de stockage
L’index pré-construit de 8,28 millions de pages Wikipedia fait environ 217 Go. Pour les applications d’entreprise avec de grands volumes de documents, stocker des index de captures d’écran coûte bien plus que des index textuels. Cependant, le projet rapporte avoir atteint 97 % d’économie de stockage grâce à la compression d’images tout en maintenant la précision de recherche.
2. Latence de rendu
pixelshot doit lancer un navigateur headless pour rendre chaque page, ce qui est plus lent que l’analyse directe du HTML. Pour les scénarios nécessitant le traitement en temps réel de milliers d’URL, c’est un goulot d’étranglement.
3. Dépendance au GPU
Le modèle d’embedding Qwen3-VL-Embedding-2B fonctionne mieux sur GPU. Bien qu’il supporte le CPU et Apple Silicon (MPS), la construction d’index à grande échelle nécessite toujours des ressources GPU.
4. Coûts de requête
Les tokens d’image sont plus coûteux que les tokens textuels. Bien que PixelRAG réalise une économie de 3x en tokens grâce à une recherche précise (car les captures d’écran retournées sont plus ciblées que plusieurs blocs de texte), le coût d’inférence VLM par requête reste supérieur aux solutions purement textuelles.
Orientations futures
- Compression visuelle plus efficace : Réduire encore les coûts de stockage et de transmission
- Rendu en streaming : Support de l’indexation incrémentale de captures d’écran pour les sites web à grande échelle
- Fusion multimodale : Combiner les signaux textuels et visuels pour une recherche hybride
- Déploiement en edge : Optimiser les modèles pour supporter l’exécution sur des appareils edge
Conclusion
PixelRAG propose un point de vue audacieux mais intuitivement juste : Les pages web sont faites pour être vues par des humains — pourquoi d’abord les « traduire » en texte machine puis faire lire les machines ? En préservant la forme visuelle originale des pages web, PixelRAG atteint une précision de recherche que le RAG textuel traditionnel ne peut égaler dans les scénarios avec tableaux, graphiques et mises en page complexes.
Il ne cherche pas à remplacer Firecrawl ou Jina Reader, mais comble le manque de « recherche visuelle » dans l’écosystème RAG. Si votre base de connaissances contient beaucoup de contenu structuré (tableaux, graphiques, formulaires), PixelRAG mérite une évaluation sérieuse.
Liens du projet :
- GitHub : StarTrail-org/PixelRAG
- Démo en direct : pixelrag.ai
- Papier : arXiv:2606.28344
- Licence : Apache 2.0
Foire aux questions (FAQ)
Q1 : Quelle est la relation entre PixelRAG et Firecrawl/Jina Reader ? Peuvent-ils être utilisés ensemble ?
PixelRAG est une innovation dans la méthode de recherche (utilisation de captures d’écran au lieu de texte) ; Firecrawl/Jina Reader sont des outils d’acquisition de données. Ils peuvent être complémentaires — utilisez Firecrawl pour le crawling web à grande échelle, et PixelRAG pour la recherche visuelle de contenu structuré.
Q2 : PixelRAG nécessite-t-il un GPU ?
Un GPU est recommandé pour la construction d’index (3x+ plus rapide), mais il supporte les modes Apple Silicon (MPS) et CPU. Le service de requêtes peut également fonctionner sur CPU.
Q3 : L’index Wikipedia de 8,28 millions de pages fait 217 Go — que faire si les coûts de stockage sont trop élevés ?
PixelRAG rapporte avoir atteint 97 % d’économie de stockage grâce à la compression d’images. Il supporte également la configuration de quantification du backend Qdrant (comme la quantification int8) pour réduire encore l’utilisation mémoire.
Q4 : Quels formats de documents PixelRAG supporte-t-il ?
Il supporte actuellement les pages web (rendu HTML/JS), les PDFs (nécessite l’installation de poppler) et les images locales. Il peut traiter de manière mixte des URL et des fichiers locaux.
Q5 : Sur quel benchmark l’amélioration de 18 % de précision est-elle basée ?
Sur le benchmark SimpleQA, PixelRAG atteint 78,8 % de précision, soit 7,2 points de pourcentage de plus que le meilleur baseline RAG textuel (71,6 %). Sur NQ-Tables, intensif en tableaux, il s’améliore de 6,3 points de pourcentage, et sur le QA visuel EVQA, de 15,5 points de pourcentage.
Q6 : Comment ajouter une capacité d’accès web visuel à Claude Code ?
Installez pixelshot (uv tool install pixelrag), puis installez le plugin Claude (claude plugin install pixelbrowse@pixelrag-plugins). Après cela, Claude peut directement prendre des captures d’écran et lire n’importe quelle page web.
J’espère que cette exploration approfondie vous sera utile ! Si vous construisez un système RAG impliquant du contenu structuré comme des tableaux et des graphiques, PixelRAG offre une approche entièrement nouvelle — laisser les machines « voir » les pages web comme des humains, plutôt que de forcer les pages web à s’adapter aux préférences textuelles des machines.
