Arquitectura de un modelo de aprendizaje automático sin servidores

Last reviewed 2017-12-21 UTC

En esta serie de artículos, se explora la arquitectura de un modelo de aprendizaje automático (AA) sin servidores para agregar metadatos a los tickets de asistencia antes de que lleguen a un agente de atención al cliente. En esta serie, se muestran tecnologías sin servidores para controlar la creación de tickets a gran escala.

Cuando los agentes toman decisiones comerciales pertinentes, necesitan acceso a los datos. Los registros son una buena fuente de estadísticas básicas, pero agregar datos enriquecidos cambia las reglas del juego. Implementar este sistema puede ser difícil. En esta serie, se ofrece una solución posible.

Requisitos y arquitectura

Administrar tickets de asistencia entrantes puede ser un desafío. Antes de que un agente pueda comenzar a trabajar en un problema, debe realizar las siguientes acciones:

  • Comprender el contexto del ticket de asistencia
  • Determinar la gravedad del problema para el cliente
  • Decidir cuántos recursos usar para resolver el problema

Por lo general, un agente de atención al cliente recibe información mínima del cliente que abrió el ticket de asistencia. A menudo, con algunos intercambios de ida y vuelta con el cliente, se reúnen detalles adicionales. Si agregas inteligencia automatizada basada en datos de los tickets, puedes ayudar a los agentes a tomar decisiones estratégicas cuando atienden solicitudes de asistencia.

Por lo general, el usuario registra un ticket después de completar un formulario que contiene varios campos. Para este caso práctico, supón que ninguno de los tickets de asistencia se enriqueció con el aprendizaje automático. También supón que el sistema de asistencia actual estuvo procesando tickets durante algunos meses.

Para comenzar a enriquecer los tickets de asistencia, debes entrenar un modelo de AA que use datos etiquetados preexistentes. En este caso, el conjunto de datos de entrenamiento consta de datos históricos que se encuentran en tickets de asistencia cerrados. Los datos que necesitas residen en dos tipos de campos:

  • Campos de entrada, que contienen los datos de formularios que el usuario debe completar
  • Campos de destino, que se completan cuando se procesa el ticket

Cuando se combinan, los datos en estos campos son ejemplos que sirven para entrenar un modelo capaz de hacer predicciones precisas. Las predicciones en este caso práctico incluyen cuánto tiempo permanecerá abierto el ticket y qué prioridad se le debe asignar.

En esta serie, se exploran cuatro enriquecimientos de AA para lograr los siguientes objetivos:

  • Analizar las opiniones según la descripción del ticket
  • Etiquetar automáticamente según la descripción del ticket
  • Predecir durante cuánto tiempo permanecerá abierto el ticket
  • Predecir la prioridad que se debe asignar al ticket

Durante el flujo de trabajo de enriquecimiento de AA, se realizan las siguientes acciones:

  1. Un usuario crea un ticket.
  2. La creación de tickets activa una función que llama a los modelos de aprendizaje automático para hacer predicciones.
  3. Los datos del ticket se enriquecen con la predicción que muestran los modelos de AA.
  4. El agente de atención al cliente usa el ticket de asistencia enriquecido para tomar decisiones eficientes.

En el siguiente diagrama, se ilustra este flujo de trabajo.

Flujo de trabajo de enriquecimiento de AA

Sistema de tickets

Ya sea que compiles el sistema desde cero, uses un código abierto o compres una solución comercial, en este artículo, se hacen las siguientes suposiciones:

  • Una IU de marca orientada al cliente genera tickets de asistencia. No todas las herramientas de asistencia ofrecen esa opción, por lo que puedes crear una mediante una página de formulario simple.
  • Se puede acceder a la herramienta de asistencia de terceros a través de una API de RESTful que puede crear un ticket. El sistema usa esta API para actualizar el backend del ticket.
  • Cuando se producen eventos, el sistema actualiza la IU del cliente personalizada en tiempo real.

Firebase es una excelente opción para este tipo de implementación por las siguientes razones:

  • Firebase es una base de datos en tiempo real que un cliente puede actualizar y muestra actualizaciones en tiempo real para otros clientes suscritos.
  • Firebase puede usar Cloud Functions para llamar a una API externa, como la que ofrece la plataforma de asistencia.
  • Firebase funciona en plataformas de escritorio y de dispositivos móviles, y se puede desarrollar en varios lenguajes. Cuando Firebase experimenta conexiones a Internet poco confiables, puede almacenar datos en caché de forma local.

