{"id":61265,"date":"2026-10-09T05:00:12","date_gmt":"2026-10-09T05:00:12","guid":{"rendered":"https:\/\/parashift.ai\/?p=61265"},"modified":"2026-10-09T05:04:08","modified_gmt":"2026-10-09T05:04:08","slug":"pruefschicht-dokumentenpipelines-sprachmodelle","status":"publish","type":"post","link":"https:\/\/parashift.ai\/de\/pruefschicht-dokumentenpipelines-sprachmodelle\/","title":{"rendered":"Warum eine Pr\u00fcfschicht f\u00fcr Dokumentenpipelines mit Sprachmodellen notwendig ist"},"content":{"rendered":"

Sprachmodelle wie Dokumentli\u00ae<\/a> lesen Dokumente inzwischen mit hoher Pr\u00e4zision, 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\u00fcr geradesteht, wenn er falsch war.<\/p>\n

Dieser Artikel beschreibt, welche Funktionen eine Pr\u00fcfschicht 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.<\/p>\n

Ausgangslage<\/h2>\n

Ein Sprachmodell liefert zu jedem Dokument eine Antwort, und zwar auch dann, wenn die Vorlage unvollst\u00e4ndig ist, schief eingezogen wurde oder von einem Typ ist, mit dem in diesem Prozess niemand gerechnet hat.<\/p>\n

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

Ein Beispiel aus einem Test auf unserem Playground<\/a>. Auf einem Lieferschein war die gedruckte Menge von 60 St\u00fcck durchgestrichen und von Hand auf 48 korrigiert, die gedruckte Zeilensumme bezog sich aber weiterhin auf die urspr\u00fcnglichen 60. Das Modell hat die handschriftliche Korrektur erkannt und 48 ausgegeben, und zwar mit hoher Konfidenz, weil die Ziffer gut lesbar war.<\/p>\n

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 \u00fcber die Lesbarkeit der Ziffer aus und nichts \u00fcber die Konsistenz des Dokuments.<\/p>\n

In einer Recherche sind solche F\u00e4lle hinnehmbar, in einer Kreditorenrechnung<\/a>, die in den Zahllauf geht, nicht, weil dort eine Differenz von zw\u00f6lf St\u00fcck zu einer Fehlbuchung f\u00fchrt und nicht zu einer ungl\u00fccklichen Formulierung.<\/p>\n

Jede Pipeline, die produktiv l\u00e4uft, braucht deshalb eine Instanz, die jede Modellausgabe entgegennimmt, nach festgelegten Kriterien bewertet und anschliessend entweder zur Weiterverarbeitung freigibt oder zur Pr\u00fcfung eskaliert.<\/p>\n

Anforderungen<\/h2>\n

Die erste Anforderung ist ein Konfidenzwert je Feld. Ein einzelner Wert \u00fcber 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.<\/p>\n

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 \u00fcber das Verh\u00e4ltnis von Pr\u00fcfaufwand zu Fehlerkosten und keine technische Konstante.<\/p>\n

Die dritte Anforderung sind Regeln, die \u00fcber das einzelne Feld hinausgreifen, also Format- und Pflichtfeldpr\u00fcfungen ebenso wie Summenpr\u00fcfungen, Dublettenpr\u00fcfung, 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\u00e4lle fallen nur auf, wenn jemand sie rechnet.<\/p>\n

Die vierte Anforderung ist ein Routing, das alles, was Schwellen und Regeln passiert, ohne Zutun weiterleitet und alles \u00dcbrige in eine Pr\u00fcfoberfl\u00e4che stellt, in der ausschliesslich die beanstandeten Felder zur Entscheidung stehen. Wenn an dieser Stelle das vollst\u00e4ndige Dokument erneut erfasst werden muss, ist der Zeitgewinn aus der Automatisierung wieder aufgebraucht.<\/p>\n

Die f\u00fcnfte Anforderung ist ein Protokoll, aus dem f\u00fcr jedes Feld hervorgeht, welcher Wert gelesen wurde, mit welcher Konfidenz, an welcher Fundstelle im Dokument, gegen welche Spezifikationsversion und welche Regeln gepr\u00fcft, von wem gegebenenfalls korrigiert und wann freigegeben. Ohne diese Aufzeichnung l\u00e4sst sich der Prozess weder gegen\u00fcber einer Revision noch gegen\u00fcber einem Kunden belegen.<\/p>\n

Umsetzung in der Parashift Plattform<\/h2>\n

Die Parashift Plattform<\/a> bildet diese f\u00fcnf Punkte als Standardfunktionen ab, sodass sie konfiguriert und nicht entwickelt werden.<\/p>\n

Konfidenzwerte entstehen je Feld, und die zugeh\u00f6rigen Schwellen lassen sich je Feld und je Mandant einstellen, womit das konfidenzbasierte Routing die Dunkelverarbeitung von den Pr\u00fcff\u00e4llen trennt.<\/p>\n

Die Validierungsregeln decken Format, Pflichtfelder, Summen, Dubletten, Kreditoren sowie Abgleiche gegen angebundene Systeme ab, und was sie nicht passiert, landet in einer eingebetteten Validierungsoberfl\u00e4che, die wahlweise der Kunde selbst betreibt oder Parashift mit vereinbarter Durchlaufzeit \u00fcbernimmt.<\/p>\n

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.<\/p>\n

OneTouchLearning\u00ae f\u00fchrt Korrekturen als Learning zur\u00fcck, der Audit Trail h\u00e4lt Spezifikationsversion, Fundstelle und Bearbeitungsverlauf fest, und \u00fcber \u00abBring your own Model\u00bb lassen sich s\u00e4mtliche Modelle einbinden, sofern sie der OpenAI API Spezifikation entsprechen.<\/p>\n

Die Plattform ist durchgehend API first aufgebaut, mandantenf\u00e4hig und bringt \u00fcber 30 Konnektoren zu den g\u00e4ngigen Ziel- und Quellsystemen<\/a> mit.<\/p>\n

Weitergehende Automatisierung mit Agenten am Dokument<\/h2>\n

Die Pr\u00fcfschicht ist die Voraussetzung f\u00fcr den n\u00e4chsten Automatisierungsschritt und nicht dessen Ersatz, denn sobald Konfidenz, Regeln und Protokoll stehen, lassen sich Agenten unmittelbar am Dokument einsetzen, ohne dass die Kontrolle \u00fcber das Ergebnis verloren geht.<\/p>\n

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\u00fcfung zu geben.<\/p>\n

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\u00e4sst, ohne dass die Nachvollziehbarkeit darunter leidet.<\/p>\n

Ohne Pr\u00fcfschicht 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\u00f6sen.<\/p>\n

Eigenbau gegen bestehende Plattform<\/h2>\n

Die Entscheidung zwischen Eigenbau und Plattform f\u00e4llt selten an der ersten Version, denn eine Konfidenzlogik mit Schwellen und einer einfachen Pr\u00fcfmaske steht in wenigen Wochen und funktioniert f\u00fcr den ersten Dokumententyp erfahrungsgem\u00e4ss gut.<\/p>\n

Der Aufwand entsteht in allem, was danach kommt, n\u00e4mlich Mandantentrennung, Rollen und Rechte, revisionssichere Protokollierung, Wiederaufnahme nach Abbruch, Massenkorrekturen, Konnektoren zu jedem weiteren Zielsystem, der Betrieb der Pr\u00fcfoberfl\u00e4che \u00fcber die gesamte Arbeitszeit sowie die R\u00fcckf\u00fchrung der Korrekturen in das Modell.<\/p>\n

Was hier entsteht, ist kein Feature, sondern ein eigenes Produkt mit laufender Wartung, und wer es selbst baut, bindet dauerhaft Entwicklungskapazit\u00e4t an einen Teil der Wertsch\u00f6pfung, mit dem er sich gegen\u00fcber dem Wettbewerb nicht unterscheidet.<\/p>\n

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.<\/p>\n

Kennzahlen f\u00fcr den Betrieb<\/h2>\n

Die Dunkelverarbeitungsquote zeigt, welcher Anteil der Dokumente ohne manuellen Eingriff durchl\u00e4uft, und ist die Gr\u00f6sse, an der sich der wirtschaftliche Effekt der gesamten Pipeline bemisst.<\/p>\n

Die Fehlerquote nach Freigabe zeigt, ob die Schwellen zu locker stehen, und l\u00e4sst sich nur erheben, wenn Stichproben aus dem automatisch freigegebenen Bestand gezogen werden statt aus dem gepr\u00fcften.<\/p>\n

Die Pr\u00fcfquote je Feld zeigt, welche Felder den manuellen Aufwand tats\u00e4chlich verursachen, und f\u00fchrt in der Praxis regelm\u00e4ssig dazu, dass eine Handvoll Felder f\u00fcr den gr\u00f6ssten Teil der Bearbeitungszeit verantwortlich ist.<\/p>\n

Die Durchlaufzeit im Pr\u00fcfschritt zeigt, ob die Oberfl\u00e4che und die dahinterstehende Organisation f\u00fcr die anfallenden Mengen ausgelegt sind, und ist der erste Wert, der kippt, wenn das Volumen steigt.<\/p>\n

Ohne diese vier Gr\u00f6ssen l\u00e4sst sich keine Schwelle begr\u00fcnden, mit ihnen wird ihre Einstellung zu einer Abw\u00e4gung zwischen Pr\u00fcfaufwand und Fehlerkosten, die sich in Zahlen ausdr\u00fccken und gegen\u00fcber der Gesch\u00e4ftsleitung vertreten l\u00e4sst.<\/p>\n

Modellwechsel<\/h2>\n

Modelle werden in kurzen Abst\u00e4nden ersetzt, die Pr\u00fcflogik dagegen bleibt \u00fcber Jahre dieselbe, weshalb Schwellen, Regeln und Protokoll in die Anwendung geh\u00f6ren und nicht in den Modellaufruf.<\/p>\n

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

Grenzen<\/h2>\n

Die Schicht erkennt zuverl\u00e4ssig, was gegen eine hinterlegte Regel verst\u00f6sst, 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.<\/p>\n

Ein hoher Konfidenzwert besagt, dass das Modell sicher ist, und nicht, dass es recht hat, und diese beiden Aussagen fallen in der Praxis h\u00e4ufiger auseinander, als die Zahl vermuten l\u00e4sst.<\/p>\n

Die Schwellen verschieben das Verh\u00e4ltnis zwischen \u00fcbersehenen Fehlern und unn\u00f6tig gepr\u00fcften Dokumenten, sie beseitigen aber weder das eine noch das andere, und wer sie einstellt, entscheidet sich f\u00fcr eine Verteilung und nicht f\u00fcr deren Abschaffung.<\/p>\n

Der st\u00e4rkste Einwand<\/h2>\n

Gegen alles bisher Gesagte l\u00e4sst 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\u00e4ftigt als der manuelle Prozess, den er ersetzen sollte.<\/p>\n

Der Einwand trifft zu, und er trifft vor allem in der Pilotphase, in der niemand weiss, welche Felder tats\u00e4chlich fehleranf\u00e4llig sind, und in der jede zus\u00e4tzliche Regel auf einer Vermutung beruht statt auf einer Messung.<\/p>\n

Daraus folgt allerdings nicht, auf die Pr\u00fcfschicht zu verzichten, sondern sie leer zu starten, also mit Konfidenz und Protokoll, aber ohne ausgebautes Regelwerk, und die Regeln erst dort zu erg\u00e4nzen, wo die Messung einen wiederkehrenden Fehler zeigt. Wer umgekehrt vorgeht, baut ein Regelwerk gegen Fehler, die es in seinen Dokumenten oft nicht gibt.<\/p>\n

Einstieg<\/h2>\n

Beginnen Sie mit einem Dokumententyp und einer \u00fcberschaubaren Zahl von Feldern, und setzen Sie die Schwellen zun\u00e4chst bewusst hoch, sodass ein grosser Teil in die manuelle Pr\u00fcfung l\u00e4uft und Sie sehen, wo die Fehler tats\u00e4chlich liegen.<\/p>\n

Messen Sie zwei bis vier Wochen, senken Sie anschliessend die Schwellen dort, wo die Pr\u00fcfung nichts beanstandet hat, und sch\u00e4rfen Sie die Regeln dort, wo sie etwas gefunden hat.<\/p>\n

Nehmen Sie den n\u00e4chsten Dokumententyp erst auf, wenn der erste stabil l\u00e4uft, weil sich sonst nicht mehr feststellen l\u00e4sst, welche \u00c4nderung welche Wirkung hatte.<\/p>\n

Fazit<\/h2>\n

Der Einsatz von Sprachmodellen in der Dokumentenverarbeitung scheitert selten an der Extraktion<\/a> und regelm\u00e4ssig an der Frage, was mit dem Ergebnis geschehen soll, bevor es in ein f\u00fchrendes System geschrieben wird.<\/p>\n

Die Pr\u00fcfschicht entscheidet dar\u00fcber, ob eine Pipeline produktiv tauglich ist, und sie ist zugleich der Teil, der in Projekten am h\u00e4ufigsten zu sp\u00e4t geplant wird, weil er in der Pilotphase nicht weh tut.<\/p>\n

Wer sie fr\u00fch definiert, also Konfidenz, Regeln, Routing und Protokoll festlegt, bevor der erste Dokumententyp in Betrieb geht, erh\u00e4lt eine Pipeline, deren Qualit\u00e4t messbar und deren Modell austauschbar ist, und schafft zugleich die Grundlage daf\u00fcr, Agenten nahe am Dokument einzusetzen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Sprachmodelle lesen Dokumente gut genug. Offen ist, was mit dem gelesenen Wert geschieht, bevor er in ERP, Buchhaltung oder Archiv landet. Welche Funktionen eine Pr\u00fcfschicht abdecken muss, welche Kennzahlen sie liefern muss und was der Eigenbau kostet.<\/p>\n","protected":false},"author":1,"featured_media":61282,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[128],"tags":[],"class_list":["post-61265","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-parashift-platform-2"],"_links":{"self":[{"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/posts\/61265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/comments?post=61265"}],"version-history":[{"count":8,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/posts\/61265\/revisions"}],"predecessor-version":[{"id":61280,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/posts\/61265\/revisions\/61280"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/media\/61282"}],"wp:attachment":[{"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/media?parent=61265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/categories?post=61265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/parashift.ai\/de\/wp-json\/wp\/v2\/tags?post=61265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}