Le benchmark de Datalab Marker v2 face à MinerU, Docling et Liteparse

Le Marker 2 de Datalab face à MinerU, Docling et LiteParse : 76,0 sur olmOCR-bench avec un débit 5 fois supérieur à MinerU

Voici l'article traduit et résumé : Datalab a publié Marker 2, une réécriture complète de son pipeline open source de conversion de documents, le 21 juillet 2026. Marker convertit les fichiers PDF, images, PPTX, DOCX, XLSX, HTML et EPUB en markdown, JSON, HTML ou en chunks. Cette nouvelle version s'appuie sur trois composants développés ces derniers mois par l'équipe de Datalab : Surya OCR 2, un modèle de détection de mise en page rapide de 20 millions de paramètres, et une version reconstruite de pdftext trois fois plus rapide que la précédente. Sur le benchmark olmOCR-bench d'Allen AI, référence tierce composée de 1403 PDF et d'environ 8400 tests, le mode équilibré de Marker 2 obtient un score global de 76,0% et 83,5% sur les documents PDF nativement numériques, tout en traitant 2,9 pages par seconde sur un seul GPU B200. À titre de comparaison, MinerU plafonne à 72,7% avec seulement 0,54 page par seconde, et Docling atteint 50,3% à 2,1 pages par seconde sur le même test. Cette avancée change concrètement la donne pour les équipes qui doivent extraire et structurer de grands volumes de documents, un besoin central dans l'entraînement de modèles de langage, l'indexation documentaire ou l'automatisation de flux d'entreprise. Un gain de vitesse supérieur à 5 fois par rapport à MinerU, à qualité égale voire supérieure sur les documents natifs, réduit directement les coûts d'infrastructure et les délais de traitement à grande échelle. Marker 2 propose désormais trois modes selon les besoins : le mode équilibré qui mobilise le modèle Surya pour les documents complexes, un mode rapide combinant un détecteur léger et un usage minimal du modèle de vision pour un coût réduit, et un mode sans OCR fonctionnant uniquement sur CPU, à 43,6% de score mais 23,7 pages par seconde. La sélection automatique du mode selon le matériel disponible facilite l'adoption par des équipes aux ressources GPU limitées. Cette évolution s'inscrit dans une course plus large entre plusieurs outils open source de conversion documentaire, tous confrontés au même défi : concilier fidélité d'extraction et rapidité de traitement à l'échelle industrielle. L'architecture de Marker 2 repose sur un changement structurel clé, plusieurs processus légers tournant sur CPU partagent un seul serveur d'inférence Surya, ce qui permet au débit de suivre la capacité du serveur plutôt que d'être limité par la mémoire GPU de chaque processus. Datalab revendique une amélioration notable par rapport au traitement en flux unique. La mise à jour s'accompagne toutefois de changements majeurs à anticiper avant toute migration : Python 3.10 minimum désormais requis, passage de Poetry à uv pour le packaging, et suppression du convertisseur d'extraction structurée, les utilisateurs étant désormais orientés vers l'API hébergée ou un usage combiné avec un LLM.

💬 Sur le papier, c'est le genre de bond qu'on n'a pas vu souvent : 5 fois plus rapide que MinerU sans sacrifier la qualité sur les PDF natifs, c'est rare. Ce qui change vraiment la donne, c'est le mode CPU sans GPU, ça ouvre l'extraction documentaire à masse aux équipes qui n'ont pas de cluster à disposition. Reste que la casse côté migration (Python 3.10, uv, convertisseur structuré supprimé) va faire râler pas mal de monde qui tournait déjà en prod avec l'ancienne version.

« Datalab Lift face à la concurrence : comment un extracteur à 9 milliards de paramètres, guidé par schéma, se compare à NuExtract3, LlamaExtract, Marker et Docling »

Datalab a lancé Lift, un outil d'extraction de documents qui promet une approche différente des solutions existantes. Le principe : on lui fournit un PDF ou une image accompagné d'un schéma JSON, et le modèle retourne directement les données structurées correspondantes, sans passer par une conversion intermédiaire en Markdown. Lift s'appuie sur un modèle de vision de 9 milliards de paramètres, capable de lire les images des pages rendues et de produire l'objet JSON final en une seule passe grâce à un décodage contraint par le schéma. Selon les benchmarks internes de Datalab, Lift atteint une précision de champs de 90,2%, contre 81,5% pour son principal concurrent open-weight, NuExtract3, développé par NuMind. Ce dernier, un modèle de 4 milliards de paramètres sous licence Apache-2.0, combine extraction structurée et conversion image-vers-Markdown, et cible des documents comme les factures, reçus, formulaires et contrats. Cette approche change la manière dont les entreprises peuvent construire leurs pipelines de traitement documentaire. Jusqu'à présent, la pratique dominante consistait à convertir un PDF en Markdown ou en texte structuré via des outils comme Docling, MinerU, Marker ou Unstructured, puis à envoyer cette représentation à un grand modèle de langage avec un schéma pour en extraire les champs utiles. Lift propose de fusionner ces deux étapes en une seule, ce qui réduit la complexité du pipeline lorsque l'objectif final est réellement l'extraction de champs précis, comme un numéro de facture, un nom de fournisseur ou une liste de lignes de commande, plutôt que la reconstruction fidèle du document dans son ensemble. Pour les équipes d'ingénierie qui traitent de gros volumes de documents visuellement complexes, cela peut se traduire par moins de composants à maintenir et une latence réduite, au prix d'une dépendance plus forte à un seul modèle propriétaire. Le marché de l'extraction documentaire par IA s'est considérablement densifié ces derniers mois, avec plusieurs catégories d'outils qui se chevauchent sans être toujours en concurrence directe. D'un côté, les parseurs comme Docling, MinerU, Marker, Unstructured, PyMuPDF ou Surya, qui produisent des représentations fidèles du document plutôt que des données applicatives. De l'autre, les extracteurs schéma-first comme Lift, NuExtract3, LlamaExtract, Reducto Extract ou Extend, ainsi que les géants du cloud comme Azure, Google et AWS avec leurs propres systèmes de compréhension documentaire. Des bibliothèques de génération structurée comme XGrammar, Outlines, Instructor ou BAML complètent cet écosystème en garantissant la conformité des sorties JSON. Face à ce paysage fragmenté, le choix entre Lift et ses alternatives dépendra moins de la performance brute que des priorités de chaque équipe : licence permissive, taille du déploiement local, ou besoin d'un modèle unique capable à la fois d'extraire et de convertir en Markdown.

