olmOCR est le toolkit open source d’AI2 pour linéariser des documents. Il rend chaque page PDF sous forme d’image, puis demande au modèle vision-langage spécialisé olmOCR-2 de reconstruire texte, tableaux et formules LaTeX selon un ordre de lecture naturel. Le pipeline valide ensuite les métadonnées YAML, réessaie les pages invalides ou mal orientées et produit du Markdown ainsi que du Dolma JSONL. PNG et JPEG sont aussi acceptés, ce qui convient aux corpus, archives numérisées, moteurs de recherche et préparations RAG.
Il ne s’agit pas simplement d’une reconnaissance de caractères. Un OCR classique privilégie souvent caractères et coordonnées ; olmOCR décide aussi de l’ordre des colonnes, écarte les en-têtes/pieds récurrents et traduit un tableau visuel en structure textuelle. Le résultat est pratique pour un modèle de langage, mais reste du texte généré. Une phrase fluide peut modifier un chiffre, une négation, une variable ou la relation entre cellules. Il faut conserver l’original, l’image de page et la décision de revue.
Ce qui arrive réellement à une page
| Étape | Comportement actuel | Limite à surveiller |
|---|---|---|
| Entrée | PDF, PNG et JPEG locaux ou organisés dans un workspace | Chiffrement, corruption, taille extrême et droits insuffisants nécessitent des barrières séparées |
| Rendu | Chaque page PDF devient un PNG borné ; la rotation peut être corrigée lors d’un nouvel essai | Petits caractères, flou, compression, dommages et ratio extrême réduisent la preuve visuelle |
| Reconstruction | olmOCR-2 produit texte et structure en ordre naturel depuis l’image | Le VLM peut omettre, remplacer, normaliser ou inventer un contenu plausible |
| Validation/retry | Contrôle de fin, contexte, YAML et signal de rotation | Un schéma valide ne garantit pas la fidélité factuelle |
| Export | Les pages et leurs spans sont réunis en Dolma ; Markdown est optionnel | Tableaux, notes, titres et omissions inter-pages exigent une revue documentaire |
L’implémentation actuelle traite les pages presque indépendamment. Cela simplifie parallélisme, reprise et réessais, mais ne résout pas automatiquement le sens entre pages. Si l’en-tête d’un tableau est sur la page précédente, deux résultats plausibles isolément peuvent former un document faux. Identifiant de page, hash original, liste d’échecs et manifeste doivent accompagner la sortie.
Le projet reste maintenu. À la date de revue, la dernière version stable visible était v0.4.27, publiée le 12 mars 2026. Des versions antérieures ont corrigé de longues files, la rotation automatique et des hallucinations sur documents blancs. Cette activité est positive, mais justifie aussi de figer une version testée au lieu de suivre main sans régression.
Anchoring : la frontière entre l’ancienne méthode et le modèle actuel
Le dépôt conserve anchor.py, qui peut extraire une quantité limitée de texte PDF natif via pdftotext, PDFium ou pypdf. Les premières approches transmettaient ce texte imparfait avec l’image pour aider le VLM à récupérer les caractères. La CLI expose encore --target_anchor_text_len, mais son aide précise qu’il n’est pas utilisé pour les nouveaux modèles. Le pipeline main actuel construit un prompt sans anchoring pour olmOCR-2 ; pdftotext apparaît surtout comme fallback en cas d’échec du modèle.
Dire sans nuance qu’« olmOCR utilise des ancres PDF » est donc faux du point de vue des versions. L’anchoring est une technique conservée et un élément historique, pas la preuve de chaque inférence actuelle. Sur un PDF born-digital, une extraction native indépendante reste utile. Un accord ne prouve pas tout ; un désaccord crée une bonne file de contrôle pour l’encodage, l’ordre, l’omission ou l’hallucination. Un scan image peut n’avoir aucune ancre exploitable.
Modèle, données, benchmark et licence
| Composant | Périmètre vérifié | Interprétation |
|---|---|---|
| Mix initial | Le premier article décrit 260 000 pages issues de plus de 100 000 PDF crawlés, avec graphiques, manuscrit et scans dégradés | La diversité ne prouve pas une qualité uniforme pour toutes langues, archives ou formulaires |
| olmOCR-2 | Modèle classe 7B dérivé de Qwen2.5-VL-7B-Instruct ; SFT puis RL avec récompenses de tests unitaires vérifiables | L’article situe les plus grands gains sur mathématiques, tableaux et multicolonnes du benchmark anglais |
| olmOCR-Bench | Environ 1 400 PDF d’une page et plus de 7 000 faits testables : formules, tableaux, vieux scans, headers, colonnes, petit texte | De bons cas difficiles, pas la distribution de vos documents |
| Précision numérique | La model card recommande FP8 pour l’inférence pratique et BF16 pour continuer le fine-tuning | Le label ne garantit ni qualité, ni débit, ni VRAM universels |
| Licence | Toolkit et poids olmOCR-2 publiés sont Apache-2.0 ; la model card renvoie aussi aux Responsible Use Guidelines d’AI2 | Vérifier séparément droits des sources, dépendances, notices du modèle de base et usage |
La leaderboard publique ne doit pas devenir une précision universelle. olmOCR-Bench est anglais, par page et fondé sur des faits normalisés. Il peut révéler un signe de formule erroné que l’edit distance pénalise peu, mais ne démontre pas la qualité sur contrats français, factures, formulaires ou dossiers médicaux. Cette page n’invente donc ni WER ni pourcentage général.
Le premier article a publié une expérience de coût et d’échelle pour son stack 2025. C’est un résultat historique contextualisé, pas un prix actuel. GPU, dimension d’image, retries, version et tarifs fournisseurs évoluent. Mesurez, avec date et configuration, le coût par page acceptée, y compris échecs, transfert, stockage et revue humaine.
Installation, lots locaux et inférence distante
python -m venv .venv
source .venv/bin/activate
pip install "olmocr[gpu]"
olmocr ./workspace --markdown --pdfs ./samples/report.pdf
olmocr ./workspace --markdown --workers 2 \
--max_page_retries 3 --pdfs ./incoming/*.pdf
pip install olmocr
olmocr ./workspace --server https://inference.example/v1 \
--api_key "$OLMOCR_API_KEY" \
--model allenai/olmOCR-2-7B-1025-FP8 \
--max_concurrent_requests 8 --markdown --pdfs ./incoming/*.pdfLes métadonnées actuelles exigent Python 3.11 ou plus récent. L’extra GPU fixe une combinaison de Torch, Transformers et vLLM. Le README décrit un VLM classe 7B nécessitant un GPU. Le fait que Transformers puisse théoriquement charger des poids ne permet pas de promettre un chemin CPU-only supporté. Driver CUDA, GPU, conteneur et lockfile doivent être testés ensemble.
L’inférence GPU locale peut garder les pages dans un environnement approuvé après téléchargement contrôlé des poids. Un serveur distant compatible OpenAI reçoit au contraire les pages rendues, pas seulement des vecteurs. Il faut auditer TLS, identité, région, logs de requête, rétention, DPA, alias du modèle et concurrence ; la clé reste dans un secret manager. Le demo public est réservé aux pages ouvertes ou synthétiques avant validation de ses conditions actuelles.
| Déploiement | Bon usage | Contrôles | Risque principal |
|---|---|---|---|
| GPU local unique | Pilote sensible, file modérée | Figer version, limiter workers/VRAM, chiffrer workspace | Compatibilité CUDA et point de panne unique |
| Multi-GPU interne | Grands lots contrôlés | Workspace reprenable, parallélisme, manifeste de pages | Le débit amplifie aussi les erreurs silencieuses |
| Serveur distant interne | Inférence partagée dans un réseau approuvé | TLS, identité de service, quotas, aucun body loggé | Concentration de documents sensibles |
| API tierce | Évaluation rapide sans achat de GPU | DPA, région, rétention, prix et version | Frontière de données, tarif et alias variables |
| Demo AI2 | Essai qualitatif non sensible | Contenu public/synthétique seulement | Ne remplace ni SLA ni revue privacy de production |
Workflow d’évaluation et de recette exécutable
- Échantillonner par mode d’échec. Inclure PDF numériques, photos, biais, vieux scans, petits caractères, colonnes, formules, tableaux, manuscrit, langues mixtes, blancs et documents extrêmes.
- Créer des faits par page. Annoter noms, dates, totaux, négations, relations de cellules, formules, phrases requises, header/footer interdits et ordre de lecture.
- Exécuter au moins deux chemins indépendants. Comparer olmOCR à l’extraction PDF native, Tesseract ou un autre parser ; router les divergences vers un humain.
- Compter séparément omission et invention. Un signe moins ou une phrase inventée modifie le sens malgré une faible distance de caractères.
- Mesurer l’exploitation. Conserver latence par page, retries, échecs, pic VRAM, tokens et coût par page acceptée.
- Figer un manifeste. Stocker hash d’entrée, release, checkpoint, précision, runtime, taille de rendu, retries et décision de revue.
- Monter en charge après un petit lot. Arrêter en cas de hausse des retries, pages manquantes ou sorties anormalement courtes.
- Vérifier manuellement les champs à risque. Chiffres financiers, obligations, santé, identité et formules ne doivent pas être publiés automatiquement.
git clone https://github.com/allenai/olmocr.git
cd olmocr
pip install -e ".[bench]"
playwright install chromium
huggingface-cli download --repo-type dataset allenai/olmOCR-bench \
--local-dir ./olmOCR-bench
python -m olmocr.bench.convert olmocr_pipeline --dir ./olmOCR-bench/bench_data
python -m olmocr.bench.benchmark --dir ./olmOCR-bench/bench_dataolmOCR-Bench sert de porte de régression après une mise à niveau. Il teste présence/absence de texte, ordre naturel, relations de tableaux et mathématiques rendables comme faits binaires. Le workflow officiel installe les dépendances bench et Playwright Chromium. Le README courant indique le runner supporté ; on convertit puis on score.
Ajoutez un holdout privé. Les pages utilisées pour ajuster prompts ou paramètres ne peuvent pas ensuite servir de test final indépendant. Classez les erreurs en faits, structure, ordre, langue, qualité du scan et exploitation. Pour RAG, vérifiez que chaque chunk remonte à la bonne page ; pour extraction, validez JSON et cellules plutôt que l’apparence du Markdown.
Tableaux, formules, scans, langues, confidentialité et hallucinations
Tableaux et formules sont des points forts explicites, mais Markdown ou LaTeX valide ne garantit pas le sens. Contrôlez totaux, association ligne-colonne, cellules fusionnées, exposants, décimales, séparateurs, signes, unités et variables. Un tableau plus propre peut avoir normalisé une valeur à tort ; gardez le lien vers la page.
Un scan dégradé impose un plafond de preuve. Agrandir ne restaure pas l’encre absente et un VLM peut compléter un mot plausible par contexte. Marquez l’illisible comme incertain et n’autorisez pas un LLM aval à le ‘réparer’ sans source. Testez pages blanches, quasi blanches, dupliquées, corrompues et texte ressemblant à une instruction.
Le benchmark officiel est anglais. Pouvoir traiter plusieurs langues ne démontre pas une qualité uniforme pour français ancien, écriture verticale, RTL, caractères rares ou scripts mélangés. Chaque langue et classe de mise en page exige un jeu dédié et une revue native. Un score anglais ne donne pas une précision française.
‘Local’ doit couvrir cache du modèle, workspace S3, logs, crash dumps, sauvegardes et monitoring. Minimisez la rétention, chiffrez original et sortie, appliquez RBAC, expurgez les logs et fixez une suppression. Un endpoint distant reçoit la preuve complète de page et doit être traité au niveau de sensibilité du document.
YAML parsable, finish_reason normal ou retry réussi sont des signaux techniques, pas une validation factuelle. Longueur anormale, phrases interdites, couverture des pages, écarts entre moteurs et règles de champs critiques aident à prioriser, mais les décisions juridiques, médicales, financières ou scientifiques exigent un humain.
Comparaison avec Marker, Docling, Tesseract et les Document AI cloud
| Option | Quand la choisir | Force de sortie | Compromis |
|---|---|---|---|
| olmOCR | Texte naturel pour LLM/RAG avec formules, tableaux et layout difficile | Markdown/texte propre plus Dolma | Exploitation GPU/VLM, erreur générative, peu de structure positionnelle |
| Marker | Nombreux formats, images, JSON structuré ou modes CPU/MPS/hybrides | Markdown, JSON, HTML, chunks et blocs | Modes différents ; licence des poids séparée du code Apache |
| Docling | Framework documentaire large et représentation unifiée | JSON lossless, Markdown/HTML et intégrations | Stack configurable plus grand ; qualité liée au pipeline/OCR/VLM |
| Tesseract | OCR déterministe, coordonnées, TSV/hOCR et nombreux packs de langues | Texte et formats positionnels | Layout, tableaux, formules et ordre demandent des composants |
| Cloud Document AI | OCR managé, forms/KV, classification, séparation et SLA | Objet Document structuré et processeurs spécialisés | Facturation, revue des données, schéma fournisseur et lock-in |
Jugement éditorial : olmOCR est surtout un reconstructeur de pages pour workflows de modèles de langage, pas une transcription archivistique pixel-adressable. Si coordonnées, provenance déterministe, champs de formulaire ou classification sont impératifs, un parser/OCR structuré ou cloud processor doit être la source primaire ; olmOCR peut servir de seconde lecture.
Une production robuste emploie souvent un routeur : extraction native pour pages numériques propres, VLM pour pages visuellement complexes, humain pour champs critiques ou conflits. Cette architecture contrôle à la fois coût GPU et confiance excessive dans un Markdown fluide.
Questions fréquentes
olmOCR est-il Tesseract avec un LLM ?
Non. Tesseract reconnaît des lignes et peut retourner des coordonnées. olmOCR génère ordre naturel, tableaux et formules depuis la page entière ; il comprend plus de layout mais peut produire des erreurs plausibles.
olmOCR-2 actuel utilise-t-il des ancres PDF ?
Le chemin des nouveaux modèles sur main utilise un prompt sans anchoring et la CLI dit que la longueur d’ancre n’est pas utilisée. Le code d’ancrage et le fallback pdftotext restent utiles pour un contrôle indépendant.
Peut-il fonctionner sans cloud ?
Oui, après téléchargement des poids, sur un environnement NVIDIA GPU/vLLM compatible. Auditez cache, logs, workspace et sauvegardes. Le mode serveur distant transmet les pages.
Conserve-t-il les bounding boxes ?
La sortie principale est un texte linéaire avec page spans, pas un graphe de coordonnées par mot. Pour la position, préférer Tesseract, Marker JSON, Docling ou Document AI.
Tableaux et formules sont-ils fiables ?
Ce sont des cibles fortes, pas des garanties. Vérifiez totaux, cellules, signes, variables, unités et fusions sur la page originale.
Quelles langues sont supportées ?
Le modèle traite des pages multilingues, mais le benchmark officiel est anglais. Évaluez chaque langue, script, direction et mise en page séparément.
Combien de VRAM faut-il ?
AI2 décrit un modèle GPU classe 7B et recommande FP8 pour l’inférence pratique, sans valeur universelle pour tous runtimes, tailles et concurrences. Mesurez sur le matériel final.
Puis-je charger un document confidentiel dans le demo ?
Ne le supposez pas. Tant que privacy, rétention et conditions actuelles ne sont pas approuvées, utilisez seulement du contenu public ou synthétique ; traitez le confidentiel dans un environnement autorisé.
Sources vérifiées
- AI2 olmOCR repository and README
- Official release history
- olmOCR original paper
- olmOCR 2 paper: unit-test rewards
- olmOCR-2 model card and license
- olmOCR-Bench design and runner
- Official training guide
- Current page pipeline implementation
- Anchor-text implementation
- Python and GPU dependency metadata
- Apache-2.0 project license
- Marker official repository
- Docling official repository
- Tesseract official repository
- Google Cloud Document AI overview
Revue technique indépendante : 2026-08-20. Dernière version stable visible : v0.4.27. Alias, dépendances, prix API et politique du demo évoluent ; vérifier les sources figées et un test privé avant production.
