Fünf Stunden, ein Update und die Frage, wann Vorsicht zur Innovation wird

Der Cursor blinkt über einem Absatz, der fast nur aus einer einzigen Markierung besteht: unleserlich, unleserlich, unleserlich. Neunzehn Mal in einem einzigen Satz. Das Dokument stammt aus dem Jahr 1932, geschrieben in einer klaren, gut erhaltenen Kurrentschrift, ein Brief eines Sohnes an seine Mutter. Lesbar für jeden, der etwas Übung mit alten Handschriften hat. Die künstliche Intelligenz, die diesen Brief transkribieren sollte, hatte gerade ein Update bekommen. Sie hätte jetzt besser sein sollen. Stattdessen hatte sie über neunzig Prozent des Textes für unlesbar erklärt.

So endete, vorläufig, ein Arbeitstag, den wir, Christian Gasche und die KI hinter transkriber.de, gemeinsam begonnen hatten. Der Ausgangspunkt war eine naheliegende Idee: Anthropic hatte eine neue Modellgeneration veröffentlicht, Claude Sonnet 5 und Claude Opus 4.8, dazu neue technische Fähigkeiten wie das sogenannte Adaptive Thinking, bei dem das Modell vor seiner Antwort sichtbar nachdenkt. Wer historische Handschriften mit künstlicher Intelligenz lesbar machen will, wie wir es täglich für Familienforscher, Archive und Heimatvereine tun, hat gute Gründe, jede neue Modellgeneration zu testen. Bessere Modelle sollten bessere Lesungen liefern. Diese Annahme war unser Ausgangspunkt. Sie war auch, wie sich zeigen sollte, nur zur Hälfte richtig.

Die Versuchung der neuen Modellgeneration

Um Adaptive Thinking überhaupt nutzen zu können, mussten wir zuerst ein technisches Detail ändern. Die Pipeline zwang das Modell bislang über einen sogenannten erzwungenen Tool-Aufruf dazu, seine Antwort in einem festen, maschinenlesbaren Format zu liefern. Dieser Mechanismus ist mit dem neuen Denkmodus nicht kompatibel. Also ersetzten wir ihn durch ein neueres Verfahren namens Structured Outputs, das dieselbe Formatierung auf andere Weise erzwingt. Das galt zunächst als reine Formsache, eine technische Anpassung ohne inhaltliche Konsequenz.

Getestet haben wir die neue Konfiguration zunächst nicht an transkriber.de selbst, sondern an einem kleineren Schwesterprojekt: einer privaten Anwendung, die seit Monaten ein Familienarchiv aus rund 1.500 Briefen erschließt, mit denselben Prompts, derselben Qualitätslogik, demselben Vorsichtsprinzip. Ein idealer Testfall, weil er über Monate gewachsene, vertraute Referenztexte besitzt und weil ein Fehler dort niemandem außer der eigenen Erwartung schadet.

„Ein Update, das stillschweigend mehr Text für unlesbar erklärt als vorher, ist kein Fortschritt, auch wenn es auf dem Papier moderner aussieht."

Der erste Vergleichslauf gegen dieselben historischen Briefe, mit denen die Pipeline seit Wochen arbeitet, zeigte etwas, das wir beide nicht erwartet hatten: eine dramatische Verschlechterung. Nicht bei einzelnen Briefen, sondern systematisch. Der Brief von 1932 war nur das deutlichste Beispiel unter vielen.

Die Anti-Hudel-Klausel: unsere strengste Regel

Bevor die Geschichte weitergeht, lohnt sich ein Umweg zu der Regel, um die sich an diesem Tag alles drehte. Wir nennen sie intern die Anti-Hudel-Klausel, und ihr Kerngedanke ist denkbar einfach: Im Zweifel gibt das Modell lieber zu, dass es eine Stelle nicht lesen kann, als eine plausible, aber möglicherweise falsche Lesart zu raten. Lieber ein ehrliches [unleserlich] als ein selbstsicher erfundenes Wort.

Diese Regel ist keine technische Fußnote, sie ist eine Haltung. Wer ein historisches Dokument transkribiert, richtet damit womöglich eine Quelle für Historiker, Archive oder Enkelkinder ein. Eine selbstsichere Erfindung ist in diesem Kontext der teurere Fehler, denn sie sieht aus wie Wissen und ist keines. Eine eingestandene Lücke dagegen bleibt sichtbar, überprüfbar, korrigierbar. Wir haben diese Klausel von Anfang an bewusst so streng formuliert, und der heutige Tag hat uns nachträglich recht gegeben, allerdings anders, als wir erwartet hatten: Nicht die Regel war zu streng. Aber sie war stark genug, um mit einer neuen Modellfähigkeit eine Wechselwirkung einzugehen, die wir so nicht vorausgesehen hatten. Dazu gleich mehr.

