Echtzeit-Sprach-KI-Assistent: Backend-Erfolgsstory

Einen Echtzeit-Sprach-KI-Assistenten entwickeln: Die Reise des Backend-Teams

Der Sprach-KI-Assistent 'Suffler' unterstützt Vertriebsleiter während Live-Gesprächen. Das System klassifiziert Dienstleistungen, erkennt Einwände, nutzt RAG zum Abruf relevanter Daten und generiert Echtzeit-Textvorschläge. Die Eingabedaten stammen als Textsegmente aus dem Transkriptionsdienst der Voximplant-API. Eine obligatorische Latenz von 1,5 bis 2 Sekunden ist vorgeschrieben. Technologiestack: Python, FastAPI, PostgreSQL, feinabgestimmte BERT-Modelle und lokales Qwen 8B. Die On-Premise-Installation war für die Einhaltung der Sicherheitsvorgaben zwingend erforderlich.

Ein Team aus 12 Backend-Entwicklern ohne vorherige ML-Erfahrung erlernte innerhalb von sechs Monaten die Grundlagen und startete erfolgreich eine Pilotversion.

Proof-of-Concept in drei Wochen

Innerhalb der ersten drei Wochen lieferte das Team einen funktionsfähigen Prototyp:

• Verarbeitung von Gesprächstranskripten als Eingabedaten.
• Zwei BERT-Klassifikatoren: einer für mehr als 15 Dienstleistungen, ein zweiter für über 15 Einwandtypen, trainiert auf 1.500 annotierten Beispielen.
• FAISS-Vektor-Datenbanken mit Dienstleistungsbeschreibungen und Gesprächsskripten.
• Integration über Prompts mittels GPT.
• Eine Django-basierte Oberfläche zur Anzeige von Echtzeit-Vorschlägen.

Der Prototyp zeigte noch eine Verzögerung von 10 bis 15 Sekunden, überzeugte aber die Stakeholder von der Machbarkeit der Idee.

Architekturelle Weiterentwicklung: Komplexität reduzieren

Der ursprüngliche monolithischer Entwurf beinhaltete eine eigene Whisper-basierte Audio-Pipeline, mehrere Klassifikatoren, LLM-Finetuning, eine Vektor-Datenbank mit Feedback-Schleifen und eine geschätzte Entwicklungszeit von 12 bis 18 Monaten mit hohem Risiko.

Verzicht auf Fine-Tuning. Statt Qwen oder Llama auf Verkaufsskripte neu zu trainieren, setzte das Team auf RAG: Das Modell zieht kontextuelle Informationen direkt aus einer Wissensdatenbank ab. Dies reduziert Halluzinationen und entfällt umfangreiche Annotationen.

Verwendung eines fertigen Transkribierers. Voximplant liefert Textsegmente per REST – sparte zwei Monate Entwicklung einer internen Audio-Pipeline.

Vereinfachung der Klassifikatoren. Ein Multi-Class-Einwand-Detektor wurde durch einen binären Klassifikator (Einwand vorhanden/fehlt) ersetzt. Die detaillierte Analyse erfolgt während der Generierung durch das LLM. Die Inferenz auf einem GPU-Server verbesserte die Geschwindigkeit deutlich.

JSON-Suche statt Vektor-Datenbanken. Wissensbasen (Dienstleistungen, Skripte) werden als strukturierte JSON-Daten im Speicher gehalten. Schneller als FAISS oder Weaviate, ohne Netzwerkverzögerung.

Lokales LLM anstelle von Cloud. Cloud-APIs wie GPT oder DeepSeek verursachten Verzögerungen von 7 bis 20 Sekunden und waren durch Sicherheitsrichtlinien blockiert. Die lokale Ausführung von Qwen 8B auf einem GPU-Server erreichte ~2 Sekunden Antwortzeit mit präzisen Ausgaben.

Leichte Oberfläche. Eine einfache Django-Seite zur Anzeige von Vorschlägen ersetzte komplexe CRM-Integrationen.

Endgültiger Echtzeit-Verarbeitungspfad

Das System funktioniert folgendermaßen:

• Eingang von Textdaten über Voximplant.
• Binäre BERT-Klassifikation (Dienstleistung + Einwand).
• RAG-Abfrage in der in-Memory-JSON-Datenbank.
• Prompt-Generierung für Qwen 8B.
• Anzeige des Vorschlags in der Benutzeroberfläche.

Die Gesamtlatenz bleibt unter 2 Sekunden.

Datenmarkierung: Pragmatismus vor Perfektion

Die Markierung von 200 Dialogen dauerte Wochen, da kontextuelles Verständnis erforderlich war. Vertriebsmanager konnten schneller markieren, waren aber nicht skalierbar verfügbar.

Lösung: Fokus auf binäre Erkennung. Das LLM bearbeitet die Details des Einwands während der Generierung. Die Iterationszyklen wurden drastisch verkürzt.

Latenz als starre Vorgabe

Live-Gespräche erfordern Antwortzeiten unter 2 Sekunden. Cloud-APIs erwiesen sich als unzuverlässig. Das lokale Qwen 8B (im Vergleich zum 32B-Modell) opfert etwas Detailtreue zugunsten der Geschwindigkeit – eine notwendige Abwägung.

Sicherheit und Isolation

Ganzheitlicher On-Premise-Workflow:

• Voximplant-Transkription (nur externe Abhängigkeit).
• Interne Verarbeitung und Klassifikation.
• Lokal generierte Antworten durch das LLM.

Keine PII-Maskierung: 200–500 ms Einsparung, geringeres Risiko von Datenverfälschung, einschließlich eines Monats Entwicklungsaufwands.

Wichtige Erkenntnisse

• RAG statt Fine-Tuning beschleunigt die Markteinführung und minimiert den Aufwand bei der Datenannotation.
• Binäre Klassifikation + LLM vereinfacht die Einwanderdetektion ohne Qualitätsverlust.
• Lokales Qwen 8B bietet den richtigen Kompromiss zwischen Geschwindigkeit und Genauigkeit für Echtzeitanwendungen.
• JSON-Suche schlägt Vektor-Datenbanken bei kleinen, strukturierten Wissensbasen.
• On-Premise-Deployment löst gleichzeitig Sicherheits- und Latenzprobleme.

— Editorial Team