Dokumentenklassifizierung mit Kofax Transformation Modules (KTM)

Viele unserer Kunden setzen Systeme zur automatischen Dokumentenklassifikation und Datenextraktion ein. Eines dieser Systeme ist das Kofax Produkt ‚Kofax Transformation Modules‘ (KTM). Diese Dokumenten-Erkennungssysteme ermitteln die Metadaten aus elektronischen Bildern (die gescannten Seiten der zu verarbeitenden Dokumente, Faxe oder eMails) und übergeben die Daten an ein nachgelagertes System (z.B. an eine Postkorbanwendung).

In diesem Artikel in der Reihe der KTM-Blogs möchte ich die verschiedenen Möglichkeiten erläutern, die KTM zur Klassifizierung von Dokumenten bietet.

Die bisher erschienenen  KTM-Artikel über Formatlokatoren finden Sie hier:

Kofax Transformation Modules – Formatlokatoren und dynamische reguläre Ausdrücke – Teil 1
Kofax Transformation Modules – Formatlokatoren und dynamische reguläre Ausdrücke – Teil 2

Bevor Daten aus einem Dokument extrahiert werden können, muss ein System zunächst wissen, um welche Art Dokument es sich handelt. Aus einer Rechnung müssen beispielsweise andere Daten extrahiert werden, als aus einem Versicherungsvertrag. Bei der Rechnung will man typischerweise die Rechnungsnummer, das Rechnungsdatum, den Lieferanten und die Beträge extrahieren, wohingegen bei dem Versicherungsdokument die Werte Versicherungsnummer und Versicherungssparte von Interesse sind.

Vor der eigentlichen Extraktion muss also zunächst bestimmt werden, welche Art von Dokument vorliegt. Dies wird bei KTM durch die vor der Extraktion stattfindende Klassifikation durchgeführt. Sobald ein Dokument klassifiziert wurde, können dann die passenden Metadaten extrahiert werden.

Die Klassifikation eines Dokuments kann durch KTM mit verschiedenen Methoden durchgeführt werden, die sich in der Komplexität und im Aufwand für die Dokumentenvorbereitung unterscheiden:

1. Layoutklassifikation

Bei dieser Klassifikationsart versucht das System die Art des Dokuments anhand des grafischen Aufbaus zu bestimmen. Dieses Vorgehen ist die schnellste Art der Klassifizierung, da hierzu keinerlei OCR-Erkennung notwendig ist, da zur Klassifikation ja nicht der Dokumenteninhalt herangezogen wird. Allerdings ist diese Art der Klassifikation nur in Dokumentenbereichen nutzbar, in denen sich die Belege optisch klar voneinander trennen lassen. Beispiel wären bestimmte Antragsarten, die sich durch ihr Design (Aufbau, Firmenlogo, …) abgrenzen lassen. Ungeeignet sind hier beispielsweise zum Teil Formulare im Finanzdienstleistungs- oder Versicherungsbereich, da diese sich optisch häufig sehr ähneln.

Natürlich muss man KTM die Layoutklassifikation für die Dokumentenarten eines Kunden antrainieren. KTM hält den manuellen Aufwand hierzu aber sehr gering. Im Vorfeld müssen für die in Frage kommenden Dokumentarten jeweils einige Beispieldokumente zusammengetragen werden. Anschließend zeigt man KTM noch, welche Beispiele für welche Dokumentenklasse stehen. KTM lernt dann selbstständig die kennzeichnenden Strukturen der Layouts der einzelnen Dokumentarten. Das Antrainieren der Beispieldokumente kann einfach über die grafische Oberfläche des KTM Project Builders durchgeführt werden.

2. Inhaltsklassifikation

Die (automatische) Inhaltsklassifikation ähnelt vom Vorgehen her der Layoutklassifikation, mit dem Unterschied, dass hier nicht die optische Struktur, sondern der tatsächliche Dokumenteninhalt zur Klassifizierung herangezogen wird. Dazu muss natürlich vorher ein OCR-Lesen der Dokumente erfolgen.