Tecnología sin servidores y activación basada en eventos

La “tecnología sin servidores” se puede definir de varias maneras, pero la mayoría de las descripciones incluyen las siguientes suposiciones:

  • Los servidores deben ser un concepto invisible y distante para los clientes.
  • Por lo general, las funciones activadas por eventos realizan las acciones.
  • Las funciones ejecutan tareas que suelen ser de corta duración (duran unos pocos segundos o minutos).
  • La mayoría de las veces, las funciones tienen un solo propósito.

Cuando se combinan, Firebase y Cloud Functions optimizan DevOps porque minimizan la administración de la infraestructura. El flujo operativo funciona de la siguiente manera:

  1. Crea un evento de Cloud Function basado en las actualizaciones de la base de datos de Firebase.
  2. El cliente escribe un ticket en la base de datos de Firebase.

  3. Un activador de Cloud Functions realiza las siguientes tareas principales:

    • Ejecuta predicciones mediante algoritmos de aprendizaje automático implementados.
    • Actualiza la base de datos en tiempo real de Firebase con datos enriquecidos.
    • Crea un ticket en el sistema de asistencia con los datos consolidados.

Enriquecimiento de tickets de asistencia

Puedes agrupar el etiquetado automático, el análisis de opiniones, la predicción de prioridad y la predicción del tiempo de resolución en dos categorías. Estas categorías se basan en la forma en que se realizan las tareas de aprendizaje automático:

  • El análisis de opiniones y el etiquetado automático usan las API de aprendizaje automático que Google ya entrenó y compiló. Los modelos entrenados previamente pueden ofrecer menos personalización que los que compilas tú mismo, pero están listos para usar.
  • Para predecir la prioridad y el tiempo de resolución de tickets, debes compilar un modelo o usar los estándares y entrenarlos con datos personalizados, como las entradas y los campos de destino.

Análisis de opiniones y etiquetado automático

Cuando se registra un ticket de asistencia, es posible que los agentes quieran saber cómo se siente el cliente. La ejecución de un análisis de opiniones en la descripción del ticket ayuda a proporcionar esta información.

También es importante tener una idea general de lo que se menciona en el ticket. Cuando se crea un ticket de asistencia, el cliente suele proporcionar algunos parámetros de una lista desplegable, pero a menudo se agrega más información cuando se describe el problema. El agente puede acotar el tema mediante una herramienta que identifica las palabras más importantes en la descripción. Este proceso se define como etiquetado automático con comodín.

Ambas soluciones son genéricas y fáciles de describir, pero son difíciles de compilar desde cero. A gran escala, usar un modelo potente y entrenado para el análisis de textos es una clara ventaja. Este modelo reduce el tiempo de desarrollo y simplifica la administración de la infraestructura.

Una buena solución para ambas ideas de enriquecimiento es la API de Cloud Natural Language. Se puede acceder fácilmente a esta API desde Cloud Functions como una API de RESTful. La API de Natural Language es un modelo previamente entrenado que usa conjuntos de datos extendidos de Google capaces de realizar varias operaciones:

  • Análisis de opiniones
  • Análisis de entidades con cálculo de relevancia
  • Análisis sintáctico

En este artículo, se aprovecha el análisis de opiniones y de entidades. Para controlar el etiquetado automático, se conservan las palabras con una relevancia por encima del umbral que define el cliente.

Si deseas un modelo que pueda mostrar etiquetas específicas automáticamente, debes entrenar y crear de manera personalizada un modelo de procesamiento de lenguaje natural (PLN). Este enfoque está abierto a cualquier etiquetado, ya que el objetivo es analizar con rapidez la descripción, no categorizar el ticket de forma completa.

Predicción de la prioridad y el tiempo de resolución de los tickets

El tiempo de resolución de un ticket y su estado de prioridad dependen de las entradas (campos de ticket) específicas de cada sistema de asistencia. En consecuencia, no puedes usar un modelo previamente entrenado como lo hiciste para el etiquetado y el análisis de opiniones del idioma inglés; debes entrenar tus propias funciones de aprendizaje automático.

