Elisabeth Heigl


Posted by Elisabeth Heigl on

Anwendungsfall: Erweiterung und Verbesserung bestehender HTR-Modelle

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.

Posted by Elisabeth Heigl on

Auf den Schultern von Giganten: Training mit Basismodellen

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.

Posted by Elisabeth Heigl on

Möglichkeiten der Validierung

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 denAdvanced 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.

Posted by Elisabeth Heigl on

Generisch Modelle und was sie können

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:

Posted by Elisabeth Heigl on

Der Regelbruch – das Problem mit Konzeptschriften

Release 1.10.1

Konzeptschriften werden verwendet, wenn ein Schreiber schnell einen Entwurf anfertigt, der erst später „ins Reine“ geschrieben wird. Bei den Spruchakten sind dies die später verschickten Urteile. Diese Schriften sind meist sehr flüchtig und „unordentlich“ geschrieben. Oftmals werden dabei Buchstaben ausgelassen oder Wortendungen „verschluckt“. Konzeptschriften sind schon für den menschlichen Leser oft nicht leicht zu entziffern. Für die HTR stellen sie eine besondere Herausforderung dar.

Um ein HTR-Modell für das Lesen von Konzeptschriften zu trainieren, geht man ganz ähnlich vor, wie beim Traininig eines Modells, das Abbreviaturen interpretieren soll. Das HTR-Modell muss in beiden Fällen befähigt werden, etwas zu lesen, was überhaupt nicht da ist – nämlich fehlende Buchstaben und Silben. Um das zu erreichen muss die Transkriptionsregel: „Wir transkribieren als Ground Truth nur das, was auch wirklich auf dem Papier steht“ gebrochen werden. Wir müssen vielmehr alle ausgelassenen Buchstaben und fehlende Wortendungen etc. in unsere Transkription einfügen. Anders werden wir am Ende kein sinnvolles und durchsuchbares HTR-Ergebnis erhalten.

Bei unseren Versuchen mit Konzeptschriften hatten wir zuerst versucht spezielle HTR-Modelle für Konzeptschriften zu trainieren. Der Erfolg damit war eher gering. Schließlich sind wir dazu übergegangen, Konzeptschriften – ähnlich wie die Abbreviaturen – direkt innerhalb unseres generischen Modells mit zu trainieren. Dabei haben wir immer wieder überprüft, ob der „falsche Ground Truth“ den wir dabei produzieren, das Gesamtergebnis unseres HTR-Modells verschlechtert. Überraschender weise hatte das Brechen der Transkriptionsregeln, keinen messbaren negativen Effekt auf die Qualität des Modells. Das ist wahrscheinlich auch auf die schiere Menge des Ground Truth zurückzuführen, der in unserem Fall verwendet wird (ca. 400.000 Wörter).

HTR-Modelle sind also in der Lage Konzeptschriften von Reinschriften zu unterscheiden und entsprechend zu interpretieren – innerhalb bestimmter Grenzen. Unten findet ihr einen Vergleich des HTR-Ergebnisses mit dem GT bei einer typischen Konzeptschrift aus unserem Material.

Posted by Elisabeth Heigl on

Language Models

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.

Posted by Elisabeth Heigl on

„zwischen den Zeilen“ – Behandlung von Einfügungen

Mindestens genauso häufig wie Streichungen oder Schwärzungen kommen Überschreibungen oder zwischen die Zeilen geschriebene, eingefügte Textpassagen vor. Hier ist es in zweierlei Hinsicht nützlich, wenn man schon zu Anfang eines Projektes klärt, wie diese Fälle behandelt werden sollen.

In diesem einfachen Beispiel könnt Ihr sehen, wie wir solche Fälle handhaben.

Da wir Streichungen und Schwärzungen sowohl im Layout als auch im Text erfassen, ist es nur konsequent, wenn wir die Überschreibungen und Einfügungen ebenso behandeln. Meist werden solche Passagen schon bei der automatischen Layoutanalyse mit separaten Baselines versehen. Hin und wieder muss man da korrigieren. Auf jeden Fall wird jede Einfügung von uns als eigene Zeile behandelt und auch in der Reading Order entsprechend berücksichtigt.

Auf keinen Fall sollte man das transkribiren was über der Streichung steht, da diese Überschreibungen oder Einfügungen eine eigene Baseline haben. Auf diese Weise würde das Trainingsmaterial versfälscht, auch wenn die Präsentation des Textes für das menschliche Auge natürlich gefälliger wäre.

Posted by Elisabeth Heigl on

Behandlung von Streichungen und Schwärzungen

HTR-Modelle behandeln gestrichenen Text genauso wie jeden anderen. Sie kennen da keinen Unterschied und bieten also immer ein Leseergebnis. Sie sind dabei sogar erstaunlich gut und lesen auch da noch sinnvolle Inhalte heraus, wo ein Transcriber längst aufgegeben hätte.

