Een stembol die feitelijk de site bestuurt: de architectuur van een assistent, geen ‘sprekende FAQ’

Kort over het belangrijkste (BLUF)

Een pratende widget op een website is geen assistent, maar een speeltje: hij praat maar doet niets. Onze stemorb beheert echt de site. Binnenin zitten drie architectuurlagen, drie harken waarop we zijn gestapt, de economie van de dialoog en een manier om dezelfde bol op je website te plaatsen.

Stemassistenten op websites komen meestal op twee manieren terecht: het is een chatbot met daaraan gekoppelde spraakherkenning, of het is een voice-over met veelgestelde vragen. Wij zijn binnen NeuralSpace ging van de omgekeerde taak: een stem maken de belangrijkste manier om de interface te beheren, en niet een bovenbouw over de tekst. Hieronder vindt u een analyse van de architectuur en de beslissingen die moesten worden genomen.

Taak

De gebruiker opent een complexe generatiepagina − video, foto's, muziek — wanneer er een modelkeuze is, wordt een referentie, een verzoek, parameters geladen. De nieuwkomer is verloren. Bij de tweede stap sluiten mensen de klassieke onboarding (rondleiding met pijlen) af. Wij wilden dat het eenvoudig mogelijk zou zijn zeggen met een stem: “Ik wil deze foto tot leven brengen”, en de assistent markeerde zelf de gewenste knop, legde deze uit en bracht deze naar het resultaat.

Belangrijk verschil met een chatbot: orb ziet de paginastatus En handelt op haar, in plaats van te reageren met de tekst 'druk daar ergens op de X-knop'.

Architectuur: drie lagen

1. Vocaal kanaal. Streaming spraakherkenning → model → responssynthese. De vereiste is een lage latentie en de mogelijkheid onderbreken (barge-in): de gebruiker begint te praten - de assistent valt stil. Zonder dit voelt de dialoog eerder als een walkietalkie dan als een gesprek.
2. Brein. We hebben bewust de ‘persoonlijkheid’ van de assistent losgekoppeld van een specifiek taalmodel: het model wordt aan de serverzijde geconfigureerd, zodat het kan worden aangepast aan de taak en de kosten zonder dat de frontend opnieuw hoeft te worden ontwikkeld. De assistent ontvangt niet alleen het antwoord van de gebruiker, maar ook machineleesbare momentopname van de huidige pagina: welke elementen zijn er, welke knoppen, wat is er al geselecteerd.
3. Uitvoerder bij de opdrachtgever. Het model retourneert niet alleen tekst, maar ook acties: element markeren, naar blok scrollen, veld uitleggen. De klant voert ze uit bovenop de echte DOM.

Drie harken waar we op stapten

Het meest interessante is niet het gelukkige pad, maar de mislukkingen. We analyseerden de logboeken van echte dialogen en kwamen met de basisregels.

1. Hallucinatie van mogelijkheden. De assistent stelde modellen voor die niet op de huidige pagina stonden, of verwarde het model voor foto's met het model voor video. De gebruiker is terecht boos: “zo’n model bestaat niet.” Oplossing - vertrouw niet op de “kennis van de wereld” van het model: de assistent kan een naam geven en schakelen alleen wat zich daadwerkelijk in de momentopname van de huidige pagina bevindt. Dit is een klassiek aardingsprobleem: het model moet strikt gebonden zijn aan de toestand van de interface, anders zal het vol vertrouwen liegen.

2. De verkeerde knop is verlicht. Ze vragen je om 'een foto uploaden' weer te geven - 'Genereren' is gemarkeerd. De reden is de vage “intentie → element”-toewijzing. Oplossing: elementen krijgen semantische ankers en de assistent moet markeren precies die, waarover hij spreekt, en niet qua betekenis.

3. Obsessiviteit. Het model is al geselecteerd - de assistent probeert het nog steeds te wijzigen; de gebruiker vraagt ​​"schrijf gewoon een verzoek" - en hij betoogt. Regel: als de staat al geschikt is of de gebruiker expliciet vraagt ​​om niet aan te raken - handel niet en maak geen ruzie, doe onmiddellijk wat er gevraagd wordt. Minder initiatief, meer uitvoering.

De conclusie die we zouden geven aan iedereen die een agent bovenop een interface bouwt, is: 90% van de kwaliteit is geen model, maar een basis en discipline van handelen. Het model moet de exacte staat zien en mag niet verder gaan.

Economie van de dialoog

Spraak is duurder dan tekst, dus Orb heeft een vrij venster en de betaling wordt gedaan na een gesprek. Facturering is gekoppeld aan de duur van de spraakinteractie, niet aan het aantal ‘berichten’.

Dezelfde bol bevindt zich op uw website

We hebben de bol voor onszelf aangepast, maar de taak is universeel: elke site met een niet-triviale interface (configurator, persoonlijk account, complex formulier, winkel met filters) profiteert van een gesproken gids die de pagina ziet en ernaar handelt. Daarom plaatsen we het in een ingebedde widget - hoe het geïnstalleerd wordt en wat het kan doen wordt apart besproken: stemagent voor elke website.

Als u iets soortgelijks doet, is het interessant om de benaderingen van gronding en binnenvallen te vergelijken. Je kunt orb live proberen op neuralspace.pro.

Veelgestelde vragen (FAQ)

Vraag: Hoe haal je het beste resultaat uit een neuraal netwerk?
Antwoord: Gebruik gedetailleerde aanwijzingen (beschrijvingen) in het Engels, stel de stijl en details van de scène in.

Vraag: Kunnen deze materialen gebruikt worden voor commerciële doeleinden?
Antwoord: Ja, de gegenereerde inhoud is geheel van jou.