Agentic AI im Einsatz ->

KI-Interviews mit Tausenden Teilnehmern: Skalierung und Observability

Wie man KI-moderierte Interviews auf Tausende parallele Gespräche skaliert – und mit welchen Kennzahlen man KI-Systeme im Betrieb überwacht: Token-Monitoring, Time-to-First-Token, Abbruchstellen.

Dr. Andreas Ejupi

Dr. Andreas Ejupi

AI Research

Ein KI-Interviewer, der ein Gespräch führt, ist schnell gebaut. Ein System, das Hunderte oder Tausende Gespräche gleichzeitig führt – jedes mit flüssigen Antworten, Nachfragen und sauberer Auswertung – ist eine andere Aufgabe. Und sie scheitert selten dort, wo man es erwartet.

Die häufigste Annahme lautet: “Das KI-Modell macht die Arbeit, der Rest ist eine normale Webanwendung.” In der Praxis liegt die Herausforderung woanders: bei Lastspitzen, bei den Kapazitätsgrenzen der Modellanbieter – und vor allem bei der Frage, ob man überhaupt sieht, was das System gerade tut. In diesem Beitrag geht es darum, worauf es bei der Skalierung ankommt und welche Kennzahlen man dafür von Anfang an messen sollte.


Warum Interviews anders skalieren als Webseiten

Eine normale Webanwendung beantwortet kurze Anfragen: Request rein, Millisekunden später Antwort raus. Ein KI-Interview verhält sich anders:

  • Lange Sitzungen: Ein Gespräch dauert 5–15 Minuten und hält währenddessen eine offene Verbindung zum Server, über die Antworten in Echtzeit gestreamt werden.
  • Alles kommt auf einmal: Nach einem E-Mail-Versand an 10.000 Empfänger klickt ein erheblicher Teil innerhalb der ersten Stunde. Das System muss binnen Minuten von null auf Hunderte parallele Gespräche kommen.
  • Der Engpass ist das Modell, nicht der Server: Jede Teilnehmerantwort löst einen Aufruf beim KI-Modell aus – mit dem gesamten bisherigen Gesprächsverlauf als Kontext. Die knappe Ressource ist deshalb nicht Rechenleistung, sondern das Kontingent an Tokens, das der Modellanbieter pro Minute verarbeitet.

Expert Insight: Kapazität plant man hier nicht in “Anfragen pro Sekunde”, sondern in Tokens pro Minute. Bei einigen Hundert parallelen Gesprächen liegt man schnell über den Standard-Limits gängiger API-Tarife – das sollte man wissen, bevor die erste große Welle startet.


Die Grundprinzipien der Skalierung

Drei Prinzipien haben sich für Interview-Systeme bewährt:

Gespräche dürfen nicht an einen einzelnen Server gebunden sein. Liegt der Gesprächszustand in einem zentralen Speicher statt auf dem Server selbst, kann jede Instanz jeden Gesprächsschritt übernehmen. Erst dadurch kann das System bei steigender Last automatisch zusätzliche Instanzen hinzunehmen – und ein Verbindungsabbruch oder ein Software-Update beendet kein laufendes Interview.

Caching nutzen. Nicht alles muss bei jedem Gesprächsschritt neu verarbeitet werden. Durchdachtes Caching senkt die Kosten pro Gespräch und verkürzt die Antwortzeiten – ein Effekt, der sich bei Tausenden Interviews vervielfacht.

Die Auswertung vom Gespräch entkoppeln. Tausend Interviews erzeugen Millionen Wörter Transkript. Qualitätsprüfung, Bot-Erkennung, Themenextraktion und Sentiment-Analyse laufen deshalb als eigener Prozess im Hintergrund – sie dürfen die laufenden Gespräche nie ausbremsen. Wie die automatisierte Auswertung funktioniert, haben wir hier beschrieben.


Observability: Man kann nur skalieren, was man sieht

Der unterschätzte Teil der Skalierung ist nicht die Infrastruktur – es ist die Sichtbarkeit. Ein klassischer Server meldet CPU und Speicher. Ein KI-System braucht eigene Kennzahlen, denn seine Engpässe liegen woanders. Diese vier haben sich als die wichtigsten erwiesen:

Liniendiagramm: Time-to-First-Token im Tagesverlauf – der Median bleibt unter 1 Sekunde, das 95. Perzentil steigt nach jeder Einladungswelle auf fast 5 Sekunden

1. Time-to-First-Token (TTFT)

Die Zeit vom Absenden der Teilnehmerantwort bis zum ersten Wort der KI-Antwort. Das ist die Kennzahl, die Teilnehmer direkt spüren: Bleibt der Bildschirm zwei, drei Sekunden leer, steigt die Abbruchrate messbar. Wichtig dabei:

  • Pro Gesprächsschritt messen, nicht pro Interview – die TTFT steigt mit wachsendem Gesprächskontext, und genau diesen Anstieg will man sehen.
  • Perzentile statt Durchschnitt: Der Median kann bei 800 Millisekunden liegen, während jedes zwanzigste Gespräch fünf Sekunden wartet. Der Durchschnitt versteckt genau die Teilnehmer, die abbrechen.
  • Ein schleichender TTFT-Anstieg über Tage ist ein Frühwarnsignal – oft kündigt sich so an, dass das Kontingent beim Modellanbieter an seine Grenze kommt, lange bevor echte Fehler auftreten.

