DeepSeek-OCR compresse le contexte textuel par 10 avec une précision de 97 %

DeepSeek a publié un article et ouvert le code de DeepSeek-OCR : un système qui transforme du texte en image et utilise les tokens visuels comme représentation compressée du contexte. Selon les auteurs, avec une compression d'environ 10x, le décodeur restitue le texte d'origine avec une précision d'environ 97 %. À 20x, la précision tombe à environ 60 %. Une analyse populaire de la chaîne Two Minute Papers y voit la solution au problème de la mémoire de l'IA. La formule est ronflante : le problème est plutôt posé que résolu, mais les chiffres sur les documents sont convaincants.

Pourquoi transformer du texte en image

Le contexte long coûte cher. Le coût de l'attention dans un transformer croît de façon quadratique avec le nombre de tokens, et une page de texte dense occupe facilement des milliers de tokens. La même page, fournie sous forme d'image, est encodée avec des centaines de tokens visuels. Les auteurs posent la question : peut-on utiliser la vision comme canal de compression pour un modèle de langage ? L'expérience montre que, pour une tâche de reconnaissance, c'est possible.

Comment ça fonctionne

Le système comprend deux parties. L'encodeur DeepEncoder combine une attention locale à fenêtres fondée sur SAM et une attention globale fondée sur CLIP-large. Entre les deux se trouve un compresseur convolutif qui réduit le nombre de tokens par 16 : l'attention globale, coûteuse, ne travaille ainsi plus que sur un petit nombre d'éléments. Le décodeur, DeepSeek3B-MoE, est un modèle de type mixture-of-experts d'environ 3 milliards de paramètres, dont environ 570 millions sont actifs pour chaque token.

Paramètres clés d'après l'article :

• compression jusqu'à 10x : précision de reconnaissance d'environ 97 % ;
• compression d'environ 20x : précision d'environ 60 % ;
• modes de résolution : Tiny (64 tokens), Small (100), Base (256), Large (400) et Gundam pour les pages complexes comportant plusieurs fragments ;
• OmniDocBench : 100 tokens par page surpassent GOT-OCR2.0, qui en exige 256 ;
• moins de 800 tokens donnent un meilleur résultat que MinerU2.0, qui en consomme environ 7000 ;
• performances : plus de 200 000 pages par jour sur une seule A100-40G, jusqu'à 33 millions de pages par jour sur 20 nœuds de 8 GPU.

Où s'arrête la belle idée

La principale limite : l'OCR vérifie que le texte peut être relu, mais pas qu'un modèle de langage est capable de raisonner sur un contexte compressé optiquement aussi bien que sur des tokens ordinaires. Ce sont deux tâches distinctes, et l'article ne répond pas à la seconde question.

Les auteurs proposent aussi une analogie avec la mémoire humaine : les anciens fragments d'une conversation pourraient être conservés dans une image de résolution toujours plus faible, c'est-à-dire être peu à peu « oubliés ». Cela paraît logique pour des agents à longue historique, mais c'est une hypothèse. On ne dispose pas encore de données sur l'effet d'un tel schéma sur la qualité des réponses dans les dialogues, le code et les tâches multi-étapes.

Il faut aussi tenir compte des pertes. Avec 60 % de précision à 20x, on ne peut pas stocker des contrats, du code ou des nombres dont le sens change à la moindre erreur d'un caractère. Dans ces cas, il faudra un contrôle qualité ou un retour au texte source.

Que tester en pratique

Les équipes qui numérisent des archives, des factures et des PDF scientifiques peuvent dès maintenant tester DeepSeek-OCR : le code et les poids sont sur GitHub. Le gain porte avant tout sur le coût de traitement : moins de tokens par page signifie moins de charge pour les GPU. Le modèle convient aussi à la génération de données d'entraînement à partir de documents à grande échelle, ce que suggèrent les chiffres de performance.

Les développeurs d'agents gagneraient à laisser de côté les conclusions tapageuses et à monter leur propre test : prendre leur longue historique de dialogue, compresser la partie ancienne en image et comparer la qualité des réponses avec un contexte classique. S'il n'y a pas de différence, l'économie de tokens sera sensible. S'il y en a une, il faudra décider quelles données on peut se permettre d'« oublier ».