OCR im großen Stil – Briefpost als Datenfundament für Machine-Learning-Projekte

Der Provinzial NordWest Konzern ist Teil der Sparkassen-Finanzgruppe und einer der größten öffentlichen Versicherungskonzerne in Deutschland.

230 T

verarbeitete Seiten pro Tag zu Spitzenzeiten

70%

Erkennungsrate für mehr als 90 % der Dokumente

Open Source Tools reduzieren die Kosten auf den Betrieb

Hohe Ergebnisqualität als Basis für weitere KI-Projekte

Ausgangssituation

Der Provinzial NordWest Versicherungskonzern ist in Schleswig-Holstein, Mecklenburg-Vorpommern, Hamburg und Westfalen für seine Kunden vor Ort: Von Westerland bis Rügen und von Viöl bis Hamburg-Harburg reicht das Netz der 220 Versicherungsfachgeschäfte der Provinzial Nord, in Westfalen ist die Westfälische Provinzial zwischen Bocholt und Höxter mit 438 Geschäftsstellen vertreten.

Die PNW digitalisiert schon seit Jahren die Eingangspost (Papier, Fax, Mail) und legt die eingescannten Dokumente digital im Bildformat „TIFF” ab. Aufgrund von Kosten und Rechenlast wurde bisher lediglich die erste Seite einer Dokumentenmappe durch OCR erkannt und zur Klassifikation herangezogen. Ende 2018 wurde das Projekt „Sherlock” ins Leben gerufen. Zunächst als Proof of Concept entwickelt, hatte Sherlock das Ziel, die gesamte Eingangspost als Volltext durchsuchbar abzulegen.

Die PNW verarbeitet täglich weit über 100.000 Seiten aus Briefen und E-Mail-Dokumenten. Grundvoraussetzung von Sherlock war es, diese Last binnen 24 Stunden zu verarbeiten und damit eine tagesaktuelle Datenbasis über die gesamte Eingangspost für Volltextsuchen aus dem CRM bereitzustellen.

Die Lösung

Das Projekt stellt gleich eine ganze Reihe neuer Anforderungen an die interne Software-Entwicklung und den IT-Betrieb. Der Einsatz moderner, aber heterogener Technologien, wie OpenCV, Tesseract, TensorFlow und Keras, erfordert ein hohes Maß an Flexibilität hinsichtlich Entwicklung, Build und Deployment. Um insbesondere in den letzteren Punkten einen gemeinsamen Standard zu schaffen, werden die einzelnen Services von Sherlock in Docker-Containern betrieben.

Zum aktuellen Zeitpunkt besteht Sherlock aus neun, lose durch Queues gekoppelte Services, die über die Anzahl ihrer Container individuell skaliert werden können. Das ist insbesondere aufgrund der hohen Last zu bestimmten Kernzeiten, wie am frühen Vormittag oder abends, wichtig. Jeder Service führt Tagebuch über seine aktuellen Durchlaufzeiten. Ein Tesseract-Service benötigt zum Beispiel im Durchschnitt zehn Sekunden pro Seite, während hingegen das Pre-processing, wie Säubern und Hochskalieren, in unter einer Sekunde erledigt ist. Durch die Microservice-Architektur kann Sherlock auf dieses Ungleichgewicht ausgerichtet werden.

Um die Texterkennung zu entlasten, werden die Seiten mithilfe eines trainierten, tiefen neuronalen Netzes in Text und Bilddokumente unterteilt. Damit lassen sich bereits zu Beginn größere TIFF-Dateien herausfiltern, die ohnehin keinen Text enthalten. Die Erkennungsrate wird zur Laufzeit anhand eines großen Wörterbuchs in Elasticsearch abgeglichen und gemessen. Elasticsearch stellt im selben Zug auch einen Mechanismus für Wortvorschläge bereit, mit dem Sherlock Fehler in der Erkennung noch einmal ausgleicht. In Elasticsearch werden die Volltexte anschließend auch persistiert und bereitgestellt.

Das Ergebnis

Sherlock hat zu Peak-Zeiten 230.000 Seiten pro Tag abgearbeitet. Die Erkennungsraten liegen dabei bei über 70 Prozent für 90 Prozent der eingehenden Dokumente. Hinzu kommen richtig erkannte Eigennamen, die nicht im Wörterbuch enthalten sind. Das System ist seit September produktiv und hat bereits über 12 Millionen Seiten persistiert, die dem CRM-System mit einer Volltextsuche zur Verfügung stehen.

Außerdem sind bereits neue Projekte auf dem Weg, die auf den Daten aufsetzen. Die Projekte reichen über neue Verfahren zur Dokumentenklassifikation mit Machine-Learning-Modellen bis hin zur Intentionserkennung im Schriftverkehr mit den Kunden. Neben den Ergebnissen des Projekts und den Folgeprojekten im KI- und Data-Science Bereich wurden auch Erfahrungen im Betrieb von Docker und heterogenen Architekturen gemacht. Mithilfe der Container stellt der Betrieb der Anwendung keinen hohen Aufwand dar und ebnet den Weg für eine heterogene Anwendungslandschaft und damit auch für neue Tools und Möglichkeiten.

Ihr Ansprechpartner

Mark Keinhörster
Data Engineer

Kontakt aufnehmen

Jetzt Kontakt aufnehmen

Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden. Weitere Informationen

Hinweis: In Ihrem Browser ist JavaScript deaktiviert. Für eine bessere und fehlerfreie Nutzung dieser Webseite, aktivieren Sie bitte JavaScript in Ihrem Browser.