PDFs automatisch trennen: KI besiegt das Zettelchaos

Stell dir vor, du stehst morgens auf der Baustelle. Der Kaffee in deiner Hand ist noch zu heiß zum Trinken, da drückt dir der Prüfer einen USB-Stick oder einen Download-Link in die Hand. Darauf: Ein einziges, 150 Seiten starkes PDF. Darin verstecken sich die frischen Prüfprotokolle für sämtliche Sektionaltore, Ladebrücken, Hebebühnen und Ketten eures gesamten Fuhrparks. Alles wild durcheinander. Für unsere Lizard Betriebsmittelverwaltung von Wolf+Strauss Solutions brauche ich genau eine Lösung. Ich habe eine kleine „LISS Engine“ gebaut, die solche PDF-Dokumente einfach importiert und daraus automatisch die einzelnen Betriebsmittel als Listen anlegt.

Klingt auf dem Papier mega cool. Hat in der Realität aber ein gewaltiges Problem.

Betriebsmittelverwaltung digital: Wenn stupides Seitenzählen scheitert

Der Klassiker bei solchen Tools ist ja: Ein hochgeladenes PDF entspricht einem Betriebsmittel. Aber ganz ehrlich? Die Praktiker draußen haben nicht für jedes verdammte Stahlseil eine feinsäuberlich abgelegte Einzeldatei. Die scannen den ganzen Stapel vom TÜV-Prüfer in einem Rutsch durch.

Das bedeutet für uns: Das dicke Dokument muss zerschnitten werden.

Wenn die Berichte alle gleich lang sind, habe ich Glück. 100 Seiten im PDF bei je einer Seite pro Maschine? Einmal jede Seite durchschnibbeln, fertig. Bei zweiseitigen Dokumenten eben jede zweite Seite.

Aber die Realität auf dem Bau ist kein sauberes Raster. Richtig blöd wird es, wenn die Betriebsmittel unterschiedlich lang dokumentiert sind. Das eine Tor braucht eine Seite, die Ladebrücke daneben drei, die Kette zwei, und das nächste Tor plötzlich fünf, weil die Verglasung defekt war.

Da kapituliert das stupide Seitenzählen. Du zerreißt zusammenhängende Prüfberichte in der Mitte. Und schon sitzt wieder irgendein armer Azubi stundenlang am Rechner und trennt PDFs per Hand. Ein absoluter Scheißprozess.

Ich brauchte also einen intelligenten KI PDF Splitter. Eine Lösung, die mitliest und versteht, wo eine Maschine aufhört und die nächste anfängt. Hier ist der Werkstattbericht, wie ich das in vier Schritten gebaut haben.

OCR für Handwerker: Vom dummen Bild zum smarten Markdown

Bevor irgendeine KI analysieren kann, ob es sich um ein Hörmann-Tor oder einen Feuerlöscher handelt, muss sie den Text lesen können. Gescannte PDFs sind für den Computer aber erstmal nur dumme Bilder – da ist null Struktur drin.

Deshalb läuft als erstes eine OCR (Optical Character Recognition) über das Dokument. Wir nutzen hier nicht einfach eine OCR, sondern eine Kombination aus OCR und LLM damit Struktur und Inhalt erhalten bleibt. Das geniale daran: Es wandelt den gescannten Text nicht einfach in einen flachen, endlosen Textbrei um, sondern in sauberes Markdown.

Warum Markdown? Weil es die Struktur des Dokuments erhält. Tabellen bleiben Tabellen, Überschriften bleiben Überschriften. Das hilft der KI später enorm, die Inhalte richtig zu interpretieren. Am Ende dieses Schritts habe ich eine massive Markdown-Datei, in der die einzelnen Seiten nur durch einfache <<< getrennt sind.

KI Datenextraktion: Warum feste Felder eine Sackgasse sind

Jetzt wird es spannend. Wir müssen den Seiten-Klassifikator (Page Classifier) anwerfen. Jede Seite wird einzeln an ein Large Language Model (LLM) geschickt – und zwar parallel, sonst wartest du auf das Ergebnis, bis der Beton ausgehärtet ist.

Die zentrale Frage am Whiteboard war: Welche Felder soll die KI extrahieren, um Dokumente zu unterscheiden?

Mein erster Ansatz war der Klassiker. Ich habe dem Modell genau vorgegeben, was es suchen soll: Auftragsnummer, Equipment-Nummer, Fabrik-Nummer, Prüfer.

Das war eine komplette Sackgasse. Jeder Dokumenttyp auf dem Bau hat andere verdammte Felder. Bei TÜV-Bescheinigungen gibt es Equipment-Nummern. Bei Hörmann-Wartungsprotokollen gibt es Checklistennummern. Bei Kettenprüfungen plötzlich Inventarnummern. Egal welche Felder ich fix vorgab – es fehlte immer etwas.

Die Lösung war, das Herr-Müller-Prinzip auf die KI anzuwenden: Wir entziehen dem System die starren Regeln und geben ihm stattdessen Verantwortung. Das LLM bekommt keine festen Feldnamen mehr, sondern nur noch diese Anweisung:

"Überlege zuerst: Welche strukturierten Informationen sind auf dieser Seite vorhanden? Extrahiere dann ALLE gefundenen Informationen als Schlüssel-Wert-Paare. Verwende die Bezeichnungen exakt so, wie sie im Dokument stehen."

Das Ergebnis ist ein dynamisches JSON-Dictionary. Es passt sich der Realität an, statt die Realität in eine Excel-Logik zu zwingen:

// TÜV-Prüfbescheinigung
{
  "Equipment-Nummer": "10613085",
  "Auftrags-Nummer": "8120908224-000120",
  "Fabrik-Nr.": "389249",
  "Prüfergebnis": "ohne Mängel"
}

