Freiform-Erkennung für Posteingangs-Dokumente: Produktive Lösungen durch Qualitätsmanagement

Input-Management, Scannen, Posteingang, Information Capture, OCR, Freeform-Recognition

Herausgeber: DOK Magazin

Ausgabe: Februar 2011

Autor: Christian Böhnel

Bei der Digitalisierung von Dokumenten, z.B. des Posteingangs, wirft die Einführung eines entsprechenden Workflows eine Reihe von Fragen auf. Denn vor allem die manuelle Verschlagwortung von gescannten Dokumenten ist ein aufwändiges Verfahren: Jedes Dokument muss einzeln gesichtet und bewertet werden, bevor die beschreibenden Metadaten manuell erfasst werden können. Dass dies viel Zeit und Geld kostet, liegt auf der Hand. Ein weiterer, gewichtiger Nachteil dieses Verfahrens ist, dass die Qualität der erfassten Daten stark abhängig von der Motivation und der Erfahrung der am Prozess beteiligten Mitarbeiter ist.

Lesen Sie nun den kompletten Artikel oder laden Sie sich die kostenlose Ausgabe als Download herunter.

Im Vergleich zur manuellen Erfassung versprechen Dokumenten-Erkennungssysteme (OCR/ICR) Verbesserungen hinsichtlich des Durchsatzes, der Qualität und insbesondere der Wirtschaftlichkeit. Vor allem auch deswegen, weil sich das Leistungsspektrum der verfügbaren Produkte in den letzten 15 Jahren deutlich ausgeweitet hat von einer rein formularorientierten hin zu einer Freiform-Erkennung von unstrukturierten Dokumenten, also einer Erkennung ohne vorherige Kenntnis von Layout und Struktur. Das ist auch der Grund, warum sich ihr Einsatzbereich mittlerweile bis in den Posteingang von Versicherungen und Banken erstreckt.

Systematische Implementierung ist Voraussetzung

An die Einführung eines Erkennungssystems sind gewöhnlich hohe Erwartungen geknüpft. Nicht zuletzt durch pauschale, vertrieblich motivierte Aussagen von Herstellern und Integratoren hinsichtlich der Leistungsfähigkeit ihrer Produkte wird die Hoffnung geschürt, schon eine reine Installation der Software sei die einzige Voraussetzung, um in der Posteingangsbearbeitung Ineffizienz in Effizienz umzuwandeln und hohe Einsparpotentiale zu realisieren. Insbesondere Produkte für die Technologie Freiform-Erkennung im Posteingang kranken an diesem Umstand – und nicht selten werden derartige Erwartungen in der Praxis nicht erfüllt. Allerdings liegt die Ursache meist nicht in der mangelnden Leistungsfähigkeit der Produkte selbst, sondern in der ungenügenden Beauftragung oder Durchführung der Implementierung. Im Folgenden möchten wir daher eine allgemeine und produktneutrale Darstellung geben, welche Methodik ein Projekt der Freiformerkennung umfassen sollte, um einen möglichst hohen Nutzen aus der Einführung eines solchen Systems zu ziehen und diesen dauerhaft zu erhalten.

Aufbau von Freiformerkennungs-Systemen

Das Ziel des Einsatzes eines Dokumenten-Erkennungssystems ist die Ermittlung von Metadaten aus elektronischen Bildern (die gescannten Seiten der zu verarbeitenden Dokumente) und die Übergabe an ein nachgelagertes System (z.B. eine Postkorbanwendung). Das dazu notwendige System zur Freiform- Erkennung besteht dabei immer aus mindestens drei Bestandteilen:

Der reinen Schrifterkennung (OCR), bei der aus den Pixeln des Bitmaps ein so genannter Volltext erzeugt wird, gegebenenfalls angereichert um strukturelle Informationen.
Eine auf dem Volltext aufbauende Interpretation des Ergebnisses, also des textuellen Inhalts. Diese Interpretation kann technisch sehr unterschiedlich ausgestaltet sein und auf neuronalen (erlernten) Strukturen beruhen oder in Form von vorgegebenen Regeln definiert werden. Die am Markt etablierten Produkte umfassen typischerweise mehrere dieser Ansätze, die in Kombination verwendet werden können. In der Regel werden – mit Ausnahme der Rechnungseingangserkennung – keine vorgefertigten Erkennungsregeln ausgeliefertet, sondern eine spezifische Fachlichkeit wird explizit und von Grund auf für diesen Anwendungsfall eingerichtet. Ein bedeutendes Werkzeug in diesem Zusammenhang ist die Einsatzmöglichkeit von Lexika. Es handelt sich dabei um im Speicher gehaltene Datenbestände bis hin zu Adresssätzen, die zum Suchen dieser Informationen und zum Abgleich von gefundenen Werten verwendet werden.
Einem Dialogprogramm zur Nachkorrektur. Hier werden diejenigen Attribute durch die Mitarbeiter manuell nachgepflegt, die nicht oder unsicher erkannt wurden. Die wesentlichen Anforderungen an die Nachkorrektur-Anwendung sind Anpassbarkeit (für eigene Prüflogiken), Durchsatz und Ergonomie.