Wenn Nachdenken zum Problem wird

War also die Vorsicht selbst zu weit gegangen? Wir machten einen gezielten Vergleichstest an genau demselben Bild, mit und ohne die Anti-Hudel-Klausel, mit und ohne Adaptive Thinking. Das Ergebnis war eindeutig. Die Klausel allein veränderte kaum etwas. Erst in Kombination mit dem lauten Nachdenken des Modells eskalierte die Vorsicht: bis zu fünfzehnmal mehr Fehlermarkierungen, ausschließlich durch das Umschalten von Thinking an oder aus, bei identischem Bild und identischer Anweisung. Das Modell schien sich während des Nachdenkens regelrecht in den eigenen Zweifel hineinzusteigern, bis am Ende selbst eindeutig lesbarer Text als hoffnungslos markiert wurde.

Das ist, für eine reine Wahrnehmungsaufgabe wie das Lesen einer Handschrift, eine bemerkenswerte Erkenntnis. Mehr Bedenkzeit führt bei einer Schachaufgabe zu einer besseren Zugfolge. Bei der Frage, ob ein verblasster Buchstabe ein a oder ein o ist, führt mehr Nachdenken nicht notwendig zu einem schärferen Blick. Es kann stattdessen dazu führen, dass sich das Modell selbst von seiner ersten, richtigen Lesung wieder abbringt.

Der zweite, unbequemere Fehler

An dieser Stelle hätte die Geschichte enden können: neue Funktion getestet, Problem gefunden, Funktion wieder abgeschaltet, fertig. Genau an diesem Punkt setzte Christian eine Grenze, die für den Rest des Tages entscheidend wurde: keine Optimierung um jeden Preis, sondern der Nachweis einer echten Qualitätsverbesserung, auch wenn das bedeutete, weiterzusuchen, statt ein bequemes Zwischenergebnis zu akzeptieren. Diese Haltung war es, die den eigentlichen Fehler erst sichtbar machte.

Ein größerer Vergleichslauf über dreißig Briefe schien zunächst zu belegen, dass selbst das alte, seit Monaten bewährte Modell plötzlich massiv schlechter abschnitt, ganz ohne die neuen Funktionen. Das ergab keinen Sinn, und wir akzeptierten es deshalb nicht als Endergebnis. Erst eine genaue Prüfung der Testdaten deckte den eigentlichen Fehler auf: Von den dreißig Vergleichsbriefen waren achtundzwanzig gar keine KI-Transkriptionen, sondern von Hand abgetippte Referenztexte, die ursprünglich zur Qualitätskontrolle angelegt worden waren. Unser Vergleich hatte also nicht KI gegen KI gemessen, sondern KI gegen Mensch, und ein Mensch, der sich Zeit für eine sorgfältige Abschrift nimmt, gewinnt diesen Vergleich fast immer, unabhängig davon, welches Modell dahinter steht.

„Ein Testergebnis ist nur so ehrlich wie die Referenz, gegen die es gemessen wird, und die eigene Referenz zu misstrauen fällt schwerer als der Software zu misstrauen."

Erst ein bereinigter Test, der ausschließlich gegen echte, bereits gespeicherte KI-Transkriptionen verglich, zeigte das tatsächliche Bild: Die vorsichtige, überarbeitete Konfiguration, ohne Adaptive Thinking, ohne Structured Outputs, mit denselben altbewährten Modellen wie zuvor, schnitt im Schnitt geringfügig besser ab als der alte Stand. Kein Sprung, aber ein echter, belegter Fortschritt, nur eben ein bescheidener, und genau der, den wir uns vorgenommen hatten, statt eines unbelegten großen Versprechens.

Diese zweite Korrektur wiegt schwerer als die erste. Einen Softwarefehler zu finden ist Handwerk. Der eigenen Messmethode zu misstrauen, obwohl sie zunächst ein bequemes, in sich schlüssiges Ergebnis geliefert hatte, ist etwas anderes. Es hätte genauso gut unentdeckt bleiben können, mit der Konsequenz, dass wir ein tatsächlich funktionierendes Update verworfen hätten, aus Angst vor einem Problem, das gar nicht existierte.

Vom Labor auf den Server

Die Prüfung an der privaten Testumgebung war noch nicht beendet, als sich herausstellte, dass die Frage keine akademische mehr war. Transkriber.de selbst hatte, in einer separaten Sitzung desselben Tages, bereits dieselbe riskante Kombination aus Adaptive Thinking und Structured Outputs produktiv ausgerollt. Nicht in einer Testumgebung, sondern live, für zahlende Kunden, die in diesem Moment Dokumente hochluden.

