KI-Transkriptionsgenauigkeit: Warum Anbieter-Benchmarks täuschen und wie wir Modelle wirklich testen

Wenn Sie herausfinden möchten, welches Speech-to-Text-Modell am genauesten ist, ist die veröffentlichte Benchmark-Zahl der falsche Ort, um nachzusehen. Die werbewirksame Genauigkeitsangabe eines Anbieters ist ein optimiertes Ergebnis auf einem sauberen, vorgelesenen Datensatz – sie sagt fast nichts darüber aus, wie das Modell mit dem Audio umgeht, das Sie tatsächlich haben: eine Produktbesprechung gespickt mit Markennamen und Fachjargon, ein Meeting, in dem zwei Personen durcheinanderreden, ein starker Akzent, ein Creator, der ständig zwischen Sprachen wechselt.

Ich betreibe Subanana, ein KI-Speech-to-Text-Tool. Wir leiten jede Transkription durch einen Stapel evaluierter Modelle und testen diesen Stapel laufend neu. In diesem Beitrag geht es darum, wie wir testen – die Methodik, die Kriterien und die echten Ergebnisse aus einem unserer eigenen Evaluierungsläufe – und warum wir den veröffentlichten Genauigkeitswerten der Anbieter für solche Entscheidungen nicht mehr trauen.

Das Wichtigste in Kürze

