Die versteckten Kosten von „ai_parse_document“ von Databricks im Produktivbetrieb

Mit „ai_parse_document“ und „ai_query“ erscheint die Extraktion von PDF-Daten ganz einfach. Hier finden Sie eine ehrliche Bewertung der Vor- und Nachteile, eine kostenlose deterministische Alternative sowie eine Übersicht darüber, was Sie vor der Entwicklung berücksichtigen sollten.

Eine kurze Anmerkung: Dies ist ein erneuter Beitrag. Ich habe bereits im Februar 2026 darüber geschrieben, was in KI-Zeit praktisch eine Ewigkeit her ist. Die unten aufgeführten wesentlichen Abwägungen gelten nach wie vor.

Ein Kollege und ich befassten uns mit einem Projekt im Gesundheitswesen, das an eine altbekannte Hürde gestoßen war. Die strukturierten Daten – Termine, Diagnosen, Abrechnungsunterlagen – waren zwar verwertbar, doch die Informationen, die die Menschen tatsächlich benötigten, befanden sich an anderer Stelle: Entlassungsberichte, Überweisungsschreiben, Aufnahmeformulare, Pflegeberichte. Allesamt unstrukturiert und uneinheitlich.

Wir waren gerade dabei, OCR-Tools, benutzerdefinierte Parser und APIs von Drittanbietern gegeneinander abzuwägen – also den üblichen Kompromiss zwischen Kosten, Genauigkeit und Wartungsaufwand –, als Databricks „ai_parse_document“ veröffentlichte, das all diese Probleme scheinbar auf einen Schlag löste.

Ein paar Zeilen SQL – und schon wurden unübersichtliche PDF-Dateien in strukturiertes JSON umgewandelt. Wenn man zum ersten Mal sieht, wie das funktioniert, kommt es einem wirklich wie Zauberei vor – ein Proof-of-Concept an einem einzigen Nachmittag.

Diese Einfachheit täuscht allerdings ein wenig, ehrlich gesagt. Sobald man über die Demo hinausgeht, verändert sich das Problem. Es geht nicht mehr darum, Felder aus einem einzelnen Dokument zu extrahieren. Es geht darum, diese Extraktion als System zu betreiben: zuverlässig, wiederholt und in großem Maßstab.

Bei diesem Wechsel – von der Abfrage zum Systemdesign – treten die eigentlichen Probleme zutage. Darum geht es in diesem Beitrag.

In den Beispielen wird Databricks verwendet, insbesondere „ai_parse_document“ und „ai_query“, entweder in SQL oder in Notebooks. Sie benötigen Databricks Runtime 17.1 oder höher sowie grundlegende Kenntnisse über Delta-Tabellen und die Medallion-Architektur.

Der Ausgangspunkt: ai_parse_document + ai_query

Bevor wir uns mit SQL befassen, ist eine Unterscheidung wichtig: Nicht alle PDF-Dateien sind gleich.

Digital erstellte PDF-Dateien enthalten echten, auswählbaren Text – denken Sie beispielsweise daran, ein Word-Dokument als PDF zu speichern. Gescannte PDF-Dateien sind Fotos von Seiten: Für den Menschen lesbar, für den Computer jedoch lediglich ein Bild, bis der Text mittels OCR rekonstruiert wird. Die Qualität der Textextraktion unterscheidet sich bei diesen beiden Arten erheblich.

Abbildung 1. Digital erstellte PDF-Datei (links) im Vergleich zu einer gescannten PDF-Datei (rechts).

So sehen „ai_parse_document“ und „ai_query“ in der Praxis aus:

Abbildung 2. Die Proof-of-Concept-Abfrage: PDFs mit „ai_parse_document“ analysieren, Felder mit „ai_query“ extrahieren.

Im Grunde genommen sind es zwei Schritte:

Parse. Die CTE „text_extracted“ ruft für jede Binärdatei aus „read_files“ die Funktion „ai_parse_document“ auf. Sie verarbeitet beide Dokumenttypen: Bei digitalen PDF-Dateien wird der eingebettete Text direkt gelesen, bei Scans wird zunächst eine OCR-Erkennung durchgeführt. Das Ergebnis ist ein strukturiertes Array „document.elements“ – bestehend aus Textblöcken und Tabellen sowie Abschnittsüberschriften –, das durch „transform“ und „concat_ws“ zu einer einzigen Zeichenkette namens „full_text“ zusammengefasst wird.

