- Das Extrahieren von Text aus PDF-Dateien ist deutlich schwieriger als erwartet, und PDF ist im Kern ein grafikbasiertes Dateiformat
- Innerhalb eines PDF gibt es nur Positionsinformationen von Glyphen, aber kaum semantische Signale, wodurch die Identifizierung und Rekonstruktion von Text schwierig wird
- Suchmaschinen verlangen sauberen Input in HTML-Form, aber bestehende Open-Source-Tools haben Grenzen bei der Extraktion struktureller Informationen wie Überschriften oder Absätze
- Machine-Learning-basierte Vision-Ansätze sind am genauesten, haben aber wegen Ressourcen- und Performance-Problemen Schwierigkeiten bei großflächigem Einsatz
- Als wichtigste Verbesserungen wurde ein Algorithmus zur Erkennung von Überschriften und Absätzen auf Basis von Schriftgröße und Statistik eingeführt, um die Extraktionsgenauigkeit zu erhöhen
Die Herausforderung der Textextraktion aus PDFs
- Moderne Suchmaschinen verfügen inzwischen über die Fähigkeit, das PDF-Dateiformat zu indizieren
- Die Extraktion von Informationen aus PDFs ist kein leichtes Problem, was darauf zurückzuführen ist, dass PDF ursprünglich kein Textformat, sondern ein Grafikformat ist
- Statt echtem Text liegen Glyphen an Koordinaten positioniert vor, wodurch Rotation, Überlagerung, durcheinandergeratene Reihenfolge und fehlende Bedeutungsinformationen auftreten
- Die Information als Text, wie wir sie gewöhnlich verstehen, existiert in der Datei nicht direkt
- Dass man in einem PDF-Viewer mit
ctrl+f nach Text suchen kann, ist eigentlich erstaunlich
Anforderungen von Suchmaschinen und Grenzen grundlegender Ansätze
- Der von Suchmaschinen am meisten bevorzugte Input ist sauberes HTML
- Moderne Machine-Learning-basierte Computer-Vision-Modelle zeigen die beste Leistung,
- aber große PDF-Dateien (mehrere hundert GB) auf einem einzelnen Server ohne GPU zu verarbeiten, ist ineffizient
- Glücklicherweise ist dieses Feld kein völlig unbekanntes Gebiet, daher
- kann die Klasse PDFBox
PDFTextStripper als Ausgangspunkt genutzt werden
- allerdings wird semantische Struktur wie Überschriften kaum erkannt — es werden nur Zeichenketten extrahiert
Algorithmus zur Überschriftenerkennung
Grundprinzip der Überschriftenerkennung
- Üblicherweise lässt sich nutzen, dass Überschriften halbfett oder noch kräftiger gesetzt und isoliert sind
- Nicht fett gesetzte Überschriften sind jedoch ebenfalls häufig, daher hat diese Methode allein Grenzen
- In vielen Fällen dient die Schriftgröße als Kriterium zur Unterscheidung von Überschriften
- Allerdings unterscheidet sich die Schriftgröße von Dokument zu Dokument stark, weshalb ein globaler Schwellenwert unmöglich ist
Nutzung von Schriftgrößenstatistiken
- Auf jeder Seite gibt es in der Regel eine dominante Schriftgröße (Fließtext)
- Seite 1 (Titelblatt) hat beschreibenden Inhalt und Autoreninformationen, daher ist die Verteilung der Schriftgrößen anders
- Da sich die Verteilung der Schriftgrößen je Seite unterscheidet, ist es effektiv, Statistiken auf Seitenebene statt für das gesamte Dokument zu verwenden
- Wird auf die mittlere Schriftgröße einer Seite (Median) ein Aufschlag von etwa 20 % angewendet, lassen sich Überschriften recht genau identifizieren
Das Problem beim Zusammenführen mehrzeiliger Überschriften
- Aus stilistischen Gründen werden Überschriften manchmal auf mehrere Zeilen verteilt
- Zu entscheiden, wann Überschriften zusammengeführt werden sollen, ist nicht einfach; Überschriften mit zwei oder mehr Zeilen, Autorennamen oder separat hervorgehobene Texte können vermischt auftreten
- Regeln für das Zusammenführen:
- Das Zusammenfassen aufeinanderfolgender Zeilen mit derselben Schriftgröße und Strichstärke funktioniert recht gut
- Es gibt jedoch viele Ausnahmen — unbedachtes Zusammenführen kann zu völlig falschen Ergebnissen führen
Verbesserte Absatzidentifikation
PDFTextStripper erkennt Absätze auf Basis von Zeilenabstand und Einrückung
- Da ein fester Wert als Schwellenwert für die Trennung zwischen Zeilen verwendet wird, gibt es Grenzen bei Dokumenten mit jeweils anderem Zeilenabstand
- Besonders bei Paper-Entwürfen oder Preprints sind Zeilenabstände von 1,5 bis 2-fach ebenfalls häufig
- Ist der Schwellenwert zu groß, kommt es zu Fehlern, bei denen Überschriften in den Fließtext einbezogen werden
Statistikbasierte Absatztrennung
- Wie bei der Schriftgröße wird auch auf den Zeilenabstand statistische Verarbeitung angewendet
- Mit dem mittleren Abstand zwischen Zeilen (Median) ist eine robuste Absatztrennung unabhängig vom Zeilenabstand möglich
Fazit
- Die Extraktion von Text aus PDFs kann grundsätzlich gar nicht perfekt sein
- weil das PDF-Format selbst nicht für diesen Zweck entworfen wurde
- In der praktischen Umsetzung sind Kompromisse unvermeidlich, und eine Strategie für Ergebnisse, die „gut genug“ sind, ist wichtig
- Für Suchmaschinen ist es effizient, sich auf die Extraktion sinnvoller Signale wie Überschriften, Zusammenfassungen und zentraler struktureller Hinweise zu konzentrieren
Referenz-Beispieltexte
- Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
: Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
- The theory of ideas and Plato’s philosophy of mathematics (2019)
: Dembiński, B.
- The role of phronesis in Knowledge-Based Economy (2024)
: Anna Ceglarska, Cymbranowicz Katarzyna
1 Kommentare
Hacker-News-Kommentare
Ich habe manchmal die Erfahrung, etwas für neu und interessant zu halten, und dann dämmert mir vage, dass ich darin früher schon über Monate oder Jahre zum Experten geworden war. Sogar Momente, in denen ich wirklich coole Dinge gemacht habe, scheinen aus meinem Kopf verschwunden zu sein, sodass es sich anfühlt, als würde ich wieder ganz von vorn anfangen. Ich habe eine undeutliche Erinnerung daran, vor etwa 6–7 Jahren etwas Großartiges mit PDF und OCR gemacht zu haben. Als ich danach googelte, kam mir der Name „tesseract“ vertraut vor
Um 2006 herum war ich frustriert darüber, dass man auf dem iRex, einem frühen hackbaren E-Reader, keinen Text aus mehrspaltigen wissenschaftlichen Artikeln kopieren konnte. Damals verwendete der PDF-Viewer poppler, also habe ich poppler so angepasst, dass es die Lesereihenfolge in mehrspaltigen Dokumenten erschließt. Dafür habe ich mich an OCR-Algorithmen von Thomas Breuel, dem Autor von tesseract, orientiert. Das war eine Art heuristischer Hack und passte nicht gut zu Accessibility-APIs. Es wurde zwar eine Mehrspalten-Auswahl eingeführt, aber es war schwierig, die Maintainer zu überzeugen. Jedenfalls bekam kpdf auf diese Weise eine Mehrspalten-Auswahl. Heute scheint es mir für solche Zwecke viel vernünftiger zu sein, tesseract direkt zu verwenden
Wegen des Formats PDF lassen sich die von der Menschheit verschwendeten Jahrzehnte nicht zurückholen. Ich frage mich, wann dieser Wahnsinn endlich endet
Tesseract war lange Zeit das beste Open-Source-OCR. Aber inzwischen halte ich docTR bei Genauigkeit und GPU-Beschleunigung für überlegen. docTR hat eine Pipeline-Struktur, in der sich verschiedene Modelle zur Texterkennung und Textdetektion kombinieren lassen. Training und Tuning in PyTorch oder TensorFlow sind ebenfalls möglich, sodass man für bestimmte Domänen deutlich besser angepasste Leistung herausholen kann
So ist das Leben. Nach jedem abgeschlossenen Projekt denke ich: „Jetzt bin ich Experte in diesem Bereich. Aber wahrscheinlich werde ich das nie wieder machen.“ Denn beim nächsten Mal fängt man wieder bei einem völlig neuen Thema von vorn an
Vor nicht allzu langer Zeit fragte mich jemand etwas zu C++, und ich sagte: „Ich habe nie ernsthaft damit gearbeitet.“ Später fiel mir dann ein, dass ich vor etwa 20 Jahren den Client-Code für einen privaten Instant Messenger in Borland C++ geschrieben hatte, den Tausende Menschen genutzt haben. So etwas passiert öfter
Ich kann natürlich nicht in deinen Kopf schauen, aber wahrscheinlich war es wirklich tesseract. Ich hatte eine ähnliche Erfahrung, bei mir war das etwa vor 12 Jahren
Als HQ populär war, habe ich mit tesseract einen automatischen HQ-Quiz-Löser gebaut. Er machte einen Screenshot des Fragenbildschirms in der App, schickte ihn an eine kleine API, suchte den Fragentext bei Google und zählte dann, wie oft jede Antwort vorkam, um sie nach Wahrscheinlichkeit zu sortieren. Es war ungenau und simpel, aber es hat großen Spaß gemacht, es zu bauen
Das ist nicht viel anders als bei Feuerameisen, die sich einfach ein anderes Blatt suchen, wenn der Wind ein Blatt davonträgt
Das war vor 7–8 Jahren, als ich in meinen Zwanzigern war, deshalb erinnere ich mich noch sehr gut daran. Vielleicht gibt es da einfach einen gewissen Altersunterschied. Oder ich würde auch eine Gesundheitsuntersuchung empfehlen
Ich wünschte, es gäbe ein Tool, mit dem man PDF-Content-Streams auf Quellcode-Ebene „sehen“ kann — also BT…ET um den Text herum, die verschiedenen Operatoren zur Angabe von Fonts und Koordinaten und so weiter — ähnlich wie Entwicklerwerkzeuge im Browser („Element untersuchen“), sodass man sie neben dem gerenderten Ergebnis vergleichen und analysieren kann. Das ist etwas anderes als der aktuelle Ansatz, bei dem Vision-Modelle PDFs „anschauen“ und dabei Text lesen; ich möchte wirklich tief verstehen, welche Informationen tatsächlich im Inneren des PDFs enthalten sind. Es gibt zwar einige Tools, aber sie zeigen nur bis zur Objektebene und dringen nicht in die Content-Streams selbst vor. Ich wünsche mir eine Umgebung, in der man den tatsächlichen Stream-Quelltext eines Beispiel-PDFs und das gerenderte Ergebnis wie bei HTML nebeneinander vergleichen und analysieren kann, um zu sehen, wie einzelne Teile dargestellt werden
Wenn man Mozilla PDF.js verwendet und das PDF ins DOM rendert, müsste man fast dieselbe Erfahrung bekommen. Operatoren wie Tj oder TJ werden zum Beispiel jeweils in <span> oder Gruppen davon umgewandelt. Vermutlich liegt das daran, dass man dem Quelldokument treu bleiben muss
Ich empfehle, das Tool cpdf auszuprobieren (habe ich selbst gemacht). Mit den Optionen -output-json und -output-json-parse-content-streams von cpdf kann man PDFs in JSON umwandeln und allerlei Experimente durchführen. Umgekehrt kann man aus JSON auch wieder PDFs erzeugen. Echtzeit-Interaktivität bietet es allerdings nicht
Du suchst vermutlich nach einem kostenlosen oder Open-Source-Tool, aber als ich früher Acrobat Pro verwendet habe, bot es fast genau diese Funktion. Allerdings inspizierte es keine Seite direkt, sondern traversierte den Content-Tree und zeigte nur bis zu Objekten/Streams, nicht bis hinunter zu einzelnen Befehlen
„Wir bauen bei Tensorlake genau die Kombination aus ‚ein PDF wie ein Mensch sehen‘ und ‚wissen, welche Daten tatsächlich im PDF stecken‘ (ich arbeite dort). Es geht nicht nur darum, Text zu lesen, sondern Tabellen, Bilder, Formeln, Handschrift usw. wirklich zu verstehen, um Daten als Markdown/JSON zu extrahieren, sodass sie in Apps mit AI, LLM usw. verwendet werden können“ https://tensorlake.ai
Nicht ganz auf dem Niveau, das du suchst, aber ich empfehle als Referenz dieses Notebook, das einen Inspektor bietet, der die verschiedenen Zeichenoperationen innerhalb eines PDFs „live“ anzeigt https://observablehq.com/@player1537/pdf-utilities
Ich habe mich bei Apple über Jahre auf dieses Problem konzentriert. Der Schlüssel ist, zu akzeptieren, dass „alles Geometrie“ ist, und einen Algorithmus zu haben, der Wortabstände und Zeichenabstände clustert und unterscheidet. Für die meisten PDFs funktioniert das gut, aber aus der Nähe betrachtet ist die Vielfalt so groß, dass manches enttäuschend bleibt. Wenn ich es heute noch einmal machen würde, würde ich OCR vollständig weglassen und rein geometriebasiert vorgehen, aber mit Machine Learning. Wenn man PDFs aus vorher bekanntem Text erzeugt und für maschinelles Lernen nutzt, lässt sich auch der Aufbau von Trainingsdaten automatisieren. (Es gibt ein Video von Bertrand Serlets WWDC-2009-Vortrag)
Ich denke nicht, dass es nur ein einziges Problem „PDF zu Text“ gibt, sondern in Wirklichkeit drei Kategorien: (1) zuverlässiges OCR (für Suche, Vektor-DB-Ingestion usw.), (2) strukturierte Datenextraktion (nur bestimmte Werte herausziehen), (3) Automatisierung ganzer Dokument-Pipelines (z. B. Hypotheken-Automatisierung). Marginalia zielt auf (1), und dank Dingen wie Gemini Flash wird OCR gerade billig und allgemein verfügbar. Aber (2) und (3) sind schwieriger, und für vollständige Automatisierung braucht man weiterhin viel menschliche Arbeit: Datensätze aufbauen, Pipelines entwerfen, Unsicherheit erkennen und manuell eingreifen, Fine-Tuning usw. Die Zukunft liegt in dieser Richtung. (Ich betreibe ein Unternehmen für LLM-Dokumentverarbeitung) https://extend.ai
Ich denke, man braucht auch eine Kategorie (4): zuverlässiges OCR und semantische Extraktion aus Dokumenten in verschiedensten Formaten, also Lösungen für Accessibility. Das ist deshalb so schwierig, weil man im Unterschied zu normalen Workflows die Dokumenttypen der Nutzer nicht vorhersagen kann, man auch nichttextuelle Elemente wie Tabellen, Header/Footer/Anmerkungen/Formeln extrahieren muss, Fehler möglichst minimiert werden müssen und man deshalb OCR nicht mehr als nötig einsetzen darf, eingebetteter Text und gerenderter Inhalt voneinander abweichen können (versteckter Text oder unübliche Kombinationen usw.), häufig lokale Apps verwendet werden und Server daher schwer einsetzbar sind, und außerdem Form-Unterstützung für Dokumente mit Imprinter-Zweck nötig ist. Derzeit gibt es keine Lösung, die all diese Punkte vollständig abdeckt
Es heißt zwar, man habe mit VLMs OCR-Pipelines vereinfacht, aber als Warnung: Bei realen komplexen Dokumenten ist das extrem schwierig. Für einfache Bildlabels sind sie hervorragend, und für sehr einfache Dokumente auch brauchbar, aber bei Dokumenten mit Tabellen, Headern und strukturierten Zusammenfassungen halluzinieren sie stark. In der Praxis ist das daher fast unbrauchbar
Ich stoße beim Umwandeln nach Markdown auf allerlei Probleme, etwa bei der Header-Erkennung. Heutiges OCR ist großartig, aber die Gesamtstruktur eines Dokuments zu erhalten, ist viel schwieriger. Ich bekomme einigermaßen brauchbare Ergebnisse, indem ich das Dokument mehrfach durch ein LLM laufen lasse, die Struktur extrahiere und seitenweise Kontext mitgebe
Eine bessere Lösung wäre, bearbeitbare Quelldokumente innerhalb des PDFs anzuhängen. Mit LibreOffice geht das ganz einfach. Im Allgemeinen kostet das nicht viel zusätzlichen Speicherplatz, und die Bedeutung des Textes ist eindeutig. Mit bestehenden PDF-Readern lässt sich das trotzdem problemlos verwenden
Wenn die Textextraktion aus bestehenden PDFs das Problem ist, frage ich mich, wie hilfreich Ratschläge zur Erstellung von PDFs wirklich sind. Ich frage mich, ab wann solche Lösungen tatsächlich Wirkung entfalten
Das stimmt, aber dadurch entsteht das Risiko, dass Quelldokument und gerendertes PDF inhaltlich völlig voneinander abweichen können
Das ist richtig, aber es funktioniert nur, wenn die Interessen derjenigen, die PDFs erzeugen, und derjenigen, die PDFs konsumieren, übereinstimmen. Im Bereich e-Discovery ist es üblich, dass die Gegenseite Dokumente absichtlich als PDFs einreicht, um sie schwerer nutzbar zu machen. Dadurch brauchen schlecht ausgestattete Pflichtverteidiger deutlich länger für die Verarbeitung und sind real benachteiligt. Um das zu verhindern, sollten verschiedene Datenarten gesetzlich zur Einreichung in standardisierten maschinenlesbaren Formaten verpflichtet werden
Wenn man Zugriff auf das Quelldokument hat, ist es sehr gut, es im PDF anzuhängen. In den meisten Fällen hat man diese Kontrolle aber nicht
Die meisten echten Probleme sind Legacy-PDFs. In unserem Unternehmen liegen Tausende davon herum, und einige sind katastrophale Scans. Manche haben eingebautes Adobe OCR, die meisten aber gar nicht
Das unten stehende PDF ist in Wirklichkeit eine .txt-Datei. Man kann die Erweiterung in .pdf ändern und es in einem PDF-Viewer öffnen oder es direkt in einem Texteditor bearbeiten, um viele Dinge zu steuern: den sichtbaren Inhalt, Fonts, Schriftgröße, Zeilenabstand, Zeichen pro Seite, Zeilen pro Seite, Papierformat usw. (einschließlich eines direkten PDF-Textbeispiels)
PDFs können auch Binär-Streams einbetten. PDF ist kein Textformat, sondern ein Format für Layout und Grafik. Wie im Beispiel kann eine ganze Zeile auf einmal erscheinen, aber in Wirklichkeit kann der Inhalt zeichenweise, wortweise oder sogar völlig ungeordnet dargestellt werden
PDF steht für „Portable Document Format“. Es ist als 7-Bit-ASCII-Datei codiert und zeichnet sich dadurch durch hohe Portabilität über verschiedene Geräte- und OS-Umgebungen hinweg aus. (Referenz: offizielles Adobe-Dokument)
Dieses Beispiel ist das „Hello World“ von PDFs. Moderne PDFs komprimieren die meisten Objekte per deflate und gruppieren diese Objekte in Streams, was alles komplizierter macht. Deshalb ist es sehr schwer, das Format einfach durch Suchen nach „6 0 Obj“ im Klartext zu analysieren
Text aus PDFs herauszuholen, besonders strukturierten Text, ist absolut nicht einfach. HTML-Tabellen lassen sich meist noch halbwegs leicht extrahieren, aber PDFs sehen nur auf Basis gerenderter Koordinaten wie Tabellen aus; tatsächlich liegen Text und Grafik verstreut vor. Ich selbst wandle PDFs mit den Poppler PDF utils in HTML um, suche dann Tabellen-Header und ermittle auf Grundlage der x-Koordinaten der Werte die Spalten, um zeilenweise Daten zu extrahieren. Das wirkt grob, liefert aber zuverlässigere Ergebnisse als es mit ausgerichtetem Text in txt der Fall wäre
Ich war frustriert darüber, dass man aus PDFs nicht wie aus Webseiten mit BeautifulSoup Daten extrahieren kann, also habe ich selbst eine Bibliothek mit so einer Schnittstelle gebaut. (Beispiel im Stil von
page.find) Die Fallunterscheidungen zwischen PDFs sind die Hölle, deshalb sammle ich Extraktions-Know-how und absurde PDF-Beispiele und baue daraus eine Bibliothek https://jsoma.github.io/natural-pdf/ , https://badpdfs.com/Irgendwann möchte ich Tabellendaten aus PDFs in meine Datenverarbeitungssoftware ziehen. Falls jemand eine kostenlose oder sehr günstige Bibliothek kennt, die sich in eine C++-App integrieren lässt, bitte Bescheid sagen
Es gibt Dokumente (zum Beispiel von staatlichen Stellen), bei denen der sichtbare Text und der tatsächlich extrahierte Text völlig unterschiedlich sind. Solche Fälle kommen öfter vor
PDF ist im Kern ein Markup-/XML-Format. Dasselbe PDF kann auf sehr viele unterschiedliche Arten erzeugt werden. Exportiert man es aus einem Grafiktool, bekommt man PDFs mit gemischten Grafiken und Text; exportiert man es aus einer Textverarbeitung, eher textzentrierte PDFs. Das Ergebnis ist mehrdimensional. Wie die erzeugende Anwendung Informationen behandelt, hat großen Einfluss darauf, wie das PDF ausgegeben wird. Mit Off-the-Shelf-Utilities wie cisdem und anderen Produktfamilien kann man teilweise strukturierte Daten extrahieren. Aber letztlich braucht man je nach Aufgabe das passende Werkzeug
Eines meiner Lieblingsbeispiele ist dieses Paper-PDF (Link beigefügt). Auf der ersten Seite gibt es typischen zweispaltigen Text mit einem mittigen Header, Text, der zwischen beide Spalten hineinragt, Elemente mit wechselnder Zeilenlänge und Einrückung. Auch die Seiten-Header unterscheiden sich zwischen geraden und ungeraden Seiten, und die Regeln für Abschnitts-Header sind uneinheitlich. Absätze sind auch nicht immer eingerückt, und der Zeilenabstand variiert. Es ist eine Gesamtsammlung unterschiedlichster Probleme
Als ich selbst einmal einen einfachen PDF-Parser geschrieben habe, war ich überrascht, wie das Format funktioniert. Deshalb habe ich mich eher immer gefragt, warum dieses Format so häufig für textzentrierte Zwecke verwendet wird. Bei Rechnungen zum Beispiel sollte ein digitales System Daten leicht extrahieren können, während für Menschen eine formatierte Darstellung geeignet ist. Ich wünschte, die Tech-Branche würde schrittweise zu besseren Formaten migrieren
Das Extrahieren „nützlicher Informationen“ aus PDFs ist genau die Arbeit von Tensorlake (https://tensorlake.ai). PDFs enthalten nicht nur Text, sondern auch Tabellen, Bilder, Formeln, Handschrift, Durchstreichungen und vieles mehr, daher müssen wir als Entwickler Text nicht nur „lesen“, sondern „verstehen“ können. (Ich bin Mitarbeiter)