Technik zur schnellen Umwandlung von PDFs in Markdown mit hoher Genauigkeit

 (github.com/VikParuchuri)
2 Punkte von GN⁺ 2023-12-02 | 1 Kommentare | Auf WhatsApp teilen
  • Marker ist ein Dokumentenintelligenz-Tool, das nicht nur PDFs, sondern auch Bilder, PPTX-, DOCX-, XLSX-, HTML- und EPUB-Dokumente schnell und präzise in Markdown, JSON, Chunks und HTML umwandelt
  • Es unterstützt die Formatierung von Tabellen, Formularen, Formeln, Inline-Mathematik, Links, Referenzen und Code-Blöcken sowie die Extraktion und Speicherung von Bildern und die Entfernung von Artefakten wie Kopf- und Fußzeilen
  • Zur Erhöhung der Genauigkeit kann mit --use_llm zusätzlich ein LLM verwendet werden; der Standard ist gemini-2.0-flash, alternativ sind Gemini, Ollama, Claude, OpenAI, Azure OpenAI usw. wählbar
  • Im Benchmark erzielte Marker bei einzelnen PDF-Seiten durchschnittlich 2.83837 Sekunden, einen heuristischen Score von 95.6709 und einen LLM-Score von 4.23916; im H100-Batch-Modus wird ein Durchsatz von 25 pages/second erwartet
  • Erforderlich sind Python 3.10+ und PyTorch; der Code steht unter GPL, die Modellgewichte unter einer modifizierten AI Pubs OpenRAIL-M-Lizenz, die für Forschung, private Nutzung und Startups mit unter $2M kostenlos ist

Von Marker konvertierte Dokumente und Ausgaben

  • Marker konvertiert Dokumente in Markdown, JSON, Chunks und HTML
  • Zu den Eingabeformaten gehören PDF, Bilder, PPTX, DOCX, XLSX, HTML und EPUB; Dokumente in allen Sprachen werden unterstützt
  • Verarbeitete Dokumentelemente:
    • Tabellen, Formulare, Formeln, Inline-Mathematik
    • Links, Referenzen, Code-Blöcke
    • Bildextraktion und -speicherung
    • Entfernung von Kopfzeilen, Fußzeilen und anderen Artefakten
  • Kann mit eigener Formatierung und Logik erweitert werden
  • Wenn ein JSON-Schema übergeben wird, ist strukturierte Extraktion möglich; diese Funktion ist beta
  • Läuft auf GPU, CPU und MPS

Verwaltete Plattform von Datalab

  • Die verwaltete Plattform von Datalab führt das aktuelle Open-Source-Modell Chandra aus
  • Chandra wird als genauer als Marker beschrieben, standardmäßig ohne Datenspeicherung, und bietet SOC 2 Type 2 sowie ein benutzerdefiniertes BAA
  • Der Batch-Verarbeitungsdienst für große Workloads hat bereits 200M+ Seiten pro Woche verarbeitet
  • Bei der Registrierung gibt es $5 Gratisguthaben; außerdem steht ein öffentliches Playground zur Verfügung
  • Für kommerzielles Self-Hosting ist eine Lizenz erforderlich; On-Premise-Lizenzen müssen separat angefragt werden

Leistung und hybrider LLM-Modus

  • Marker präsentiert günstige Benchmark-Ergebnisse im Vergleich zu Cloud-Diensten wie Llamaparse und Mathpix sowie zu anderen Open-Source-Tools
  • Die vollständigen Leistungsergebnisse in der README basieren auf serieller Ausführung einzelner PDF-Seiten
  • Im Batch-Modus ist Marker schneller; auf einer H100 wird ein Durchsatz von 25 pages/second erwartet
  • Für maximale Genauigkeit kann mit dem Flag --use_llm zusätzlich ein LLM verwendet werden
    • Zusammenführen von Tabellen über Seiten hinweg
    • Verarbeitung von Inline-Mathematik
    • Verbesserte Tabellenformatierung
    • Extraktion von Werten aus Formularen
  • Der hybride LLM-Modus erreicht bei Tabellen-Benchmarks eine höhere Genauigkeit als Marker allein oder Gemini Flash allein

