So entsteht ein offener Benchmark für deutsches und regionales Text-to-Speech

Methodik, keine Ergebnisse. Dieser Leitfaden beschreibt einen Benchmark für deutsches TTS. Er enthält weder Messergebnisse noch einen Testsieger.

Wichtige Erkenntnisse

• Messen Sie Verständlichkeit, Entitätskorrektheit, wahrgenommene Qualität, Dialektauthentizität, Latenz und Zuverlässigkeit separat.
• Behandeln Sie die ASR-basierte Zeichenfehlerrate als Pipeline-Metrik und nicht als direkte Messung dessen, was eine Person versteht.
• Definieren Sie die Hörfrage, die Probenzuteilung, Ausschlüsse und die statistische Analyse, bevor Sie Bewertungen sammeln.
• Ordnen Sie Dialektbeispiele einer klar benannten Varietät und einem Ort zu. „Deutscher Dialekt“ ist keine sinnvolle Auswertungskategorie.
• Archivieren Sie exakte Eingaben, Anfragen, Ausgaben, Versionen und den Analysecode. Kennzeichnen Sie eine API ausdrücklich, wenn sich ihre Backend-Version nicht als datierter Stand festschreiben lässt.
• Halten Sie Angaben zu Bereitstellung und Daten-Governance von der Bewertung der Audioqualität getrennt.

Zuletzt aktualisiert im August 2026.

Wie sollte ein offener Benchmark für deutsches TTS aufgebaut sein?

Schreiben Sie das Protokoll fest, bevor Sie Audio erzeugen. Jedes zugelassene System erhält innerhalb einer klar definierten Vergleichsspur denselben Text. Speichern Sie die unveränderte Antwort, erstellen Sie Wiedergabekopien mit einer veröffentlichten Konvertierungspipeline, transkribieren Sie mit einer festgelegten ASR-Konfiguration, führen Sie eine verblindete Hörstudie durch und messen Sie die Latenz von einem kontrollierten Client aus. Optimieren Sie Prompts nicht nachträglich anhand der Testergebnisse.

Für jede Ergebniszeile werden Fall-ID, System- und Stimmkennung, vollständige Anfrage, API-Region oder lokale Hardware, Softwareversion, Zeitstempel, Ergebnis einzelner Wiederholungsversuche, Prüfsumme der Ausgabe und Protokollversion benötigt. Eine mögliche Verzeichnisstruktur für eine Veröffentlichung sieht so aus:

