Zum Hauptinhalt springen

Architektur

Architektur der Sprachinteraktion

Wie eine Transkription auf dem Gerät und ein gehostetes Stimmmodell einen belegbasierten Assistenten umschließen: Die Stimme der Besucher bleibt im Browser, der Assistent sieht nur Text, und geprüfte Antworten werden auf Wunsch vorgelesen.

Veröffentlicht am 5. Oktober 2026

Mit dem Fotografie-Kurator und dem Engineering-Ask meines Portfolios kann man sprechen, und beide können ihre Antworten vorlesen. Keiner der beiden Assistenten weiß davon. Die Spracherkennung macht aus der Stimme der Besucherin oder des Besuchers einen bearbeitbaren Entwurf im selben Textfeld, in das man auch hätte tippen können, und die Sprachsynthese liest die fertige, geprüfte Antwort danach vor. Diese Fallstudie handelt davon, beide Systeme außerhalb des Assistenten zu halten: ein kleines Modell auf dem Gerät der Besucher zum Zuhören, ein gehostetes Stimmmodell zum Sprechen – und Text als das Einzige, was in das System gelangt, das tatsächlich denkt.

Das Problem

Tippen ist nicht immer der beste Weg, ein Fotoarchiv zu erkunden. „Zeig mir ruhige Straßen bei Nacht“ ist leichter gesagt als getippt, und eine Antwort über eine Reihe von Fotos hört man gern, während man sie ansieht. Sprache bringt aber Probleme mit sich, die Text nicht hat:

  • Mikrofonaudio ist persönlich. Es kann Dinge enthalten, die niemand senden wollte, und Audio an einen Server zu schicken ist ein anderes Versprechen als eine getippte Frage.
  • Zwei Sprachen. Die Seite funktioniert auf Englisch und Deutsch. Ein Modell, das Deutsch als Englisch missversteht, erzeugt eine selbstbewusste, falsche Frage.
  • Browser unterscheiden sich. Audiowiedergabe, Mikrofonzugriff und Inferenz auf dem Gerät verhalten sich in Chrome, Firefox und Safari unterschiedlich, auf dem Desktop anders als auf dem Smartphone.
  • Der Assistent ist ohnehin schwer richtig zu machen. Der Kurator ist ein belegbasiertes System mit Validatoren für alles, was er sagt. Ihn sprachfähig zu machen, würde die Fläche vervielfachen, die diese Validatoren abdecken müssen.

Die Designvorgabe

Der Assistent bleibt textbasiert. Sprache ist ein Adapter auf beiden Seiten:

  • Eingabe: Audio → Transkription → ein bearbeitbarer Textentwurf → der bestehende Absendeweg.
  • Ausgabe: die geprüfte Textantwort → Sprachsynthese → Audio.

Die Anfrage an den Assistenten enthält die Frage und nichts darüber, wie sie entstanden ist: Es gibt kein Sprach-Flag. Nichts, was der Assistent tut, hängt davon ab, ob die Antwort gelesen, gehört oder beides wird.

Die Architektur im Überblick

EINGABE · auf dem Gerät

Mikrofon
   │  Rohaudio, nur im Speicher
   ▼
Audioaufnahme (AudioWorklet)
   │  16 kHz Mono-Samples
   ▼
Whisper-tiny im Web Worker
  WebGPU, sonst WebAssembly
   │  Transkript
   ▼
Entwurf ◄── Tastatur
   │  geprüft, dann gesendet
   ▼
════════════ TEXT ════════════
   │
   ▼
Bestehender Assistent
  Retrieval · Belege ·
  Validierung
   │
   ▼
Geprüfte Textantwort
   ├─────► als Text angezeigt
   │
   ▼  nur auf Wunsch gesprochen
Vorlesetext
  ohne Markup, segmentiert
   │  signierter Antworttext
   ▼
Sprach-Route (mein Server)
   │
   ▼
Grok Voice, Stimme „eve“,
  über OpenRouter
   │  gestreamtes PCM-Audio
   ▼
Web-Audio-Wiedergabe
  • Aufnahme und Transkription laufen vollständig im Browser. Der Mikrofonstream speist einen kleinen Audioprozessor, der Samples sammelt, bis die Aufnahme endet, und sie dann an einen Hintergrund-Worker übergibt, in dem das Sprachmodell läuft.
  • Der Entwurf ist dasselbe Textfeld, in das man tippt. Das Transkript wird nie automatisch gesendet, sodass Erkennungsfehler sichtbar und korrigierbar sind, bevor irgendetwas den Assistenten erreicht.
  • Der Assistent bleibt von Sprache unberührt. Er beantwortet eine Zeichenkette.
  • Das Vorlesen beginnt mit genau der Antwort, die die Validatoren freigegeben haben. Ein Formatierer entfernt, was nicht gesprochen werden soll, etwa Zitatmarker und Links, und teilt den Text in kurze Abschnitte, damit der erste Ton schnell kommt. Nichts formuliert die Antwort um.
  • Die Synthese geschieht in der Sprach-Route meines Servers, die das gehostete Stimmmodell aufruft und das Audio zurückstreamt, während es entsteht.
  • Die Wiedergabe nutzt die Web-Audio-API des Browsers und plant jeden Abschnitt direkt im Anschluss an den vorherigen.

Eingabe: lokale Transkription

Das Transkriptionsmodell ist Whisper-tiny, mehrsprachig, ausgeführt mit Transformers.js und ONNX Runtime Web in einem eigenen Web Worker, damit die Seite währenddessen reaktionsfähig bleibt. Es versucht zuerst WebGPU und fällt auf WebAssembly zurück, wenn WebGPU fehlt, sich nicht initialisieren lässt oder in derselben Sitzung bereits gescheitert ist.

Woher das Modell kommt. Gewichte und Laufzeit werden von meiner eigenen Seite ausgeliefert, aus einer festen Liste versionierter Dateien – nicht zur Laufzeit von einem Modell-Hub oder einem fremden CDN geladen. Der Browser speichert sie zwischen. Die erste Nutzung lädt rund 66 MB Gewichte; spätere Besuche laden aus dem Cache.

Genauigkeit. Die erste ausgelieferte Version nutzte durchgehend volle Genauigkeit, ein Download von 154 MB. Das ganze Modell zu quantisieren verfehlte die englische Qualitätsschwelle (88,5 % erhaltene Absicht gegenüber einer Schwelle von 95 %). Weitere Messungen zeigten, dass die englische Qualität von der Genauigkeit des Encoders abhängt, nicht von der des Decoders. Die ausgelieferte Version behält deshalb einen Encoder mit voller Genauigkeit und einen quantisierten Decoder: 57 % kleiner, die erste Vorbereitung ungefähr halbiert, die Qualität gehalten.

Wann sie angeboten wird. Spracheingabe erscheint nur, wo sie funktionieren kann: auf einer sicheren Seite, mit Mikrofon- und Audio-APIs, Web Workern und WebAssembly. Auf Geräten, die primär per Touch bedient werden, etwa Smartphones, ist sie bewusst deaktiviert. Mobile Inferenz auf dem Gerät wurde nicht als tragfähig gemessen; dort erscheint der Mikrofon-Button nicht, und Tippen ist der Weg. Der Modell-Download beginnt erst, nachdem die Mikrofonberechtigung erteilt wurde – eine Ablehnung kostet also nichts.

Warum die Transkription auf dem Gerät läuft

Das Ziel stand fest, bevor ein Modell gewählt wurde: Englisch und Deutsch vollständig auf dem Gerät der Besucher transkribieren, ohne dass Rohaudio den Browser verlässt und ohne neuen Anbieteraufruf. Der Grund ist Datenschutz. Eine gesprochene Frage kann mehr enthalten, als beabsichtigt war, und das am besten geschützte Audio ist das, das das Gerät nie verlässt.

Diese Entscheidung hatte Kosten, die ich in Kauf genommen und gemessen habe, statt sie zu verbergen:

  • Ein einmaliger Download von rund 66 MB.
  • Kaltstart. Die erste Vorbereitung dauerte nach der Optimierung rund 7,3 Sekunden statt rund 14,5. Warm dauert das Transkribieren einer kurzen Frage etwa ein bis anderthalb Sekunden mit WebAssembly und etwa 0,6 Sekunden mit WebGPU.
  • Die Genauigkeit eines kleinen Modells. Der Entwurf ist bearbeitbar, gerade weil ein winziges Modell Fehler macht.

Die Dateien liefere ich aus Gründen der Lieferkette und des Datenschutzes selbst aus, nicht wegen der Geschwindigkeit: Der Browser lädt genau die festgelegten Dateien, die ich bereitgestellt habe, von meiner Domain und sonst nichts. Einen automatischen Rückfall auf einen Cloud-Transkriptionsdienst gibt es bewusst nicht.

Die Grenze zum Assistenten

Getippte und gesprochene Fragen laufen in einer Zeichenkette zusammen, in einem Textfeld, abgeschickt über einen Handler. Die Anfrage an den Assistenten enthält die Frage und ihren optionalen Gesprächskontext. Sie hat kein Feld, das sagt: „Das kam aus einem Mikrofon.“

Diese Grenze ist die zentrale Architekturentscheidung, und sie zahlt sich mehrfach aus:

  • Ein Denkweg. Retrieval, Belegauswahl und Validatoren sind für jede Frage dieselben. Als Sprache hinzukam, musste nichts neu validiert werden.
  • Tests bleiben textbasiert. Benchmarks und Evaluationen des Assistenten messen weiterhin Text hinein, Text heraus.
  • Austauschbare Teile. Transkriptionsmodell und Stimmmodell können sich jeweils ändern, ohne den Assistenten zu berühren. Die Stimme ist Konfiguration, kein Code.
  • Kontrollierte Herabstufung. Ist Spracheingabe nicht verfügbar, funktioniert das Textfeld weiter. Scheitert die Sprachausgabe, steht die geschriebene Antwort bereits auf dem Bildschirm.
  • Text bleibt maßgeblich. Was gelesen wird, ist das, was geprüft wurde; was gehört wird, ist eine Wiedergabe davon, nie eine eigene Generierung.

Dasselbe Spracheingabemodul dient beiden Assistenten und ist bewusst domänenblind: Sein Vertrag endet bei einem Transkript, und es importiert nichts aus einem der beiden Produkte.

Ausgabe: gesprochene Antworten

Das Vorlesen ist standardmäßig aus und beginnt nur, wenn die Besucher es wünschen – pro Antwort oder mit einem „Auto“-Modus, der jede neue Antwort spricht. Es gibt es nur, wenn tatsächlich eine Antwort entstanden ist: Ablehnungen werden nie gesprochen.

Das Stimmmodell ist Grok Voice (grok-voice-tts-1.0) mit der Stimme „eve“, erreicht über den Sprach-Endpunkt von OpenRouter. Der Server sendet Text und erhält rohes PCM-Audio mit 24 kHz, gestreamt, während es entsteht. Rohes PCM bedeutet, dass der Browser keinen Audiocodec dekodieren muss; das Format verhält sich überall gleich.

Nur echte Antworten können gesprochen werden. Jede Antwort trägt eine signierte Freigabe über ihren genauen Text und ihre Sprache. Die Sprach-Route lehnt jeden Text ab, den sie nicht selbst erzeugt hat, und ist ratenbegrenzt. Sie ist kein allgemeiner Text-zu-Sprache-Endpunkt; niemand kann über sie auf meine Kosten beliebigen Text sprechen lassen.

Streaming und Segmentierung. Die Antwort wird in kurze Abschnitte geteilt, der erste bewusst klein. Der Browser fordert die Abschnitte in einer begrenzten Pipeline an und beginnt mit der Wiedergabe, sobald etwa eine Drittelsekunde Audio da ist. Jeder Abschnitt wird direkt nach dem vorherigen geplant, sodass die Antwort ohne Unterbrechung läuft.

Steuerung und Lebenszyklus. Anhören, Pause, Fortsetzen und erneutes Abspielen sind ein Bedienelement pro Antwort. Eine neue Frage, das Schließen des Panels oder der Wechsel zu einem anderen Foto beendet das aktuelle Vorlesen und bricht seine laufenden Anfragen ab. Pro Assistent spielt immer nur ein Vorlesen. Nichts wird zwischengespeichert: Erneutes Abspielen fordert das Audio neu an.

Warum Eingabe und Ausgabe verschiedene Modelle nutzen

Die beiden Richtungen haben unterschiedliche Aufgaben, und das Modell sitzt dort, wo die jeweilige Aufgabe am besten erledigt wird.

Zuhören ist auf Datenschutz und Unmittelbarkeit optimiert. Die Eingabe ist die eigene Stimme der Besucher; das Ergebnis ist ein Entwurf, den sie vor dem Senden lesen. Ein kleines Modell, das lokal läuft, sichtbare Fehler macht und pro Nutzung nichts kostet, ist der richtige Kompromiss.

Sprechen ist auf Qualität und Sprache optimiert. Die Eingabe ist Text, den die Besucher ohnehin sehen; das Ergebnis muss auf Englisch und Deutsch natürlich klingen. Ich habe drei gehostete Stimmmodelle in beiden Sprachen gemessen (144 Syntheseläufe, keine Fehler) und jedes danach bewertet, wie gut eine separate Spracherkennung die Wörter zurückgewinnen konnte:

  • Deepgram Aura-2 hatte das schnellste erste Audio (Median 316 ms), aber das schwächste Deutsch (Wortfehlerrate 0,093).
  • Microsoft MAI-Voice-2 war am genauesten, brauchte aber über eine Sekunde bis zum ersten Audio (1.052 ms).
  • Grok Voice war das einzige Modell, dessen Deutsch so verständlich war wie sein Englisch (0,043 gegenüber 0,047), mit einem ersten Byte nach rund 450 ms, durchgehendem Streaming, einer wiedererkennbaren Stimme in beiden Sprachen und der Hälfte der Kosten von Aura-2 pro Antwort.

Ein menschlicher Hördurchgang hat es danach bestätigt. Ein kleines offenes Modell war um eine Größenordnung günstiger, sprach aber nur Englisch. Synthese auf dem Gerät wurde nicht als Produktionsoption evaluiert. Bei rund 0,007 $ pro gesprochener Antwort war Qualität mehr wert als die Kosten ganz zu vermeiden.

Umgang mit Sprache

Die Sprache fließt in beiden Richtungen bewusst unterschiedlich:

  • Die Transkription bekommt die Sprache der Seite mitgeteilt. Die eigene Spracherkennung von Whisper hat kurze deutsche Fragen schwer missverstanden: Mit automatischer Erkennung blieb die Absicht in 9,5 % der deutschen Testäußerungen erhalten, mit vorgegebener Sprache in 95,2 %. Deshalb entscheidet die Sprache der Seite (Englisch oder Deutsch), wie das Modell zuhört; einen zweiten Detektor gibt es nicht.
  • Die Sprache der Antwort wird deterministisch aus dem Fragetext erkannt, genau wie bei getippten Fragen, und folgt ihm.
  • Die Vorlesesprache ist diese erkannte Sprache, zusammen mit der Antwort in die signierte Freigabe eingebunden. Der Server wählt aus der Konfiguration eine Stimme pro Sprache; derzeit nutzen beide Sprachen „eve“, die beide spricht. Der Anbieter erhält keinen Sprachparameter; die Stimme beherrscht beide.
  • Alles andere wird abgelehnt: Das System unterstützt genau Englisch und Deutsch, durchgehend.

