Vapi führt Traffic Splitting ein: Änderungen an Voice Agents lassen sich auf Live-Anrufen testen

Was Traffic Splitting verändert

Laut Vapi konnten Teams zwar schon bisher Versionen eines Assistants anlegen, doch mit der Veröffentlichung wechselten alle Anrufe auf einen Schlag zur neuen Version. Entwickler hatten damit keine verlässliche Möglichkeit, bei echten Kunden zu prüfen, ob ein geänderter Prompt, ein anderes Modell oder eine neue Stimme wie gewünscht funktioniert oder ob sie besser abschneidet als die Vorgängerversion.

Das Unternehmen sagt, das habe Teams vorsichtig gemacht. In seinen Worten wurden Teams "erst vorsichtig, dann langsam, und irgendwann hörten sie auf zu iterieren, sobald alles gut genug war". Mit der neuen Funktion kann ein Team 0,1 %, 1 % oder 5 % der Anrufe an eine neue Version schicken, die Kennzahlen beobachten und anschließend vor- oder zurückrollen. Vapi beschreibt das als "im Grunde einen Canary für Ihren Assistant".

Peter Gomez, Member of the Technical Staff bei Vapi, der an der Funktion mitgearbeitet hat, argumentiert, das Risiko sei bei LLMs am größten, weil das Ergebnis einer Änderung nicht deterministisch sei. Schon ein einzelnes zusätzliches Schlüsselwort im Prompt könne Folgewirkungen haben, mit denen niemand gerechnet habe. Simulationen und Evals brächten Teams vor dem Start auf vielleicht 90 % Zuversicht, den Rest decke der Betrieb mit echten Anrufen ab.

So funktioniert es und so nutzen es Teams

Die größte technische Herausforderung sei gewesen, Code zu ändern, der im Hot Path liegt, also bei jedem Anruf durchlaufen wird, ob die Funktion genutzt wird oder nicht, sagt Gomez. Vapi habe alles hinter Feature Flags gelegt, umfangreich intern getestet und das Zurückrollen einfach gemacht.

Die zweite Herausforderung nennt Vapi Stickiness: Wiederholte Anrufer sollen bei derselben Version bleiben. Das Team musste dafür einen Anrufer über Telefonanrufe, Webanrufe, eingehende und ausgehende Gespräche hinweg identifizieren, damit jemand, der zurückruft, möglichst dieselbe Version bekommt. Die Identifikation lässt sich für Deployments, in denen das erforderlich ist, ein- oder ausschalten.

Vor dem Start betrieben laut Gomez manche Teams doppelte Assistants und routeten zwischen ihnen, andere versionierten über Vapis GitOps-Repository, wieder andere bauten eine eigene Routing-Logik mit dem Assistant Request als Notausgang. Die meisten dieser Lösungen seien komplexer und weniger zuverlässig als die integrierte Option, sagt er.

Die Kundendaten zeigen Vapi zufolge, dass Splits meist nur vorübergehend bestehen. Sobald ein Team einer neuen Version vertraut, stellt es den Assistant oft wieder auf "follow latest", sodass neue Versionen direkt den gesamten Traffic erhalten. Gomez beschreibt das Muster als "splitten, bestätigen, zurückschalten, wiederholen". Beim Austausch des LLM wird gesplittet, während eine kleine Prompt-Anpassung in der Regel direkt auf 100 % geht und ein paar Stunden später überprüft wird.

Empfehlungen und Ausblick

Vapi empfiehlt, mit Zwei-Wege-Splits zu beginnen. Die Funktion unterstützt auch mehr, doch bei zwei Varianten gleichzeitig ist klarer erkennbar, was einen Unterschied verursacht. Da jeder Anruf an seine Version gebunden ist, lassen sich Ergebnisse sauber zuordnen, und viele Experimente erreichen schnell statistische Signifikanz. Manche Änderungen, besonders bei geringerem Volumen oder stark schwankendem Traffic, brauchen unter Umständen eine Woche oder länger. Teams, die doppelte Assistants oder eigenes Routing nur pflegen, um das Alles-oder-nichts-Veröffentlichen zu umgehen, rät Vapi, eine Vereinfachung zu prüfen.

Frühe Nutzer setzen die Funktion laut Gomez eher als Gate ein denn als Werkzeug für lang laufende Experimente. Zudem habe die Zurückhaltung bei der Einführung von Teams gestammt, die sich bereits eine eigene Lösung gebaut hätten, denn eine funktionierende interne Lösung zu ersetzen, erfordere eine bewusste Entscheidung.

Auf der Roadmap sieht Gomez Traffic Splitting als Baustein für ergebnisbasierte Funktionen. Da Anrufe an Versionen gebunden sind, könnten automatische Rollouts neben statistischen Experimenten möglich werden. Sein Beispiel: Misst eine strukturierte Ausgabe die Deflection-Rate, könnte Vapi eine Version nur behalten, solange die Deflection stabil bleibt, und zurückrollen, wenn sie sinkt. Das Unternehmen prüfe diese Richtung noch, sagt er.

Für Entwickler auf Vapi bedeutet das praktisch: Wer ein neues Modell, einen neuen Prompt oder eine neue Stimme ausprobieren will, muss nicht mehr den gesamten Kundenstamm aussetzen. Anleitungen zur Einrichtung stehen in der Dokumentation von Vapi.