Durch die Abfolge dieser Schritte werden die Metadaten eines Dokumentes routinemäßig ermittelt. Sie bestehen typischerweise aus folgenden Informationen:

Dokumentengrenzen : Wann beginnt innerhalb eines größeren Ordnungskriteriums (z.B. ein Umschlag, eine Akte o.Ä. ) ein neues Dokument und welche Seiten gehören gegebenenfalls zu welchem Dokument?
Klassifikation: Zu welcher Dokumentenklasse (z.B. Schadensmeldung, Neuantrag, Adresswechsel) gehört ein Dokument?
Extraktion: Welche Fachdaten (z.B. Versicherungsnummer, Kündigungsdatum) befinden sich auf dem Dokument oder lassen sich anhand der gefundenen Werte ableiten?

Eine Erkennungslösung der beschriebenen Art ist dabei immer in den gesamten Erfassungs-Workflow integriert, und dieser beginnt typischerweise mit der Vorbereitung der Belege für den Scanvorgang. Schon zu diesem frühen Zeitpunkt kann die Erfassung von Metadaten vorbereitet werden: So lässt sich z.B. die Menge der möglichen Klassifikationsergebnisse einschränken, indem eine sachgebietsorientierte Zuordnung oder eine Dokumenten-Teilung durch Trennblätter durchgeführt wird. Diese zusätzliche Dokumenten-Vorbereitung ist ein wichtiger Bestandteil des Gestaltungs-Spielraums in einem Workflow: Sie sollte, sofern möglich, immer mit bedacht werden.

Ergebnis der Dokumenterkennung: „sicher“, „ unsicher“ oder „nicht erkannt“

Abstrakt betrachtet, handelt es sich bei einer Erkennungs-Lösung um ein maschinelles Bewertungs- und Entscheidungssystem. Maschinelle Bewertungssysteme kennen wir hinlänglich aus unserem Alltag, z.B. im Bereich der Wettervorhersage. Dort werden ebenfalls Eingangs-Parameter in einem komplexen Regelwerk verarbeitet und zu einer Aussage, z.B. über die Regenwahrscheinlichkeit des nächsten Tages, kumuliert. Das Ergebnis ist im einfachsten Fall eine Zahl zwischen 0 und 1, z.B. eine Wahrscheinlichkeit von 81%, dass es morgen in Münster regnet. In Bezug auf die Erfassung des Posteingangs führen solche Systeme beispielsweise zu der Feststellung, dass es sich bei einem Eingangs-Dokument zu 63% um ein Kündigungsschreiben handelt. Ein solches Bewertungssystem wird zu einem Entscheidungssystem, wenn es aus den unscharfen Bewertungszahlen diskrete Entscheidungen ableitet, mithin also eine „harte“ Interpretation der Zahlen durchführt. Hier unterscheidet sich die Wettervorhersage deutlich von den Erkennungssystemen: Der Wetterfrosch muss lediglich bewerten (und die Entscheidung zur Absage der Gartenparty treffen anschließend Sie), während das Dokumenten-Erkennungssystem den Wert bzw. die Werte einer konkreten Entscheidung zugrunde legt: So muss hier definiert werden, ob ein gefundener Wert (63% Wahrscheinlichkeit Dokumenttyp Kündigung) als sicher, unsicher oder als unzureichend (d.h. als nicht erkannt) interpretiert wird. Nur Attribute, die als sicher geliefert werden, erfüllen den Hauptzweck der Erkennungstechnologie: Sie können „dunkel“ verarbeitet werden und erfordern keinen manuellen Eingriff in der Nachkorektur. Nicht erkannte oder unsichere Werte (Vorschlag) kommen typischerweise zur Anzeige und benötigen Mitarbeiterkapazitäten – und ihre Reduzierung stellt ja ein wesentliches Ziel zur Einführung der Erkennungssystems dar.

