Par Jay depuis 凹非寺
QbitAI | compte officiel WeChat QbitAI
Quoi ?! RSI appliqué à l'OCR, avec des résultats aussi bluffants ??
Récemment, un modèle open source national de seulement 1.3B de paramètres a dynamité l'analyse de documents.
OmniDocBench, olmOCR-Bench et DocParsingBench : premier dans les trois classements.
Assez parlé des benchmarks, regardons directement des exemples visuels.
Des notes manuscrites de mathématiques supérieures à l'ancienne, converties en MD en un clic.
Il peut même dessiner des structures chimiques...
Incroyable, pratiquement tout devient analysable.
Mais ce que je n'avais pas prévu, c'est que la vitesse est aussi folle ???
Sur une seule RTX PRO 6000, l'analyse documentaire de bout en bout de 100 pages n'a pris que101 secondes。
Aïe, l'efficacité de la société A pour distiller des livres papier va décoller (ironie).
Ça fait aussi un carton dans la communauté internationale des développeurs, avec déjà plus de 1.1K étoiles GitHub.
Et un moment, c'était même la Daily News la plus en vogue sur Twitter.
Et tout cela repose sur le concept le plus sexy de l'industrie de l'IA aujourd'hui :
RSI.
Cette nouvelle espèce d'OCR à auto-amélioration s'appelle OXR.
Optical « Everything » Recognition.
Premier mondial dans les trois classements
L'analyse de documents, une montagne qui semble sans grande proue technique, mais jamais encore entièrement conquise.
Face à un PDF en apparence banal, l'OCR traditionnel tourne souvent au désastre.
Articles à deux colonnes fusionnés, formules manuscrites reconnues en fouillis de caractères, grands tableaux inter-pages dont la structure s'effondre, et pour les formules chimiques, beaucoup d'outils les jettent carrément comme des lignes incohérentes...
Une fois cette extraction de mauvaise qualité injectée dans un RAG, aussi intelligent soit le modèle, tous les Tool Calls en aval tombent à l'arrêt.
Aujourd'hui, cette barrière qui empêchait l'IA d'accéder à un contexte de qualité a enfin été dynamitée.
- OmniDocBench : 97.18, premier (open source par le Shanghai Artificial Intelligence Laboratory, couvrant 10 types de documents complexes)
- olmOCR-Bench : 87.84, premier (lancé par la renommée équipe d'IA internationale Ai2, plus de 7000 tests unitaires ultra-exigeants)
- DocParsingBench : 87.76, premier (#1, couvrant 5 grands secteurs et 14 scénarios métiers réels)
Un modèle open source d'analyse de documents nommé OXR a gravi la première place des trois classements mondiaux.
De plus, l'ensemble du processus d'évaluation et du code est entièrement open source et reproductible.
J'ai aussi fait un essai rapide moi-même, et c'est vraiment différent. Enfin un outil qui n'est plus une intelligence artificielle stupide.
Avec les outils d'avant, je comptais essentiellement sur leur capacité à transformer une image en texte, et pour le reste je laissais l'IA inférer et interpréter seule.
Tandis qu'OXR peut avaler d'un seul coup13 types d'éléments de document :
tableaux, formules, blocs de code, images, équations chimiques, notes de bas de page, en-têtes, pieds de page, tampons……
Appliqué à des cas concrets, cela donne ceci :
Magazines : sortie en MD structuré conservant la structure sémantique complète et l'ordre de lecture.
Formules mathématiques : conversion directe en code LaTeX standard.
Des articles scientifiques ?
Inutile de laisser le LLM appeler des outils pour lire péniblement tout seul ; même la mise en page en deux colonnes n'affecte pas la qualité.
Et même, les épreuves de mathématiques peuvent être analysées ???
On dirait que GPT pourra désormais mieux aider les écoliers à faire leurs devoirs de vacances o(╥﹏╥)o.
Bien sûr, ce qui est le plus passionnant, c'est le fait que ce soit open source.
Il faut savoir que ce type de petit modèle vertical a une signification bien différente de celle de l'open source des LLM.
Je le dis franchement : l'open source des LLM, c'est bien, mais cela n'a pas grand-chose à voir avec les utilisateurs ordinaires.
Même un modèle de seulement 27B a un coût de déploiement local ridiculement élevé : il faut au minimum une M5 Pro 64G, sans même compter la question de la vitesse de sortie.
Mais OXR, ce petit gars,fait seulement 1.3B…
Qu'est-ce que ça veut dire ?
Avec une simple RTX 3060, on peut le faire tourner à pleine puissance et en abuser à volonté.
Les développeurs à l'étranger sont eux aussi aux anges.
Ça a de la gueule.
Alors, comment un modèle d'analyse de documents de 1.3B a-t-il réussi à atteindre une précision SOTA ?
Le secret, tout est caché dans le post-entraînement —
Ça repose sur le RSI ???
Révélation de l'entraînement RSI
Depuis longtemps, tout le monde a un schéma de pensée figé :
pour que l'IA atteigne une précision extrême, il faut empiler des modèles géants à dizaines de milliards de paramètres et des masses d'annotations manuelles.
Mais à dire vrai, dans le domaine de l'analyse de documents, les données annotées sont un véritable gouffre sans fond.
Les mises en page sont d'une variété folle, les formules spécialisées, le code et les graphiques sont d'une complexité inextricable ; se fier uniquement à l'annotation manuelle coûte un prix astronomique, et le taux d'erreur des annotations humaines est lui-même effrayant.
On ne peut tout simplement pas épuiser les longues traînées de Bad Case du monde réel. L'ingénieur peine à sélectionner les mauvais échantillons, les corrige à la main, réentraîne, sort tant bien que mal une nouvelle version, et ça plante encore face à une nouvelle mise en page saugrenue.
La vitesse de préparation des données étrangle littéralement l'évolution du modèle.
L'équipe a mené une exploration plutôt audacieuse dans ce domaine.
Ils ont réalisé que l'analyse de documents possédait depuis longtemps une caractéristique facile à négliger :
Chaque entrée possèdeune réponse standard objectif et déterminée。
Le texte est-il correct, le tableau comporte-t-il des erreurs de fusion de lignes ou de colonnes, des symboles de formules sont-ils manquants : tout cela peut être mesuré avec précision.
Puisqu'on peut juger objectivement le vrai du faux, pourquoi faudrait-il encore attendre que des humains viennent nettoyer derrière ?
Après avoir mené cette expérience de pensée, OXR a pris une décision :
lors de la phase de post-entraînement, introduire un paradigme d'entraînement d'auto-amélioration récursive (RSI) orienté vers l'analyse de documents.
Sans dépendre de nouvelles annotations manuelles humaines, le système d'IA trouve lui-même ses erreurs, analyse lui-même les causes, prépare lui-même les données d'entraînement du tour suivant et itère et évolue de lui-même.
Ce processus RSI peut être grossièrement divisé en trois étapes :
1. Prédiction et classification (Prediction&Classification)
OXR commence par analyser une masse considérable de documents réels sans étiquettes.
Immédiatement après, un modèle multimodal généraliste (General VLM) entre en scène et, en combinant l'image originale, les résultats d'analyse et les critères d'évaluation, répartit les échantillons en trois catégories :
- Correct : totalement correct, validé directement.
- Wrong : jugé clairement erroné, envoyé pour analyse approfondie.
- Uncertain : prédiction instable ou en marge de la distribution, également envoyé pour analyse.
Conserver la catégorie Uncertain est un savoir-faire assez contre-intuitif.
Si vous n'offrez au modèle que deux options tranchées, Correct ou Wrong, l'hésitation du modèle évaluateur se retrouve emballée de force en une étiquette définitive, ce qui finit par injecter du poison dans le tour d'entraînement suivant.
Grâce à Uncertain, les échantillons douteux peuvent être récupérés par un filet de sécurité.
En plus du VLM, OXR s'auto-évalue également en effectuantplusieurs échantillonnages de rollout。
Si un document produit, sur plusieurs exécutions, des résultats très divergents, cela signifie que le modèle manque d'assurance ; même s'il tombe juste par hasard une fois, il sera directement placé dans l'ensemble Uncertain.
Enfin, sans changer le moins du monde le contenu sémantique, le système applique à ces échantillons à forte divergence de légères perturbations d'image (léger redimensionnement, compression, flou léger ou décalage).
Si, après perturbation, la divergence s'accroît encore, cela signifie que le modèle est excessivement sensible à ces changements visuels inoffensifs ; cette action de perturbation est alors immédiatement consignée comme une cause racine essentielle, guidant directement le renforcement ciblé du tour suivant.
2. Attribution et planification de l'entraînement (Attribution&Training Planning)
Une fois les échantillons erronés et faibles filtrés, il ne faut surtout pas les fournir tels quels au modèle ; vous devez comprendre exactement où il a échoué.
À cette étape, le General VLM agit comme un vieux médecin chevronné, diagnostiquant chaque échantillon : s'agit-il d'un échec d'alignement de cellules fusionnées sur plusieurs colonnes, ou d'une erreur de reconnaissance d'écriture manuscrite cursive ?
Les causes diagnostiquées en langage naturel sont saisies dans SigLIP2 pour en extraire des vecteurs de caractéristiques, puis regroupées en clusters par un modèle de clustering indépendant, formant des clusters de raisons (Reason clusters) bien définis.
Par exemple, un état financier et une fiche d'expérience de chimie n'ont en apparence rien à voir, ni par l'aspect ni par le texte ; mais si le clustering d'attribution révèle qu'ils échouent tous deux sur une certaine structure rare de fusion de lignes et de colonnes, cela sera dégagé comme une direction commune de construction de données.
Voilà une frappe de précision : on renforce là où c'est le plus faible.
3. Génération de données (Data Generation)
Grâce à des clusters de raisons bien définis, le générateur sait quels exercices il doit s'entraîner à traiter.
La méthode concrète d'OXR est la suivante : les clusters de raisons fournissent les difficultés structurelles, tandis que le vivier d'échantillons réels fournit les références de mise en page et de style visuel.
À chaque génération de nouvelles données, un style de mise en page est tiré des échantillons réels pour servir d'ancre, et les difficultés structurelles à surmonter y sont naturellement intégrées.
Les points faibles visuels découverts lors des tests de perturbation précédents sont également intégrés systématiquement dans le pipeline de synthèse, obligeant le modèle à se désensibiliser par la répétition lors des exercices.
Enfin, les données générées passent une validation rigoureuse de conformité, puis sont directement réinjectées pour entraîner la prochaine génération d'OXR.
Une fois un cycle terminé, les faiblesses du modèle sont comblées ; un nouveau cycle lancé sur de vrais documents révèle à nouveau de nouvelles faiblesses, ce qui pilote l'itération suivante.
Le RSI, dès lors, prenait forme.
À chaque itération, les données deviennent de plus en plus complètes et de plus en plus solides.
C'est aussi la raison pour laquelle OXR parvient à une densité d'intelligence aussi élevée.
Quand la qualité des données atteint un certain niveau, le modèle n'a plus besoin d'une quantité de paramètres enflée pour mémoriser par cœur.
Une architecture légère et enfichable
Après avoir parlé des données et des algorithmes, passons à la question suivante.
La précision en premier, je peux comprendre.
Mais la vitesse aussi en premier, c'est quoi cette histoire ???
Sur une seule RTX PRO 6000, OXR analyse de bout en bout un document de 100 pages en seulement 101.0 secondes, première among open source.
Au début, je pensais que c'était dû à la petite taille des paramètres.
Mais j'ai réalisé plus tard que, pour l'analyse de documents, il n'est pas possible d'y arriver uniquement avec un petit modèle.
Derrière cela, il y a beaucoup de savoir-faire contre-intuitif.
En revenant sur l'évolution technique de l'analyse de documents ces deux dernières années, l'industrie est en réalité passée par plusieurs étapes.
Au tout début, tout le monde faisait duPipeline: détection, reconnaissance et tri utilisaient chacun un modèle propriétaire indépendant, ce qui donnait un assemblage extrêmement lourd, avec des coûts de maintenance astronomiques.
Ensuite, lesVLMsont devenus à la mode, et tout le monde a découvert qu'en essence toutes les tâches étaient des mappings d'image vers séquence ; on a donc commencé à tenter de tout résoudre en une fois avec un grand modèle de bout en bout, laissant le grand modèle cracher directement le texte et la mise en page d'une page entière.
Cette solution est certes élégante, mais sa vitesse est celle d'un escargot, car la génération autorégressive de longues séquences est très gourmande en puissance de calcul.
Plus tard,PaddleOCR-VLa franchi un très beau pas :
en fusionnant l'analyse de mise en page (LA) et l'ordre de lecture (RO) en un seul petit modèle, suivi d'un modèle de reconnaissance (Recognition), réalisant ainsi deux modèles et deux étapes.
Cela a ramené du coup la vitesse de détection de mise en page au niveau milliseconde de la détection d'objets traditionnelle, devenant directement la solution standard de l'industrie ces deux dernières années.
Mais, est-ce parfait pour autant ?
Non. Chaque annotation de mise en page ajoutée doit être inévitablement liée à une annotation d'ordre de lecture, doublant directement la difficulté du traitement des données.
Après une analyse approfondie, l'équipe OXR a proposé une solution de restructuration au niveau des tâches complètement différente :
un modèle léger indépendant se charge de l'analyse de mise en page (LA), tandis que le modèle principal d'OXR gère à la fois la reconnaissance de contenu (Recognition) et la détermination de l'ordre de lecture (RO).
Autrement dit :
Analyse de mise en page–>Reconnaissance+Ordre de lecture
Cette combinaison de découpage, en apparence simple, apporte sur le plan de l'ingénierie deux transformations qualitatives majeures :
Premièrement,elle élimine totalement la perte de performance liée à l'ordre de lecture.
Dans l'ensemble du pipeline, le temps nécessaire pour déterminer l'ordre de lecture était déjà bien inférieur à celui de la reconnaissance de texte.
Depuis qu'OXR a intégré la détermination de l'ordre de lecture dans le modèle principal, non seulement aucun temps supplémentaire n'a été ajouté, mais, grâce à la capacité de compréhension sémantique propre au modèle principal (Content-Aware), la précision de la détermination de l'ordre de lecture s'est considérablement améliorée.
Parallèlement, le modèle d'analyse de mise en page en amont (LA), déchargé du lourd fardeau du tri complexe, voit sa tâche devenir extrêmement pure : il peut directement adopter un modèle de détection plus léger et plus efficace, faisant décoller le débit global sur place.
Deuxièmement,le module d'analyse de mise en page est indépendant et entièrement remplaçable à la demande.
Des besoins métier différents ont des exigences de mise en page totalement contradictoires — c'est un problème de longue traîne :
Pour une zone mêlant texte et images, l'équipe de contenu souhaite l'extraire comme une image entière, tandis que l'équipe de la base de connaissances veut en extraire le texte comme corps principal ;
Pour une planche de quatre cases densément agencée, le métier A veut un découpage global, le métier B veut la couper en quatre petites images ;
……
Bref, c'est très difficile à définir, impossible de satisfaire tout le monde.
Mais dans l'architecture d'OXR, l'analyse de mise en page est un module totalement indépendant et enfichable —
avec un coût de transformation minimal, pour une liberté d'adaptation métier maximale.
Si votre métier a des besoins de découpage de mise en page extrêmement particuliers — par exemple si vous traitez des ouvrages anciens ou des documents médicaux — vous pouvez tout à fait le remplacer sans interruption par votre propre modèle privé d'analyse de mise en page que vous avez entraîné,
le back-end continuant de profiter gratuitement des puissantes capacités de reconnaissance de contenu d'OXR.
Écosystème prêt à l'emploi
Bien sûr, puisqu'il est né pour la communauté des développeurs, aussi bien qu'un modèle puisse se vanter, s'il ne peut pas être déployé, cela ne sert à rien.
À cet égard, l'éditeur fournit une API gratuite, sans inscription ni demande de clé.
Oui, totalement gratuit, du pur bénéfice…
L'éditeur déclare qu'ils maintiendront le service open source gratuit, du moins tant que la charge des serveurs reste supportable.
Comment ne pas se lever et pédaler !
C'est donc en toute hâte que j'ai intégré cette API dans mon application d'écriture.
Honnêtement, en matière d'analyse de PDF, comparé aux solutions précédentes, le résultat est bien, bien meilleur.
Au fait, pour ceux qui veulent un déploiement local, aucun problème non plus. OXR est pleinement compatible avec les principaux frameworks d'inférence.
Pas besoin de recompiler vous-même péniblement vLLM : il suffit de monter le plugin dans le Docker ou le CLI officiels pour lancer le service en un clic.
À l'heure actuelle, le code d'OXR, ses poids ainsi que l'intégralité du processus de reproduction des évaluations de référence sont entièrement publics.
Le lien est en fin d'article, les personnes intéressées peuvent se servir.
Bien sûr, si vous avez des besoins plus élevés — par exemple traiter davantage de formats comme Word, PPT, Excel, ou rechercher des capacités de post-traitement personnalisé plus abouties — vous pouvez également vous intéresser au moteur de niveau commercial maintenu par l'éditeur.
Il s'appelle SoMark.
C'est aussi le nom de l'équipe d'OXR.
One More Thing
Enfin, j'ai encore une petite idée dont j'aimerais discuter avec vous.
Pourquoi, aujourd'hui, consacrer autant d'efforts à nous acharner sur l'analyse de documents ?
À l'heure où les Agent prennent en charge les flux de travail de tous les secteurs, la grande majorité des connaissances privées les plus essentielles et les plus spécialisées accumulées par l'humanité au cours des dernières décennies dort encore tranquillement dans ces PDF, documents scannés et rapports aux formats chaotiques et à la mise en page complexe.
Si intelligents que soient les grands modèles de langage, si on leur donne en entrée un tas de déchets de caractères désordonnés et de tableaux brisés, ils ne produiront que des hallucinations.
Par le passé, beaucoup considéraient l'OCR comme un travail de manutention sans grande valeur technique, mais aujourd'hui, d'OCR à OXR, la mission qu'il porte a complètement changé.
Il est le pont entre l'homme et la machine, reconstituant intégralement et sans perte tous les documents multimodaux complexes du monde humain en actifs structurés extrêmement compatibles avec les Agent.
Honnêtement, voir des équipes nationales travailler sur des choses aussi proches de la mise en œuvre concrète en ingénierie est assez enthousiasmant.
Trop de regards se concentrent sur les récits fancy, on court chaque jour après les technologies de pointe, et l'on oublie ainsi une chose très importante —
De quoi les utilisateurs ont-ils réellement besoin ?
Avec le stade de développement auquel les LLM sont parvenus, la réponse à cette question n'est absolument plus une intelligence de modèle supérieure.
Le plus grand goulot d'étranglement se trouve dans les domaines encore inexplorés, où il faut se salir les mains (Get Hands Dirty).
Si un consensus pouvait se former sur ce point —
l'infrastructure propre aux Agents,s'assemblerait pièce par pièce, à une vitesse visible à l'œil nu, comme un puzzle.
GitHub : https://github.com/SoMarkAI/OXR
Hugging Face : https://huggingface.co/SoMarkAI/OXR-1.0
Démo en ligne :
https://free-oxr.somark.cn/
API gratuite :
https://free-oxr.somark.cn/api/v1
Site officiel de SoMark : https://www.somark.cn