Datenschutzgrenzen

Vier Arten von Daten durchlaufen dieses System, und jede hat ihre eigene Grenze:

  • Rohes Mikrofonaudio bleibt im Browser der Besucher. Es existiert im Speicher zwischen Audioprozessor und Worker und wird nach der Transkription verworfen. Keine Route auf meinem Server nimmt aufgenommenes Audio an.
  • Das Transkript bleibt auf dem Gerät, bis die Besucher es absenden. Danach ist es eine gewöhnliche getippte Frage.
  • Die Antwort des Assistenten entsteht auf meinem Server und wird angezeigt. Soll sie gehört werden, geht ihr Text über meinen Server an den Stimmanbieter.
  • Erzeugtes Audio wird an den Browser zurückgestreamt und abgespielt. Es wird nicht gespeichert.

Die ehrliche Aussage ist also eng: Zuhören ist lokal; Sprechen nutzt ein gehostetes Stimmmodell für den Antworttext. Die Stimme der Besucher verlässt nie ihr Gerät. Die Worte des Assistenten schon – wenn die Besucher sie hören möchten.

Latenz

Ein gesprochener Austausch ist eine Pipeline, und seine Verzögerung ist die Summe sehr unterschiedlicher Stufen:

  • Abschluss der Aufnahme (lokal): Die Aufnahme endet; das Audio geht an den Worker. Das Zuhören zu starten dauert warm 42–66 ms und bei der ersten Nutzung etwa eine halbe Sekunde – das sind Berechtigung und Audio-Einrichtung, nicht das Modell.
  • Transkription (lokal, Modell): warm etwa 0,6 s mit WebGPU und 1,2–1,4 s mit WebAssembly für eine kurze Frage.
  • Die Prüfung durch die Besucher (Mensch): bewusst nicht automatisiert.
  • Generierung durch den Assistenten (Netzwerk und Modell): gestreamt; beschrieben in der Fallstudie zum Fotografie-Assistenten.
  • Sprachsynthese (Netzwerk und Modell): im Median rund 450 ms bis zum ersten Audio-Byte beim Anbieter; etwa 0,5–0,7 s über meine Route im Browser.
  • Start der Wiedergabe (Browser): Rund 0,35 s Audio werden gepuffert, bevor der Ton beginnt, damit die Stimme nicht stockt.

Diese Werte stammen aus getrennten, datierten Messungen einzelner Stufen. Eine durchgehende Latenzmessung für Sprache gibt es nicht. Der Client hat keine Telemetrie, und der Server misst nur den Syntheseaufruf. Das ist eine benannte Lücke, keine verborgene.

Fehlerisolation

Sprache kann an mehr Stellen scheitern als Text, deshalb bleibt jeder Sprachfehler ein Sprachfehler:

  • Mikrofon verweigert: Der Button erklärt es, Tippen bleibt möglich; das Modell wird nie geladen.
  • Nicht unterstützter Browser oder Smartphone: Der Mikrofon-Button erscheint nicht.
  • Fehler beim Laden des Modells, bei der Transkription oder Stille: eine kurze Statusmeldung; das Textfeld bleibt unberührt.
  • Falsches Transkript: im Entwurf sichtbar und vor dem Senden korrigierbar.
  • Stimme auf dem Server nicht konfiguriert: Es erscheint gar kein Anhören-Element.
  • Fehler bei Synthese oder Netzwerk: Das Bedienelement zeigt, dass die Stimme nicht verfügbar ist. Die geschriebene Antwort, bereits sichtbar, bleibt unberührt.
  • Audio vom Browser blockiert: Die Stimme wird gar nicht erst angefordert (es entstehen also keine Kosten), und ein Hinweis bittet darum, auf Anhören zu tippen.
  • Neue Frage, geschlossenes Panel, Unmount: Das Vorlesen endet, und seine Anfragen werden abgebrochen.