Das charmante daran ist, dass der Entwickler keinerlei Vorgaben zur Bedeutung des Inhalts machen muss. Ähnlich wie bei der Layoutklassifikation muss auch hier für jede Dokumentart ein Stapel an Beispieldokumenten zusammengetragen werden. Nach erfolgter OCR-Lesung der Beispieldokumente zeigt man KTM auch hier wieder, welcher Beispielstapel für welche Dokumentart steht. Anschließend lernt KTM dann selbstständig welche Worte, Phrasen oder Wortkombinationen charakteristisch für eine Dokumentart sind. Das Antrainieren der Beispieldokumente geschieht auch hier einfach über die grafische Oberfläche des KTM Project Builders.

3. Instruktionsklassifikation

Bei der Layout- und Inhaltsklassifikation müssen dem KTM-System ’nur‘ genug Beispielbelege zur Verfügung gestellt werden. Die eigentliche Arbeit des Lernens und Bewertens wird dann von KTM durchgeführt. Bei der Instruktionsklassifikation muss hingegen der Entwickler die Dokumente inhaltlich kennen und bewerten können. Je Dokumentart kann der Entwickler manuell Worte, Phrasen und Wortkombinationen hinterlegen, die eine Dokumentart kennzeichnen. Hier ist also fachspezifisches Wissen über das Beleggut notwendig.

Die Instruktionsklassifikation wird häufig bei Beleggut eingesetzt, das zum großen Teil aus Korrespondenz besteht. Kommen beispielsweise die Worte ‚Mahngebühr‘ und ‚Mahnung‘ beide auf einem Dokument vor, kann man das Dokument darüber in die Dokumentart ‚Mahnverfahren‘ klassifizieren.

Damit die Instruktionsklassifikation genutzt werden kann, muss vorher eine OCR-Lesung des Belegguts erfolgt sein. Die Eingabe der Instruktionen (Worte, Phrasen, Wortkombinationen) erfolgt über die grafische Oberfläche des KTM Project Builders.

4. Skript-Klassifikation

4.1 Barcode

In manchen Anwendungsfällen kann ein auf den Dokumenten aufgebrachter Barcode ausreichend für die Klassifizierung des Dokuments sein. KTM bietet auch diese Möglichkeit, man muss dazu aber die KTM-eigene Skriptsprache benutzen.

Ausgangspunkt ist ein auf Projektebene definierter Barcode-Lokator (BCode), der die Dokumentenbarcodes erkennt. Ein Stückchen Skript auf der Projektebene hilft das Dokument auf die gewünschte Dokumentart zu klassifizieren:

1' Class script: Project
2Private Sub Document_BeforeClassifyXDoc(pXDoc As CASCADELib.CscXDocument, bSkip As Boolean)
3  If pXDoc.Locators.ItemByName("BCode").Alternatives.Count>0 Then
4     If pXDoc.Locators.ItemByName("BCode").Alternatives(0).Confidence > 0.95 Then
5       pXDoc.Reclassify "Barcodeantrag"
6       Exit Sub 'möglichst nur ein reclassify
7     End If
8  End If
9End Sub

Das Skript wird im Event Document_BeforeClassifyXDoc aufgerufen, welches vor allen anderen Klassifizierungsmechanismen von KTM ausgeführt wird.

Zunächst wird überprüft, ob der Barcode-Lokator überhaupt etwas gefunden hat, und ob die Konfidenz über 95% lag. Falls ja erfolgt über den reclassify-Befehl die Klassifizierung auf die Dokumentart ‚Barcodeantrag‘. Nach erfolgter Klassifizierung wird die Routine verlassen, damit keine weitere Klassifizierung durch ein folgendes Stück Skript erfolgen kann. Ein mehrfaches reclassify ist zwar inzwischen mit KTM möglich, sollte aber nur mit Vorsicht eingesetzt werden, da man damit leicht Endlosschleifen hervorrufen kann.

4.2 Formatlokatoren, Erweiterte Zonenlokatoren und der ganze Rest…