Auszug. Die äußere SELECT-Anweisung übermittelt diesen Text an ai_query mit der Anweisung: „Fünf Felder als JSON extrahieren: patient_ref, document_date, document_type, primary_diagnosis, follow_up_required“ – ausreichend, um eine abfragbare Patientenkohorte zu erstellen und zu kennzeichnen, wer eine Nachuntersuchung benötigt. Meistens werden die Felder korrekt ermittelt. Wenn etwas mehrdeutig oder nicht angegeben ist, leitet das System eine Schlussfolgerung ab, teilt Ihnen dies jedoch nicht immer mit.

Hier ist eine einzelne Zeile aus dem Ergebnis, noch bevor eine Bereinigung vorgenommen wurde:

Abbildung 3. Eine einzelne ai_query-Antwort vor jeglicher Bereinigung – Prosa, in Markdown-Fences eingeschlossenes JSON und eine Inferenznotiz, alles in einer einzigen Zeichenkette.

Einige Punkte sind zu beachten: „extracted“ ist kein JSON-Objekt, sondern eine reine Textzeichenfolge: ein Prosasatz, in Markdown-Fences eingeschlossener JSON-Code und anschließend eine „Note:“, die die Argumentation des Modells erläutert. Alles in einer durchgehenden Zeichenfolge, die bereinigt werden muss, bevor der darin enthaltene JSON-Code geparst werden kann.

Hierbei handelt es sich um eine Schlussfolgerung, nicht um eine Extraktion. Das Modell hat eine Ermessensentscheidung bezüglich „follow_up_required“ getroffen und diese hier erläutert, doch es wird dies nicht immer tun, und es kann in beiden Fällen mit Sicherheit falsch liegen.

Wo die Risse sichtbar werden

Die Abfrage funktioniert. Der erste Durchlauf ist nicht das Problem, sondern der zweite, und dabei treten vier Probleme zutage, die Ihnen ein Notizbuch niemals anzeigt:

Kosten. Beide Funktionen verursachen bei jedem Durchlauf Kosten. Da kein Checkpoint gesetzt ist, wird bei jedem Durchlauf jedes Dokument neu verarbeitet, und jede Änderung der Eingabeaufforderung führt zu einer erneuten Ausführung des gesamten Vorgangs. Die erste Abrechnung ist nicht das Problem. Das Problem ist vielmehr, dass jede Korrektur, jede Überarbeitung der Eingabeaufforderung und jeder Neuverarbeitungszyklus den Zähler erneut startet.

Dokumente aus dem Gesundheitswesen treffen in unregelmäßigen Chargen ein, beispielsweise in Form von Monatsend-Exporten, Migrationen aus Altsystemen oder korrigierten Datensätzen, die in großen Mengen erneut übermittelt werden. Bei Tarifen für mittlere Komplexität (~4,20–4,55 $ pro 1.000 Seiten) kostet die Analyse eines 30.000-seitigen Korpus 126–137 $ – ein einmaliger, überschaubarer Aufwand. Eine zeitnahe Iteration ist jedoch kein einmaliger Kostenfaktor. Bei jeder Verfeinerung wird „ai_query“ erneut auf jedes Dokument angewendet, und die Einbindung des Formats eines neuen Krankenhauses kann eine vollständige Neuauswertung auslösen.

Doppelte Einträge. Krankenhäuser senden Dokumente erneut, beispielsweise einen korrigierten Entlassungsbericht oder ein Überweisungsschreiben, das nach einer Systemumstellung erneut übermittelt wurde. Die oben genannte Abfrage erfasst dies nicht. Beide Versionen landen in Silver: Derselbe Patient erscheint zweimal, und falls sich durch die Korrektur die Diagnose geändert hat, gilt dies auch für beide Versionen.

Nichtdeterminismus. Der heikle Punkt: Ihre Pipeline kann „korrekt“ sein und dennoch an verschiedenen Tagen unterschiedliche Ergebnisse liefern. Ein regelbasierter Parser liefert bei gleicher Eingabe stets dieselbe Ausgabe. Ein LLM tut dies nicht. ai_query ist standardmäßig auf den Wert „Temperature 0“ eingestellt, was zwar hilfreich ist, doch selbst „Temperature 0“ garantiert keine identischen Ausgaben – Rundungen bei Gleitkommazahlen und die Parallelität der GPU führen ohnehin zu Abweichungen.

