Show HN : un parseur PDF open source basé sur des règles pour le RAG

 (github.com/nlmatics)
1 points par GN⁺ 2024-01-26 | 1 commentaires | Partager sur WhatsApp
  • nlm-ingestor est le code du service auquel l’API llmsherpa se connecte, et fournit des parseurs de documents pour PDF, HTML, Text, DOCX, PPTX, etc., adaptés au RAG
  • Le parseur PDF utilise les coordonnées de texte, les graphiques et les données de police obtenus depuis une version modifiée de Tika par nlmatics, et peut appliquer automatiquement l’OCR via l’option apply_ocr si le PDF contient des pages scannées
  • Les fonctions de traitement PDF incluent le niveau section/sous-section, la fusion de paragraphes, les liens section-paragraphe, les tableaux, les listes imbriquées, la fusion de contenu entre pages, la suppression des en-têtes/pieds de page répétés, la suppression des filigranes et les boîtes englobantes OCR
  • Par rapport aux parseurs visuels basés sur des modèles, ce parseur basé sur des règles n’a pas besoin de générer des images des pages PDF et serait donc 100 fois plus rapide ; il est jugé plus pratique pour les PDF avec couche texte que pour l’OCR, ainsi que pour les documents de plusieurs centaines de pages
  • Le serveur de développement peut être lancé via Docker ou directement, et en production il est recommandé de le faire tourner derrière une passerelle de sécurité comme nginx ou une gateway cloud

Les parseurs de documents fournis par nlm-ingestor

  • nlm-ingestor est le dépôt du code de service auquel l’API llmsherpa peut se connecter
  • Il fournit des parseurs personnalisés pour plusieurs formats de fichier, conçus pour le RAG (retrieval augmented generation)

    • PDF

    • HTML

    • Text

      • DOCX, PPTX et d’autres formats pris en charge par Apache Tika

Fonctionnement et capacités du parseur PDF

  • Le parseur PDF est basé sur des règles et utilise les coordonnées de texte, les graphiques et les données de police obtenus via nlm-tika, une version modifiée par nlmatics
  • Il s’appuie sur la couche texte du PDF et peut appliquer automatiquement l’OCR aux pages scannées via l’option apply_ocr
  • La fonctionnalité OCR repose en interne sur une version modifiée de Tika par nlmatics utilisant tesseract
  • Un notebook permettant d’expérimenter directement le parseur PDF est disponible : pdf_visual_ingestor_step_by_step
  • Les fonctionnalités du parseur PDF sont les suivantes
    • identification des sections, sous-sections et de chaque niveau
    • fusion de plusieurs lignes pour former des paragraphes
    • création de liens entre sections et paragraphes
    • identification des tableaux et des sections où des tableaux ont été détectés
    • traitement des listes et des listes imbriquées
    • fusion de contenu sur plusieurs pages
    • suppression des en-têtes et pieds de page répétés
    • suppression des filigranes
    • fourniture de boîtes englobantes pour les résultats OCR

Traitement des documents HTML, Text et Office

  • Le parseur HTML génère des blocs tenant compte de la mise en page afin de produire des chunks de meilleure qualité pour améliorer les performances RAG
  • Le parseur Text infère listes, tableaux, en-têtes, etc. à partir du seul texte, sans informations visuelles, de police ni boîtes englobantes
  • Les formats DOCX, PPTX et les autres formats pris en charge par Apache Tika sont d’abord convertis via la sortie HTML de Tika, puis traités par le parseur HTML

Exécution et utilisation de l’API

  • La procédure d’exécution directe comprend l’installation de Java, le lancement du serveur Tika, l’installation de nlm-ingestor, puis le lancement de l’ingestor
    • Lancement du serveur Tika : java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • Installation : pip install nlm-ingestor
    • Exécution : python -m nlm_ingestor.ingestion_daemon
  • Une image Docker est fournie sur le GitHub Container Registry public
    • Récupérer l’image : docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • Exemple de lancement : docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • Une fois le serveur lancé, il est possible de récupérer des chunks via la bibliothèque API llmsherpa pour les utiliser dans des projets LLM
  • Exemple de llmsherpa_url : http://localhost:5010/api/parseDocument?renderFormat=all
    • Appliquer l’OCR : &applyOcr=yes
    • Utiliser le nouveau parseur d’indentation avec un algorithme différent pour l’attribution des niveaux de titres : &useNewIndentParser=yes
  • Le serveur peut servir au développement, mais en production il est recommandé de l’exécuter derrière une passerelle de sécurité comme nginx ou une gateway cloud
  • Un exemple de code pour tester le serveur avec le parseur llmsherpa est disponible dans le notebook test_llmsherpa_api

