Header Ads Widget

Ticker

6/recent/ticker-posts

¿Debería diseñar primero las API de Natural Language?

 


Los humanos se están volviendo más perezosos, pero las API tienden a ser bastante complicadas. ¿No sería bueno si pudiéramos, en cambio, hablar en un lenguaje sencillo para iniciar automáticamente cualquier cambio en el backend? Para algunos escenarios, una fachada de lenguaje natural puede ser simplemente hacia donde se dirigen las API web.

El esquema clásico CRUD (Crear, Leer, Actualizar, Eliminar) para actuar sobre los datos está en desacuerdo con la forma en que los humanos se comunican naturalmente, lo que plantea algunas preguntas interesantes sobre el diseño de API cuando consideramos la ubicuidad entrante de las máquinas integradas en inteligencia artificial y controladas por voz. Como describimos anteriormente , el procesamiento del lenguaje natural (PNL) es una tendencia creciente que podría afectar la estructura de la comunicación máquina-máquina.

El problema se reduce a cómo los desarrolladores se comunican con una base de datos. Al interactuar con la asistencia de voz y los comandos impulsados ​​por NLP, herramientas como Alexa, Google Home, demuestran cómo CRUD ya no es aplicable para todas las situaciones de diseño. James Higginbotham ha expresado cómo el diseño de API está cambiando en la era de los bots, IoT y voz. También vimos evidencia en la Cumbre de Plataformas 2018 de las API nórdicas: Pavel Veller proporcionó un ejemplo de comprensión del lenguaje natural integrado en la práctica. La API de Pavel en realidad acepta comandos en idioma inglés natural dentro de las solicitudes JSON.

En este artículo, profundizaremos en cómo y por qué las API pueden usar lenguaje natural en sus diseños. Consideraremos cómo podría comportarse una API web diseñada con comprensión del lenguaje natural, citando una aplicación de viaje de muestra impulsada por el lenguaje natural en el proceso.

Esta publicación se inspiró en una sesión impartida por Pavel Veller en la Cumbre de Plataformas 2018 de las API nórdicas:

Diapositivas

¿Qué es la comprensión del lenguaje natural?

En primer lugar, ¿qué es exactamente la comprensión del lenguaje natural? En una presentación en las API nórdicas, Pavel Veller describe cómo los modelos estadísticos se centran principalmente en dos objetivos principales para comprender el lenguaje: detección de intenciones y reconocimiento de entidades con nombre .

Veamos cómo funciona esto en la práctica. Por ejemplo, si un usuario realiza una solicitud a una aplicación de programación de reuniones, un comando de voz típico podría ser algo como:

"Please schedule a meeting with Robert for tomorrow at 2pm"

Es probable que el algoritmo del otro extremo intente primero comprender la intención de la solicitud. Un analizador resaltará la palabra clave "programación" para activar la funcionalidad de programación. A continuación, se descubrirán entidades como quién y cuándo . En este caso, estas entidades son Roberttomorrow2pmCon esta información, la aplicación de programación puede cumplir fácilmente algo como una llamada a la API del calendario de Google para satisfacer la solicitud del usuario.

Relacionado: ¿Qué significa el auge de los bots para las API?

¿Por qué crear una API con NLP Design?

El procesamiento del lenguaje natural ahora se utiliza para chatbots, asistentes de voz y otros escenarios emergentes de IoT. En estas transacciones, NLP no encaja del todo con el modelo CRUD, lo que invita a algunos desarrolladores a construir interfaces externas de apariencia más natural.

Fuera del razonamiento CRUD, incluir el lenguaje natural dentro del diseño de la API puede traer otros beneficios. En primer lugar, confía más en los servidores backend para proporcionar funcionalidad, satisfaciendo la filosofía de colocar más carga en el lado del servidor. También puede aumentar la experiencia del desarrollador, lo que permite a los principiantes y no codificadores aprovechar al máximo las API.

Lea también: 7 tendencias de diseño de API en crecimiento

¿Qué aspecto tiene una API que utiliza NLP?

No existe una regla estricta y rápida sobre cómo deben diseñarse las API infundidas con PNL. Una API de lenguaje natural puede recibir solo una cadena de texto en inglés sin formato como entrada. Lo que viaja por el cable podría ser una frase en inglés natural.

Curiosamente, si miramos la definición de JSON , vemos que no hay nada de malo en usar lenguaje natural, ya que JSON es independiente del lenguaje:

"JSON es un formato de texto que es completamente independiente del idioma ... Estas propiedades hacen de JSON un idioma ideal para el intercambio de datos"

Pavel señala que JSON no es un idioma, sino un idioma de intercambio de datos, por lo que transportar un inglés simple es sin duda un juego justo. Se podría argumentar que una API de lenguaje natural puro también debería responder en lenguaje sencillo. Sin embargo, Pavel prevé obstáculos con esto, como errores de comunicación y la molestia de ejecutar la comprensión del lenguaje natural en el lado del cliente para las solicitudes entrantes.

