Remplacer l’OCR par un Vision Language Model

• Ce cookbook est un projet open source qui explore des algorithmes de traitement vidéo et d’image à travers diverses études de cas et travaux pratiques
• Il couvre différents domaines d’application, comme l’inférence vidéo, les catalogues d’images et la recherche hybride sur des images de mode
• Par rapport à d’autres projets, il présente l’avantage de permettre l’apprentissage des algorithmes à travers divers cas concrets
• Fichiers et notebooks principaux
  • 00_quickstart.ipynb : guide de démarrage rapide du projet
  • 01_schema_showcase.ipynb : inclut des études de cas présentant différents schémas de données
  • 02_case_study_drivers_license.ipynb : reconnaissance de permis de conduire
  • 03_case_study_tv_news.ipynb : comprendre l’écran d’un journal télévisé
  • 04_visual_grounding.ipynb : exploration des algorithmes de visual grounding. Extraction de JSON à l’intérieur de boîtes dans l’image
  • 05_case_study_image_catalogue.ipynb : analyse d’un catalogue de produits de mode pour reconnaître la description produit, la catégorie, le genre cible et la saison
  • 06_fashion_images_hybrid_search.ipynb : étude de cas sur la recherche hybride d’images de mode
  • advanced_finetuning_video_inference.ipynb : techniques avancées de fine-tuning pour l’inférence vidéo

[GN⁺]

Avis Hacker News

• Idée intéressante, mais pas encore assez fiable pour une utilisation en production. Les modèles d’OCR traditionnels produisent des résultats absurdes avec une faible confiance lorsqu’ils n’arrivent pas à lire le texte. Les VLM, en revanche, génèrent avec assurance des résultats inventés lorsqu’ils n’y arrivent pas, sans aucun moyen de rapporter un niveau de confiance. Lors d’essais de reconnaissance d’écriture manuscrite, un VLM a inventé de faux noms et de fausses dates correspondant au ton du document. Il n’existe aucun moyen d’ancrer le modèle sur le texte source

• Nous avons récemment publié un benchmark open source pour évaluer les VLM et l’OCR, et de manière générale les VLM ont obtenu de meilleures performances que les modèles d’OCR traditionnels

• Avantages des VLM :

  • Reconnaissance de l’écriture manuscrite. La prise en compte du contexte aide. Autrement dit, le modèle interprète le mot ou la phrase dans son ensemble, plutôt que caractère par caractère
  • Graphiques / infographies. Les VLM peuvent interpréter des graphiques ou des organigrammes sous forme textuelle. Y compris les lignes codées par couleur

• Avantages de l’OCR traditionnel :

  • Documents standardisés (par ex. formulaires fiscaux américains)
  • Texte dense. Pensez aux manuels scolaires et aux articles de recherche en colonnes multiples. C’est le cas d’usage le plus simple pour l’OCR, mais les VLM ont plus de mal à mesure que le nombre de tokens de sortie augmente
  • Boîtes englobantes. Il n’existe pas encore de modèle fournissant des boîtes englobantes très précises. Gemini et Qwen ont été entraînés pour cela, mais ne s’en sortent pas aussi bien que les modèles traditionnels

• Il reste beaucoup de marge d’amélioration, mais des modèles comme Gemini sont particulièrement compétitifs en précision / coût

• Je me demande pourquoi tous les services d’OCR ne montrent que des captures d’écran parfaites de documents numériques. Y a-t-il vraiment tant de gens que ça qui veulent faire de l’OCR sur des données numériques ? Il suffit de copier le HTML, non ? Quand le document n’est pas numérique, où sont les captures avec des plis, des lignes décalées, des gradients d’éclairage, des doigts, etc. ?

• J’ai expérimenté vlm-run et des définitions de formulaires personnalisées, et cela fonctionne étonnamment bien avec Gemini 2.0 Flash. J’ai aussi compris que le coût était faible. On obtient les meilleurs résultats sur des formulaires simples à moyennement complexes. Des formulaires qu’un humain peut traiter avec moins de 10 minutes de formation

• Les outils d’OCR font bien ce qui est écrit sur la boîte, comme reconnaître les caractères sur le papier. L’avantage d’utiliser des vision language models est qu’on peut ajouter une logique du type : « c’est une chaîne de caractères, mais est-ce que cela ressemble à un horodatage ? »

• Ce que je veux : scanner / photographier des documents (y compris des livres entiers), les transmettre à un modèle de langage, et obtenir un document LaTeX correspondant exactement au document d’origine. En excluant les défauts du copieur / de l’appareil photo et l’angle. Il semble qu’un modèle d’apprentissage par renforcement pour cela soit possible. Il devrait pouvoir apprendre à générer du LaTeX qui reproduit l’image au pixel près

• Il faut utiliser les deux. Utiliser l’OCR et un LLM, puis corréler les deux résultats améliore fortement la qualité. On obtient non seulement la compréhension du document et le contexte, mais aussi les boîtes englobantes, etc. Je développe une app « ne jamais remplir de paperasse » et j’aimerais parler avec des personnes intéressées

• C’est peut-être dû à mon prompt, mais j’ai l’impression qu’il y a trop d’interprétation après l’embedding de l’image. Dans mon exemple, il s’est mis à résumer une partie du texte, et malheureusement de manière incorrecte. Sur une facture avec du texte tapé, il disait en réalité que si l’on soumettait après 14 h le vendredi, ce ne serait publié que le lundi suivant, mais le modèle a résumé cela par un délai de 2 à 3 jours ouvrés avant publication. C’est sensiblement différent. Je me demande s’il est possible de supprimer cette couche d’une manière ou d’une autre. La détection / reconnaissance structurée de texte en one-shot était bien meilleure que l’OCR de base

• C’est bien de voir davantage de travail dans ce domaine, mais je ne comprends pas pourquoi cela doit être lié à l’API propriétaire de quelqu’un. Changer de fournisseur de modèle et ajouter une journalisation de base ne devrait pas être assez pénible pour justifier l’onboarding d’un autre prestataire. Surtout lorsqu’il s’agit de manipuler quelque chose d’aussi sensible que des prompts LLM

• Quel est l’outil OCR en CLI le plus rapide et le plus précis ? Mon cas d’usage est simple : je veux capturer une partie de l’écran (Flameshot est très bien pour ça) et faire de l’OCR dessus. J’en ai besoin pour prendre des notes pendant du pair programming sur Zoom. J’utilise actuellement tesseract, et c’est rapide et cela fonctionne bien, mais il fait des erreurs. Ce serait bien s’il pouvait distinguer des tableaux et les convertir en tableaux ASCII ou Markdown. J’ai essayé docling, mais cela m’a semblé un peu excessif. Ça paraît lent — j’ai besoin de récupérer le texte d’une capture d’écran très rapidement. Je n’ai testé que les réglages par défaut, et j’ai l’impression qu’en l’ajustant cela pourrait s’améliorer. Quelqu’un peut-il partager son avis là-dessus ? Merci !