Audio-KI testen

Audio-KI-Systeme testen bedeutet, Modelle für Spracherkennung und Sprachsynthese auf Fehler zu prüfen, ohne dabei in die Blackbox des Modells schauen zu können. Weil jede Korrektur ein mehrtägiges, kostspieliges Neutraining erfordert, helfen sogenannte goldene Testsätze und KI-generierte Testvariationen dabei, Aussprache- und Erkennungsfehler systematisch aufzudecken.

Das Wichtigste in Kürze

• KI-Audiomodelle lassen sich nicht von innen debuggen: Wer einen Fehler findet, etwa ein falsch erkanntes Wort, muss das Modell komplett neu trainieren, was mehrere Tage und mehrere hundert bis tausend Euro kostet.
• Goldene Testsätze sind derzeit die wichtigste Qualitätssicherungsmethode für Audio-KI, weil klassische Testautomatisierung an der Blackbox-Natur von KI-Modellen scheitert.
• Das Datenproblem trifft Deutsch besonders hart: Von 600.000 annotierten Audiostunden im Whisper-Modell entfallen nur etwa 2.000 bis 3.000 auf Deutsch, was die Erkennungsqualität für deutsche Sprecher strukturell begrenzt.
• Fehlende Diversität in Trainingsdaten schlägt direkt auf die Modellqualität durch: Wer mit 90 Prozent Männerstimmen trainiert, erhält ein Modell, das Frauen schlecht erkennt und synthetisierte Frauenstimmen männlich klingen lässt.
• ChatGPT lässt sich nutzen, um synthetische Testdaten für Audio-KI zu generieren, weil es sprachliche Variationen produziert, auf die Menschen beim manuellen Erstellen von Testfällen schlicht nicht kommen.

Audio-KI testen heißt eine Blackbox prüfen

Der schwierigste Teil beim Testen von Audio-KI ist, dass niemand wirklich in das Modell hineinschauen kann. Ein Sprachmodell für Transkription oder Sprachsynthese ist eine Blackbox, deren innere Logik sich nicht Zeile für Zeile prüfen lässt wie eine klassische Funktion. Du siehst nur, was vorne reingeht und was hinten herauskommt.

Bei einer klassischen Funktion findest du einen Rundungsfehler, korrigierst die Nachkommastellen und der Test ist grün. Bei einem KI-Modell gibt es diesen Eingriffspunkt nicht. Spricht das Modell ein Wort falsch aus oder erkennt es nicht, kannst du nicht einfach eine Regel ändern. Du müsstest das Modell neu trainieren, und das kostet je nach Größe einige Tage und mehrere hundert bis mehrere tausend Euro.

Olaf Thiele beschäftigt sich seit Jahren mit Audio-KI auf Deutsch, also mit Speech-to-Text und Text-to-Speech. Sein Befund: die Modelle funktionieren inzwischen, beim Testen steht die Branche dagegen noch am Anfang.

Warum die Reproduzierbarkeit beim KI-Training scheitert

Ein KI-Training lässt sich derzeit nicht zuverlässig reproduzieren, weil schon die Hardware das Ergebnis verändert. Bei den gängigen Libraries PyTorch und TensorFlow kann derselbe Datensatz auf unterschiedlichen Rechnerarchitekturen leicht abweichende Ergebnisse liefern, selbst wenn alle anderen Variablen gleich bleiben.

Das wird zum Problem, sobald jemand ein Ergebnis exakt nachrechnen will. Trainiert wird meist bei Hyperscalern wie AWS, Google Cloud, Azure oder OVH. Dort weißt du nicht, ob du in einer Woche dieselbe physische Maschine zugeteilt bekommst, etwa eine V100 oder A100. Damit fehlen die Rahmenbedingungen, um überhaupt ein identisches Ergebnis erzeugen zu können.

Diese Frage stellte sich lange gar nicht. Solange es nur darum ging, dass ein Modell überhaupt läuft, hat niemand nach exakter Reproduzierbarkeit gefragt. Erst jetzt, wo Kunden größer werden und Governance verlangen, rückt sie nach vorn.

Wann hört man beim Training auf? Eine Bauchentscheidung

Es gibt keine Formel dafür, an welchem Punkt ein Training beendet werden soll. Ein Modell durchläuft mehrere Stufen, und mit jeder Stufe wird es besser auf seinem internen Testset. Genau hier lauert die Falle: je länger trainiert wird, desto besser passt das Modell auf die Trainingsdaten, aber die Verallgemeinerung auf neue, ungesehene Daten wird ab einem Punkt schlechter.

Die Lernkurve flacht logarithmisch ab. Ob man in Schritt neun, zehn, elf oder zwölf aufhört, entscheidet oft das Gefühl. Hinzu kommt ein Verteilungsproblem innerhalb der Daten: Während ein männlicher Sprecher mit fortschreitendem Training immer besser erkannt wird, kann eine weibliche Stimme gleichzeitig schlechter werden. Wo du da aufhörst, ist nicht eindeutig zu beantworten.

