{"notes":[{"id":"deepseek/deepseek-ocr-2","category":"deepseek","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DeepSeek-OCR 2","subtitle":"L'ordre du regard","author":"Z. Yuan","paperDate":"2026-01-28","publishedOn":"2026-11-08","world":"external/deepseek-ocr2","paperTitle":"DeepSeek-OCR 2: Visual Causal Flow","paperUrl":"https://arxiv.org/abs/2601.20552","bibliography":{"title":"DeepSeek-OCR 2: Visual Causal Flow","authors":["Haoran Wei","Yaofeng Sun","Yukun Li"],"url":"https://arxiv.org/abs/2601.20552","pdfUrl":"https://arxiv.org/pdf/2601.20552v1","codeUrl":"https://github.com/deepseek-ai/DeepSeek-OCR-2","preprint":{"id":"2601.20552","submittedOn":"2026-01-28","url":"https://arxiv.org/abs/2601.20552"},"publication":null,"citation":"@misc{deepseekdeepseekocr22026,\n  title = {{DeepSeek-OCR 2: Visual Causal Flow}},\n  author = {Haoran Wei and Yaofeng Sun and Yukun Li},\n  year = {2026},\n  eprint = {2601.20552},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2601.20552}\n}\n","citationPath":"/content/papers/citations/deepseek/deepseek-ocr-2.02901bc9ba9f.bib"},"thumbnail":{"src":"/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png","width":1194,"height":483},"locale":"fr","path":"/content/papers/fr/deepseek/deepseek-ocr-2.78e33262b694.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"remplacer-clip-par-un-modèle-de-langage","text":"Remplacer CLIP par un modèle de langage","depth":3},{"id":"le-masque-décide-qui-voit-qui","text":"Le masque décide qui voit qui","depth":3},{"id":"combien-de-tokens-pour-une-page","text":"Combien de tokens pour une page ?","depth":3},{"id":"entraînement","text":"Entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"omnidocbench-v15","text":"OmniDocBench v1.5","depth":3},{"id":"les-neuf-types-de-documents-en-détail","text":"Les neuf types de documents en détail","depth":3},{"id":"que-surveiller-en-production","text":"Que surveiller en production ?","depth":3},{"id":"la-vision-des-auteurs-et-les-résultats-ultérieurs","text":"La vision des auteurs et les résultats ultérieurs","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"deepseek/deepseek-ocr","relation":"referenced","topic":""}]},{"id":"deepseek/deepseek-ocr","category":"deepseek","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DeepSeek-OCR","subtitle":"Une image vaut mille mots","author":"Z. Yuan","paperDate":"2025-10-21","publishedOn":"2026-03-09","world":"external/deepseek-ocr","paperTitle":"DeepSeek-OCR: Contexts Optical Compression","paperUrl":"https://arxiv.org/abs/2510.18234","bibliography":{"title":"DeepSeek-OCR: Contexts Optical Compression","authors":["Haoran Wei","Yaofeng Sun","Yukun Li"],"url":"https://arxiv.org/abs/2510.18234","pdfUrl":"https://arxiv.org/pdf/2510.18234v1","codeUrl":"https://github.com/deepseek-ai/DeepSeek-OCR","preprint":{"id":"2510.18234","submittedOn":"2025-10-21","url":"https://arxiv.org/abs/2510.18234"},"publication":null,"citation":"@misc{deepseekdeepseekocr2025,\n  title = {{DeepSeek-OCR: Contexts Optical Compression}},\n  author = {Haoran Wei and Yaofeng Sun and Yukun Li},\n  year = {2025},\n  eprint = {2510.18234},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2510.18234}\n}\n","citationPath":"/content/papers/citations/deepseek/deepseek-ocr.66e8e5a7db8d.bib"},"thumbnail":{"src":"/content/papers/assets/6f53ecfe63f39804454a69ef4468c93e8018fa1afbe08d1bb52b7e8d52d194c3.png","width":1288,"height":350},"locale":"fr","path":"/content/papers/fr/deepseek/deepseek-ocr.dfea002cdca7.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-densemble","text":"Architecture d'ensemble","depth":3},{"id":"suivons-une-page-de-10241024","text":"Suivons une page de 1024×1024","depth":3},{"id":"le-décodeur-restituer-le-texte-à-partir-dune-représentation-compressée","text":"Le décodeur : restituer le texte à partir d'une représentation compressée","depth":3},{"id":"données-et-entraînement","text":"Données et entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"expérience-de-taux-de-compression-100-pages-de-fox","text":"Expérience de taux de compression : 100 pages de Fox","depth":3},{"id":"documents-réels-omnidocbench","text":"Documents réels : OmniDocBench","depth":3},{"id":"compression-optique-et-oubli","text":"Compression optique et oubli","depth":3},{"id":"le-débat-après-la-publication","text":"Le débat après la publication","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"model-evaluation/linguistic-crutch","relation":"referenced","topic":""}]}],"text":"Comment lit-on un journal sur trois colonnes ?\n\nPas en balayant d'un trait la page du coin supérieur gauche au coin inférieur droit. On lit d'abord le titre, on descend le long de la première colonne, puis, arrivé en bas, on remonte en haut de la deuxième ; à la mention « suite en page 5 », le regard saute là-bas. L'endroit où se pose le regard suivant dépend de ce qu'on vient de lire.\n\nUn VLM ne lit pas ainsi. L'image est découpée en une grille de patchs, alignés en une seule rangée selon un ordre fixe, « de gauche à droite, de haut en bas », puis complétés d'un encodage de position et transmis au modèle de langage. Pour une photo ordinaire, cela pose peu de problèmes ; pour un document à la mise en page complexe, cet ordre diffère souvent de l'ordre logique du contenu.\n\nDeepSeek-OCR 2 veut laisser l'encodeur décider lui-même **où regarder d'abord, et où regarder ensuite**. Il s'agit d'un rapport technique déposé par DeepSeek-AI le 28 janvier 2026 ; cette note suit la v1. Le code et les poids ont été publiés en même temps.\n\n\n> [!TIP]\n> \n> Pour le DeepEncoder de la génération précédente et la conception de la compression optique, voir d'abord :\n> \n> - **[[25.10] DeepSeek-OCR : Une image vaut mille mots](/blog/papers/deepseek/deepseek-ocr)**\n\n\n## Définir le problème\n\nLes auteurs partent d'une observation : le mouvement du regard humain obéit à une causalité, chaque point de fixation dépendant de ce qui a été vu auparavant ; or les encodeurs des VLM actuels aplatissent l'image 2D en séquence 1D selon un ordre fixe, indépendant du contenu.\n\nLes modèles de langage sont entraînés sur du texte unidimensionnel et ordonné. D'où la question des auteurs : peut-on traiter une image bidimensionnelle en enchaînant deux raisonnements « unidimensionnels et causalement ordonnés » ?\n\n- Le premier, dans l'encodeur, réordonne les tokens visuels en ordre de lecture, d'après le contenu de l'image.\n- Le second, dans le décodeur, produit le texte de manière autorégressive en suivant cet ordre.\n\nIls prennent la lecture de documents comme terrain d'essai : avec leurs mises en page multicolonnes, leurs formules et leurs tableaux, les documents ont un ordre de lecture porteur d'une logique propre.\n\n## Résoudre le problème\n\n### Remplacer CLIP par un modèle de langage\n\n[![À gauche : DeepEncoder, un Tokenizer de 80M suivi de CLIP ViT 300M ; à droite : DeepEncoder V2, le même Tokenizer suivi d'un modèle de langage fondé sur Qwen2 500M, où un ensemble de requêtes apprenables suit les tokens visuels et où seule la sortie des requêtes est transmise plus loin](/content/papers/assets/e199e1e56c505533eb91beb5fa681e7a2366dac66b585a0317ab82b1c950d79d.png)](/content/papers/assets/e199e1e56c505533eb91beb5fa681e7a2366dac66b585a0317ab82b1c950d79d.png)\n\n*Figure 1 de l'article, extraite de la [**page 1 du PDF v1**](https://arxiv.org/pdf/2601.20552v1#page=1), CC BY 4.0. À gauche, le DeepEncoder de la génération précédente ; à droite, DeepEncoder V2.*\n\nLa moitié supérieure est identique des deux côtés : un Tokenizer d'environ 80 millions de paramètres, qui reprend le SAM-base et les deux couches de convolution de la génération précédente pour diviser le nombre de tokens par seize.\n\nLa différence se trouve dans la moitié inférieure. La génération précédente utilisait un CLIP de 300 millions de paramètres pour l'attention globale ; V2 le remplace par une architecture de modèle de langage initialisée avec **Qwen2-0.5B**, et ajoute après les tokens visuels un ensemble de **requêtes apprenables** (que les auteurs appellent *causal flow tokens*).\n\nCes requêtes sont aussi nombreuses que les tokens visuels. Au bout du compte, seule la moitié de la sortie qui correspond aux requêtes est transmise au décodeur ; les tokens visuels eux-mêmes ne vont pas plus loin.\n\nLes auteurs ont aussi essayé un autre montage : placer les tokens visuels dans un encodeur séparé, que les requêtes lisent par attention croisée, à la manière de la structure encodeur-décodeur de mBART. L'entraînement n'a pas convergé. Selon eux, isolés dans un autre encodeur, les tokens visuels n'interagissaient pas assez avec les requêtes ; c'est en les plaçant comme préfixe dans la même séquence, pour que l'information circule à chaque couche, que l'entraînement a pu aboutir.\n\n### Le masque décide qui voit qui\n\n[![Schéma du masque d'attention : un masque bidirectionnel de type ViT et un masque causal de type LM se combinent pour former celui de DeepEncoder V2 ; dans les trois premières lignes, les tokens visuels se voient tous entre eux ; dans les trois dernières, les requêtes voient tous les tokens visuels et les requêtes précédentes](/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png)](/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png)\n\n*Figure 5 de l'article, extraite de la [**page 7 du PDF v1**](https://arxiv.org/pdf/2601.20552v1#page=7), CC BY 4.0. Vert : attention autorisée ; rose : attention interdite ; cercle blanc : le token lui-même.*\n\nCette figure est au cœur de toute la conception. Parcourons-la avec trois tokens visuels $v_0,v_1,v_2$ et trois requêtes $q_0,q_1,q_2$. Les lignes indiquent « qui regarde », les colonnes « ce qui est regardé » ; 1 signifie que l'attention est autorisée :\n\n```text\n       v0 v1 v2 | q0 q1 q2\nv0      1  1  1 |  0  0  0\nv1      1  1  1 |  0  0  0\nv2      1  1  1 |  0  0  0\n----------------+---------\nq0      1  1  1 |  1  0  0\nq1      1  1  1 |  1  1  0\nq2      1  1  1 |  1  1  1\n```\n\n- **En haut à gauche** : les tokens visuels se voient tous entre eux. C'est une attention bidirectionnelle, comme dans un ViT, qui conserve la vue d'ensemble de l'image propre à CLIP.\n- **En haut à droite** : les tokens visuels ne voient pas les requêtes ; les caractéristiques de l'image ne dépendent donc pas de l'ordre des requêtes.\n- **En bas à gauche** : chaque requête voit tous les tokens visuels.\n- **En bas à droite** : entre requêtes, le masque est triangulaire inférieur ; $q_1$ ne voit que $q_0$ et elle-même, comme dans l'attention causale d'un modèle de langage decoder-only.\n\nL'article l'écrit ainsi :\n\n$$\nM=\\begin{bmatrix}\\mathbf{1}_{m\\times m} & \\mathbf{0}_{m\\times n}\\\\ \\mathbf{1}_{n\\times m} & \\mathrm{LowerTri}(n)\\end{bmatrix},\\quad n=m\n$$\n\nC'est ce triangle inférieur, en bas à droite, qui crée l'« ordre ». $q_0$ décide d'abord de ce qu'elle extrait de l'image ; $q_1$, sachant ce que $q_0$ a pris, décide de la suite ; et ainsi de suite. Alignées en une rangée, les sorties des requêtes forment en elles-mêmes un ordre de lecture.\n\nLes auteurs écrivent l'ensemble du processus ainsi :\n\n$$\n\\mathbf{O}=\\mathcal{D}\\big(\\pi_Q(\\mathcal{T}^L(\\mathcal{E}(\\mathbf{I})\\oplus\\mathbf{Q}_0;\\mathbf{M}))\\big)\n$$\n\n$\\mathcal{E}$ est le Tokenizer, $\\oplus$ concatène tokens visuels et requêtes, $\\mathcal{T}^L$ est un Transformer masqué à $L$ couches, $\\pi_Q$ ne garde que les $n$ dernières sorties, c'est-à-dire celles des requêtes, et $\\mathcal{D}$ est le décodeur.\n\n### Combien de tokens pour une page ?\n\nPour ne pas avoir à préparer un jeu de requêtes par résolution, les auteurs fixent deux vues :\n\n- **Vue globale** de 1024×1024 : 1024/16 = 64, 64×64 = 4 096 blocs, soit **256** tokens après compression par seize, associés à 256 requêtes.\n- **Recadrages locaux** de 768×768 : 768/16 = 48, 48×48 = 2 304 blocs, soit **144** tokens après compression ; tous les recadrages partagent le même jeu de 144 requêtes.\n\nLe nombre de recadrages $k$ va de 0 à 6 ; si les deux côtés de l'image font moins de 768, il n'y a pas de recadrage. Le décodeur reçoit donc $144k+256$ tokens : au minimum 256, au maximum $6\\times144+256=1{,}120$.\n\nLes auteurs prennent soin de situer ce plafond : le mode Gundam de la génération précédente montait jusqu'à 1 156 tokens, et le plafond de tokens visuels de Gemini 3 Pro est lui aussi de 1 120.\n\nLe décodeur ne change pas : c'est toujours le MoE 3B de la génération précédente, avec environ 500 millions de paramètres activés.\n\n### Entraînement\n\nLes sources de données sont les mêmes que pour la génération précédente, avec 80 % de données OCR. Deux petits ajustements : les données OCR 1.0 sont réparties selon leur contenu en texte, formules et tableaux, échantillonnés dans un rapport 3:1:1 ; les annotations de mise en page fusionnent des catégories sémantiquement proches, comme les légendes de figures et les titres de figures.\n\nL'entraînement compte trois étapes :\n\n1. **Préentraînement de l'encodeur** : le Tokenizer est repris de la génération précédente ; l'encodeur de type modèle de langage est initialisé à partir de Qwen2-0.5B-base et relié à un petit décodeur pour la prédiction du token suivant. 160 A100, environ 100 millions de paires image-texte.\n2. **Renforcement des requêtes** : le Tokenizer est gelé ; l'encodeur et le décodeur DeepSeek sont entraînés ensemble pour renforcer la capacité de réordonnancement des requêtes.\n3. **Spécialisation du décodeur** : l'encodeur entier est gelé et seul le décodeur est entraîné. À taille de batch égale, l'entraînement va plus de deux fois plus vite.\n\n## Discussion\n\n### OmniDocBench v1.5\n\nL'évaluation principale porte sur OmniDocBench v1.5 : 1 355 pages, 9 types de documents, en chinois et en anglais.\n\n| Modèle | Plafond de tokens visuels | Overall | ED texte | ED ordre de lecture |\n| --- | ---: | ---: | ---: | ---: |\n| DeepSeek-OCR (9 recadrages) | 1 156 | 87,36 | 0,073 | 0,085 |\n| DeepSeek-OCR 2 | 1 120 | 91,09 | 0,048 | 0,057 |\n\n*Tableau : extrait de la Table 1 de l'article. ED désigne la distance d'édition (plus bas, c'est mieux) ; pour Overall, plus haut, c'est mieux.*\n\nAvec des sources de données comparables, le score global gagne 3,73 points, et la distance d'édition de l'ordre de lecture passe de 0,085 à 0,057. Dans la Table 2, les auteurs comparent aussi leur distance d'édition globale à celle de Gemini 3 Pro : avec le même plafond de 1 120 tokens, DeepSeek-OCR 2 obtient 0,100, Gemini 3 Pro 0,115.\n\nLa même Table 1 contient deux concurrents à noter. PaddleOCR-VL obtient 92,86 et MinerU2.5 90,67 ; tous deux analysent d'abord la mise en page avant de reconnaître des zones découpées, et l'article les classe dans la catégorie Pipeline. Autrement dit, sur ce benchmark, DeepSeek-OCR 2, modèle de bout en bout, se rapproche beaucoup des systèmes en deux étapes, sans encore dépasser le meilleur d'entre eux.\n\n### Les neuf types de documents en détail\n\nLa Table 3 détaille les résultats des deux générations sur les neuf types de documents. La distance d'édition de l'ordre de lecture **s'améliore dans les neuf catégories** : par exemple de 0,125 à 0,066 pour les manuels en couleur, et de 0,089 à 0,035 pour les notes.\n\nPour la distance d'édition du texte, le tableau est moins uniforme. La plupart des catégories progressent, mais les livres passent de 0,022 à 0,033, et les journaux de 0,131 à 0,139. Pour les journaux, les auteurs avancent deux raisons : d'une part, le plafond de tokens visuels, plus bas, ne suffit pas pour des pages aussi chargées en texte, et on pourrait à l'avenir augmenter le nombre de recadrages ; d'autre part, les données d'entraînement de journaux ne comptent que 250 000 exemples, trop peu pour un nouvel encodeur.\n\n### Que surveiller en production ?\n\nCette section est très courte, mais c'est à notre avis la partie la plus concrète de l'article.\n\nEn interne, DeepSeek-OCR sert à deux choses : lire, pour les modèles de langage de DeepSeek, les images et documents envoyés par les utilisateurs, et traiter des PDF par lots pour produire des données de préentraînement. En production, il n'existe pas de vérité terrain à laquelle se comparer ; les auteurs retiennent donc le **taux de répétition** comme principal indicateur de qualité observable :\n\n| Modèle | Images d'utilisateurs en ligne | PDF de préentraînement |\n| --- | ---: | ---: |\n| DeepSeek-OCR | 6,25 % | 3,69 % |\n| DeepSeek-OCR 2 | 4,17 % | 2,88 % |\n\n*Tableau : Table 4 de l'article ; plus le taux de répétition est bas, mieux c'est.*\n\nLa répétition est l'échec le plus facile à observer en OCR génératif : le même passage revient sans fin, et un programme le repère aussitôt.\n\nÀ l'inverse, sans vérité terrain, les erreurs du type « texte fluide mais faux » échappent au taux de répétition. Pour les applications qui prennent des décisions à partir de résultats d'OCR, ce tableau rappelle que la surveillance en production doit prévoir d'autres moyens de repérer ce type d'erreur : comparer avec la couche de texte, vérifier le format des champs, ou faire relire un échantillon par des humains.\n\n### La vision des auteurs et les résultats ultérieurs\n\nDans la discussion, les auteurs voient plus grand : un encodeur causal qui réordonne le visuel, relié à un décodeur causal qui raisonne sur la tâche ; ces deux raisonnements unidimensionnels pourraient mener à un « véritable raisonnement bidimensionnel ». Ils imaginent aussi qu'un même encodeur de type modèle de langage pourrait traiter images, parole et texte en changeant simplement de jeu de requêtes. Tout cela reste pour l'instant prospectif ; l'article ne le valide que sur la lecture de documents.\n\nOmniDocBench est depuis passé à la v1.6, avec 296 pages plus difficiles. Dans le classement officiel, DeepSeek-OCR 2 obtient 90,25 ; les cinq premières places reviennent à des modèles spécialisés d'environ un milliard de paramètres, dont le meilleur atteint environ 97. [OmniDocBench README](https://github.com/opendatalab/OmniDocBench)\n\n## Conclusion\n\nLes changements de DeepSeek-OCR 2 sont très ciblés : seule la seconde moitié de l'encodeur est remplacée, pour qu'un ensemble de requêtes apprenables lise l'image dans l'ordre et réordonne les tokens visuels selon l'ordre de lecture.\n\n1. **Le masque est la clé.** Les tokens visuels se voient tous dans les deux sens, les requêtes se voient entre elles de manière causale ; seule la sortie des requêtes est transmise.\n2. **L'ordre de lecture progresse partout.** Sur OmniDocBench v1.5, sa distance d'édition passe de 0,085 à 0,057, avec une amélioration pour les neuf types de documents.\n3. **La reconnaissance du texte ne progresse pas partout.** Pour les livres et les journaux, la distance d'édition du texte augmente même légèrement ; les journaux pâtissent du plafond de tokens et du manque de données d'entraînement.\n4. **L'indicateur de production ne voit que la répétition.** Le taux de répétition baisse de 6,25 % à 4,17 %, mais cet indicateur ne voit pas les erreurs qui se lisent sans accroc.\n\nConfier l'ordre de lecture à des requêtes qui regardent l'image l'une après l'autre est une idée très intuitive. Elle rapproche la lecture du modèle de celle d'un humain ; quant à savoir si les caractères lus ont vraiment été vus ou complétés d'après le contexte, il faut toujours le vérifier séparément.\n","imageSizes":{"/content/papers/assets/e199e1e56c505533eb91beb5fa681e7a2366dac66b585a0317ab82b1c950d79d.png":{"width":1111,"height":588},"/content/papers/assets/2ba25df8f4e3579425551e93bdce7b8b0f180bb349cef46511dce7f44ffd68f3.png":{"width":1194,"height":483}}}