La technologie pour convertir rapidement des PDF en Markdown avec une grande précision

(github.com/VikParuchuri)

2 points par GN⁺ 2023-12-02 | 1 commentaires | Partager sur WhatsApp

Marker est un outil d’intelligence documentaire qui convertit rapidement et avec précision non seulement les PDF, mais aussi les images, documents PPTX, DOCX, XLSX, HTML et EPUB en Markdown, JSON, chunks et HTML
Il prend en charge le formatage des tableaux, formulaires, équations, mathématiques inline, liens, références et blocs de code, ainsi que l’extraction et l’enregistrement des images et la suppression d’artefacts comme les en-têtes et pieds de page
Pour améliorer la précision, il peut utiliser un LLM avec --use_llm ; la valeur par défaut est gemini-2.0-flash, et il est possible de choisir Gemini, Ollama, Claude, OpenAI, Azure OpenAI, etc.
Dans les benchmarks, Marker a enregistré en moyenne 2.83837 secondes par page PDF unique, un score heuristique de 95.6709 et un score LLM de 4.23916 ; en mode batch sur H100, un débit de 25 pages/second est attendu
Python 3.10+ et PyTorch sont requis ; le code est sous licence GPL, et les poids des modèles sont sous une licence AI Pubs OpenRAIL-M modifiée avec gratuité pour la recherche, l’usage personnel et les startups de moins de $2M

Documents et formats de sortie pris en charge par Marker

Marker convertit les documents en Markdown, JSON, chunks et HTML
Les formats d’entrée incluent PDF, images, PPTX, DOCX, XLSX, HTML et EPUB, avec prise en charge des documents dans toutes les langues
Éléments documentaires pris en charge :
- tableaux, formulaires, équations, mathématiques inline
- liens, références, blocs de code
- extraction et enregistrement des images
- suppression des en-têtes, pieds de page et autres artefacts
Il peut être étendu avec son propre formatage et sa propre logique
En fournissant un schéma JSON, il peut effectuer une extraction structurée ; cette fonctionnalité est en bêta
Il fonctionne sur GPU, CPU et MPS

Plateforme managée Datalab

La plateforme managée Datalab exécute le dernier modèle open source Chandra
Chandra est présenté comme plus précis que Marker, avec par défaut aucune conservation des données, ainsi que SOC 2 Type 2 et un BAA personnalisé
Le service de traitement par lots pour les workloads à grand volume a déjà traité plus de 200M pages par semaine
À l’inscription, $5 de crédits gratuits sont offerts, ainsi qu’un playground public
Une licence est nécessaire pour l’auto-hébergement commercial, et les licences on-premise font l’objet d’une demande séparée

Performances et mode hybride avec LLM

Marker présente des résultats de benchmark favorables face à des services cloud comme Llamaparse et Mathpix ainsi qu’à d’autres outils open source
Les résultats complets de performance dans le README sont basés sur l’exécution en série de pages PDF uniques
En mode batch, il est plus rapide, avec un débit attendu de 25 pages/second sur H100
Pour une précision maximale, un LLM peut être utilisé avec le flag --use_llm
- fusion de tableaux sur plusieurs pages
- traitement des mathématiques inline
- amélioration du formatage des tableaux
- extraction de valeurs depuis des formulaires
Le mode hybride LLM obtient une meilleure précision sur le benchmark de tableaux que Marker seul ou Gemini Flash seul

Installation et usage de base

Python 3.10+ et PyTorch sont requis
Installation centrée sur les PDF :
```
pip install marker-pdf
```
Pour traiter d’autres formats que le PDF, il faut installer des dépendances supplémentaires
```
pip install marker-pdf[full]
```
Conversion d’un fichier unique :
```
marker_single /path/to/file.pdf
```
Conversion de plusieurs fichiers par dossier :
```
marker /path/to/input/folder
```
Conversion sur plusieurs GPU :
```
NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
```
- NUM_DEVICES est le nombre de GPU à utiliser et doit être supérieur ou égal à 2
- NUM_WORKERS est le nombre de processus parallèles par GPU

