Les interfaces de programmation d'applications (API) jouent un rôle de plus en plus important dans les mondes virtuel et physique grâce au développement de technologies telles que l'architecture orientée services, le cloud computing et l'Internet des objets (IoT). Aujourd'hui, nos collègues de la division Microsoft Research ont partagé leurs meilleures pratiques dans le domaine des interfaces en langage naturel (interfaces en langage naturel). Rejoignez-nous maintenant!
Les services Web basés sur le cloud dédiés à la météo, aux sports et à la finance via l'API Web fournissent des données et des services aux utilisateurs finaux, tandis que les appareils IoT permettent à d'autres appareils du réseau d'utiliser leurs fonctionnalités.
En règle générale, les API sont utilisées dans divers logiciels: applications de bureau, sites Web et applications mobiles. Ils servent également les utilisateurs via une interface utilisateur graphique (GUI). Les interfaces graphiques ont grandement contribué à la vulgarisation des ordinateurs, mais, avec le développement de la technologie informatique, leurs nombreuses limites deviennent plus évidentes. À mesure que les appareils deviennent plus petits, plus mobiles et plus intelligents, de plus en plus de demandes sont imposées à l'affichage graphique à l'écran, par exemple, avec des appareils portables ou des appareils connectés à l'IoT.
Les utilisateurs sont également obligés de s'habituer à une grande variété d'interfaces graphiques lors de l'utilisation de divers services et appareils. À mesure que le nombre de services et d'appareils disponibles augmente, le coût de la formation et de l'adaptation des utilisateurs augmente également. Les interfaces en langage naturel (NLI) présentent un potentiel important en tant qu'outil intelligent unique pour une large gamme de services et d'appareils côté serveur. Les NLI ont des capacités incroyables pour déterminer l'intention de l'utilisateur et reconnaître les informations contextuelles, ce qui rend les applications, telles que les assistants virtuels, beaucoup plus pratiques pour les utilisateurs.
Nous avons étudié les interfaces en langage naturel pour les API (NL2API). Contrairement aux NLI à usage général tels que les assistants virtuels, nous avons essayé de comprendre comment créer des NLI pour des API Web individuelles, telles que l'API du service de calendrier. À l'avenir, ces NL2API seront en mesure de démocratiser l'API, en aidant les utilisateurs à interagir avec les systèmes logiciels. Ils peuvent également résoudre le problème d'évolutivité des assistants virtuels à usage général en permettant le développement distribué. L'utilité d'un assistant virtuel dépend en grande partie de l'étendue de ses capacités, c'est-à-dire du nombre de services qu'il prend en charge.
Cependant, l'intégration de services Web dans un assistant virtuel un à la fois est un travail extrêmement laborieux. Si les fournisseurs de services Web individuels avaient un moyen facile de créer des NLI pour leurs API, les coûts d'intégration pourraient être considérablement réduits. Un assistant virtuel n'aurait pas à gérer différentes interfaces pour différents services Web. Il lui suffirait d'intégrer simplement des NL2API individuelles, qui atteignent l'uniformité grâce au langage naturel. NL2API peut également faciliter le développement de services Web, de systèmes de recommandation de programmation et d'aide pour l'API. Ainsi, vous n'avez pas à mémoriser le grand nombre d'API Web disponibles et leur syntaxe.
Figure 1. Façons de créer une interface en langage naturel pour l'API. À gauche: les méthodes traditionnelles apprennent aux modèles de perception du langage à reconnaître les intentions dans un langage naturel, d'autres modèles apprennent à extraire les cellules associées à chaque intention, puis à les associer manuellement aux demandes d'API. À droite: notre méthode peut traduire le langage naturel directement en requêtes API.La tâche principale de NL2API est de reconnaître les expressions dans le langage naturel de l'utilisateur et de les traduire en une demande d'API. Pour être plus précis, nous nous sommes concentrés sur les API Web créées à l'image de l'architecture REST, c'est-à-dire l'API RESTful. Les API RESTful sont largement utilisées dans les services Web, les appareils pour l'IoT, ainsi que dans les applications pour smartphones. Un exemple de l'API Microsoft Graph est illustré à la figure 1.
Le côté gauche de la figure montre la méthode traditionnelle de construction d'un langage naturel, dans laquelle nous enseignons aux modèles de perception du langage à reconnaître les intentions, et à d'autres modèles pour extraire les cellules associées à chacune des intentions, puis les associer manuellement aux demandes d'API en écrivant du code. Au lieu de cela (comme indiqué sur le côté droit de la figure), nous pouvons apprendre à traduire les expressions d'un langage naturel directement en demandes d'API. Dans le cadre de l'étude, nous utilisons notre système pour les API du package
API Microsoft Graph . Les API Web Microsoft Graph permettent aux développeurs d'accéder à des données améliorant la productivité: courrier, calendrier, contacts, documents, répertoires, appareils, etc.
Figure 2. Les API Web Microsoft Graph permettent aux développeurs d'accéder à des données qui offrent une productivité accrue: courrier, calendrier, contacts, documents, répertoires, appareils, etc.L'une des exigences du modèle que nous développons est la capacité de créer une interface utilisateur détaillée. La plupart des NLI existants font peu pour aider les utilisateurs si l'équipe n'était pas correctement reconnue. Nous suggérons qu'une expérience utilisateur plus détaillée puisse rendre NLI beaucoup plus pratique.
Nous avons développé un modèle modulaire qui fonctionne sur une base «de séquence en séquence» (voir Figure 3) pour fournir une interaction détaillée avec NLI. Pour ce faire, nous utilisons une architecture qui fonctionne sur un principe «de séquence en séquence», mais en même temps nous décomposons le résultat du décryptage en plusieurs unités interprétées, appelées modules.
Chaque module essaie de prédire un résultat prédéterminé, par exemple, en utilisant un paramètre spécifique basé sur une instruction reçue dans NL2API. Après une comparaison simple, les utilisateurs peuvent facilement comprendre le résultat prévisionnel de n'importe quel module et interagir avec le système à un niveau modulaire. Chaque module de notre modèle génère des résultats cohérents, pas un état continu.
Figure 3. Un modèle modulaire fonctionnant de séquence en séquence. Le contrôleur active plusieurs modules, chacun créant un paramètre.Modules: Nous définissons d'abord ce qu'est un module. Un module est un réseau neuronal spécialisé conçu pour effectuer une tâche spécifique de prédiction d'une séquence. Dans NL2API, différents modules correspondent à différents paramètres. Par exemple, dans l'API GET-Messages, les modules seront FILTER (expéditeur), FILTER (isRead), SELECT (pièces jointes), ORDERBY (receivedDateTime), SEARCH, etc. La tâche du module est de reconnaître l'instruction entrante et de créer un paramètre complet s'il est activé. Pour cela, le module doit déterminer les valeurs de son paramètre en fonction de l'instruction entrante.
Par exemple, si une déclaration entrante ressemble à des «lettres non lues sur une thèse de doctorat», le module SEARCH doit prédire que la valeur du paramètre SEARCH est «thèse de doctorat» et générer le paramètre «SEARCH doctoral dissertation» comme séquence de sortie. Par analogie, le module FILTER (isRead) doit se rappeler que des expressions telles que «courriels non lus», «courriels qui n'ont pas été lus» et «courriels non lus» indiquent que sa valeur de paramètre doit être «Faux» .
Il est tout à fait naturel que l'étape suivante ait été la création de modules décodeurs qui déterminent sur quoi se concentrer, comme dans le modèle habituel «de séquence en séquence». Cependant, au lieu d'un décodeur, qui est utilisé pour tout, nous avons maintenant plusieurs décodeurs, chacun étant spécialisé dans la prédiction de paramètres spécifiques. De plus, comme chaque module a une terminologie clairement définie, il devient beaucoup plus facile de configurer l'interaction utilisateur au niveau du module.
Modérateur: Seuls quelques modules seront utilisés pour chaque phrase d'introduction. La tâche du régulateur est de déterminer quels modules il va exécuter. Ainsi, le régulateur est également un décodeur qui détermine ce sur quoi il vaut la peine de se concentrer. En codant une instruction et en la transformant en entrée, elle crée une séquence de modules appelée circuit. Ensuite, les modules créent les paramètres qui leur correspondent et, enfin, les paramètres sont combinés pour former la demande finale à l'API.
En décomposant le processus de prévision complexe du modèle standard «séquence à séquence» en petites unités de prévision hautement spécialisées appelées modules, le modèle de prévision sera facile à expliquer aux utilisateurs. Ensuite, en utilisant les commentaires des utilisateurs, il sera possible de corriger les éventuelles erreurs de prévision au niveau le plus bas. Dans notre étude, nous testons notre hypothèse en comparant l'INL interactif à sa version non interactive, à la fois par simulation et par des expériences impliquant des personnes utilisant des API réellement fonctionnelles. Nous pouvons démontrer qu'avec les NLI interactifs, les utilisateurs réussissent plus souvent et plus rapidement, ce qui se traduit par des niveaux de satisfaction plus élevés.
Très prochainement, nous publierons
un article qui détaille la création d'interfaces en langage naturel pour l'API web. Restez à l'écoute!