Handschriftenerkennung & Transkription historischer Dokumente

Archive, Bibliotheken, Unternehmen und Familien besitzen enorme Mengen handschriftlichen und historischen Materials, das nicht durchsuchbar ist und nur von wenigen Fachleuten gelesen werden kann. Modelle zur Handschriftenerkennung (Handwritten Text Recognition, HTR) und Vision-Language-Modelle (VLMs) wandeln Seitenbilder in Text mit Koordinaten und Konfidenzwerten um. Ein Mensch korrigiert und gibt das Ergebnis frei. Der Nutzen ist Zugang: Ganze Bestände werden im Volltext durchsuchbar, und routinemäßige handschriftliche Formulare müssen nicht mehr abgetippt werden.

Problem & Nutzen

• Heute: Die Transkription erfolgt manuell (Ehrenamtliche, Paläografen, Erfassungskräfte) oder ist durch klassische OCR auf gedruckten Text beschränkt. Diese scheitert an Kurrentschrift, Sütterlin, Abkürzungen und beschädigtem Papier. Bestände bleiben unerschlossen; handschriftliche Formulare und Notizen werden neu abgetippt.
• KI-Nutzen: automatische Zeilensegmentierung und Erkennung, auch bei unvollkommener Fehlerrate durchsuchbar (Keyword Spotting und unscharfe Suche), schnellere erste Entwürfe für die menschliche Korrektur sowie strukturierte Extraktion aus Registern.
• Belege zum Umfang (Herstellerangaben): Transkribus nennt mehr als 200 Millionen transkribierte Seiten, über 300 Community-Modelle und mehr als 100 Sprachen/Schriften einschließlich Kurrent und Sütterlin; ein zitiertes Universitätsprojekt transkribierte 20.000 Seiten in zwei Monaten [1]. Dies sind Herstellerangaben, keine unabhängigen Messungen.
• Unabhängige Belege: Ein akademischer Benchmark (moderne und historische Handschriften auf Englisch, Französisch, Deutsch und Italienisch) stellte fest, dass multimodale LLMs bei moderner Handschrift sehr gut sind und bei Englisch besser abschneiden als bei anderen Sprachen; weder LLMs noch Transkribus-Modelle lagen durchgehend vorn. LLMs konnten ihre eigenen Zero-Shot-Fehler nicht zuverlässig korrigieren [6].

Varianten

• Archive, Bibliotheken, Museen: Massendigitalisierung von Manuskripten, Kirchenbüchern und Personenstandsregistern mit ALTO/PAGE-XML-Ausgabe und digitalen Editionen.
• Digital Humanities / Genealogie: Forschungsprojekte und Familienforschende (auch mit Briefen in Kurrent/Sütterlin) – private Nutzung ist über Abo-Werkzeuge realistisch.
• Öffentliche Verwaltung: ältere Papierakten, handschriftliche Anträge, Grundbücher und Gebäuderegister.
• Unternehmen: handschriftliche Formulare, Anmerkungen auf Lieferscheinen, Labor- und Wartungsprotokolle, Notizen des Außendienstes (Überschneidung mit DOC-003, DOC-006, DOC-007).
• Gesundheitswesen: handschriftliche ärztliche Notizen/Rezepte; die Extraktion aus Patientenakten wird in DOC-007 behandelt.
• Strukturierte Registerextraktion: Tabellen mit Einträgen (Namen, Daten, Beträge) in Datensätze überführen, statt Fließtext zu erkennen.

So funktioniert es

1. scan / photo (300+ dpi, deskew, contrast)
2. layout analysis (regions, lines, reading order, tables)
3. text recognition (HTR model or VLM)
4. text + confidence per line
5. optional post-correction (LLM with glossary, spelling variants kept)
6. human review & correction (highlighted low-confidence lines)
7. export (ALTO/PAGE XML, TEI, searchable PDF, JSON) + entity tagging
8. search index / edition / database; corrections feed model retraining