// Hörmann-Wartungsprotokoll
{
  "Checklistennr.": "440000543536755",
  "Tor-Nr.": "2",
  "Produkttyp": "SPU67THERMO"
}

Zusätzlich lasse ich mir ein reasoning-Feld ausgeben, in dem die KI ihre Überlegung dokumentiert. Für das Debugging ist das Gold wert. Es zwingt das LLM jedoch auch, die Vorhersage in die richtige Richtung zu lenken. Daher gehört ein Reasoning-Feld (ähnlich wie beim Thinking) immer an den Anfang. Das heißt, die KI philosophiert darüber, welche Felder sinnvoll sind, bevor sie diese mit Leben füllt.

Automatisierte Dokumententrennung: Der magische Grenz-Schnitt

Jetzt kommt der alles entscheidende Schritt. Wo hört das eine Dokument auf und wo fängt das nächste an?

Dieser sogenannte Boundary Detector läuft sequenziell. Für jeden Übergang bekommt das LLM zwei Dinge: Das aktuelle, bisher gesammelte Dokument und die nächste Seite (inklusive der extrahierten Felder). Die KI vergleicht die Daten und entscheidet: Gehört das noch dazu oder ist das eine neue Maschine?

Dabei bin ich in ein paar ordentliche Fallen getappt. Hier sind meine wichtigsten Learnings, wenn du PDFs automatisch trennen willst:

Seitenzahlen lügen gnadenlos: „Seite 3 von 15" heißt nicht, dass die nächsten 12 Seiten zum gleichen Betriebsmittel gehören. Das ist oft ein Druckzähler für den Gesamtauftrag. 15 Seiten können 15 verschiedene Maschinen sein.

Die Auftragsnummer ist nutzlos zur Trennung: Ein einziger Auftrag umfasst auf der Baustelle oft zwanzig verschiedene Tore und Ladebrücken. Die Auftragsnummer bleibt gleich, das Betriebsmittel ändert sich.

Identifikatoren sind der Heilige Gral: Worauf es wirklich ankommt, sind Tor-Nummern, Service-IDs oder Fabriknummern. Daran erkennt die KI den Wechsel.

Anhängsel richtig zuordnen: Manche Seiten enthalten kaum eigene Daten, nur eine Unterschrift oder Haftungshinweise. Die KI muss checken, dass diese trotz fehlender Maschinen-ID zum vorherigen Dokument gehören.

Wenn die KI die Grenzen erkannt hat, übernimmt wieder ganz stumpf die Software. Python (mit PyPDF2) greift sich die erkannten Schnittmarken und zerlegt das Original-PDF in saubere, mit Metadaten benannte Einzeldateien.

LiteLLM im Einsatz: Wie wir das perfekte Modell fanden

Ein Aspekt, der sich als absoluter Gamechanger herausgestellt hat: Ich nutze LiteLLM als Abstraktionsschicht.

Statt mich fest an OpenAI, Anthropic oder Google zu binden und für jeden deren SDKs in meinen Code zu meißeln, nutze ich LiteLLM. Ich schreibe den Code einmal und wechsle das Modell einfach über eine Umgebungsvariable.

Das ist Wahnsinn für das Prototyping. Kein Code umschreiben. Einfach die Variable ändern und neu starten. Und hier kam die Überraschung: Mistral Large hat am besten abgeschnitten.

Während Claude Haiku 4.5 in meinem Test Tor-Prüfungen fälschlicherweise zusammengefasst hat und GPT-5.1 an manchen Parametern stolperte, hat Mistral Large auf Anhieb fast alles richtig getrennt – und das bei deutlich niedrigeren Token-Kosten. Bei 24 Seiten mit komplexer Extraktion fliegen dir die Tokens nämlich ordentlich um die Ohren. Am Ende waren es 0,003 € pro Seite, also 8,5 Cent für 24 Seiten in 2 Minuten. Kein Student hätte das so kostengünstig selbst geschnitten. Gegenrechnung: Komplexität mittel bis hoch. Unterschiedliche Seitenlängen und Dopplungen. Der Zeitaufwand für 24 Seiten betrug etwa 5 Minuten, was bei einem Mindestlohn von 13,90 € pro Stunde 1,15 € für die gleiche Arbeit entspricht. Das heißt, das LLM war doppelt so schnell und etwa 14-mal günstiger als der Student!

Echte Digitalisierung im Handwerk bedeutet Unsichtbarkeit

Was wir hier sehen, ist der Unterschied zwischen „Wir scannen jetzt alles ein“ und echter Digitalisierung.

Einfach ein PDF in eine Cloud zu schieben, digitalisiert nur das Chaos. Echte Digitalisierung, wie ich sie in meinen NoCode- und Automatisierungsprojekten predige, bedeutet: Technologie übernimmt die Denkarbeit, die für Menschen ohnehin nur frustrierend ist. High-Tech im Maschinenraum, radikale Einfachheit auf der Benutzeroberfläche.

Am Ende hatte ich ein Testdokument mit 24 Seiten. Darin wild gemischt: Eine Notbeleuchtungs-Wartung (3 Seiten), zwei Kettenprüfungen, drei TÜV-Bescheinigungen für Druckbehälter und 12 Sektionaltore.

Das Ergebnis? 18 Dokumente. Alle korrekt erkannt, fehlerfrei getrennt und sauber benannt.

Wenn ihr in eurem Betrieb auch vor PDF-Bergen sitzt, die euch den letzten Nerv rauben: Es gibt Wege da raus. Man muss sich nur trauen, die Werkzeuge richtig zusammenzustecken. Einfach mal machen!

Zum Video