Release 1.10.1

Ein neues HTR-Modell ist über eine Seite gelaufen und du willst einen ersten Überblick haben, wie das Modell gelesen hat? Setze in den Tools, unter Compute Accuracy die entsprechenden Referenz (GT) und Hypothese (HTR Text) ein und schaue dir den Text Compare an:

Dieses Tool visualisiert den Vergleich der HTR mit der GT-Version direkt im Text. Ein Wort mit einem Fehler erscheint rot markiert und gestrichen, in grün steht dahinter die korrekte Version aus dem GT. Der Text Compare bildet die Wortfehlerquote (WER) ab. Es erlaubt uns aber vor allem schnell zu erkennen welche Fehler genau gemacht wurden. So können wir beispielsweise auch nachvollziehen, dass es sich bei vielen der Fehler tatsächlich um Kleinigkeiten handelt, die beim Lesen und der Wortsuche eigentlich nicht weiter stören. In unserem Beispiel hier sehen wir eine WER von 15%.

Release 1.10.1

Im letzten Beitrag haben wir beschrieben, dass ein Base Model alles was es bereits “gelernt” hat, an das neue HTR-Modell weitergeben kann. Mit zusätzlichem Ground Truth kann das neue Modell dann seine Fähigkeiten erweitern und verbessern.

Hier nun ein typischer Anwendungsfall: In unserem Teilprojekt zu den Assessorenvoten des Wismarer Tribunals trainieren wir ein Modell mit acht verschiednene Schreibern. Das Train Set umfasst 150.000 Wörter, die CER lag beim letzten Training bei 4,09 %. Allerdings war die durchschnittliche CER für einzelne Schreiber viel höher als für andere.

Wir entschieden uns also für ein Experiment. Wir fügten 10.000 Wörter neuen GT für zwei der auffälligen Schreiber (Balthasar und Engelbrecht) hinzu und nutzten das Base Model und dessen Trainings- und Validation Set für das neue Training.

Das neue Modell hatte im Ergebnis eine durchschnittliche CER von 3,82 % – es hatte sich also verbessert. Was aber bemerkenswert ist, ist das nicht nur die CER für die beiden Schreiber verbessert wurde, für die wir neuen GT hinzugefügt hatten – in beiden Fällen um bis zu 1%. Auch die Zuverlässigkeit des Modells für die anderen Schreiber hat nicht gelitten, sondern sich im Gegenteil, ebenfalls verbessert.

Release 1.10.1

Wer generische HTR-Modelle entwickeln möchte, der kommt an der Arbeit mit Base Models nicht vorbei. Beim Training mit Base Models wird jeder Trainingsdurchgang für ein Modell auf der Grundlage eines bereits existierenden Modells, eben eines Base Models, durchgeführt. Das ist in der Regel das letzte HTR-Modell, das man in dem entsprechenden Projekt trainiert hat.

Base Models „erinnern“ sich an das, was sie bereits „gelernt“ haben. Daher verbessert auch jeder neue Trainingsdurchgang die Qualität des Modells (theoretisch). Das neue Modell lernt also von seinem Vorgänger und wird dadurch immer besser. Daher ist das Training mit Base Models auch für große generische Modelle, die über lange Zeit kontinuierlich weiterentwickelt werden, besonders geeignet.

Um ein Training mit Base Model durchzuführen, wählt man im Trainingstool – neben den üblichen Einstellungen – einfach ein bestimmtes Base Model aus. Danach fügt man aus dem Reiter HTR Model Data das Train Set und und das Validation Set (in früheren Transkribus-Versionen als Test Set bezeichnet) des Base Models ein, sowie das neue Trainings und Validation Set. Zusätzlich kann man dann noch weiteren neuen Ground Truth hinzufügen und anschließend das Training starten.

Release 1.10.1

Es gibt mehrere Möglichkeiten für die Validierung unserer HTR-Ergebnisse in Transkribus: drei Compare tools können die Genauigkeit eines Modells auf unterschiedliche Weise berechnen bzw. darstellen. In allen Fällen vergleichen wir die Hypothese (HTR-Version) eines Textes mit einer entsprechenden Referenz (korrekte Version, also GT) des gleichen Textes.

Das erste und unmittelbarste Tool ist der Textvergleich „Compare Text Versions“. Er visualisiert die Unterschiede für die jeweils geöffnete Seite im Text selbst. Hier können wir also genau nachvollziehen, an welchen Stellen die HTR welche Fehler gemacht hat.

