Une interface utilisateur en langage naturel n'est qu'une interface utilisateur

Quelques mots sur ce battage médiatique…

Disons que vous écrivez une application et que vous souhaitez lui donner une interface conversationnelle: vos utilisateurs taperont une commande et votre application fera quelque chose en réponse, éventuellement après avoir demandé des éclaircissements.

Il y a beaucoup de termes associés à cette technologie - commerce conversationnel, bots, agents d'intelligence artificielle, etc. Je pense qu'il est beaucoup plus clair de l'appeler une interface utilisateur linguistique (LUI), par analogie avec l'interface utilisateur graphique (GUI) à laquelle vous pourriez vous attacher. la même application.

Imaginer votre application avec une interface graphique est un bon antidote à une réflexion potentiellement laineuse sur les «agents de l'IA». Vous devez toujours connecter l'interface utilisateur à l'application sous-jacente, et le modèle conceptuel de votre application sous-jacente continuera de jouer un rôle dominant dans l'expérience utilisateur globale.

Le texte de votre utilisateur est comme un clic

Disons que vous avez une application simple, capable d'exécuter quatre fonctions:

  • check_weather (): affiche la météo actuelle et les prévisions de demain.
  • check_calendar (): affiche les rendez-vous d'aujourd'hui.
  • call_mom (): Appelez votre mère.
  • tell_joke (): Raconte une blague ringarde.

Imaginez écrire une interface graphique pour cette application à partir de zéro. L'utilisateur déplace le curseur et clique. À chaque clic, vous obtenez une paire de chiffres, représentant la position du curseur. Ainsi, chaque action utilisateur vous donne un vecteur de deux valeurs réelles. Votre application connaît les limites de ses quatre boutons. Pour chaque vecteur, vous vérifiez si le point se situe dans les limites de l'un de vos boutons. Si c'est le cas, vous déclenchez l'animation par pression sur un bouton et exécutez la fonction appropriée.

Pour écrire un LUI à partir de zéro, nous devons prendre le texte de l'utilisateur et le résoudre en un vecteur de nombres. Nous devons déterminer «où» l'utilisateur a «cliqué». En règle générale, nous mappons chaque mot sur un ID arbitraire. Ensuite, si nous reconnaissons un vocabulaire de 5 000 mots, nous pouvons considérer chaque mot comme un point distinct dans un espace de 5 000 dimensions. Ensuite, nous réduisons cet espace à un espace plus dense de, disons, 300 dimensions. Cela nous amène à une grande partie de la résolution du texte en un vecteur de sens gérable.

Pour illustrer cela, reconnaissons un vocabulaire de quelques mots et attribuons une valeur réelle à chaque mot. Pour mapper le texte de l'utilisateur en deux dimensions, nous prendrons le premier mot que nous reconnaissons comme coordonnée x et le dernier mot que nous reconnaissons comme coordonnée y.

La fonction simple ci-dessus nous permet de représenter la «signification» du texte de l'utilisateur comme une paire de deux valeurs réelles:

  • get_coords («vérifier la météo») → (0,3, 0,3)
  • get_coords («afficher mon calendrier») → (0,1, 0,7)
  • get_coords («dites quelque chose de drôle») → (0,1, 0,1)
  • get_coords («appeler maman») → (0.9, 0.9)

Nous pouvons compléter l'analogie entre le LUI et le GUI en traçant ces valeurs et en proposant des limites pour nos «boutons» - les actions de notre application.

Avec une interface graphique, il n'y a aucun problème à déterminer les coordonnées du clic, et vous n'avez jamais à penser à résoudre l'événement de clic sur un bouton particulier, le cas échéant. Ce truc arrive juste - il est pris en charge pour vous. Avec un LUI, vous devez faire attention à ces détails. Vous pouvez faire un travail meilleur ou pire dans ce domaine, mais le «standard d'or» - le Saint Graal de tous vos efforts d'apprentissage automatique - ne vous donnera que quelque chose que vous teniez pour acquis tout au long d'une interface graphique. Bien sûr, vous disposez d'un canevas multidimensionnel beaucoup plus grand sur lequel l'utilisateur peut «cliquer», et chaque clic peut vous donner des données richement structurées. Mais vous devez toujours peindre des boutons, des formulaires, des menus de navigation, etc. sur cette toile. Vous connectez toujours une interface utilisateur à un ensemble de capacités sous-jacent fixe.

Considérez une boîte de dialogue comme celle-ci:

- Salut! Comment puis-je vous aider aujourd'hui? - Je recherche une assurance automobile. - Êtes-vous déjà titulaire d'un contrat? - Non c'est ma première voiture

Disons que sous le capot, l'énoncé final de l'utilisateur déclenche la fonction car_insurance.non_holder.tell (), qui imprime un mur de texte. Le LUI donne ici à l'utilisateur un menu hiérarchique, dont les options sont déterminées par le domaine sous-jacent. Dans la conception d'interface graphique, les problèmes posés par les menus imbriqués sont bien connus, et il est facile d'imaginer des problèmes analogues pour un LUI.