2. Token-Verbrauch pro Gesprächsschritt und pro Interview

Tokens sind bei KI-Systemen das, was bei klassischen Anwendungen CPU-Zeit ist: die eigentliche Kostengröße. Deshalb gehört zu jedem Modell-Aufruf ein Protokoll mit Input-Tokens, Output-Tokens und der Cache-Nutzung. Daraus ergeben sich drei Auswertungen:

  • Kosten pro Interview: Erst mit dieser Zahl lässt sich seriös kalkulieren, was eine Studie mit 10.000 Teilnehmern kostet – und ob sich eine Leitfaden-Kürzung rechnet.
  • Cache-Trefferquote: Fällt sie plötzlich ab, steckt meist eine unbeabsichtigte Änderung an der Konfiguration dahinter – und jeder Gesprächsschritt kostet ein Vielfaches. Ohne Monitoring fällt das erst auf der Monatsrechnung auf.
  • Ausreißer-Erkennung: Ein Interview, das das Fünffache der üblichen Tokens verbraucht, ist ein Warnsignal – eine Endlos-Nachfrageschleife, ein Teilnehmer, der das System absichtlich in lange Diskussionen verwickelt, oder ein Prompt-Injection-Versuch.

3. Abbruchstellen im Gesprächsverlauf

Wo genau steigen Teilnehmer aus? Diese Kennzahl verbindet Technik und Inhalt: Verteilen sich Abbrüche gleichmäßig und korrelieren mit hoher TTFT, ist es ein Infrastrukturproblem. Häufen sie sich an einer bestimmten Frage, ist der Leitfaden das Problem – zu lang, zu persönlich, unverständlich formuliert. Bei 20 Interviews sieht man das beim Lesen der Transkripte; bei 20.000 sieht man es nur noch im Dashboard.

4. Strukturierte Logs pro Gesprächsschritt

Jeder Schritt sollte als ein durchsuchbarer Eintrag protokolliert werden: Session-ID, Zeitstempel, TTFT, Token-Zahlen, aufgerufene Werkzeuge, Fehlercode. Das klingt banal, entscheidet aber über die Fehlersuche: Meldet ein Teilnehmer “die Umfrage hing plötzlich”, muss sich das konkrete Gespräch in Sekunden rekonstruieren lassen – bei Hunderten parallelen Sessions geht das nur mit strukturierten, nach Session filterbaren Logs.

Expert Insight: Bauen Sie das Monitoring vor der ersten großen Welle, nicht danach. Kennzahlen wie TTFT und Token-Verbrauch kosten wenige Zeilen Code, wenn man sie von Anfang an mitschreibt – aber sie nachträglich für vergangene Interviews zu rekonstruieren, ist unmöglich.


Der Weg in die Breite: erst testen, dann staffeln

Bewährt hat sich ein dreistufiges Vorgehen:

  1. Pilot mit 20–50 Teilnehmern: Leitfaden validieren und die Transkripte tatsächlich vollständig lesen. Fragt die KI an den richtigen Stellen nach? Jede Schwäche im Leitfaden multipliziert sich später mit der Teilnehmerzahl. Gleichzeitig liefert der Pilot die Referenzwerte für das Monitoring: übliche TTFT, üblicher Token-Verbrauch pro Interview.
  2. Lasttest vor der großen Welle: Simulierte Teilnehmer gegen das echte System fahren – einschließlich echter Modell-Aufrufe. Erst dabei zeigen sich Kontingent-Grenzen und Verbindungslimits, die im Normalbetrieb unsichtbar bleiben.
  3. Gestaffelter Versand: Einladungen in Kohorten verschicken statt als einzelnen Blast, etwa viermal 2.500 im Stundenabstand. Das glättet die Lastspitze – und zwischen den Kohorten zeigt das Dashboard, ob TTFT und Abbruchrate stabil bleiben, bevor die nächste Welle startet.

Expert Insight: Skalieren Sie nie den ersten Entwurf. Die 50 Pilot-Interviews kosten einen Tag – ein schwacher Leitfaden bei 10.000 Teilnehmern kostet die ganze Studie.


Fazit

Die Skalierung von KI-Interviews entscheidet sich nicht im KI-Modell, sondern in der Architektur darum herum: ein Gesprächszustand, der unabhängig vom einzelnen Server gehalten wird; durchdachtes Caching; eine Auswertung, die entkoppelt im Hintergrund läuft. Und vor allem: Observability von Anfang an – Time-to-First-Token in Perzentilen, Token-Verbrauch pro Interview, Abbruchstellen im Gesprächsverlauf und strukturierte Logs pro Gesprächsschritt.

Denn bei tausend parallelen Gesprächen liest niemand mehr mit. Was man nicht misst, sieht man nicht – und was man nicht sieht, skaliert nicht.


Weiterführende Artikel


Selbst ausprobieren

Erstellen Sie eine KI-moderierte Umfrage und testen Sie das Interview-Erlebnis selbst.

Demo testen