Der normale „Compare“ gibt uns diese Validierungsergebnisse in Zahlenwerten. Er berechnet u.a. die durchschnittliche Wortfehlerquote (WER), die Zeichenfehlerquote (CER) sowie die jeweiligen Genauigkeitsraten. (Wenn jemand weiß, was es mit den Bag Tokens auf sich hat, darf er/sie uns gerne dazu einen Kommentar schreiben). Im „Compare“ haben wir außerdem die Möglichkeit den „Advanced Compare“ auszulösen, mit dem wir die entsprechenden Berechnungen für das gesamte Dokument oder auch nur für bestimmte Seiten ausführen lassen können.

Das Vergleichsinstrument „Compare Sample“ haben wir an anderer Stelle schon einmal vorgestellt, um zu zeigen wie Test Samples erstellt werden können. Der Sample Compare stellt dann nämlich eine Prognose an, wie ein Modell potentiell auf einem so erstellten Validierungssample lesen wird.

Release 1.10.1

In einem der vorigen Beiträge haben wir über den Unterschied zwischen Spezialmodellen und generischen Modellen gesprochen. Spezialmodelle sind immer dann die erste Wahl, wenn dein Material nur eine begrenzte Anzahl von Schreibern umfasst. Für sehr vielfältiges Material – wenn bspw. in einem Handschriftenkonvolut der Schreiber häufig wechselt – bietet es sich an, ein generisches Modell zu trainieren.

Die folgenden Beiträge gründen sich auf unsere Erfahrungen mit dem Training eines generischen Modells für die Responsa der Greifswalder Juristenfakultät, in dem ca. 1000 unterschiedliche Schreiberhände trainiert wurden.

Aber zuerst: Was soll ein generisches HTR-Modell können? Das wichtigste ist schon gesagt: Es soll mit einer Vielfalt verschiedener Schreiberhände umgehen können. Es soll aber auch verschiedene Schriftarten (Alphabete) und Sprachen „lesen“ könne und in der Lage sein, Abbreviaturen zu interpretieren.

Hier seht ihr ein paar typische Beispiele für solche Herausforderungen aus unserer Sammlung.

Verschiedene Schreiberhände auf einer Seite:

Abbreviaturen:

Verschiedene Sprachen auf einer Seite:

Release 1.10.1

Wir haben in einem früheren Beitrag über die Verwendung von Wörterbüchern gesprochen und dabei erwähnt, dass – je besser ein HTR-Modell ist (CER besser als 7%) – der Nutzen eines Wörterbuches für das HTR-Ergebnis geringer wird.

Anders ist das beim Einsatz von Language Models, die seit Dezember 2019 in Transkribus verfügbar sind. Wie Wörterbücher werden auch Language Models bei jedem HTR-Training aus dem dort genutzten Ground Truth generiert. Anders als Wörterbücher zielen Language Models aber nicht auf die Identifizierung einzelner Wörter. Sie ermitteln stattdessen die Wahrscheinlichkeit für eine Wortfolge oder die regelmäßige Kombination von Wörtern und Ausdrücken in einem bestimmten Kontext.

Anders als bei Wörterbüchern führt der Einsatz von Language Models immer zu wesentlich besseren HTR-Ergebnissen. In unseren Tests verbesserte sich die durchschnittliche CER im Vergleich zum HTR-Ergebnis ohne Language Model bis zu 1 % – und zwar durchweg, auf allen Testsets.

Tipps & Tools: Das Language Model kann bei der Konfiguration der HTR ausgewählt werden. Anders als bei Wörterbüchern sind Language Models und HTR-Modell nicht frei kombinierbar. Es wird immer das zum HTR-Modell generierte Language Model genutzt.

Wenn eine Projektkonzeption es nicht zulässt, den Aufbau von Testsets strategisch zu planen und zu organisieren, dann gibt es eine einfache Alternative: automatisch erstellte Samples. Sie stellen auch eine gute Ergänzung zu den von uns manuell erstellten Testsets dar, denn hier entscheiden nicht wir, sondern die Maschine, welches Material in das Testset kommt und welches nicht. Das läuft darauf hinaus, dass Transkribus einzelne Zeilen aus einer Menge von Seiten auswählt, die ihr natürlich zuvor zur Verfügung gestellt habt. Es handelt sich also um eine mehr oder weniger zufällige Auswahl. Das lohnt sich bei Projekten, die über sehr viel Material verfügen – also auch bei unserem.

