Show HN: Open-Source regelbasierter PDF-Parser für RAG

 (github.com/nlmatics)
1 Punkte von GN⁺ 2024-01-26 | 1 Kommentare | Auf WhatsApp teilen
  • nlm-ingestor ist der Service-Code, den die llmsherpa-API angebunden nutzt, und bietet auf RAG zugeschnittene Dokument-Parser für PDF, HTML, Text, DOCX, PPTX und weitere Formate
  • Der PDF-Parser verwendet Textkoordinaten, Grafiken und Font-Daten aus der von nlmatics angepassten Version von Tika; wenn gescannte Seiten vorhanden sind, kann per Option apply_ocr automatisch OCR angewendet werden
  • Zu den PDF-Funktionen gehören Abschnitts- und Unterabschnittsebenen, Absatz-Zusammenführung, Verknüpfung von Abschnitten und Absätzen, Tabellen, verschachtelte Listen, Zusammenführung seitenübergreifender Inhalte, Entfernung wiederholter Header und Footer, Wasserzeichenentfernung sowie OCR-Bounding-Boxen
  • Im Vergleich zu modellbasierten Vision-Parsern sei der regelbasierte Parser 100-mal schneller, da keine PDF-Seitenbilder erzeugt werden müssen; für PDFs mit Text-Layer ohne OCR und für Dokumente mit Hunderten von Seiten sei er praktischer
  • Der Entwicklungsserver kann per Docker oder direkt gestartet werden; für Produktionsumgebungen wird empfohlen, ihn hinter einem Security-Gateway wie nginx oder einem Cloud-Gateway zu betreiben

Dokument-Parser von nlm-ingestor

  • nlm-ingestor ist das Service-Code-Repository, an das die API von llmsherpa angebunden werden kann
  • Es bietet mehrere auf RAG (retrieval augmented generation) zugeschnittene Custom-Parser für verschiedene Dateiformate

    • PDF

    • HTML

    • Text

      • DOCX, PPTX sowie andere von Apache Tika unterstützte Formate

Funktionsweise und Features des PDF-Parsers

  • Der PDF-Parser ist regelbasiert und verwendet Textkoordinaten, Grafiken und Font-Daten aus nlm-tika, einer von nlmatics angepassten Version
  • Er arbeitet auf Basis des PDF-Text-Layers; über die Option apply_ocr kann OCR automatisch angewendet werden, wenn das PDF gescannte Seiten enthält
  • Die OCR-Funktion basiert intern auf der von nlmatics angepassten Tika-Version, die tesseract verwendet
  • Zum direkten Ausprobieren des PDF-Parsers steht das Notebook pdf_visual_ingestor_step_by_step bereit
  • Der PDF-Parser bietet folgende Funktionen
    • Erkennung von Abschnitten, Unterabschnitten und ihren Ebenen
    • Zusammenführen mehrerer Zeilen zu Absätzen
    • Erzeugen von Verknüpfungen zwischen Abschnitten und Absätzen
    • Erkennung von Tabellen und der Abschnitte, in denen sie gefunden wurden
    • Verarbeitung von Listen und verschachtelten Listen
    • Zusammenführen seitenübergreifender Inhalte
    • Entfernen wiederholter Header und Footer
    • Entfernen von Wasserzeichen
    • Bereitstellung von Bounding-Boxen für OCR-Ergebnisse

Verarbeitung von HTML-, Text- und Office-Dokumenten

  • Der HTML-Parser erzeugt layoutbewusste Blöcke, um für bessere RAG-Leistung qualitativ hochwertigere Chunks zu erstellen
  • Der Text-Parser schätzt Listen, Tabellen, Header usw. allein anhand des Texts, ohne visuelle Informationen, Font-Informationen oder Bounding-Boxen
  • DOCX, PPTX und andere von Apache Tika unterstützte Formate werden zunächst über die HTML-Ausgabe von Tika verarbeitet und anschließend durch den HTML-Parser geleitet

Ausführung und API-Nutzung

  • Das Verfahren für die direkte Ausführung besteht aus der Installation von Java, dem Starten des Tika-Servers, der Installation von nlm-ingestor und dem Start des Ingestors
    • Tika-Server starten: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • Installation: pip install nlm-ingestor
    • Starten: python -m nlm_ingestor.ingestion_daemon
  • Im öffentlichen GitHub Container Registry ist ein Docker-Image verfügbar
    • Image abrufen: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • Ausführungsbeispiel: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • Nach dem Serverstart können Chunks über die llmsherpa-API-Bibliothek abgerufen und in LLM-Projekten verwendet werden
  • Ein Beispiel für llmsherpa_url ist http://localhost:5010/api/parseDocument?renderFormat=all
    • OCR anwenden: &applyOcr=yes
    • Neuen Indent-Parser verwenden, der einen anderen Algorithmus für die Zuweisung von Header-Ebenen nutzt: &useNewIndentParser=yes
  • Der Server eignet sich für Entwicklungszwecke, für Produktionsumgebungen wird jedoch empfohlen, ihn hinter einem Security-Gateway wie nginx oder einem Cloud-Gateway zu betreiben
  • Beispielcode zum Testen des Servers mit dem llmsherpa-Parser befindet sich im Notebook test_llmsherpa_api

