Unlimited OCR — le modèle de parsing de longs documents en un seul passage de Baidu

 (github.com/baidu)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Modèle d’OCR E2E basé sur DeepSeek OCR, où toute l’attention du décodeur est remplacée afin de transcrire des documents de plusieurs dizaines de pages en une seule passe avant (forward pass)
  • Le point clé est la Reference Sliding Window Attention (R-SWA), qui maintient le cache KV constant même quand la longueur de décodage augmente, bloquant ainsi la hausse des coûts mémoire et de calcul
  • Le modèle imite la mémoire de travail (working memory) humaine lors de la copie d’un livre, en oubliant progressivement les sorties lointaines pour ne référencer que le contexte voisin
  • Sur OmniDocBench v1.5, il atteint 93 %, soit 6 % de mieux que DeepSeek OCR, et établit un SOTA end-to-end sur la v1.6 avec 93,92 %
  • Au-delà de l’OCR, R-SWA est un mécanisme d’attention de parsing générique applicable à des tâches longues à base de référence comme l’ASR et la traduction

Contexte et définition du problème

  • Les humains peuvent traiter sans perte d’efficacité des tâches longues comme la transcription de centaines de pages ou la traduction de plusieurs heures d’audio, alors que les modèles d’OCR existants ne parviennent pas à parser ne serait-ce que 10 pages en une seule passe
    • Les modèles actuels fonctionnent page par page (for-loop), en réinitialisant la mémoire à chaque étape
    • Cette approche n’est qu’un contournement d’ingénierie qui fragmente un processus long et cohérent en tâches courtes isolées, sans constituer un progrès vers une intelligence orientée AGI
  • Utiliser un LLM comme décodeur améliore les performances en exploitant les distributions a priori du langage, mais à mesure que la sortie s’allonge, le cache KV accumulé augmente la consommation mémoire et ralentit progressivement la génération
  • Le comportement humain en transcription ne correspond ni à la full attention standard ni à la linear attention
    • On ne relit pas tout le texte déjà écrit : on ne se réfère qu’au contexte adjacent pour garder le cap
    • Les tokens visuels/de référence ne subissent pas de mise à jour d’état récurrente — sinon les caractéristiques visuelles s’estompent peu à peu et la précision de reconnaissance baisse

Reference Sliding Window Attention (R-SWA)

  • Chaque token accède à tous les tokens de référence (tokens visuels + prompt), tandis que l’attention de sortie est limitée aux n derniers tokens (128 par défaut)
    • Cela permet à chaque token de percevoir l’image complète tout en suivant de façon autonome l’avancement de l’OCR via des transitions d’état dans une fenêtre glissante causale
    • Pendant l’inférence, le cache KV reste constant, ce qui réduit la pression mémoire et le coût de calcul
  • L’attention est restreinte à une fenêtre en deux segments de taille m+n
    • m est la fenêtre de préfixe contenant les tokens visuels et le prompt ; elle reste fixe durant une inférence unique et dépend seulement du nombre de pages et de la résolution, pas de la longueur de décodage
    • n est la fenêtre de la zone de décodage, de taille fixe, qui glisse causalement

  • Gestion du cache KV

    • Le baseline DeepSeek OCR utilise une MHA standard, ce qui fait croître indéfiniment la taille du cache KV jusqu’à Lm + T
    • R-SWA conserve l’ensemble du cache de préfixe Lm, mais pour la partie générée ne garde que les n tokens les plus récents, avec une taille de cache bornée par Lm + min(n,T) ≤ Lm + n
    • Quand la longueur de sortie devient suffisante, le ratio de cache ρ(T) converge vers 0 → la croissance linéaire est ramenée à une constante

  • Analyse des kernels

    • Dans les mesures du kernel Flash Attention v3, la MHA standard de DeepSeek OCR voit sa latence augmenter à chaque étape de décodage, alors qu’Unlimited OCR garde une durée constante grâce à R-SWA
    • DeepSeek OCR présente des pics lorsque la longueur du cache KV franchit certains seuils d’alignement et fait chuter l’efficacité des transferts de données ; ces pics n’apparaissent pas avec R-SWA
    • En inférence, la mémoire GPU du modèle d’origine augmente linéairement, alors qu’Unlimited OCR reste stable — cette stabilité simultanée du calcul et de la mémoire rend possible le parsing de longs documents