Wir verwenden Samples als Gegenprobe zu unseren planmäßig manuell erstellten Testsets und weil Samples den statistischen Verfahren der Stichprobenerhebung vergleichbar sind, die die DFG in ihren Praxisregeln auch für die Überprüfung der Qualität der OCR empfiehlt.

Da HTR (anders als OCR) zeilenbasiert arbeitet, wandeln wir die Empfehlung der DFG etwas ab. Ich erkläre das am konkreten Beispiel: Für unser Modell Spruchakten_M-3K sollte eine Überprüfung der erzielten Lesegenauigkeit vorgenommen werden. Für unser Sample wurde zunächst eine Stichprobe von 600 Seiten gezogen, verteilt über den Gesamtzeitraum, für den das Modell arbeitet (1583-1627) und ausschließlich aus untrainiertem Material. Dafür wurde jede 20. Seite des Datensets ausgewählt. Bezogen auf das gesamte für diesen Zeitraum zur Verfügung stehende Material von 16.500 Seiten repräsentiert dieses Subset ca. 3,7%. All das geschieht auf dem eigenen Netzlaufwerk. Nachdem dieses Subset in Transkribus hochgeladen und mit der CITlab Advanced LA verarbeitet wurde (16.747 lines wurden insgesamt erkannt), ließen wir Transkribus ein Sample daraus erstellen. Es enthält 900 per Zufallsgenerator ausgewählte Zeilen. Das sind also ca. 5% des Subsets. Dieses Sample wurde nun mit GT versehen und als Testset zur Überprüfung des Modells genutzt.

Und so geht das in der Praxis: Im Menü „Tools“ wird die Funktion „Sample Compare“ aufgerufen. Unser Subset wird in der Collection ausgewählt und mit dem Button „add to sample“ zum Sample Set hinzugefügt. Dabei geben wir auch die Anzahl der Zeilen an, die Transkribus aus dem Subset auswählen soll an. Wir wählen hier mindestens so viele Zeilen, wie Seiten im Subset vorhanden sind, so dass rechnerisch auf jede Seite eine Testzeile kommt. In unserem Fall haben wir uns für den Faktor 1,5 entschieden, um sicher zu gehen. Das Programm wählt die Zeilen nun eigenständig aus und stellt daraus ein Sample zusammen, das als neues Dokument gespeichert wird. Dieses Dokument enthält keine pages, sondern ausschließlich Zeilen. Die müssen nun – wie gewohnt – transkribiert und so GT erzeugt werden. Anschließend kann jedes beliebige Modell über die Compare-Funktion an diesem Testset ausprobiert werden.

Release 1.7.1

HTR benötigt keine Wörterbücher. Dennoch gibt es sie auch hier und sie können wahlweise zugeschaltet werden, wenn man eine Volltexterkennung durchführt.

Bei jedem HTR-Training, kann aus dem GT im Trainingsset ein Wörterbuch generiert werden, in dem auch die Häufigkeit, mit der ein Wort vorkam, hinterlegt ist. Es ist also möglich, ein passendes Wörterbuch für jedes Modell bzw. für die Textart mit der man arbeitet zu erzeugen.

Insgesamt werden Wörterbücher in Transkribus aber selten benutzt. In unserem Projekt werden sie nur zu Beginn der Arbeit an neuen Modellen eingesetzt. So lange das Modell, das verbessert werden soll noch eine CER von mehr als 8% aufweist, ist nämlich das Korrigieren der von der HTR erkannten Texte sehr aufwendig. Setzt man an dieser Stelle ein Wörterbuch ein, lässt sich die CER manchmal bis auf 5% senken. Hat das Modell bereits eine CER unter 8%, ist der Einsatz von Wörterbüchern kontraproduktiv, weil sich das Leseergebnis dann häufig wieder verschlechtert. Die HTR ersetzt dann manchmal „wider besseres Wissen“ ihr eigenes Leseergebnis gegen eine Empfehlung, die sich aus dem Wörterbuch ergibt.

Wir setzen Wörterbücher nur zur Unterstützung von sehr schwachen Modellen ein. Und wir tun das auch eher, um den Transcriber bei besonders schwierigen Schriften eine Hilfestellung zu geben. So haben wir ein Wörterbuch bei der Erstellung des GT für die wirklich kaum lesbaren Konzeptschriften eingesetzt. Die Ergebnisse mussten natürlich in jedem Fall korrigiert werden. Aber die „Leseempfehlungen“ die aufgrund der HTR mit Wörterbuch entstanden, waren eine gute Hilfe. Sobald unser Modell in der Lage war, auch Konzeptschriften mit unter 8% CER zu erkennen, haben wir auf den Einsatz des Wörterbuches verzichtet.

