Si vous soumettez un mémoire juridique de 300 pages ou un rapport annuel relié dans la plupart des pipelines OCR, le logiciel le divisera discrètement en segments. Page un, traitement, vidage de la mémoire. Page deux, traitement, vidage de la mémoire. Au moment où le système atteint les pièces jointes à la fin, tout le contexte qu'il aurait pu glaner dans l'introduction a disparu depuis longtemps. Les notes de bas de page deviennent des orphelines. Les tableaux répartis sur plusieurs pages perdent leur structure. Les en-têtes qui se poursuivent sur plusieurs pages sont mal étiquetés. Le résultat est un fichier texte recousu qu'un humain doit réassembler.
Baidu estime que ce flux de travail est fondamentalement défaillant. Leur réponse est l'Unlimited OCR, une architecture conçue pour ingérer des documents massifs de plusieurs pages en une seule passe avant (forward pass) sans l'explosion de la mémoire GPU qui en résulte habituellement. L'astuce réside dans un nouveau mécanisme d'attention qui traite la mémoire moins comme un disque dur et plus comme la mémoire de travail humaine : gardez le matériel source sous les yeux, souvenez-vous de ce que vous venez d'écrire, et laissez le passé lointain s'effacer.
Pourquoi les documents longs nuisent à l'OCR standard
Pour comprendre la solution, il est utile de voir où les systèmes OCR de bout en bout conventionnels échouent.
La plupart des pipelines OCR modernes utilisent un grand modèle de langage comme décodeur. À mesure que le modèle lit une page et génère du texte, il stocke des représentations internes appelées cache KV — essentiellement un journal de bord continu de clés et de valeurs qui aide le modèle à garder une trace de ce qu'il a déjà dit. Le problème est que ce journal croît linéairement à chaque nouvelle ligne de sortie. Traitez dix pages, et le cache fait dix pages de profondeur. Traitez cent pages, et il gonfle pour atteindre des centaines de milliers de jetons, dévorant la VRAM et ralentissant la vitesse de génération jusqu'à l'immobilisme.
Les ingénieurs ont géré cela en ne gérant tout simplement rien. Ils découpent les documents en pages individuelles, font passer chaque page dans le modèle indépendamment et réinitialisent le cache KV entre chaque étape. Cela permet de maintenir le système en marche, mais cela prive également le modèle de tout fil conducteur continu. Un paragraphe qui commence à la page trois et se termine à la page quatre se retrouve coupé en deux. Le formatage des tableaux sur plusieurs pages se désintègre. Les références aux sections précédentes se transforment en liens brisés car le décodeur n'a aucune mémoire persistante de ce qui précède. Le modèle ne lit pas vraiment le document ; il effectue une série de fiches de révision isolées.
L'astuce humaine : Reference Sliding Window Attention
Les chercheurs de Baidu ont abordé ce problème en s'inspirant de la cognition humaine. Pensez à la copie manuelle d'un passage d'un livre. Vous ne gardez pas en mémoire chaque phrase précédemment copiée. Vous jetez un coup d'œil à la source, regardez les derniers mots que vous avez écrits, et continuez. Votre mémoire de travail est minuscule, mais comme le texte source reste ouvert devant vous, la tâche est sans effort.
La Reference Sliding Window Attention, ou R-SWA, formalise exactement cette intuition.
Sous le capot, le cache KV devient une file d'attente de longueur fixe. Lorsque le modèle génère un nouveau jeton, il conserve une visibilité totale sur les « jetons de référence » — les embeddings visuels originaux et l'invite (prompt) initiale — mais il ne regarde en arrière que sur les 128 derniers jetons qu'il a personnellement générés. C'est tout. Que le modèle soit à la page une ou à la page cinquante, l'empreinte mémoire de son propre historique de sortie reste figée. Le cache ne croît pas. Il se recycle.
C'est une