benchmark/
  PROTOCOL.md
  CHANGELOG.md
  LICENSES.md
  dataset/cases.jsonl
  dataset/provenance.csv
  configs/systems/*.yaml
  environment/container-digest.txt
  outputs/raw/<system>/<case-id>.*
  outputs/playback/<system>/<case-id>.wav
  asr/raw-transcripts.jsonl
  listening-study/design.json
  listening-study/anonymized-ratings.csv
  results/metrics.csv
  results/latency-events.jsonl
  scripts/

Veröffentlichen Sie eine unveränderliche, mit Prüfsummen versehene Version und nicht nur einen fortlaufend veränderten Branch. Die ACM-Kriterien für Forschungsartefakte bieten dafür einen sinnvollen Maßstab: Ein Artefakt sollte dokumentiert, vollständig, ausführbar und mit den erhobenen Ansprüchen vereinbar sein. Seine bloße Verfügbarkeit belegt noch nicht, dass andere das Ergebnis reproduzieren können.

Welche Kennzahlen sollte ein TTS-Benchmark ausweisen?

Fassen Sie diese Zeilen nicht zu einem gewichteten „Qualitätsscore“ zusammen. Die Gewichtung wäre eine Produktentscheidung im Gewand einer Messung. Verwenden Sie für die Dimensionierung der Bereitstellung ein separates Protokoll zur TTS-Kapazitätsplanung.

Was gehört in den deutschen Testsatz?

Leiten Sie den Testsatz aus der vorgesehenen Arbeitslast ab und gliedern Sie ihn anschließend in Kategorien. Ein Benchmark für den Kundenservice könnte einfache Dialoge, lange zusammengesetzte Wörter, Namen, Datums- und Uhrzeitangaben, Währungen, Telefonnummern, alphanumerische Kennungen, Abkürzungen und Wechsel zwischen Deutsch und Englisch abdecken. Veröffentlichen Sie Anzahl und Herkunft der Fälle je Kategorie. Ein Benchmark für längere Erzähltexte braucht anderes Material und sollte diese Mischung nicht ungeprüft übernehmen.

Jede Datensatzzeile sollte mindestens Folgendes enthalten:

{
  "case_id": "de_money_001",
  "input_text": "Der Betrag ist 3.847,26 Euro.",
  "spoken_reference": "Der Betrag ist dreitausendachthundertsiebenundvierzig Euro und sechsundzwanzig Cent.",
  "category": "currency",
  "language_tag": "de-DE",
  "variety_label": "Standard German",
  "locality": null,
  "source": "benchmark-authored",
  "license": "CC-BY-4.0"
}

Die erwartete gesprochene Form muss vor der Synthese festgelegt werden. So kann ein ASR-System, das Ziffern ausgibt, nicht nachträglich bestimmen, welche Lesart als korrekt gilt. Gibt es mehrere zulässige Varianten, müssen sie vorab dokumentiert werden. Bewerten Sie die Korrektheit kritischer Entitäten getrennt von der CER: Eine einzige falsche Ziffer kann betrieblich gravierend sein, obwohl sie die Fehlerrate auf Satzebene kaum verändert. Der Leitfaden zur Textnormalisierung erklärt, warum für Daten, Währungen und Kennungen ausdrücklich erwartete gesprochene Formen benötigt werden.

Verwenden Sie für die veröffentlichte Auswertung zurückgehaltene Testfälle. Eine Entwicklungsmenge kann von Anfang an öffentlich sein; veröffentlichen Sie jede später freigegebene Testversion zusammen mit ihren Ergebnissen und erneuern Sie die Fälle für künftige Durchläufe. Das schließt Überschneidungen mit Trainingsdaten nicht aus. Deshalb muss jede Veröffentlichung angeben, wann Modell und Testsatz erschienen sind.

Wie sollten Dialektvarietäten ausgewählt und gekennzeichnet werden?

Verwenden Sie Dateinamen wie de-BY nicht als Bezeichnung für Bairisch. In BCP 47 steht ein zweibuchstabiges Regions-Subtag für einen ISO-Ländercode, nicht für ein deutsches Bundesland. Nutzen Sie ein gültiges Tag nach RFC 5646 und erfassen Sie die regionale Varietät sowie den Ort in eigenen Feldern. So kann language_tag: de-DE beispielsweise mit variety_label: Munich Bavarian und einem dokumentierten Ort kombiniert werden. Verwenden Sie gsw-CH oder nds-DE nur, wenn diese registrierten Sprach-Subtags das Beispiel tatsächlich beschreiben.

„Bairisch“, „Alemannisch“ und „Schweizerdeutsch“ umfassen jeweils zahlreiche regionale Formen. Bestehende Korpora machen das sichtbar: STT4SG-350 verteilt schweizerdeutsches Material über mehrere Dialektregionen, während das Betthupferl-Korpus getrennte Teilmengen für Fränkisch, Bairisch, Alemannisch und Hochdeutsch veröffentlicht. Ein Benchmark sollte daher zunächst Ergebnisse für jeden erhobenen Ort ausweisen, bevor er sie zu größeren Gruppen zusammenfasst.

Lassen Sie Personen, die die benannte Varietät selbst sprechen, den Text verfassen oder Text, Schreibweise, beabsichtigte Aussprache und Varietätenbezeichnung prüfen. Dokumentieren Sie relevante Angaben zu den Prüfpersonen, etwa wo sie aufgewachsen sind, wo sie heute leben und wie häufig sie die Varietät verwenden. Das sind Beschreibungen der Stichprobe und keine Prüfung, ob jemand „authentisch“ ist.

Führen Sie bei Bedarf zwei getrennte Vergleichsspuren:

1. Spur mit identischer Eingabe: Jedes System erhält denselben Dialekttext; nicht dokumentierte Korrekturen sind unzulässig.
2. Spur für dokumentierte Funktionen: Ein System darf seine dokumentierte Akzentsteuerung, einen Prompt oder eine Referenzstimme verwenden, sofern die genaue Konfiguration veröffentlicht wird.

Fassen Sie diese Vergleichsspuren nie in einer Rangliste zusammen. Dialekthörer sollten Verständlichkeit und regionale Passung getrennt bewerten: Eine klare standarddeutsche Lesart eines Dialekttexts kann bei der einen Frage gut und bei der anderen schlecht abschneiden.

Wie wird die ASR-basierte Zeichenfehlerrate berechnet?

Synthetisieren Sie den Eingabetext und transkribieren Sie das Audio mit einem festgeschriebenen ASR-System. Normalisieren Sie Hypothese und gesprochene Referenz mit derselben veröffentlichten Funktion. Die CER ergibt sich anschließend aus der Summe von Einfügungen, Löschungen und Ersetzungen geteilt durch die Länge der Referenz. Die NIST-SCTK-Dokumentation beschreibt diese Familie editierdistanzbasierter Kennzahlen für die Spracherkennung.

Veröffentlichen Sie sowohl die unveränderte ASR-Ausgabe als auch jede normalisierte Zeichenfolge. Verwenden Sie bevorzugt eine zurückhaltende Unicode-Normalisierung mit NFC und legen Sie Regeln für Groß- und Kleinschreibung sowie Satzzeichen ausdrücklich fest. Die Unicode-Normalisierungsspezifikation weist darauf hin, dass Kompatibilitätsnormalisierungen Unterschiede löschen können. „NFKC anwenden“ ist daher keine neutrale Voreinstellung. Eine falsch gesprochene Zahl darf nicht nachträglich auf die erwartete Zahl abgebildet werden.

Benennen Sie die Kennzahl nach der ASR-Konfiguration, beispielsweise CER_ASR-X_v1, da sie TTS, ASR und Normalisierung gemeinsam misst. Falls die Ressourcen reichen, wiederholen Sie den Test mit einem zweiten festgeschriebenen ASR-System, um die Empfindlichkeit zu prüfen. Weisen Sie beide Ergebnisse getrennt aus, statt sie zu mitteln. Vergleichen Sie einen Dialektausschnitt nicht so mit Standarddeutsch, als wäre der ASR-Fehler in beiden Gruppen gleich verteilt.

Wie sollte eine verblindete Hörstudie durchgeführt werden?

Beginnen Sie mit ITU-T S.85 zur subjektiven Bewertung von Sprachausgabesystemen. Für per Crowdsourcing durchgeführte Tests ist ITU-T P.808 relevant. Diese Empfehlungen sind Ausgangspunkte; sie machen nicht automatisch jedes Fünf-Punkte-Webformular zu einer gültigen MOS-Studie.

Registrieren Sie Fragestellung und Analyse vorab. „Wie natürlich klingt diese Sprachausgabe?“ ist nicht gleichbedeutend mit Gesamtqualität, Sprecherähnlichkeit, Höraufwand oder Dialektauthentizität. Fragen Sie jeweils nur ein Konstrukt ab oder weisen Sie die Antworten getrennt aus.

Im freigegebenen Design sollte Folgendes enthalten sein:

• Anzahl der Stimmen je System, Hörproben, Testpersonen und Bewertungen je Hörprobe;
• Sprache und Dialektkenntnisse der Testpersonen sowie Rekrutierungsregion;
• randomisierte Reihenfolge, Verblindung der Systeme und Verfahren zur Zuteilung der Hörproben;
• Wiedergabeformat, Höranweisungen und Prüfungen von Gerät oder Umgebung;
• Referenz- und Kontrollproben, Aufmerksamkeitsprüfungen und vorab festgelegte Ausschlussregeln;
• genaue Fragestellung, Antwortskala, Verteilung der Rohbewertungen und Analysecode.

Nutzen Sie eine Pilotstudie, um die Stichprobengröße an einem festgelegten Präzisions- oder Teststärkeziel auszurichten. Eine universelle Zahl an Testpersonen gibt es nicht. Bewertungen wiederholen sich über Testpersonen und Äußerungen hinweg; deshalb muss die Analyseeinheit ausdrücklich benannt werden. Geben Sie an, ob ein Konfidenzintervall für einzelne Dateien oder ganze Bedingungen gilt, und berechnen Sie es entsprechend. ITU-T P.1401 behandelt beide Formen. Soll ein Sieger bestimmt werden, veröffentlichen Sie das vorab festgelegte Vergleichsmodell und die Korrektur für Mehrfachvergleiche. Ein Mittelwert mit einem unerklärten „95-%-KI“ reicht nicht aus.

Mitarbeiter, Ersteller der Hörproben und alle Personen, die Systemausgaben erkennen könnten, sollten als getrenntes Expertengremium ausgewiesen oder vom verblindeten Panel ausgeschlossen werden. Wird ein System nur durch eine Stimme vertreten, gilt die Schlussfolgerung für diese Stimme und Konfiguration, nicht für den gesamten Stimmenkatalog des Anbieters.

Wie sollten Zeit bis zum ersten Audio und Zuverlässigkeit gemessen werden?

Definieren Sie die Zeit bis zum ersten Audio als monotone Zeitspanne unmittelbar vor dem Absenden der Syntheseanfrage durch den Client bis zum ersten Audiosample, das die Anwendung dekodieren und abspielen kann. Ein HTTP- oder Container-Header ist noch kein abspielbares Audio. Speichern Sie die Zeitstempel der Einzelereignisse, damit andere die Kennzahl neu berechnen können.

Führen Sie separate Szenarien aus und melden Sie sie:

• Kaltverbindung, einschließlich DNS, TCP und TLS, sofern zutreffend;
• Warme, wiederverwendete Verbindung bei Parallelität eins;
• eine deklarierte Ankunftsrate oder Parallelität, die repräsentativ für die Produktion ist;
• unveränderte verlustfreie Ausgabe und gegebenenfalls eine einheitliche 8-kHz-Telefoniekonvertierung, nachdem das Original archiviert wurde.

Verschachteln Sie die Anfragen an die Systeme, um tageszeitabhängige Effekte zu verringern. Halten Sie Clientstandort, Anbieterregion, Textsatz, Format, Abtastrate, Timeout, Wiederholungsstrategie und Wiederverwendung der Verbindung konstant. Deaktivieren Sie automatische Wiederholungen oder protokollieren Sie jeden einzelnen Versuch. Timeouts, ungültiges Audio, Rate Limits und Serverfehler gehören sowohl in den Nenner als auch in klar benannte Fehlerkategorien. Wer sie stillschweigend entfernt, lässt Latenz und Zuverlässigkeit auf dem Papier besser erscheinen.

Veröffentlichen Sie Stichprobenumfang, empirische Verteilung sowie p50 und p90. Veröffentlichen Sie p99 nur zusammen mit seiner Unsicherheit und mit genügend Beobachtungen für die angestrebte Genauigkeit. Die MLPerf-Inferenzregeln verdeutlichen, warum verlässliche Aussagen zur Tail-Latenz deutlich mehr Beobachtungen benötigen als ein Median. Ein p99 aus wenigen Dutzend Anrufen sollte keine Beschaffungsentscheidung tragen. Vom Anbieter gemeldete Verarbeitungslatenz kann getrennt ausgewiesen werden, darf aber nicht mit Ende-zu-Ende-Messungen vom Client vermischt werden.

Welche Systeme können fair einbezogen werden?

Definieren Sie die Liste in der versionierten Benchmark-Version, nicht in einem Marketingartikel. Wenden Sie für KugelAudio und jeden Teilnehmer die gleiche Zulassungsregel an.

Auch eine geschlossene API kann für einen offenen Benchmark relevant sein, obwohl ihre Implementierung nicht Open Source ist. Der Benchmark muss die daraus entstehende Einschränkung klar benennen. Lokale Alternativen beschreibt der Leitfaden zu selbst gehosteten TTS-Modellen. Prüfen Sie zum Veröffentlichungszeitpunkt stets die konkrete Modellkarte und Lizenz des Checkpoints.

Was muss zu Lizenzen und Weiterverbreitung veröffentlicht werden?

Verfolgen Sie die Rechte für jedes Artefakt einzeln. Benchmark-Code, Testtexte, Referenzaufnahmen, Stimm-Prompts, erzeugtes Audio, Modellgewichte und Anbieterbedingungen können unterschiedlichen Lizenz- und Weiterverbreitungsregeln unterliegen. Eine LICENSE-Datei auf oberster Ebene für das Testsystem gewährt keine Rechte am Datensatz oder am Audio.

Dokumentieren Sie Aufnahmequelle, Autor oder Rechteinhaber, Lizenzkennung oder URL der Bedingungen, Abrufdatum, erforderliche Namensnennung und Zulässigkeit der Weiterverbreitung. SPDX bietet standardisierte Metadaten für Software, KI-Modelle und Datensätze, unter anderem zu Herkunft, Lizenzen und Prüfsummen. Holen Sie für jede Referenzstimme eine dokumentierte Einwilligung ein und legen Sie die erlaubten Nutzungen im Benchmark fest.

Untersagen Anbieterbedingungen die Veröffentlichung des erzeugten Audios, legen Sie das vor dem Durchlauf offen und kennzeichnen Sie das System als nur eingeschränkt reproduzierbar. Ersetzen Sie fehlende Dateien nicht durch handverlesene Beispiele. Archivieren Sie jede Version, sichern Sie – soweit erlaubt – einen Stand der Bedingungen und führen Sie ein Korrekturprotokoll. Andere sollten alle veröffentlichten Tabellen mit einem dokumentierten Befehl aus den freigegebenen Artefakten neu erzeugen können.

Wie sollen Leser die Ergebnisse interpretieren?

Jede Schlussfolgerung gilt nur für die untersuchten Stimmen, Texte, Dialektorte, Testpersonen, ASR-Konfiguration, Region, Last, Codec und den jeweiligen Zeitpunkt. Veröffentlichen Sie Ergebnisse auf Fallebene und Verteilungen je Segment, bevor Sie zusammenfassen. Verdichten Sie mehrere regionale Resultate nicht zu einem universellen „Score für deutsche Dialekte“.

KugelAudio verkauft ein System, das in einer solchen Auswertung vorkommen kann. Jede von KugelAudio durchgeführte Ausgabe muss diesen Interessenkonflikt direkt bei den Ergebnistabellen offenlegen, das veröffentlichte Protokoll ohne nachträgliche Ausnahmen anwenden und unabhängige Wiederholungen ermöglichen. Nutzen Sie den Benchmark zur Eingrenzung einer Auswahlliste und wiederholen Sie den Test anschließend mit Ihrem eigenen Traffic-Mix, kritischen Entitäten, Regionen, Parallelitätsprofil und Stimmen. Qualitätsnachweise belegen weder Datenschutz noch regulatorische Konformität; prüfen Sie beides separat mithilfe des Leitfadens zu On-Premise-Voice-AI-Infrastruktur.

FAQ

Wie wird die deutsche TTS-Qualität gemessen?

Verwenden Sie getrennte Nachweise für die Verständlichkeit gewöhnlicher Texte, die Korrektheit kritischer Entitäten, wahrgenommene Qualität, Dialektpassung, Latenz und Fehler. Keine einzelne Kennzahl kann all diese Aussagen stützen.

Was ist Roundtrip-CER?

Damit ist die Zeichenfehlerrate zwischen einer vorab festgelegten gesprochenen Referenz und der Ausgabe eines festgeschriebenen ASR-Systems gemeint, das das synthetisierte Audio transkribiert. Die Kennzahl ist reproduzierbar, wenn ASR- und Normalisierungscode versioniert sind. Sie ist jedoch weder eine reine TTS-Metrik noch ein unmittelbares Maß für menschliche Verständlichkeit.

Wie viele Testpersonen braucht eine MOS-Studie?

Dafür gibt es keine universelle Zahl. Führen Sie eine Pilotstudie durch, legen Sie ein Präzisions- oder Teststärkeziel fest und veröffentlichen Sie anschließend die Zahl der Testpersonen, Bewertungen je Hörprobe, Ausschlüsse und Analyseeinheit. Mehr Bewertungen beheben weder ein verzerrtes Hörpanel noch einen ungeeigneten Testsatz.

Kann ein Benchmark p99 aus 100 Anfragen melden?

Ein Stichprobenperzentil lässt sich berechnen, enthält bei dieser Größenordnung aber nur sehr wenig Information über den Rand der Verteilung. Veröffentlichen Sie Rohverteilung, Stichprobenumfang und Unsicherheit. Stellen Sie einen p99 aus einer kleinen Serie nicht als Garantie für stabilen Produktivbetrieb dar.

Welches deutsche TTS-System ist am genauesten?

Diese Methodik nennt keines. Eine belastbare Antwort muss Textausschnitt, Stimmen, Modellstände, ASR-Konfiguration, Hörpanel und Datum benennen und die zugrunde liegenden Nachweise verfügbar machen.

Muss jedes enthaltene Modell open source sein?

Nein. Eine versionierte kommerzielle API kann transparent ausgewertet werden. Lässt sich das Backend nicht festschreiben oder dürfen Ausgaben nicht weitergegeben werden, muss diese Einschränkung klar gekennzeichnet werden. Das System darf dann nicht als exakt reproduzierbar bezeichnet werden.

Bedeutet eine bessere Audioqualität eine bessere Privatsphäre oder Compliance?

Nein. Hostingregion, Speicherfristen, Unterauftragsverarbeiter, Verträge und On-Premise-Kontrollen sind eigenständige Beschaffungsnachweise. Bewerten Sie sie unabhängig von der Audioqualität.