Zusätzliche Dimension: „richtig“ oder „falsch“

Dies ist (leider) noch nicht das Ende der Geschichte. Denn ein weiterer möglicher Sachverhalt wird oft gar nicht oder erst zu spät wahrgenommen: Ein Entscheidungssystem kann sich irren. Es kann eine Behauptung (z.B. ein Dokument wird sicher der Versicherungsnummer 123 zugeordnet) aufstellen, die nicht der Wahrheit entspricht. Die Gründe dafür können vielschichtig gelagert sein, die Auswirkungen sind jedoch immer gleich: Wenn ein Attribut von der Maschine als sicher bewertet wird und daher nicht mehr manuell verifiziert werden muss, wird es an die Nachfolge-Verarbeitung abgegeben und führt dort de facto zu einer falschen Verarbeitung.

Neben den Dimensionen „sicher“, „unsicher“, „nicht erkannt“ gibt es demnach immer ein weiteres Kriterium bei der Erkennung eines Attributs: „richtig“ oder „falsch“. Das maschinelle Erkennungssystem selbst „kennt“ diese Einstufung selbstverständlich nicht, denn diese Bewertung kann erst später, in der Realität durch die Person, die den Vorgang bearbeitet, vorgenommen werden. Für den Projekterfolg hat diese Tatsache –die Lieferung eines sicheren Ergbenisses kann auch falsch sein – eine entscheidende Bedeutung, wenn sie auch gerne in Vertriebsgesprächen außen vor gelassen wird.

Die Grafik stellt die fünf möglichen Kombinationen noch einmal vor, die sich bei den Antworten eines Erkennungsystems für eine konkrete Fragestellung (z.B. „um welchen Dokumententyp handelt es sich?“) ergeben können:

Die drei auf der rechten Seite abgebildeten Cluster führen nicht (zwangsläufig) zu einer falschen Verarbeitung, sind jedoch mit einem unerwünschten manuellen Eingriff verbunden. Denn oberstes Ziel der Einrichtung des Erkennungssystems ist eine möglichst hohe Quote der Kombination „sicher“ und „richtig“ – und damit die Vermeidung von Benutzer-Interaktionen in Kombination mit einem richtigen Ergebnis. Der verbleibende Cluster („sicher“ und „falsch“) schließlich führt zu dem angesprochenen Fehlverhalten. Diese Fehler werden als Substitutionen bezeichnet.

Aus den Ausführungen wird deutlich, dass eine Projekt-Zielsetzung über eine einzelne Kenngröße der Art „wir brauchen 80 Prozent Erkennung“ nicht ausreichend ist. Der Begriff Erkennungsgüte dagegen nimmt eine differenziertere Bewertung vor, indem er sich auf die dargestellte Matrix bezieht: Er bezeichnet die Einordnung der Ergebnisse einer Erkennungsaufgabe (z.B. die Klassifikation) anhand einer hinreichend großen Anzahl an Beispielen.

Was kostet ein Fehler?

Für den Architekten einer Erkennungslösung ist die Kenntnis dieser Zusammenhänge elementar und bildet eine Grundlage seiner Tätigkeit. Durch Kombination von Technologien und fachlichen Regeln wird er versuchen, möglichst viele Ergebnisse in den Bereichen „sicher“ und „richtig“ zu produzieren. In der Praxis führt dieser Wunsch zu einem Zielkonflikt: Eine Erhöhung der sicheren Ergebnisse führt parallel meist zu einer gleichzeitigen Erhöhung von richtigen und falschen Ergebnissen. Erzeugt das System umgekehrt weniger Substitutionen, geht damit eine Erhöhung der unsicheren Ergebnisse einher und, als weitere Konsequenz, eine Zunahme des manuellen Aufwands. Die Aufgabe des Lösungsarchitekten besteht folglich darin, das Gesamtsystem mittels Erkennungslogiken und Hilfsmitteln (Skripte, DB-Lookups, Ausschlüsse etc.) so zu konfigurieren, dass eine der angegebenen Zielsetzungen mit möglichst geringen negativen Auswirkungen erreicht wird.