Der Begriff “Testset” im Training meint hier nicht Testen im Sinne der Softwareentwicklung. Es ist eine kleine Datenmenge zur internen Selbstkontrolle des Modells, kein Qualitätsnachweis im klassischen Sinn.

Der goldene Testsatz als Behelf

Das gängigste Hilfsmittel beim Audio-Testing ist ein goldener Testsatz: eine sorgfältig zusammengestellte Sammlung von Beispielen, an denen sich die Qualität des Modells messen lässt. Idealerweise erstellt der Kunde diesen Satz selbst, weil er am besten weiß, was er erreichen will. In der Praxis passiert das selten.

Ein guter goldener Testsatz bildet Abstufungen ab. Bei Dialekten heißt das zum Beispiel ein sehr starkes Bayerisch neben einem leichten Bayerisch. An einigen tausend Samples lässt sich dann beobachten, wie sich das Modell über Trainingsläufe verändert.

Der Testsatz hilft auch, gefundene Fehler abzumildern. Erkennt ein Modell ein bestimmtes Wort nicht, schiebt man mehr Beispiele dieses Wortes nach. Eine echte Korrektur im Sinne eines gezielten Bugfixes ist das nicht, eher ein Nachsteuern über die Datenmenge.

Die KI weiß nicht, was sie nicht weiß

Das Kernproblem beim Finden von Fehlern: Eine KI kennt keine Grenze, an der sie sagt, das weiß ich nicht. Sie liefert auch dann ein Ergebnis, wenn sie eigentlich keine Antwort hätte. Beim Erkennen von Audio bedeutet das, dass du oft nicht weißt, welche Wörter ein Modell auslässt oder verschluckt.

Ein anschauliches Beispiel ist die Aussprache von Lehnwörtern. Manche Menschen sagen “Budget” mit harter Aussprache, andere französisch. Um einem Modell beizubringen, beides zu erkennen, bräuchte man tausende Beispiele für genau diese Variante. Woher die nehmen?

Diese Lücke trifft auch das Testen der Ausgabe. Willst du synthetisierte Sprache automatisiert prüfen, läufst du in einen Zirkelschluss: Du müsstest das erzeugte Audio wieder durch eine Erkennungs-KI schicken. Ist diese auf denselben Daten trainiert, übersieht sie genau das, was sie auch beim Original übersehen würde. Das Grundproblem reproduziert sich selbst.

Gold in, Gold out: Datenqualität entscheidet über das Ergebnis

Ein Modell kann nur das wiedergeben, was in die Trainingsdaten hineinging. Diese Regel prägt jede Anwendung. Wer eine junge, weibliche Stimme synthetisieren will, aber überwiegend altes, männliches Audiomaterial als Input hat, kämpft gegen die Datenlage an.

Genau hier liegt eine Verzerrung, die sich bis ins Ergebnis durchzieht. Die frei verfügbaren Mozilla-Sprachdaten bestehen zu rund 90 Prozent aus männlichen Stimmen. Die Folge: Frauenstimmen werden schlechter erkannt, und synthetisierte Frauenstimmen klingen mitunter männlich.

Der Effekt verstärkt sich, wenn ein Modell auf wenige Sprecher überoptimiert wird. Trainierst du 300 Stunden mit einer einzigen prominenten Stimme, bekommst du einen perfekten Versteher für diese Person, aber andere Sprecher, etwa eine ältere Frau, werden kaum noch erkannt.

Je nachdem, was ich in so ein Modell reinpacke, das bekomme ich auch raus. Deshalb bin ich sehr vorsichtig bei Anwendungen, die divers sein sollen.

Olaf Thiele

Warum Deutsch beim Datenmangel besonders leidet

Für Deutsch gibt es deutlich weniger nutzbare Trainingsdaten als für Englisch. Ein bekanntes Modell wurde auf 600.000 annotierten Stunden Audiomaterial trainiert, davon entfielen rund 550.000 Stunden auf Englisch. Für Deutsch blieben nur etwa 2.000 bis 3.000 Stunden.

Wer ein deutsches Modell auf englischem Niveau will, braucht eine vergleichbare Datenbasis, also in der Größenordnung von 50.000 Stunden Deutsch. Solche Mengen sammeln derzeit vor allem die Hyperscaler, und deren Modelle werden messbar besser.

Frei verfügbare Quellen sind rar. Das Mozilla-Projekt zum Sammeln von Sprache lief aus. Viele naheliegende Quellen scheitern an Lizenzfragen: Bundestagssitzungen, Radiosendungen, vorgelesene Bücher aus dem Gutenberg-Projekt. Letztere haben zusätzlich das Problem, dass die Vorlesestimme nicht klingt wie ein natürliches Gespräch.

Ein positives Gegenbeispiel ist die frei lizenzierte deutsche Stimme von Thorsten, der rund 20 Stunden mit einem guten Mikrofon aufgenommen hat. Solche offenen Datensätze bräuchte es mehr, auch von Frauen und aus verschiedenen Regionen.

Dialekte sind gewünscht und kaum umsetzbar