Estudio de caso: Travelwhelm

Entonces, ¿cómo diseñaríamos una API de lenguaje natural? Veamos uno de esos casos: la API Travelwhlem . Travelwhelm es un proyecto paralelo desarrollado por Pavel para ayudar a calcular el tiempo que pasa viajando.

Esta herramienta de cara al usuario acepta información sobre viajes y genera un porcentaje del tiempo dedicado a viajar. Los empleados en marketing, como los defensores de los desarrolladores, por ejemplo, a menudo están de acuerdo en que un cierto porcentaje de sus horas de trabajo esté de viaje. Por lo tanto, los usuarios que viajan en avión pueden ingresar su tiempo de viaje en Travelwhelm para calcular un porcentaje cada mes.

Relacionado: Los asistentes virtuales aprovechan el poder de los desarrolladores de terceros

3 opciones de entrada de lenguaje natural

Puede interactuar con Travelwhelm en cualquiera de estos tres métodos: una entrada a un sitio web , un mensaje de texto SMS o mediante una habilidad de Alexa . En la Cumbre de la Plataforma, Pavel ofreció una demostración en vivo del proceso en acción; habló con un dispositivo Amazon Echo para iniciar un ajuste de calendario en la interfaz Travelwlehm.

Tome este comando Travelwhlem de muestra:

"I was in New York last Thursday"

Afortunadamente, el sistema de lenguaje natural no necesita descubrir mucho para iniciar este comando. Simplemente tiene que marcar cada día, ya sea como viajado o no recorrido . Pavel describe cómo diseñar un sistema binario es un primer paso fácil.

"Cuando resuelvo problemas con la tecnología, lo primero que intento es lo más fácil que funciona"

Pavel destila esta teoría en Travelwhelm al detectar primero una intención positiva o negativa, ya sea viajar o no viajar. Su algoritmo elaborado en casa utiliza la siguiente expresión para analizar el sentimiento negativo:

/\bcance|\bnot\b|\b(wo|were|was)n't/

A continuación, la aplicación debe buscar entidades , que en este caso eran fechas. Como puede inferir, hay muchas bibliotecas disponibles para el reconocimiento de fechas fuera del inglés, como Stanford y Google NLP . Sin embargo, en el caso de Pavel, los matices de sus comandos de usuario no funcionaron bien con ninguna biblioteca construida previamente. Tomemos, por ejemplo, este comando:

I will be in Stockholm on October 22nd, 23rd, and 24th

Desafortunadamente, las bibliotecas construidas previamente solo pudieron detectar el patrón de month + date, lo que significa que solo el 22 de octubre se reconocería a partir de la declaración anterior. Esto da como resultado una fecha y dos números ordinarios que no se basan en el mes. Del mismo modo, existen problemas con comandos como:

"I was in SFC this past Tues and Wed"

Pavel descubrió que las bibliotecas de PNL tienen problemas para conectar la información que se basa en palabras anteriores. Entonces, se puso a trabajar en la construcción de su propia biblioteca, Orolo , que describe como un “analizador agresivo” diseñado para comprender fechas y rangos de fechas en una oración.

Lea también: Uso del flujo de dispositivos OAuth para dispositivos que no admiten la interfaz de usuario

Conclusiones sobre cómo diseñar primero el lenguaje natural

El reconocimiento de entidades con nombre no es fácil y la evolución del lenguaje natural siempre puede estar un paso por delante de nuestras máquinas digitales vacías. Sin embargo, Pavel es optimista de que algún día los sistemas realmente podrán comunicarse entre sí utilizando el lenguaje natural. Para las API de nicho que entran en contacto con escenarios controlados por voz, tal diseño podría tener sentido, aliviando la presión de procesamiento en el lado del cliente.

“Quizás en el futuro podamos hacerlo mucho mejor con la comprensión del lenguaje natural…. Y tal vez los sistemas puedan comunicarse entre sí "

Sin embargo, por ahora, los experimentos de Pavel actúan como un recordatorio informativo: construir la comprensión del lenguaje natural desde cero requiere mucho tiempo . Pavel observa cómo su biblioteca de Orovlo tomó exponencialmente más tiempo para construir que el propio marco de la aplicación. El lenguaje natural agrega otra capa de abstracción a una API, lo que aumenta la complejidad y la necesidad de mantenimiento adicional.

Entonces, ¿deberían los desarrolladores crear API que solo hablen inglés (o cualquier lenguaje natural, para el caso)? Probablemente una respuesta simple no sea en este momento. Como ha señalado Pavel, los matices sutiles en los comandos aún requieren bibliotecas personalizadas y analizar el inglés en el lado del cliente es una carga. Aún así, es un concepto novedoso y seguiremos considerando a medida que las interfaces de usuario se vuelvan más impulsadas por la voz en el futuro de la IA personal.

Publicar un comentario

0 Comentarios