Dirk Alvermann


Posted by Dirk Alvermann on

Anwendungsfall: „Modell Booster“

Release 1.10.1

Unser Beispiel ist die Verbesserung unseres HTR-Modells für die Spruchakten. Das ist ein HTR-Modell, dass Kurrentschriften des 17. Jahrhunderts lesen kann. Auf der Suche nach einem möglichen Base Model findet man in den „public models“ von Transkribus zwei Kandidaten, die in Frage kommen: „German Kurrent M1+“ vom Transkribus Team und „German_Kurrent_XVI-XVIII_M1“ von Tobias Hodel. Beide könnten passen. Der Test auf dem Sample Compare ergibt allerdings, dass „German_Kurrent_XVI-XVIII_M1“ mit einer vorhergesagten mittleren CER von 9,3% auf unserem Sample Set die bessere Performance zeigte.

Für das Training wurde also „German_Kurrent_XVI-XVIII_M1“ als Base Model ausgewählt. Danach wurde der Ground Truth der Spruchakten (108.000 Wörter) und auch das Validation Set unseres alten Modells hinzugefügt. Die durchschnittliche CER unseres HTR-Modells hat sich nach dem Base Model Training erheblich verbessert, von 7,3% auf 6.6%. In der Grafik seht ihr, dass das Base Model auf dem Testset zwar wesentlich schlechter gelesen hat, als das Originalmodell, dass der Hybrid aus beiden aber besser ist als beide einzeln. Die Verbesserung des Modells ist in jedem einzelnen der getesteten Jahre zu beobachten und beträgt bis zu 1%.

Posted by Dirk Alvermann on

Modelle kombinieren

Release 1.10.1

Je länger man selbst HTR-Modelle trainiert, desto mehr beschäftigt man sich auch mit der Möglichkeit Modelle zu kombinieren. Es kann zum Beispiel sein, dass man mehrere Spezialmodelle für einzelne Schreiber oder auch Modelle, die auf besonderen Schriftarten oder Sprachen spezialisiert sind miteinander kombinieren möchte.

Ulm eine Kombination von Modellen zu erreichen gibt es verschiedenen Möglichkeiten. Hier möchte ich eine Technik vorstellen, die vor allem für sehr große generische Modelle aus meiner Erfahrung gut funktioniert – der „Model Booster“.

Dabei startet man ein Base Model Training und verwendet ein möglichst mächtiges fremdes HTR-Model als Base Model und den eigenen Ground Truth als Train Set. Bevor ihr startet aber noch zwei Ratschläge:

a) schaut euch genau die Eigenschaften des verwendeten Base Models an (für welche Zeit ist es Trainiert, für welchen Schriftstil und welche Sprache?) – sie müssen mit denen eures eigenen Materials möglichst übereinstimmen.

b) wenn möglich versucht die Performance des Base Models auf eurem eigenen Material vorherzusagen und entscheidet euch dann für das Base Model mit der besten Performance. Eine solche Vorhersage kann man recht über die Funktion Sample Compare machen. Eine andere Möglichkeit ist, das Basemodel mit dem Andvanced Compare auf dem eigenen Testset zu überprüfen.

Posted by Dirk Alvermann 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 Dirk Alvermann 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 Dirk Alvermann 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 Dirk Alvermann 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 Dirk Alvermann 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 Dirk Alvermann 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 Dirk Alvermann on

Strukturtagging – wofür das noch gut ist (Layout and beyond)

Im einem der letzten Beiträge habt Ihr gelesen, wie bei uns ein Strukturtagging durchführt wird. Wie der gesamte Werkzeugkasten des Strukturtaggings funktioniert, könnt ihr hier nachlesen. In unserem Projekt dient es v.a. dazu, ein angepasstes LA-Modell für die mixed layouts zu erstellen. Aber da steckt noch mehr Potential drin.

Wer kennt das Problem nicht?

Wenn sich auf einer Seite mehrere, sehr unterschiedliche Handschriften befinden, wird es schwierig, gleichmäßig gute HTR-Ergebnisse zu bekommen. Am häufigsten kommt das vor, wenn eine ‚saubere‘ Handschrift von einem weiteren Schreiber in einer Konzeptschrift kommentiert worden ist. Hier seht ihr so ein Beispiel:

Der eigentliche Grund für das Problem ist, dass die HTR bislang ausschließlich auf der Ebene der Seite ausgeführt wird. Das heißt, ich kann die Seite oder Seiten entweder mit dem einen oder dem anderen HTR-Modell lesen lassen, aber nicht mit zwei verschiedenen, die den jeweils vorkommenden Handschriften angepasst wären.

Seit Version 1.10. ist es möglich,  HTR-Modelle auf der Ebene der Textregionen anzuwenden und nicht nur den Seiten zuzuweisen. Dadurch können die Inhalte einzelner spezifischer Textregionen auf einer Seite mit unterschiedlichen HTR-Modellen gelesen werden. Hier spielt das Strukturtagging eine wichtige Rolle, zum Beispiel bei Textregionen, mit vom Haupttext abweichenden Schriften. Diese erhalten einen bestimmten Strukturtag, dem wiederum ein spezielles HTR-Modell zugewiesen wird. Grund genug also, sich mit Strukturtagging auseinander zu setzen.

Posted by Dirk Alvermann on

P2PaLA vs. Standard LA

Release 1.9.1

Im vorigen Post haben wir beschrieben, dass – wenn die Layouts der Dokumente sehr anspruchsvoll sind – die Standard LA in Transkribus nicht immer befriedigende Ergebnisse liefert. Für ein perfektes HTR-Ergebnis braucht man aber eine perfekte LA.

Vor allem in den Dokumenten des 16. und frühen 17. Jahrhunderts konnte die CITlab Advanced LA uns nicht überzeugen. Wir hatten von Anfang an nicht erwartet, dass die Standard LA die anspruchsvolleren Layouts (Textregionen) differenziert erkennt. Es war aber die line detection, die am Ende unseren Ansprüchen bei diesen Dokumenten nicht mehr genügen konnte.

Ein Beispiel dafür, wie (im schlimmsten Fall) die line detection der Standard LA auf unserem Material arbeitete, seht ihr hier:


1587, page 41

Dies kann ein Einzelfall sein. Wenn man aber große Mengen von Dokumenten in Transkribus verarbeitet, können solche Fälle häufiger auftreten. Um das Problem richtig bewerten zu können, haben wir daher an zwei Konvoluten unseres Materials eine repräsentative Fehlerstatistik aufgenommen. Es zeigt sich, dass die Standard LA hier mit durchschnittlich 12 Fehlern in der line detection pro Seite arbeitete (siehe Grafik unten, 1598). Das hat natürlich unerwünschte Auswirkungen auf das HTR-Ergebnis, die wir im nächsten Post näher beschreiben.