Installation und grundlegende Verwendung

  • Erforderlich sind Python 3.10+ und PyTorch
  • Installation für PDF-zentrierte Nutzung: 
    pip install marker-pdf
  • Für andere Dokumentformate als PDF müssen zusätzliche Abhängigkeiten installiert werden 
    pip install marker-pdf[full]
  • Konvertierung einer einzelnen Datei: 
    marker_single /path/to/file.pdf
  • Konvertierung mehrerer Dateien auf Ordnerebene: 
    marker /path/to/input/folder
  • Konvertierung mit mehreren GPUs: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES ist die Anzahl der zu verwendenden GPUs und muss mindestens 2 sein
    • NUM_WORKERS ist die Anzahl paralleler Prozesse pro GPU

Wichtige CLI-Optionen

  • --page_range TEXT: Gibt Seitennummern und -bereiche zur Verarbeitung an
  • --output_format [markdown|json|html|chunks]: Gibt das Ausgabeformat an
  • --output_dir PATH: Gibt das Verzeichnis zum Speichern der Ausgabedateien an
  • --paginate_output: Gibt Seitenzahlen und Trennlinien in der Ausgabe aus
  • --use_llm: Erhöht die Genauigkeit mit einem LLM
  • --force_ocr: Erzwingt OCR für das gesamte Dokument und formatiert auch Inline-Mathematik passend
  • --block_correction_prompt: Gibt im LLM-Modus einen Prompt zur Korrektur der Marker-Ausgabe an
  • --strip_existing_ocr: Entfernt vorhandenen OCR-Text und führt OCR mit surya erneut aus
  • --redo_inline_math: Verbessert zusammen mit --use_llm die Qualität der Inline-Mathematik-Konvertierung
  • --disable_image_extraction: Extrahiert keine Bilder aus PDFs
  • --converter_cls: Wählt den Standard marker.converters.pdf.PdfConverter oder den tabellenspezifischen marker.converters.table.TableConverter
  • --llm_service: Gibt bei Verwendung von --use_llm den LLM-Dienst an; Standard ist marker.services.gemini.GoogleGeminiService
  • --workers: Gibt die Anzahl gleichzeitiger Konvertierungs-Worker an
    • Pro Worker werden maximal 5 GB VRAM, im Durchschnitt 3.5 GB VRAM genutzt

Python-API und Manipulation interner Blöcke

  • Mit PdfConverter kann die Konvertierung direkt in Python erfolgen 
    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)
  • Bei Markdown-Ausgabe besitzt rendered die Eigenschaften markdown, metadata und images
  • Bei JSON-Ausgabe besitzt rendered die Eigenschaften children, block_type und metadata
  • Mit ConfigParser können Ausgabeformat, Prozessoren, Renderer, LLM-Dienst usw. konfiguriert werden
  • Dokumente bestehen aus einem Baum aus Seiten und Blöcken; Seiten können wiederum Blöcke enthalten
  • Mit contained_blocks lassen sich bestimmte Blöcke wie Formulare programmatisch extrahieren

Arten von Konvertern

  • PdfConverter: Standardkonverter zur Umwandlung vollständiger PDFs
  • TableConverter: Extrahiert und konvertiert nur Tabellen
    • Mit force_layout_block=Table wird die Layouterkennung umgangen und jede Seite als Tabelle behandelt
    • Mit output_format=json können zusätzlich Bounding Boxes der Zellen ausgegeben werden
  • OCRConverter: Führt nur OCR aus
    • Wenn --keep_chars gesetzt ist, bleiben einzelne Zeichen und Bounding Boxes erhalten
  • ExtractionConverter: Ein beta-Konverter für strukturierte Extraktion
    • Zunächst muss ein LLM-Dienst konfiguriert werden
    • Gibt extrahierte Werte im JSON-Format zurück
    • Wenn original_markdown eines vorherigen Laufs als existing_markdown übergeben wird, kann das erneute Parsen des Dokuments übersprungen werden