Release 1.7.1

HTR benötigt keine Wörterbücher und funktioniert auch unabhängig von der Sprache in der ein Text verfasst ist – solange nur das Zeichensystem verwendet wird, auf das das benutzte Modell trainiert ist.

Für die Trainingsstrategie in unserem Projekt bedeutet das, dass wir zwischen lateinischen und deutschen Texten oder niederdeutschen und hochdeutschen Texten bei der Auswahl des Trainingsmaterials nicht unterscheiden. Wir konnten bisher in der Qualität der HTR-Ergebnisse keine gravierenden Unterschiede zwischen Texten in beiden Sprachen feststellen.

Für historische Handschriften aus dem deutschen Sprachraum ist diese Beobachtung wichtig. Denn üblicherweise ändert sich mit der verwendeten Sprache innerhalb eines Dokuments hier auch die Schrift. Die meisten Schreiber des 16. bis 18. Jahrhunderts wechseln, wenn sie vom Deutschen zum Lateinischen übergehen, mitten im Text von der Kurrentschrift zur lateinischne Schreibschrift (Antiqua). Das ist – in den Augen der Maschine – ein anderes Zeichensystem. Anders als bei der OCR, wo die gemischte Verwendung von Fraktur und Antiqua in neuzeitlichen Drucken große Schwierigkeiten bereitet, hat die HTR – sofern sie darauf traniert ist – mit diesem Wechsel kein Problem.

Ein typisches Beispiel aus unserem Material, das hier mit einem Vergleich der Textversionen von HTR-Ergebnis und GT, versehen ist, kann das verdeutlichen. Die Fehlerquote in dem sich sprachlich unterscheidenden Textabschnitten der Seite ist durchaus vergleichbar. Zum Einsatz kam das Modell Spruchakten M 2-8 sowie M 3-1. Während das erstere ein Gesamtmodell ist, ist das zweite für Schriften von 1583 bis 1627 trainiert.

Ist dir in dem Diagramm zur Modellentwicklung aufgefallen, dass die Zeichenfehlerquote (CER) des letzten Modells wieder etwas schlechter wurde? Und das, obwohl wir den GT-Input deutlich gesteigert hatten? Wir hatten rund 43.000 mehr Wörter im Training aber eine Verschlechterung der durchschnittlichen CER von 2,79 auf 3,43 %. Erklären konnten wir uns das nicht so richtig.

An dieser Stelle kamen wir mit immer mehr GT doch nicht so richtig weiter. Wir mussten also unsere Trainings-Strategie ändern. Bisher hatten wir Gesamtmodelle trainiert, mit Schriften aus einem Gesamtzeitraum von 70 Jahren und von über 500 Schreibern.

Unser erster Verdacht fiel auf die Konzeptschriften, von denen wir schon wussten, dass die Maschine (LA und HTR) – wie wir auch – damit ihre Probleme hat. Beim nächsten Training schlossen wir deshalb diese Konzeptschriften aus und trainierten also nur mit „sauberen“ Kanzleischriften. Eine auffällige Verbesserung brachte das aber nicht: die Test Set-CER sank von 3,43 auf gerade einmal 3,31 %.

Im den darauf folgenden Trainings setzten wir dann zusätzlich auf eine chronologische Sequenzierung der Modelle. Wir teilten unser Material und erstellten zwei verschiedene Modelle: Spruchakten_M_3-1 (Spruchakten 1583-1627) und Spruchakten_M_4-1 (Spruchakten 1627-1653).

Mit den neuen Spezialmodellen erreichten wir tatsächlich wieder eine Verbesserung der HTR – wo das Gesamtmodell nicht mehr ausgereicht hatte. In den Testsets wiesen jetzt etliche Seiten eine Fehlerquote von unter 2 % auf. Im Fall des M_4-1er Modells blieben viele Seiten-CERs unter 1 % und zwei Seiten sogar fehlerfrei mit 0 %.

Ob ein Gesamt- oder Spezialmodell weiterhilft und die besseren Ergebnisse bringt, hängt natürlich sehr vom Umfang und der Zusammenstellung des Materials ab. Am Anfang, wenn du noch „Masse machen“ willst (viel hilft viel) lohnt sich ein Gesamtmodell. Wenn das aber an seine Grenzen kommt, solltest du die HTR nicht weiter „überfordern“ sondern stattdessen deine Modelle spezialisieren.