• HTR-Engines sind trainierte Erkennungs- und Segmentierungsmodelle (CRNN-/Transformer-basiert, z. B. Kraken, TrOCR-artig), die je Handschrift, Epoche oder Schrift mit transkribierten Beispielseiten trainiert werden [3][5].
• VLMs lesen das Seitenbild im Zero-Shot-Verfahren, benötigen oft kein Training, können Text aber unbemerkt „normalisieren“ oder erfinden.
• Mensch-in-der-Schleife (Human-in-the-Loop): für Editionen und rechtliche Nutzung zwingend; bei reiner Suchnutzung genügt stichprobenbasierte Qualitätssicherung.

Datenaufbereitung

Daten: Seitenbilder von Briefen, Registern, Kontobüchern, Formularen und Notizen sowie eine kleine Menge von Referenztranskriptionen (Ground Truth). Im Mittelstand liegen sie in Papierordnern, Kellerarchiven, auf Dateifreigaben mit unbeschrifteten Scans oder in E-Mail-Anhängen; in Archiven sind es gebundene Bände und Mikrofilme.

Typische Lücken: niedrige Auflösung oder Handyfotos, schiefe und beschnittene Seiten, gemischte Handschriften und Epochen, keine Seitenreihenfolge oder Metadaten, keine transkribierten Beispiele sowie personenbezogene Daten mit Aufbewahrungsfristen oder Zugriffsbeschränkungen.

Aufbereitungsschritte: 1. Bestände inventarisieren und priorisieren (PREP-001, PREP-002); entscheiden, was die Transkription wert ist. 2. Mit mindestens 300 dpi digitalisieren, unkomprimiert oder verlustfrei, mit einheitlicher Benennung (PREP-006). 3. Schräglage korrigieren, beschneiden und Kontrast verbessern; nach Handschrift, Epoche und Schrift sortieren. 4. Minimale Metadaten ergänzen (Quelle, Datum, Signatur) und eine Transkriptionsrichtlinie samt Glossar der Namen und Orte festlegen (PREP-015). 5. 50-100 repräsentative Seiten als Ground Truth für Bewertung und Feintuning transkribieren (PREP-018, PREP-016). 6. Rechtsgrundlage und Schutzfristen prüfen, bevor personenbezogene Daten verarbeitet werden (PREP-025).

Werkzeuge: Scanner oder Buchwiegen, ScanTailor, OCRmyPDF, Transkribus oder eScriptorium für Ground Truth.

Aufwandsanteil: Etwa 50-60 Prozent des Projekts entfallen auf Scannen, Sortieren und Ground Truth; die Erkennung selbst geht schnell. Siehe auch: DOC-014, DOC-018, GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Ausgereifte Transkriptionsplattformen aus der EU gibt es zu bezahlbaren Seitenpreisen, und die Arbeit ist eine standardisierte, projektbezogene Aufgabe.
• Großunternehmen: Weg B. Firmenarchive und Register brauchen meist eine Übergabe der Ergebnisse an DMS- oder Fallbearbeitungssysteme, was eine API-Integration erfordert.
• Entwickler: Weg C. Open-Source-HTR-Engines (z. B. Kraken) lassen sich auf eigene Handschriften und Schriften trainieren und frei einbetten.
• Privat: Weg A. Genealogen und Hobbyforschende erzielen mit fertigen Apps ohne jede Einrichtung die besten Ergebnisse.
• Öffentlicher Sektor: Weg C. Archive und Bibliotheken brauchen souveränen Betrieb und offene Formate (ALTO/PAGE XML) und betreiben Community-Plattformen oft auf eigener oder deutscher Cloud-Infrastruktur.

Weg A — Kaufen (empfohlen)