Pourquoi avoir choisi un parseur basé sur des règles

  • L’équipe de nlmatics a évalué plusieurs options pendant 4 ans, dont un parseur visuel basé sur YOLO développé par Tom Liu et Yi Zhang, avant de choisir un parseur basé sur des règles
  • Un parseur basé sur des règles est nettement plus rapide que n’importe quel parseur visuel ; la description du dépôt parle de 100 fois plus rapide
    • Un parseur visuel doit générer des images de toutes les pages, même pour des PDF disposant d’une couche texte
    • Un parseur visuel peut être un meilleur choix pour de petits PDF OCR sans couche texte ou constitués de données de formulaire
    • Pour de grands PDF avec couche texte s’étendant sur plusieurs centaines de pages, le parseur basé sur des règles est jugé plus pratique
  • Si l’on n’utilise pas la fonctionnalité OCR PDF, aucun matériel spécialisé n’est nécessaire
    • La description du dépôt indique qu’il peut fonctionner sur du matériel du début des années 2000
  • Tous les parseurs, y compris les parseurs visuels, peuvent produire des erreurs, et la méthode de correction des erreurs des parseurs basés sur des modèles n’a pas été jugée satisfaisante
    • Ajouter davantage d’exemples à l’ensemble d’entraînement peut dégrader la précision de l’apprentissage précédent et rendre incertain du code qui fonctionnait auparavant
    • Corriger les problèmes des parseurs basés sur des modèles avec des idées fondées sur des règles conduit à réécrire de nombreuses règles

La version modifiée de Tika par nlmatics

  • La version modifiée de Tika par nlmatics se trouve sur la branche 2.4.1-nlm
  • Pour plus de commodité, un fichier jar compilé est inclus dans le dossier jars/ du dépôt
  • Certains PDF peuvent provoquer des erreurs côté serveur Java ; dans ce cas, il faut corriger le code concerné puis recompiler le fichier jar
  • Les fichiers modifiés ajoutent la police et les coordonnées à chaque élément de texte PDF et suppriment les filigranes
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • La modification de GraphicsStreamProcessor.java sert à ajouter des lignes et des rectangles pouvant aider à la détection des tableaux
  • L’impact de ces modifications peut être observé au début du notebook pdf_visual_ingestor_step_by_step
  • Les pistes de travail futures sont les suivantes
    • écrire son propre wrapper au-dessus de pdfbox pour supprimer la dépendance aux modifications de Tika
    • mettre à niveau vers une version plus récente de Tika
    • rendre le format HTML renvoyé plus compatible avec CSS

À lire aussi