Für die Konfigurierung einer Erkennungslösung ist darüber hinaus ein weiterer Aspekt zur Bewertung der Erkennungsgüte relevant: Dabei geht es um die Frage, was eine Substitution, also ein sicheres und falsches Ergebnis, kostet. Denn die Kenntnis der Kosten könnte beispielsweise dazu führen, dass höhere Substitutionen in Kauf genommen werden, weil die Korrektur oder Toleranz dieser Fehler im Backend weniger Kosten verursachen als die Korrektur dieser und weiterer Dokumente innerhalb des Erfassungsflusses durch ein Bewertungssystem, bei dem zur Vermeidung eben dieser Substitutionen auf einen höheren Automatisierungsgrad verzichtet wird.

Welche Zielsetzung als höher bewertet wird, kann im Einzelfall verschieden sein. So kann z.B. für den Anwendungsfall „Aufbau Data Warehouse“ eine höhere Substitution akzeptabel sein, während bei den Daten für ein automatisiertes Buchungssystem eine weitaus geringere Fehlerquote geliefert werden müsste.

Vorgehensmodell

Die Ausführungen belegen, dass die Qualität der Software-Produkte nicht allein über deren Erkennungsgüte entscheidet – ausschlaggebend ist auch die konkrete Einrichtung und Anwendung. Und letztendlich steht das Projektteam hier in der Verantwortung. Jedoch auch die effektive Systementwicklung ist an eine weitere Voraussetzung gebunden: Basisdaten über die aktuelle Erkennungsgüte sind dafür zwingend erforderlich.

Denn kein Erkennungssystem kann die Dimension „richtig“ oder „falsch“ liefern. Für diese Transparenz muss im Projekt selbst gesorgt werden. Sie kann nicht geschaffen werden, indem die Entwickler dokumentweise Ergebnisse betrachten und gegebenenfalls Strichlisten führen, sondern die Erkennungsgüte lässt sich nur über statistische Verfahren explizieren. Ein früher Schritt bei der Einrichtung eines Erkennungssystems ist daher die Bildung eines Referenzbestandes. Er besteht aus einer Menge an Bildern zu Dokumenten mit folgenden Merkmalen:

entspricht ungefähr einer Tagesmenge an Belegen, in kleinen Projekten (<1.000 Dokumente/Tag) eher mehr, in großen Projekten (>10.000 Dokumente/Tag) eher weniger,
die Verteilung des Klassifikationsergebnisses (Dokumententypen) entspricht in etwa dem täglichen Posteingang,
die korrekten (richtigen) Metadaten zu jedem Dokument liegen elektronisch vor,
es findet keine gezielte Aussortierung von „nicht erkennbaren“ Dokumenten statt.

Die Referenzdokumente stellen somit den gewünschten SOLL-Zustand einer Tagesproduktion dar: den optimalen Fall einer hundertprozentig korrekten Erkennung.

Darüber hinaus wird ein zweiter Dokumentenbestand benötigt: Die Trainingsmenge. Sie besteht aus Beispiel-Belegen, die von den Systementwicklern genutzt werden, um die Erkennung einzurichten, bzw. zu trainieren. Der Mengenbedarf ist typischerweise deutlich geringer und richtet sich im Wesentlichen an dem Bedarf des Produktes bzw. der eingesetzten Methoden sowie der Varianz der Ausprägungen zu einzelnen Dokumenttypen aus.

Vergleich von SOLL und IST

Die Einrichtung des Erkennungssystems erfolgt zyklisch anhand der Trainingsmenge. Die Erkennungsgüte wird dabei ermittelt, indem die SOLL-Ergebnisse des Referenzbestandes gegen den IST-Zustand der Erkennung abgeglichen werden, um dadurch feldweise den Güte-Cluster aufzubauen. Je Erkennungs-Attribut ist anschließend der aktuelle Stand der Erkennungsgüte transparent. Diese Informationen sind die Grundlage für die weiteren Schritte, aber auch für die Diskussion zwischen den Entwicklern und dem Auftraggeber: Unter Berücksichtigung der o.g. „Fehlerkosten“ und dem Projektauftrag wird der aktuelle Stand der Erkennung bewertet und das Ziel des nächsten Zyklus der Entwicklung festgelegt.

