Docbyte-Facebook-Pixel
Nehmen Sie an der „Docbyte Vault 26.3 Executive Preview“ teil – Donnerstag, 29. Oktober, 12:00–18:00 Uhr, Gent — Eine Einladung anfordern

Ergänzung Ihrer Poststellenlösung um ein LLM: Sollte die IDP-Plattform migriert werden?

[tta_listen_btn]

docbyte-idp-llm-mailroom-ohne-Bedienfelder

Inhaltsverzeichnis

Docbyte arbeitete mit einem großen Versicherungsunternehmen zusammen, um ein großes Sprachmodell (LLM) als Ebene für kontextbezogene Schlussfolgerungen in einen bestehenden Dokumenten-Workflow zu integrieren. Der Workflow selbst blieb dabei unverändert.

Der Versicherer Intelligente Dokumentenverarbeitung Der (IDP)-Workflow bearbeitete bereits eingehende Korrespondenz von Kunden und Maklern, nutzte dabei jedoch eher traditionelle Technologien: cloudbasierte Modelle des maschinellen Lernens in Kombination mit Schlüsselwortregeln. Nichts Außergewöhnliches, aber es funktionierte. Außerdem waren ständige Anpassungen erforderlich, da sich Dokumentformate, Produkte und Terminologie ständig änderten und Dokumenttypen mit hoher Ähnlichkeit nur schwer zuverlässig voneinander zu unterscheiden waren. Den Modellen des maschinellen Lernens fehlte die erforderliche Fähigkeit, Nuancen und Zusammenhänge zu erfassen, die starre Regeln einfach nicht berücksichtigen konnten.

 

Das Problem: Ein Arbeitsablauf, der ständig Aufmerksamkeit erforderte

Der Workflow verarbeitet pro Arbeitstag etwa 50.000 Dokumente. Etwa 97% des eingehenden Materials besteht aus E-Mails von Kunden, Versicherern und Maklern, oft mit mehreren Anhängen, die größtenteils digital erstellt wurden, wobei sich auch einige Scans und handschriftliche Inhalte darunter befinden. Für jedes dieser Dokumente benötigt der Prozess zwei Antworten: Zu welchem bestehenden Schadenfall es gehört und um welche Art von Anfrage es sich handelt.

Es handelt sich also eindeutig um eine Aufgabe der Informationsklassifizierung: die Ermittlung der richtigen Dokumentart, Fallart und Schadensfallnummer. Die Klassifizierung ist schwieriger als die Datenextraktion. Viele IDP-Plattformen bieten lediglich die Extraktion an, da sie der Meinung sind: “Hey, wir müssen doch nur die Schadensfallnummer und ein paar Schlüsselwörter extrahieren!”

Ein falscher Typ, aber die richtige Groß-/Kleinschreibung, führt zu einer schnellen Neuzuordnung. Stimmt die Groß-/Kleinschreibung überhaupt nicht überein, wird das Dokument zur manuellen Überprüfung weitergeleitet, da es keine
eine sichere automatisierte Ausweichlösung dafür. Die Typklassifizierung ist wichtig, stellt jedoch eine sekundäre Kennzahl dar.

Der Versicherer testete den Ansatz zunächst in seinem Geschäftsbereich Kfz-Versicherung: dem umsatzstärksten Geschäftsbereich des Unternehmens und demjenigen mit den komplexesten und am schwersten zu unterscheidenden Dokumenten. Dies wurde bewusst als anspruchsvoller Testfall ausgewählt. Sollte die Schlussfolgerungsebene die Hürde beim schwierigsten Problem des Unternehmens nicht nehmen können, lohnte sich ein weiterer Ausbau nicht.

Das Pilotprojekt umfasste 16 vom Unternehmen definierte Dokumentenklassen: Angebotsanfragen, Angebote und Verträge, Vertragsänderungen, Registrierungen
sowie Kündigungsanträge, Abmeldebescheide, Auskunftsersuchen, Todesfallmeldungen und Insolvenzmitteilungen. Diese sind nicht immer auf den ersten Blick erkennbar
unterschiedliche Vorlagen. Eine Mitteilung über die Abmeldung, bei der ein Kennzeichen entzogen wird, kann auch die Kündigung der zugehörigen Versicherung bedeuten. Es handelt sich hierbei um ein spezifisches Geschäftsereignis und nicht um eine standardmäßige Kündigungsformulierung. Genau diese Art von Mehrdeutigkeit bereitet maschinellen Lernmodellen, die anhand von Schlüsselwörtern und Beispielen trainiert wurden, Schwierigkeiten.

 