• Transkribus (READ-COOP SCE, Österreich – EU): die Referenzplattform für historische Dokumente; über 300 Modelle, Training eigener Modelle, Erkennung von Layout, Tabellen und Feldern, API ab dem Scholar-Tarif. Die Daten bleiben auf den Servern der Genossenschaft in Österreich. Öffentliche Preise zum Recherchezeitpunkt: kostenlos 50 Credits/Monat; Scholar 99 €/Jahr; Team 449 €/Jahr; HTR kostet 1 Credit pro Seite, API-Aufträge die Hälfte der Credits [2]. On-Premises wird nicht beworben – beim Hersteller nachfragen.
• eScriptorium (EPHE/PSL Paris, Open Source, selbst hostbar): eine Transkriptionsumgebung auf Basis von Kraken [3][4].
• Allgemeine Dokumenten-KI-Produkte (Azure Document Intelligence Read, Google Document AI, ABBYY, Adobe) für moderne Handschrift in Formularen; schwächer bei historischen Handschriften. EU-Region und AVV prüfen.
• A wählen, wenn: ein Bestand von bis zu einigen hunderttausend Seiten vorliegt und kein internes ML-Team vorhanden ist.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Multimodale Spitzenmodelle (Gemini-, Claude-, GPT-Familien) mit Seitenbildern und einem Prompt, der eine diplomatische Transkription verlangt; Gemini akzeptiert PDFs bis zu 1.000 Seiten [8]. Mistral OCR (EU-Anbieter, Batch-API) für gemischten Druck und Handschrift [7]. Azure Document Intelligence prebuilt-read extrahiert handschriftlichen Text und markiert handschriftliche Zeilen mit Konfidenz [9].
• Muster: Segmentierung durch ein Layout-Werkzeug, VLM-Aufruf auf Zeilen- oder Seitenebene, Konfidenz über Selbstkonsistenz (zweimal ausführen, vergleichen) oder Logprobs, Oberfläche zur Prüfung. Für personenbezogene Daten EU-Regionen und Verträge ohne Datenspeicherung (Zero Retention) nutzen.
• B wählen, wenn: moderne Handschrift vorliegt, viele verschiedene Hände vorkommen oder keine Zeit bleibt, Modelle je Handschrift zu trainieren.

Weg C — Selbst betreiben (Open Source)

• Kraken (Apache-2.0, trainierbare Layout- und Texterkennung, ALTO-/PAGE-Ausgabe) mit eScriptorium [3][4].
• Offene VLMs: Qwen3-VL (Apache-2.0; 2B–235B, 32 OCR-Sprachen einschließlich seltener Zeichen) [10]; olmOCR-2 (Apache-2.0, 7B FP8, ≥12 GB GPU) vor allem für Druck und saubere Layouts [11]; Docling/Granite-Docling (MIT) für Layout-Analyse [12].
• Hardware: HW2 (eine GPU mit 24–32 GB) zum Training von Zeilenerkennern und zum Betrieb von 7–8B-VLMs; für Kraken-Inferenz bei geringem Volumen genügt auch eine reine CPU.
• C wählen, wenn: sensible personenbezogene Daten (Gesundheit, Gericht, Asylakten) das Haus nicht verlassen dürfen.

Weg D — Eigenes Training

Für historisches Material meist der Standardweg: ein HTR-Modell auf 25–100+ transkribierten Seiten der konkreten Handschrift/Epoche feintunen (die Workflows von Transkribus und Kraken sind dafür gebaut). Das Feintuning eines VLM lohnt sich nur bei großen, homogenen Beständen. Die Qualität der Ground Truth (einheitliche Transkriptionsregeln) zählt mehr als die Menge.

Stand der Technik (2026)