Das in 4.1 anhand eines Barcodelokators beschriebene Prinzip der Skriptklassifizierung kann natürlich auch mit beliebigen anderen Lokatoren durchgeführt werden. Wichtig ist, dass der entsprechenden Lokator auf Projektebene definiert wird, da er sonst im Event Document_BeforeClassifyXDoc nicht ausgewertet werden kann, und er muss natürlich die Dokumentart eindeutig kennzeichnen. Der primäre Zweck dieser ‚Projektlokatoren‘ ist also nicht die Datenextraktion sondern sie dienen als Hilfsmittel zur Klassifikation.

Mit einem auf Projektebene definierten Formatlokator kann man beispielsweise den Typ eines Versicherungsantrags feststellen und dann das Dokument entsprechend klassifizieren. Das folgende Bild zeigt  einen Ausschnitt eines Haftpflichtversicherungsantrags:

Mit einem Formatlokator (Antrag_Haft), der beispielsweise das Wort Haftpflichtversicherung oberhalb des Wortes Antrag in einer Region in der linken oberen Ecke des Dokuments sucht, kann der Antragstyp eindeutig bestimt werden.

Das passende Stück Skript sieht dann so aus (enstprechend dem Barcodebeispiel):

1' Class script: Project
2Private Sub Document_BeforeClassifyXDoc(pXDoc As CASCADELib.CscXDocument, bSkip As Boolean)
3  If pXDoc.Locators.ItemByName("Antrag_Haft").Alternatives.Count>0 Then
4     If pXDoc.Locators.ItemByName("Antrag_Haft").Alternatives(0).Confidence > 0.95 Then
5       pXDoc.Reclassify "Antrag_Haftpflicht"
6       Exit Sub 'möglichst nur ein reclassify
7     End If
8  End If
9End Sub

Nutzt man einen ‚Erweiterten Zonenlokator‘ (Antrag_Haft_EZL) für die Klassifizierung muss man das Skript nur leicht an die Unterfelder des Zonenlokators anpassen:

1' Class script: Project
2Private Sub Document_BeforeClassifyXDoc(pXDoc As CASCADELib.CscXDocument, bSkip As Boolean)
3  If pXDoc.Locators.ItemByName("Antrag_Haft_EZL").Alternatives.Count>0 Then
4     If pXDoc.Locators.ItemByName("Antrag_Haft_EZL").Alternatives(0).SubFields.ItemByName("UF_Zone0").Confidence > 0.95 Then
5       pXDoc.Reclassify "Antrag_Haftpflicht"
6       Exit Sub 'möglichst nur ein reclassify
7     End If
8  End If
9End Sub

Hat man das Prinzip der Skriptklassifizierung einmal verstanden, sind der Fantasie eigentlich keine Grenzen gesetzt. So könnte man beispielsweise über einen Datenbanklokator den Absender der Eingangsdokumente bestimmen (falls eine entsprechende Stammdatendatei vorliegt) und die Dokumente dann in vordefinierte Gruppen klassifizieren.

Oft haben Formulare eine eindeutige Formularnummer um 90° gedreht in der unteren linken Ecke aufgedruckt. Mit einem ‚Erweiterten Zonenlokator‘ kann diese um 90° gedrehte Nummer ausgelesen und zur Dokumentenklassifikation genutzt werden.

Ich hoffe Ihnen durch diesen Artikel einige Anregungen für die Arbeit mit Kofax Transformation Modules gegeben zu haben und wünsche viel Spaß beim Experimentieren 🙂

Noch ein Hinweis für die Entwickler unter den Lesern: mein Kollege Frank Engelen aus dem codecentric Unternehmensbereich Agile Software Factory hat aktuell einen sehr interessanten Artikel über Daten- / Dokumentklassifizierung unter Nutzung des Tools ‚RapidMiner‘ verfasst. Mit ‚etwas‘ Java KnowHow können Sie Ihre eigenen Klassifizierungsmechanismen entwickeln!

Hier der Link zum Artikel: Taking a look at Java-based Machine Learning by Classification

Neu: KTM im Versicherungseinsatz: Heller, grauer und dunkler Posteingang