Aller au contenu principal
OutilsMarkTechPost · 2 min de lecture

RAG natif pixel : guide pratique de l'indexation visuelle de documents

Source originale ↗·

Cet article étant un tutoriel technique (non daté, sans événement d'actualité précis), voici la traduction-résumé en respectant le format demandé :

Un tutoriel technique détaille la construction complète d'un pipeline de recherche documentaire dit "pixel-native", fondé sur l'image plutôt que sur l'extraction classique de texte HTML. La méthode consiste à convertir des pages web et des documents PDF en images, à les découper en tuiles se chevauchant de 1024 par 1024 pixels avec un recouvrement de 128 pixels, puis à générer des embeddings multimodaux via des modèles comme SigLIP (google/siglip base patch16 224), CLIP, ou en option Qwen3 VL Embedding 2B. Ces vecteurs sont stockés dans un index FAISS pour la recherche par similarité, renforcée par un score BM25 basé sur l'OCR et fusionnée grâce à la méthode dite de reciprocal rank fusion, avec un coefficient k de 60. Le système agrège ensuite les résultats obtenus au niveau des tuiles pour produire un classement au niveau du document entier, et expose le tout via un service de recherche FastAPI tournant sur le port 8000. Le tutoriel s'appuie sur cinq pages Wikipédia en exemple, consacrées au RAG, aux bases de données vectorielles, à l'architecture Transformer, à la photosynthèse et à Delhi, avec jusqu'à douze tuiles générées par document.

Cette approche répond à une limite bien connue des systèmes de RAG classiques, contraints de parser du HTML, d'extraire du texte puis de le découper en segments fixes, une méthode fragile face aux tableaux, aux schémas, aux mises en page complexes ou aux PDF scannés. En travaillant directement sur l'image de la page, le pipeline capture aussi la structure visuelle et les éléments non textuels du document. Le tutoriel montre comment évaluer la qualité de la recherche à l'aide des métriques Recall@k et MRR, et comment entraîner un léger adaptateur résiduel par apprentissage contrastif pour affiner les embeddings. En option, les tuiles les mieux classées peuvent être transmises à un modèle vision langage, en l'occurrence Qwen2.5 VL 3B Instruct, pour générer une réponse finale ancrée dans les preuves visuelles retrouvées. Pour des équipes traitant des documents scannés, des rapports financiers en PDF ou des pages web à la mise en page riche, cette architecture promet une recherche plus fidèle sans dépendre d'un parsing texte souvent imparfait.

Ce travail s'inscrit dans une tendance plus large de la recherche en intelligence artificielle vers des systèmes de RAG multimodaux, portée par les progrès récents des modèles vision langage capables de comprendre directement des captures d'écran de documents. Des acteurs comme Alibaba, avec ses familles de modèles Qwen3 VL et Qwen2.5 VL, illustrent cette évolution vers des architectures capables d'indexer un document sans jamais en extraire le texte brut. Le code complet, écrit en Python, s'appuie sur des bibliothèques standards telles que FAISS et Playwright pour le rendu des pages, ainsi que sur des modèles disponibles via Hugging Face, et reste pensé pour tourner sur Google Colab. À terme, cette approche pourrait s'imposer pour l'indexation de contenus riches en mise en page, ouvrant la voie à des moteurs de recherche documentaire plus robustes face à la diversité des formats rencontrés en entreprise.

Dans nos dossiers

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Implémentation Python pour le benchmarking de parsing de documents avec LlamaIndex ParseBench
1MarkTechPost 

Implémentation Python pour le benchmarking de parsing de documents avec LlamaIndex ParseBench

LlamaIndex a publié ParseBench, un jeu de données de référence conçu pour évaluer de manière rigoureuse les systèmes d'analyse de documents. Hébergé sur Hugging Face sous l'identifiant llamaindex/ParseBench, ce benchmark est structuré autour de plusieurs dimensions d'évaluation distinctes : extraction de texte brut, reconnaissance de tableaux, interprétation de graphiques et respect de la mise en page. La procédure d'utilisation s'appuie sur un pipeline Python standardisé mobilisant des bibliothèques open source comme datasets, pandas, PyMuPDF (alias fitz), rapidfuzz et rich. Les données sont distribuées au format JSONL, avec des fichiers PDF associés accessibles directement depuis le dépôt Hugging Face via hfhubdownload. Le pipeline de référence décrit dans le tutoriel officiel construit un extracteur de texte léger basé sur PyMuPDF, compare les sorties aux annotations de référence grâce à des métriques de similarité floue (fuzz), et produit des visualisations de la distribution des exemples par dimension. L'importance de ParseBench réside dans le manque criant de standards objectifs pour comparer les moteurs d'analyse documentaire, qu'il s'agisse de solutions OCR classiques, de modèles de vision-langage ou de parseurs hybrides. Jusqu'ici, les équipes évaluaient leurs systèmes sur des jeux de données internes non reproductibles, rendant toute comparaison inter-organisations impossible. Avec ce benchmark unifié, les développeurs peuvent mesurer la qualité de l'extraction sur chaque dimension séparément, texte, tableaux, graphiques, layout, et identifier précisément où leurs pipelines échouent. Pour les entreprises qui traitent des volumes importants de documents (contrats, rapports financiers, publications scientifiques), disposer d'un tel outil de mesure change concrètement la façon dont on sélectionne et valide un moteur de parsing avant de le passer en production. ParseBench s'inscrit dans une tendance plus large portée par LlamaIndex, qui cherche à standardiser l'outillage autour des pipelines RAG (retrieval-augmented generation). La qualité de l'extraction documentaire est en effet le maillon critique souvent négligé de ces architectures : un PDF mal parsé produit des embeddings bruités, ce qui dégrade directement les réponses des assistants IA en aval. Plusieurs acteurs du secteur, comme Unstructured, LlamaParse ou encore Docling d'IBM, se livrent une concurrence directe sur ce segment. L'arrivée d'un benchmark public et reproductible oblige désormais ces acteurs à rendre des comptes sur des métriques communes. Les prochaines étapes probables incluent l'intégration de modèles de vision-langage comme GPT-4o ou Qwen-VL comme baselines supplémentaires, et l'extension du benchmark à des formats au-delà du PDF.

OutilsOutil
1 source
Automatiser la génération de schémas pour le traitement intelligent de documents
2AWS ML Blog 

Automatiser la génération de schémas pour le traitement intelligent de documents

Amazon Web Services vient d'enrichir son IDP Accelerator, solution open-source et serverless dédiée au traitement automatisé de documents, d'une nouvelle fonctionnalité baptisée "multi-document discovery". Jusqu'ici, exploiter le traitement intelligent de documents (IDP) exigeait de constituer manuellement un schéma de configuration pour chaque type de document à analyser : définir les classes, identifier des exemples représentatifs, spécifier les champs à extraire. Une contrainte rédhibitoire dès lors qu'une organisation se retrouve avec des milliers de documents non étiquetés et aucune visibilité sur les catégories qui les composent. La nouvelle fonctionnalité répond directement à ce problème : elle analyse une collection de documents inconnus, les regroupe automatiquement par type, puis génère les schémas de configuration prêts à l'emploi. Le pipeline repose sur AWS Step Functions pour l'orchestration, AWS Lambda pour le calcul serverless, Amazon S3 pour le stockage, et les modèles disponibles via Amazon Bedrock pour la génération des schémas, dont le modèle d'embeddings Cohere Embed v4 utilisé par défaut. L'intérêt opérationnel est considérable pour les équipes qui traitent des volumes documentaires hétérogènes. Là où le module Discovery existant nécessitait de connaître ses classes de documents à l'avance et de fournir un exemple par classe, la nouvelle approche supprime ce prérequis. Le système génère d'abord un embedding visuel pour chaque document, en se basant sur la première page uniquement pour les documents multi-pages, puis utilise le score de silhouette pour déterminer automatiquement le nombre de clusters pertinents. Un agent construit avec Strands Agents et un LLM Bedrock analyse ensuite chaque cluster pour identifier le type de document et produire un schéma. Une étape de "réflexion" finale compare l'ensemble des schémas générés pour détecter les chevauchements et incohérences avant validation humaine. Cette approche réduit drastiquement le travail préparatoire qui, à grande échelle, pouvait représenter des semaines de labelling manuel. Le choix des embeddings visuels plutôt que textuels, via OCR, est une décision technique délibérée : la mise en page, le formatage et la structure visuelle d'un document permettent de distinguer des types documentaires même lorsque leur contenu textuel se ressemble. Ce positionnement s'inscrit dans la stratégie plus large d'AWS de faire de Bedrock un socle central pour les workflows d'IA en entreprise, en y adossant des briques comme Strands Agents pour la partie agentique. La solution reste open-source, disponible sur GitHub, ce qui permet aux équipes de l'adapter à leurs propres collections. L'enjeu sous-jacent est de rendre accessibles les initiatives IDP à des organisations qui ne disposent pas des ressources pour classifier manuellement leur patrimoine documentaire avant même de commencer à en extraire de la valeur.

OutilsOutil
1 source
3AWS ML Blog 

Évaluer les agents IA pour la production : un guide pratique de Strands Evals

Le passage des agents IA du prototype à la production soulève un défi fondamental : comment évaluer de manière systématique des systèmes qui, par nature, ne produisent pas de résultats déterministes ? Strands Evals, un framework d'évaluation développé pour le Strands Agents SDK, apporte une réponse structurée à cette question en combinant évaluateurs automatisés, simulation de conversations multi-tours et outils de reporting. L'enjeu est de taille pour le secteur. Les tests logiciels traditionnels reposent sur un principe simple : même entrée, même sortie attendue. Les agents IA brisent cette règle fondamentale. Un agent peut répondre à la question "Quel temps fait-il à Tokyo ?" de dizaines de façons différentes, en Celsius ou en Fahrenheit, avec ou sans humidité, et toutes peuvent être correctes. S'y ajoutent les interactions multi-tours où le contexte s'accumule au fil de la conversation, et les appels d'outils dont la pertinence doit elle aussi être évaluée, indépendamment de la réponse finale. Strands Evals structure cette évaluation autour de trois concepts centraux : les Cases (scénarios de test unitaires, contenant l'entrée, la sortie attendue et la séquence d'outils prévue appelée trajectory), les Experiments (regroupements de cases avec leurs évaluateurs associés, analogues aux suites de tests), et les Evaluators eux-mêmes. Pour dépasser les limites de la comparaison mécanique de mots-clés, le framework s'appuie sur des modèles de langage (LLM) comme évaluateurs, capables de juger des dimensions qualitatives comme l'utilité, la cohérence ou la fidélité aux sources. Cette approche marque une évolution significative dans la manière dont les équipes d'ingénierie peuvent industrialiser le déploiement d'agents IA. En fournissant une infrastructure de mesure répétable et traçable, Strands Evals ouvre la voie à des pipelines d'intégration continue adaptés aux systèmes non déterministes, un prérequis pour tout passage à l'échelle en production.

OutilsOutil
1 source
Guide de programmation pour créer des pipelines avancés d'analyse de documents avec Google LangExtract, OpenAI et visualisation interactive
4MarkTechPost 

Guide de programmation pour créer des pipelines avancés d'analyse de documents avec Google LangExtract, OpenAI et visualisation interactive

Google a publié LangExtract, une bibliothèque Python conçue pour transformer des documents textuels non structurés en données exploitables par machine, en s'appuyant sur les modèles de langage d'OpenAI. L'outil s'intègre directement avec l'API OpenAI, notamment le modèle gpt-4o-mini, et permet d'analyser une large variété de documents : contrats juridiques, comptes-rendus de réunion, annonces produits ou journaux d'opérations. Le pipeline d'extraction repose sur des prompts configurables et des exemples annotés fournis par le développeur, à partir desquels LangExtract identifie des entités, des obligations, des délais, des risques ou des clauses spécifiques, tout en ancrant chaque résultat à sa position exacte dans le texte source via des intervalles de caractères. Les sorties sont générées en double format : JSONL pour le traitement programmatique, et HTML interactif pour la visualisation directe dans un environnement notebook. L'intérêt concret de LangExtract réside dans sa capacité à industrialiser l'analyse documentaire sans infrastructure lourde. Là où la lecture manuelle de centaines de contrats ou de rapports mobilise des équipes entières, un pipeline LangExtract peut extraire automatiquement les parties contractantes, les conditions de paiement, les pénalités ou les clauses de résiliation, et les organiser en tableaux Pandas directement exploitables pour des workflows d'automatisation ou des systèmes décisionnels. Pour les équipes juridiques, financières ou opérationnelles, cela représente un gain de temps considérable et une réduction des erreurs humaines sur des tâches répétitives à fort enjeu. La bibliothèque supporte également le traitement parallèle via un paramètre max_workers, ce qui rend l'approche viable à l'échelle. LangExtract s'inscrit dans une tendance plus large d'outillage autour des LLM pour l'extraction d'information structurée, un domaine en pleine expansion depuis que les modèles de fondation ont démontré leur capacité à comprendre des textes complexes. Google positionne ici un outil de niveau intermédiaire : plus accessible que de coder une chaîne d'extraction LLM from scratch, mais plus flexible que les solutions no-code. La dépendance à l'API OpenAI (et donc à gpt-4o-mini ou ses successeurs) implique des coûts variables selon le volume de documents traités, ce qui constitue une limite pour les déploiements à très grande échelle. La prochaine évolution attendue de ce type d'outil serait la compatibilité avec des modèles open-source locaux comme Ollama, afin de supprimer cette dépendance externe et de traiter des documents sensibles sans sortir les données du périmètre de l'entreprise.

OutilsOutil
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic