web-enzyme-v2-logo-white
logo-enzyme-2-blog

Experiencias y recomendaciones de uso de IBM Watson y Google DialogFlow

Hoy en día los asistentes virtuales y, en particular los chatbots, se están convirtiendo en una commodity. En 2020 ya no clasificamos las soluciones de negocio basadas en Inteligencia Artificial y Procesamiento de Lenguaje Natural (NLP en inglés) como nice-to-have sino como must. Actualmente existe un gran abanico de opciones en el mercado con grandes players entre los que se encuentran, por citar algunos relevantes: IBM, Google, Amazon, Microsoft, SAP, etc.

El equipo de Enzyme tiene amplia experiencia en la implantación de soluciones cognitivas a medida para impulsar la innovación y el impacto en negocio en nuestros clientes. Recientemente hemos tenido la oportunidad de ejecutar dos proyectos “gemelos” (mismo alcance y contexto de negocio) con dos tecnologías referencia en el mercado de los asistentes virtuales: IBM Watson Assistant y Google DialogFlow.

A continuación, vamos a explorar las principales diferencias entre ambas tecnologías percibidas por nuestros expertos de implantación y compartidas a nivel de equipo en las sesiones de retrospectiva y mejora continua

Este artículo está dirigido a:

  • Usuarios de IBM Watson Assistant o DialogFlow, que estén planteando un cambio entre ambas tecnologías
  • Usuarios de negocio y/o técnicos que se planteen construir su primer chatbot en una de estas dos tecnologías
  • En general, a quien le interesa una primera noción de en qué ámbitos se mueven ls diferencias entre las tecnologías NLP a nivel de implantación, es decir, configuración y mantenimiento de un chatbot

Por otro lado, no analizaremos las diferencias a nivel de rendimiento del NLP como tal (cómo de bien entiende cada tecnología el lenguaje natural humano), si bien es cierto que, con el entrenamiento adecuado del chatbot, el nivel de madurez de estas tecnologías genera diferencias de rendimiento cada vez más estrechas y empiezan a imperar otros criterios de decisión

Asimismo, en este artículo arrojaremos algo de luz sobre estos nuevos criterios a tener en cuenta a la hora de elegir la tecnología más adecuada para la construcción y mantenimiento de nuestros chatbots.

 

Análisis comparativo del uso y configuración

A continuación se acompaña una relación de los puntos más destacados percibidos por nuestros expertos entre el NLP de Google DialogFlow respecto a Watson Assistant de IBM durante la fase de implantación:

  • Uno de los puntos claramente a favor de DialogFlow es la interfaz de uso (UI) de la página web de configuración (“backoffice web”).
    • Inicialmente resulta más bonita y amigable, pero en la práctica puede resultar tediosa, debido al sistema de paginación de los intents, la nula posibilidad de estructurar los nodos en árboles de diálogo, o el insalvable refresco completo de la página web ante cada cambio; la configuración y mantenimiento en DialogFlow resulta lenta y un poco tediosa, en particular cuando el número de nodos del diálogo es alto.
    • Por su parte Watson permite mover nodos y (des)intercalar bloques de nodos, (des)agrupar nodos en carpetas, y todo se produce sin refrescos de página (SPA o “single page application”) lo cual resulta en un flujo de trabajo claramente más usable y productivo.
  • DialogFlow no permite saltar de un nodo de conversación a otro, es decir, empalmar diálogos configurados en distintos nodos en una misma respuesta al usuario:
    • Esto obliga inicialmente a duplicar diálogos en algunos nodos, lo cual dificulta la configuración inicial y mantenimiento en adelante; y puede ser una fuente de errores y aumentar el tiempo de testeo.
    • Para salvar esta situación (y atender otros requerimientos), Enzyme desarrolló un orquestador para DialogFlow que facilita al equipo de diálogos simular este salto con un comando adhoc configurado en los diálogos en DialogFlow.

  • DialogFlow incluye una forma original y sencilla de incluir integraciones con varios canales de mensajería (el front-end del chatbot, lo que el usuario final utilizará para dialogar con el asistente virtual) sin tener que hacer varios diálogos o chatbot para cada uno:
    • Se incluyen algunas integraciones listas para usar con: Google Assistant, Facebook Messenger, Hangouts Chat, Line, Slack y Telegram; también permite integraciones con sistemas terceros mediante API.
    • Esto puede ser beneficioso en algunos casos, si bien las posibilidades de cada canal están “impuestas” lo que en algunos casos avanzados podría llegar a resultar limitante; Enzyme utilizó la opción genérica de API contra el orquestador para DialogFlow para poder personalizar y tener control del comportamiento multicanal del chatbot
    • Watson en este aspecto está menos desarrollado en cuanto a opciones nativas listas para usar (“out-of-the-box”) y es recomendable casi siempre gestionar la multicanalidad desde un orquestador para Watson Assistant
  • DialogFlow cuenta a su favor con una gestión incorporada de diálogos multidioma que, hoy por hoy, Watson Assistant no tiene:
    • En este sentido, Watson obliga a disponer de varios “bots” configurados en paralelo y delegar el redireccionamiento a uno u otro desde un orquestador para Watson Assistant
    • Aunque en general sí es una ventaja disponer de multidioma en los propios diálogos, no debe entenderse esto necesariamente como una limitación porque, de hecho, en algunos escenarios muy maduros de “arquitectura empresarial de chatbots” puede ser ventajoso de cara a la escalabilidad y modularidad “orgánica” de una gran solución semántica empresarial

  • DialogFlow no permite respuestas condicionales en los propios diálogos:
    • Por ejemplo si se pide la edad al usuario, no se puede dar una respuesta distinta en función de su tramo de edad en los propios diálogos de DialogFlow.
    • La solución propuesta por Google en este caso es llamar mediante un API a un sistema externo o “webhook” (DialogFlow denomina esto “fulfillment” en inglés o “entregas” en castellano), pero esto obliga a desplazar la lógica de negocio (qué contestar “comercialmente” al usuario) a un sistema externo.
  • DialogFlow no permite evaluar condiciones a la entrada de un nodo del diálogo:
    • Los nodos solo se activan cuando se cumplen unas condiciones de coincidencia con los Intents (en base a “inputs de usuario” entrenados en el Intent, que pueden incluir anotaciones de Entities).
    • Sin embargo no permite añadir, además, otras lógicas adicionales como considerar otras Entities no anotadas en el Intent, valores de variables, o el scoring del NLP sobre el Intent.
    • Esto puede limitar o hacer más complicada y elaborada la construcción de diálogos complejos o ricos en comportamiento.
  • DialogFlow permite una gestión de variables en el diálogo (“contexto”) bastante limitada:
    • Por ejemplo si se recoge la información de perfilado del usuario para registrarlo en un CRM, puede ser complicado estructurar esta información en objetos agrupados complejos, y puede ser necesario disponer de muchas variables sueltas que pueden dificultar la configuración y mantenimiento

