Come costruire un benchmark aperto per TTS tedesco e dialetti

Metodologia, non risultati. Questa guida specifica un benchmark per il TTS tedesco. Non riporta punteggi né indica un vincitore.

Punti chiave

• Misurate separatamente intelligibilità, correttezza delle entità, qualità percepita, autenticità dialettale, latenza e affidabilità.
• Trattate il character error rate basato su ASR come una metrica di pipeline, non come una misura diretta di ciò che una persona comprende.
• Definite la domanda di ascolto, l'allocazione dei campioni, le esclusioni e l'analisi statistica prima di raccogliere le valutazioni.
• Identificate i campioni dialettali con il nome della varietà e la località. “Dialetto tedesco” non è una categoria di valutazione utile.
• Archiviate input, richieste, output, versioni e codice di analisi esatti. Etichettate come osservazione datata un'API la cui revisione di backend non può essere fissata.
• Tenete i dati su deployment e governance dei dati fuori dal punteggio di qualità audio.

Ultimo aggiornamento: agosto 2026.

Come deve funzionare un benchmark aperto sul TTS tedesco?

Congelate il protocollo prima di generare audio. Ogni sistema ammesso riceve lo stesso testo all'interno di una traccia dichiarata. Conservate la risposta non modificata, create copie per la riproduzione con un'unica pipeline di conversione pubblicata, eseguite una configurazione ASR fissa, conducete uno studio di ascolto in cieco e misurate la latenza da un unico client controllato. Non ottimizzate i prompt dopo aver visto i risultati sul set di test.

Ogni riga di risultato richiede ID del caso, identificativi di sistema e voce, richiesta completa, regione API o hardware locale, versione del software, timestamp, esito dei retry, checksum dell'output e versione del protocollo. Una struttura di rilascio pratica è la seguente:

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/

Pubblicate un rilascio immutabile con checksum, non solo un branch che cambia. I criteri ACM sugli artefatti sono un utile standard di evidenza: un artefatto deve essere documentato, completo, eseguibile e coerente con ciò che afferma. La sola disponibilità non dimostra che un altro valutatore possa riprodurre un risultato.

Quali metriche deve riportare un benchmark TTS?

Non riducete queste righe a un unico “punteggio di qualità” ponderato. I pesi sarebbero una decisione di prodotto travestita da misurazione. Per il dimensionamento del deployment, usate un protocollo di capacity planning per il TTS separato.

Che cosa deve contenere il set di test in tedesco?

Costruite il set a partire dal carico di lavoro previsto, poi stratificatelo. Un benchmark di customer service può distribuire i casi tra dialogo semplice, composti lunghi, nomi, date e orari, valute, numeri di telefono, identificativi alfanumerici, abbreviazioni e code-switching tedesco-inglese. Pubblicate numero e fonte per ogni categoria. Un benchmark di narrazione richiede materiale diverso e non deve ereditare questo mix senza una motivazione.

Ogni riga del dataset deve includere almeno:

{
  "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"
}

Il riferimento parlato va scritto prima della sintesi. Impedisce che un ASR che restituisce cifre decida a posteriori che cosa conti come lettura corretta. Per i campi con alternative legittime, elencate quelle alternative in anticipo. Tenete l'accuratezza sulle entità separata dal CER, perché una singola cifra sbagliata può essere grave sul piano operativo pur incidendo poco su un tasso di errore a livello di frase. La guida alla normalizzazione del testo spiega perché date, valute e identificativi richiedono letture attese esplicite.

Usate casi held-out per la valutazione pubblicata. Il sottoinsieme di sviluppo può essere pubblico fin dall'inizio; pubblicate ogni versione held-out insieme ai suoi risultati e ruotate i casi di test futuri. Questo non elimina la contaminazione dei dati di addestramento, quindi il rilascio deve indicare quando ogni modello e ogni set di test sono diventati pubblici.

Come vanno campionate ed etichettate le varietà dialettali?