Si bien el flujo de trabajo para predecir el tiempo de resolución y la prioridad es similar, las dos acciones representan dos tipos de valores diferentes:

  • El tiempo de resolución es un valor continuo.
  • La prioridad tiene varias opciones predefinidas en función del sistema de asistencia.

Elige una arquitectura que te permita realizar las siguientes acciones:

  • Entrenar modelos con datos personalizados
  • Implementar modelos y hacer que estén disponibles como una API de RESTful para la función de Cloud Functions
  • Escalar modelos según sea necesario

Cloud Datalab es una herramienta administrada por Google que ejecuta notebooks de Jupyter en la nube. Cloud Datalab se integra en otros productos de Google Cloud Platform (GCP). Cloud Datalab también puede ejecutar ML Workbench (puedes ver algunos ejemplos de notebooks aquí ), una biblioteca de Python que facilita el uso de dos tecnologías clave: TensorFlow y AI Platform.

Estas son las características de TensorFlow:

  • Los grafos compilados por TensorFlow (ejecutables) son portátiles y pueden ejecutarse en varios hardware.
  • La API de Estimator te permite usar modelos personalizados o compilados previamente. En este artículo, se usa ML Workbench, que hace que conceptos como asignar datos a un modelo sean accesibles.
  • La función Experimento te permite tomar un modelo, entrenarlo y evaluarlo en un entorno distribuido.

AI Platform es un servicio administrado que puede ejecutar grafos de TensorFlow. El servicio facilita las siguientes tareas de aprendizaje automático:

  • El entrenamiento de modelos en un entorno distribuido con DevOps mínimas
  • La integración con otros productos de GCP
  • El ajuste de hiperparámetros para mejorar el entrenamiento de modelos
  • La implementación de modelos como API de RESTful para realizar predicciones a gran escala

ML Workbench usa la API de Estimator en segundo plano, pero simplifica gran parte del código estándar cuando se trabaja con problemas de predicción de datos estructurados. La API de Estimator agrega varias opciones interesantes, como la combinación de atributos, la discretización para mejorar la precisión y la capacidad de crear modelos personalizados. Sin embargo, nuestro caso práctico actual solo requiere un regresor y un clasificador, con poca necesidad de ingeniería de atributos. Este enfoque se adapta bien a las capacidades de ML Workbench, que también admiten el entrenamiento distribuido, la lectura de datos por lotes y el escalamiento vertical según sea necesario mediante AI Platform.

Según qué tan lejos quieres llegar en TensorFlow y la codificación, puedes elegir entre ML Workbench o la API de Estimator de TensorFlow. El resto de esta serie se centra en ML Workbench porque el objetivo principal es aprender a llamar a modelos de AA en un entorno sin servidores. En la serie, también se proporciona información adicional sobre TensorFlow y AI Platform.

Sincronización con la plataforma de asistencia

La sincronización entre los dos sistemas fluye en ambas direcciones:

Saliente
Cuando un cliente abre o actualiza un ticket, Cloud Functions activa una escritura de Firebase. Cloud Functions también actualiza la plataforma de asistencia de terceros mediante una llamada a la API de RESTful.
Entrante
Cuando un agente usa la plataforma de asistencia para actualizar un ticket, la plataforma activa su propio evento y llama a un controlador HTTP de Cloud Functions, que actualiza Firebase y la IU del cliente en tiempo real.

Arquitectura

La arquitectura tiene el siguiente flujo:

  1. Un usuario escribe un ticket en Firebase, que activa una función de Cloud Functions.

  2. La función de Cloud Functions llama a 3 extremos diferentes para enriquecer el ticket:

    • Un extremo de AI Platform, en el que la función puede predecir la prioridad
    • Un extremo de AI Platform, en el que la función puede predecir el tiempo de resolución
    • La API de Natural Language para realizar análisis de opiniones y relevancia de palabras

  3. Para cada respuesta, la función de Cloud Functions actualiza la base de datos en tiempo real de Firebase.

  4. Luego, la función de Cloud Functions crea un ticket en la plataforma de asistencia mediante la API de RESTful.

En el siguiente diagrama, se ilustra esta arquitectura.

Arquitectura sin servidores

Próximos pasos