Warum ein regelbasierter Parser gewählt wurde

  • Das nlmatics-Team bewertete über vier Jahre hinweg mehrere Optionen, darunter einen YOLO-basierten Vision-Parser, der von Tom Liu und Yi Zhang entwickelt wurde, und entschied sich anschließend für einen regelbasierten Parser
  • Ein regelbasierter Parser ist deutlich schneller als jeder Vision-Parser; in der Repository-Beschreibung wird dies als 100-mal schneller bezeichnet
    • Vision-Parser müssen selbst bei PDFs mit Text-Layer Bilder aller Seiten erzeugen
    • Für OCR-PDFs ohne Text-Layer oder kleine PDFs, die aus Formulardaten bestehen, können Vision-Parser die bessere Wahl sein
    • Für große PDFs mit Text-Layer über Hunderte von Seiten hinweg gilt ein regelbasierter Parser als praktischer
  • Wenn die PDF-OCR-Funktion nicht verwendet wird, ist keine spezielle Hardware erforderlich
    • Laut Repository-Beschreibung soll er sogar auf Hardware aus den frühen 2000er-Jahren laufen können
  • Bei allen Parsern, auch bei Vision-Parsern, können Fehler auftreten; die Methode zur Fehlerbehebung bei modellbasierten Parsern habe sich als nicht zufriedenstellend erwiesen
    • Fügt man dem Trainingssatz weitere Beispiele hinzu, kann die Genauigkeit früherer Trainings sinken und zuvor funktionierender Code unsicher werden
    • Wenn Probleme modellbasierter Parser mit regelbasierten Ideen behoben werden, führt das am Ende wieder zum Schreiben vieler Regeln

Von nlmatics angepasste Tika-Version

  • Die von nlmatics angepasste Tika-Version befindet sich im 2.4.1-nlm-Branch
  • Der kompilierte jar-File ist aus Bequemlichkeit im Ordner jars/ des Repositorys enthalten
  • Bei einigen PDFs können auf dem Java-Server Fehler auftreten; in diesem Fall muss der betreffende Code angepasst und der jar-File neu kompiliert werden
  • Die modifizierten Dateien fügen jedem PDF-Textelement Fonts und Koordinaten hinzu und entfernen Wasserzeichen
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • Die Änderung an GraphicsStreamProcessor.java dient dazu, Linien und Rechtecke hinzuzufügen, was bei der Tabellenerkennung helfen kann
  • Die Auswirkungen der Änderungen lassen sich am Anfang des Notebooks pdf_visual_ingestor_step_by_step nachvollziehen
  • Zu den Ideen für künftige Arbeiten gehören
    • Einen eigenen Wrapper auf Basis von pdfbox schreiben, um die Abhängigkeit von Tika-Änderungen zu entfernen
    • Auf eine neuere Tika-Version upgraden
    • Das zurückgegebene HTML-Format stärker CSS-freundlich aufräumen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-26
