Wir leben gerade in einer Zeit, in der bei fast jedem Datenproblem ziemlich schnell dieselbe Frage gestellt wird:
„Können wir das nicht mit KI lösen?“
Ich beschäftige mich selbst viel mit KI und entwickle Anwendungen damit.
Aber je mehr ich damit arbeite, desto wichtiger finde ich eine andere Frage:
Brauchen wir hier überhaupt KI?
Vor Kurzem hatte ich ein schönes Beispiel dafür.
170 Seiten PDF. Hunderte Tabellen.
Die Aufgabe klang zunächst relativ einfach:
Ein PDF mit über 170 Seiten enthielt hunderte Tabellen. Diese Tabellen sollten in strukturierte Daten überführt werden, damit sie anschließend von einer Software verarbeitet werden können.
Also im Grunde:
PDF rein → strukturierte Daten raus.
Klingt nach einem perfekten Anwendungsfall für KI.
War es aber nicht.
Der offensichtliche Weg: LLM oder OCR
Mein erster Gedanke ging natürlich in Richtung LLM.
Das Problem: Die Tabellen waren teilweise komplex aufgebaut, erstreckten sich über mehrere Seiten und hatten unterschiedliche Strukturen.
Ein LLM kann Tabellen durchaus verstehen.
Aber „kann meistens erkennen“ ist etwas anderes als:
„Ich kann mich bei hunderten Tabellen darauf verlassen, dass jede einzelne Zelle korrekt zugeordnet wird.“
Für eine automatisierte Datenverarbeitung ist das ein entscheidender Unterschied.
Dann bleibt OCR.
Also ungefähr:
PDF-Seite in ein Bild umwandeln.
Tabelle erkennen.
Zeilen und Spalten erkennen.
Zellen extrahieren.
Inhalte den richtigen Zellen zuordnen.
Erkennen, ob eine Tabelle auf der nächsten Seite weitergeht.
Tabellen wieder zusammensetzen.
Fehler behandeln.
Validieren.
Plötzlich war aus einem vermeintlich einfachen Import ein ziemlich komplexes Computer-Vision-Projekt geworden.
Und ich dachte:
Das kann doch nicht die einfachste Lösung sein.
Dann fiel mir etwas in den Metadaten auf
Ich schaute mir das PDF genauer an.
In den Metadaten stand, womit das ursprüngliche Dokument erstellt worden war:
Microsoft Word.
Das war der entscheidende Hinweis.
Also öffnete ich das PDF in Word und speicherte es wieder als .docx.
Und dann erinnerte ich mich an etwas, das ich irgendwann vor vielen Jahren gelernt hatte:
Ein DOCX-Dokument ist im Grunde nur ein ZIP-Container.
Darin liegen verschiedene XML-Dateien, die den Inhalt und die Struktur des Word-Dokuments beschreiben.
Also habe ich das DOCX entpackt und mir die Struktur angesehen.
Und da waren sie.
Die Tabellen.
Nicht als Pixel.
Nicht als visuelle Elemente, deren Bedeutung erst durch ein KI-Modell interpretiert werden musste.
Sondern als strukturierte XML-Elemente.
Eine Word-Tabelle wird beispielsweise als <w:tbl> repräsentiert.
Zeilen und Zellen haben ebenfalls definierte Strukturen.
Plötzlich war das Problem ein völlig anderes.
Kein OCR. Kein LLM. Kein Raten.
Statt einer Pipeline aus Bilderkennung, Tabellenanalyse und KI brauchte ich im Wesentlichen nur noch:
DOCX öffnen.
XML lesen.
<w:tbl>-Elemente finden.
Zeilen und Zellen extrahieren.
Die Daten in meine gewünschte Struktur überführen.
Der Rest war ganz normale Softwareentwicklung.
Deterministisch.
Testbar.
Nachvollziehbar.
Und vor allem: deutlich weniger komplex.
Vielleicht ist das die wichtigere Fähigkeit im KI-Zeitalter
Wir haben heute unglaublich mächtige Werkzeuge.
LLMs können Texte verstehen, Bilder analysieren, Dokumente klassifizieren und unstrukturierte Informationen in strukturierte Daten verwandeln.
Das verändert Softwareentwicklung massiv.
Aber genau deshalb entsteht auch eine neue Gefahr:
Wir greifen zu schnell zur mächtigsten Technologie, bevor wir das eigentliche Problem verstanden haben.
Nicht jedes Dokument ist wirklich unstrukturiert.
Nicht jedes PDF muss per OCR gelesen werden.
Nicht jede Klassifikation braucht ein LLM.
Nicht jede Automatisierung braucht einen AI Agent.
Manchmal existiert die Information bereits in einer Struktur, die wir nur noch nicht entdeckt haben.
Und dann ist ein XML-Parser möglicherweise die bessere „KI-Lösung“.
Erst verstehen. Dann Technologie auswählen.
Das Beispiel hat mich wieder an eine einfache Regel erinnert, die ich in Softwareprojekten immer wichtiger finde:
Nicht mit der Technologie anfangen.
Erst verstehen:
Was habe ich eigentlich vor mir?
Woher kommen die Daten?
Wie wurden sie erzeugt?
Welche Struktur existiert bereits?
Welche Informationen sind zuverlässig vorhanden?
Und erst danach entscheiden:
Was ist die einfachste Technologie, die dieses Problem zuverlässig löst?
Manchmal ist das ein LLM.
Manchmal Machine Learning.
Manchmal OCR.
Manchmal eine API.
Und manchmal ist es einfach ein XML-Parser.
Für mich ist genau das gute Softwareentwicklung.
Nicht möglichst viel Technologie einzusetzen.
Sondern möglichst wenig Technologie zu brauchen, um ein Problem zuverlässig zu lösen.
Und dann war da noch die eigentliche Digitalisierung …
Eine Sache blieb allerdings ungelöst.
Irgendwann hat jemand hunderte strukturierte Tabellen in ein Word-Dokument gepackt.
Dann daraus ein PDF exportiert.
Und dieses PDF anschließend als digitale Datenquelle bereitgestellt.
Technisch gesehen natürlich digital.
Strukturell gesehen …
nun ja. 😉
Vielleicht brauchen wir dafür dann doch noch KI.