Las interfaces de programación de aplicaciones (API) están desempeñando un papel cada vez más importante tanto en el mundo virtual como en el físico gracias al desarrollo de tecnologías como la arquitectura orientada a servicios, la computación en la nube e Internet de las cosas (IoT). Hoy, nuestros colegas de la división Microsoft Research compartieron sus mejores prácticas en el campo de las interfaces de lenguaje natural (interfaces de lenguaje natural). Únete ahora!
Los servicios web basados en la nube dedicados al clima, los deportes y las finanzas a través de la API web proporcionan datos y servicios a los usuarios finales, mientras que los dispositivos IoT permiten que otros dispositivos en la red utilicen su funcionalidad.
Por lo general, las API se utilizan en varios programas: aplicaciones de escritorio, sitios web y aplicaciones móviles. También sirven a los usuarios a través de una interfaz gráfica de usuario (GUI). Las interfaces gráficas han hecho una gran contribución a la popularización de las computadoras, pero, con el desarrollo de la tecnología informática, sus muchas limitaciones son cada vez más evidentes. A medida que los dispositivos se vuelven más pequeños, más móviles e inteligentes, cada vez hay más demandas en la pantalla gráfica en la pantalla, por ejemplo, con dispositivos portátiles o dispositivos conectados al IoT.
Los usuarios también se ven obligados a acostumbrarse a una amplia variedad de interfaces gráficas cuando utilizan diversos servicios y dispositivos. A medida que aumenta la cantidad de servicios y dispositivos disponibles, también lo hace el costo de capacitación y adaptación de los usuarios. Las interfaces de lenguaje natural (NLI) demuestran un potencial significativo como una herramienta inteligente única para una amplia gama de servicios y dispositivos del lado del servidor. Los NLI tienen capacidades increíbles para determinar la intención del usuario y reconocer la información contextual, lo que hace que las aplicaciones, como los asistentes virtuales, sean mucho más convenientes para los usuarios.
Estudiamos interfaces de lenguaje natural para API (NL2API). A diferencia de las NLI de uso general, como los asistentes virtuales, tratamos de comprender cómo crear NLI para API web individuales, como la API del servicio de calendario. En el futuro, estos NL2API podrán democratizar la API, ayudando a los usuarios a interactuar con los sistemas de software. También pueden resolver el problema de escalabilidad de los asistentes virtuales de propósito general al permitir el desarrollo distribuido. La utilidad de un asistente virtual depende en gran medida de la amplitud de sus capacidades, es decir, de la cantidad de servicios que admite.
Sin embargo, la integración de servicios web en un asistente virtual de uno en uno es un trabajo increíblemente laborioso. Si los proveedores de servicios web individuales tuvieran una manera fácil de crear NLI para sus API, los costos de integración podrían reducirse significativamente. Un asistente virtual no tendría que manejar diferentes interfaces para diferentes servicios web. Sería suficiente para él simplemente integrar NL2API individuales, que logran uniformidad gracias al lenguaje natural. NL2API también puede facilitar el desarrollo de servicios web, sistemas de recomendación de programación y ayuda para la API. Por lo tanto, no tiene que memorizar la gran cantidad de API web disponibles y su sintaxis.
Figura 1. Formas de crear una interfaz de lenguaje natural para la API. Izquierda: los métodos tradicionales enseñan a los modelos de percepción del lenguaje a reconocer intenciones en un lenguaje natural, otros modelos aprenden a extraer celdas asociadas con cada intención y luego las emparejan manualmente con las solicitudes de API. Correcto: nuestro método puede traducir el lenguaje natural directamente en solicitudes de API.La tarea principal de NL2API es reconocer expresiones en el lenguaje natural del usuario y traducirlas a una solicitud de API. Para ser más precisos, nos centramos en las API web creadas a semejanza de la arquitectura REST, es decir, la API RESTful. Las API RESTful se usan ampliamente en servicios web, dispositivos para IoT, así como en aplicaciones para teléfonos inteligentes. Un ejemplo de la API de Microsoft Graph se muestra en la Figura 1.
El lado izquierdo de la figura muestra el método tradicional de construcción de un lenguaje natural, en el que enseñamos modelos de percepción del lenguaje para reconocer intenciones, y otros modelos para extraer celdas asociadas con cada una de las intenciones, y luego emparejarlas manualmente con las solicitudes de API escribiendo código. En cambio (como se muestra en el lado derecho de la figura), podemos aprender a traducir expresiones de un lenguaje natural directamente en solicitudes de API. Como parte del estudio, utilizamos nuestro sistema para API del paquete
API de Microsoft Graph . Las API web de Microsoft Graph permiten a los desarrolladores acceder a datos que mejoran la productividad: correo, calendario, contactos, documentos, directorios, dispositivos y más.
Figura 2. Las API web de Microsoft Graph permiten a los desarrolladores acceder a datos que proporcionan una mayor productividad: correo, calendario, contactos, documentos, directorios, dispositivos y más.Uno de los requisitos para el modelo que estamos desarrollando es la capacidad de crear una interfaz de usuario detallada. La mayoría de las NLI existentes hacen poco para ayudar a los usuarios si el equipo no fue reconocido correctamente. Sugerimos que una experiencia de usuario más detallada puede hacer que NLI sea mucho más conveniente.
Desarrollamos un modelo modular que funciona "de secuencia en secuencia" (ver Figura 3) para proporcionar una interacción detallada con NLI. Para hacer esto, utilizamos una arquitectura que funciona según el principio de "secuencia a secuencia", pero al mismo tiempo desglosamos el resultado del descifrado en varias unidades interpretadas, llamadas módulos.
Cada módulo intenta predecir un resultado predeterminado, por ejemplo, mediante el uso de un parámetro específico basado en una declaración recibida en NL2API. Después de una comparación simple, los usuarios pueden comprender fácilmente el resultado del pronóstico de cualquier módulo e interactuar con el sistema a nivel modular. Cada módulo en nuestro modelo genera resultados consistentes, no un estado continuo.
Figura 3. Un modelo modular que trabaja de secuencia en secuencia. El controlador activa varios módulos, cada uno de los cuales crea un parámetro.Módulos: Primero definimos qué es un módulo. Un módulo es una red neuronal especializada diseñada para realizar una tarea específica de predecir una secuencia. En NL2API, diferentes módulos corresponden a diferentes parámetros. Por ejemplo, en la API GET-Messages, los módulos serán FILTER (remitente), FILTER (isRead), SELECT (adjuntos), ORDERBY (recibidoDateTime), SEARCH, etc. La tarea del módulo es reconocer la declaración entrante y crear un parámetro completo si está activado. Para esto, el módulo debe determinar los valores de su parámetro en función de la declaración entrante.
Por ejemplo, si una declaración entrante suena como "letras no leídas sobre una disertación doctoral", el módulo de BÚSQUEDA debe predecir que el valor del parámetro de BÚSQUEDA es "disertación doctoral" y generar el parámetro completo de "disertación doctoral de BÚSQUEDA" como la secuencia de salida. Por analogía, el módulo FILTER (isRead) debe recordar que frases como "correos electrónicos no leídos", "correos electrónicos que no se han leído" y "correos electrónicos aún no leídos" indican que el valor de su parámetro debe ser "Falso" .
Es natural que el siguiente paso sea la creación de módulos decodificadores que determinen en qué enfocarse, como en el modelo habitual "de secuencia a secuencia". Sin embargo, en lugar de un decodificador, que se utiliza para todo, ahora tenemos varios decodificadores, cada uno de los cuales se especializa en predecir parámetros específicos. Además, dado que cada módulo tiene una terminología claramente definida, resulta mucho más fácil configurar la interacción del usuario a nivel del módulo.
Moderador: Solo se usarán unos pocos módulos para cada frase introductoria. La tarea del regulador es determinar qué módulos ejecutará. Por lo tanto, el regulador también es un decodificador que determina en qué vale la pena enfocarse. Al codificar una declaración y convertirla en entrada, crea una secuencia de módulos llamada circuito. Luego, los módulos crean los parámetros que les corresponden y, finalmente, los parámetros se combinan para formar la solicitud final a la API.
Al dividir el complejo proceso de pronóstico en el modelo estándar de "secuencia a secuencia" en unidades de pronóstico pequeñas y altamente especializadas llamadas módulos, el modelo de pronóstico será fácil de explicar a los usuarios. Luego, utilizando los comentarios de los usuarios, será posible corregir posibles errores de pronóstico en el nivel más bajo. En nuestro estudio, probamos nuestra hipótesis comparando el NLI interactivo con su versión no interactiva, tanto a través de la simulación como a través de experimentos que involucran a personas que utilizan API que realmente funcionan. Podemos demostrar que con los NLI interactivos, los usuarios alcanzan el éxito con mayor frecuencia y rapidez, lo que resulta en niveles más altos de satisfacción del usuario.
Muy pronto, publicaremos
un artículo que detalla la creación de interfaces de lenguaje natural para la API web. Estén atentos!