Das einfache Beispiel zeigt einen auch für das menschliche Auge noch lesbaren gestrichenen Text, den das HTR-Modell fast fehlerfrei gelesen hat. Richtig wäre die Lesung „billig vormeinet habe“.

Weil wir diese Fähigkeit der HTR-Modelle bereits in anderen Projekten kennenlernen durften, haben wir von Anfang an beschlossen, auch Streichungen und Schwärzungen, so gut es eben geht, zu transkribieren um dieses Potential der HTR ebenfalls auszunutzen. Die entsprechenden Passagen werden von uns im Text einfach als text-style „strike through“ getaggt und bleiben so auch für evtl. interne Suchabfragen kenntlich.

Möchte man diesen Aufwand nicht treiben, hat man schlicht die Möglichkeit, an den entsprechenden Textpassagen, die Streichungen oder Schwärzungen enthalten, in das Layout einzugreifen und bspw. die Baselines zu löschen oder entsprechend zu verkürzen. Dann „sieht“ die HTR solche Passagen nicht und kann sie auch nicht erkennen. Das ist aber nicht weniger aufwendig als der von uns gewählte Weg.

Auf keinen Fall sollte man an Streichungen generell mit dem „beliebten“ Ausdruck „[…]“ arbeiten. Die Transkriber wissen zwar was das Auslassungszeichen bedeutet, die HTR lernt hier aber, wenn viele solche Stellen ins Training kommen, etwas völlig Falsches.

Posted by Elisabeth Heigl on

Testsamples – die unparteiische Alternative

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.

Posted by Elisabeth Heigl on

Auflösung

Ein technischer Parameter, der zu Beginn des Scanprozesses einheitlich festgelegt werden muss, ist die Auflösung der Digitalisate, d.h. wie viele Bildpunkte/dots per inch (dpi) das gescannte Bild aufweist.

Die DFG-Praxisregeln zur Digitalisierung empfehlen allgemein 300 dpi (S. 15). Für „Textdokumente mit dem kleinsten signifikanten Zeichen“ von bis zu 1,5 mm kann jedoch eine Auflösung von 400 dpi gewählt werden (S. 22). Tatsächlich können bei den Handschriften – insbesondere den Konzeptschriften – der frühen Neuzeit kleinste Zeichenbestandteile unterschiedliche Lesarten zur Folge haben und sollten also möglichst eindeutig zu erkennen sein. Wir haben uns daher für 400 dpi entschieden.

Neben den Vorteilen für das Entziffern der Schriften muss aber gleichzeitig auch das deutlich größere Speicherformat der 400er (rund 40.000 KB/img.) gegenüber den 300er (rund 30.000 KB/img.) Dateien bedacht und eingeplant werden!

Die gewählte dpi-Zahl hat darüber hinaus auch Auswirkungen auf den Prozess der automatischen Handschriftenerkennung. Unterschiedliche Auflösungen bringen unterschiedliche Ergebnisse der Layout Analyse und der HTR mit sich. Zur Überprüfung dieser These haben wir etwas willkürlich drei Seiten aus einer Spruchakte von 1618 ausgewählt, diese jeweils in 150, 200, 300 und 400 dpi gescannt, sämtliche Seiten in Transkribus bearbeitet und folgende CERs ermittelt:

Seite/dpi 150 200 300 400
2 3,99 3,5 3,63 3,14
5 2,1 2,37 2,45 2,11
9 6,73 6,81 6,52 6,37

Grob gesagt bedeutet eine geringere Auflösung also eine Verschlechterung der CER – wenn auch im Rahmen von unter einem Prozent.

Ehrlich gesagt, hinken solche Vergleiche der HTR-Ergebnisse aber. Schon die Grundlage der HTR – die Layout Analyse – kommt nämlich bei unterschiedlichen Auflösungen zu latent unterschiedlichen Ergebnissen die im Resultat dann die HTR-Ergebnisse (scheinbar gröbere Analysen erzielen schlechtere HTR-Ergebnisse) aber auch die GT-Produktion selbst beeinflusst (z.B. bei abgeschnittenen Wortbestandteilen).

In unserem Beispiel seht ihr dasselbe image in unterschiedlicher Auflösung. Hier verändert sich das Ergebnis der CITlab Advanced LA mit fortschreitend erhöhter Auflösung. Das initiale „V“ der ersten Zeile wird bei höherer Auflösung nicht mehr erkannt, während Zeile 10 bei höherer Auflösung zunehmend „auseinandergerissen wird“. Mit zunehmender Auflösung wird die LA sensibler – das kann Vor- und Nachteile zugleich haben.

Wichtig ist daher in erster Linie eine für das gesamte Projekt einheitliche dpi-Zahl, damit die durchschnittlichen CER-Werte sowie das gesamte statistische Material belastbar bleiben.