• Zwei Welten nähern sich an: Spezialisierte HTR (Transkribus, Kraken) liefert kontrollierbare, koordinatengenaue, trainierbare Ergebnisse; multimodale LLMs liefern starke Zero-Shot-Ergebnisse bei moderner Handschrift und gemischten Dokumenten. Benchmarks zeigen keinen durchgehenden Sieger; LLMs sind bei Englisch und modernen Handschriften am besten [6].
• Bewährte Praxis: hybrid – HTR/Segmentierung für die Geometrie, VLM für schwierige Zeilen oder zur Nachkorrektur, konfidenzbasierte Prüfung.
• Grenzen und Fehlerbilder:
• LLMs halluzinieren plausible Wörter, modernisieren die Schreibweise und lösen Abkürzungen ungefragt auf – fatal für diplomatische Editionen.
• Namen, Zahlen und Daten in Registern sind die fehleranfälligsten Felder; immer stichprobenartig prüfen.
• Die Genauigkeit sinkt bei nicht englischen Texten, seltenen Schriften, durchscheinender Rückseite, beschädigtem Papier und dichten Randnotizen.
• Berichtete Fehlerraten hängen von der Handschrift ab; CER/WER stets an der eigenen Stichprobe messen.
• Tabellen sowie gemischter Druck und Handschrift brauchen eine eigene Layout-Behandlung.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie in der Dokumentenfamilie: ocr-docparse + vlm + llm-general bedienen DOC-001 (Rechnungen), DOC-003 (Formulare), DOC-007 (Patientenakten) und DOC-008 (Posteingangsklassifikation) auf einem VLM-Server (HW2/HW3).
• Nachgelagert: DOC-014 (Parsing für RAG), KNOW-001 (Unternehmenssuche über transkribierte Archive), embedding-text + search-engine / Vektorindex für semantische Archivsuche, LANG-005 (Übersetzung transkribierter historischer Texte), Entitätsextraktion mit einem text-classifier/NER-Modell.
• Gemeinsame Datenpipelines: Scan-Vorverarbeitung, Prüfoberfläche, Ground-Truth-Speicher und Nachtrainingsschleife sind für jeden Erfassungs-Anwendungsfall wiederverwendbar.

Aufwand, Kosten & Kennzahlen

• Weg A: Einrichtung in Tagen; Kosten pro Seite/Credit plus Prüfaufwand.
• Weg B: 1–2 Monate für eine Pipeline mit Prüfoberfläche; API-Kosten pro Seite plus Prüfaufwand.
• Weg C/D: 2–4 Monate einschließlich Erstellung der Ground Truth und einer GPU-Workstation; das Training je Bestand dauert Stunden bis Tage.
• Kennzahlen: Zeichen-/Wortfehlerrate an einer zurückgehaltenen Stichprobe, Anteil der Zeilen mit Korrekturbedarf, Korrektur- minuten pro Seite, Such-Recall, Seiten pro Tag, Kosten pro Seite.

Menschen & Veränderung

Früh einbinden: Geschäftsleitung (Umfang, Budget), die Abteilungsleitung oder Archivarin bzw. den Archivar als Prozessverantwortliche, die Endanwender, die Korrektur lesen, die IT (Speicher, Konten), die Datenverantwortlichen der Bestände und die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten. Die/den Datenschutzbeauftragte(n) vor Beginn des Scannens einbeziehen, wenn das Material personenbezogene Daten enthält, etwa Personenstandsregister oder Personalakten.

Betriebsrat: in der Regel nicht betroffen. Das System verarbeitet Dokumente, nicht das Verhalten von Beschäftigten; §87 Abs. 1 Nr. 6 BetrVG greift nur, wenn Produktivität oder Fehlerquoten der Prüfenden je Person protokolliert werden. Den Betriebsrat dennoch nach §90 Abs. 1 Nr. 3 informieren, wenn sich Arbeitsabläufe ändern; im öffentlichen Dienst gilt der Personalrat. Siehe GUIDE-004.

Datenschutz: Rechtsgrundlage und Aufbewahrung prüfen; für große Bestände sensibler personenbezogener Daten ist wahrscheinlich eine Datenschutz-Folgenabschätzung (DSFA) nötig, und jeder Cloud-Anbieter braucht einen Auftragsverarbeitungsvertrag (AVV) (GUIDE-005).

KI-Kompetenz: Die KI-Verordnung (AI Act, Art. 4) verlangt Maßnahmen zur Förderung der KI-Kompetenz der Beschäftigten; eine kurze Schulung dazu, wie HTR Fehler macht, warum Konfidenzwerte wichtig sind und wie VLMs Text erfinden können, genügt (GUIDE-006).

