Nanonets-OCR-s – un modèle OCR qui convertit les documents en Markdown structuré

 (huggingface.co)
26 points par GN⁺ 2025-06-17 | 2 commentaires | Partager sur WhatsApp
  • Un modèle OCR image-vers-Markdown haute performance qui va au-delà de la simple reconnaissance de caractères pour convertir l’ensemble d’un document en une structure Markdown
  • Convertit les formules mathématiques au format LaTeX, ajoute des descriptions automatiques aux images, et restitue les tableaux en HTML/Markdown, afin de produire un résultat optimisé pour une utilisation avec les LLM
  • Reconnaît les signatures, filigranes et cases à cocher et les convertit en formats tels que <signature>, <watermark>, ☐/☑, montrant une excellente capacité de traitement selon les composants du document
  • Facile à exploiter via Transformers de Hugging Face ou un serveur vLLM, et également utilisable sous forme d’application web via la bibliothèque docext
  • Offre une très grande précision et un niveau de structuration élevé sur divers types de documents et mises en page complexes, ce qui le rend très utile pour les contrats, formulaires, rapports, etc.

Vue d’ensemble du projet et importance

  • Nanonets-OCR-s est un modèle innovant qui dépasse les fonctions de OCR classique (reconnaissance optique de caractères) en analysant le sens et la structure des documents pour produire le résultat au format Markdown
  • Il distingue formules, images, tableaux, cases à cocher, signatures et filigranes, puis les convertit avec des balises et modes de représentation pertinents (LaTeX, HTML, Markdown, etc.), afin de fournir une sortie adaptée aux traitements downstream ou au traitement documentaire fondé sur des LLM (grands modèles de langage)
  • Par rapport aux projets OCR open source existants, il affiche de meilleures performances sur les structures documentaires complexes et l’extraction de divers éléments sémantiques, avec un potentiel plus élevé d’intégration dans des workflows automatisés
  • Il s’agit d’une version fine-tunée du modèle Qwen2.5-VL-3B-Instruct, capable d’identifier divers composants de document et de les baliser avec un markup porteur de sens

Caractéristiques principales

  • Reconnaissance des formules LaTeX
    • Convertit et restitue automatiquement en syntaxe LaTeX les équations et formules mathématiques contenues dans le document, selon qu’il s’agit d’un format inline($...$) ou display($$...$$)
  • Description intelligente des images
    • Pour chaque image, décrit en détail, dans une balise <img>, la nature, le style et le contenu de l’image
    • Décrit aussi des logos, graphiques et diagrammes variés avec leur contexte et leur sens, afin de les convertir en entrées adaptées à l’usage avec les LLM
  • Détection et séparation des signatures
    • Traite les images de signature séparément du texte, dans une balise <signature> dédiée
    • Présente une forte valeur d’usage pour le traitement automatisé des documents juridiques et commerciaux
  • Extraction des filigranes
    • Détecte le texte de filigrane inséré dans le document et l’organise séparément dans une balise <watermark>
  • Conversion des cases à cocher et boutons radio
    • Restitue les éléments sous forme de symboles Unicode standard : * ☐ (non coché), ☑ (coché), ☒ (refusé)
    • Améliore la fiabilité du traitement de documents de type formulaire, questionnaire ou demande
  • Extraction de structures tabulaires complexes
    • Convertit même des tableaux complexes en tableaux Markdown et HTML, offrant une grande réutilisabilité

Principaux modes d’utilisation

Exemple de code Python

  • Il est possible de charger et d’exécuter facilement le modèle à l’aide de la bibliothèque transformers de Hugging Face
  • En fournissant une image en entrée, on obtient une sortie sous forme de Markdown structuré comprenant texte, tableaux, formules, descriptions d’images, filigranes, etc.
  • Les numéros de page ou filigranes sont encapsulés et distingués par ,
  • Les cases à cocher sont restituées sous forme de symboles Unicode (☐, ☑)

Utilisation avec vLLM

  • Il est possible d’enregistrer le modèle sur un serveur vLLM et d’y accéder facilement via une API compatible OpenAI
  • Lors d’une entrée image, le résultat de conversion est restitué dans un format cohérent pour le texte, les tableaux, les formules, les filigranes, etc.

Utilisation du package docext

  • Via un package séparé nommé docext, il est possible d’appliquer directement Nanonets-OCR-s à la structuration de documents en exécutant simplement une commande dédiée
  • Voir la documentation GitHub

À lire aussi