Die Ausgangslage: ein System, das immer mehr ins Stocken geriet

Bevor das Team etwas Neues testete, ermittelte es zunächst den aktuellen Stand der Dinge. Das bestehende Modell nutzt OCR als Eingabe und hatte bei dieser Aufgabe zunächst eine Genauigkeit von etwa 60% erreicht, die sich jedoch im Zuge von Abweichungen bei Formaten und Terminologie auf etwa 40% verschlechtert hatte. Ein erneutes Training kam ebenfalls nicht in Frage. Die Dokumenttypen waren nie einheitlich neu beschriftet worden, sodass es keine verlässliche Referenzquelle gab, anhand derer das Modell trainiert werden konnte.

Dieser Rückgang war von größerer Bedeutung als die reine Zahl. Ein Modell, dessen Genauigkeit mit der Zeit nachlässt, verlagert einen größeren Teil der Arbeit auf die manuelle Überprüfung, und diese Verlagerung
verschlimmert sich, je länger das Modell unverändert läuft.

 

Was wurde entwickelt: ein LLM, das auf die bestehende Plattform aufgesetzt wurde

Im Rahmen des Projekts wurde der bestehende Workflow für kontrollierte Dokumente beibehalten und um ein LLM als zusätzliche Schlussfolgerungsebene erweitert. Die Pipeline:

  1. Erfassen Sie die E-Mail und ihre Anhänge, einschließlich gescannter Dokumente.
  2. Wandeln Sie die Eingabe in eine PDF-Darstellung um.
  3. Senden Sie diese zusammen mit den zulässigen Klassifizierungen, Geschäftsdefinitionen und Entscheidungsregeln an das LLM.
  4. Geben Sie die Fallnummer, eine strukturierte Klassifizierung und die vom Modell generierte Erklärung zurück.
  5. Überprüfen Sie das Ergebnis und exportieren Sie es in die Fallbearbeitungsumgebung, wo die eigentlichen Folgemaßnahmen stattfinden.

 

Dem Modell wird keine frei definierbare Aufgabe gestellt. Um das Risiko und die betrieblichen Auswirkungen nicht unterstützter Antworten zu verringern, wird bei jeder Anfrage eine neue, eingeschränkte Sitzung gestartet, und die Klassifizierung muss aus einer geschlossenen Menge zulässiger Werte stammen. Deterministische Dienste steuern weiterhin die Validierung, das Routing, die Speicherung und die Ausführung des Workflows. Diese Eingrenzung ermöglicht es, den Ausgabewerten des Modells zu vertrauen, ohne auf die
das Modell selbst.
Da die Abtretung von Ansprüchen die entscheidende Kennzahl ist, wird sie in der Pipeline entsprechend behandelt: Die extrahierte Fallnummer durchläuft einen deterministischen
Validierungsergebnisse sowie ungültige Ergebnisse werden einer Person zugeordnet, anstatt zwangsweise einer plausibel erscheinenden Zuordnung zugeführt zu werden. Fehler bei der Typeneinstufung werden nachsichtiger behandelt, da deren Behebung mit geringerem Aufwand verbunden ist. Die vom Modell generierte Erklärung wird ebenfalls in der Benutzeroberfläche angezeigt. Auch diese stellt keinen Beweis für die Richtigkeit der Antwort dar, ermöglicht es den mit dem Fall befassten Mitarbeitern jedoch, zu erkennen, warum das Ergebnis so ausgefallen ist, anstatt das Dokument hin und her zu schicken. Dies entspricht mehr oder weniger der Vorgehensweise bei menschlichen Sachbearbeitern, bei der eine Person ein Dokument anders klassifizieren würde als ihr Kollege. Darüber hinaus hilft dies den Implementierungsteams, systematische Fehler zu erkennen und Dokumentdefinitionen zu verfeinern.

 

Aus den Fehlern haben wir etwas Nützliches gelernt

