Dialekte, Namen und Adressen: die unspektakulären Härtetests für Voice AI im DACH-Alltag
Ein Agent kann über komplexe Produkte sprechen und an „Schröder-Laux“ oder einer Schweizer Telefonnummer scheitern. Genau diese Details entscheiden, ob der Vorgang später nutzbar ist.
Das Wichtigste
- Eigennamen und Identifikatoren werden anders behandelt als freie Sprache: segmentieren, normalisieren, rücklesen.
- Das interne Datenformat bleibt eindeutig; die gesprochene Darstellung passt sich Land und Nutzer an.
- Bei wiederholter Unsicherheit wechselt der Agent Methode oder Kanal, statt selbstbewusst zu raten.
Der teure Fehler klingt oft langweilig
Eine falsche Pointe ist peinlich. Eine falsch erfasste Hausnummer landet beim falschen Kunden, eine vertauschte Ziffer verhindert den Rückruf, und ein fehlender Bindestrich kann einen Datensatz unauffindbar machen. Solche Angaben tragen viel Bedeutung in wenigen Lauten. Sie verdienen einen eigenen Erfassungsmodus statt dieselbe lockere Dialoglogik wie eine offene Frage.
Intern sollten Telefonnummern einem eindeutigen internationalen Format folgen; der E.164-Standard bildet die Grundlage des internationalen öffentlichen Nummerierungsplans. Gesprochen wird die Nummer trotzdem in gut hörbaren Gruppen und in der gewohnten lokalen Form zurückgelesen.[1]
Vier Datentypen, vier kleine Strategien
| Datentyp | Erfassung | Bestätigung |
|---|---|---|
| Name | frei sprechen, bei Unsicherheit buchstabieren | vollständig, mit markierten Sonderzeichen |
| Rufnummer | Ziffern gruppieren und Land klären | in kurzen Gruppen zurücklesen |
| lokalen Teil, at, Domain getrennt | langsam und mit Punkt/Bindestrich | |
| Adresse | Straße, Hausnummer, PLZ, Ort separat | kritische oder unsichere Felder gezielt |
Dialekt ist kein Fehlerzustand
Der Agent sollte nicht verlangen, dass Menschen „deutlicher Deutsch“ sprechen. Er kann seine eigene Ausgabe langsamer machen, eine Frage verkürzen, Kontext nutzen und einzelne Werte isolieren. Entscheidend ist, Unsicherheit sichtbar zu behandeln: Eine wahrscheinliche Erkennung darf nicht still in einen verbindlichen Datensatz wandern.
- Häufige regionale Orts- und Straßennamen in die Testdaten aufnehmen.
- Mischformen aus Dialekt, Standardsprache und fremdsprachigen Produktnamen abdecken.
- Bestätigung neutral formulieren: „Ich habe … verstanden“ statt „Sie haben … gesagt“.
- Nach zwei erfolglosen Reparaturen eine andere Methode anbieten: Buchstabieren, SMS-Link oder Mensch.
Ein lokales Testset schlägt die allgemeine Sprachdemo
Jeder Standort hat sein eigenes schwieriges Vokabular: Gemeindenamen, Familiennamen, Modellreihen, Versicherer, Ärzte oder Straßen. Aus anonymisierten realen Fehlern entsteht ein kuratiertes Set mit Audio- oder Aussprachevarianten und erwarteter Normalform. Das Set läuft nach Änderungen an Stimme, Erkennung, Prompt oder Datenmodell erneut.
Die Auswertung sollte Fehlerarten unterscheiden. Wurde das Wort akustisch falsch erkannt, aus dem Kontext falsch normalisiert oder erst beim Schreiben ins Zielsystem verändert? Diese Trennung verhindert, dass ein Team an der Stimme feilt, obwohl in Wahrheit eine Adressvalidierung „St.“ ungefragt zu „Sankt“ umgebaut hat. Zu jedem Test gehören deshalb gehörte Form, interne Normalform und gespeicherter Zielwert.
Die richtige Antwort kann „nicht sicher“ sein: Wenn der Agent eine Zeichenfolge nicht zuverlässig erfassen kann, ist eine transparente Lücke besser als ein syntaktisch gültiger, aber falscher Wert. Der Prozess braucht dafür eine sichere Nachbearbeitung.
Quellen und Prüfstand
Primärquellen der Anbieter, zuletzt geprüft am 19. August 2026.
- [1]ITU-T E.164 – The international public telecommunication numbering plan · International Telecommunication Union · abgerufen am 19. August 2026