Kommunikation und Pilot: einen Band oder eine Handschrift als Pilot mit zwei oder drei Freiwilligen wählen und Zeichenfehlerrate sowie Korrekturzeit messen (GUIDE-009).

Typische Bedenken: Angst, Fachleute zu ersetzen (sie werden zu Prüfenden und Qualitätsverantwortlichen), Vertrauen in die Ergebnisse (die Konfidenzhervorhebung zeigen) und redaktionelle Integrität (Menschen geben jeden Editionstext frei).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Transkription selbst hat minimales Risiko (Pflicht zur KI-Kompetenz, Art. 4). Hochrisiko wird sie nur, wenn ihr Ergebnis in ein System für Entscheidungen nach Anhang III einfließt (z. B. Asyl/Migration, Anspruch auf Leistungen, Beweismittel der Strafverfolgung); dann trägt das nachgelagerte System die Pflichten. Keine verbotene Praktik.
• DSGVO: Handschriftliche Dokumente enthalten oft besondere Kategorien personenbezogener Daten (Gesundheit, Religion in Kirchenbüchern); lebende Personen erfordern eine Rechtsgrundlage; Archiv- und Forschungsprivilegien (Art. 89) sowie nationale Archivgesetze gelten. EU-Hosting (Transkribus: Österreich) oder Selbstbetrieb bevorzugen.
• Authentizität & Recht: Eine maschinelle Transkription ist keine beglaubigte Abschrift; das Originalbild als maßgebliche Quelle aufbewahren. Für steuerrelevante Dokumente gelten die GoBD-Regeln zur nachvollziehbaren Umwandlung.
• Gegenmaßnahmen: Richtlinie diplomatische vs. normalisierte Transkription, Konfidenzschwellen, versionierte Korrekturen, klare Kennzeichnung KI-erzeugter Transkripte.

Erste Schritte

1. 50 repräsentative Seiten auswählen (beste, typische, schlechteste) und 10–20 davon von Hand als Ground Truth transkribieren.
2. Sie durch Transkribus (öffentliche Modelle), eine VLM-API und bei Bedarf Kraken laufen lassen; CER/WER berechnen.
3. Transkriptionsregeln (Abkürzungen, Schreibweise, Zeilenumbrüche) festlegen, bevor irgendetwas trainiert wird.
4. Ein HTR-Modell auf 25–100 Seiten feintunen oder eine VLM-Pipeline mit konfidenzbasierter Prüfung aufsetzen.
5. In ALTO/PAGE XML oder einen Suchindex exportieren; vor der Veröffentlichung die datenschutzrechtliche Grundlage für personenbezogene Daten prüfen.

Quellen

1. Transkribus (READ-COOP) — platform overview and stated figures — https://www.transkribus.org/
2. Transkribus — pricing, credits per page, API — https://www.transkribus.org/pricing
3. Kraken OCR/HTR engine (Apache-2.0) — https://github.com/mittagessen/kraken
4. eScriptorium documentation (EPHE/PSL) — https://escriptorium.readthedocs.io/en/latest/
5. TrOCR: Transformer-based OCR with pre-trained models — https://arxiv.org/abs/2109.10282
6. Crosilla, Klic, Colavizza — Benchmarking Large Language Models for Handwritten Text Recognition — https://arxiv.org/abs/2503.15195
7. Mistral AI — OCR documentation — https://docs.mistral.ai/capabilities/document_ai/basic_ocr/
8. Google — Gemini API document processing — https://ai.google.dev/gemini-api/docs/document-processing
9. Microsoft — Azure Document Intelligence Read model — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/read
10. Qwen3-VL — https://github.com/QwenLM/Qwen3-VL
11. olmOCR (AI2) — https://github.com/allenai/olmocr
12. Docling — https://github.com/docling-project/docling
13. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj