In den letzten Monaten, während wir an unserem intelligenten Sprachassistenten SABOT gearbeitet haben, wurde uns klar, dass wir eine robuste Lösung für Speech-to-Text (STT) und Text-to-Speech (TTS) benötigen.
Und nicht irgendeine Lösung – wir brauchten eine, die lokal läuft, zuverlässig in industriellen Umgebungen funktioniert und sich nahtlos in die natürliche Sprachschnittstelle unseres Assistenten integrieren lässt. Als Team beschlossen wir, sie selbst zu entwickeln. In diesem Beitrag zeige ich, wie wir unsere Echtzeit-Sprach-API entwickelt haben, wie ihre Architektur aussieht und was wir dabei gelernt haben.
Wir entwickeln SABOT, unseren intelligenten Sprachassistenten, der speziell für industrielle Maschinen konzipiert ist. Mit SABOT können Maschinenbediener natürlich mit ihren Geräten sprechen – Befehle geben, Fragen stellen, Rückmeldungen erhalten – alles über Sprache.
Damit SABOT in einem Fabrikumfeld wirklich einsetzbar ist, brauchten wir hochwertige Sprachfunktionen, die offline arbeiten, aus Datenschutz- und Latenzgründen lokal betrieben werden können und unseren Kunden vollständige Kontrolle über die Lösung geben.
So begann das Projekt. Was als Anforderung für SABOT begann, entwickelte sich zu einer eigenständigen Komponente: einer modularen Sprach-API, die sowohl Echtzeit-Transkription als auch Sprachsynthese übernimmt. Wir setzen sie nun in SABOT ein und planen, sie in zukünftigen Kundenprojekten wiederzuverwenden.
Hier ist ein Überblick über das System:
Wir haben die API so entworfen, dass sie Live-Mikrofoneingaben in Echtzeit transkribieren, Textantworten in natürlich klingende Sprache umwandeln, effizient mit niedriger Latenz und guter Sprachunterstützung arbeiten, sich einfach in Systeme wie SABOT integrieren lässt und vollständig auf lokaler Infrastruktur läuft. Sie ist nun Teil der SABOT-Sprachpipeline, wurde aber so gebaut, dass sie in verschiedenen Setups wiederverwendet werden kann.
Unter der Oberfläche ist das System modular und skalierbar aufgebaut. Hier ist eine vollständige Aufschlüsselung der Architektur:
Unser Sprachverarbeitungssystem ist in drei verschiedene Ebenen unterteilt, die jeweils für einen bestimmten Teil der Sprachinteraktion optimiert sind. Die Client-Ebene läuft auf dem Gerät des Nutzers und steuert alle benutzerseitigen Interaktionen über eine koordinierte Gruppe von Komponenten. Der Audio Recorder erfasst und formatiert das Mikrofon-Rohsignal, wandelt es in PCM (Pulse-Code Modulation) um. Die Echtzeitkommunikation erfolgt über unseren WebSocket-Client, der Audioabschnitte an das Backend streamt, während der Recognition Result Receiver den transkribierten Text empfängt. Für den Rückkanal arbeiten der Request Processor und der REST-Client zusammen, um Text zur Sprachsynthese zu senden und die resultierende Audiowiedergabe über den Audio Player zu steuern, der die Sprachausgabe direkt über den Lautsprecher wiedergibt.
Die Sprach-API ist das rechentechnische Herzstück unseres Systems. Voice Activity Detection (VAD) dient als intelligenter Filter, der Stille und Hintergrundgeräusche herausfiltert und nur relevante Sprache zur Erkennungs-Engine weiterleitet. Dadurch bleibt das System effizient und präzise. Unsere Sprachverarbeitung und Erkennung basieren auf den Whisper-Modellen von OpenAI, die wir wegen ihrer Geschwindigkeit, Genauigkeit und Mehrsprachigkeit gewählt haben. Diese Modelle können für fachspezifische Vokabulare feinabgestimmt werden, was sie ideal für spezialisierte Anwendungen macht.
Für die Sprachsynthese nutzen unser Textprozessor und der Synthese-Engine die StyleTTS2-Architektur – eine Open-Source-Lösung mit Unterstützung für verschiedene Stimmenprofile über Geschlechter- und Sprachstile hinweg. Das Ergebnis ist eine natürliche, angenehme Sprachausgabe. Der Audio Streamer vervollständigt den Kreislauf, indem er das erzeugte Audio zurück an den Client streamt – für sofortige Wiedergabe.
Unsere Modellregistrierung verwaltet alle Modelle in einer strukturierten, leicht zugänglichen Form und ermöglicht reibungslosen Wechsel und Updates. Diese Architektur hält das System hochgradig modular, egal ob wir neue Stimmen hinzufügen, Sprachen wechseln oder für spezifische Hardware optimieren. Die Registry verwaltet sowohl STT- als auch TTS-Modelle, jeweils mit verschiedenen Stimmen und Stilen für unterschiedliche Anwendungen.
Von Anfang an war unser Ziel ein „local-first“-System. In industriellen Umgebungen bedeutet das: keine Cloud-Abhängigkeit – Maschinen verstehen und reagieren auch ohne Internetzugang. Außerdem volle Datenhoheit, da alle Audio- und Textdaten lokal bleiben, geringere Latenz für schnellere Reaktionen und maximale Kontrolle über Modelle, Stimmen und Verhalten. Diese Entscheidung prägte alle unsere technischen Weichenstellungen und führte zu einer robusten, eigenständigen Lösung.
Das System arbeitet nahtlos vom gesprochenen Wort bis zur Sprachausgabe. Bei Speech-to-Text spricht der Bediener ins Mikrofon, das Audio wird an das Backend gestreamt. VAD filtert Stille und Geräusche heraus, und die Erkennungs-Engine transkribiert die relevanten Teile. Der transkribierte Text wird an den Client zurückgesendet.
,Bei Text-to-Speech sendet der Client Text an das Backend, dieser wird verarbeitet und an die Synthese-Engine weitergeleitet. Das generierte Audio wird zurück an den Client gestreamt und in Echtzeit wiedergegeben.
Der Aufbau dieses Systems brachte uns wichtige Erkenntnisse zur Echtzeit-Sprachverarbeitung. VAD erwies sich als absolut entscheidend – ohne es verschwendete die STT-Engine Ressourcen auf Rauschen und Stille. Die passende VAD-Implementierung verbesserte die Performance erheblich. Streaming über WebSockets sicherte die geringste Latenz, essenziell für eine flüssige Nutzererfahrung. Die Entkopplung der Modelle über ein Registry-Muster erleichterte Upgrades und hielt die Kern-API logisch und modular.
Überraschenderweise hat auch in industriellen Kontexten die Stimmwahl erheblichen Einfluss auf die Nutzererfahrung. Eine gut gewählte Stimme lässt den Assistenten natürlicher und weniger robotisch wirken – etwas, das von den Nutzern stärker geschätzt wurde als erwartet. Zudem zeigte sich, dass die Feinabstimmung von STT- und TTS-Modellen auf bestimmte Vokabulare oder Akzente äußerst effektiv ist – ein spannender Bereich, den wir künftig weiter erkunden möchten.
Was als Komponente für SABOT begann, wurde zu einem Echtzeit-Sprach-API-Service, den wir projektübergreifend wiederverwenden und für verschiedene industrielle Anwendungsfälle anpassen. Wir arbeiten kontinuierlich an der Weiterentwicklung: mit Plänen zur Feinabstimmung der STT-Modelle für Branchen wie Automobil oder Fertigung, der Einführung gebrandeter Sprachprofile für Maschinen und der stärkeren Integration in multimodale Assistenten mit Sprach-, Bildschirm- und Gestensteuerung.
Der Aufbau dieser Sprach-API von Grund auf mit Open-Source-Modellen war für unser Team eine sehr bereichernde Erfahrung. Sie gab uns die nötige Flexibilität und Kontrolle und erlaubte es uns, eine Lösung zu schaffen, die exakt unseren Anforderungen entspricht. Ich hoffe, dieser Beitrag vermittelt Einblicke in unseren Entwicklungsprozess und die Herausforderungen, denen wir begegnet sind. Wenn Sie an ähnlichen Projekten arbeiten oder mehr über unser System erfahren möchten – sprechen Sie uns gerne an.
Vielen Dank fürs Lesen!