1 commentaires

 
GN⁺ 2024-01-26
Avis sur Hacker News

  • Si vous traitez des articles scientifiques, GROBID mérite aussi d’être ajouté : https://github.com/kermitt2/grobid
    Je l’utilise avec paperetl (https://github.com/neuml/paperetl)

  • Bon projet. Pour le parsing de documents, j’utilise depuis longtemps Tika, qui est mature et prend en charge un large éventail de formats, et sa sortie XHTML aide au découpage des documents en chunks pour le RAG
    Il y a des exemples ici : https://neuml.hashnode.dev/build-rag-pipelines-with-txtai et https://neuml.hashnode.dev/extract-text-from-documents
    À noter que je suis l’auteur principal de txtai (https://github.com/neuml/txtai)

    • Un peu hors sujet, mais je me demande comment Tika se compare aux autres bibliothèques de parsing PDF
      pdfminer.six (utilisé par unstructured) m’a déçu : sa détection de mise en page est assez basique et échoue sur le texte en plusieurs colonnes, alors que MuPDF l’a parfaitement géré
      Aujourd’hui, j’utilise un mélange de MuPDF + AWS Textract (surtout pour les tableaux), mais j’aimerais savoir ce que les autres utilisent

  • Ça a l’air assez utile. Dans l’entreprise où je travaille, nous avons un outil de comparaison de PDF, « PDFC », qui lit les PDF et compare les différences sémantiques : https://www.inetsoftware.de/products/pdf-content-comparer
    Le format PDF est tellement complexe que son parsing peut être un vrai casse-tête. Nous prenons déjà en charge la plupart de ces fonctionnalités, mais il y a toujours beaucoup de cas limites, donc des approches supplémentaires peuvent aider

  • Le fallback Tesseract OCR a l’air intéressant
    Il existe maintenant beaucoup de chargeurs de fichiers pour le RAG, comme langchain, LLMindex, unstructured, etc. Je me demande s’il y a une raison de préférer celui-ci, par exemple des benchmarks où il obtient de meilleurs scores

    • Cet outil ne se build pas sur Apple Silicon et il n’y a pas d’image Docker ARM, donc je n’ai pas pu l’essayer moi-même
      Cela dit, j’ai utilisé ces outils RAG pour parser des PDF et la qualité de sortie était assez faible. Comme le LLM contourne le problème dans une certaine mesure, cela fonctionne à peu près pour du RAG, mais si l’on veut des réponses de meilleure qualité avec de vraies références, je pense que le mieux est d’utiliser soi-même un parseur à base de règles. C’est ce que j’ai fini par faire, mais avec une base MuPDF plutôt que Tika
      Les auteurs de cet outil ont peut-être eu un raisonnement similaire
    • La dernière fois que j’ai utilisé Langchain, certes il y a environ 6 mois, son implémentation de l’extraction de contenu depuis les fichiers PDF et HTML était très basique
      C’était suffisant pour faire tourner un prototype RAG, mais pas pour construire quelque chose de fiable. Ce projet ressemble beaucoup plus à une implémentation éprouvée en conditions réelles

  • Excellent travail, et très intéressant. Mais quand on va sur GitHub, on voit « This organization has no public members », on ne sait absolument pas qui vous êtes, ni ce que cela pourrait contenir d’autre qui ne serait pas public
    Globalement, je pense qu’il faut trouver, avec le temps, un juste milieu pour construire identification et confiance entre « un groupe caché anonyme qui publie quelque chose sur le site de sécurité de $CORP » et les méthodes traditionnelles de présentation et d’établissement de la confiance

  • Pour obtenir des chunks optimaux dans des projets LLM/RAG, il suffit d’utiliser ce serveur avec llmsherpa LayoutPDFReader : https://github.com/nlmatics/llmsherpa
    Consultez les exemples et notebooks du dépôt

  • Je me demande s’il existe quelque part des paires exemple entrée/sortie

  • J’ai parsé quelques centaines de PDF avec ça et les résultats étaient plutôt bons. Si ça avait été développé en Julia, ça aurait été au moins 10 fois plus rapide, je pense

  • Je me demande en quoi cela diffère d’Azure Document Intelligence, ou si c’est en fait la même chose

    • Ce n’est pas la même chose. La plupart des parseurs cloud utilisent des modèles de vision, ils sont donc beaucoup plus lents et coûteux, et il faut écrire du code par-dessus pour extraire de bons chunks
      En utilisant ce serveur avec la bibliothèque llmsherpa (https://github.com/nlmatics/llmsherpa), on obtient des chunks adaptés à la mise en page pour les projets LLM/RAG
    • Il n’y a pas d’OCR ni d’IA ici, sauf les fallbacks standard
      Cette bibliothèque et des outils comme fitz/pymupdf extraient directement le texte du PDF et permettent d’appliquer des règles de parsing et de structuration. La plupart des PDF récents permettent d’extraire le texte sans OCR
      C’est évidemment beaucoup moins cher, mais cela ne passe pas très bien à l’échelle sur l’ensemble des mises en page dynamiques ; on l’utilise donc en général quand on peut le configurer pour des structures standard. Cela dit, pour des articles scientifiques par exemple, j’ai constaté que l’extraction de texte à base de règles fonctionne de manière assez dynamique
    • La dernière fois que je l’ai utilisé, Azure Document Intelligence n’était pas très malin pour choisir les points de découpe. Celui-ci semble implémenter de meilleures heuristiques
    • Je me pose la même question. ADI est fiable, mais a des problèmes de cas limites avec les PDF mal produits
      Cela dit, je crains que Tesseract OCR soit une limite potentielle. Je l’ai vu faire beaucoup trop d’erreurs

  • Je me demande s’il y a des exemples. Il ne semble y avoir aucun fichier PDF dans le dépôt

    • On peut voir des exemples dans le projet llmsherpa : https://github.com/nlmatics/llmsherpa
      Ce projet nlm-ingestor fournit le backend qui fonctionne avec llmsherpa. La bibliothèque llmsherpa est très pratique pour extraire de bons chunks destinés aux projets LLM/RAG