Principales options CLI

--page_range TEXT : spécifie les numéros et plages de pages à traiter
--output_format [markdown|json|html|chunks] : spécifie le format de sortie
--output_dir PATH : spécifie le répertoire d’enregistrement des fichiers de sortie
--paginate_output : ajoute les numéros de page et des séparateurs à la sortie
--use_llm : améliore la précision avec un LLM
--force_ocr : force l’application de l’OCR à l’ensemble du document et formate aussi correctement les mathématiques inline
--block_correction_prompt : spécifie un prompt pour corriger la sortie de Marker en mode LLM
--strip_existing_ocr : supprime le texte OCR existant et relance l’OCR avec surya
--redo_inline_math : améliore la qualité de conversion des mathématiques inline avec --use_llm
--disable_image_extraction : n’extrait pas les images depuis le PDF
--converter_cls : permet de choisir le convertisseur par défaut marker.converters.pdf.PdfConverter ou le convertisseur dédié aux tableaux marker.converters.table.TableConverter
--llm_service : spécifie le service LLM lors de l’utilisation de --use_llm ; la valeur par défaut est marker.services.gemini.GoogleGeminiService
--workers : spécifie le nombre de workers de conversion simultanés
- chaque worker utilise jusqu’à 5GB de VRAM, avec une moyenne de 3.5GB de VRAM

API Python et manipulation interne des blocs

Il est possible de convertir directement en Python avec PdfConverter

from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("FILEPATH")
text, _, images = text_from_rendered(rendered)

En sortie Markdown, rendered possède les attributs markdown, metadata, images
En sortie JSON, rendered possède children, block_type, metadata
ConfigParser permet de configurer le format de sortie, les processors, les renderers, le service LLM, etc.
Les documents sont structurés en arbre de pages et de blocs, et chaque page peut contenir à son tour des blocs
contained_blocks permet d’extraire programmatiquement uniquement certains blocs, comme les formulaires

Types de convertisseurs

PdfConverter : convertisseur par défaut pour convertir un PDF complet
TableConverter : extrait et convertit uniquement les tableaux
- avec force_layout_block=Table, il évite la détection de mise en page et suppose que toutes les pages sont des tableaux
- avec output_format=json, il est aussi possible d’obtenir les bounding box des cellules
OCRConverter : exécute uniquement l’OCR
- avec --keep_chars, il conserve les caractères individuels et leurs bounding box
ExtractionConverter : convertisseur d’extraction structurée en bêta
- il faut d’abord configurer le service LLM
- il renvoie les valeurs extraites en sortie JSON
- en passant original_markdown d’une exécution précédente comme existing_markdown, il est possible d’éviter le reparsing du document

Formats de sortie

Sortie Markdown :
- liens d’images
- tableaux formatés
- équations LaTeX encadrées par $$
- blocs de code avec triple backticks
- exposants pour les notes de bas de page
Sortie HTML :
- images avec balises img
- équations avec balises <math>
- code avec balises pre
Sortie JSON :
- les pages sont représentées sous forme de liste, chaque page étant un bloc du schéma interne de Marker
- elle contient les clés id, block_type, html, polygon, children
- les blocs enfants ajoutent section_hierarchy et images
- la structure des blocs est arborescente
Sortie Chunks :
- similaire au JSON, mais tout est aplati dans une liste unique
- inclut le HTML complet de chaque bloc, ce qui permet un chunking flexible pour le RAG
Tous les formats de sortie renvoient metadata
- table_of_contents, une table des matières PDF calculée
- page_stats, qui contient la méthode d’extraction de texte et le nombre de blocs par page

Services LLM pris en charge

Services sélectionnables avec --use_llm :
- Gemini : utilise par défaut l’API Gemini developer et requiert --gemini_api_key
- Google Vertex : requiert --vertex_project_id et la spécification de marker.services.vertex.GoogleVertexService
- Ollama : utilise un modèle local avec --ollama_base_url et --ollama_model
- Claude : nécessite --claude_api_key et --claude_model_name
- OpenAI : prend en charge les endpoints compatibles OpenAI avec --openai_api_key, --openai_model, --openai_base_url
- Azure OpenAI : nécessite --azure_endpoint, --azure_api_key, --deployment_name

Architecture interne et points d’extension

Marker fonctionne comme un pipeline de modèles de deep learning
- extraction du texte, avec OCR si nécessaire
- détection de la mise en page des pages et de l’ordre de lecture
- nettoyage et formatage de chaque bloc
- amélioration de la qualité via un LLM si nécessaire
- fusion des blocs et post-traitement du texte complet
Les étapes liées à l’OCR et à la mise en page utilisent surya
Le formatage des équations s’appuie sur texify
Composants clés :
- Providers : fournissent les informations à partir de fichiers source comme les PDF
- Builders : créent les blocs initiaux du document et remplissent le texte
- Processors : traitent certains blocs spécifiques, comme le formateur de tableaux
- Renderers : rendent les blocs dans le format de sortie
- Schema : classes pour tous les types de blocs
- Converters : exécutent l’ensemble du pipeline end-to-end
Pour modifier le comportement du traitement, il faut redéfinir processors
Pour un nouveau format de sortie, il faut ajouter un nouveau renderer
Pour un nouveau format d’entrée, il faut ajouter un nouveau provider

Serveur API et déploiement

Il est possible de lancer un serveur FastAPI simple

pip install -U uvicorn fastapi python-multipart
marker_server --port 8001

Le serveur est accessible sur localhost:8001, et les options des endpoints sont visibles sur localhost:8001/docs
Ce serveur API n’est pas une API robuste et est destiné uniquement à un usage limité
Pour des options de conversion plus robustes, il est possible d’utiliser l’API Datalab hébergée
Des exemples de déploiement incluent le déploiement d’un endpoint web via Modal

Résolution des problèmes

En cas de problème de précision, utiliser un LLM avec --use_llm
- dans ce cas, la clé API Gemini doit être définie via GOOGLE_API_KEY
Si du texte apparaît corrompu, relancer l’OCR du document avec force_ocr
TORCH_DEVICE permet de forcer le device torch à utiliser
En cas d’erreur de mémoire insuffisante, il est possible de réduire le nombre de workers ou de découper les longs PDF en plusieurs fichiers
L’option debug enregistre des images de pages avec la mise en page et le texte détectés, ainsi que des fichiers JSON contenant les informations de bounding box

Résultats des benchmarks

Le benchmark de conversion PDF complet utilise un jeu de benchmark créé à partir de pages PDF uniques extraites du common crawl
Les scores sont calculés à partir d’une heuristique d’alignement avec les segments de texte ground truth, ainsi que d’une méthode LLM-as-judge
Résultats de conversion PDF complète :
- marker : temps moyen 2.83837, heuristique 95.6709, LLM 4.23916
- llamaparse : temps moyen 23.348, heuristique 84.2442, LLM 3.97619
- mathpix : temps moyen 6.36223, heuristique 86.4281, LLM 4.15626
- docling : temps moyen 3.69949, heuristique 86.7073, LLM 3.70429
marker et docling ont été exécutés sur H100, tandis que llamaparse et mathpix utilisent des services cloud
Le benchmark de débit sur de longs PDF utilise Think Python
- marker : 0.18 seconde par page
- 43.42 secondes par document
- 3.17GB de VRAM
- 22 processus individuels peuvent être exécutés sur H100, pour un débit estimé de 122 pages/second
Le benchmark de conversion de tableaux compare la représentation HTML du split de test FinTabNet
- marker : score moyen 0.816, total 99 tableaux
- marker w/use_llm : score moyen 0.907, total 99 tableaux
- gemini : score moyen 0.829, total 99 tableaux
En raison des différences entre FinTabNet et la méthode de détection du modèle de layout, les tableaux impossibles à aligner avec la ground truth sont filtrés