Die offensichtlichste Verwirrung bestand zwischen einer Abmeldung und einer allgemeinen Löschung. Anstatt einen erneuten Trainingszyklus durchzuführen, lässt sich dies durch eine Präzisierung der Klassifizierungsdefinition beheben: Die Abmeldung wird als spezifischer Untertyp der Löschung definiert, der ausdrücklich mit der Entfernung des Kennzeichens verbunden ist. Die Korrektur eines bekannten Fehlermusters erfordert die Anpassung einer Definition und nicht das Training oder Umtrainieren eines Modells.

In einem separaten Test wurde geprüft, ob das LLM bei den Dokumenten, auf die es am meisten ankam – nämlich jenen, die das bestehende ML-Modell bereits falsch eingestuft hatte –, einen Mehrwert lieferte. Das LLM klassifizierte 7% der Dokumente in dieser Teilmenge korrekt, die gerade deshalb ausgewählt worden war, weil das bestehende Modell sie falsch klassifiziert hatte. Dies ist zwar kein direkt vergleichbarer Gesamtvergleich, da die Genauigkeit des bestehenden Modells bei derselben Teilmenge konstruktionsbedingt bei 0% liegt, doch zeigt es, dass die Schlussfolgerungsebene einen bedeutenden Anteil der Fehler des bestehenden Arbeitsablaufs beheben konnte. Dies bedeutet, dass sich die Erfolgsquote für diese Ausnahmen von 0% auf 73% verändert hat.

 

Die bisherigen Ergebnisse

Die nachstehenden Zahlen beziehen sich auf die Klassifizierung nach Dokumenttyp, die sekundäre Kennzahl. Die Fallzuordnung selbst wird nicht auf dieselbe Weise bewertet: Die extrahierte Fallnummer durchläuft entweder eine deterministische Validierung oder nicht, und alle unklaren Fälle werden einer manuellen Überprüfung unterzogen, anstatt als Prozentsatz ausgewiesen zu werden.

Vorgehensweise Genauigkeit
Bestehendes ML-Modell (herabgestuft von ursprünglich ~60%) 40%
LLM (Gemini 2.5 Flash) – vollständiges Testbeispiel 80%

Der Wert von 80% wurde ohne zusätzliches Modelltraining oder Feinabstimmung erreicht, und zwar anhand eines ersten Testdatensatzes, der manuell überprüft und gemeinsam mit den Fachexperten des Versicherers begutachtet wurde. Der Vorteil ergab sich aus der Fähigkeit des Modells, die Beziehungen zwischen Phrasen in einer E-Mail und ihren Anhängen zu gewichten und eine in natürlicher Sprache verfasste geschäftliche Definition anzuwenden, anstatt auf einen proprietären, neu trainierbaren Klassifikator zurückzugreifen.

 

Was dies für das Unternehmen bedeutet

Im Tagesgeschäft verläuft der Arbeitsablauf nun in dreierlei Hinsicht anders.

  • Mehrsprachige Verarbeitung: Die Lösung liefert in jeder Sprache dieselben Ergebnisse, ohne dass für jede Sprache ein eigener Dokumentensatz zum Trainieren des Modells erforderlich ist.
  • Die Verfeinerung von Regeln wird einfacher: Eine bekannte Unklarheit, wie beispielsweise die Überschneidung zwischen Abmeldung und Stornierung, wird durch eine präzisere Definition behoben – nicht durch das erneute Trainieren eines Modells oder das Abwarten eines Release-Zyklus.
  • Die Überprüfung wird transparenter: Die vom Modell generierte Erklärung wird in der Benutzeroberfläche angezeigt, sodass die mit einem Fall befassten Mitarbeiter sehen können, warum der Fall dort gelandet ist, anstatt ihn hin und her weiterleiten zu müssen, um dies herauszufinden.

 

Ein Tipp: Beziehen Sie die Sicherheitsabteilung und den Datenschutzbeauftragten ein, noch bevor die Wirtschaftlichkeitsanalyse abgeschlossen ist.

Ein überzeugendes Geschäftsargument allein reicht nicht aus. Wenn das Unternehmen ein LLM in den Arbeitsablauf integrieren möchte, aber die Sicherheitsabteilung oder der Datenschutzbeauftragte
Sofern nicht festgelegt wurde, wohin die Daten fließen, wie sie aufbewahrt werden und wer darauf zugreifen darf, wird das Projekt nicht umgesetzt – ganz gleich, wie gut die Genauigkeitswerte auch aussehen mögen. Beziehen Sie diese Interessengruppen ein, solange die Architektur noch festgelegt wird, und nicht erst, nachdem ein Pilotprojekt das Konzept bereits bewiesen hat. Genau diese Reihenfolge führt am häufigsten dazu, dass ein funktionierendes Pilotprojekt ins Stocken gerät, bevor es in die Produktion geht: Datenfluss, Aufbewahrungsfristen und Bedingungen für die Datenverarbeitung werden erst dann geprüft, wenn das Konzept bereits funktioniert, anstatt während die Architektur noch offen ist.