Architecture du modèle

  • Basé sur DeepSeek OCR, avec combinaison de DeepEncoder et d’un décodeur MoE (3B au total, 500M de paramètres actifs)
    • La MHA existante est remplacée par R-SWA, qui ajoute au cache KV de référence m un buffer KV de sortie n à capacité fixe pour permettre le parsing long
    • Le cache KV est implémenté comme une file de capacité m+n ; à chaque nouveau token généré, le KV du token en position (m+1) est expulsé afin de garantir l’absence d’augmentation du coût et de la mémoire

  • DeepEncoder

    • Cascade de SAM-ViT et CLIP-ViT, avec compression de tokens par 16 au niveau du bridge — la première partie traite les tokens d’image d’origine avec window attention, et l’attention globale est réservée aux tokens compressés
    • Cette approche maintient de faibles activations lors de l’encodage d’images haute résolution pour économiser la mémoire GPU, en compressant une image PDF 1024×1024 à seulement 256 tokens
    • Deux modes sont proposés : Base pour le multipage (1024×1024) et Gundam pour la page unique (résolution dynamique)
    • Les tokens visuels sont encodés une seule fois et restent statiques durant tout le processus, sans transition d’état avec la sortie

Configuration d’entraînement

  • Entraînement sur environ 2 millions d’exemples de documents OCR, avec un ratio page unique / multipage de 9:1
    • Les PDF d’une seule page sont annotés avec Paddle OCR, en reliant coordonnées et contenu de chaque bloc pour constituer la ground truth ; les coordonnées sont normalisées dans l’intervalle 0–1000
    • Les jeux multipages sont synthétisés par concaténation de pages uniques ; environ 200 000 échantillons (2 à 50 pages) utilisent le séparateur <page>, avec empaquetage dans des séquences complètes de 32K tokens
  • 4 000 étapes d’entraînement supplémentaires à partir d’un checkpoint DeepSeek OCR, batch global 256, séquence maximale 32K, avec 8×16 GPU A800
    • Pendant l’entraînement, DeepEncoder est gelé et seuls les paramètres du LLM sont appris
    • Optimiseur AdamW, scheduler cosine annealing, taux d’apprentissage initial 1e-4, DeepEP (EP=4), sur base du framework Megatron-LM
    • Pour l’inférence, la gestion du cache KV de R-SWA est implémentée dans la bibliothèque Transformers, avec prise en charge optimisée dans le moteur SGLang — les deux frameworks fonctionnent avec un TPS et une mémoire GPU constants

