Estamos en un momento en el que los chatbots y los asistentes virtuales parecen surgir como setas, y si tienes una empresa y no tienes algún proyecto de chatbots parece que te estés quedando atrás. Los chatbots se basan en técnicas de Procesamiento del Lenguaje Natural (NLP, Natural Language Processing) para entender lo que les dice. Pero cuando a alguien le preguntas "¿y cómo funciona?" te suelen contestar un "pues con inteligencia artificial", y si tratas de rascar una respuesta más válida, te miran con cara rara como si fueses un bicho raro y repiten como un mantra "pues con inteligencia artificial, ¿qué no entiendes?".
Todo ello crea un halo de misticismo y una sensación de que hay unos avances en inteligencia artificial brutales, y te deja pensando que cualquier día te despiertas y tu tostadora tratará de matarte mientras tu Google Home chilla "¡muerte a los seres de carne!". Y bueno, no te quedas tranquilo del todo. Y por eso es mejor entender qué es la inteligencia artificial y cómo los chatbots entienden el lenguaje de los humanos.
Por cierto, se me escaparán muchos términos en inglés, pero es que es un tema técnico y la terminología común es en inglés, si yo os digo "declaración y propósito" en lugar de "utterance e intent", seguramente cuando vayáis a leer sobre el tema no os enteraréis de nada. Lo siento de antemano, pero mejor ceñirse a la terminología técnica.
Utterances e intents
Son nombres raros, pero conceptos sencillos. Una utterance es una frase dicha en lenguaje natural, es decir, tal y como la dice una persona. Un intent vendría a ser la intención de dicha frase, lo vemos mejor con esta tabla, que será el ejemplo que veremos a lo largo de todo el artículo:
Una cosa a entender es que cuando tienes un chatbot, tienes una lista de intents, que son las cosas que puede realizar tu chatbot, y para cada intent has entrenado con una o varias utterances. Pero puede suceder que el usuario diga una frase que no se corresponde a nada que el chatbot sepa hacer, y en esas situaciones la inteligencia artificial debe ser capaz de suponer que no es ninguno de los intents, para poder responder al usuario algo como "Lo siento, no entiendo tu pregunta" o similares.
Tokenization
Antes de entrenar, cada una de las frases debe descomponerse en una lista ordenada de palabras. A este proceso se le llama "tokenization". Durante este proceso se puede decidir si los signos de puntuación son retirados o no, dependiendo de cómo queramos trabajar con las frases. Supongamos que nuestro método funciona sin signos de puntuación, entonces nuestro ejemplo anterior quedaría así:
Este proceso que puede parecer sencillo en castellano, se vuelve más arduo en otros idiomas. Pensad sin ir más lejos el inglés la frase "I'm here but I don't see you", la descomposición tiene que romper las contracciones: [I, am, here, but, I, do, not, see, you]. Este proceso se hace especialmente complicado en idiomas como japonés o chino. En japonés hay dos silabarios, hiragana y katakana, en los que cada símbolo respresenta a una sílaba, y además están los kanjis en los que cada símbolo es un idiograma que representa una idea. Para hacer este proceso en japonés, es necesario tener un proceso de conversión de kanjis y de hiragana hacia katakana.
Normalización
Es un proceso opcional pero útil en muchos casos, y básicamente consiste en pasar a minúsculas y opcionalmente eliminar símbolos especiales como las tildes, diéresis y demás.
Stemming y Lemmatization
Ahora que tenemos las palabras, tenemos un problema con palabras derivadas, conjugaciones y similares. Por ejemplo "viajando", "viajé", "viajaré", de todas esas formas entendemos que el verbo es "viajar". El lema sería saber calcular la palabra de base con significado existente en el diccionario, en este caso "viajar", y a la acción de calcular ese lema se le llama "lemmatization". Por desgracia este proceso es duro de hacer porque implica tener un diccionario con todas las formas diferentes que pueden tener las palabras, y eso implica mucho trabajo, mucho espacio, memoria y tiempo de búsqueda.
Pero además del lema, existe el concepto de raíz. La raíz de las palabras "viajando", "viajé" y "viajaré" es "viaj". A la acción de buscar esta raíz se le llama "stemming". La ventaja del stemming es que hay algoritmos para hacerlo, que aunque no son perfectos, son suficientemente buenos.
Aquí tendríamos nuestro ejemplo tras aplicar stemming:
Features y Frecuencia
A cada uno de las diferentes raíces que hemos calculado la llamaremos "feature". Además podemos calcular la frecuencia que tienen nuestras features en el modelo que queremos entrenar.
Ahora para cada frase podemos calcular un vector de features, en el que cada posición representa a una feature, y si esa frase la tiene ponemos un 1 (o un true) y si no la tiene pondremos un 0 (o un false). Nuestros vectores de features de los datos de entrenamiento quedaría así:
Clasificación
Ahora es cuando empieza el proceso. ¿Qué sucede cuando alguien le dice algo al bot? Pues que esa frase debe ser clasificada, es decir, se debe decidir si se corresponde con alguno de los intents de nuestro modelo, y no solamente eso, sino que nos debe decir qué seguridad tiene de ello, a ser posible mediante una probabilidad.
Por cierto, aprovecho para decir que en inteligencia artificial una clasificación es cuando dado un input debemos calcular el output dentro de un ámbito discreto, es decir, conocemos de antemano una lista finita de posibles outputs. Pero también existen las regresiones dónde dado un input se calcula el output dentro de un ámbito contínuo, valores numéricos por ejemplo.
Para ello siempre la fase que entra pasará por las fases anteriores: tokenization, normalization, stemming y finalmente obtener un vector de features. ¿Qué sucede cuando la frase contiene palabras cuya raíz no es ninguna de las features que tenemos? Pues que esas palabras se descartan.
Supongamos que al bot le decimos "Dime cómo te haces llamar". El proceso sería el siguiente:
Naive Bayes Classifier
Muchas veces al lidiar con la clasificación la gente opta por algo llamado Naive Bayes Classifier o Clasificador Bayesiano Ingenuo. Esto se suele hacer porque es un método que no require entrenamiento, y es meramente estadístico, con lo cual es rápido de calcular. Por desgracia sus resultados en el ámbito de chatbots no son muy buenos que digamos.
El método es sencillo, para cada intent se hace el siguiente cálculo: se cuentan en cuántas de las observaciones del intent está presente cada feature, y ese número se divide entre el número de observaciones y se calcula el logaritmo neperiano. En nuestra frase "dime cómo te haces llamar" vemos que la feature "com" está presente en una observación, así que el valor sería ln(1/3) = -1.09861.
Hacemos lo mismo para cada feature, y sumamos los resultados. El total nos da -4.39444.
Ahora elevamos e a ese resultado (0.01235), lo multiplicamos por el número de observaciones de ese intent (3) y dividimos entre el número total de observaciones de nuestro modelo (6) y el total nos da 0.006175.
En el caso del intent llamar, hacer las mismas operaciones nos lleva al resultado 0.
Inteligencia Artificial
Aquí es dónde llega la magia. La inteligencia artificial la hay de muchas formas y colores, pero hoy vamos a hablar del perceptrón.
Suponed que tenéis una función f que no sabéis cuál es, pero sí sabéis varios x diferentes (x1, x2, x3,...) y cuánto vale f(x) para cada uno (y1, y2, y3,...). Y os piden que hagáis una función g que se comporte lo más parecido posible a la función f.
Lo primero que hay que preguntarse es, ¿cómo sé yo si dos g diferentes que me invente, cuál es la que mejor se aproxima a f? Haciendo una función que me diga cuál es el error, un simple número que cuanto más bajo mejor. Esta función la encontraréis con el nombre de función de coste, loss o error. El objetivo de una inteligencia artificial es calcular esa función g, y para saber lo bien que lo está haciendo necesita esa función de coste porque es la que va a usar para estimar si va por el buen o mal camino.
Y aquí es dónde entra en juego el perceptrón:
El perceptrón no es más que una función que dado un vector entrante, multiplica cada término por un número distinto llamado peso y al resultado le suma un número llamado bias. Cuando ha calculado esto, aplica una función llamada función de activación. Si nuestra función f admitía 3 parámetros, f(x1, x2, x3), eso significa que tendremos 3 pesos w1, w2 y w3, y el bias, y nuestro resultado será activación(x1*w1 + x2*w2 + x3*w3 + bias).
Si combinamos varios perceptrones en forma de red, tendremos muchísimos pesos y bias por el medio a calcular, pero la función resultante puede ser cada vez más compleja.
El problema está en, ¿y cómo calculo esos pesos y ese bias de mi modelo? Podríamos hacerlo a mano, empiezas poniendo varios al azar, miras el resultado y aplicas la función de coste, y luego vas haciendo cambios y calculas de nuevo la función de coste y así poco a poco vas viendo si vas bien o mal... Pero eso es un tostón. Y aquí es dónde viene en nuestra ayuda algo llamado optimizador. Un optimizador es el verdadero cerebro de una inteligencia artificial y es el que va a calcular esos pesos y bias por nosotros, usando la función de coste para guiarse. ¿Y cómo lo hace? Bueno, os podría hablar del descenso de gradiente, y cómo es un problema bastante complejo en el que trabajó incluso Newton, pero vamos a simplificarlo un poco porque no es el objetivo. Pero quedémonos conque tiene que buscar el mínimo de la función de coste y para ello hace cambios en los números. Y el tamaño de cada cambio que puede hacer se denomina learning rate. Y esto es muy importante, porque sucede lo siguiente:
Si el learning rate es muy bajo, calculará muy bien el mínimo, pero llevará mucho tiempo. Si el learning rate es muy alto, puede suceder que no encuentre un mínimo satisfactorio y pasaría que no aprendería. Así que hay que encontrar el learning rate adecuado para que obtenga una solución suficientemente buena en un tiempo aceptable.
Logistic Regression Classifier
Entendido lo anterior, ¿cómo lo aplicamos a nuestro problema? Bien, suponed que para cada intent tenéis un perceptrón. No hace falta más la verdad. Cada uno de esos perceptrones responderá a una simple pregunta: ¿qué probabilidad hay de que la frase que dice nuestro usuario, que es este vector de unos y ceros que representan features, se corresponda con las frases que tiene ese intent? Y con eso puedes calcular los pesos, y el modelo quedaría así:
La segunda y tercera columna son los pesos para cada uno de los intents. ¿Por qué resulta que son los mismos pero negados? Porque solamente hay 2 intents, y las features no se solapan, así que las que son buenas para un intent, son malas para el otro en la misma cantidad.
La cuarta columna es nuestro vector de features, la quinta columna es la segunda multiplicada por la cuarta, y la sexta columna es la tercera multiplicada por la cuarta. Resulta que nuestra frase nos devuelve el número 4,823266 para el intent "nombre" y -4,82327 para el intent "lugar". Pero recordad que hay algo llamado función de activación: en nuestro caso elegimos la sigmoide, pero podría haber sido perfectamente la tangente hiperbólica. Y los resultados son que está un 99,2% seguro de que el intent es "nombre".
¿Y cómo se yo si una IA es mejor o peor que otras para hacer chatbots?
Bueno, no hay mucho material al respecto, pero hay un paper de base de la Universidad de Munich: workshop.colips.org/wochat/@sigdial2017/documents/SIGDIAL22.pdf
El paper propone probar con 3 corpus diferentes, es decir, con 3 conjuntos de utterances/intents, y para cada utterance te dice si es un dato para entrenar o un dato para probar, de forma que el sistema de NLU verá los datos para entrenar, y luego debe calcular los resultados para datos que no ha visto nunca.
Y estos son los resultados que hay de esa evaluación para diferentes sistemas de NLU. A destacar que todos son en la nube excepto RASA y NLP.js. Esto es importante porque si vuestra empresa maneja datos delicados, normalmente no querréis mandar las conversaciones de vuestros usuarios a Microsoft, Google, IBM, SAP u otra empresa de terceros.
Extracción de entidades
Solamente con saber el intent basta para según qué problemas, pero para otros no es suficiente y hay que hacer algo llamado extracción de entidades. ¿Qué significa eso? Suponed que queréis hacer un chatbot para gestionar viajes, y para poder dar opciones al usuario necesitáis tres datos: la ciudad de origen, la ciudad de destino y la fecha. Está claro que esos datos no van en el intent. Pensad en la frase "quiero viajar de Madrid a Londres mañana", el intent sería "viajar", pero necesitáis la entidad ciudad de origen "Madrid", ciudad de destino "Londres" y fecha "mañana".
La extracción de entidades se suele hacer con reglas (expresiones regulares) más que con inteligencia artificial. Una de las maneras más sencillas es simplemente tener una lista de palabras, por ejemplo en el problema anterior la lista de ciudades, aunque ya véis que no bastaría porque un usuario puede decir "quiero viajar de Madrid a Londres" o puede decir "quiero viajar a Londres desde Madrid", así que normalmente hay más reglas por detrás.
Slot Filling
¿Qué pasa cuando necesitas obligatoriamente unas entidades y el usuario no te las dice todas? Pues que tienes que preguntar las que faltan. A este proceso se le llama slot filling. En el ejemplo anterior el usuario podría decir "quiero viajar mañana a Londres", y el bot tendría que reaccionar preguntando "¿Desde dónde viajar?".
Pues a mí me habían hablado de algo llamado PoS
PoS significa Part of Speech. ¿Recordáis en lengua cuando en una oración teníamos que saber sujeto, predicado, complemento del verbo, adverbios,...? Pues eso es exactamente lo mismo. Por ejemplo:
Habíamos visto en la parte de entidades que era complejo saber, dada una lista de ciudades, si una ciudad en concreto es el origen o el destino. Si miramos el gráfico anterior vemos que el PoS nos relaciona Madrid con "desde" y podemos inducir de ello que es el origen, y nos relaciona Londres con "hasta" y podemos inducir de ello que es el destino.
¿Y qué es un n-grama?
¡Pero si yo he mencionado n-gram en todo el artículo! Pero ya que preguntas, son secuencias de n palabras consecutivas. Por ejemplo en la frase "me gustan mucho las lentejas" podrías calcular 4 bigramas [(me, gustan), (gustan, mucho), (mucho, las), (las, lentejas)], 3 trigramas [(me, gustan, mucho), (gustan, mucho, las), (mucho, las, lentejas)]... etc.
Esto es muy útil para saber la frecuencia con la que varias palabras van juntas, para calcular modelos de Markov. ¿Sabéis la predicción de palabras en móviles por ejemplo? Pues se basan en esto.
También son útiles en criptografía, pero eso es otra historia.
¿Y el word2vec del que se habla tanto?
Bueno, NLP es un ámbito muy grande con muchos temas de estudio. word2vec propone representar las palabras como vectores en un espacio n-dimensional en el que cada dimensión representa a una cierta característica de la información. Pero esto no se suele usar en chatbots, porque normalmente no hay corpus suficiente como para analizar y crear los vectores. Pero por ejemplo analizando libros o documentación sí.
Estos vectores tienen unas propiedades muy curiosas, como que por ejemplo se pueden sumar o restar, y.. bueno, recordad que cada dimensión era una característica. Suponed la palabras "Rey" y "Reina", sus vectores serían muy similares, lo mismo que las palabras "hombre" y "mujer". Pues resulta que puedo hacer esta operación vectorial: "Rey - hombre + mujer" y obtengo un vector, que resulta que será el mismo o el más cercano a "Reina".
Lo mismo si educase mi modelo con países, ciudades y datos geopolíticos, si hago "París - Francia + España" me daría el vector de Madrid.
Conclusión
La inteligencia artificial no es magia, y tampoco es un Terminator. Es lo que es y sirve para lo que sirve, y en el caso del NLU para chatbots el resultado es bastante satisfactorio. Además, según tienes un chatbot funcionando, cada vez tienes más información de qué piden los usuarios y cómo lo piden, y puedes reentrenarlo para que cada vez sea capaz de responder a más y más cosas y hacer más y más acciones.
Comentarios
¿Esto lo has escrito tú o lo has copiado de algún sitio? Si es lo primero, felicidades, has dado un curso claro y sencillo del tema. Si no, deberías comprobar la licencia del documento y si fuera necesario, eliminarlo.
#1 Como podrás comprobar buscando, no existe en ningún sitio, está escrito por mí íntegramente.
#2 Está genial y aporta más que la inmensa mayoría de artículos y noticias.
Me acuerdo que meneame estaba plagado de envíos como éste, con información útil y de calidad, hace muchos años. Gracias por hacerme recordar lo que un día fue este sitio.
#4 Bueno, la bajada de calidad de contenidos de menéame, desde mi opinión, es fruto de diversos factores.
- No es una plataforma adecuada para escribir contenidos. Aunque existen muchas opciones opensource para editar contenidos, menéame opta por algo "hecho a mano" que carece de cosas fundamentales como el autoguardado de borradores, y la interfaz deja un pelín que desear.
- La base de usuarios ha cambiado. Antes se premiaba la información útil, hoy se premia lo rápido, mascado y mediocre. Echa un ojo en artículos a los últimos, de los que más karma tienen una tira cómica de disfraces de halloween que además no tiene gracia. Esfuerzo: click en artículo, click en subir foto. Aportación propia del usuario: 0.
- Como la base de usuarios cambia y se premia lo rápido y mediocre, los usuarios que sí aportaban se van con su música a otra parte. Uno no dedica varias horas de su vida a escribir un artículo basado en años de experiencia en un tema, para ver que una foto de un gatete resulta mucho más importante, y que su artículo muere en una marea de contenidos supérfluos. Así que se va a otros medios.
Pero es lo que hay, la vida es así de dura.
Buen articulo, pero hecho de menos añadir el que aportan las API de IBM Watson Conversation o de Google Dialogflow para reconocer intents y aplicar de forma automática diálogos en los chatbots.
#12 Me parece muy interesante lo que comentas de RSA, le hecharé un vistazo en cuanto pueda (no te extrañe que no lo conociera con anterioridad, mi puesto de trabajo no esta relacionado directamente con la IA, es mas inquietud personal y para aplicar sinergias con otros productos de los que si soy responsable).
Si conozco botkit, de hecho lo he usado con Watson, tanto para el UI de cara al usuario, como para aquellas cosas que en las que no quiero un dialogo asistido, sino mis propias reglas.. sigo opinando de todas formas que lo mejor es combinar ambos mundos, realmente los sistemas de dialogo asistido consiguen acelerar mucho el desarrollo y el mantenimiento....(ademas el watson assistant de ahora, no tiene nada que ver con el antiguo watson conversation de hace unos meses, ha mejorado muchisimo, no esta en absoluto limitado a empresas pequeñas, hay clientes muy grandes usandolo por las ventajas que comentaba).... eso no significa que debas usarlo para todo, son una ayuda mas (y considero que muy buena), no un sustituto.
Snips no lo conocia tampoco...... ¿ tiene algun diferenciador mas que el de poder ejecutarse en local sin requerir conexion a la nube ?. Por otra parte, quitando botkit, ¿ hay algun otro "frontal" para chatbots que me puedas sugerir ?
Buen articulo, pero hecho de menos añadir el que aportan las API de IBM Watson Conversation o de Google Dialogflow para reconocer intents y aplicar de forma automática diálogos en los chatbots (vamos, un poco de detalle sobre que podemos encontrarnos hoy en IA para trabajar con los chatbots).
#7 No entiendo muy bien tu pregunta la verdad. Lo que cuento en el artículo es con suficiente detalle el cómo se hace, precisamente para chatbots y no para análisis de corpus grandes. Y lo que cuento es con detalle lo que puedes encontrarte hoy en IA para trabajar con chatbots. Incluso incluyo una comparativa de NLU entre diversas plataformas. E incluso soy el desarrollador de la que tiene mejor score de NLU de todas ellas, así que creo que si sigues mi artículo paso a paso puedes desarrollar una IA exactamente igual, y que te dará mejor score que DialogFlow, y aproximadamente el de IBM Watson Conversation. No puedo confirmarte qué tipo de IA usa cada plataforma, lo que sí cuento en el artículo es cómo funciona una hecha con logistic regression classifier. Efectivamente no cuento binary relevance neural network, que es lo que permite dar mejor score que IBM Watson Conversation, pero mi código es licencia MIT, así que puedes ir a mirarlo.
Es decir, he dado un detalle brutal sobre como funcionan las IAs de NLU para chatbots.
Así que a lo mejor puedes reenunciar tu pregunta para que entienda qué es exactamente lo que echas de menos.
#8 La sencillez... Explicas muy bien los conceptos de NLU ,y como hacer tu propio analisis para que el bot tome decisiones.
Pero lo que yo creo entender es que la mayoria de las veces, no se utilizan esas tecnicas solas, simplemente por lo tedioso y lo complejo que puede llegar a ser construir un chatbot solo asi, y tomar decisiones. Ademas de las APIs de NLU de Watson , Google o cualquier otro proveedor (para lo cual viene muy bien saber los conceptos que tu indicas en tu articulo), mi experiencia con IBM Watson Assistant / Conversation (que es una capa "mas" a lo que simplemente serian las APIs de Watson NLU) es que simplifica enormemente hacer un chatbot al permitir identificar frases (y multiples variaciones de las mismas), asociarlas directamente a intents, identificar entities dentro de las mismas, y automaticamente, generarte el dialogo de vuelta, incluso solicitando al usuario final "scopes" si le faltan para hacer una accion (ejemplo que diga que quiera hacer una reserva pero no mencione en la frase para que dia o para cuantas personas). Nunca he querido insinuar que el articulo tuviera algun problema, ya digo que me parece un trabajo cojonudo.... y me ha servido para aprender cosas que no sabia.... pero yo (personalmente), con mis chatbots, me siento mucho mas comodo, y desarrollo mucho mas rapido (y con la suficiente precision) ayudandome de estos sistemas que he mencionado....... por eso echaba de menos simplemente mencionarlos, o bien para mencionar su valor añadido o por el contrario, aunque sea criticandolos, porque creo que son una parte importante, que mucha gente los usa, y que si te vas a meter a desarrollar chatbots, al menos debes conocer.
Para que te hagas una idea, con IBM Watson NLU es muy facil analizar una frase, pero incluso ni siquiera asi lo hago, prefiero utilizar directamente el Watson Assistant y automaticamente construir el dialogo....... De acuerdo que si me hago mi propio NLU ahorraria dinero (sin llamar a las APIs de Watson), pero no lo necesito. Me costaria mucho tiempo y esfuerzo llegar a un nivel parecido al que ya encuentro de terceros, el coste es totalmente asumible, consigo un desarrollo mucho mas rapido, sencillo, y me es mucho mas comodo añadir nuevas iteraciones y hacer un training/mantenimiento de la plataforma para reconocer nuevas frases.....
Si tuviera que reformular la pregunta, seria: ¿ Que valor ventajas e inconvenientes tiene desarrollarte tu propio NLU, al de utilizar frameworks/APIs que estan incluso un nivel por encima, al permitirte no solo utilizar su propio NLU Internamente, sino ademas general automaticamente dialogos y acciones ?
#9 Bien, por eso mi artículo no se titula "proovedores de NLP del mercado", se titula "cómo entienden los bots el lenguaje". Porque su objetivo es mostrar cómo funcionan los NLP por dentro, no enunciar cada uno de los comerciales y sus características ni compararlos. Eso lo dejo a los señores comerciales.
Pero ya que preguntas ventajas...:
1. Entender. En lugar de usar una API, que es algo que sabe hacer cualquier persona, estás entendiendo realmente la IA y cómo funciona, y deja de ser una caja mágica que hace cosas.
2. Gratuito y sin límites. Los que no cuestan dinero, tienen limitaciones al uso que no hacen posible implementar bots masivos a millones de usuarios.
3. Privacidad. Según la legislación de cada región, algunas conversaciones de usuarios no pueden ser enviadas a un tercero, por ejemplo datos sobre alergias, enfermedades, etc.
4. Velocidad. Al tener tu NLU directamente en el bot, el tiempo de clasificación de una utterance es de en torno a 1 milisegundo, frente al tiempo de transporte de una llamada a través de internet, que normalmente te pone en torno a 200ms mínimo, usualmente 400ms.
5. Implementación de características propias. Un ejemplo: la manera que tiene los proveedores en nube de manejar el multiidioma es que en cada utterance tienes que decir también el locale. En mi caso, identifico automáticamente el locale y lo paso al clasificador que toca, con lo cual un usuario puede cambiar de idioma en caliente en el bot, sin necesidad de pasar por un proceso de selección de idioma para guardar el locale en el contexto.
6. Modelo offline: Al entrenar tu modelo, puedes descargarlo e incluirlo en el bot, y no necesitar internet para nada. Por ejemplo para hacer bots que funcionan en móvil incluso si no hay cobertura. En mi caso lo que he implementado funciona en el browser, con lo cual se puede hacer una SPA sin estar consumiendo continuamente llamadas al backend.
7. Implementación propia de contexto y control de sesiones. Un ejemplo, con un bot con botkit o microsoft bot framework, el control del punto de conversación en el que estás para que los diálogos y ayudas sean contextuales al momento del usuario, no hay dios que lo haga en ningún NLP en la nube: Microsoft LUIS ni sabe lo que es un contexto, el de IBM solamente posee context variables, el más desarrollado comercial sería DialogFlow. En mi caso me lo implementé yo en mi NLP para que algo tan tonto como que las ayudas sean contextualizadas el momento del diálogo, funcionen en el NLP en lugar de tener que programarlas a mano.
8. Implementación de fallback to human, incluso basado en sentiment analysis.
Entiendo que trabajas en una de las empresas, pero no en la parte técnica que desarrolla la plataforma, sino como parte que la vende. Y por ello entiendo tu comentario. Pero entiende también que no ha lugar, dado el título y temática del artículo, en el que ni siquiera pongo link a mi código ni me promociono. Pero te invitaría, si además de vender sabes programar, a ir a mirar tanto la librería como el frontend.
#10 No pretendo que compares NLP del mercado. Solo digo que hay una capa mas, incluso, por encima del NLP, que facilita hacer trabajar a un bot, y que es la creacion de dialogos asistidos...... Tanto Google. como IBM, como Microsoft tienen API de NLU... pero luego, tienen otros "Productos" o "Servicios SaaS" que son asistentes de dialogo (que por dentro a su vez usaran NLUs). A esos me refereria...... no te pedia comparacion de los distintos que hay, sino que hubiera sido interesante tambien añadir en tu articulo la mencion a esta nueva capa......que puede usarse para automatizar el dialogo en un chatbot.. (y de manera sencilla y eficaz). Es algo habitual de usar tambien en bots, por lo que a mi parecer, si era algo que podia mencionarse dentro del articulo, y mas cuando este articulo es muy buena referencia en el uso de la IA en Chatbot para entender/procesar el lenguage.
No soy vendedor, soy tecnico, y tambien programo (aunque no de forma habitual, hago mas de consultor/arquitecto, y tal vez alguna prueba de concepto que requiera algun pequeño programa). Dicho esto... ¿ que tiene de malo en el que trabaje en una empresa de la que mencionas ? ¿ eso no me capacita para, aun dejando claro que el articulo es muy bueno, poder defender que añadir la capa del dialogo al articulo lo haria mas completo ? No se trataba de una critica negativa, no te ofendas por ello. Si, si trabajo en una empresa que hace IA y como tal, tiene herramientas que comercializa de NLU, pero me daba igual que herramienta comentaras, Watson Assistant, Google Dialogflow, o Microsoft Luis (que por otra parte, ignoro si tiene tambien la parte de dialogo o solo NLU). En el articulo, en ningun momento te dirigia especificamente a una, ni que comparases NLU, sino que a mi punto de ver, faltaba el punto de los asistentes de dialogo que existen por encima.
En cuanto a las ventajas que argumentas arriba son, muchos de ellos, discutibles y con una vision poco objetiva (y en algun caso desde mi punto de vista erroneos), pero no es mi intencion empezar un debate por cada uno de ellos, podriamos eternizarnos y aburririamos ademas al resto de la gente. Solo comentaba que echaba de menos un analisis de esos temas.
De verdad, el articulo me ha parecido muy bueno, ya te digo que yo he aprendido mucho leyendolo y ha despertado alguna inquietud...pero no te extrañe ni te ofendas cuando te digo que hecho de menos añadir en el articulo una visión también más práctica... y que es bastante habitual en el entorno que yo conozco (y usado por programadores expertos).....
No conocia el RASA Stack que mencionas en tu articulo (un NLU open-source), y lo probare cuando tenga oportunidad. Tengo curiosidad por saber si es posible que en un descarga "razonable" pueda bajarme todos los datos necesarios para trabajar off-line multi-idioma (diccionario, sinonimos, variaciones, reglas, etc....) , si es facil suministrarlo/intregrarlo con tu codigo, y por supuesto, como de efectivo es. No es facil salvar esa problematica, pero si lo hace bien, puede que incluso lo use en algun proyecto donde me baste con la capa NLU.
Me encantaria ver la libreria, siempre se aprende y se ven otras formas de hacer las cosas... tambien te animaria que vieras y usaras productos como, por ejemplo, watson assistant.. veras que NO es una NLU.... obviamente se basa en ella para reconocer el dialogo y sugerir las frases o acciones de vuelta, que es un concepto mas amplio. ,SI puedes hacer ayudas contextualizadas porque puedes pasar todo el contexto del dialogo (no solo variables, sino toda la relacion de todos nodos y intents que has atravesado para llegar ahi) o hacer un fallback a un humano, o a otra API, libreria o accion.. . yo lo que hago es tratar el dialogo con Watson Assistant, y si no me reconoce el intent porque no lo tengo implementado, entonces ya hacer NLU... ( Watson NLU, pero podria perfectamente utilizar cualquier libreria NLU ahi opensource)..... De la misma forma podria pasar una API de reconocimiento de sentimiento (ejemplo, Tone Analizer) antes de enviarlo al Watson Assistant (aunque tendria mucho mas sentido fuera, si no reconoce la frase en el dialogo, o como acumulativo del sentimiento de toda la conversacion)....
#c-11" class="content-link" style="color: rgb(14, 170, 116)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3035206/order/11">#11
Microsoft LUIS no solamente no tiene contextos, es que no tiene NLG, es decir, su plataforma solamente es un NLU que dado un utterance te indica el intent, pero las respuestas las tienes que gestionar tú.
La gestión de diálogos en SaaS está bien para pequeñas empresas. En empresas grandes, los diálogos tienen más reglas de las que sabe gestionar un proveedor en la nube, muchas de ellas dependientes de sus sistemas de Core IT, con lo cual el manejador de diálogos suele ser botkit (Node) o Microsoft Bot Framework SDK (C#, Node, Java y Python).
He usado y uso productos como Watson, DialogFlow y LUIS. Llevo haciendo bots desde el año 97 (para IRC, bots de trivial, de cine, gestores de contenido, personalidades), haciendo Inteligencia Artificial desde el 95 (en aquel entonces con Matlab y C, a día de hoy mayormente python y Tensorflow), y en los últimos 3 años casi el 100% de mi tiempo dedicado a ello con un equipo de 8 personas, y 5 bots en producción y desarrollando 3 más. De uno de ellos tienes disponible la nota de prensa y el eco en diversos medios.
Si no conoces RASA, estoy algo extrañado entonces, porque llevan 2 años y pico muy activos en todas las conferencias importantes de chatbots, New York, San Francisco, Viena, Berlín.... Alex, su CEO, es una persona brillante y le he visto ya en 3 conferencias diferentes de chatbots a lo largo del mundo, aparte de haber tenido el placer de hablar con él en dos calls. Supongo que tampoco conocerás Snips que es su competidor directo pero de origen francés, y que entra fuerte porque apuesta por un interfaz amigable.
En cuanto a lo que pesan las reglas... Mi librería para frontend, minimizada y con 26 idiomas (en lugar de los 27 que soporto en backend, porque con chino hay un problema) pesa 7.84 MB. En 7.84MB va:
- 26 idiomas con sus tokenizers y stemmers.
- Brain.js
- Implementación de matemática de vectores, matrices y descenso de gradiente
- Implementación de Logistic Regression Classifier
- Implementación de Binary Relevance Neural Network
- Importador desde Excel
- Motor de búsqueda de similares dentro de strings utilizando una implementación propia de distancia de Levensthein más rápida que las existentes (para poder buscar named entities permitiendo un margen de error por parte del usuario).
- Un parser/evaluador de javascript para condiciones complejas de contexto
- Builtin Entity Extraction completo para Inglés, Francés, Español, Portugués y Japonés (completo significa que entiende "treinta y tres marcos suizos" como el número 33 y la moneda marcos suizos), y parcial para el resto de idiomas. Las entidades que extrae son: email, ip, hashtag, números de teléfono, URL, números, ordinales, porcentajes, dimensiones (tanto SMI como imperial), edades, monedas, fechas y duraciones. La comprensión de fechas permite incluso parciales y con intervalos: https://github.com/axa-group/nlp.js/blob/master/docs/builtin-entity-extraction.md#date-extraction
- Motor NER incluyendo Enum Named Entity, Regex Named Entity, Trim Named Entity y las builtin. Además este motor hace reducción de edges, es decir, si hay entidades en colisión es capaz de reducirlas a las realmente útiles que necesita el usuario.
- Motor de NLG con templating a partir de contexto, y con condiciones a partir de contexto: para el mismo intent basándose en condiciones de negocio puede elegir respuestas diferentes que se ajusten al momento de la conversación. Una de las variables que automáticamente se inyecta al contexto es el identificador de diálogo y paso de Microsoft Bot Framework SDK, de manera que si se hace un bot con esta tecnología en todo momento podemos saber en qué punto exacto de la conversación está: si el bot está pidiendo un número de bastidor y el usuario no sabe lo que es y pide ayuda, ese intent de ayuda devolverá frases distintas basadas en el identificador de diálogo y paso, si el diálogo del número de bastidor es "/askBastidor" por poner un ejemplo, sabrá la respuesta a decir que será diferente de la respuesta si el usuario pide ayuda en otros momentos del diálogo. El templating por su parte es que las frases de la respuesta pueden incluir variables que son sustituidas por los valores en el contexto. El contexto incluído no es solamente de conversación, puede contener datos extraídos de otros sistemas, que es una limitación que sí poseen los que son en nube, y que además me parece correcta la limitación: a partir del DNI de un usuario yo obtengo sus datos de Core IT porque quiero usarlos en la conversación, pero no tengo por qué andar mandándoselos a ningún sistema de terceros.
- Estimador de lenguaje: en función de la frase estima el lenguaje para derivarla al clasificador correcto entrenado para ese lenguaje.
- Sentiment Analysis para inglés, español, francés, italiano, alemán y holandes... lo cual implica todos los diccionarios de su palabras con sus valores AFINN o Senticon.
- Gestor de Slot Filling
- Gestor de contextos
- Recognizer compatible con Microsoft Bot Framework
...
Todo eso cabe en 7.84 megas... aunque acabo de fijarme de que no está completamente minimizado, estimo que podría caber lo mismo en menos de 5 megas, esta tarde me pondré a ver por qué no minimiza del todo.
Lo que no cabe ya en 7.84 MB es el backend y el frontend, pero caben en 48 MB comprimidos en una imagen docker, y desplegables totalmente gratis en Heroku+mLab con un simple click de un botón.