Una sfera vocale che controlla effettivamente il sito: l’architettura di un assistente, non di una “FAQ parlante”
Brevemente sulla cosa principale (BLUF)
Un widget parlante su un sito web non è un assistente, ma un giocattolo: parla ma non fa nulla. La nostra sfera vocale gestisce davvero il sito. All'interno ci sono tre strati di architettura, tre rastrelli su cui abbiamo calpestato, l'economia del dialogo e un modo per mettere la stessa sfera sul tuo sito web.
Gli assistenti vocali sui siti Web di solito finiscono in due modi: o è un chatbot con riconoscimento vocale allegato o è una voce fuori campo delle FAQ. Siamo dentro NeuralSpace è passato dal compito inverso: dare voce il modo principale per gestire l'interfacciae non una sovrastruttura sul testo. Di seguito è riportata un'analisi dell'architettura e delle decisioni che è stato necessario prendere.
Compito
L'utente apre una pagina di generazione complessa − video, immagini, musica — dove c'è la scelta del modello, il caricamento di un riferimento, una richiesta, parametri. Il nuovo arrivato è perduto. Al secondo passaggio si chiude l'onboarding classico (tour con le frecce). Volevamo che fosse possibile semplicemente dire con una voce: "Voglio dare vita a questa foto", e l'assistente stesso ha evidenziato il pulsante desiderato, lo ha spiegato e lo ha portato al risultato.
Differenza fondamentale rispetto a un chatbot: orb vede lo stato della pagina E agisce su di lei, invece di rispondere con il testo "premi il pulsante X da qualche parte lì".
Architettura: tre strati
- Tratto vocale. Streaming riconoscimento vocale → modello → sintesi della risposta. I requisiti sono la bassa latenza e la capacità interrompere (intervento): l'utente inizia a parlare, l'assistente tace. Senza questo, il dialogo sembra un walkie-talkie piuttosto che una conversazione.
- Cervello. Abbiamo deliberatamente disaccoppiato la “personalità” dell'assistente da un modello linguistico specifico: il modello è configurato lato server, quindi può essere modificato in base al compito e al costo senza dover ri-sviluppare il front-end. L'assistente riceve non solo la risposta dell'utente, ma anche istantanea leggibile dalla macchina della pagina corrente: quali elementi ci sono, quali pulsanti, cosa è già selezionato.
- Esecutore sul cliente. Il modello restituisce non solo testo, ma anche azioni: evidenzia l'elemento, scorri fino al blocco, spiega il campo. Il client li esegue sul DOM reale.
Tre rastrelli su cui abbiamo calpestato
La cosa più interessante non è il percorso felice, ma i fallimenti. Abbiamo analizzato i registri dei dialoghi reali e abbiamo creato le regole di base.
1. Allucinazione di possibilità. L'assistente ha suggerito modelli che non erano presenti nella pagina corrente oppure ha confuso il modello per le immagini con il modello per il video. L’utente è giustamente arrabbiato: “non esiste un modello del genere”. Correzione: non fare affidamento sulla "conoscenza del mondo" del modello: l'assistente può nominare e cambiare solo ciò che è effettivamente nell'istantanea della pagina corrente. Questo è un classico problema di messa a terra: il modello deve essere strettamente legato allo stato dell'interfaccia, altrimenti mentirà con sicurezza.
2. È illuminato il pulsante sbagliato. Ti chiedono di mostrare "carica una foto" - "Genera" è evidenziato. Il motivo è la mappatura confusa “intento → elemento”. Soluzione: gli elementi ricevono ancore semantiche e l'assistente deve evidenziarle esattamente quello, di cui parla, e non vicino nel significato.
3. Ossessività. Il modello è già stato selezionato: l'assistente tenta ancora di cambiarlo; l'utente chiede "basta scrivere una richiesta" - e lui discute. Regola: se lo stato è già idoneo o l'utente chiede esplicitamente di non toccare - non agire né discutere, fai immediatamente ciò che ti viene chiesto. Meno iniziativa, più esecuzione.
La conclusione che daremmo a chiunque costruisca un agente sopra un'interfaccia è: Il 90% della qualità non è un modello, ma fondamento e disciplina dell'azione. Il modello deve vedere lo stato esatto e non gli è consentito andare oltre.
Economia del dialogo
La voce è più costosa del testo, quindi Orb ha una finestra gratuita, quindi il pagamento viene effettuato al momento della conversazione. La fatturazione è legata alla durata dell’interazione vocale, non al numero di “messaggi”.
La stessa sfera è sul tuo sito web
Abbiamo personalizzato l'orb per noi, ma il compito è universale: qualsiasi sito con un'interfaccia non banale (configuratore, account personale, modulo complesso, archivio con filtri) beneficia di una guida vocale che vede la pagina e agisce su di essa. Pertanto, lo inseriamo in un widget incorporato: come viene installato e cosa può fare viene discusso separatamente: agente vocale per qualsiasi sito web.
Se stai facendo qualcosa di simile, è interessante confrontare gli approcci al grounding e al barge-in. Puoi provare Orb dal vivo su neuralspace.pro.
Domande frequenti (FAQ)
Domanda: Come ottenere il miglior risultato da una rete neurale?
Risposta: utilizzare istruzioni dettagliate (descrizioni) in inglese, impostare lo stile e i dettagli della scena.
Domanda: questi materiali possono essere utilizzati per scopi commerciali?
Risposta: Sì, il contenuto generato è interamente tuo.