Non usate nomi di file come de-BY per indicare il bavarese. In BCP 47, un subtag di regione a due lettere indica un codice di Paese ISO, non un Land tedesco. Usate un tag valido secondo RFC 5646, poi registrate varietà subnazionale e località in campi separati. Per esempio, language_tag: de-DE può accompagnare variety_label: Munich Bavarian e una località documentata. Usate gsw-CH o nds-DE solo quando quei subtag di lingua registrati descrivono accuratamente il campione.

“Bavarese”, “alemanno” e “svizzero tedesco” comprendono ciascuno una variazione interna. I corpora esistenti lo rendono evidente: STT4SG-350 bilancia il materiale in svizzero tedesco tra le regioni dialettali, mentre il corpus Betthupferl pubblica sottoinsiemi separati per francone, bavarese, alemanno e tedesco standard. Un benchmark deve quindi riportare separatamente ogni località reclutata prima di mostrare qualsiasi sintesi per gruppi più ampi.

Fate scrivere o rivedere testo, ortografia, pronuncia attesa ed etichetta di varietà a parlanti della varietà indicata. Registrate i criteri di selezione dei revisori, per esempio dove sono cresciuti, dove vivono attualmente e con quale frequenza usano la varietà. Sono descrittori del campione, non test per stabilire se qualcuno sia “autentico”.

Se necessario, eseguite due tracce diverse:

1. Traccia a input comune: ogni sistema riceve lo stesso testo dialettale e nessuna correzione non dichiarata.
2. Traccia a capacità documentate: un sistema può usare i propri controlli documentati di accento, prompt o voce di riferimento, ma la configurazione esatta è pubblica.

Non mescolate mai queste due tracce in un'unica classifica. Gli ascoltatori dialettali devono rispondere a intelligibilità e aderenza regionale come domande separate; una lettura chiara in tedesco standard di un testo dialettale può ottenere un buon punteggio sulla prima e uno scarso sulla seconda.

Come si calcola il character error rate basato su ASR?

Sintetizzate l'input, trascrivete l'audio con un unico sistema ASR congelato, normalizzate l'ipotesi e il riferimento parlato con la stessa funzione pubblicata, poi calcolate inserzioni, cancellazioni e sostituzioni divise per la lunghezza del riferimento. La documentazione NIST SCTK descrive questa famiglia di punteggi per il riconoscimento vocale basati sulla distanza di edit.

Pubblicate l'output ASR grezzo e ogni stringa normalizzata. Preferite una normalizzazione Unicode conservativa in NFC, una gestione esplicita delle maiuscole e regole esplicite sulla punteggiatura. La specifica di normalizzazione Unicode avverte che le forme di compatibilità possono cancellare distinzioni, quindi “applicare NFKC” non è un'impostazione neutra. Non mappate un numero pronunciato in modo errato sul numero atteso.

La metrica va nominata in base alla configurazione ASR, per esempio CER_ASR-X_v1, perché misura insieme TTS, ASR e normalizzazione. Se le risorse lo consentono, rieseguitela con un secondo ASR congelato come verifica di sensibilità e mostrate entrambi i risultati invece di farne la media. Non confrontate una fetta dialettale con il tedesco standard come se l'errore dell'ASR fosse distribuito allo stesso modo tra le due.

Come va condotto lo studio di ascolto in cieco?

Partite dalla ITU-T P.85, che tratta la valutazione soggettiva dei dispositivi di uscita vocale. Usate la ITU-T P.808 quando il test è condotto in crowdsourcing. Queste raccomandazioni sono punti di partenza, non la prova che un qualsiasi modulo web a cinque punti sia uno studio MOS valido.

Registrate in anticipo la domanda di ascolto e l'analisi. “Quanto suona naturale questo parlato?” non è intercambiabile con qualità complessiva, somiglianza del parlante, sforzo di ascolto o autenticità dialettale. Chiedete un costrutto alla volta oppure riportate ogni risposta separatamente.

Il disegno pubblicato deve indicare:

• il numero di voci per sistema, di campioni, di ascoltatori e di valutazioni per campione;
• lingua degli ascoltatori, familiarità con il dialetto e area geografica di reclutamento;
• ordine randomizzato, anonimizzazione dei sistemi e criteri di allocazione dei campioni;
• formato di riproduzione, istruzioni di ascolto e verifiche su dispositivo o ambiente;
• campioni di riferimento e di controllo, controlli di attenzione ed esclusioni dichiarate in anticipo;
• la domanda esatta, le etichette di risposta, la distribuzione grezza delle valutazioni e il codice di analisi.

Usate un pilota per scegliere una dimensione campionaria che soddisfi un obiettivo dichiarato di precisione o potenza statistica; non esiste un numero universale di ascoltatori valido per ogni disegno. Le valutazioni si ripetono tra ascoltatori ed enunciati, quindi l'unità di analisi conta. Dichiarate se l'intervallo di confidenza è per file o per condizione e calcolatelo di conseguenza; la ITU-T P.1401 discute entrambe le forme. Se dichiarate un vincitore, pubblicate il modello di confronto definito in anticipo e il trattamento dei confronti multipli. Una media più un “IC al 95%” non spiegato non basta.

Dipendenti, produttori dei campioni e chiunque possa riconoscere gli output dei sistemi vanno riportati come panel di esperti separato oppure esclusi dal panel in cieco. Se un sistema è rappresentato da una sola voce, la conclusione vale per quella voce e per quella configurazione, non per l'intero catalogo del fornitore.

Come si misurano tempo al primo audio e affidabilità?

Definite il tempo al primo audio come il tempo trascorso, su orologio monotono, dall'istante immediatamente precedente all'invio della richiesta di sintesi da parte del client fino al primo campione audio che l'applicazione può decodificare e riprodurre. Un header di risposta o di contenitore non è audio riproducibile. Conservate i timestamp degli eventi, così altri possano ricalcolare la metrica.

Eseguite e riportate scenari separati:

• connessione a freddo, incluse DNS, TCP e TLS ove applicabili;
• connessione riutilizzata a caldo con concorrenza pari a uno;
• un tasso di arrivo o una concorrenza dichiarati e rappresentativi della produzione;
• output nativo senza perdita e, se rilevante, una conversione telefonica comune a 8 kHz applicata dopo aver archiviato l'originale.

Alternate le richieste ai vari sistemi per ridurre l'effetto dell'ora del giorno. Fissate posizione del client, regione del fornitore, set di testi, formato, frequenza di campionamento, timeout, politica di retry e riuso delle connessioni. Disattivate i retry automatici oppure registrate ogni tentativo. Timeout, audio non valido, rate limit ed errori del server appartengono al denominatore e a categorie di guasto esplicite; scartarli in silenzio migliora sulla carta sia la latenza sia l'affidabilità.

Pubblicate numero di osservazioni, distribuzione empirica, p50 e p90. Pubblicate il p99 solo con la sua incertezza e con osservazioni sufficienti per la precisione desiderata. Le regole di MLPerf Inference mostrano perché la confidenza sulla latenza di coda richiede molte più osservazioni della mediana; un p99 calcolato su poche decine di chiamate non deve sostenere un'affermazione in fase di acquisto. La latenza di elaborazione dichiarata dal fornitore può comparire in una colonna separata, ma non va mescolata con le misurazioni end-to-end lato client.

Quali sistemi possono essere inclusi in modo equo?

Definite l'elenco nel rilascio versionato del benchmark, non in un articolo di marketing. Applicate la stessa regola di ammissione a KugelAudio e a ogni concorrente.

Un'API chiusa può essere utile in un benchmark aperto anche quando la sua implementazione non è open source. Il benchmark deve dichiarare il limite che ne deriva. Per le alternative locali, consultate la guida ai modelli TTS self-hosted, poi verificate model card e licenza del checkpoint esatto al momento del rilascio.

Che cosa va pubblicato per licenze e riproduzione?

Tracciate i diritti per singolo artefatto. Codice del benchmark, testi di test, registrazioni di riferimento, prompt vocali, audio generato, pesi dei modelli e condizioni dei fornitori possono avere licenze o condizioni di ridistribuzione diverse. Un file LICENSE al livello principale dell'harness non concede diritti sul dataset o sull'audio.