Limites et licence

Le PDF est un format difficile à traiter, et Marker ne fonctionne donc pas toujours parfaitement
Limites connues :
- les mises en page très complexes avec tableaux imbriqués et formulaires peuvent ne pas fonctionner
- le rendu des formulaires peut être imparfait
Les flags --use_llm et --force_ocr permettent de résoudre la plupart de ces problèmes
Les poids des modèles sont sous licence AI Pubs OpenRAIL-M modifiée
- ils sont gratuits pour la recherche, l’usage personnel et les startups avec financement/chiffre d’affaires inférieur à $2M
Le code est sous licence GPL
Une licence commerciale plus large ou la suppression des obligations GPL relèvent de la page de tarification

1 commentaires

GN⁺ 2023-12-02

Avis sur Hacker News

La façon dont le dépôt compare avec Nougat dans son ensemble est un peu déroutante
Nougat est un modèle entraîné spécifiquement pour les documents académiques, et je ne pense pas qu’il ait jamais été présenté comme le meilleur modèle d’OCR. Même dans le benchmark, il est indiqué que Nougat est plus précis sur les documents arXiv. Par ailleurs, dire que marker convertit moins bien les formules que Nougat tout en comparant la vitesse avec Nougat est aussi un peu regrettable, justement parce que c’est un modèle pour documents académiques
Si vous voulez faire de l’OCR sur des PDF contenant des maths, Nougat vaut vraiment la peine d’être essayé. Il s’installe facilement comme paquet Python et extrait formules, texte, tableaux, etc. dans un fichier .mmd avec une seule commande. Pour un usage personnel, la vitesse est correcte aussi : sur un portable i5 vieux de 4 ans, il a fallu environ 30 secondes pour convertir un document de 6 pages uniquement avec le CPU
- Comparer deux choses ne signifie pas que l’outil existant ait été promu comme le meilleur
  C’est simplement une manière de placer le nouvel outil à côté d’un repère familier. Comme vous le dites, Nougat est facile à installer et à lancer, donc il est naturel de s’en servir comme point de comparaison. Ce serait évidemment encore mieux et plus utile si la comparaison incluait davantage de bibliothèques
- Je me demande dans quelle mesure Nougat traiterait bien les PDF de livres de règles de RPG
  Je cherche un modèle d’OCR qui m’aiderait à convertir des extraits de livres de RPG en Markdown. Idéalement, les emphases comme le gras ou l’italique seraient conservées
  Le mélange de texte, de chiffres et de symboles mathématiques ressemble à celui de documents techniques ou académiques, mais on y trouve souvent des mises en page bizarres, des encadrés de texte dans les marges et beaucoup de tableaux
- Je suis l’auteur. Mon cas d’usage est la conversion en masse de PDF scientifiques, donc Nougat était la meilleure solution, et c’est pourquoi je l’ai pris comme comparaison de base
  Plus bas, j’ai aussi comparé avec une extraction de texte simple. Nougat est un excellent modèle et convertit bien beaucoup de PDF, mais je voulais quelque chose de plus rapide et de plus généralisable
- J’aimerais extraire des états financiers sous forme de tableaux dans des PDF ; Nougat convient-il aussi à ce genre d’usage ?
Il ne faut pas sous-estimer l’impact de ce type d’outil. Il s’agit de libérer une quantité énorme de connaissances enfermées dans un format « agréable à lire, mais mauvais pour la diffusion »
C’est vraiment prometteur. Ce serait bien de créer un pipeline : tous les PDF → tout convertir en Markdown → tout archiver sur archive.org
- Pour de l’archivage, ce pipeline ne me semble pas approprié. Un meilleur ordre serait tous les PDF → archiver les originaux → convertir en Markdown
  Ainsi, à chaque correction de bug et à chaque amélioration, on peut relancer la conversion. En général, pour la conservation d’archives, on préfère stocker les données sous une forme aussi proche que possible des originaux, car toutes les conversions ultérieures ne peuvent qu’entraîner une perte de données
