Warum eine Prüfschicht für Dokumentenpipelines mit Sprachmodellen notwendig ist

Sprachmodelle wie Dokumentli® lesen Dokumente inzwischen mit hoher Präzision, so dass das Auslesen von Werten aus Dokumenten selten die eigentliche Herausforderung ist. Das Problem ist die Frage, was mit dem gelesenen Wert geschieht, bevor er in der Buchhaltung, im ERP oder im Archiv landet, und wer dafür geradesteht, wenn er falsch war.

Dieser Artikel beschreibt, welche Funktionen eine Prüfschicht zwischen Modell und Zielsystem abdecken muss, welche Kennzahlen sie liefern muss, damit sie steuerbar bleibt, und mit welchem Aufwand zu rechnen ist, wenn ein Unternehmen sie selbst baut. Er richtet sich an Teams, die ein Sprachmodell bereits produktiv einsetzen oder den Einsatz vorbereiten. Die Umsetzung in der Parashift Plattform dient als Referenz, nicht per se als Empfehlung.

Ausgangslage

Ein Sprachmodell liefert zu jedem Dokument eine Antwort, und zwar auch dann, wenn die Vorlage unvollständig ist, schief eingezogen wurde oder von einem Typ ist, mit dem in diesem Prozess niemand gerechnet hat.

Die Antwort ist in aller Regel sauber formatiert und inhaltlich plausibel. Ob sie zutrifft, lässt sich ihr nicht entnehmen, weil das Modell keinen Unterschied zwischen einer sicheren und einer geratenen Angabe ausweist, sofern man ihn nicht eigens erhebt.

Ein Beispiel aus einem Test auf unserem Playground. Auf einem Lieferschein war die gedruckte Menge von 60 Stück durchgestrichen und von Hand auf 48 korrigiert, die gedruckte Zeilensumme bezog sich aber weiterhin auf die ursprünglichen 60. Das Modell hat die handschriftliche Korrektur erkannt und 48 ausgegeben, und zwar mit hoher Konfidenz, weil die Ziffer gut lesbar war.

Der Wert war damit richtig gelesen, und das Dokument rechnete trotzdem nicht mehr auf, weil die Positionszeile der ausgewiesenen Summe widersprach. Dieser Widerspruch taucht in keinem Konfidenzwert auf, denn die Konfidenz sagt etwas über die Lesbarkeit der Ziffer aus und nichts über die Konsistenz des Dokuments.

In einer Recherche sind solche Fälle hinnehmbar, in einer Kreditorenrechnung, die in den Zahllauf geht, nicht, weil dort eine Differenz von zwölf Stück zu einer Fehlbuchung führt und nicht zu einer unglücklichen Formulierung.

Jede Pipeline, die produktiv läuft, braucht deshalb eine Instanz, die jede Modellausgabe entgegennimmt, nach festgelegten Kriterien bewertet und anschliessend entweder zur Weiterverarbeitung freigibt oder zur Prüfung eskaliert.

Anforderungen

Die erste Anforderung ist ein Konfidenzwert je Feld. Ein einzelner Wert über das ganze Dokument hilft nicht weiter, weil ein Dokument aus Feldern mit sehr unterschiedlicher Lesbarkeit besteht und ein gut gedruckter Rechnungskopf dieselbe Bewertung erhielte wie eine handschriftliche Korrektur in der Positionszeile darunter.

Die zweite Anforderung sind Schwellen, die sich je Feld und je Mandant getrennt setzen lassen, weil ein Rechnungsbetrag eine andere Absicherung verlangt als ein Ansprechpartner und weil eine Versicherung ihre Dokumente anders behandelt als ein Logistiker. Wo die Schwelle liegt, ist eine betriebswirtschaftliche Entscheidung über das Verhältnis von Prüfaufwand zu Fehlerkosten und keine technische Konstante.

Die dritte Anforderung sind Regeln, die über das einzelne Feld hinausgreifen, also Format- und Pflichtfeldprüfungen ebenso wie Summenprüfungen, Dublettenprüfung, Kreditorenabgleich und den Abgleich gegen Bestellung, Wareneingang und Stammdaten. Ein Modell kann die ausgewiesene Rechnungssumme vollkommen korrekt lesen und trotzdem ein Ergebnis liefern, dessen Positionen sich nicht zu dieser Summe addieren, und genau diese Fälle fallen nur auf, wenn jemand sie rechnet.

Die vierte Anforderung ist ein Routing, das alles, was Schwellen und Regeln passiert, ohne Zutun weiterleitet und alles Übrige in eine Prüfoberfläche stellt, in der ausschliesslich die beanstandeten Felder zur Entscheidung stehen. Wenn an dieser Stelle das vollständige Dokument erneut erfasst werden muss, ist der Zeitgewinn aus der Automatisierung wieder aufgebraucht.