Résultats d’évaluation

  • Le benchmark principal est OmniDocBench (v1.5/v1.6), qui évalue les capacités de parsing sur plusieurs dimensions : texte, formules, structure des tableaux, ordre de lecture, etc.
    • La v1.6 est la version la plus récente, avec 296 images de test de plus que la v1.5 ; la v1.5 permet la comparaison avec des modèles classiques, dont DeepSeek OCR
    • Un jeu de test interne pour l’OCR longue séquence a aussi été construit, avec romans, documents et articles, répartis en catégories 2/5/10/20/40+ pages (au moins 10 ouvrages par catégorie)

  • Performances principales

    • Avec seulement 2M de données et un entraînement additionnel, le modèle atteint un SOTA end-to-end ; sur la v1.5, la distance d’édition du texte baisse de 0,035 et le TEDS des tableaux progresse de 5,96 %
    • Sur la v1.6, le score global atteint 93,92 %, soit un SOTA end-to-end — preuve qu’un remplacement complet de l’attention standard par R-SWA de largeur 128 reste efficace et sans perte
    • Grâce à 0,5B de paramètres MoE actifs, l’inférence reste très efficace, avec 5580 TPS en mode Base (soit 12,7 % plus rapide que les 4951 TPS de DeepSeek OCR)

  • Analyse par sous-catégorie

    • Par rapport à DeepSeek OCR, les gains sont cohérents sur tous les indicateurs, au point d’évoquer une amélioration de type free lunch
    • Face à DeepSeek OCR 2, le modèle est meilleur sur 7 indicateurs sur 9 pour la distance d’édition du texte et l’ordre de lecture
    • Il ne montre aucune faiblesse sur des mises en page complexes comme les PPT, journaux, magazines ou notes

  • Parsing long document

    • Grâce à R-SWA, il peut prefill en un seul passage des dizaines à des centaines de pages, puis parser de façon continue de la première à la dernière page tout en gardant une latence de sortie stable avec cache KV fixe
    • Il reste robuste même avec une entrée simultanée de 20 pages, en conservant une distance d’édition inférieure à 0,11 sur 40+ pages et un Distinct-35 de 97 %
    • Les erreurs de répétition proviennent de la difficulté à distinguer les petits caractères dans le mode multipage Base (1024×1024), et non d’une perte de direction liée à R-SWA

Analyse de l’efficacité

  • Comparaison du TPS de sortie dans des conditions idéales de parallélisme (longueur de prefill fixée à 10)
    • À 256 tokens, les vitesses d’inférence des deux modèles sont presque identiques
    • Quand la longueur de sortie augmente, le TPS de DeepSeek OCR baisse continuellement, et à 6 000 tokens il est 35 % derrière Unlimited OCR
    • Cela confirme qu’une vitesse de génération constante est une exigence essentielle pour les tâches d’OCR longue séquence