Respecto a estos últimos 3 puntos:

    • La solución propuesta por DialogFlow para estos 3 puntos es delegar este tipo de respuestas "complicadas" de nuevo a un servicio externo webhook (“fullfillment” o “entregas”)
    • Como expertos desaconsejamos este modelo porque obliga a complicar los diálogos y desplazar la lógica de negocio (las respuestas de los diálogos) fuera de DialogFlow, lo cual puede suponer un cuello de botella para el equipo de Negocio que mantenga los diálogos ya que deberán mantenerlos en "el código" del orquestador o sistema tercero similar.

Todos los puntos indicados sí están soportados de forma nativa en Watson Assistant.

 

Conclusiones:

  • DialogFlow es recomendable para:
    • Diálogos/chatbots relativamente sencillos, tipo "QnA" (pares pregunta y respuesta para “preguntas frecuentes” o FAQs) o flujos de soporte (p.ej. hacer una reserva) sencillos y con ciertas limitaciones.
    • Permite apoyarse en un servicio externo (webhook) pero entendemos que debería ser algo excepcional para garantizar la escalabilidad y mantenimiento.
    • En caso de un chatbot sencillo, sí es útil el hecho de que dispone de "Integraciones" listas para activar y conectar con los canales más populares (Facebook Messenger, Slack, etc. pero NO WhatsApp); pero en este caso el resultado final queda limitado a las opciones de DialogFlow para cada canal. 
    • La gestión de diálogos multidioma sí está soportado de forma nativa en DialogFlow (en los propios diálogos)

  • Watson Assistant por su parte:
    • Es, en general, la opción más recomendable para montar chatbots 'industriales' donde el nivel de complejidad de los diálogos es medio-alto: número de nodos ("número de FAQs"), profundidad y grado de ramificación de los diálogos, comportamiento 'rico' en los diálogos (cambiante según condicionado de variables recogidas del perfil de usuario o la información suministrada), etc. 
    • Esto contribuye claramente en favor también del mantenimiento, escalabilidad e integración con otros chatbots/servicios semánticos a medio y largo plazo.

Para acabar, os invitamos a asistir al próximo webinar que vamos a realizar jueves 21 de mayo dónde revisaremos el panorama de chatbots actual poniendo especial atención a los asistentes de atención al cliente externos e internos, explicaremos cómo se puede mejorar la inteligencia de un chatbot y pondremos ejemplos de casos reales que ilustren estos puntos.  ¡Puedes registrarte aquí

Posts relacionados
¡Comparte con tus contactos!
   

Comenta este artículo...

ebook Blockchain

Suscríbete y no te pierdas ninguna novedad

New call-to-action

¡Comparte con tus contactos!

   
New call-to-action