Si vous regardez en haut d'un menu imbriqué, comment savez-vous quelles sont les feuilles de l'arbre? Et si vous savez que vous avez besoin d'une feuille particulière, comment devinez-vous de manière fiable comment y accéder? Les invites LUI vous donnent plus de texte, de sorte que le contexte peut parfois être plus clair. D'un autre côté, la gamme d'options disponibles n'est pas toujours énumérée et votre intention peut être mal classée.

Mon point ici est qu'une interface utilisateur linguistique (LUI) n'est qu'une interface. Votre application a toujours besoin d'un modèle conceptuel et vous devez certainement communiquer ce modèle conceptuel à vos utilisateurs. Alors, demandez-vous: si cette application avait une interface graphique, à quoi ressemblerait cette interface graphique?

Une version GUI de Siri vous donnerait probablement un écran d'accueil avec des pages d'éléments de formulaire, une pour chacune des sous-applications de Siri. Il y aurait également une longue liste de boutons, pour déclencher les fonctions atomiques "d'oeuf impatient" de Siri. Notez que l'interface graphique de Siri ne serait pas simplement l'écran d'accueil d'iOS. Si cela était vrai, Siri mapperait votre énoncé à une séquence d'événements tactiles et d'entrées utilisateur.

Lorsque vous dites «dites à ma mère que je l'aime», Siri exécute la commande sms («ma mère», «je l'aime»). Il n'exécute certainement pas une séquence d'actions utilisateur, qui «pilote» votre iPhone comme vous le faites. Essayer de le faire serait fou. Siri est juste une application, avec son propre modèle conceptuel d'actions que vous voudrez probablement effectuer. Il vous expose ces actions via un LUI plutôt qu'une interface graphique.

Que n'avons-nous pas pu faire hier?

Je pense qu'il est important de comprendre exactement quelles opportunités la nouvelle technologie améliorée de l'IA ouvre. Un LUI est réalisable maintenant parce que vous pouvez vous attendre à pouvoir attraper le «clic» de l'utilisateur et le résoudre à l'action correcte avec une précision raisonnable. Vous pouvez désormais vous attendre à bien interpréter le texte de l'utilisateur. C'est nouveau et l'occasion est intéressante. Mais l'opportunité est également beaucoup plus restreinte que beaucoup de gens ne le pensent.

Je pense qu'un LUI peut être particulièrement agréable pour remplir des formulaires compliqués, où vous avez beaucoup d'arguments rarement utilisés. Cependant, plus je veux être précis, moins je suis impatient d'utiliser le langage naturel. Ma requête NL va être mappée dans une requête de base de données et la structure de la table que j'interroge est prédéterminée. Il peut être bon ou mauvais que la structure de la table me soit cachée.

L'avantage est que la structure de la table peut changer sans que je doive changer mon interaction avec l'interface utilisateur. L'inconvénient est qu'on me ment - on me force à interagir avec l'application sur une abstraction qui fuit. Probablement si je veux trouver un café à proximité avec WiFi et options végétariennes ouvertes après 22 heures, je serais ravi d'utiliser une interface NL. Si je réserve un vol pour l'Australie, je préfère ouvrir mon ordinateur portable et remplir un formulaire Web.

À moins que vous ne compiliez les instructions de l'utilisateur en code et que vous l'évaluiez (ce que je ne conseillerais pas!), Un LUI n'introduit aucune expressivité supplémentaire. Les interfaces utilisateur linguistiques et les interfaces utilisateur graphiques sont toutes les deux… des interfaces utilisateur.

L'interface linguistique pourrait être meilleure, ou elle pourrait être pire. Cela se résume à la conception, et votre succès sera intimement lié à l'application que vous essayez de créer. Le problème est que nous avons beaucoup moins d'expérience dans la conception de LUI, et les utilisateurs ont beaucoup moins d'expérience dans leur utilisation.

Ma prédiction est qu'il y aura un fort avantage de second moteur pour les personnes qui créent des applications avec des interfaces utilisateur linguistiques. Les leçons sur la conception de l'interface utilisateur devront être réapprises et une culture d'hypothèses d'utilisation devra se développer. En attendant, je m'attends à ce que les LUI conviennent le mieux aux applications relativement modestes qui sont enthousiasmées par la réduction des coûts et le ferroutage sur les plates-formes populaires.

En d'autres termes, je pense que les LUI conviennent mieux aux petites équipes et aux petites entreprises qui font de petits investissements. Si vous avez un gros plan audacieux et que votre ambition consiste à donner à votre application une «interface utilisateur unique», vous devez faire attention à ce que vous souhaitez. C'est comme espérer vivre à une époque intéressante.

À propos de moi

Je suis linguiste en informatique de Sydney et de Berlin. Je suis le développeur des outils spaCy NLP et co-fondateur d'Explosion AI. Si vous travaillez sur l'IA ou le ML, vous devriez consulter notre outil d'annotation propulsé par l'apprentissage actif Prodigy.

Courriel: matt@explosion.ai Twitter: @honnibal