Die fünfte Anforderung ist ein Protokoll, aus dem für jedes Feld hervorgeht, welcher Wert gelesen wurde, mit welcher Konfidenz, an welcher Fundstelle im Dokument, gegen welche Spezifikationsversion und welche Regeln geprüft, von wem gegebenenfalls korrigiert und wann freigegeben. Ohne diese Aufzeichnung lässt sich der Prozess weder gegenüber einer Revision noch gegenüber einem Kunden belegen.

Umsetzung in der Parashift Plattform

Die Parashift Plattform bildet diese fünf Punkte als Standardfunktionen ab, sodass sie konfiguriert und nicht entwickelt werden.

Konfidenzwerte entstehen je Feld, und die zugehörigen Schwellen lassen sich je Feld und je Mandant einstellen, womit das konfidenzbasierte Routing die Dunkelverarbeitung von den Prüffällen trennt.

Die Validierungsregeln decken Format, Pflichtfelder, Summen, Dubletten, Kreditoren sowie Abgleiche gegen angebundene Systeme ab, und was sie nicht passiert, landet in einer eingebetteten Validierungsoberfläche, die wahlweise der Kunde selbst betreibt oder Parashift mit vereinbarter Durchlaufzeit übernimmt.

Freigabeworkflows bilden mehrstufige Kontrollen ab, wobei Agent in the Loop und Human in the Loop zwei Konfigurationen desselben Mechanismus sind und sich je Dokumententyp unterschiedlich setzen lassen.

OneTouchLearning® führt Korrekturen als Learning zurück, der Audit Trail hält Spezifikationsversion, Fundstelle und Bearbeitungsverlauf fest, und über «Bring your own Model» lassen sich sämtliche Modelle einbinden, sofern sie der OpenAI API Spezifikation entsprechen.

Die Plattform ist durchgehend API first aufgebaut, mandantenfähig und bringt über 30 Konnektoren zu den gängigen Ziel- und Quellsystemen mit.

Weitergehende Automatisierung mit Agenten am Dokument

Die Prüfschicht ist die Voraussetzung für den nächsten Automatisierungsschritt und nicht dessen Ersatz, denn sobald Konfidenz, Regeln und Protokoll stehen, lassen sich Agenten unmittelbar am Dokument einsetzen, ohne dass die Kontrolle über das Ergebnis verloren geht.

Ein solcher Agent kann bei einer gescheiterten Regel die fehlende Angabe im Quellsystem nachschlagen, bei einer Abweichung zwischen Rechnung und Bestellung die Differenz klassifizieren und einer Toleranz zuordnen oder bei unklarem Dokumententyp die fehlenden Seiten anfordern, statt den Fall unbearbeitet in die manuelle Prüfung zu geben.

Entscheidend ist, dass jeder dieser Agenten gegen dieselben Schwellen arbeitet und in dasselbe Protokoll schreibt wie die Extraktion selbst, weil sich die Grenze der Dunkelverarbeitung nur dann nach oben verschieben lässt, ohne dass die Nachvollziehbarkeit darunter leidet.

Ohne Prüfschicht ist dieser Schritt nicht sinnvoll, weil ein Agent ohne Schwellen und ohne Protokoll ein zweites System ist, das plausible Antworten erzeugt, und damit das Ausgangsproblem vervielfacht, statt es zu lösen.

Eigenbau gegen bestehende Plattform

Die Entscheidung zwischen Eigenbau und Plattform fällt selten an der ersten Version, denn eine Konfidenzlogik mit Schwellen und einer einfachen Prüfmaske steht in wenigen Wochen und funktioniert für den ersten Dokumententyp erfahrungsgemäss gut.

Der Aufwand entsteht in allem, was danach kommt, nämlich Mandantentrennung, Rollen und Rechte, revisionssichere Protokollierung, Wiederaufnahme nach Abbruch, Massenkorrekturen, Konnektoren zu jedem weiteren Zielsystem, der Betrieb der Prüfoberfläche über die gesamte Arbeitszeit sowie die Rückführung der Korrekturen in das Modell.

Was hier entsteht, ist kein Feature, sondern ein eigenes Produkt mit laufender Wartung, und wer es selbst baut, bindet dauerhaft Entwicklungskapazität an einen Teil der Wertschöpfung, mit dem er sich gegenüber dem Wettbewerb nicht unterscheidet.

Der Eigenbau rechtfertigt sich jedoch dort, wo die fachlichen Regeln so spezifisch sind, dass sie sich in keiner Standardkonfiguration abbilden lassen, und diese Konstellation kommt vor, nur sollte man sie belegen, bevor man sich darauf festlegt.

Kennzahlen für den Betrieb

Die Dunkelverarbeitungsquote zeigt, welcher Anteil der Dokumente ohne manuellen Eingriff durchläuft, und ist die Grösse, an der sich der wirtschaftliche Effekt der gesamten Pipeline bemisst.