2 commentaires

 
GN⁺ 2025-06-17
Avis Hacker News

  • Je travaille chez Nanonets, et je suis très enthousiaste à l’idée d’annoncer la sortie de Nanonets-OCR-s, un modèle VLM de 3B
    C’est un modèle léger optimisé pour convertir des documents en Markdown propre et structuré
    Il a appris la structure et le contexte des documents (tableaux, formules, images, diagrammes, filigranes, cases à cocher, etc.)
    Parmi ses principales fonctionnalités : reconnaissance des formules LaTeX (avec distinction correcte entre formules inline et en bloc), descriptions d’images intégrées (via la balise img, avec prise en charge des graphiques, logos, schémas, etc.), détection et séparation des signatures (sortie dans un bloc signature), extraction des filigranes (stockés avec une balise watermark), gestion intelligente des cases à cocher et boutons radio (conversion Unicode pour améliorer la fiabilité du post-traitement), extraction de structures de tableaux complexes (y compris les tableaux à lignes/colonnes multiples, bien rendus en Markdown et HTML)
    Si vous voulez l’essayer vous-même, vous pouvez consulter Huggingface ou Docext Colab

    • Le bon lien pour Docext est README.md

    • Je me demande si le LLM utilisé présente des hallucinations

    • Je me demande s’il est possible d’extraire les images elles-mêmes, ou s’il faut toujours un processus d’extraction séparé

    • Je me demande si cela peut servir à parser des photos ou PDF de menus de restaurant selon un schéma JSON (probablement avec l’aide d’un LLM de post-traitement), ou si un grand LLM multimodal serait mieux adapté à cet usage

  • J’ai essayé plusieurs LLM pour traduire un dictionnaire shipibo (langue autochtone du Pérou)-espagnol en dictionnaire anglais, mais les deux colonnes, les retours à la ligne bizarres et le mélange de shipibo et d’espagnol dans les définitions rendent la compréhension difficile
    En plus, la qualité du scan n’est pas bonne
    Je me dis que je devrais essayer ce modèle

  • Cela fait longtemps que je cherche une solution capable de prendre tout le contenu accumulé pendant des décennies dans Word et PowerPoint, puis de le convertir dans une forme normalisée afin de pouvoir réutiliser chaque élément dans d’autres formats
    C’est un bloc de construction essentiel pour mettre en place ce système
    Il me faudrait maintenant une fonction d’archivage ou d’historique, pour pouvoir archiver et recharger facilement chaque élément
    Vraiment beau travail

    • Avis selon lequel il serait peut-être plus simple de commencer par une conversion de base avec unoconv ou pandoc, puis d’utiliser un LLM pour nettoyer le texte brut

  • C’est dommage que ce type de modèles vise uniquement le Markdown
    En pratique, le Markdown a plusieurs variantes et prend mal en charge les notes de bas de page, bibliographies, figures, etc.
    Il faudrait un format avec une spécification plus structurée et plus claire

    • En réalité, nous avons entraîné le modèle à faire à la fois la conversion en Markdown et le balisage sémantique
      Par exemple, les formules sont extraites en LaTeX, les images (diagrammes, figures, etc.) sont décrites en détail via la balise img
      Les signatures (signature), filigranes (watermark), numéros de page, etc. utilisent aussi des balises
      Les tableaux complexes (multi-lignes/colonnes) sont sortis en tableaux HTML plutôt qu’en Markdown

    • Le concept de « Markdown structuré » m’enthousiasmait plus que le modèle OCR LLM lui-même, mais au final cela donne l’impression de se limiter à du balisage de certains éléments, donc l’utilité en dehors du modèle semble un peu restreinte

  • Je me demande quels sont les avantages et inconvénients par rapport à docling(https://github.com/docling-project/docling)

  • Je me demande quelle est la différence avec Datalab/Marker(https://github.com/datalab-to/marker)
    J’ai comparé beaucoup de convertisseurs PDF->MD, et jusqu’ici Marker est le meilleur, même s’il n’est pas parfait

    • D’après mon expérience personnelle, Marker s’en sort plutôt bien pour convertir des articles mêlant formules complexes et code
      Par exemple, si on traite avec Marker une page d’un article sur la transformation de Laplace inverse en Fortran, où se mélangent formules (inline/display) et blocs de code monospace, un inline $\sigma_0$ devient « <sup>s</sup> 0 » et $f(t)$ devient « <i>f~</i>~t*! »
      La force de ce modèle est de produire correctement ce type d’éléments en interne
      Capture d’écran de référence (https://imgur.com/a/Q7UYIfW)

    • Je commence tout juste mes propres comparaisons croisées, donc si quelqu’un peut partager une liste de candidats, ce serait vraiment apprécié

  • J’ai écrit moi-même un script Powershell pour appliquer ce modèle à des PDF depuis n’importe où
    En pratique, comme mon GPU (1080 8GB) est ancien, l’exécution est assez lente (au moins 5 minutes par page)
    Si quelqu’un veut essayer un utilitaire de conversion PDF vers Markdown fonctionnant sur Cloud Run (avec support GPU externe), dites-le-moi
    Je partagerai aussi le lien une fois ce sera terminé

    • Je viens justement de le faire tourner sur Cloud Run et je rapporte un exemple de résultat
      Sur une partie de animate.pdf, le titre, l’auteur, l’éditeur, les illustrations en noir et blanc (décrites avec la balise img) et la balise de numérisation Google sont bien extraits
      La table des matières est également parfaitement sortie sous forme de tableau
      À part la lenteur, je suis très satisfait des fonctionnalités et de la précision

    • Je suis très intéressé par un service PDF vers Markdown utilisant Cloud Run

  • Je me demande comment sont gérés les documents contenant des tableaux à colonnes multiples ou lignes multiples (exemple : rowspan en page 1, colspan en page 29 de ce PDF)

  • Je me demande quelles sont les performances en reconnaissance de texte non anglais
    D’après ce que je sais, les OCR basés sur des LLM sont bien moins performants que les OCR traditionnels pour les langues étrangères

    • Je me demande si c’est fondé sur une expérience personnelle ou sur une compréhension théorique
      Dans mon expérience, quand on utilise directement Google Translate et ChatGPT sur des images, ChatGPT est toujours meilleur
      Il traduit et explique très bien même des menus manuscrits en japonais

  • Un modèle qui ne mentionne pas de prise en charge multilingue a en pratique des performances très mauvaises sur les PDF non anglais

    • En pratique, il a surtout été entraîné sur de l’anglais, mais une partie des données d’entraînement contient aussi du chinois et diverses langues européennes
      De plus, le modèle de base (Qwen-2.5-VL-3B) est multilingue
      J’ai déjà vu sur Reddit un message disant qu’il marche bien aussi en chinois (lien)
 
chakankim 2025-06-18

J’ai testé le traitement d’un échantillon de ticket de caisse coréen : c’est lent, mais il le lit parfaitement.