- En réalité, le PDF est un excellent format de diffusion
  On peut y inclure de manière invisible les données brutes utilisées pour générer le document vu par l’utilisateur final, dans le format que l’on veut. Par exemple, si l’on rend du HTML avec PrinceXML pour produire un PDF, on peut mettre dans le PDF le JSON source utilisé pour générer tout le texte, les graphes, les diagrammes, etc. Bien sûr, la plupart des gens ne le font pas en pratique, mais ce n’est pas la faute de la spécification
- Je suis l’auteur. C’est justement l’une des raisons pour lesquelles j’ai créé cet outil
  https://github.com/VikParuchuri/libgen_to_txt peut aussi être intéressant. Je ne l’ai pas encore intégré à marker, et pour l’instant il utilise une extraction de texte simple
- La demande pour ce genre d’outil est énorme. Les grandes organisations qui ont beaucoup de documents PDF sous des formes variées seront forcément très intéressées
  Même s’il ne couvre qu’une partie des besoins ou des cas d’usage, s’il fonctionne correctement, il sera très utile
- C’est aussi très utile du point de vue de l’accessibilité
  Rendre des PDF correctement accessibles représente un travail énorme, et même quand c’est fait, il y a de fortes chances que le lecteur PDF utilisé par l’utilisateur ne prenne pas en charge les standards nécessaires
Je vais l’essayer moi-même ce week-end
Je retranscris souvent à la main des scans de PDF de RPG d’origine inconnue, soit sans OCR permettant de sélectionner du texte, soit avec un OCR de mauvaise qualité
Il arrive littéralement que taper directement soit plus rapide que corriger les erreurs de copier-coller ou les erreurs après OCR
Même avec des PDF officiels, la mise en forme est souvent cassée, avec des doubles ou triples espaces, ou des tabulations entre les mots. Si ça marche correctement, cela pourrait vraiment faire gagner beaucoup de temps
- J’avais aussi ce cas d’usage en tête. J’ai déjà essayé avec un livre, mais les résultats n’étaient pas très bons
  Les tableaux et les encadrés de texte étaient très dégradés. En faisant une capture d’écran d’un tableau et en la collant dans ChatGPT pour demander une conversion en tableau Markdown, j’ai obtenu de très bons résultats. Avec un peu de prompt, du type « lis ligne par ligne ; les en-têtes de colonnes sont X, Y, Z ; X est du texte, Y est un nombre, Z est un mot », il arrivait même à traiter des tableaux irréguliers
- Parmi les ressources liées aux RPG, il y en a vraiment beaucoup qui n’ont même jamais existé sur support physique et qui sont devenues orphelines du point de vue de la propriété intellectuelle, donc c’est exactement ce qui m’est venu à l’esprit
Aujourd’hui, Tesseract OCR est-il correct ? Quand je l’avais essayé par le passé, il était très loin derrière les OCR en ligne d’AWS, Azure et GCP
- Il y a eu pas mal de mises à jour récentes, et le dépôt git mentionne Tesseract 5 comme dépendance. Il est très possible qu’il se soit nettement amélioré depuis la dernière fois que je l’ai utilisé
  https://github.com/tesseract-ocr/tesseract/releases
  Au final, cela dépendra sans doute du cas d’usage. Pour ce genre de travail personnel, il a de bonnes chances d’être suffisant, sans nécessiter d’informations utilisateur ni de carte bancaire
- Il était meilleur que ce à quoi je m’attendais, et ses performances dans le navigateur étaient impressionnantes
  En revanche, il est très sensible à la résolution. Quand l’image descend en dessous d’une certaine taille, même si elle reste parfaitement lisible pour un humain, la sortie de Tesseract devient catastrophique