Der Assistent scheitert nie an der Sprache, und die Sprache ändert nie, was der Assistent gesagt hat.

Grenzen der Browser

  • Spracheingabe wird in Desktop-Browsern angeboten, die die oben genannten APIs bereitstellen. WebGPU wird genutzt, wo es funktioniert, sonst WebAssembly. Meine Messungen liefen in Chromium; echte Läufe der Transkription in Safari und Firefox sind nicht dokumentiert, und Smartphones sind bewusst ausgeschlossen.
  • Gesprochene Antworten funktionieren in Chrome, Firefox und Safari – nach einem browserübergreifenden Fehler, den ich unten beschreibe. Browser verlangen eine Nutzergeste, bevor Audio spielen darf. Jeder Antwort geht ein Klick oder Tastendruck voraus; in der Praxis betrifft das daher nur den Auto-Modus, in dem ein blockierter Start einen Hinweis zeigt, statt stumm zu scheitern.

Was gescheitert ist

Gesprochene Antworten waren in Firefox und Safari stumm. Problem: Der Player prüfte direkt nach dem Startbefehl, ob die Audio-Engine lief. Experiment: dieselbe Produktionsseite in Chromium, Firefox und WebKit, jeweils mit echtem Klick. Ergebnis: Chromium meldete sofort „running“. Firefox und WebKit melden „suspended“, bis die Engine tatsächlich startet, 3–88 ms später – also schaltete der Player das Audio ab und forderte nie Sprache an. Autoplay-Regeln und das Audioformat wurden beide ausgeschlossen. Konsequenz: eine begrenzte Wartezeit von bis zu 500 ms – mehr als das Fünffache des langsamsten gemessenen Starts –, bevor Audio als blockiert gilt.

Die Kamera des Kurators auf seine Stimme reagieren lassen. Problem: Das Kamerasymbol des Kurators sollte sichtbar reagieren, während er spricht. Experiment: ein Audio-Analyser im Wiedergabepfad, eine Sprachenergie-Hüllkurve und ein davon gesteuerter Shader-Parameter, alles ohne React-State pro Frame (rund 0,4 µs pro Abtastung). Ergebnis: Der Shader-Parameter steuerte nicht die sichtbare Silhouette. Mit jedem relevanten Parameter am Anschlag bewegte sich der Umriss nur um 5,2 % statt der nötigen 20–40 %. Die Spektralanalyse zeigte außerdem, dass 95 % der Sprachenergie unter 390 Hz liegen, sodass die Frequenzbänder neu gesetzt werden mussten. Konsequenz: Die Shader-Änderung wurde zurückgenommen. Ausgeliefert wurde etwas Einfacheres: eine weiche „Membran“ aus verschwommenen Formen neben dem Symbol, deren Größe acht Sprachfrequenzbändern folgt. Eine Animationsschleife schreibt CSS-Variablen auf ein einziges Element, nur während die Stimme spricht. Eine menschliche Prüfung hat sie auf Anhieb akzeptiert. Bei reduzierter Bewegung wird sie gar nicht dargestellt.

WebGPU: vier Anläufe. Problem: WebGPU versprach schnellere Transkription. Ergebnis: Die erste Konfiguration lieferte Unsinn und war 15,6-mal langsamer. Zwei weitere Anläufe scheiterten an der Qualität. Der vierte wurde ausgeliefert, mit WebGPU zuerst und einem nachgewiesenen Rückfall auf WebAssembly: warm 569 ms gegenüber 1.248 ms. Konsequenz: WebGPU ist eine Beschleunigung, nie eine Voraussetzung; scheitert WebGPU, gilt es für den Rest der Sitzung als unzuverlässig, und die Transkription läuft mit WebAssembly weiter.

