Bea v3 in der Entwicklung: Wie Voicebot 3.0 entsteht

BERTA Lab | Februar 2029

Vor knapp drei Jahren haben wir Bea live geschaltet — einen Enterprise-Voice-Assistenten für das Vergaberecht, gebaut auf LiveKit, Mistral Voxtral und einem selbst entwickelten RAG-Backend. Seit März 2027 ist sie im produktiven Einsatz. Wir haben viel gelernt.

Jetzt bauen wir Bea v3. Dieser Post ist kein Launch-Bericht, sondern ein Einblick in den Entwicklungsprozess — was wir ändern, warum, und welche Architekturentscheidungen wir treffen.

Was Bea v2 gut gemacht hat — und wo die Grenzen lagen

Bea v2 ist robust. Sie versteht Vergaberecht-Fragen, gibt kontextbezogene Antworten aus unserem RAG-Backend, und hält sich an die Grenzen des Systems: Wenn sie etwas nicht weiß, sagt sie das.

Aber zwei Jahre Produktiveinsatz zeigen Muster, die wir mit v2 nicht vollständig lösen konnten:

Kontextverlust bei längeren Gesprächen. Ab einem gewissen Gesprächsverlauf verlor Bea v2 den Thread früherer Aussagen. Nutzer mussten sich wiederholen. Das erzeugt Frustration — besonders bei komplexen Ausschreibungsprozessen, die über mehrere Gespräche gehen.

STT-Halluzinationen in Pausen. Unsere Speech-to-Text-Engine halluzinierte in natürlichen Gesprächspausen gelegentlich englische Sätze. Ein bekanntes Problem — und eines, das uns motiviert hat, die STT-Architektur grundlegend zu überarbeiten.

Kein Multimodal-Support. Nutzer wollten Dokumente einreichen und darüber sprechen. „Kannst du mir diesen Abschnitt aus der Vergabeakte erklären?" Bea v2 konnte das nicht. Bea v3 soll es können.

Markdown im TTS. Das LLM-Backend produzierte strukturierte Antworten mit Markdown-Formatierung, die von der TTS-Engine vorgelesen wurde. Bulletpoints als wörtliche Sternchen. Das ist kein großes Problem — aber ein nerviges.

Die Architektur von Bea v3

Wir nehmen Bea v3 als Gelegenheit, die Architektur grundlegend zu überarbeiten. Nicht alles auf einmal, aber mit klarer Richtung.

Persistent Memory Layer

Das größte neue Element: ein persistenter Gedächtnislayer, der Gespräche über Sessions hinweg kontextualisiert.

Bea v3 weiß, dass dieser Nutzer letzte Woche nach der VOB/B gefragt hat. Sie weiß, welche Ausschreibungen der Nutzer in der Vergangenheit eingereicht hat. Sie nutzt diesen Kontext, ohne dass der Nutzer ihn jedes Mal neu herstellen muss.

Wir implementieren das mit einem Mem0-ähnlichen Ansatz: selektive Persistenz relevanter Gesprächselemente, explizit keine vollständige Transkript-Speicherung (DSGVO-konform), mit Nutzer-Kontrolle über das, was gespeichert wird.

Audio-Native Modell als STT-Basis

Statt der bisherigen Whisper-basierten Pipeline wechseln wir auf ein audio-natives Modell als primäre STT-Komponente. Audio-native Modelle verstehen gesprochene Sprache als Ganzes — sie interpolieren nicht durch das Transkript, sondern durch den Audio-Kanal selbst. Pausen werden korrekt als Pausen interpretiert.

Die Herausforderung: Audio-native Modelle sind in der Regel größer und latenz-intensiver als Whisper-Varianten. Wir testen aktuell, ob wir die Latenz unter 300ms halten können — das ist unsere Grenze für flüssige Gesprächsführung.

Multimodal Input Processing

Bea v3 bekommt einen Dokumenten-Input-Kanal. Nutzer können während eines Gesprächs PDFs oder Bilder einreichen, über die Bea dann spricht.

Das klingt einfacher als es ist. Das Modell muss den visuellen Kontext und den gesprochenen Kontext synchronisieren — und klar kommunizieren, worauf es sich bezieht. Wir arbeiten an einem Referenz-Framework, das expliziert: „Du hast mir Seite 3 des Dokuments gezeigt, Abschnitt 4.2..."

Response Sanitization Pipeline

Für das Markdown-im-TTS-Problem bauen wir eine dedizierte Response-Sanitization-Pipeline, die LLM-Output vor der TTS-Übergabe bereinigt: Markdown-Syntax entfernen, Listenpunkte in natürliche Sprache überführen, Fußnoten auflösen.

Das ist technisch trivial — aber es verbessert die User Experience spürbar.

Was wir lernen: KI-Produktentwicklung ist iterativ, nicht linear

Der interessanteste Aspekt bei der Entwicklung von Bea v3 ist nicht die Technologie, sondern der Prozess.

Wir wussten von den meisten Problemen bereits kurz nach dem Bea-v2-Launch. Aber die Entscheidung, sie zu beheben, kam nicht sofort — sie kam, als wir genug Nutzungsdaten hatten, um zu verstehen, welche Probleme wirklich die User Experience blockieren und welche lediglich stören.

Kontextverlust: harte Blockade. Nutzer brechen Gespräche ab.
STT-Halluzinationen: Störfaktor, aber kein Abbruchgrund. Nutzer korrigieren und machen weiter.
Markdown im TTS: nervig, aber tolerierbar.
Kein Multimodal: verpasste Gelegenheit, kein akuter Schmerzpunkt.

Diese Priorisierung hat die Architektur von Bea v3 beeinflusst: Persistent Memory bekommt die meiste Aufmerksamkeit, weil Kontextverlust der häufigste Abbruchgrund war.

Timeline und nächste Schritte

Wir planen Bea v3 für Frühjahr 2029. Der Launch-Post kommt im März.

Was wir bis dahin noch lösen müssen:

• Audio-native STT-Latenz unter 300ms (aktuell: ~450ms im Test)
• DSGVO-konforme Memory-Consent-Flows für Nutzer
• Integration der Dokumenten-Pipeline in das bestehende LiveKit-Setup
• Performance-Baseline für Bea v3 vs. Bea v2 (Latenz, Qualität, Kontextgenauigkeit)

Wer ähnliche Voice-KI-Systeme baut und Erfahrungen mit audio-nativer STT oder persistenter Gedächtnisarchitektur hat — ich freue mich auf den Austausch.

Daniel Röding
KI-Architekt und Leiter BERTA Lab, Bechtle AI Competence Center Bremen

#KI #EnterpriseKI #BERTALab #Voicebot #BeaV3 #VoiceAI #Multimodal #STT #LLM #OnPremiseKI