In der Praxis kann der Wert von „follow_up_required“ für dasselbe Dokument bei verschiedenen Durchläufen zwischen „true“ und „false“ wechseln – ohne Fehlermeldung, ohne Warnung, lediglich mit einem unauffälligen Unterschied im Ergebnis. In einem regulierten Umfeld beeinträchtigt dies die Nachvollziehbarkeit: Der Bericht ändert sich, ohne dass sich die zugrunde liegenden Daten ändern.

Sie können dies abmildern, indem Sie die Extraktion mehrmals durchführen und das häufigste Ergebnis übernehmen oder einen beschrifteten Testdatensatz erstellen, um Ihre Eingabeanweisung anhand bekannter, korrekter Ausgaben zu überprüfen. Diese zweite Option macht sich bezahlt, sobald Sie einen neuen Dokumenttyp oder ein neues Krankenhausformat unterstützen; ohne sie können Sie nicht feststellen, ob eine Änderung der Eingabeanweisung dem neuen Format geholfen hat, ohne dabei unbemerkt das alte Format zu beeinträchtigen. Beachten Sie jedoch, dass mehrere Durchläufe Ihre „ai_query“-Kosten direkt vervielfachen. Nichtdeterminismus und Kosten sind hier keine voneinander getrennten Probleme.

Eingabegeräusche. Auf jeder Seite ist ein Stempel mit einem Text wie „Vertraulich – Amsterdam UMC – Seite 4 von 11“ aufgedruckt, der für jedes Krankenhaus einheitlich ist, für die Extraktion jedoch bedeutungslos ist und ebenfalls an das LLM weitergeleitet wird. Da „ai_parse_document“ die Binärdaten intern verarbeitet, ist das Rauschen bereits fest im Text verankert, sodass Sie es erst in Silver bereinigen müssen, anstatt dies bereits vor der Verarbeitung durch das LLM zu tun. Das typische Symptom: Eine „primary_diagnosis“, die mit dem Briefkopf des Krankenhauses beginnt, anstatt mit der eigentlichen Diagnose.

Nichts davon ist schwerwiegend. All dies erfordert eine Systemkonzeption, die Ihnen in der Demo verborgen bleibt.

Bronze: Wo die LLM an ihre Grenzen stößt

Sobald Sie die Abfrage nicht mehr als Produkt, sondern als Datenaufnahme betrachten, ist Streaming mit Checkpoints die naheliegende Lösung.

Eines sollte zunächst besonders hervorgehoben werden: Das eigentliche Problem hinsichtlich personenbezogener Daten ist der vollständige Dokumententext. Entlassungsberichte und klinische Notizen enthalten Namen, Geburtsdaten und Diagnosen, und all diese Informationen werden an „ai_query“ übermittelt. Bevor Sie dies mit echten Patientendaten ausführen, sollten Sie entweder identifizierende Informationen entfernen, bevor diese das LLM erreichen, oder sicherstellen, dass Ihre Datenverarbeitungsvereinbarungen die Weiterleitung klinischer Inhalte abdecken. Wie bereits erwähnt, liegt dies außerhalb des Rahmens dieses Beitrags, sollte jedoch vor der Entwicklung berücksichtigt werden.

Abbildung 4. Von PDF-Dateien zu abfragbaren klinischen Daten. cloudFiles überträgt neue Dateien automatisch; ai_parse_document analysiert jede Binärdatei und wandelt sie in ein Array strukturierter Elemente um; der zusammengestellte Text wird zur Feldextraktion an ai_query weitergeleitet; Bronze speichert das Ergebnis mit einem Streaming-Checkpoint; Silver entpackt die Struktur in eine flache, abfragbare Tabelle.

Der erste Impuls ist, bei SQL zu bleiben: Jede Datei mit einem Hash versehen, in einer Delta-Tabelle nachverfolgen, was bereits verarbeitet wurde, und pro Eingabeaufforderung eine Version erstellen. Das funktioniert zwar, ist jedoch Standardcode, den Sie selbst schreiben und pflegen müssen.

„Structured Streaming“ ist der elegantere Weg. Spark verwaltet den Status über Checkpoints; neue Dateien werden durchgeleitet, bereits verarbeitete werden übersprungen, und das LLM wird nicht unnötig erneut ausgeführt. Weniger Standardcode, weniger Fehlerquellen.