Dialektfähige Modelle scheitern fast immer an der Datenlage. Dialekte unterscheiden sich regional stark, teils von Tal zu Tal. In der Schweiz baut jemand pro Tal ein eigenes Modell, gefördert durch öffentliche Mittel.

In Deutschland ist die Entwicklung stärker kommerziell getrieben, mit einer klaren Schlagseite. Es gibt tendenziell mehr Daten aus dem Süden und weniger aus dem Osten. Die Konsequenz: Menschen aus dem Osten werden schlechter erkannt als Menschen aus dem Süden. Für ein sächsisches Modell bräuchte es etwa 1.000 Stunden Sächsisch, die schlicht fehlen.

Eine Sprachanwendung enthält mehrere KIs, jede ein eigenes Testproblem

Ein Sprach-Skill besteht nicht aus einer KI, sondern aus mindestens drei. Am Beispiel einer Pizzabestellung lassen sich die Stationen und ihre jeweilige Testbarkeit klar trennen.

Die mittlere Komponente, das Natural Language Understanding, lässt sich klassisch testen. Du gibst einen Text rein und prüfst, ob der richtige Intent erkannt wird. Solche Tests schreibst du wie gewohnt, auch wenn Plattformen wie Alexa das nicht out of the box anbieten.

Die beiden Audio-Enden bleiben das Problem. Bei der Spracherkennung siehst du nur den erkannten Text. Ob ein Fehler von einem Dialekt, einer Nuschelei oder einem schlechten Mikrofon kam, lässt sich nicht rekonstruieren. Bei der Ausgabe stellt sich erneut die Frage, wie du hunderte synthetisierte Antworten prüfst, ohne hundert Menschen zuhören zu lassen.

Generative KI als Werkzeug zum Erzeugen von Testdaten

Sprachmodelle wie ChatGPT helfen beim Testen am unmittelbarsten dort, wo viele Textvariationen gebraucht werden. Wer Ausgaben eines Sprach-Skills prüfen will, muss normalerweise alle Antwortvarianten von Hand formulieren, und nach einigen Stunden fällt einem schlicht nichts Neues mehr ein.

Ein Sprachmodell liefert auf Zuruf 50 oder 100 Varianten einer Antwort. Über die Temperatur lässt sich steuern, wie frei das Ergebnis ausfällt. Diese Texte werden dann als Audio synthetisiert und stichprobenartig angehört. Auf diesem Weg lassen sich Fehler finden, die vorher durchrutschten, etwa eine falsche Aussprache oder zwei Wörter, die in Kombination falsch gesprochen werden, weil die Synthese über Phoneme läuft.

Der gleiche Hebel funktioniert für die Eingabeseite. Lässt du dir 100 Formulierungen für eine Pizzabestellung generieren, kommen Sätze zurück, auf die du selbst nie gekommen wärst. Jeder zusätzliche Satz im Testdatensatz kostet fast nichts und erweitert das geprüfte Spektrum deutlich.

Eine Grenze bleibt: Bei sensiblen oder gefährlichen Anwendungsfällen ist die Fehlerrate generativer Modelle nicht akzeptabel. Für interne und vorbereitende Aufgaben funktioniert der Ansatz dagegen gut.

MLOps und Standardisierung kommen, aber Audio hängt hinterher

Werkzeuge für MLOps gewinnen an Fahrt, doch sie sind bisher auf Text zugeschnitten und beim Audio fehlt vieles. Der Grund liegt in der Datenmenge: Aus zehn Sekunden Audio entstehen Fenster von je 20 Millisekunden, für jedes Fenster wird das komplette Frequenzband ausgewertet, und über ein Sliding Window fließen benachbarte Fenster mit ein. Daraus werden riesige Vektoren. Ein typischer Trainingsdatensatz liegt schnell bei 400 bis 500 Gigabyte.

Diese Größe macht es schwer, Daten über Trainingsläufe hinweg sauber mitzuziehen. Variiert man die Zusammensetzung, etwa einen höheren Frauenanteil oder weniger schnell sprechende Männer, bräuchte man ein Tracking, welche Daten genau in welchem Lauf steckten. Genau dieses Tracking liefern die gängigen Werkzeuge nicht.

Die Plattform Hugging Face funktioniert hier wie ein GitHub für KI-Modelle und hostet zehntausende Modelle. Ihre Library erlaubt es, aus einem Datensatz etwa 20 Prozent zu ziehen, gibt aber die zugehörigen Metadaten nicht mit aus. Vorgeschrieben werden bislang nur technische Laufdaten, also was nötig ist, damit ein Modell überhaupt startet. Welche Daten reingelaufen sind und mit welchen Parametern trainiert wurde, bleibt offen.

Eine Standardisierung würde dem Feld helfen, vor allem wegen der Vergleichbarkeit. Kunden betreiben heute ganze Sammlungen von Modellen, einen sogenannten Model-Zoo. Qualitätssicherung und Governance über viele unterschiedlich gebaute Modelle hinweg sind kaum machbar, solange jeder mit eigenen Konventionen ankommt. Wer einen Standard setzen könnte, hätte mit der Reichweite einer Plattform wie Hugging Face die besten Voraussetzungen.