Un orbe vocal qui contrôle réellement le site : l’architecture d’un assistant, pas une « FAQ parlante »
En bref sur l'essentiel (BLUF)
Un widget parlant sur un site internet n'est pas un assistant, mais un jouet : il parle mais ne fait rien. Notre orbe vocal gère vraiment le site. À l’intérieur se trouvent trois couches d’architecture, trois râteaux sur lesquels nous avons marché, l’économie du dialogue et une manière de mettre le même orbe sur votre site Web.
Les assistants vocaux sur les sites Web finissent généralement de deux manières : soit il s’agit d’un chatbot avec reconnaissance vocale attachée, soit il s’agit d’une voix off de FAQ. Nous sommes dans NeuralSpace est passé de la tâche inverse - faire une voix le principal moyen de gérer l'interface, et non une superstructure sur le texte. Vous trouverez ci-dessous une analyse de l’architecture et des décisions qui ont dû être prises.
Tâche
L'utilisateur ouvre une page de génération complexe - vidéo, des photos, musique — où il y a un choix de modèle, chargement d'une référence, d'une requête, de paramètres. Le nouveau venu est perdu. Les gens clôturent l'intégration classique (visite avec des flèches) à la deuxième étape. Nous voulions qu'il soit possible de simplement dire d'une voix: "Je veux donner vie à cette photo", et l'assistant lui-même a mis en évidence le bouton souhaité, l'a expliqué et l'a amené au résultat.
Différence clé avec un chatbot : orbe voit l'état de la page Et agit sur elle, plutôt que de répondre par le texte « appuyez sur le bouton X quelque part là-bas ».
Architecture : trois niveaux
- Voie vocale. Reconnaissance vocale en streaming → modèle → synthèse de réponses. L'exigence est une faible latence et la capacité interrompre (intervention) : l'utilisateur commence à parler - l'assistant se tait. Sans cela, le dialogue ressemble plus à un talkie-walkie qu’à une conversation.
- Cerveau. Nous avons délibérément découplé la « personnalité » de l'assistant d'un modèle de langage spécifique : le modèle est configuré côté serveur, il peut donc être modifié en fonction de la tâche et du coût sans re-développer le front-end. L'assistant reçoit non seulement la réponse de l'utilisateur, mais également instantané lisible par machine de la page actuelle: quels éléments y a-t-il, quels boutons, ce qui est déjà sélectionné.
- Exécuteur sur le client. Le modèle renvoie non seulement du texte, mais aussi actes : mettre en surbrillance l'élément, faire défiler jusqu'à bloquer, expliquer le champ. Le client les exécute au-dessus du vrai DOM.
Trois râteaux sur lesquels nous avons marché
Le plus intéressant n’est pas le chemin heureux, mais les échecs. Nous avons analysé les journaux de dialogues réels et avons trouvé les règles fondamentales.
1. Hallucination des possibilités. L'assistant a suggéré des modèles qui n'étaient pas sur la page actuelle, ou a confondu le modèle pour les photos avec le modèle pour la vidéo. L’utilisateur est à juste titre en colère : « un tel modèle n’existe pas ». Correction : ne vous fiez pas à la « connaissance du monde » du modèle : l'assistant peut nommer et changer de modèle. seulement ce qui se trouve réellement dans l'instantané de la page actuelle. Il s'agit d'un problème de base classique - le modèle doit être strictement lié à l'état de l'interface, sinon il mentira en toute confiance.
2. Le mauvais bouton est allumé. Ils vous demandent d'afficher « télécharger une photo » - « Générer » est en surbrillance. La raison en est le mappage flou « intention → élément ». Solution : les éléments reçoivent des ancres sémantiques, et l'assistant doit mettre en évidence exactement celui-là, dont il parle, et non voisin en sens.
3. Obsessivité. Le modèle a déjà été sélectionné - l'assistant essaie toujours de le modifier ; l'utilisateur demande « écrivez simplement une demande » - et il argumente. Règle : si l'état est déjà adapté ou que l'utilisateur demande explicitement de ne pas toucher - ne pas agir ni discuter, faites immédiatement ce qui est demandé. Moins d'initiative, plus d'exécution.
La conclusion que nous donnerions à quiconque construit un agent au-dessus d’une interface est la suivante : 90 % de la qualité n'est pas un modèle, mais un fondement et une discipline d'action. Le modèle doit voir l'état exact et n'est pas autorisé à le dépasser.
Économie du dialogue
La voix coûte plus cher que le texte, donc Orb a une fenêtre gratuite, puis le paiement s'effectue lors de la conversation. La facturation est liée à la durée de l’interaction vocale et non au nombre de « messages ».
Le même orbe est sur votre site Web
Nous avons personnalisé l'orbe pour nous-mêmes, mais la tâche est universelle : tout site doté d'une interface non triviale (configurateur, compte personnel, formulaire complexe, boutique avec filtres) bénéficie d'un guide vocal qui voit la page et agit sur elle. Par conséquent, nous l'avons placé dans un widget intégré - la manière dont il est installé et ce qu'il peut faire est discuté séparément : agent vocal pour n'importe quel site Web.
Si vous faites quelque chose de similaire, il est intéressant de comparer les approches d’échouement et d’intervention. Vous pouvez essayer Orb en direct sur neuralspace.pro.
Questions fréquemment posées (FAQ)
Question : Comment obtenir le meilleur résultat d’un réseau de neurones ?
Réponse : Utilisez des invites détaillées (descriptions) en anglais, définissez le style et les détails de la scène.
Question : Ces matériaux peuvent-ils être utilisés à des fins commerciales ?
Réponse : Oui, le contenu généré vous appartient entièrement.