Hacker-News-Meinungen

  • Wenn es um wissenschaftliche Paper geht, wäre auch GROBID eine Ergänzung wert: https://github.com/kermitt2/grobid
    Ich nutze es zusammen mit paperetl (https://github.com/neuml/paperetl).

  • Gutes Projekt. Für das Parsen von Dokumenten habe ich wegen der Reife und der breiten Formatunterstützung lange Tika verwendet; die XHTML-Ausgabe hilft beim Chunking von Dokumenten für RAG.
    Beispiele gibt es unter https://neuml.hashnode.dev/build-rag-pipelines-with-txtai und https://neuml.hashnode.dev/extract-text-from-documents.
    Zur Einordnung: Ich bin der Hauptautor von txtai (https://github.com/neuml/txtai).

    • Etwas off-topic, aber ich frage mich, wie Tika im Vergleich zu anderen PDF-Parsing-Bibliotheken abschneidet.
      pdfminer.six (das von unstructured genutzt wird) war enttäuschend, weil die Layout-Erkennung ziemlich grundlegend ist und beim Parsen von mehrspaltigem Text scheitert; MuPDF hat das perfekt erledigt.
      Aktuell verwende ich eine Mischung aus MuPDF + AWS Textract (hauptsächlich für Tabellen), würde aber gern wissen, was andere nutzen.

  • Das dürfte ziemlich hilfreich sein. In der Firma, in der ich arbeite, gibt es ein PDF-Vergleichstool namens „PDFC“, das PDFs liest und semantische Unterschiede vergleicht: https://www.inetsoftware.de/products/pdf-content-comparer
    Das PDF-Format ist so komplex, dass das Parsen ziemlich mühsam werden kann. Wir unterstützen die meisten dieser Funktionen bereits, aber es gibt immer viele Edge Cases, sodass ein zusätzlicher Ansatz hilfreich sein kann.

  • Der Tesseract-OCR-Fallback sieht gut aus.
    Inzwischen gibt es viele File Loader für RAG, etwa langchain, LLMindex, unstructured usw.; ich frage mich, ob es einen Grund gibt, dieses hier zu bevorzugen. Zum Beispiel, ob es Belege wie bessere Benchmark-Werte gibt.

    • Dieses Tool lässt sich auf Apple Silicon nicht bauen und es gibt auch kein ARM-Docker-Image, daher konnte ich es selbst nicht ausprobieren.
      Ich habe diese RAG-Tools allerdings für PDF-Parsing genutzt, und die Ausgabequalität war ziemlich niedrig. Weil ein LLM die Probleme bis zu einem gewissen Grad umgeht, funktioniert es für RAG einigermaßen, aber wenn man hochwertigere Antworten mit ordentlichen Referenzen will, ist ein eigener regelbasierter Parser meiner Meinung nach am besten. Genau das habe ich letztlich auch gemacht, allerdings auf Basis von MuPDF statt Tika.
      Die Autoren dieses Tools könnten ähnlich gedacht haben.
    • Als ich Langchain zuletzt ausprobiert habe — zugegeben vor etwa sechs Monaten —, war die Implementierung zur Content-Extraktion aus PDF- und HTML-Dateien sehr grundlegend.
      Für einen RAG-Prototyp reichte es, aber nicht, um etwas Verlässliches zu bauen. Dieses Projekt wirkt wie eine deutlich stärker praxiserprobte Implementierung.

  • Großartige Arbeit und sehr interessant. Wenn man jedoch auf GitHub geht, steht dort „This organization has no public members“, man weiß überhaupt nicht, wer ihr seid, und man kann auch nicht erkennen, was sonst noch unveröffentlicht darin enthalten sein könnte.
    Insgesamt denke ich, dass es zwischen „eine namenlose, verborgene Gruppe hat etwas auf einer $CORP-Sicherheitsseite veröffentlicht“ und den traditionellen Wegen von Vorstellung und Vertrauensaufbau eine Zwischenstufe braucht, über die sich mit der Zeit Identität und Vertrauen aufbauen lassen.

  • Um optimale Chunks für LLM/RAG-Projekte zu erhalten, kann man diesen Server zusammen mit llmsherpa LayoutPDFReader verwenden: https://github.com/nlmatics/llmsherpa
    Siehe die Beispiele und Notebooks im Repository.

  • Ich frage mich, ob es irgendwo Beispielpaare aus Eingabe und Ausgabe gibt.

  • Ich habe damit ein paar Hundert PDFs geparst, und die Ergebnisse waren ziemlich gut. Wäre es in Julia entwickelt worden, wäre es meiner Meinung nach mindestens 10-mal schneller gewesen.

  • Ich frage mich, worin sich das von Azure Document Intelligence unterscheidet, oder ob es im Grunde dasselbe ist.

    • Es macht nicht dasselbe. Die meisten Cloud-Parser verwenden Vision-Modelle, sind daher viel langsamer und teurer, und um gute Chunks zu extrahieren, muss man darüber hinaus zusätzlichen Code schreiben.
      Wenn man diesen Server zusammen mit der llmsherpa-Bibliothek (https://github.com/nlmatics/llmsherpa) verwendet, erhält man layoutfreundliche Chunks, die für LLM/RAG-Projekte geeignet sind.
    • Hier steckt kein OCR oder AI drin, abgesehen von Standard-Fallbacks.
      Diese Bibliothek und Tools wie fitz/pymupdf extrahieren Text direkt aus PDFs und ermöglichen es, Parsing- und Strukturierungsregeln anzuwenden. Aus den meisten modernen PDFs lässt sich Text ohne OCR extrahieren.
      Das ist natürlich viel günstiger, skaliert aber nicht gut über dynamische Layouts hinweg; daher nutzt man es meist, wenn man es auf Standardstrukturen konfigurieren kann. Trotzdem habe ich gesehen, dass regelbasierte Textextraktion bei Dingen wie wissenschaftlichen Papers ziemlich dynamisch gut funktioniert.
    • Als ich Azure Document Intelligence zuletzt verwendet habe, war es beim Auswählen von Trennstellen nicht besonders clever. Diese Lösung scheint bessere Heuristiken implementiert zu haben.
    • Das interessiert mich auch. ADI ist verlässlich, hat aber bei schlecht erzeugten PDFs Edge-Case-Probleme.
      Allerdings mache ich mir Sorgen, ob Tesseract OCR eine mögliche Einschränkung ist. Ich habe gesehen, dass es zu viele Fehler macht.

  • Ich frage mich, ob es Beispiele gibt. Im Repository scheint es keine einzige PDF-Datei zu geben.

    • Beispiele findet man im llmsherpa-Projekt: https://github.com/nlmatics/llmsherpa
      Dieses nlm-ingestor-Projekt stellt das Backend bereit, das mit llmsherpa zusammenarbeitet. Die llmsherpa-Bibliothek ist sehr praktisch, um gute Chunks für LLM/RAG-Projekte zu extrahieren.