Registrate fonte, autore o titolare dei diritti, identificativo di licenza o URL delle condizioni, data di acquisizione, attribuzione richiesta e se la ridistribuzione sia consentita. SPDX fornisce metadati standardizzati per software, modelli di IA e dataset, inclusi provenienza, licenze e checksum. Ottenete un consenso documentato per ogni voce di riferimento e dichiarate gli usi consentiti nel benchmark.

Se le condizioni del fornitore impediscono di pubblicare l'audio generato, dichiaratelo prima dell'esecuzione e segnate il sistema come solo parzialmente riproducibile. Non sostituite i file con esempi selezionati ad arte. Archiviate ogni rilascio, lo snapshot delle relative condizioni ove consentito e un registro delle correzioni. Un altro valutatore deve poter ricostruire tutte le tabelle riportate a partire dagli artefatti rilasciati con un unico comando documentato.

Come vanno interpretati i risultati?

Ogni conclusione è limitata da voci, testi, località dialettali, ascoltatori, ASR, regione, carico, codec e data campionati. Riportate i dati per singolo caso e le distribuzioni per fetta prima delle sintesi. Non trasformate i risultati di più località in un “punteggio universale sui dialetti tedeschi”.

KugelAudio vende un sistema che può comparire nella valutazione. Ogni rilascio condotto da KugelAudio deve dichiarare quel conflitto accanto a ogni tabella di risultati, applicare il protocollo pubblicato senza eccezioni a posteriori e invitare a riesecuzioni indipendenti. Usate il benchmark per restringere una shortlist, poi rieseguitelo con il vostro mix di traffico, le vostre entità critiche, le vostre località, la vostra concorrenza e le vostre voci. Le evidenze di qualità non stabiliscono inoltre privacy o conformità; valutatele separatamente usando la guida all'infrastruttura voice AI on-premise.

FAQ

Come si misura la qualità del TTS tedesco?

Usate evidenze separate per intelligibilità del testo ordinario, entità critiche, qualità percepita dalle persone, aderenza dialettale, latenza e guasti. Nessuna metrica singola sostiene tutte quelle conclusioni.

Che cos'è il CER round-trip?

È il character error rate tra un riferimento parlato dichiarato e l'output di un sistema ASR congelato applicato all'audio sintetizzato. È ripetibile quando ASR e codice di normalizzazione sono fissati, ma non è un punteggio puro di TTS né di intelligibilità umana.

Di quanti ascoltatori ha bisogno uno studio MOS?

Non esiste un numero universale. Sceglietelo da un pilota e da un obiettivo dichiarato di precisione o potenza, poi pubblicate ascoltatori, valutazioni per campione, esclusioni e unità di analisi. Più valutazioni non correggono un panel di ascoltatori o un set di test distorti.

Un benchmark può riportare il p99 su 100 richieste?

Può calcolare un percentile campionario, ma quella stima contiene pochissima informazione sulla coda. Riportate distribuzione grezza, numero di campioni e incertezza; non presentate un p99 da poche esecuzioni come una garanzia stabile per la produzione.

Quale sistema TTS tedesco è il più accurato?

Questa metodologia non ne indica uno. Una risposta difendibile deve specificare fetta di testo, voci, snapshot dei modelli, configurazione ASR, panel di ascolto e data, e deve rendere disponibili le evidenze sottostanti.

Ogni modello incluso deve essere open source?

No. Un'API commerciale versionata può essere valutata in modo trasparente. Se il suo backend non può essere fissato o i suoi output non possono essere ridistribuiti, dichiarate quel limite e tenetelo fuori dalle affermazioni sulla riproducibilità esatta.

Una qualità audio migliore implica privacy o conformità migliori?

No. Regione di hosting, conservazione, subresponsabili, contratti e controlli on-premise sono evidenze di acquisto separate. Valutateli indipendentemente dai punteggi audio.