Ein praktischer Hinweis: „patient_ref“ ist die interne Kennung eines Krankenhauses. Derselbe Patient erhält in der nächsten Einrichtung eine völlig andere Kennung. Speichern Sie die Kennung des Ursprungskrankenhauses von Anfang an zusammen mit jeder „patient_ref“-Angabe – das ist jetzt nur eine Zeile, kann Ihnen aber Monate voller Ärger ersparen, wenn Sie dies versäumen.

Die Pipeline gliedert sich in drei Streaming-Aufgaben, von denen jede über eine eigene Delta-Tabelle und einen eigenen Checkpoint verfügt:

Abbildung 5. Die drei Streaming-Aufgaben – Parsen, Text zusammenstellen, Felder extrahieren – schreiben jeweils in ihre eigene Delta-Tabelle und ihren eigenen Checkpoint.

Zu Duplikaten: cloudFiles verfolgt Dateien anhand ihres Pfades; daher wird eine erneut gesendete Datei mit demselben Namen vom Checkpoint übersprungen. Ein korrigiertes Dokument unter einem neuen Dateinamen hat jedoch einen anderen Pfad und wird als neue Zeile neben dem Original gespeichert. Die Deduplizierung erfolgt in der Silver-Stufe, wo die Funktion `ROW_NUMBER() OVER (PARTITION BY patient_ref, document_date, document_type ORDER BY _commit_timestamp DESC)` nur die aktuellste Extraktion pro logischem Dokument beibehält.

Die Aufteilung in drei Aufgaben wirkt sich auch positiv auf die Kosten aus. Parsing und Extraktion erfolgen getrennt, sodass Sie die Eingabeaufforderung aktualisieren können, ohne etwas erneut parsen zu müssen. ai_parse_document wird pro Seite abgerechnet; eine erneute Ausführung bei historischen Dateien jedes Mal, wenn Sie die Extraktion verfeinern, ist eine unnötige Kostenbelastung. Wenn ein Krankenhaus „patiëntnummer“ anstelle von „patient_ref“ verwendet oder Sie zusätzlich Medikamente extrahieren möchten, setzen Sie lediglich den Checkpoint von Aufgabe 3 zurück und führen Sie „ai_query“ erneut auf den bereits analysierten Text aus. Die Kosten für die Analyse bestehender Dateien bleiben dabei bei null.

Versehen Sie jeden Durchlauf mit einer neuen `prompt_version`; alte und neue Generationen existieren dann nebeneinander in der Tabelle, wobei der Prüfpfad intakt bleibt.

Databricks veröffentlicht ein Databricks Asset Bundle mit genau diesem Drei-Aufgaben-Muster als einsetzbare Referenz. In der Produktion werden die Schritte in der Regel als Databricks-Workflow ausgeführt: Parsen, Zusammenstellen, Extrahieren, Silver neu erstellen, Qualitätsprüfung durchführen. Sollte Bronze fehlschlagen, werden keine nachgelagerten Schritte ausgeführt.

Silver: Hauptsächlich nur SQL

Bronze übernimmt die Hauptarbeit. Bei Silber geht es hauptsächlich um SQL: Die extrahierte Struktur wird in eine abfragbare Tabelle umgewandelt, und die im Text bereits enthaltenen Stördaten werden entfernt. Eine SQL-UDF sorgt dafür, dass diese Bereinigung wiederverwendbar bleibt:

Abbildung 6. Die SQL-UDF „strip_noise“, die in jedem Freitextfeld wiederverwendet wird.

Wenden Sie sie auf jedes Freitextfeld an, in das möglicherweise Briefkopfdaten hineinragen, z. B. `strip_noise(extracted.primary_diagnosis)`, wie unten gezeigt. Jedes Krankenhaus erhält sein eigenes Kopfzeilenmuster; bauen Sie eine Bibliothek auf, sobald Sie neue Einrichtungen aufnehmen.

Abbildung 7. Die „Silver“-Abfrage: Die extrahierte Struktur flach darstellen, den Text bereinigen, abgeleitete Datumsfelder hinzufügen.

„follow_up_due_date“ ist hier ein Platzhalter für ein festes 30-Tage-Fenster. Die tatsächlichen Nachsorgeintervalle variieren je nach Diagnose und sollten idealerweise aus dem Dokument selbst stammen.

Hier sehen Sie eine typische Zeile in „bronze_documents_structured“ sowie denselben Datensatz, nachdem „Silver“ ihn abgeflacht und bereinigt hat:

Tabelle 1. Derselbe Datensatz vor und nach der Anwendung von „strip_noise“ und der „Silver“-Abfrage.

