OvisOCR3, avec 0,8 Md de paramètres, devance les modèles OCR : 96,74 sur OmniDocBench v1.6

Des chercheurs d'ATH-MaaS présentent OvisOCR3, un modèle vision-langage compact de 0,8 Md de paramètres, qui remplace tout un ensemble de systèmes OCR ultra-spécialisés. Un seul jeu de poids analyse des documents, reconnaît du texte sur des images quelconques, extrait les champs clés de formulaires et de tickets de caisse, décrit les graphiques et les illustrations présents dans les documents, et recolle les tableaux étalés sur plusieurs pages. Sur OmniDocBench v1.6, le modèle obtient 96,74 points, et il prend la première place d'OCRBench v2. Les poids et des exemples d'inférence sont publiés sur Hugging Face, dans le dépôt ATH-MaaS/OvisOCR3.

Cinq enseignants de 4 Md de paramètres pour un seul élève

La question centrale du projet : comment faire tenir cinq compétences différentes dans 0,8B de paramètres ? Les auteurs commencent par poursuivre l'entraînement du modèle sur un mélange de données réelles et synthétiques (continued pretraining). Vient ensuite une étape de mid-training équilibré par domaine : les tâches diffèrent fortement par le volume de données et la longueur des réponses. Une page convertie en Markdown et un court champ extrait d'un ticket de caisse relèvent d'ordres de grandeur différents, et sans rééquilibrage, les tâches longues écraseraient facilement les courtes.

Vient ensuite la distillation on-policy multi-enseignants. Cinq enseignants de domaine, de 4 Md de paramètres chacun et un par spécialité, transfèrent leurs connaissances au modèle commun. La distillation on-policy signifie que l'élève génère lui-même ses réponses, que les enseignants évaluent et corrigent. La chaîne se termine par un apprentissage par renforcement sur tâches mixtes, avec des récompenses propres à chaque domaine : chaque type de tâche a sa propre métrique de qualité.

Où le modèle prend l'avantage

Les auteurs ont comparé OvisOCR3 à des VLM généralistes et à des modèles OCR spécialisés, sur des benchmarks publics et internes. Voici les résultats pour les cinq familles de tâches :

• OmniDocBench v1.6 (analyse de documents) : score global de 96,74.
• PureDocBench, Real5-OmniDocBench, MDPBench : meilleur score global parmi les modèles comparés.
• OCRBench v2 : première place, avec 65,9 sur le split anglais et 61,3 sur le split chinois.
• OCRBench : le modèle devance les modèles de référence utilisés pour la comparaison.
• Quatre benchmarks d'extraction d'informations clés (KIE) : meilleurs résultats sur les quatre.
• DocFigCapBench (légendes d'illustrations de documents) : meilleur F1 de localisation ; la qualité des légendes est proche de celle de Qwen3.8-Max.
• CrossTabBench (tableaux sur plusieurs pages) : première place sur le Relation F1.
• MPDocBench-Parse : meilleur TEDS sur les tableaux tronqués.

La première place sur OCRBench v2 compte en soi : ce benchmark ne teste pas seulement la lecture du texte, mais aussi différents scénarios de travail avec ce texte, dans deux langues. Le score du split chinois est inférieur à celui du split anglais, mais le modèle est en tête sur les deux.

Les tableaux qui ne tiennent pas sur une page

La reconstitution de tableaux sur plusieurs pages mérite une attention particulière. Rapports financiers, spécifications et registres reportent régulièrement des lignes sur la page suivante, et un parseur page par page classique brise la structure : l'en-tête reste sur une page, les données passent sur l'autre. OvisOCR3 rétablit les liens entre les fragments, et c'est précisément là qu'il domine, sur le Relation F1 comme sur le TEDS des tableaux tronqués. Pour des usages comme l'ingestion de documents dans un système RAG ou l'automatisation comptable, c'était un point douloureux, longtemps traité à coups de rustines.

Le modèle arrive dans une vague de travaux similaires. La recherche sémantique de Hugging Face fait apparaître à ses côtés PolyOCR-Venus, Xiaomi-OCR-0, Jina-OCR-v1 et une étude sur des VLM légers pour l'OCR avec sortie JSON structurée. Le marché se dirige clairement vers de petits modèles unifiés, plutôt que vers des chaînes composées d'un détecteur, d'un module de reconnaissance et d'un post-traitement.

Qui devrait l'essayer

Avec 0,8 Md de paramètres, le modèle peut tourner sur du matériel modeste : une seule carte graphique grand public, dans un périmètre privé, sans envoyer les documents vers une API externe. C'est intéressant pour les équipes qui traitent des scans de contrats, des factures, des formulaires et des rapports de plusieurs milliers de pages. Un seul moteur à la place de cinq simplifie le déploiement et la maintenance.

Les limites sont, elles aussi, claires : les comparaisons ont été réalisées par les auteurs eux-mêmes, et une partie des benchmarks est interne. Avant de modifier un pipeline de production, il vaut donc mieux tester le modèle sur ses propres documents, notamment sur des polices rares, des scans de mauvaise qualité et des tableaux multipages. Les auteurs sollicitent eux-mêmes les retours de la communauté, et les premières mesures indépendantes devraient donc arriver vite.