{"notes":[{"id":"text-spotting/paddleocr-vl","category":"text-spotting","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"PaddleOCR-VL","subtitle":"La mise en page d'abord, les mots ensuite","author":"Z. Yuan","paperDate":"2025-10-16","publishedOn":"2026-10-31","world":"external/paddleocr-vl","paperTitle":"PaddleOCR-VL: Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model","paperUrl":"https://arxiv.org/abs/2510.14528","bibliography":{"title":"PaddleOCR-VL: Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model","authors":["Cheng Cui","Ting Sun","Suyin Liang","Tingquan Gao","Zelun Zhang","Jiaxuan Liu","Xueqing Wang","Changda Zhou","Hongen Liu","Manhui Lin","Yue Zhang","Yubo Zhang","Handong Zheng","Jing Zhang","Jun Zhang","Yi Liu","Dianhai Yu","Yanjun Ma"],"url":"https://arxiv.org/abs/2510.14528","pdfUrl":"https://arxiv.org/pdf/2510.14528v4","codeUrl":"https://github.com/PaddlePaddle/PaddleOCR","preprint":{"id":"2510.14528","submittedOn":"2025-10-16","url":"https://arxiv.org/abs/2510.14528"},"publication":null,"citation":"@misc{textspottingpaddleocrvl2025,\n  title = {{PaddleOCR-VL: Boosting Multilingual Document Parsing via a 0.9B Ultra-Compact Vision-Language Model}},\n  author = {Cheng Cui and Ting Sun and Suyin Liang and Tingquan Gao and Zelun Zhang and Jiaxuan Liu and Xueqing Wang and Changda Zhou and Hongen Liu and Manhui Lin and Yue Zhang and Yubo Zhang and Handong Zheng and Jing Zhang and Jun Zhang and Yi Liu and Dianhai Yu and Yanjun Ma},\n  year = {2025},\n  eprint = {2510.14528},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2510.14528}\n}\n","citationPath":"/content/papers/citations/text-spotting/paddleocr-vl.c7969231dd04.bib"},"thumbnail":{"src":"/content/papers/assets/8ee9dd9a20b760af5b9fa7f40b97755487d35e7d6eab2577db214b267ad05ef7.png","width":1288,"height":555},"locale":"fr","path":"/content/papers/fr/text-spotting/paddleocr-vl.48bc83e3f6a2.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":"deux-étapes","text":"Deux étapes","depth":3},{"id":"la-mise-en-page-détecter-puis-ordonner","text":"La mise en page : détecter, puis ordonner","depth":3},{"id":"la-reconnaissance-un-petit-modèle-de-09b","text":"La reconnaissance : un petit modèle de 0,9B","depth":3},{"id":"entraînement-et-données","text":"Entraînement et données","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"omnidocbench-v15","text":"OmniDocBench v1.5","depth":3},{"id":"vitesse","text":"Vitesse","depth":3},{"id":"les-versions-suivantes","text":"Les versions suivantes","depth":3},{"id":"à-garder-en-tête-en-lisant-cet-article","text":"À garder en tête en lisant cet article","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"En 2025, l'analyse de documents suit en gros deux voies.\n\nLa première procède **en plusieurs étapes** : détection de la mise en page, reconnaissance du texte, des tableaux, des formules, chacune confiée à un modèle spécialisé, le tout enchaîné en pipeline. C'est précis, mais les pièces sont nombreuses, les jointures aussi, et les erreurs se propagent tout au long de la chaîne.\n\nLa seconde va **de bout en bout** : un VLM regarde l'image de la page entière et écrit directement le Markdown. Le processus est simple, mais une seule page demande de générer des milliers de tokens, ce qui est lent et gourmand en mémoire ; sur les pages multicolonnes ou mêlant texte et images, l'ordre de lecture se brouille souvent, et le modèle peut produire du contenu absent de l'original.\n\nPaddleOCR-VL, de l'équipe PaddlePaddle de Baidu, choisit un compromis : **la mise en page est confiée à un modèle de détection spécialisé, le contenu de chaque bloc à un tout petit VLM**. L'article a été déposé sur arXiv le 16 octobre 2025 ; cette note suit la v4 du 25 novembre. Le code et les modèles sont open source.\n\n## Définir le problème\n\nLes auteurs critiquent les deux voies sans détour.\n\nLes systèmes en plusieurs étapes sont complexes à intégrer, les erreurs s'y accumulent, et ils plafonnent sur les documents très complexes. Les modèles de bout en bout reposent sur une longue génération autorégressive, coûteuse en latence comme en mémoire ; sur les pages multicolonnes ou mêlant texte et images, leur analyse de la mise en page manque de stabilité, et ils hallucinent.\n\nLes auteurs veulent un système capable de traiter de nombreuses langues et de nombreux types d'éléments, tout en restant assez petit pour être réellement déployé.\n\n## Résoudre le problème\n\n### Deux étapes\n\n[![Vue d'ensemble de PaddleOCR-VL : à gauche, des documents non structurés (PDF, PNG, JPG, etc.) ; au centre, PP-DocLayoutV2 analyse d'abord la mise en page et produit la position, la catégorie et l'ordre de lecture des blocs, transmis par lots à PaddleOCR-VL-0.9B, qui les reconnaît selon quatre instructions : OCR, tableau, formule, graphique ; à droite, la sortie en Markdown et JSON](/content/papers/assets/8ee9dd9a20b760af5b9fa7f40b97755487d35e7d6eab2577db214b267ad05ef7.png)](/content/papers/assets/8ee9dd9a20b760af5b9fa7f40b97755487d35e7d6eab2577db214b267ad05ef7.png)\n\n*Figure 2 de l'article, extraite de la [**page 5 du PDF v4**](https://arxiv.org/pdf/2510.14528v4#page=5), CC BY 4.0.*\n\nDe gauche à droite :\n\n1. **PP-DocLayoutV2** lit l'image de la page entière, trouve la position et la catégorie de chaque bloc (texte, tableau, formule, graphique, etc.) et prédit leur ordre de lecture.\n2. Chaque bloc est découpé et transmis par lots à **PaddleOCR-VL-0.9B**, avec l'instruction qui correspond à sa catégorie : OCR, reconnaissance de tableau, de formule ou de graphique.\n3. Un post-traitement léger assemble les résultats des deux étapes et produit du Markdown et du JSON.\n\n### La mise en page : détecter, puis ordonner\n\nPP-DocLayoutV2 enchaîne deux réseaux :\n\n- un modèle de détection fondé sur **RT-DETR**, qui trouve et classe les éléments de la mise en page ;\n- un **réseau de pointeurs** (*pointer network*), un Transformer à 6 couches chargé d'établir l'ordre de lecture.\n\nLa méthode de tri mérite un coup d'œil. Chaque bloc détecté est d'abord représenté par un encodage de position 2D absolu, auquel s'ajoute un embedding de catégorie ; l'attention intègre en plus le biais géométrique de Relation-DETR, pour que le modèle tienne compte directement de la position relative de deux blocs. Ensuite, une tête de sortie de relations par paires calcule pour chaque paire de blocs un score qui indique « lequel lire en premier », ce qui donne une matrice $N\\times N$. Enfin, un décodage déterministe par « cumul des victoires » produit un ordre cohérent.\n\nEssayons avec une page de trois blocs : un titre en haut, puis deux colonnes, à gauche et à droite. Les nombres du tableau donnent la probabilité que « le bloc de la ligne (à gauche) doive être lu avant le bloc de la colonne (en haut) » (valeurs illustratives) :\n\n| | Titre | Colonne gauche | Colonne droite |\n| --- | --- | --- | --- |\n| Titre | — | 0,92 | 0,95 |\n| Colonne gauche | | — | 0,81 |\n\nComparons chaque paire une fois : le titre bat la colonne gauche et la colonne droite, deux victoires ; la colonne gauche bat la colonne droite, une victoire ; la colonne droite, aucune. Classés par nombre de victoires : titre → colonne gauche → colonne droite.\n\nL'intérêt de cette méthode : l'ordre résulte d'une comparaison d'ensemble, et une erreur sur une paire ne le fait pas trop dévier. De plus, il s'agit d'un petit modèle indépendant, qu'on peut entraîner et évaluer séparément.\n\n### La reconnaissance : un petit modèle de 0,9B\n\nPaddleOCR-VL-0.9B adopte une architecture de type LLaVA, en trois parties :\n\n- **Encodeur visuel** : de style NaViT, il accepte des entrées en résolution native et est initialisé avec le modèle visuel de Keye-VL. Selon les auteurs, l'image n'a pas à être redimensionnée ni déformée par un découpage en tuiles ; les hallucinations sont moins nombreuses, et les contenus denses en texte sont mieux traités.\n- **Couche de projection** : un MLP à deux couches, qui fusionne les caractéristiques visuelles voisines avant de les transmettre au modèle de langage.\n- **Modèle de langage** : **ERNIE-4.5-0.3B**, avec 3D-RoPE. Les auteurs prennent soin d'expliquer pourquoi ils ont choisi un modèle de langage aussi petit : la génération autorégressive ne produit qu'un token à la fois, et la taille du décodeur détermine directement la latence.\n\nLe modèle complet prend en charge 109 langues.\n\n### Entraînement et données\n\nL'entraînement se fait en deux temps :\n\n1. **Préentraînement d'alignement** : 29 millions de paires image-texte, un epoch, résolution maximale de 1280×28×28.\n2. **Affinage sur instructions** : 2,7 millions d'exemples, deux epochs, résolution maximale portée à 2048×28×28. Quatre tâches : OCR, tableaux (sortie au format OTSL), formules (LaTeX qui distingue formules en ligne et hors texte), graphiques (sortie en tableau Markdown).\n\nLes données proviennent de jeux publics, de données synthétiques, de documents variés collectés sur le web et de données internes accumulées par l'équipe au fil des années. Le processus d'annotation vaut le détour :\n\n1. L'outil en plusieurs étapes de l'équipe, PP-StructureV3, produit d'abord des pseudo-annotations préliminaires.\n2. L'image d'origine et ses pseudo-annotations sont confiées à de grands modèles multimodaux comme ERNIE-4.5-VL ou Qwen2.5-VL, chargés de les corriger.\n3. Un **filtrage des hallucinations** supprime enfin le contenu que les grands modèles ont pu inventer.\n\nMême pour fabriquer des données d'entraînement, il faut se prémunir contre les grands modèles qui ajoutent du texte de leur cru.\n\nLes auteurs ont aussi construit un moteur d'évaluation qui répartit le texte en 23 catégories, dont chinois, anglais, imprimé, manuscrit, japonais, latin et emoji, et les tableaux en 20 catégories ; il sert à repérer les échantillons difficiles pour compléter les données de manière ciblée.\n\n## Discussion\n\n### OmniDocBench v1.5\n\nSur OmniDocBench v1.5 (1 355 pages), PaddleOCR-VL obtient un score global de 92,86, devant MinerU2.5, deuxième avec 90,67. Il mène aussi sur tous les sous-indicateurs : distance d'édition du texte de 0,035, CDM des formules de 91,22, TEDS des tableaux de 90,89, distance d'édition de l'ordre de lecture de 0,043.\n\nSur olmOCR-Bench, son score global est de 80,0, avec les meilleurs résultats dans les catégories ArXiv et en-têtes et pieds de page.\n\nCes résultats sont rapportés par les auteurs eux-mêmes. Plus tard, quand l'article de DeepSeek-OCR 2 cite les résultats officiels d'OmniDocBench, PaddleOCR-VL y figure aussi avec 92,86, en tête de tous les modèles.\n\n### Vitesse\n\nSur une seule A100, avec des lots de 512 PDF, les auteurs mesurent le temps de bout en bout, du chemin du PDF en entrée jusqu'au Markdown complet en sortie. Déployé avec FastDeploy, PaddleOCR-VL traite 53,1 % de pages par seconde de plus que MinerU2.5, et produit 50,9 % de tokens par seconde de plus.\n\nUn petit modèle de langage, et une reconnaissance limitée aux blocs découpés : de quoi prendre une sérieuse avance en vitesse.\n\n### Les versions suivantes\n\nPaddleOCR-VL a ensuite connu une version 1.5 (janvier 2026) et une version 1.6 (juin 2026). Dans le classement officiel d'OmniDocBench v1.6, PaddleOCR-VL-1.6 obtient un score global de 96,34, parmi les tout premiers. [OmniDocBench README](https://github.com/opendatalab/OmniDocBench)\n\n### À garder en tête en lisant cet article\n\n1. **Des résultats surtout autodéclarés.** Ceux d'OmniDocBench ont pu être recoupés plus tard avec le classement officiel ; les autres évaluations internes ne sont pas vérifiables de façon indépendante.\n2. **Une erreur de mise en page ne se rattrape pas en aval.** La conception en deux étapes concentre le risque sur l'analyse de la mise en page : si un bloc n'est pas détecté, son texte ne sera jamais reconnu. La partie détection de PP-DocLayoutV2 est entraînée sur plus de 20 000 échantillons constitués par l'équipe ; elle est ensuite gelée, et le réseau d'ordonnancement est entraîné séparément.\n3. **De grands modèles ont participé à l'annotation.** Les pseudo-annotations sont corrigées par ERNIE-4.5-VL et Qwen2.5-VL, puis passent un filtrage des hallucinations ; l'article ne chiffre pas ce que ce filtrage parvient à intercepter.\n\n## Conclusion\n\nLa conception de PaddleOCR-VL repose sur une division du travail très pragmatique :\n\n1. **La mise en page au modèle de détection** : RT-DETR trouve les blocs, et le réseau de pointeurs établit l'ordre de lecture par comparaisons deux à deux.\n2. **Le contenu à un tout petit VLM** : un encodeur visuel NaViT et un ERNIE de 0,3B, avec une instruction propre à chacun des quatre types d'éléments.\n3. **Des résultats et de la vitesse** : 92,86 au score global d'OmniDocBench v1.5, et un débit supérieur d'environ 50 % à celui de MinerU2.5.\n\nVue depuis la vague du bout en bout, cette conception ressemble à un retour du pipeline en plusieurs étapes, à ceci près que la pièce chargée de lire est désormais un petit VLM. Il ne lit qu'un bloc à la fois et produit des sorties courtes ; selon les auteurs, cela réduit à la fois la latence et le risque d'hallucination.\n","imageSizes":{"/content/papers/assets/8ee9dd9a20b760af5b9fa7f40b97755487d35e7d6eab2577db214b267ad05ef7.png":{"width":1288,"height":555}}}