Ein Klick in Salesforce, und aus dem Dokument werden Daten

Das Modell läuft in der Umgebung des Kunden selbst.

Azure OpenAI statt eines öffentlichen API-Endpunkts, im Azure des Kunden. Für ein Unternehmen, das deutsche Finanzdokumente verarbeitet, ist das die erste gestellte Frage und diejenige, die darüber entscheidet, ob ein Projekt überhaupt zustande kommt: Die Dokumente überschreiten nie eine Grenze, die der Kunde nicht kontrolliert, und es kommt kein zweiter Auftragsverarbeiter hinzu, der in ein Verzeichnis müsste. Es ist dieselbe Haltung wie der Eigenbetrieb der Pipeline im ersten Projekt, und aus demselben Grund. Die bequeme Wahl stand in beiden Fällen zur Verfügung und wäre in beiden Fällen die falsche gewesen.

Wenn er etwas nicht lesen kann, scheitert er laut, statt zu raten.

Ein Durchlauf, der kein brauchbares Ergebnis erzeugen kann, meldet einen Fehler mit Fehlercode und Begründung und lässt sich wiederholen. Er gibt nicht seine beste Vermutung zurück. Das ist das mit Abstand wichtigste Verhalten in einem System, das eine Kreditentscheidung speist, denn die Alternative ist keine fehlende Zahl, sondern eine selbstbewusst falsche in einem Feld, auf das jemand hin handeln wird. Ein Fehlschlag kostet einen erneuten Versuch. Eine plausible falsche Zahl kostet die Entscheidung, die sie verzerrt, und nichts weiter unten in der Kette kann sie von einer richtigen unterscheiden.

Jeder Dokumenttyp bekommt sein eigenes Schema, seinen eigenen Prompt und seine eigenen Regeln.

Deutsche Finanzdokumente sind nicht ein Format. Jeder Typ hat sein eigenes Layout, sein eigenes Vokabular und seine eigene Vorstellung davon, welche Zahlen zählen, und die Felder, die sich beim einen zu extrahieren lohnen, sind nicht die des anderen. Ein einziger allgemeiner Prompt über alle hinweg erzeugt eine Ausgabe, die für jeden Typ plausibel und für keinen richtig ist, und genau das ist die Schwachstelle, die Dokumentenextraktion in der Vorführung gut und im Betrieb schlecht dastehen lässt. Die Trennung nach Typ kostet vorab mehr und ist der Grund, warum die Ergebnisse tragen.

Einen Dokumenttyp hinzuzufügen ist eine Datenfrage, keine Codeänderung.

Ein neuer Typ ist ein Schema, ein Prompt und dessen Regeln, kein neuer Zweig durch die Pipeline. Das lässt die Abdeckung wachsen, ohne dass sich die Struktur des Systems ändert, und es bedeutet, dass diejenigen, die die Dokumente verstehen, es erweitern können, ohne den Dienst anzufassen. Eine Pipeline, die für jedes neue Formular eine Entwicklerin braucht, hört in dem Moment auf zu wachsen, in dem diese Entwicklerin beschäftigt ist.

Zu entscheiden, was das Modell zu sehen bekommt, ist der Großteil der Ingenieursarbeit.

Diese Dokumente kommen lang an, das Modell hat ein begrenztes Kontextfenster, und der lohnende Inhalt ist ein kleiner Bruchteil des Textes. Alles vor dem Modellaufruf existiert, um eine einzige Frage gut zu beantworten: Welchen Teil dieses Dokuments muss das Modell sehen, um dieses Schema zu füllen. Wird das falsch beantwortet, rettet kein Prompt die Sache, und deshalb stehen Erkennung und Verarbeitung vor der Extraktion, statt in sie hineingefaltet zu sein.

Der Auslöser sitzt dort, wo die Arbeit ohnehin stattfindet.

Das gesamte System ist erreichbar, indem man in Salesforce ein Dokument anklickt. Niemand meldet sich an einem zweiten Werkzeug an, lädt eine Datei hoch, wartet, lädt ein Ergebnis herunter und fügt es wieder ein. Das klingt nach Bequemlichkeit und geht in Wahrheit um Akzeptanz: Ein Extraktionsdienst, der einen Umweg verlangt, wird die erste Woche genutzt und dann liegen gelassen, und der Wert dieses Dienstes liegt darin, dass er auf einem Weg liegt, den jemand ohnehin gegangen ist.

Die Ergebnisse gehen dorthin zurück, wo entschieden wird.

Die Ausgabe ist keine Datei, die jemand erst suchen muss. Die extrahierten Felder, die abgeleiteten fachlichen Spalten und jede Kalkulation landen wieder auf dem Salesforce-Datensatz, der den Durchlauf ausgelöst hat, und das ist die Maske, an der entschieden wird. Die Artefakte werden zusätzlich auf den Azure-Share geschrieben, sodass JSON und CSV für alles Nachgelagerte vorliegen, aber das eigentliche Ziel ist der Datensatz.

Vorher: Handarbeit

Ersetzt wurde die Arbeit von Menschen, die Zahlen aus Dokumenten abtippen.

Jedes Dokument wurde geöffnet, gelesen und von Hand ins CRM eingegeben, bevor eine Entscheidung möglich war. Das war langsam, es band Personen, und die Kosten wuchsen mit der Menge. Diesen Schritt übernimmt jetzt der Dienst, was diese Personen für Arbeit frei macht, bei der sorgfältiges Lesen eines Dokuments tatsächlich zählt. Eine Zahl dazu, was das eingespart hat, steht hier nicht, weil der Kunde das gemessen hat und ich nicht.

Er nennt den Grund

Ein Fehlschlag ist ein Code und eine Begründung, kein leeres Feld.

Wenn die Extraktion kein brauchbares Ergebnis erzeugen kann, scheitert der Durchlauf ausdrücklich, meldet, auf welchen Fehler er gestoßen ist, und lässt sich wiederholen. Das Entwurfsziel war, dass keine Ausgabe schlechter ist als eine falsche Ausgabe in einem System, das eine Kreditentscheidung speist, und die Fehlercodes sind das, was einen erneuten Versuch zu einer informierten Handlung macht statt zu einer hoffnungsvollen.

Was auch immer ankommt

Scans, Fotos, Bilder, gedrehte Seiten, schlechte Handschrift.

Die Verarbeitungsstufe setzt nichts über die Eingangsqualität voraus, weil die Dokumente aus Tausenden einzelner Praxen kommen und nicht aus einem System, das sich vereinheitlichen ließe. Eine Pipeline, die eine saubere Textebene verlangt hätte, hätte die leichte Hälfte automatisiert und die schwere genau dort gelassen, wo sie war.