Implémentation Python pour le benchmarking de parsing de documents avec LlamaIndex ParseBench

LlamaIndex a publié ParseBench, un jeu de données de référence conçu pour évaluer de manière rigoureuse les systèmes d'analyse de documents. Hébergé sur Hugging Face sous l'identifiant llamaindex/ParseBench, ce benchmark est structuré autour de plusieurs dimensions d'évaluation distinctes : extraction de texte brut, reconnaissance de tableaux, interprétation de graphiques et respect de la mise en page. La procédure d'utilisation s'appuie sur un pipeline Python standardisé mobilisant des bibliothèques open source comme datasets, pandas, PyMuPDF (alias fitz), rapidfuzz et rich. Les données sont distribuées au format JSONL, avec des fichiers PDF associés accessibles directement depuis le dépôt Hugging Face via hfhubdownload. Le pipeline de référence décrit dans le tutoriel officiel construit un extracteur de texte léger basé sur PyMuPDF, compare les sorties aux annotations de référence grâce à des métriques de similarité floue (fuzz), et produit des visualisations de la distribution des exemples par dimension. L'importance de ParseBench réside dans le manque criant de standards objectifs pour comparer les moteurs d'analyse documentaire, qu'il s'agisse de solutions OCR classiques, de modèles de vision-langage ou de parseurs hybrides. Jusqu'ici, les équipes évaluaient leurs systèmes sur des jeux de données internes non reproductibles, rendant toute comparaison inter-organisations impossible. Avec ce benchmark unifié, les développeurs peuvent mesurer la qualité de l'extraction sur chaque dimension séparément, texte, tableaux, graphiques, layout, et identifier précisément où leurs pipelines échouent. Pour les entreprises qui traitent des volumes importants de documents (contrats, rapports financiers, publications scientifiques), disposer d'un tel outil de mesure change concrètement la façon dont on sélectionne et valide un moteur de parsing avant de le passer en production. ParseBench s'inscrit dans une tendance plus large portée par LlamaIndex, qui cherche à standardiser l'outillage autour des pipelines RAG (retrieval-augmented generation). La qualité de l'extraction documentaire est en effet le maillon critique souvent négligé de ces architectures : un PDF mal parsé produit des embeddings bruités, ce qui dégrade directement les réponses des assistants IA en aval. Plusieurs acteurs du secteur, comme Unstructured, LlamaParse ou encore Docling d'IBM, se livrent une concurrence directe sur ce segment. L'arrivée d'un benchmark public et reproductible oblige désormais ces acteurs à rendre des comptes sur des métriques communes. Les prochaines étapes probables incluent l'intégration de modèles de vision-langage comme GPT-4o ou Qwen-VL comme baselines supplémentaires, et l'extension du benchmark à des formats au-delà du PDF.

Langages dynamiques : plus rapides et moins coûteux dans le benchmark Claude Code à 13 langages

Un benchmark de 600 exécutions mené par Yusuke Endoh, contributeur au langage Ruby, a comparé les performances de Claude Code sur 13 langages de programmation différents, en lui faisant implémenter une version simplifiée de Git. Les résultats montrent que Ruby, Python et JavaScript sont les langages les plus rapides et les moins coûteux, avec un tarif compris entre 0,36 et 0,39 dollar par exécution. Les langages à typage statique, comme Java, Go ou Rust, se révèlent 1,4 à 2,6 fois plus chers. L'ajout de vérificateurs de types aux langages dynamiques entraîne quant à lui des ralentissements de 1,6 à 3,2 fois. Le jeu de données complet est disponible sur GitHub. Ces chiffres ont des implications directes pour les équipes qui utilisent des agents de codage alimentés par des LLM dans leurs workflows de développement. Le choix du langage influence non seulement la vitesse d'exécution des agents, mais aussi le coût opérationnel à grande échelle. Pour les entreprises qui déploient Claude Code massivement, la différence entre un langage dynamique et un langage statiquement typé peut représenter une multiplication substantielle des dépenses en tokens. Cette étude s'inscrit dans un contexte où l'utilisation des agents de codage autonomes se généralise rapidement dans l'industrie. Anthropic, l'entreprise derrière Claude, pousse activement Claude Code comme outil de développement agentic. La question de l'efficacité par langage devient stratégique alors que les équipes cherchent à optimiser leurs pipelines d'automatisation du code, et ce type de benchmark indépendant fournit des données concrètes pour guider ces choix techniques.