PDFs für LLMs und Retrieval-Pipelines vorbereiten

Warum nicht einfach den Rohtext auslesen

Jede PDF-Bibliothek liefert Ihnen den Text eines Dokuments in wenigen Zeilen Code, und für ein einspaltiges Memo genügt das wirklich. Für alles andere nicht, aus drei Gründen, die allesamt Retrieval-Qualität kosten.

Erstens die Lesereihenfolge. Rohes Auslesen liefert den Text in der Reihenfolge, in der die Glyphen gezeichnet wurden, was auf einer zweispaltigen Seite die Spalten verschränkt. Die Hälfte Ihrer Chunks wird zu Satzfragmenten, die zwischen zusammenhanglosen Absätzen wechseln, und sie betten auf einen Punkt im Vektorraum ein, dem nichts entspricht.

Zweitens die Grenzen. Ohne Überschriften gibt es nichts, woran sich zerteilen ließe, außer der Zeichenzahl; Chunks brechen also mitten im Satz und mitten in der Tabelle, und ein Chunk, der mitten in einer Erklärung beginnt, ist für sich nicht verständlich — genau das aber muss ein abgerufener Chunk sein.

Drittens die Tabellen. Als Rohtext ausgelesen wird eine Tabelle zu einem Strom von Zahlen ohne jeden Hinweis darauf, aus welcher Spalte sie stammen. Ein Modell, das das liest, wird Ihre Frage dazu trotzdem beantworten. Die Antwort wird nur falsch sein.

Was Markdown der Pipeline gibt

Markdown ist hier aus Gründen ein gutes Zwischenformat, die nichts damit zu tun haben, dass es hübsch ist.

• Überschriften liefern semantische Chunk-Grenzen, sodass ein Chunk ein Abschnitt ist und kein Fenster von tausend Zeichen.
• Der Überschriftenpfad gibt jedem Chunk seinen Kontext — Sie können „Kapitel 3 › Ratenbegrenzung › Burst-Verhalten“ vor dem Einbetten voranstellen, was das Retrieval bei Dokumenten messbar verbessert, in denen dasselbe Wort in verschiedenen Abschnitten Verschiedenes bedeutet.
• Pipe-Tabellen halten Zeilen und Spalten beisammen, sodass ein Modell beim Lesen einer abgerufenen Tabelle erkennt, welche Zahl zu welcher Überschrift gehört.
• Es ist kompakt. Markdown trägt Struktur zum Preis weniger Zeichen je Element, während HTML oder JSON-Layoutformate Tokens für Markup ausgeben, das dem Modell nichts sagt.
• Es ist ein Format, von dem jedes aktuelle Modell im Training riesige Mengen gesehen hat, es braucht also keine Erklärung im Prompt.

Chunking, konkret

Der Ansatz, der bei umgewandelten Dokumenten funktioniert, ist: zuerst an Überschriften trennen und erst innerhalb eines übergroßen Abschnitts auf Größengrenzen zurückfallen.

Grobe Parameter, die sich über die meisten Dokumentarten halten:

Trennen Sie niemals eine Tabelle

Das ist die Regel, die die meisten Pipelines verletzen, weil ein naiver Splitter nicht bemerkt, dass er sich in einer Tabelle befindet.

Eine mittendurch getrennte GFM-Tabelle ergibt zwei Chunks, von denen keiner eine gültige Tabelle ist: Der erste hat einen Kopf und einige Zeilen, der zweite hat Zeilen ganz ohne Kopf. Der zweite ist schlimmer als nutzlos, denn seine Zahlen sind unbeschriftet, und ein Modell wird sie durch Raten beschriften.

Erkennen Sie Tabellenblöcke vor dem Zerteilen und halten Sie jeden intakt, auch wenn dabei ein Chunk über der Zielgröße entsteht. Ist eine Tabelle wirklich zu groß für einen Chunk, wiederholen Sie die Kopfzeile in jedem Teil.

Wo gescannte Dokumente hineinpassen

Ein Scan hat keinen Text, es gibt also nichts zu zerteilen. Die Texterkennung muss zuerst laufen — und ihre Ausgabe hat Eigenschaften, die eine Pipeline berücksichtigen muss, denn Erkennung ist eine Schätzung und keine Abschrift.

Zwei davon besonders. Die Konfidenz schwankt je Seite, ein Dokument kann also über vierzig Seiten nahezu fehlerfrei und auf dreien unzuverlässig sein; wenn Ihr Erkennungsschritt Konfidenz je Seite meldet, führen Sie sie in die Chunk-Metadaten mit, damit sich eine unsichere Antwort kennzeichnen lässt. Und unlesbare Wörter fallen weg, statt markiert zu werden — der Text wirkt also flüssig und vollständig, während genau das fehlt, was der Engine am schwersten fiel: oft Namen, Aktenzeichen und Zahlen.

Wo ein Fehler Folgen hat, sollte erkannter Text als zu prüfender Hinweis gelten, nicht als Quelle der Wahrheit.

Was vor dem Indexieren eines Korpus zu prüfen ist

Indexieren ist der teure, langsame, schwer rückgängig zu machende Schritt, es lohnt sich also, vorher zwanzig Minuten in eine Stichprobe zu stecken. Wandeln Sie fünf möglichst unterschiedliche Dokumente um und lesen Sie das Markdown.

• Bilden die Überschriften eine sinnvolle Leiter? Sind sie flach, hat Ihr Chunker nichts, woran er trennen könnte, und Sie fallen im ganzen Korpus auf Fenster fester Größe zurück.
• Haben die Tabellen überlebt? Zählen Sie bei zwei oder drei die Spalten gegen das Original.
• Stimmt die Lesereihenfolge auf mehrspaltigen Seiten? Verschränkte Spalten sind offensichtlich, sobald man hinsieht, und unsichtbar, sobald indexiert ist.
• Gibt es leere oder fast leere Umwandlungen? Das sind Scans, und die brauchen einen anderen Weg.
• Wiederholt sich in jedem Dokument derselbe Textbaustein? Wiederkehrende Kopf- und Fußzeilen werden zu beinahe identischen Chunks, die echte Inhalte aus den Trefferlisten verdrängen.

Die Datenschutzdimension, die nicht nebensächlich ist

RAG-Korpora entstehen genau aus den Dokumenten, die Organisationen am wenigsten an Dritte geben wollen: Verträge, interne Berichte, Kundendaten, noch unveröffentlichte Forschung.

Es lohnt sich, bewusst zu entscheiden, welche Schritte Ihrer Pipeline diese Dokumente irgendwohin senden. Die Umwandlung muss keiner davon sein: Ein Konverter im Browser verarbeitet die Datei auf dem Rechner, auf dem sie ohnehin liegt, der Umwandlungsschritt fügt der Kette also keine Partei hinzu. Ob spätere Schritte das tun, ist eine eigene Entscheidung — aber eine, die Sie getrennt treffen können.