Warum ein kleineres Whisper-Modell mein größeres geschlagen hat

Salati hat einen Auswendiglern-Modus. Der Nutzer rezitiert einen Vers aus dem Koran, die App hört zu und sagt, ob er richtig war. Das läuft vollständig auf dem Telefon, ohne Netz, ohne dass eine Aufnahme das Gerät verlässt. Der erste Bau davon war nicht gut genug: zu viele richtige Rezitationen wurden als falsch gewertet.

Der naheliegende Schluss war, dass das Modell zu klein sei. Also habe ich ein größeres eingebaut. Whisper large-v3, quantisiert, knapp ein Gigabyte. Das Ergebnis war nicht besser. Es war langsamer, der Erst-Download wurde für Nutzer mit schlechtem Netz unzumutbar, und die Erkennungsqualität bei koranischem Arabisch blieb ungefähr gleich.

Warum ein größeres Modell hier nichts bringt

Whisper ist auf allgemeine Sprache trainiert, über viele Sprachen hinweg. Koranisches Arabisch ist etwas anderes als das Arabisch, das in Nachrichten oder Podcasts gesprochen wird: klassische Grammatik, ein eng begrenztes Vokabular, und eine Rezitationsweise mit gedehnten Vokalen, deren Länge bedeutungstragend ist. Ein größeres generisches Modell ist in genau dem besser, was hier nicht gebraucht wird, nämlich Breite. Es ist nicht besser in dem, was gebraucht wird, nämlich Tiefe in einem sehr schmalen Ausschnitt.

Dazu kommt ein zweites Problem, das mit der Modellgröße gar nichts zu tun hat. Ein mehrsprachiges Modell schreibt arabische Laute manchmal mit persischen oder Urdu-Buchstabenformen. Für das Ohr sind ی und ي identisch. Für einen Zeichenkettenvergleich sind sie es nicht.

Der erste Hebel: dem Modell sagen, was es hören wird

Beim Auswendiglernen ist der erwartete Text bekannt. Die App weiß, welchen Vers der Nutzer gerade übt. Whisper nimmt einen prompt entgegen, der als Vorkontext in den Decoder geht und die Wahrscheinlichkeiten in Richtung dieser Wörter verschiebt. Das ist eine Zeile Code.

const { promise } = ctx.transcribeData(pcm, {
  language: 'ar',
  ...(expectedText ? { prompt: expectedText } : {}),
});

Gemessen an acht echten Rezitationen des Rezitators Alafasy: Wortfehlerrate 9,2 Prozent ohne Prompt, 7,9 Prozent mit. Das klingt nach wenig. In der Wirkung ist es viel, weil die verbleibenden Fehler sich verschieben. Ohne Prompt erfindet das Modell Wörter, die im Vers nicht vorkommen. Mit Prompt liegen die Fehler fast nur noch bei Vokallängen, und genau die fängt der nächste Schritt ab.

Der zweite Hebel: vergleichen, was vergleichbar ist

Bevor Rezitation und Vorlage verglichen werden, laufen beide durch dieselbe Normalisierung. Sie wirft alles weg, was für die Frage „war das derselbe Vers?“ keine Rolle spielt, und vereinheitlicht Buchstabenvarianten. Die Reihenfolge ist dabei nicht beliebig.

export function normalizeArabic(text: string): string {
  return text
    .replace(DIACRITICS, '')
    // Persische und Urdu-Formen ZUERST auf Arabisch abbilden. Sonst macht
    // die [^ء-ي]-Bereinigung unten Leerzeichen daraus und zerreißt Wörter.
    .replace(/ک/g, 'ك')
    .replace(/[یۍ]/g, 'ي')
    .replace(/ے/g, 'ي')
    .replace(/ھ/g, 'ه')
    .replace(/[أإآٱ]/g, 'ا')
    .replace(/ة/g, 'ه')
    .replace(/ى/g, 'ي')
    .replace(/[^ء-ي\s]/g, ' ')
    .replace(/\s+/g, ' ')
    .trim();
}

Der Vergleich selbst ist ein Dice-Koeffizient über Wörter, keine exakte Gleichheit. Ein einzelnes falsch erkanntes Wort in einem Vers mit zwölf Wörtern senkt den Wert, verwirft die Rezitation aber nicht. Das ist eine bewusst milde Bewertung: Wer übt, soll für einen Erkennungsfehler des Modells nicht bestraft werden.

Das Ergebnis: kleiner ist besser

Mit Prompt-Konditionierung und Normalisierung wurde die Modellgröße zur Nebensache. Standard ist heute ein auf Tarteel feingetuntes Base-Modell, quantisiert auf q5_0, 55 MB. Daneben steht wählbar large-v3-turbo mit 574 MB für starke Geräte. Das ein Gigabyte große large-v3 ist raus.

Auch die Quantisierung ist gemessen und nicht geraten. Dieselben acht Rezitationen ergaben mit der F16-Datei und mit q5_0 exakt dieselben Transkripte. Gleiche Genauigkeit, 63 Prozent weniger Download.

Die Falle beim Konvertieren, die eine Woche gekostet hat

Tarteel veröffentlicht sein Modell im Hugging-Face-Format. Für whisper.cpp muss es nach GGML konvertiert werden. Das Skript dafür liest config.json und schreibt einen Wert daraus als n_text_ctx ins GGML.

Tarteels config.json enthält max_length: 1024. Das ist ein Generations-Parameter und nicht die Kontextlänge des Text-Decoders. Whisper hat dort fest 448. Wer den falschen Wert übernimmt, bekommt eine Datei, die aussieht wie ein Modell, sich aber von whisper.rn nicht laden lässt. Die Fehlermeldung sagt nur, das Modell sei nicht verfügbar.

Woher die Gewichte kommen, und warum das belegt ist

Zuerst lag im Projekt eine fremde Konvertierung von Hugging Face, deren Herkunft nicht dokumentiert war. In einer App, die Millionen Menschen beim Auswendiglernen eines heiligen Textes unterstützen soll, ist das die falsche Grundlage. Also konvertiere ich Tarteels Original selbst und lege die Datei auf eigenen Speicher.

Dass es dieselben Gewichte sind, ist nicht behauptet, sondern nachgewiesen: Meine F16-Konvertierung ist byte-identisch zur damaligen Fremddatei, SHA-256 aaebca10…50ead. Ein Hash ist hier der ganze Beweis, und er kostet nichts.

Was ich davon mitnehme

1. 01Bevor das Modell größer wird, prüfen, ob die Aufgabe Breite oder Tiefe braucht. Diese brauchte Tiefe.
2. 02Wenn die Anwendung weiß, was gleich gesagt wird, gehört diese Information ins Modell. Prompt-Konditionierung ist die billigste Genauigkeit, die zu haben ist.
3. 03Die Metrik muss zur Aufgabe passen. Exakte Gleichheit war hier die falsche Frage.
4. 04Bei allem, was von außen kommt, gilt: Herkunft dokumentieren, Identität hashen.

Der letzte Punkt hat einen Nebeneffekt, der über dieses Projekt hinausgeht. Die Buchstaben-Normalisierung ist inzwischen eine eigene Bibliothek, weil das Problem nicht auf Koran-Apps beschränkt ist. Jeder, der arabischen Text aus einem mehrsprachigen Modell mit einer Vorlage vergleicht, hat es.