• Genauigkeits-Benchmarks von Anbietern (ein einzelner WER-Wert, „98 % genau") sind größtenteils Benchmark-Maxing – gemessen an sauberem, skriptiertem Audio mit einer einzelnen Sprecherin oder einem einzelnen Sprecher, das mit echten mehrsprachigen, akzentbehafteten Aufnahmen oder solchen mit mehreren Sprechern nichts zu tun hat.
• Deshalb wählen wir Modelle nicht nach ihren veröffentlichten Zahlen aus. Wir testen sie an unserem eigenen unsauberen, realen Audio und beurteilen die Ausgabe so, wie es eine Redakteurin oder ein Redakteur tun würde: Hat es falsch verstandene Wörter korrigiert, liest es sich wie saubere Schriftsprache und – entscheidend – hat es keine Fakten verändert?
• In einem echten Evaluierungslauf schlug ein kleines, schnelles Modell unsere schwerere Produktions-Standardeinstellung (etwa 92 % Richter-Präferenz, rund 13× schneller). Größer und langsamer war nicht genauer.
• Der Fehler, der den Punkt beweist: Ein Modell schrieb einen Kamerasensor „LYT-828" still und heimlich zu „LYT-808" um – sauber lesbar, faktisch falsch und für einen WER-Wert unsichtbar.
• Sie evaluieren ein Tool selbst? Testen Sie Ihr schwierigstes echtes Audio – die Akzente, das Durcheinanderreden, den Jargon, den Sprachwechsel –, beobachten Sie die Zeitstempel auf dem Bildschirm und suchen Sie nach faktischer Verfälschung, nicht nach der Bestenlisten-Zahl.

Warum sind Transkriptions-Benchmarks von Anbietern irreführend?

Eine veröffentlichte Wortfehlerrate (Word Error Rate, WER) oder Genauigkeitsangabe in Prozent ist eine einzelne Zahl, die unter Bedingungen entsteht, die der Anbieter selbst gewählt hat. Drei Dinge machen sie für die Auswahl eines Produktionsmodells nahezu nutzlos:

• Der Testdatensatz ist sauber. Benchmark-Audio ist meist skriptiert, mit einer einzelnen Person, in einem ruhigen Raum aufgenommen, in einer ressourcenstarken Sprache. Echtes Audio ist nichts davon.
• Die Metrik ist grob. Die WER zählt Ersetzungen, Einfügungen und Auslassungen gleich. Aber eine Modellnummer falsch wiederzugeben (aus einem „Vivo X30" wird ein „Vivo X90") ist ein katastrophaler Fehler, während ein fehlendes Komma harmlos ist. Die WER bewertet beides gleich.
• Es ist die Anzeigetafel des Anbieters selbst. Jedes Labor berichtet die Konfiguration, in der sein Modell am besten dasteht. Sie lesen den Höchststand, nicht das zu erwartende Ergebnis.

Nichts davon ist im engeren Sinne unredlich. Es ist einfach Benchmark-Maxing – Optimierung auf die Bestenliste statt auf Ihren Anwendungsfall. Wenn wir also Modelle evaluieren, zitieren wir keine veröffentlichte Zahl. Wir lassen das Modell auf dem unsauberen, sprachgemischten, realen Audio laufen, das unsere Nutzerinnen und Nutzer tatsächlich hochladen, und wir beurteilen die Ausgabe an den Dingen, die für einen fertigen Untertitel oder ein fertiges Transkript zählen.

Das ist die ganze Philosophie: Genauigkeit ist keine Zahl, die ein Anbieter Ihnen überreicht. Sie ist etwas, das Sie an Ihrem eigenen Anwendungsfall messen – sonst kennen Sie sie nicht wirklich.

Was „Genauigkeit" bei einem Untertitel tatsächlich bedeutet

Wenn die meisten Menschen von „Transkriptionsgenauigkeit" sprechen, vermischen sie zwei völlig verschiedene Aufgaben:

1. Speech-to-Text (STT / ASR) – Audio in rohen Text mit Zeitstempeln umwandeln. Hier lebt die WER.
2. Textaufbereitung – diesen rohen, unsauberen ASR-Text in einen veröffentlichungsfähigen Untertitel verwandeln: falsch verstandene Wörter korrigieren, gesprochene Formulierungen in saubere Schriftsprache übertragen, Abstände und Interpunktion wiederherstellen, Füllwörter entfernen und entscheidend keine Fakten verändern.

Beide Stufen können scheitern, und sie scheitern auf unterschiedliche Weise. Ein Modell kann hervorragenden Rohtext liefern und trotzdem unbrauchbare Untertitel ausspielen, weil die Zeitstempel auseinanderdriften. Ein anderes Modell kann perfekt ausgerichtete Zeitstempel haben und dennoch einen Markennamen verstümmeln. Eine einzelne Genauigkeitsangabe in Prozent kann nichts davon erfassen – genau deshalb testen wir jede Stufe getrennt und qualitativ.

Der Rest dieses Beitrags geht durch beide: zuerst die Stufe der Textaufbereitung, für die wir eine strukturierte Evaluierung mit echten Zahlen haben, die wir teilen können, und anschließend die reine STT-Stufe, bei der unsere Erkenntnisse bewusst qualitativ sind.

Wie wir die Textaufbereitungs-Stufe testen: LLM-as-Judge auf echtem Audio

Hier ist die Methodik für einen echten Evaluierungslauf, den wir im April 2026 durchgeführt haben. Das Ziel war das Modell, das den Aufbereitungsdurchgang auf der rohen ASR-Ausgabe leistet – der Schritt, der ein grobes maschinelles Transkript in einen veröffentlichungsfähigen Untertitel verwandelt. Dieser Durchgang erledigt zwei verschiedene Aufgaben, und wir testen jede einzeln:

• Fehler korrigieren – die Wörter und Zahlen ausbessern, die das Speech-to-Text falsch verstanden hat: ein falsch gehörter Markenname, eine falsche Modellnummer, eine ausgelassene Verneinung.
• Die Formulierung bereinigen – gesprochene, umgangssprachliche Formulierungen in saubere Schriftsprache übertragen, Interpunktion und Abstände wiederherstellen und Füllwörter trimmen – ohne die Bedeutung zu verändern. (In manchen Sprachen ist diese Kluft groß: Kantonesisch etwa hat eine ausgeprägte Umwandlung von gesprochener zu geschriebener Sprache, 口語 → 書面語.)

(Der Geltungsbereich, klar gesagt: Dieser Lauf evaluiert den Textaufbereitungs-Durchgang, nicht das rohe Speech-to-Text. Beide werden unterschiedlich getestet.)

• Der Datensatz war eine kleine, bewusst kuratierte Sammlung echter Beispiele – in unserem Fall sprachgemischtes Hongkong-Kantonesisch und Englisch –, ausgewählt nicht wegen der Größe, sondern wegen der Fälle, die Modelle in die Knie zwingen: gemischte Schrift, Fachbegriffe und Modellnummern, interpunktionslastige Passagen, kurze fragile Fragmente und lange Spannen. Die konkrete Sprache zählt weniger als das Prinzip: Eine Handvoll wirklich gemeiner Beispiele aus Ihrem eigenen Anwendungsfall fördert mehr echte Fehler zutage als tausend saubere.
• Der Vergleich war paarweise. Für jedes Beispiel trat die Ausgabe jedes Kandidatenmodells direkt gegen unsere aktuelle Produktions-Baseline an, und ein separates Richter-Modell wählte die bessere aus – oder erklärte ein Unentschieden.
• Die Kriterien waren sechs Dinge, die einen guten Untertitel tatsächlich ausmachen, je Beispiel unabhängig bewertet:
  • Falsch verstandene Wörter korrigieren – hat es ausgebessert, was das Speech-to-Text falsch hatte?
  • Bereinigung von gesprochen zu geschrieben – hat es umgangssprachliche Rede in saubere Schriftsprache verwandelt? (In unseren kantonesischen Beispielen ist dies die Umwandlung 口語 → 書面語; jede Sprache hat ihre eigene Variante, Gesprochenes in Prosa zu ordnen.)
  • Entfernung von Füllwörtern – hat es die Ähs und Fehlstarts gestrichen?
  • Faktentreue – hat es Namen, Zahlen und Fakten unangetastet gelassen?
  • Verbot von Anmerkungen – hat es darauf verzichtet, eingeklammerte Notizen zu erfinden, die der Sprecher nie gesagt hat?
  • Gründlichkeit – hat es den Text wirklich aufgeräumt oder offensichtliche Fehler stehen gelassen?

Wir haben 31 Modellkonfigurationen in diesen Lauf gegeben. Nur 17 waren überhaupt lauffähig – der Rest fiel beim Preflight um, mit ungültigen Modell-IDs, Anfrage-Timeouts oder nicht unterstützten Einstellungen, was selbst ein nützliches Ergebnis ist: Ein Modell, das Sie nicht zuverlässig aufrufen können, ist kein Kandidat, ganz gleich, wie sein Benchmark-Wert aussieht.

Das ist Methodik in Dokumentationsqualität, kein Bauchgefühl. Jede Zahl unten stammt aus der eigenen Ausgabe dieses Laufs, und wir teilen sie, weil sie uns gehört – nicht, weil ein Anbieter uns gesagt hat, sein Modell sei gut.

Was wir gefunden haben: die Zahlen aus unserem eigenen Lauf

Ein paar Ergebnisse stachen heraus. Alle Angaben stammen aus unserer eigenen Evaluierung; es sind Richter-Präferenz-Gewinnraten und Geschwindigkeit bei der Untertitel-Aufbereitung – nicht irgendjemandes STT-Genauigkeitsprozentsatz.

Drei Erkenntnisse aus unseren Daten:

• Die beste durchschnittliche Richter-Präferenz im gesamten Lauf lag bei etwa 92 % – eine leichtgewichtige Gemini 3.1 Flash Lite-Konfiguration, die der Richter bei der großen Mehrheit der Beispiele unserer Produktions-Baseline vorzog. Ein kleines, schnelles Modell schlug die schwerere Standardeinstellung.
• Die schlankste lauffähige Konfiguration war rund 13× schneller als die Baseline – etwa 19 Sekunden gegenüber rund 4 Minuten – zu einem Bruchteil der Kosten und gewann das direkte Duell beim Korrigieren von Fehlern dennoch klar. Größer und langsamer war nicht besser.
• Das Deckeln des „Denk"-Budgets des Modells war der einzelne größte Effizienzgewinn. Die Baseline gab den überwiegenden Teil ihres Budgets für Reasoning-Token aus, die sie weitgehend nicht brauchte. Dieses Reasoning-Budget bei derselben Modellfamilie abzuschalten, brachte eine Ausgabe hervor, die der Richter als gleich gut oder besser bewertete – rund eine Größenordnung schneller und weit schlanker. Für eine eng umrissene, klar spezifizierte Aufgabe wie die Untertitel-Aufbereitung war ausgedehntes Reasoning größtenteils vergebene Mühe.

Sie werden bemerken, dass nichts davon „Genauigkeitsprozentsätze" sind. Es sind relative Präferenzwerte eines Richter-Modells, auf unserem Audio, gegen unsere eigene Baseline. Das ist eine bewusst bescheidenere Behauptung als „98 % genau" – und sie ist weit nützlicher, um tatsächlich ein Modell auszuwählen.

Der Fehler, der beweist, warum menschlich bewertete, am Anwendungsfall ausgerichtete Tests zählen

Hier ist das Beispiel, das das gesamte Argument einfängt. Ein Kandidatenmodell tat bei der Aufbereitung einer Smartphone-Rezension (einer unserer sprachgemischten kantonesisch-englischen Aufnahmen) Folgendes:

Quelle:    T-828 的 sensor 啦。那這顆 LYT-828 呢，我們，我們又來……
Baseline:  ……呢粒 LYT-828 呢……
Kandidat:  ……嗰呢粒 LYT-808 呢……

Das Modell schrieb den Kamerasensor „LYT-828" still und heimlich zu „LYT-808" um. Wir sahen dieselbe Fehlerklasse an anderer Stelle im Lauf, wo ein weiterer Kandidat aus einem „Vivo X30 Pro" ein „Vivo X90 Pro" machte.

Der Text liest sich tadellos. Die Grammatik ist sauber, die Interpunktion ist wiederhergestellt, die gesprochene Formulierung ist ordentlich in korrekte Schriftform gebracht. Ein WER-Wert würde die Änderung kaum registrieren – eine Ziffer in einer langen Passage. Aber es ist eine faktische Verfälschung: ein anderes Produkt, ein anderer Sensor. Für eine Tech-Rezensentin oder einen Tech-Rezensenten ist das die Art von Fehler, für die in den Kommentaren eine Richtigstellung gefordert wird.

Die Lehre handelt nicht von einer bestimmten Sprache. Sie lautet: Die gefährlichsten Transkriptionsfehler sind die flüssigen – ein sauber lesbarer Satz mit einem still und heimlich vertauschten Fachbegriff, einer Modellnummer oder einem Eigennamen. Solche verstecken sich genau in dem schriftgemischten, jargonreichen Audio, das echte Nutzerinnen und Nutzer aufnehmen, in jeder Sprache. Kein veröffentlichter Genauigkeits-Benchmark hätte das erwischt; es kam nur ans Licht, weil wir die Ausgabe so beurteilten, wie es eine Redakteurin oder ein Redakteur täte – an der konkreten Frage „Hat das Modell einen Fakt verändert?" – auf der Art von Audio, auf der dieser Fehler tatsächlich auftritt. Das ist der Unterschied zwischen Benchmark-Maxing und am Anwendungsfall verankertem Testen.

Es zeigt auch, warum „Faktentreue" eines unserer sechs Kriterien ist und warum wir es als vergleichendes Signal lesen statt als wörtliche Fehlerzählung. Im selben Lauf gab ein Modell „neunzig Prozent" auf zwei gleichermaßen korrekte Weisen wieder (百分之九十 gegenüber 九成) – semantisch identisch, gar kein Fehler. Eine naive Metrik hätte die Umformulierung beanstandet und den Sensor-Tausch übersehen. Urteilsvermögen, am richtigen Material, bekommt diese Reihenfolge richtig hin.

Was ist mit der rohen Speech-to-Text-Stufe?

Für die STT-Stufe selbst – Audio rein, zeitgestempelter Text raus – sind unsere Erkenntnisse bewusst qualitativ. Wir veröffentlichen keine WER-Tabelle, weder unsere noch die von irgendwem, weil die Fehler, die hier zählen, von einer einzelnen Fehlerrate nicht gut erfasst werden. Was ein STT-Modell in der Produktion zu Fall bringt, ist meist eines davon: halluzinierte Inhalte, die der Sprecher nie gesagt hat, übergangene echte Sprache, instabile Leistung bei ressourcenärmeren oder sprachgemischten Sprachen oder Zeitstempel, die aus dem Takt mit dem Audio geraten.

Ein paar Dinge, die wir gelernt haben, indem wir Modelle auf unserem eigenen Audio testeten, statt ihre Datenblätter zu lesen:

• Guter Text bedeutet nicht gute Zeitstempel. Wir evaluierten ein Frontier-Multimodal-Modell als Transkriptions-Engine: Seine rohe Textqualität war wirklich gut, aber seine Cue-Zeitstempel drifteten – in Ordnung für ein Lese-Transkript, unbrauchbar für Untertitel, die auf dem richtigen Bild landen müssen.
• Manche Modelle liefern von vornherein unbrauchbares Timing. Ein anderes Modell, das wir für dieselbe Aufgabe testeten, hatte in unseren Notizen „Müll-Zeitstempel" – auf dem Papier stark, ein No-Go für zeitlich ausgerichtete Untertitel.
• Ressourcenarme und sprachgemischte Sprachen sind dort, wo allgemeine Modelle wackeln. Die saubereren, ressourcenstarken Sprachen, auf die sich ein Benchmark stützt, sind der einfache Fall; das Wackeln zeigt sich bei Akzenten, Dialekten und Audio, das innerhalb einer Aufnahme zwischen Sprachen wechselt. Subanana begann mit einem einzigen bekannten STT-Modell, und wir wurden vom Einzelanbieter-Ansatz durch genau die Art von Fehler abgebracht, die Benchmarks verbergen: Halluzinationen und übergangene Sprache unter realen Bedingungen, wobei die schwierigeren Sprachen – Kantonesisch unter ihnen – am wenigsten stabil waren. Deshalb leiten wir heute über mehrere evaluierte Engines und fallen automatisch zurück, wenn eine ein schlechtes Segment produziert.
• Die eigentliche Ingenieursarbeit lebt in den Lücken. Als wir einen neuen STT-Anbieter hinzunahmen, war die Arbeit nicht „ist die WER niedriger". Sie bestand aus: einer Passage Hintergrundmusik, die auf das Timing des falschen Untertitels gemappt wurde, vereinzelten [upbeat music]-Tags, die entfernt werden mussten, Segmenten, die ohne Leerzeichen zusammengeklebt wurden. Nichts davon taucht in einem Genauigkeitswert auf; alles davon taucht für eine Nutzerin oder einen Nutzer auf.

Die ehrliche Zusammenfassung lautet: Wir wählen das leistungsstärkste STT-Modell je Ausgangssprache und je Anwendungsfall, und wir prüfen immer wieder neu – denn ein Modell, das gut benchmarkt, kann bei den Zeitstempeln dennoch driften oder bei den schwierigeren Sprachen halluzinieren, und die einzige Möglichkeit, es zu wissen, ist, es auf der echten Sache laufen zu lassen. Mehr darüber, wie dieses Routing und der Qualitätsstapel funktionieren, lesen Sie auf unseren Seiten zum KI-Untertitelungstool und zur KI-Meeting-Transkription.

Wie sollten Sie die Transkriptionsgenauigkeit selbst evaluieren?

Sie brauchen kein Eval-Harness, um der Benchmark-Falle zu entgehen. Das Prinzip ist einfach: Testen Sie auf Ihrem eigenen Audio, beurteilen Sie nach dem, was Ihnen wichtig ist.

• Nehmen Sie Ihr schwierigstes echtes Audio, keine saubere Aufnahme. Wählen Sie die Datei mit den Akzenten, dem Durcheinanderreden, dem Jargon, dem Sprachwechsel. Dort trennen sich die Modelle.
• Prüfen Sie die Zeitstempel, nicht nur die Wörter. Spielen Sie das Video mit eingeschalteten Untertiteln ab. Driftende Cues sind in einem Text-Diff unsichtbar und auf dem Bildschirm offensichtlich.
• Suchen Sie gezielt nach faktischer Verfälschung. Scannen Sie Namen, Zahlen sowie Produkt- und Markenbegriffe. Ein sauber lesbarer Untertitel mit einer falschen Zahl ist schlimmer als ein offensichtlich grober.
• Beurteilen Sie die fertige Ausgabe, nicht das rohe Transkript. Was Sie ausliefern, ist der korrigierte, formatierte Untertitel – also evaluieren Sie genau diesen, samt der Frage, wie viel manuelle Nacharbeit er noch braucht.
• Testen Sie über die Zeit erneut. Modelle ändern sich. Das beste für Ihre Sprache in diesem Quartal ist es nächstes Quartal vielleicht nicht mehr. Wir wiederholen unsere Evaluierung genau deshalb, weil die Antwort ständig in Bewegung bleibt.

Wenn Sie diesen Parcours lieber nicht selbst laufen möchten, ist genau das die Aufgabe, die wir laufend erledigen: die Modelle benchmarken, je Sprache und Anwendungsfall an die beste leiten und Halluzinationserkennung sowie Korrekturlesen darüberlegen, damit die Ausgabe, die Sie prüfen, bereits die stärkste ist, die das System erzeugen kann. Sie können es auf Ihrem eigenen schwierigsten Audio ausprobieren – beginnen Sie mit einer kostenlosen Datei und prüfen Sie die obigen Punkte.

FAQ

Ist ein höherer veröffentlichter Genauigkeitsprozentsatz ein verlässlicher Weg, ein Transkriptionstool auszuwählen?

Nein. Veröffentlichte Angaben sind optimierte Ergebnisse auf sauberem Audio – oft mit nur einer sprechenden Person – in ressourcenstarken Sprachen. Sie sagen die Leistung bei echtem Audio mit Akzenten, Durcheinanderreden, Fachbegriffen oder Sprachwechsel selten voraus. Testen Sie stattdessen auf Ihren eigenen Dateien.

Was ist der Unterschied zwischen Transkriptionsgenauigkeit und Untertitelqualität?

Transkriptionsgenauigkeit bezieht sich meist auf rohes Speech-to-Text – Wörter und Zeitstempel. Untertitelqualität ist das fertige Ergebnis nach der Aufbereitung: falsch verstandene Wörter korrigiert, gesprochene Formulierung in saubere Schriftsprache gebracht, Interpunktion und Abstände wiederhergestellt, Füllwörter entfernt und Fakten unangetastet gelassen. Ein Tool kann das eine gut und das andere schlecht beherrschen.

Warum evaluieren Sie Modelle mit einem anderen Modell als Richter?

Für die Textaufbereitungs-Stufe erlaubt uns ein LLM-Richter, zwei Ausgaben paarweise nach einheitlichen Kriterien zu vergleichen – weit schneller als manuelle Prüfung und beliebig oft günstig wiederholbar, sobald ein neues Modell erscheint. Wir behandeln seine Urteile als relatives Präferenzsignal gegen unsere eigene Baseline – nicht als absoluten Genauigkeitswert – auf einem bewusst schwierigen, kuratierten Beispielsatz, und wir halten Menschen bei den Fehlerfällen im Spiel, die zählen, etwa der faktischen Verfälschung.

Erzeugt ein Modell mit gutem Transkriptionstext immer gute Untertitel?

Nein, und das ist eine häufige Falle. Wir haben Modelle mit wirklich gutem Rohtext erlebt, die driftende oder unbrauchbare Zeitstempel produzierten. Für Untertitel, die sich am Bild ausrichten müssen, zählt die Zuverlässigkeit des Timings ebenso wie die Wortgenauigkeit – und die beiden sind nicht korreliert.

Warum verwendet Subanana mehrere Speech-to-Text-Modelle statt eines?

Weil kein einzelnes Modell über jede Sprache und jeden Anwendungsfall hinweg das beste ist und jedes Modell auf echtem Audio halluzinieren oder Sprache übergehen kann. Subanana begann bei einem einzigen Anbieter und wechselte zu einem Mehr-Modell-Ansatz, nachdem Produktionsdaten die Grenzen einer einzelnen Engine zeigten – besonders bei ressourcenärmeren und sprachgemischten Sprachen. Wir leiten an das bestbewertete Modell je Ausgangssprache und fallen automatisch zurück, wenn die Ausgabequalität nachlässt.