Die Fehlerquote nach Freigabe zeigt, ob die Schwellen zu locker stehen, und lässt sich nur erheben, wenn Stichproben aus dem automatisch freigegebenen Bestand gezogen werden statt aus dem geprüften.

Die Prüfquote je Feld zeigt, welche Felder den manuellen Aufwand tatsächlich verursachen, und führt in der Praxis regelmässig dazu, dass eine Handvoll Felder für den grössten Teil der Bearbeitungszeit verantwortlich ist.

Die Durchlaufzeit im Prüfschritt zeigt, ob die Oberfläche und die dahinterstehende Organisation für die anfallenden Mengen ausgelegt sind, und ist der erste Wert, der kippt, wenn das Volumen steigt.

Ohne diese vier Grössen lässt sich keine Schwelle begründen, mit ihnen wird ihre Einstellung zu einer Abwägung zwischen Prüfaufwand und Fehlerkosten, die sich in Zahlen ausdrücken und gegenüber der Geschäftsleitung vertreten lässt.

Modellwechsel

Modelle werden in kurzen Abständen ersetzt, die Prüflogik dagegen bleibt über Jahre dieselbe, weshalb Schwellen, Regeln und Protokoll in die Anwendung gehören und nicht in den Modellaufruf.

Wer das beachtet, kann ein Modell gegen ein anderes tauschen, ohne den Prozess neu zu bauen, und der Vergleich zweier Modelle wird zu einer Messung auf denselben Kennzahlen statt zu einem Projekt mit eigener Laufzeit.

Grenzen

Die Schicht erkennt zuverlässig, was gegen eine hinterlegte Regel verstösst, und sie erkennt nicht, was plausibel und zugleich falsch ist, weshalb ein korrekt gelesener Betrag an der falschen Position unentdeckt bleibt, solange keine Regel diese Position adressiert.

Ein hoher Konfidenzwert besagt, dass das Modell sicher ist, und nicht, dass es recht hat, und diese beiden Aussagen fallen in der Praxis häufiger auseinander, als die Zahl vermuten lässt.

Die Schwellen verschieben das Verhältnis zwischen übersehenen Fehlern und unnötig geprüften Dokumenten, sie beseitigen aber weder das eine noch das andere, und wer sie einstellt, entscheidet sich für eine Verteilung und nicht für deren Abschaffung.

Der stärkste Einwand

Gegen alles bisher Gesagte lässt sich einwenden, dass Schwellwerte und Regeln die Automatisierung genau dort ausbremsen, wo sie wirken soll, und dass ein Prozess mit vierzig Validierungsregeln am Ende mehr Menschen beschäftigt als der manuelle Prozess, den er ersetzen sollte.

Der Einwand trifft zu, und er trifft vor allem in der Pilotphase, in der niemand weiss, welche Felder tatsächlich fehleranfällig sind, und in der jede zusätzliche Regel auf einer Vermutung beruht statt auf einer Messung.

Daraus folgt allerdings nicht, auf die Prüfschicht zu verzichten, sondern sie leer zu starten, also mit Konfidenz und Protokoll, aber ohne ausgebautes Regelwerk, und die Regeln erst dort zu ergänzen, wo die Messung einen wiederkehrenden Fehler zeigt. Wer umgekehrt vorgeht, baut ein Regelwerk gegen Fehler, die es in seinen Dokumenten oft nicht gibt.

Einstieg

Beginnen Sie mit einem Dokumententyp und einer überschaubaren Zahl von Feldern, und setzen Sie die Schwellen zunächst bewusst hoch, sodass ein grosser Teil in die manuelle Prüfung läuft und Sie sehen, wo die Fehler tatsächlich liegen.

Messen Sie zwei bis vier Wochen, senken Sie anschliessend die Schwellen dort, wo die Prüfung nichts beanstandet hat, und schärfen Sie die Regeln dort, wo sie etwas gefunden hat.

Nehmen Sie den nächsten Dokumententyp erst auf, wenn der erste stabil läuft, weil sich sonst nicht mehr feststellen lässt, welche Änderung welche Wirkung hatte.

Fazit

Der Einsatz von Sprachmodellen in der Dokumentenverarbeitung scheitert selten an der Extraktion und regelmässig an der Frage, was mit dem Ergebnis geschehen soll, bevor es in ein führendes System geschrieben wird.

Die Prüfschicht entscheidet darüber, ob eine Pipeline produktiv tauglich ist, und sie ist zugleich der Teil, der in Projekten am häufigsten zu spät geplant wird, weil er in der Pilotphase nicht weh tut.

Wer sie früh definiert, also Konfidenz, Regeln, Routing und Protokoll festlegt, bevor der erste Dokumententyp in Betrieb geht, erhält eine Pipeline, deren Qualität messbar und deren Modell austauschbar ist, und schafft zugleich die Grundlage dafür, Agenten nahe am Dokument einzusetzen.