← Alla artiklar

En röstkula som faktiskt styr webbplatsen: arkitekturen för en assistent, inte en "talande FAQ"

En röstkula som faktiskt styr webbplatsen: arkitekturen för en assistent, inte en "talande FAQ"

Kort om det viktigaste (BLUF)

En talande widget på en webbplats är inte en assistent, utan en leksak: den pratar men gör ingenting. Vår röstkula driver verkligen sajten. Inuti finns tre lager av arkitektur, tre rakes som vi trampade på, ekonomin med dialog och ett sätt att sätta samma orb på din webbplats.

Röstassistenter på webbplatser hamnar vanligtvis på ett av två sätt: antingen är det en chatbot med taligenkänning bifogad, eller så är det en FAQ-voiceover. Vi är med NeuralSpace gick från den omvända uppgiften - att göra en röst det huvudsakliga sättet att hantera gränssnittet, och inte en överbyggnad över texten. Nedan följer en analys av arkitekturen och beslut som måste fattas.

Uppgift

Användaren öppnar en komplex genereringssida − video, bilder, musik — där det finns ett val av modell, laddning av en referens, en begäran, parametrar. Nykomlingen är förlorad. Människor stänger den klassiska onboarding (tur med pilar) vid det andra steget. Vi ville att det skulle vara möjligt att helt enkelt säga med en röst: "Jag vill väcka det här fotot till liv," och assistenten själv markerade den önskade knappen, förklarade den och förde den till resultatet.

Nyckelskillnad från en chatbot: orb ser sidans tillstånd Och agerar på henne, istället för att svara med texten "tryck på X-knappen någonstans där."

Arkitektur: tre lager

Tre lager: röstkanal, hjärna med maskinläsbar sidbild, exekutor ovanpå DOM
Tre lager: röstkanal, hjärna med maskinläsbar sidbild, exekutor ovanpå DOM
  1. Röstkanal. Strömmande taligenkänning → modell → svarssyntes. Kravet är låg latens och förmågan avbryta (pråm-in): användaren börjar prata - assistenten tystnar. Utan detta känns dialogen som en walkie-talkie snarare än ett samtal.
  2. Hjärna. Vi frikopplade medvetet assistentens "personlighet" från en specifik språkmodell: modellen är konfigurerad på serversidan, så att den kan ändras för att passa uppgiften och kostnaden utan att utveckla fronten på nytt. Assistenten får inte bara användarens svar utan också maskinläsbar ögonblicksbild av den aktuella sidan: vilka element finns där, vilka knappar, vad är redan valt.
  3. Exekutor på klienten. Modellen returnerar inte bara text, utan också åtgärder: markera element, scrolla till block, förklara fält. Klienten kör dem ovanpå den riktiga DOM.

Tre krattor trampade vi på

Det mest intressanta är inte den lyckliga vägen, utan misslyckandena. Vi analyserade loggarna av riktiga dialoger och kom fram till grundreglerna.

1. Hallucination av möjligheter. Assistenten föreslog modeller som inte fanns på den aktuella sidan, eller blandade ihop modellen för bilder med modellen för video. Användaren är med rätta arg: "det finns ingen sådan modell." Fix - lita inte på modellens "kunskap om världen": assistenten kan namnge och byta bara det som faktiskt finns i ögonblicksbilden av den aktuella sidan. Detta är ett klassiskt jordningsproblem - modellen måste vara strikt knuten till gränssnittets tillstånd, annars kommer den med säkerhet att ljuga.

2. Fel knapp lyser. De ber dig visa "ladda upp ett foto" - "Generera" är markerat. Anledningen är den otydliga kartläggningen av "avsikt → element". Lösning: element får semantiska ankare och assistenten måste markera precis den, som han talar om, och inte närliggande till betydelsen.

3. Besatthet. Modellen har redan valts - assistenten försöker fortfarande ändra den; användaren frågar "skriv bara en förfrågan" - och han argumenterar. Regel: om tillståndet redan är lämpligt eller om användaren uttryckligen ber att inte röra - inte agera eller argumentera, gör omedelbart vad som efterfrågas. Mindre initiativ, mer utförande.

Slutsatsen vi skulle ge alla som bygger en agent ovanpå ett gränssnitt är: 90% av kvaliteten är inte en modell, utan grund och handlingsdisciplin. Modellen måste se det exakta tillståndet och får inte gå utöver det.

Dialogens ekonomi

Röst är dyrare än text, så Orb har ett ledigt fönster, sedan betalas betalning vid samtal. Faktureringen är bunden till röstinteraktionens varaktighet, inte antalet "meddelanden".

Samma orb finns på din webbplats

Vi anpassade klotet för oss själva, men uppgiften är universell: alla webbplatser med ett icke-trivialt gränssnitt (konfigurator, personligt konto, komplex form, butik med filter) drar nytta av en röstguide som ser sidan och agerar på den. Därför lägger vi in ​​den i en inbäddad widget - hur den är installerad och vad den kan göra diskuteras separat: röstagent för vilken webbplats som helst.

Om du gör något liknande är det intressant att jämföra tillvägagångssätten för grundstötning och inhopp. Du kan prova orb live på neuralspace.pro.

Tre lager: röstpipeline, hjärna med en maskinläsbar sidbild, klientexekutor över DOM
Tre lager: röstpipeline, hjärna med en maskinläsbar sidbild, klientexekutor över DOM

Vanliga frågor (FAQ)

Fråga: Hur får man det bästa resultatet från ett neuralt nätverk?
Svar: Använd detaljerade uppmaningar (beskrivningar) på engelska, ställ in stilen och detaljerna för scenen.

Fråga: Kan dessa material användas för kommersiella ändamål?
Svar: Ja, det genererade innehållet är helt och hållet ditt.