Den identischen Fix haben wir deshalb unmittelbar auf das Produktivsystem übertragen, und zwar über den etablierten Weg: direkte Verbindung zum Server, keine Abkürzung über automatisierte Werkzeuge, jeder Schritt einzeln bestätigt, vom Kopieren der Datei über das Stoppen und Neustarten des betroffenen Dienstes bis zur Kontrolle, dass der nächste eingehende Kundenauftrag den Prozess ohne Absturz durchlief. Die öffentliche Website blieb währenddessen durchgehend erreichbar, betroffen war ausschließlich der Hintergrunddienst, der die eigentliche Texterkennung übernimmt.

Diese Umständlichkeit ist Absicht, nicht Zufall. Wer an einem System arbeitet, das echte Dokumente echter Menschen verarbeitet, verzichtet auf Abkürzungen, die zwar schneller wären, aber im Fehlerfall schwerer rückgängig zu machen sind. Die Deutsche Digitale Bibliothek, die selbst umfangreiche Erfahrung mit der Digitalisierung historischer Bestände hat, weist in ihren Grundsätzen zur Langzeitverfügbarkeit auf denselben Gedanken hin: Verlässlichkeit entsteht nicht durch die neueste Technik, sondern durch die Disziplin, mit der sie eingeführt wird.

Was ein einziges Testdokument verrät

Ein Nebenfund dieses Tages hatte mit der Software selbst nichts mehr zu tun, sondern mit denjenigen, die sie nutzen. Ein kostenloser Testzugang hatte ein einziges Dokument hochgeladen, ein Chronik- oder Registereintrag aus den Jahren 1621 bis 1635, geschrieben in einer vierhundert Jahre alten Kanzleischrift. Das Ergebnis enthielt tatsächlich lesbare Fragmente, Jahreszahlen, Namen, einzelne Sätze, aber auch einen sehr hohen Anteil an eingestandener Unlesbarkeit.

Das ist kein Softwarefehler. Kanzleischriften des frühen siebzehnten Jahrhunderts gehören zu den anspruchsvollsten Aufgaben der historischen Hilfswissenschaften überhaupt, mit eigenen Abkürzungssystemen, wechselnden Schreibkonventionen und oft stark verblasster Tinte. Wer sich mit historischer Paläografie beschäftigt, weiß, dass selbst geübte Handschriftenexperten für einzelne Seiten dieser Zeit mehrere Anläufe benötigen.

Das Muster, das sich hier zeigt, ist ein anderes: Kostenlose Testzugänge laden auffällig oft nicht einen durchschnittlichen Brief hoch, sondern genau das schwierigste Einzeldokument, das sie besitzen, häufig eines, an dem bereits ein professioneller Handschriftenkenner gescheitert ist. Danach wird über das gesamte Produkt geurteilt, anhand eines einzigen, bewusst gewählten Grenzfalls. Eine verständliche menschliche Reaktion, aber eine, die eine ehrliche Einordnung verdient: Manche Dokumente sind schwer, unabhängig davon, welche Intelligenz sie liest.

Warum Vorsicht manchmal die eigentliche Innovation ist

Am Ende des Tages stand kein spektakulärer Durchbruch, sondern etwas Bescheideneres und, mit etwas Abstand betrachtet, Wichtigeres. Die Anti-Hudel-Klausel, unsere Regel, im Zweifel lieber Unsicherheit zuzugeben als zu raten, hat sich bewährt. Sie erwies sich sogar als so wirksam, dass sie in Kombination mit lautem Nachdenken die Fähigkeiten des Modells eher blockierte als freisetzte, eine Nebenwirkung, die erst durch systematisches Nachmessen sichtbar wurde, nicht durch Intuition, und nur deshalb, weil wir uns nicht mit dem ersten Ergebnis zufriedengaben.

Für die schwierigsten Einzelfälle, jene Dokumente, an denen sowohl das Standardmodell als auch die anschließende Qualitätsprüfung scheitern, bieten wir mit Claude Fable 5 weiterhin eine letzte, bewusst teurere Eskalationsstufe an. Sie wird manuell ausgelöst, für einzelne Dokumente, nicht als stiller Standard für jeden Upload, und sie verzichtet auf genau die Kombination aus Denkmodus und struktureller Ausgabe, die sich an diesem Tag als Schwachstelle erwiesen hatte.

Die eigentliche Verbesserung dieser fünf Stunden war deshalb nicht die neue Technik. Es war unsere Bereitschaft, einer plausiblen Annahme so lange zu misstrauen, bis sie entweder widerlegt oder bestätigt ist, auch wenn das zwei Selbstkorrekturen kostet und am Ende nur ein kleiner, dafür aber echter Fortschritt übrig bleibt. Ein Update, das man versteht, ist mehr wert als eines, dem man nur vertraut.