Das Design und die anfängliche Entwicklung dauerten etwa drei bis vier Monate. Der Großteil dieser Zeit entfiel auf die Neugestaltung der Pipeline selbst sowie auf
Gespräche mit den Fachabteilungen über Dokumenttypen und die Unterschiede zwischen diesen. Das LLM macht dieses Fachwissen nicht überflüssig. Es erleichtert jedoch dessen Formulierung, Überprüfung und Verfeinerung – und genau diese Arbeit wird derzeit geleistet, um von 80% auf 90% überzugehen.

IDP bietet nach wie vor die Erfassung, Strukturierung und Steuerung, während das LLM darüber hinaus eine kontextbezogene Interpretation hinzufügt. Geschäftsregeln, Validierung und
Es sind die Menschen, die diese Kombination zu einem Prozess machen, auf den man sich verlassen kann. Anstatt sich isoliert auf die Klassifizierungsgenauigkeit zu konzentrieren, ist die entscheidende Kennzahl, wie oft das Dokument bereits beim ersten Versuch dem richtigen Fall zugeordnet wird.

 

Prüfen Sie, wie Ihr Dokumenten-Workflow mit den Fällen umgeht, die nicht in das Schema passen

Wir können Ihnen dabei helfen, zu ermitteln, an welcher Stelle in Ihrem Dokumenten-Workflow eine LLM-Schlussfolgerungsebene den größten Nutzen bringen würde: welche Klassifizierungen mehrdeutig sind, wie eine sichere Ausweichlösung zur manuellen Überprüfung aussieht und wie die Fallvalidierung deterministisch bleibt, während das Modell die Interpretation übernimmt.

 

Häufig gestellte Fragen

Bedeutet die Einführung eines LLM, dass das bestehende IDP-System abgeschafft wird?

Nein. Das LLM wird als Entscheidungsschicht auf den bestehenden Arbeitsablauf aufgesetzt. Die deterministische Validierung, die Weiterleitung und das Fallmanagement steuern weiterhin die nachfolgenden Vorgänge.

Warum sollte man die Fallzuordnung messen und nicht die Gesamtgenauigkeit der Klassifizierung?

Denn die beiden Fehler sind mit unterschiedlichen Kosten verbunden. Ein Dokument, das zwar dem richtigen Fall, aber dem falschen Typ zugeordnet ist, lässt sich schnell neu zuordnen. Ein Dokument, das keinem Fall zugeordnet werden kann, wird zur manuellen Überprüfung weitergeleitet, ohne dass eine automatische Ausweichlösung zur Verfügung steht.

Warum sollten Sie mit dem schwierigsten Dokumentensatz beginnen, anstatt mit dem einfachsten?

Um frühzeitig herauszufinden, ob sich der Ansatz unter realen Bedingungen bewährt, anstatt zunächst nur eine weniger weitreichende These an einem einfacheren Geschäftsbereich zu belegen und die schwierigere Frage offen zu lassen.

Abbildung von Frederik Rosseel
Frederik Rosseel

Guten Tag, ich bin Frederik, Geschäftsführer von Docbyte. Da ich seit Jahren Pionierarbeit im Bereich der digitalen Archivierung und qualifizierter Vertrauensdienste leiste, lasse ich diese unschätzbaren Erfahrungen in meine Texte einfließen. Mein Ziel ist es, Unternehmen dabei zu unterstützen, durch klar verständliche Einblicke eine solide Datensicherheit und eine nahtlose Einhaltung gesetzlicher Vorschriften zu erreichen.

Kontaktieren Sie uns


Bei Docbyte nehmen wir den Schutz Ihrer Daten ernst. Wir verwenden Ihre personenbezogenen Daten ausschließlich zur Verwaltung Ihres Kontos und zur Bereitstellung der von Ihnen angeforderten Produkte und Dienstleistungen.

Haben Sie Interesse daran, einen Beitrag für unseren Blog zu verfassen?
Aktuelle Blogbeiträge