- Il faut pas mal de prétraitement. Je n’ai essayé que la solution GCP, mais d’après mon expérience elle était meilleure
- Je l’ai essayé assez récemment et il a échoué même sur des images très basiques
  J’ai aussi essayé l’API iOS Vision, mais elle a également échoué. Le cas de test était une photo nette d’une page de livre
Question à l’auteur : pourquoi Markdown ? La partie difficile de cet outil semble être de parser le PDF avec une grande précision, pas vraiment le format dans lequel il l’exporte ensuite.
Ce serait donc bien que l’utilisateur puisse choisir le format de sortie. S’il existe un parseur PDF très précis, j’aimerais l’utiliser pour générer des EPUB
- Il faut bien une forme de balisage capable de préserver autant que possible le balisage structurel.
  Je gère des ebooks dans une presse universitaire, et nous avons une longue liste d’anciens titres en attente de conversion, dont beaucoup n’existent plus que sous forme de scans de pages d’anciennes éditions imprimées. Pour les proposer en EPUB, il faut savoir où se trouvent les séparations de chapitres, les titres, les tableaux, les graphiques, les formules, les citations, etc. Des prestataires peuvent le faire, mais pour certains livres, le coût de conversion dépasse les recettes de vente. Ce serait utile de pouvoir en faire au moins une partie nous-mêmes
- Je suis d’accord pour dire que le format intermédiaire devrait être proche du texte brut, afin de pouvoir être converti facultativement vers d’autres formats.
  Cela dit, ici, Markdown semble servir de format intermédiaire. Il est proche du texte brut, tout en pouvant préserver des informations de mise en page simples. En pratique, j’imagine qu’on prendrait la sortie Markdown pour la brancher sur un outil qui la convertit vers le format de sortie final souhaité
- La raison du choix de Markdown est que je voulais préserver les formules, les tableaux, les informations de gras/italique et les titres.
  Les formules peuvent être entourées de $/$$. Je n’ai pas encore étudié la sortie EPUB, mais ces besoins excluaient le texte brut
J’ai un cas d’usage particulier pour lequel je n’ai pas encore trouvé de bonne solution : lire des documents de construction.
Les plans arrivent toujours en PDF, alors que j’obtenais de bien meilleurs résultats en parsant des fichiers DXF (AutoCAD). Mais même quand je suis l’entrepreneur général sur le chantier, il n’est pas toujours facile d’obtenir les DXF auprès de l’architecte
Je lis surtout les textes longs sur une liseuse ebook.
Les PDF, en particulier avec une mise en page en plusieurs colonnes, sont presque un cauchemar avec les fonctions de base de l’Amazon Kindle ou du Pocketbook. Cet outil semble pouvoir améliorer nettement l’expérience de lecture
Beau travail.
Je me demandais d’où venaient les hallucinations visibles dans la sortie de Nougat. En parcourant la sortie Nougat de l’exemple Think Python, on voit de quoi il s’agit.
En relisant, j’ai vu que cela passe par un LLM, donc les hallucinations étaient prévisibles
- Je pense que ce genre d’outil reste dangereux tant que le taux d’hallucination du texte ou de la mise en forme n’est pas inférieur au taux d’erreur d’un lecteur attentif relisant le document plusieurs fois.
  Ce niveau est proche de zéro, et selon l’usage, il doit parfois être réellement nul. Si le contenu exact du document n’a pas d’importance, c’est globalement acceptable, mais il me semble rare qu’il existe de grandes quantités de documents qui ne soient importants pour personne, ni aujourd’hui ni à l’avenir, tout en devant être plus accessibles que des PDF
Ça ressemble à un outil qui pourrait m’aider à migrer mes notes depuis OneNote
- Et si tu essayais ça ?
  https://help.obsidian.md/import/onenote
- Je me demande en quoi cela aide avec OneNote
C’est assez intéressant. Ce serait bien d’ajouter au repo quelques exemples avant/après conversion.
Je me demande pour quels types de PDF vous l’optimisez. Comment les annotations manuscrites sont-elles traitées ?