Ausgabeformate

  • Markdown-Ausgabe:
    • Bildlinks
    • Formatierte Tabellen
    • In $$ eingeschlossene LaTeX-Formeln
    • Code-Blöcke mit dreifachen Backticks
    • Hochgestellte Fußnoten
  • HTML-Ausgabe:
    • Bilder mit img-Tags
    • Formeln mit <math>-Tags
    • Code mit pre-Tags
  • JSON-Ausgabe:
    • Stellt Seiten als Liste dar, wobei jede Seite ein Block des internen Marker-Schemas ist
    • Enthält die Schlüssel id, block_type, html, polygon und children
    • Kindblöcke enthalten zusätzlich section_hierarchy und images
    • Die Blockstruktur ist baumförmig
  • Chunks-Ausgabe:
    • Ähnlich wie JSON, aber alles wird zu einer einzigen Liste abgeflacht
    • Enthält das vollständige HTML jedes Blocks und kann flexibel für RAG-Chunking genutzt werden
  • Alle Ausgabeformate geben metadata zurück
    • table_of_contents als berechnetes PDF-Inhaltsverzeichnis
    • page_stats mit Extraktionsmethode und Anzahl der Blöcke pro Seite

Unterstützte LLM-Dienste

  • Verfügbare Dienste bei Verwendung von --use_llm:
    • Gemini: Verwendet standardmäßig die Gemini developer API und benötigt --gemini_api_key
    • Google Vertex: Benötigt --vertex_project_id und marker.services.vertex.GoogleVertexService
    • Ollama: Verwendet lokale Modelle; --ollama_base_url und --ollama_model müssen gesetzt werden
    • Claude: --claude_api_key und --claude_model_name müssen gesetzt werden
    • OpenAI: Unterstützt OpenAI-kompatible Endpunkte; --openai_api_key, --openai_model und --openai_base_url müssen gesetzt werden
    • Azure OpenAI: --azure_endpoint, --azure_api_key und --deployment_name müssen gesetzt werden

Interne Struktur und Erweiterungspunkte

  • Marker arbeitet als Deep-Learning-Modellpipeline
    • Textextraktion, bei Bedarf mit OCR
    • Erkennung von Seitenlayout und Lesereihenfolge
    • Bereinigung und Formatierung einzelner Blöcke
    • Qualitätsverbesserung bei Bedarf mit LLM
    • Zusammenführung von Blöcken und Nachbearbeitung des Gesamttests
  • Für OCR- und layoutbezogene Schritte wird surya verwendet
  • Für formelbezogene Formatierung wird texify verwendet
  • Zentrale Komponenten:
    • Providers: Liefern Informationen aus Quelldateien wie PDFs
    • Builders: Erstellen anfängliche Dokumentblöcke und füllen Text ein
    • Processors: Verarbeiten bestimmte Blöcke, etwa Tabellenformatierer
    • Renderers: Rendern Blöcke in Ausgabeformate
    • Schema: Klassen für alle Blocktypen
    • Converters: Führen die vollständige End-to-End-Pipeline aus
  • Um das Verarbeitungsverhalten zu ändern, werden processors überschrieben
  • Neue Ausgabeformate werden durch Schreiben eines neuen renderer hinzugefügt
  • Neue Eingabeformate werden durch Schreiben eines neuen provider hinzugefügt

API-Server und Bereitstellung

  • Ein einfacher FastAPI-Server kann gestartet werden 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • Der Server ist unter localhost:8001 erreichbar; unter localhost:8001/docs lassen sich die Endpoint-Optionen einsehen
  • Dieser API-Server ist keine robuste API und nur für kleine Nutzung gedacht
  • Für robustere Konvertierungsoptionen kann die gehostete Datalab API verwendet werden
  • Zu den Bereitstellungsbeispielen gehört auch die Bereitstellung eines Web-Endpoints über Modal