Das gleiche Prinzip wie bei „Bronze“: Führen Sie die aufwendige Arbeit nur einmal durch und wiederholen Sie sie nicht. Implementieren Sie „Silver“ als Tabelle und nicht als Ansicht. Sie zahlen einmal pro Durchlauf geringe Rechenkosten, und alle nachgelagerten Prozesse lesen aus einem sauberen, vorab berechneten Datensatz. Analystenabfragen werden schneller ausgeführt, „Bronze“ wird nicht wiederholt aufgerufen, und das LLM wird ausschließlich bei der Dateneingabe ausgeführt. Neue Prompt-Versionen werden als neue Zeilen hinzugefügt, und Sie aktualisieren lediglich den Filter.

Zu diesem Zeitpunkt verfügen Sie über eine saubere, flache „Silver“-Ebene mit strukturierten Feldern, von Rauschen befreit und mit einer nachverfolgten Prompt-Version. Was Sie darauf in „Gold“ aufbauen, hängt ganz von Ihrem Anwendungsfall ab, sodass dies ebenfalls nicht Gegenstand dieses Beitrags ist.

Bevor Sie jedoch damit beginnen, sollten Sie sich zunächst eine wichtige Frage stellen.

Nicht jede Pipeline benötigt ein LLM

Ein großer Teil der Dokumente im Gesundheitswesen folgt vorhersehbaren Vorlagen. Entlassungsberichte derselben Einrichtung sehen in etwa gleich aus. Überweisungsschreiben folgen einer Standardstruktur. Wo dies der Fall ist, ist ein LLM das falsche Werkzeug: Sie zahlen für Flexibilität, die Sie nicht benötigen, und akzeptieren einen Nicht-Determinismus, den Sie sich nicht leisten können.

In diesem Zusammenhang ist OpenDataLoader PDF erwähnenswert. Es handelt sich um eine Open-Source-Lösung (Apache 2.0), deren lokaler Modus vollständig deterministisch ist und den geometrischen XY-Cut++-Algorithmus für die Lesereihenfolge und die Tabellenerkennung nutzt, ohne dass ein Modell erforderlich ist. Der Aufwand für die Analyse sinkt auf null, und Sie können bei Bedarf zusätzlich ai_query zur Feldextraktion einsetzen. Die Einschränkung liegt in der Variabilität der Vorlagen: Wenn Krankenhäuser dasselbe Feld unterschiedlich bezeichnen („Patiëntnummer“ vs. „Patient ID“), benötigen Sie weiterhin ein LLM, um diese zu normalisieren. Sind die Vorlagen jedoch konsistent, ist das deterministische Parsing in Kombination mit regulären Ausdrücken kostengünstiger, schneller und vollständig reproduzierbar.

Andere Tools befinden sich an unterschiedlichen Punkten desselben Spektrums: layoutbewusste ML-Parser wie Docling oder MinerU in der Mitte, vollständig LLM-native Tools wie LlamaParse am anderen Ende. Der Kompromiss gilt für alle: mehr Komfort und Flexibilität, dafür weniger Determinismus und Kostenkontrolle.

Welcher Ansatz ist der richtige?

Die ehrliche Antwort hängt von Ihren Unterlagen ab:

Tabelle 2. Ordnen Sie die Vorgehensweise den Dokumenten zu.

Wann sich „ai_parse_document“ besonders gut eignet

„ai_parse_document“ ist kein schlechtes Tool. Es legt den Schwerpunkt auf eine schnelle Einrichtung, eine breite Dokumentenunterstützung und flexible Extraktion statt auf strikten Determinismus und Kosteneffizienz bei großem Umfang. Daher eignet es sich gut für:

In solchen Szenarien überwiegen die Vorteile tatsächlich die Nachteile.

Der Databricks-native Ansatz ist der bequemste Ausgangspunkt und manchmal auch das richtige Endergebnis, aber nicht immer das, worauf Sie nach einer umfassenden Bewertung in der Produktion hinauskommen. Wenn Sie keine Abweichungen bei den Ergebnissen tolerieren können, sollten Sie nicht mit einem LLM beginnen. Die meisten Teams benötigen keine intelligentere Analyse, sondern vorhersehbarere Systeme.

Die Arbeit an diesem Projekt hat mir großen Spaß gemacht. Falls Sie an einem ähnlichen Projekt arbeiten oder sich austauschen möchten, finden Sie mich auf LinkedIn.