Sprache an der Quelle korrigieren

VoxRange betreibt KI-Agenten, die echte Telefonanrufe auf Urdu beantworten, und in der Mischung aus Urdu und Englisch mit ständigem Sprachwechsel, die Menschen tatsächlich sprechen. Ich bin der Lead Architect. In diesem Beitrag geht es um einen Fehler, den wir im Hörteil dieser Pipeline gemacht haben, und um die Regel, die ich daraus mitgenommen habe.

Das Symptom

Die Spracherkennung lieferte bei Urdu-Anrufen immer wieder vereinzelten Text in lateinischer Schrift mitten in Urdu-Transkripten. Schmalbandiges Telefonaudio, gemischte Sprachen und Namen machen die Transkription ohnehin schwer, und diese Fragmente verschlimmerten es: Was im Transkript steht, ist das, worauf der Agent reagiert.

Der naheliegende Schritt war, die Ausgabe zu bereinigen. Ist ein Agent auf Urdu eingestellt und kommt ein Fragment in lateinischer Schrift zurück, wird es verworfen, bevor der Agent es sieht.

Warum der Filter falsch war

Der Filter funktionierte insofern, als der Müll verschwand. Echte Sprache allerdings auch.

Anrufer bleiben nicht in einer Schrift. Viel Urdu wird als Roman Urdu in lateinischen Buchstaben geschrieben, und viele Alltagsgespräche wechseln für ein Wort oder eine ganze Phrase ins Englische. Ein erfundenes Beispiel: „mera appointment confirm kar dein“ ist eine gewöhnliche Bitte, und jedes Wort darin ist echte Sprache in lateinischen Buchstaben. Eine Regel, die Text in lateinischer Schrift entfernt, kann diesen Satz nicht von Rauschen unterscheiden, denn wenn sie läuft, ist das Einzige, was sie noch beurteilen kann, die Schrift, und die Schrift ist nicht das Problem.

Wir haben den Filter zurückgenommen. Ein engerer blieb: Schriften, die bei diesen Anrufen unmöglich echte Sprache sein können, etwa kyrillische oder CJK-Zeichen, werden weiterhin verworfen, weil ihr Entfernen nichts Echtes kostet.

Woher der Müll tatsächlich kommt

Die vereinzelten Fragmente waren ein Symptom dafür, dass die Hörstufe sich falsch verhielt, und genau dort gehört die Korrektur hin:

• Erkennung des Sprechendes. Die Sprachaktivitätserkennung entscheidet, wann ein Anrufer aufgehört hat zu sprechen. Entscheidet sie zu früh, wird ein Redebeitrag in Fragmente zerschnitten, und das Fragment eines Wortes ist genau die Art Audio, die ein Sprachmodell in selbstbewussten Unsinn verwandelt.
• Sprachverankerung. Dem Modell zu sagen, welche Sprache zu erwarten ist, statt es bei jedem kurzen Clip raten zu lassen, verhindert, dass es bei einem Rauschstoß in eine andere Sprache abdriftet.
• Vokabular. Namen, Orte und Fachbegriffe, die das Modell nie gesehen hat, kommen als knapp danebenliegende Vermutungen zurück. Ihm das Vokabular zu geben, das es hören wird, ist günstiger, als die Vermutungen zu reparieren.

Jede dieser Maßnahmen ändert, was das Modell hört oder erwartet. Keine davon wirft etwas weg, das der Anrufer gesagt hat.

Die verwandte Lektion: Konfigurationsdrift

Die Erkennung des Sprechendes hängt von einem Wert ab: wie lange auf Stille gewartet wird, bevor entschieden wird, dass der Anrufer fertig ist. Wir hatten ihn nach früheren Problemen bei Anrufen abgestimmt. Bei einem späteren Anruf stand er wieder auf einem aggressiven Wert, und der Agent unterbrach Anrufer mitten im Satz. Auch die fragmentierten Redebeiträge, die überhaupt erst die schlechten Transkripte verursacht hatten, waren zurück.

Der Wert existierte nur in der Umgebung eines Servers. Nichts im Code oder seiner Historie hielt den abgestimmten Wert fest, also hinderte ihn nichts daran, sich zu ändern. Ein solcher Abstimmungswert gehört in versionierte Konfiguration, neben den Code, der ihn liest, mit einer Notiz dazu, warum er so gesetzt ist:

# voice-runtime config, versioned with the code
# How long to wait in silence before ending the caller's turn.
# Too short cuts callers off and fragments transcripts.
END_OF_SPEECH_SILENCE_MS: <tuned value>

Derselbe Anruf lehrte noch etwas. Die Stille in einem Redebeitrag ist die Summe mehrerer Stufen: Warten auf das Sprechende, Transkription, Retrieval, das LLM und die Sprachsynthese. Einige davon wurden gemessen, eine nicht. Man kann nicht entscheiden, was optimiert werden soll, solange nicht jede Stufe eines Redebeitrags gemessen ist, denn die Stufe, die man nicht misst, ist die, über die man am Ende rät.

Was ich jemandem raten würde, der dasselbe baut

1. Wenn ein Modell Müll produziert, finden Sie die Stufe, die ihn verursacht hat, bevor Sie eine Regel schreiben, die ihn entfernt. Ausgabefilter sehen keine Ursachen.
2. Testen Sie jede Bereinigungsregel an echter, unordentlicher Sprache, einschließlich Sprachwechseln, bevor Sie ihr vertrauen.
3. Halten Sie Abstimmungswerte in versionierter Konfiguration mit einer Begründung fest, nicht nur in der Umgebung eines Servers.
4. Messen Sie jede Stufe eines Redebeitrags, bevor Sie eine davon optimieren.