Fehlerbehebung

  • Bei Genauigkeitsproblemen sollte --use_llm verwendet werden
    • In diesem Fall muss der Gemini-API-Schlüssel als GOOGLE_API_KEY gesetzt werden
  • Wenn Text beschädigt erscheint, sollte das Dokument mit force_ocr erneut per OCR verarbeitet werden
  • Mit TORCH_DEVICE kann das zu verwendende Torch-Gerät erzwungen werden
  • Bei Speicherfehlern kann die Anzahl der Worker reduziert oder ein langes PDF in mehrere Dateien aufgeteilt werden
  • Die Option debug speichert Seitenbilder mit erkanntem Layout und Text sowie JSON-Dateien mit Bounding-Box-Informationen

Benchmark-Ergebnisse

  • Für den Benchmark zur vollständigen PDF-Konvertierung wurde ein Benchmark-Set verwendet, das aus aus Common Crawl extrahierten einzelnen PDF-Seiten erstellt wurde
  • Die Scores werden über Heuristiken zur Ausrichtung an Ground-Truth-Textsegmenten sowie mit dem Ansatz LLM-as-judge berechnet
  • Ergebnisse der vollständigen PDF-Konvertierung:
    • marker: Durchschnittszeit 2.83837, Heuristik 95.6709, LLM 4.23916
    • llamaparse: Durchschnittszeit 23.348, Heuristik 84.2442, LLM 3.97619
    • mathpix: Durchschnittszeit 6.36223, Heuristik 86.4281, LLM 4.15626
    • docling: Durchschnittszeit 3.69949, Heuristik 86.7073, LLM 3.70429
  • marker und docling liefen auf einer H100, llamaparse und mathpix nutzten Cloud-Dienste
  • Für den Durchsatzbenchmark mit langen PDFs wurde Think Python verwendet
    • marker: 0.18 Sekunden pro Seite
    • 43.42 Sekunden pro Dokument
    • 3.17 GB VRAM
    • Auf einer H100 können 22 einzelne Prozesse laufen, woraus ein erwarteter Durchsatz von 122 pages/second resultiert
  • Für den Benchmark zur Tabellenkonvertierung wurde die HTML-Darstellung des Test-Splits von FinTabNet verglichen
    • marker: Durchschnittsscore 0.816, insgesamt 99 Tabellen
    • marker w/use_llm: Durchschnittsscore 0.907, insgesamt 99 Tabellen
    • gemini: Durchschnittsscore 0.829, insgesamt 99 Tabellen
  • Tabellen, die sich aufgrund von Unterschieden zwischen FinTabNet und der Erkennung des Layout-Modells nicht mit der Ground Truth ausrichten ließen, wurden herausgefiltert