Die Bewertung und damit die Weiterentwicklung richtet sich demnach nach den festgestellten Abweichungen von SOLL und IST. Für die Entwickler sind allerdings weitere, spezifischere Informationen als die bloße Gütematrix erforderlich, die die Ergebnisse lediglich kumuliert darstellt; die dazu nötigen Daten lassen sich aber ebenfalls aus dem Abgleich zwischen SOLL und IST herauslesen und sollten von dem verfügbaren Vergleichswerkzeug geliefert werden. Sie ermöglichen einen differenzierteren Blick auf die Ergebnisse der Klassifikation: Denn zur Beantwortung der Frage, welche Ergebniswerte de facto einer Verbesserung bedürfen, ist eine Analyse auf Basis der konkreten Ausprägungen unabdingbare Voraussetzung.

Wie die Grafik zeigt, arbeitet man bei der Analyse mit drei Werten:

Der Wert für Recall sagt aus, wie häufig Dokumente des auf der horizontalen Achse angegebenen Typs irrtümlich einem anderen Dokumententyp zugeordnet wurden.
Precision hingegen beschreibt die „Anziehungskraft“ des Typs gegenüber Dokumenten aus anderen Dokumenttypen, also den Anteil der irrtümlich dem Typ zugeordneten Dokumente.
Nicht zugeordnete Dokumente werden unter der Bezeichnung NoResult angezeigt.

Je mehr sich jeder einzelne Wert der 100%-Marke nähert (z.B. in der Abbildung für Typ 502), desto selektiver sind die Definitionen für diesen Dokumententypen. In der Abbildung wird beispielsweise auch deutlich, dass die Precision für den Dokumententypen 505 schlecht ist, die Definition also weniger „aggressiv“ gegenüber Dokumenten aus anderen Klassen gestaltet werden muss.

Die folgende Abbildung zeigt diesen Zusammenhang für eine Dokumentenklasse A. Die Buchstaben stellen die SOLL-Werte dar, während die Rechtecke den IST-Zustand aus der Erkennung für die Klassen A und B repräsentieren.

Darüber hinaus sind weitere Informationen aus einer Messung zu entnehmen, z.B. eine Verwechslungsmatrix zwischen den Dokumententypen, um zu erkennen, welche Klassen primär für schlechte Werte verantwortlich sind.

Nur durch diesem auf „Menge“ basierendem Vergleich zwischen Soll und Ist sind belastbare Aussagen zur aktuellen Qualität der Konfiguration sowie zur zielorientierten Handlungsanweisung für eine Optimierung möglich. Eine fallweise Überprüfung per manueller Strichliste bzw. die kontextfreie Korrektur einzelner Fehlerfälle greifen hier definitif zu kurz, weil eine Bewertung von Einzelfällen nichts über die Qualität im Ganzen aussagen kann.

Die Erzeugung des Datenbestands für diese Analyse ist relativ einfach und wird zum Teil von den Standard-Produkten zur Freiformerkennung unterstützt. Wenn Produkte diese Messungen nicht out-of-the-box liefern, kann man mit pragmatischer, programmierter Ergänzung zur Lieferung und zum Vergleich von Werten relativ schnell zu entsprechenden Ergebnissen kommen. Der Aufwand dafür lohnt sich in zweifacher Hinsicht: Man erhält Transparenz über die Erkennungsgüte im Rahmen des Projekts und schafft gleichzeitig die Voraussetzung zur Messung der Güte im Betrieb, welche durch stetig angepasste Referenzmengen auf gleiche Art und Weise erreicht werden kann.

Fazit

Die Einführung einer (Freiform-)Erkennungslösung birgt die Gefahr von nicht bekannter Erkennungsgüte und damit von nicht zielgerichteter und nicht effizienter Weiterentwicklung. Letzendlich bedeutet dies einen Verlust von Vertrauen in das System.

Somit muss innerhalb des Projekts Klarheit geschaffen werden über den tatsächlichen Stand der Entwicklung. Dies wird erreicht über einen permanenten Vergleich zwischen den SOLL- und IST-Daten der Erkennung und über die anschließende Analyse des Vergleichs. Das Ergebnis dient zur Formulierung der Ziele für die Weiterentwicklung des Systems. Freiform-Erkennungssysteme leisten wertvolle Arbeit, sie führen jedoch im konkreten Anwendungsfall nicht zu einer hundertprozentigen Lösung („sicher“ und „richtig“). Befriedigung und Vertrauen in die Lösung stellt sich daher erst dann ein, wenn die Grenzen der Machbarkeit erkannt wurden und ein spürbarer Grenznutzen in der Erkennung nicht mehr erzielt werden kann.

Zurück zu den Publikationen