← Alle Artikel

Eine Sprachkugel, die tatsächlich die Site steuert: die Architektur eines Assistenten, keine „sprechende FAQ“

Eine Sprachkugel, die tatsächlich die Site steuert: die Architektur eines Assistenten, keine „sprechende FAQ“

Kurz zur Hauptsache (BLUF)

Ein sprechendes Widget auf einer Website ist kein Assistent, sondern ein Spielzeug: Es spricht, tut aber nichts. Unsere Sprachkugel steuert die Seite wirklich. Im Inneren befinden sich drei Ebenen der Architektur, drei Rechen, auf die wir getreten sind, die Ökonomie des Dialogs und eine Möglichkeit, dieselbe Kugel auf Ihrer Website zu platzieren.

Sprachassistenten auf Websites enden normalerweise auf zwei Arten: entweder als Chatbot mit angehängter Spracherkennung oder als FAQ-Voiceover. Wir sind dabei NeuralSpace ging von der umgekehrten Aufgabe aus – eine Stimme zu machen die wichtigste Möglichkeit, die Schnittstelle zu verwaltenund kein Überbau über dem Text. Nachfolgend finden Sie eine Analyse der Architektur und der zu treffenden Entscheidungen.

Aufgabe

Der Benutzer öffnet eine komplexe Generierungsseite − Video, Bilder, Musik — wo die Wahl zwischen Modell, Laden einer Referenz, einer Anfrage und Parametern besteht. Der Neuankömmling ist verloren. Den Abschluss des klassischen Onboardings (Rundgang mit Pfeilen) bildet der zweite Schritt. Wir wollten, dass es einfach möglich ist mit einer Stimme sagen: „Ich möchte dieses Foto zum Leben erwecken“, und der Assistent selbst markierte den gewünschten Button, erklärte ihn und brachte ihn zum Ergebnis.

Hauptunterschied zu einem Chatbot: Orb sieht den Seitenstatus Und wirkt auf sie, anstatt mit dem Text „Drücken Sie irgendwo dort die X-Taste“ zu antworten.

Architektur: drei Schichten

Drei Schichten: Stimmtrakt, Gehirn mit maschinenlesbarem Seitenschnappschuss, Executor oben auf DOM
Drei Schichten: Stimmtrakt, Gehirn mit maschinenlesbarem Seitenschnappschuss, Executor oben auf DOM
  1. Stimmtrakt. Streaming-Spracherkennung → Modell → Antwortsynthese. Voraussetzung ist eine geringe Latenz und die Fähigkeit unterbrechen (Barge-In): Der Benutzer beginnt zu sprechen – der Assistent verstummt. Ohne dies fühlt sich der Dialog eher wie ein Walkie-Talkie als wie ein Gespräch an.
  2. Gehirn. Wir haben die „Persönlichkeit“ des Assistenten bewusst von einem bestimmten Sprachmodell entkoppelt: Das Modell wird serverseitig konfiguriert, sodass es je nach Aufgabe und Kosten geändert werden kann, ohne das Frontend neu zu entwickeln. Der Assistent erhält nicht nur die Antwort des Benutzers, sondern auch maschinenlesbarer Schnappschuss der aktuellen Seite: Welche Elemente gibt es, welche Schaltflächen, was ist bereits ausgewählt.
  3. Testamentsvollstrecker auf dem Client. Das Modell gibt nicht nur Text zurück, sondern auch Aktionen: Element markieren, zum Block scrollen, Feld erklären. Der Client führt sie auf dem echten DOM aus.

Drei Rechen, auf die wir getreten sind

Das Interessanteste ist nicht der glückliche Weg, sondern die Misserfolge. Wir haben die Protokolle echter Dialoge analysiert und die Grundregeln entwickelt.

1. Halluzination von Möglichkeiten. Der Assistent schlug Modelle vor, die nicht auf der aktuellen Seite waren, oder verwechselte das Modell für Bilder mit dem Modell für Videos. Der Nutzer ist zu Recht verärgert: „So ein Modell gibt es nicht.“ Fix – Verlassen Sie sich nicht auf das „Wissen des Modells über die Welt“: Der Assistent kann benennen und wechseln nur das, was tatsächlich im Snapshot der aktuellen Seite enthalten ist. Dies ist ein klassisches Erdungsproblem – das Modell muss strikt an den Zustand der Schnittstelle gebunden sein, sonst lügt es sicher.

2. Die falsche Taste leuchtet. Sie werden aufgefordert, „Foto hochladen“ anzuzeigen – „Generieren“ ist hervorgehoben. Der Grund ist die unscharfe Zuordnung „Absicht → Element“. Lösung: Elemente erhalten semantische Anker und der Assistent muss sie hervorheben genau das, worüber er spricht, und in der Bedeutung nicht benachbart.

3. Besessenheit. Das Modell wurde bereits ausgewählt – der Assistent versucht noch, es zu ändern; Der Benutzer fragt: „Schreiben Sie einfach eine Anfrage“ – und er argumentiert. Regel: Wenn der Zustand bereits geeignet ist oder der Benutzer ausdrücklich darum bittet, nicht zu berühren - Handeln oder argumentieren Sie nicht, sofort tun, was verlangt wird. Weniger Initiative, mehr Umsetzung.

Die Schlussfolgerung, die wir jedem ziehen würden, der einen Agenten auf einer Schnittstelle aufbaut, ist: 90 % der Qualität ist kein Modell, sondern die Grundlage und Disziplin des Handelns. Das Modell muss den genauen Zustand erkennen und darf diesen nicht überschreiten.

Ökonomie des Dialogs

Sprache ist teurer als Text, daher hat Orb ein kostenloses Fenster, die Zahlung erfolgt dann beim Gespräch. Die Abrechnung richtet sich nach der Dauer der Sprachinteraktion und nicht nach der Anzahl der „Nachrichten“.

Die gleiche Kugel befindet sich auf Ihrer Website

Wir haben die Kugel für uns selbst angepasst, aber die Aufgabe ist universell: Jede Website mit einer nicht trivialen Benutzeroberfläche (Konfigurator, persönliches Konto, komplexes Formular, Shop mit Filtern) profitiert von einer Sprachführung, die die Seite sieht und darauf reagiert. Deshalb haben wir es in ein eingebettetes Widget eingefügt – wie es installiert wird und was es kann, wird separat besprochen: Sprachagent für jede Website.

Wenn Sie etwas Ähnliches tun, ist es interessant, die Ansätze für Grounding und Barge-In zu vergleichen. Sie können Orb live unter ausprobieren neuralspace.pro.

Drei Schichten: Sprachpipeline, Gehirn mit einem maschinenlesbaren Seiten-Snapshot, Client-Executor über das DOM
Drei Schichten: Sprachpipeline, Gehirn mit einem maschinenlesbaren Seiten-Snapshot, Client-Executor über das DOM

Häufig gestellte Fragen (FAQ)

Frage: Wie erzielt man mit einem neuronalen Netzwerk das beste Ergebnis?
Antwort: Verwenden Sie ausführliche Ansagen (Beschreibungen) auf Englisch, legen Sie den Stil und die Details der Szene fest.

Frage: Können diese Materialien kommerziell genutzt werden?
Antwort: Ja, der generierte Inhalt gehört vollständig Ihnen.