Grenzen und Lizenz

  • PDFs sind ein schwer handhabbares Format, daher funktioniert Marker nicht immer perfekt
  • Bekannte Einschränkungen:
    • Sehr komplexe Layouts mit verschachtelten Tabellen und Formularen funktionieren möglicherweise nicht
    • Das Rendering von Formularen kann problematisch sein
  • Mit den Flags --use_llm und --force_ocr lassen sich die meisten dieser Probleme beheben
  • Die Modellgewichte stehen unter einer modifizierten AI Pubs OpenRAIL-M-Lizenz
    • Kostenlos für Forschung, private Nutzung und Startups mit funding/revenue unter $2M
  • Der Code steht unter der GPL-Lizenz
  • Für breitere kommerzielle Lizenzen oder den Wegfall der GPL-Anforderungen siehe die Pricing-Seite

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-02
Meinungen auf Hacker News

  • Die Art, wie im gesamten Repo mit Nougat verglichen wird, ist etwas verwirrend.
    Nougat ist ein Modell, das speziell für wissenschaftliche Dokumente trainiert wurde, und ich glaube nicht, dass jemals behauptet wurde, Nougat sei das beste OCR-Modell. Auch in den Benchmarks steht, dass Nougat bei arXiv-Dokumenten eine höhere Genauigkeit erreicht. Außerdem ist es etwas schade, dass marker mit Nougat bei der Geschwindigkeit verglichen wird, während zugleich gesagt wird, dass marker Formeln weniger gut umwandelt als Nougat – gerade weil Nougat ein Modell für wissenschaftliche Dokumente ist.
    Wenn man PDFs mit Mathematik per OCR verarbeiten will, sollte man Nougat auf jeden Fall ausprobieren. Es lässt sich leicht als Python-Paket installieren und extrahiert mit einem einzigen Befehl Formeln, Text, Tabellen usw. in eine .mmd-Datei. Für den persönlichen Gebrauch ist auch die Geschwindigkeit in Ordnung: Auf einem vier Jahre alten i5-Laptop dauerte die Umwandlung eines 6-seitigen Dokuments nur mit der CPU etwa 30 Sekunden.

    • Zwei Dinge zu vergleichen bedeutet nicht, dass das bisherige als das beste beworben wurde.
      Es ist einfach eine Methode, ein neues Tool neben etwas Bekanntem einzuordnen. Wie gesagt: Nougat ist leicht zu installieren und auszuführen, daher ist es ein naheliegender Vergleichskandidat. Wenn mehr Bibliotheken in den Vergleich aufgenommen würden, wäre das natürlich noch besser und nützlicher.
    • Ich frage mich, wie gut Nougat PDFs von RPG-Regelwerken verarbeiten würde.
      Ich suche ein OCR-Modell, das dabei hilft, Teile von RPG-Büchern nach Markdown zu übertragen. Schön wäre, wenn Hervorhebungen wie Fett- oder Kursivschrift möglichst erhalten blieben.
      Die Kombination aus Text, Zahlen und mathematischen Symbolen wirkt ähnlich wie in technischen oder wissenschaftlichen Dokumenten, aber es gibt oft merkwürdige Formatierungen, Textboxen in den Rändern und viele Diagramme.
    • Ich bin der Autor. Mein Use Case ist die Massenkonvertierung wissenschaftlicher PDFs, daher war Nougat die beste Lösung und deshalb der Standardvergleich.
      Weiter unten habe ich auch einen Vergleich mit einfacher Textextraktion eingefügt. Nougat ist ein hervorragendes Modell und konvertiert viele PDFs gut, aber ich wollte etwas Schnelleres und allgemeiner Einsetzbares.
    • Ich möchte Jahresabschlüsse aus Tabellen in PDFs extrahieren. Wäre Nougat auch für so etwas geeignet?

  • Man sollte die Wirkung solcher Tools nicht unterschätzen. Es geht darum, enormes Wissen freizulegen, das in einem Format steckt, das „gut zum Lesen, aber schlecht zum Verteilen“ ist.
    Ich bin wirklich gespannt. Eine Pipeline wäre großartig: alle PDFs → alle nach Markdown konvertieren → alles auf archive.org archivieren

    • Für Archivierungszwecke wirkt diese Pipeline nicht passend. Eine bessere Reihenfolge wäre alle PDFs → Originale archivieren → nach Markdown konvertieren.
      So kann man die Konvertierung erneut laufen lassen, wenn Bugs behoben und Verbesserungen vorgenommen werden. Bei der Langzeitarchivierung bevorzugt man normalerweise, so nah wie möglich am Originalmaterial zu speichern, weil jede spätere Umwandlung nur Datenverlust verursachen kann.
    • PDF ist tatsächlich ein hervorragendes Distributionsformat.
      Man kann die Rohdaten, mit denen das Dokument für Endnutzer erzeugt wurde, unsichtbar in einem gewünschten Format einbetten. Wenn man zum Beispiel HTML mit PrinceXML zu einem PDF rendert, kann man das ursprüngliche JSON, mit dem sämtliche Texte, Graphen, Charts usw. erzeugt wurden, in das PDF einbetten. Natürlich machen das die meisten in der Praxis nicht, aber das ist nicht die Schuld der Spezifikation.
    • Ich bin der Autor. Das ist einer der Gründe, warum ich dieses Tool gebaut habe.
      https://github.com/VikParuchuri/libgen_to_txt ist ebenfalls einen Blick wert. Es ist noch nicht mit marker integriert und verwendet derzeit einfache Textextraktion.
    • Für Tools dieser Art gibt es enorme Nachfrage. Besonders große Organisationen mit vielen PDF-Dokumenten in unterschiedlichsten Formen müssen daran zwangsläufig interessiert sein.
      Selbst wenn nur ein Teil der Anforderungen oder Use Cases abgedeckt wird, wäre es sehr nützlich, sofern es zuverlässig funktioniert.
    • Auch aus Sicht der Barrierefreiheit ist das sehr nützlich.
      PDF-Barrierefreiheit korrekt umzusetzen ist eine enorme Aufgabe, und selbst wenn sie korrekt umgesetzt ist, ist gut möglich, dass der PDF-Viewer des Nutzers die nötigen Standards nicht unterstützt.

  • Das muss ich am Wochenende selbst ausprobieren.
    Ich tippe häufig gescannte RPG-PDFs unbekannter Herkunft von Hand ab, bei denen entweder gar keine OCR vorhanden ist, sodass kein Text auswählbar ist, oder die OCR von schlechter Qualität ist.
    Manchmal ist es buchstäblich schneller, einfach direkt zu tippen, als Copy-and-paste-Fehler zu korrigieren oder erst OCR-Text zu erzeugen und dann dessen Fehler zu beheben.
    Selbst bei offiziellen PDFs ist die Formatierung oft kaputt, sodass zwischen Wörtern doppelte oder dreifache Leerzeichen oder Tabs auftauchen. Wenn das ordentlich funktioniert, könnte es wirklich sehr viel Zeit sparen.

    • Ich hatte ebenfalls diesen Use Case im Kopf. Ich habe es schon mit einem Buch versucht, aber die Ergebnisse waren nicht besonders gut.
      Tabellen und Textboxen wurden stark beschädigt. Wenn man von Tabellen Screenshots macht, sie in ChatGPT einfügt und eine Umwandlung in Markdown-Tabellen verlangt, kommen ziemlich gute Ergebnisse heraus. Mit etwas Prompting wie „Lies zeilenweise. Die Spaltenüberschriften sind X, Y, Z. X ist Text, Y ist eine Zahl, Z ist ein Wort“ konnte es auch unregelmäßige Tabellen verarbeiten.
    • Bei RPG-Material gibt es wirklich sehr viel, das nie auf physischen Medien erschienen ist und bei dem die Rechteinhaberschaft verwaist ist; genau daran musste ich denken.

  • Wie brauchbar ist Tesseract OCR heutzutage? Als ich es früher ausprobiert habe, war es den Online-OCR-Diensten von AWS, Azure und GCP weit unterlegen.

    • Es gab in letzter Zeit einige Updates, und im Git-Repo wird Tesseract 5 als Abhängigkeit genannt. Es ist gut möglich, dass es deutlich besser geworden ist als bei meinem letzten Einsatz.
      https://github.com/tesseract-ocr/tesseract/releases
      Am Ende dürfte es vom Use Case abhängen. Für solche persönlichen Arbeiten ist es wahrscheinlich ausreichend, und man braucht auch keine Nutzerdaten oder Kreditkarte.
    • Es war besser als erwartet, und auch die Performance im Browser war beeindruckend.
      Allerdings ist es sehr empfindlich gegenüber der Auflösung. Wenn ein Bild unter eine bestimmte Größe fällt, ist es für Menschen noch gut lesbar, aber die Ausgabe von Tesseract wird völlig unbrauchbar.
    • Es braucht ziemlich viel Vorverarbeitung. Ich habe nur die GCP-Lösung verwendet, und meiner Erfahrung nach war die besser.
    • Ich habe es ziemlich kürzlich ausprobiert, und es scheiterte schon an sehr einfachen Bildern.
      Ich habe auch die iOS Vision API versucht, aber sie scheiterte ebenfalls. Der Testfall war ein scharfes Foto einer Buchseite.

  • Frage an den Autor: Warum Markdown? Der schwierige Teil dieses Tools scheint zu sein, PDFs mit hoher Genauigkeit zu parsen, nicht in welches Format anschließend exportiert wird.
    Deshalb wäre es gut, wenn Nutzer das Ausgabeformat wählen könnten. Wenn es einen PDF-Parser mit hoher Genauigkeit gibt, würde ich ihn gern für die EPUB-Erstellung verwenden.

    • Irgendeine Art von Markup, das strukturelles Markup möglichst gut erhält, ist nötig.
      Ich verwalte E-Books bei einem Universitätsverlag, und es gibt viele alte Titel, die auf eine Konvertierung warten; bei vielen davon sind nur noch Seitenscans der alten Druckausgaben vorhanden. Um sie als EPUB bereitzustellen, muss man wissen, wo Kapiteltrennungen, Überschriften, Tabellen, Diagramme, Formeln, Zitate usw. stehen. Externe Dienstleister können das übernehmen, aber bei manchen Büchern sind die Konvertierungskosten höher als die Verkaufserlöse. Es wäre gut, wenn wir zumindest einen Teil selbst machen könnten.
    • Ich stimme zu, dass das Zwischenformat möglichst nahe an Plain Text liegen sollte, der sich optional in andere Formate umwandeln lässt.
      Allerdings scheint Markdown hier als Zwischenformat verwendet zu werden. Es ist nah an Plain Text, kann aber einfache Layoutinformationen bewahren. In der Praxis würde man die Markdown-Ausgabe vermutlich an ein Tool anschließen, das sie in das gewünschte endgültige Ausgabeformat konvertiert.
    • Markdown wurde gewählt, weil man Formeln, Tabellen, Fett-/Kursivinformationen und Überschriften erhalten wollte.
      Formeln lassen sich mit $/$$ umschließen. EPUB-Ausgabe habe ich mir noch nicht angesehen, aber wegen dieser Anforderungen fiel reiner Plain Text weg.

  • Es gibt einen speziellen Anwendungsfall, für den ich noch keine gute Lösung gefunden habe: Baudokumente lesen.
    Pläne kommen immer als PDF, dabei hat es beim Parsen von DXF-Dateien (AutoCAD) viel besser funktioniert. Aber selbst wenn ich der Generalunternehmer auf der Baustelle bin, ist es nicht immer einfach, vom Architekten DXF-Dateien zu bekommen.

  • Lange Texte lese ich hauptsächlich auf einem E-Book-Reader.
    PDFs, besonders mehrspaltige Layouts, sind mit den Standardfunktionen von Amazon Kindle oder PocketBook nahezu ein Albtraum. Dieses Tool könnte das Leseerlebnis deutlich verbessern.

  • Gute Arbeit.
    Ich hatte mich gefragt, woher die Halluzinationen in der Nougat-Ausgabe kommen. Wenn man die Nougat-Ausgabe des Think-Python-Beispiels überfliegt, sieht man, was gemeint ist.
    Beim erneuten Hinsehen steht dort, dass es durch ein LLM läuft, also waren Halluzinationen zu erwarten.

    • Ich halte solche Tools für riskant, solange die Halluzinationsrate bei Text oder Formatierung nicht niedriger ist als die Fehlerrate eines sorgfältigen Lesers, der ein Dokument wiederholt liest.
      Dieses Niveau liegt nahe bei null, und je nach Anwendungsfall muss es tatsächlich null sein. Wenn der genaue Dokumentinhalt nicht wichtig ist, ist es meist in Ordnung; aber es dürfte selten große Mengen an Dokumenten geben, die weder jetzt noch in Zukunft für irgendjemanden wichtig sind und zugleich zugänglicher als ein PDF sein müssen.

  • Sieht nach einem Tool aus, das mir helfen könnte, meine Notizen aus OneNote zu migrieren.

  • Ziemlich interessant. Es wäre gut, ein paar Vorher-/Nachher-Beispiele für Konvertierungen ins Repo aufzunehmen.
    Ich frage mich, auf welche Arten von PDFs ihr es abstimmt. Wie werden handschriftliche Anmerkungen behandelt?