Ausdrucksstarke Sprach-Tags. Experiment: explizite Pausen-Tags, um den Antworten einen natürlicheren Rhythmus zu geben. Ergebnis: Die Stimme pausierte an Satzgrenzen bereits rund 0,6 s; die Tags verlängerten das auf über eine Sekunde, was langsamer klang, nicht besser. Konsequenz: abgelehnt, ohne Änderung in Produktion.

Lecks im Lebenszyklus des Mikrofons. Eine Prüfung fand vier Wege, auf denen das Mikrofon offen bleiben konnte, nachdem das Gespräch weitergegangen war: Ein verborgenes Panel ließ seine Aufnahme weiterlaufen; eine zweite Ansicht konnte daneben eine zweite Aufnahme starten; eine Berechtigung, die erst nach dem Verschwinden der Komponente eintraf, veröffentlichte einen Stream, den niemand mehr las; und ein Fehler ließ das Mikrofon hinter der Fehlermeldung an. Ein separater Wettlauf konnte „Hört zu“ anzeigen, bevor die Aufnahme verbunden war. Alle wurden behoben und im Browser geprüft. Das Mikrofon wird jetzt freigegeben, sobald die Sitzung das Zuhören verlässt, und eine verspätete Berechtigung gibt sich selbst frei, wenn die Komponente nicht mehr existiert.

Abwägungen

  • Modell auf dem Gerät gegen Download- und Laufzeitkosten. Datenschutz und keine Kosten pro Nutzung, bezahlt mit 66 MB beim ersten Download, einem Kaltstart von mehreren Sekunden und der Genauigkeit eines kleinen Modells.
  • Gehostete Stimme gegen Netzwerkabhängigkeit. Natürliche deutsche und englische Sprache, bezahlt mit einer Anbieterabhängigkeit, rund 7 $ pro tausend gesprochene Antworten und einem Netzwerk-Umlauf vor dem ersten Ton.
  • Qualität gegen Zeit bis zum ersten Audio. Grok hatte nicht das schnellste erste Byte; das hatte Aura-2. Die deutsche Verständlichkeit gab den Ausschlag.
  • Sprach-UX gegen Browser-Komplexität. Audio-Freischaltung, WebGPU-Zustand, Worker-Lebenszyklen und Mikrofonfreigabe sind Code, den es nur wegen der Sprache gibt.
  • Modalitätsunabhängigkeit gegen Adapterzustand. Den Assistenten sprachblind zu halten, hat die Komplexität in zwei Adapter verlagert, jeder mit eigener Zustandsmaschine, eigenem Abbruch und eigenem Aufräumen. Sie werden getrennt getestet.
  • Kein automatischer Cloud-Rückfall. Ein Browser, der das Modell nicht ausführen kann, bekommt keine Spracheingabe. Das habe ich in Kauf genommen, statt Audio stillschweigend anderswohin zu schicken.

Ergebnis

Was die Architektur leistet und was ich zeigen kann:

  • Besucher können eine Frage auf Englisch oder Deutsch sprechen, ohne dass ihre Stimme ihr Gerät verlässt.
  • Sie können jede geprüfte Antwort in beiden Sprachen mit natürlicher Stimme hören, lesen oder beides.
  • Der Assistent, die Grenze seiner Belege und seine Validatoren bleiben von Sprache unberührt. Eine gesprochene und eine getippte Frage sind dieselbe Anfrage.
  • Jeder Sprachbaustein lässt sich ersetzen – das Transkriptionsmodell, die Stimme, der Anbieter –, ohne den Assistenten zu berühren.
  • Wenn Sprache scheitert, scheitert sie allein.

Offen sind: eine durchgehende Latenzmessung, Tests auf echten Geräten jenseits von Chromium für die Transkription und Spracheingabe auf Smartphones.

Weiterlesen

Die Fallstudie zum Fotografie-Assistenten beschreibt den belegbasierten Assistenten, den beide Sprachadapter umschließen. Auf der Seite Fotografie lassen sich der Kurator und seine Stimme ausprobieren.