Limites et travaux futurs

  • Avec une longueur de contexte finie (par exemple 32K), le parsing réellement illimité reste impossible à cause de la contrainte sur la longueur de prefill — malgré le fort taux de compression de DeepEncoder, le prefill s’allonge à mesure que les pages s’accumulent
  • À court terme, l’équipe prévoit d’entraîner des modèles à contexte plus long, comme 128K, pour prendre en charge davantage de pages en prefill
  • À plus long terme, l’objectif est de construire un prefill pool et d’entraîner le modèle à aller récupérer automatiquement des chunks KV de prefill, pour reproduire l’effet d’un humain qui tourne les pages et ainsi atteindre un véritable OCR illimité
  • R-SWA doit aussi être transféré à des tâches à base de référence comme l’ASR et la traduction

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Assez intéressant. Si j’ai bien compris, les chercheurs semblent avoir trouvé un hack d’architecture qui évite à l’IA d’accumuler sans cesse de la mémoire lorsqu’elle lit de longs documents
    En général, quand une IA transcrit un PDF de 100 pages, elle essaie de se souvenir de tous les mots déjà lus, et cette mémoire à court terme, le cache KV, augmente linéairement en O(N), jusqu’à épuiser la VRAM ou atteindre une limite. Les développeurs finissent donc par écrire du code bricolé qui découpe le PDF page par page avant de recoller le tout
    Unlimited OCR sépare l’attention en deux voies avec le Reference Sliding Window Attention (R-SWA). L’une est une référence globale qui voit l’image du document source dans son intégralité, l’autre est une génération locale qui limite la mémoire textuelle produite par le modèle à une fenêtre glissante étroite, par exemple les 128 derniers mots. Ça semble assez intéressant pour l’IA locale, et j’ai hâte de voir ce que la communauté va construire et étendre

    • On dirait aussi qu’il y a là quelque chose de très adapté à la conversation. J’expérimente depuis assez longtemps la capsulisation des longues conversations : il existe un contexte de haut niveau et des faits qui changent peu, comme le nom des participants ou des éléments de contexte
      À l’inverse, des faits très fins comme ce qu’on a mangé ce matin peuvent être utiles sur le moment, mais n’ont guère d’intérêt à long terme en dehors de tendances générales. Pour reconstruire une conversation, il faut trouver le bon équilibre sans ramener tout ce qui a été discuté jusque-là, donc cette approche mérite d’être creusée
    • Je n’ai pas encore lu l’article en entier, mais la fenêtre de génération locale me paraît un peu petite. En particulier, comme les entrées image consomment beaucoup de tokens, ce serait mieux d’avoir quelque chose de plus grand, au moins autour de 4096 mots, selon l’emplacement des couches d’attention locale
    • C’est exactement ce que je fais pour l’OCR d’images. Quand j’envoyais une grande image découpée en plusieurs petites images au LLM, c’était parfait à chaque fois, mais si je fournissais l’image entière, le résultat était catastrophique
    • Je pensais que les principaux outils LLM prenaient déjà en charge l’attention à fenêtre glissante
    • C’est pour ça que LeetCode est utile. À force d’en faire, on finit par comprendre pourquoi ces techniques existent et comment elles sont réellement utilisées. Il y a plein de choses intéressantes

  • J’ai récemment acheté une tablette pour partitions, principalement pour remplacer les recueils de jazz Real Book pendant les jam sessions. Les scans faits avec l’appareil photo du téléphone sont passables, mais la taille est fixe et il y a beaucoup d’artefacts
    Ce serait bien de pouvoir transposer à la volée pour des instruments en Bb ou en Eb, mais comme ce sont des scans, c’est évidemment impossible. En regardant l’état de la reconnaissance optique de partitions, j’en suis arrivé à la conclusion que la musique est presque un territoire vierge du point de vue de l’IA. La reconnaissance optique de partitions est assez médiocre, et la compréhension de la théorie musicale par l’IA est également médiocre dès qu’il s’agit de lire de vraies partitions. Les LLM se débrouillent à peu près pour les explications textuelles de concepts théoriques qui ont sans doute figuré dans les textes en ligne utilisés pour l’entraînement
    Le problème semble être qu’il manque encore un format numérique capable d’encoder correctement les points sur le papier que lisent les musiciens. La notation musicale est assez riche. MIDI a surtout été conçu pour capturer les aspects nécessaires à la lecture ou à l’exécution, et ne contient donc pas tout ce qu’il faut pour une compréhension symbolique. MusicXML semble être le format numérique le plus proche de ce que veulent les musiciens, mais il manque de bons corpus d’entraînement reliant les représentations MusicXML aux images de partitions ou à l’audio. Cela semble venir du fait que MusicXML ne contient pas, à lui seul, assez d’informations pour la gravure de partitions
    Des outils comme MuseScore doivent suivre beaucoup d’informations de mise en page que MusicXML ne peut pas représenter. Le format LilyPond est moins verbeux que MusicXML et contient un peu plus d’informations utiles aux créateurs de partitions, mais la plupart des gens ne créent pas leurs partitions en LilyPond. J’ajouterais qu’à cause de l’état des polices jazz, LilyPond est décevant. Je n’aime pas voir des partitions « de style classique » dans un contexte jazz. À chaque amélioration incrémentale qui rend l’OCR assez convaincant, ça me rappelle à quel point l’OMR est désastreux

    • Le format utilisé par les musicologues et chercheurs en musique, c’est MEI : https://music-encoding.org/ et le graveur de référence est verovio : https://www.verovio.org/index.xhtml
      verovio peut graver au format SVG tout en conservant autant que possible les informations de la partition MEI d’origine, ce qui permet d’extraire assez de métadonnées pour constituer de vrais jeux de données de détection pour des modèles de deep learning. Il existe aussi un script bricolé qui fabrique un dataset COCO à partir d’un ensemble de partitions gravées avec verovio : https://github.com/kwon-young/music/blob/main/svg2pl.py
      Le dataset synthétique de partitions créé ici a également été publié : https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... Toute personne souhaitant entraîner un détecteur dessus est la bienvenue. Si l’OMR est autant laissé de côté, c’est surtout parce que la plupart des gens sous-estiment énormément la difficulté de cette tâche. C’est un travail très particulier, avec une variété de formes extrême et une grammaire graphique très complexe mêlée à tout cela
    • L’idée que « la musique est presque partout un territoire vierge pour l’IA » est vraiment juste. Ma copine étudie la musicologie et, à cause d’un handicap physique, elle a parfois du mal à prendre des notes, donc je lui fabrique petit à petit de petites applis basées sur l’IA, comme du TTS/OCR, pour l’aider
      Et dans ce cadre, il devient douloureusement évident que la musique n’a jamais été considérée comme une partie importante dans pratiquement aucun dataset d’entraînement pour l’IA. Ces temps-ci, la capacité d’Opus 4.8 à comprendre et expliquer la théorie musicale est assez impressionnante, mais si on lui demande de transcrire des partitions ou de faire de l’OCR/OMR, il produit avec assurance des résultats MusicXML/LilyPond du niveau de « 2 + 2 = cheval ». J’espère que ce domaine négligé sera lui aussi emporté par la vague montante de l’IA, mais pour l’instant il reste injustement sous-estimé
    • Si vous n’avez besoin que d’analyse d’accords, il existe la notation Harte, qui vise à représenter les notes sans ambiguïté : https://ismir2005.ismir.net/proceedings/1080.pdf
      Bien sûr, elle ne fournit pas toutes les informations supplémentaires nécessaires à la gravure ou à une représentation complète de la musique, mais il existe des datasets de recherche comme https://github.com/smashub/choco. Pour des travaux d’analyse, j’ai aussi utilisé le dataset https://github.com/MarkGotham/When-in-Rome, même s’il ne correspond pas non plus à 100 % à ce que je cherche. Pour remplacer des standards de jazz sur tablette avec un usage de transposition, l’application « iReal Pro » pourrait vous plaire. Pour ce cas d’usage, c’est nettement mieux qu’un scan photo
    • Que pensez-vous d’un format de gravure de partitions comme https://abcnotation.com/ ?
    • En suivant le domaine de l’OCR musical, j’ai l’impression que jusqu’ici la seule solution vraiment correcte est soundslice. Après le scan, si l’on ne vérifie que quelques cas limites, le résultat est excellent. C’est un service payant d’une petite entreprise, mais il mérite largement d’être soutenu

  • Écrire « merci aux modèles et idées valables de Deepseek-OCR, Deepseek-OCR-2 et PaddleOCR » est une attitude élégante

    • Je ne comprends pas pourquoi certains le prennent sur un ton sarcastique

  • Au passage, « Unlimited OCR Works » est une parodie de Unlimited Blade Works de Fate/stay night. À l’origine, Unlimited Blade Works est un pouvoir magique censé copier les armes créées par d’autres

  • L’article est disponible sur https://arxiv.org/abs/2606.23050
    À titre indicatif, je fais de l’OCR local pour un petit usage RAG autour de citations lues dans des livres, et moi aussi je découpe les entrées en chunks pour économiser la RAM, donc je trouve intéressant qu’une approche aussi naturelle fonctionne aussi avec des modèles en streaming

  • Cela semble plus prometteur que ce que Mistral vient juste de sortir. Une coïncidence ? Je ne pense pas
    Cette approche pourrait aussi servir d’une certaine manière à la génération d’images. On pourrait imaginer qu’après avoir lu ou vu une image, le modèle commence à la redessiner dans un outil comme Illustrator/Inkscape ou en SVG, puis complète plus tard les parties manquantes

  • Je me demande comment cela se compare à infinty parser 2, qui semblait écraser les autres outils OCR : https://huggingface.co/datasets/allenai/olmOCR-bench
    Pour être juste, il n’existe pas de benchmark OCR avec un seul vainqueur, et cet outil n’apparaît encore nulle part

  • Je vais peut-être avoir l’air de quelqu’un qui ne comprend rien au monde, mais quelle est la vraie raison pour laquelle des entreprises publient en open source de très bons logiciels ?
    Si c’est Baidu ou Google, ne devraient-ils pas plutôt les garder pour eux afin d’en extraire toute la valeur sans laisser les concurrents les copier ?

    • Même dans les grandes entreprises, il y a des gens qui croient à l’idéal de l’open source et qui parviennent à convaincre leur employeur d’autoriser la publication du projet
      L’entreprise y gagne en réputation, ce qui aide le funnel de recrutement. Parfois, cela peut aussi servir stratégiquement à déstabiliser des concurrents, comme quand Meta a publié Ollama
    • Publier des modèles open source peut rogner les revenus des laboratoires d’IA américains. Si cela réduit l’argent qu’ils peuvent réinvestir pour gagner la compétition à long terme, cela peut avantager la Chine

  • Chaque tentative d’OCR avec l’IA que j’ai vue mélangeait toujours des résultats inventés, ce qui la rendait difficile à utiliser en production. Je me demande si c’est aussi le cas ici
    Un exemple simple : des mots qui devraient rester dans une autre langue sont automatiquement traduits en anglais, ce qui ruine le résultat

    • On finit par ne plus vouloir de machine learning à un niveau supérieur au mot, c’est-à-dire au niveau des paires de mots, des expressions, des phrases, des documents ou des corpus
      Pour une transcription, on veut un résultat presque certain, ou bien une indication claire que le texte n’a pas pu être lu avec certitude. On peut faire des suppositions à partir du contexte, mais avec certains OCR il faut savoir si la supposition vient d’autre chose que du simple fait que des lettres, dans cet ordre, forment un mot
      Par exemple, dans des documents de recensement sur familysearch.com, un transcripteur a « corrigé » un prénom en Joseph, alors que les lettres réellement écrites à la main étaient Josepth, qui était en fait une variante orthographique locale. Dans d’autres documents, le rédacteur avait abrégé « Joh », et un transcripteur humain l’a probablement rendu par John ; c’était le plus plausible, mais factuellement faux. Parfois, il est important de savoir qu’il ne s’agit que d’une supposition ; d’autres fois, on a juste besoin de la meilleure supposition possible
    • Si je voulais un résultat de reconnaissance à 100 %, je combinerais cette méthode avec un modèle d’image de reconstruction du document original. L’idée serait de recréer le document d’origine à partir du texte transcrit et de la mise en page
      En utilisant tout le document sauf la page ou le paragraphe qu’on veut tester, on peut éviter que le passage évalué soit simplement régénéré à l’identique à partir d’artefacts visuels. Après reconstruction, il suffirait de faire une comparaison optique pour repérer et aligner les caractères divergents, puis d’itérer pour trouver les erreurs. Ce serait coûteux, mais cela pourrait garantir une reconnaissance à 100 %
    • Je suis en train d’utiliser ce modèle sur une 4090 pour transcrire un PDF de grammaire japonaise. Le document est rédigé en anglais et contient beaucoup d’exemples en japonais ; dans la partie que j’ai vérifiée, ça fonctionne plutôt bien
      La sortie conserve correctement les kanji/hiragana et l’anglais là où il le faut, sans essayer de traduire. Il a converti environ 200 pages par heure
    • Je serais curieux de savoir quels modèles ou outils vous avez utilisés

  • Je ne sais pas ce qu’est devenu Reducto. Il y a 12 à 15 mois, ça paraissait assez prometteur