Automatización en tiempo real

En este tutorial práctico crearemos una sencilla aplicación de clasificación automatizada que utiliza Communications Mining para categorizar los correos electrónicos entrantes en tiempo real. Crearemos un flujo de trabajo de extremo a extremo que puede utilizarse como punto de partida para tu propia automatización de Communications Mining, y veremos en detalle cómo utilizar la API de transmisión en tiempo real.

Requisitos previos

Conceptos básicos de Communications Mining

Antes de comenzar este tutorial, asegúrate de estar familiarizado con los conceptos y la terminología de Communications Mining y los conceptos básicos de la API de Communications Mining.

Acceso a Communications Mining

Necesitas los siguientes permisos para seguir el tutorial. Puedes comprobar tus permisos actuales en la página Administrar cuenta.

Proyecto	Descripción	PERMISSIONS
reinfer-sandbox	Contiene el conjunto de datos reinfer-sandbox/integration-tutorial preanotado utilizado en este tutorial.	"Ver fuentes", "Ver etiquetas"
Su proyecto de desarrollo	Durante tu incorporación, deberías haber recibido acceso a un proyecto que puedas utilizar como tu entorno de desarrollo.	"Administrador de transmisiones", "Consumir transmisiones", "Ver fuentes", "Ver etiquetas"

Póngase en contacto con el soporte técnico si no está seguro de qué proyecto puede utilizar para el desarrollo, o si necesita los permisos "Ver fuentes" y "Ver etiquetas" en reinfer-sandbox.

Datos del tutorial

En este tutorial, utilizaremos datos preanotados. Para hacer una copia del conjunto de datos reinfer-sandbox/integration-tutorial preanotado, crea un nuevo conjunto de datos en tu proyecto de desarrollo utilizando la opción "Copiar una taxonomía existente". Puedes encontrar instrucciones sobre cómo hacerlo aquí.

Dado que tu nuevo conjunto de datos contiene datos anotados, el modelo comenzará a entrenarse de inmediato. Puedes realizar un seguimiento del estado de entrenamiento del modelo en la barra de estado del conjunto de datos. Una vez hecho esto, las métricas de rendimiento de cada etiqueta aparecerán en la página Validación, y aparecerá una nueva versión del modelo en la página Modelos.

Figura 1. Página de validación que muestra el rendimiento de la etiqueta

Figura 2. Página de modelos que muestra la nueva versión del modelo

Diseña tu aplicación

Ahora que estás familiarizado con los requisitos previos, comencemos a crear nuestro flujo de trabajo de extremo a extremo. En esta sección discutiremos el diseño de una aplicación de triaje automatizada simple y su integración con Communications Mining. En las siguientes secciones, aprenderemos sobre la API de transmisión que impulsará nuestra automatización. Por último, construiremos nuestra aplicación basándonos en el diseño aquí, y la probaremos utilizando datos preanotados.

Visión general del caso de uso

Nos centraremos en un caso de uso típico de soporte por correo electrónico como punto de partida para nuestro diseño:

• Un buzón de soporte de Outlook recibe un gran número de correos electrónicos de clientes a diario.
• Un equipo de clasificación convierte cada correo electrónico en un ticket de soporte. Esto requiere rellenar los campos del ticket con información del correo electrónico (por ejemplo, un ID de cliente). A continuación, cada ticket se añade a la cola del flujo de trabajo correspondiente.
• Los tickets en las colas del flujo de trabajo son procesados continuamente por un equipo de atención al cliente.
  Figura 3. Un caso de uso sencillo de asistencia por correo electrónico
  

  

  
  

Aquí hay dos oportunidades de automatización: el paso de clasificación y el paso de procesamiento. Este tutorial demostrará cómo automatizar el paso de clasificación utilizando Communications Mining para extraer los campos necesarios del correo electrónico y asignar el correo electrónico a una cola de flujo de trabajo.

Nota: Aunque el paso de procesamiento no se trata en este tutorial, se basa en los datos recopilados durante el paso de clasificación, por lo que tienes la opción de añadirlo después de crear la aplicación de clasificación de muestra.

Diseño de extremo a extremo

Echemos un vistazo al siguiente diagrama, que esboza el diseño de extremo a extremo que construiremos:

Figura 4. Diseño de automatización de extremo a extremo

Debido a la conexión activa entre el servidor de Exchange y Communications Mining, Communications Mining puede servir como fuente de datos para tu aplicación. De esta manera, no se necesita una conexión independiente entre tu aplicación y el servidor de Exchange. Tu aplicación sondeará continuamente Communications Mining en busca de nuevos correos electrónicos y los recibirá junto con sus etiquetas previstas y campos generales. (Suponemos que ningún usuario está trabajando directamente en la bandeja de entrada del buzón de correo al mismo tiempo que se ejecuta tu aplicación; de lo contrario, tendrías que tener en cuenta los conflictos entre tu aplicación y los usuarios del buzón de correo).

Tu aplicación consultará a Communications Mining y, para cada correo electrónico, comprobará si las etiquetas y los campos generales necesarios están presentes en la respuesta de la API. En caso afirmativo, se creará un ticket en la cola de flujo de trabajo adecuada. Si no es así, realizará una segunda solicitud de API a Communications Mining para marcar el correo electrónico como una excepción "sin predicción". Del mismo modo, debería haber una forma de que los usuarios que procesan los tickets informen de los tickets mal categorizados para que los correos electrónicos correspondientes puedan marcarse en Communications Mining como una excepción de "predicción incorrecta". (El mantenedor del modelo revisará y anotará ambos tipos de excepción para mejorar el rendimiento del modelo).

Partes del diseño (que se muestran en el diagrama con un contorno punteado) estarán fuera del alcance de este tutorial. En un escenario de la vida real, estos pasos, por supuesto, no deben omitirse:

• Utilizaremos los datos existentes en la plataforma en lugar de configurar una conexión EWS activa.
• Los datos vienen preanotados, por lo que no necesitaremos entrenar un modelo.
• No diseñaremos un bucle de comentarios para las excepciones de "predicción incorrecta", ya que el diseño depende de las capacidades del sistema donde se procesan los tickets.

Incorporación de datos

La opción recomendada para obtener datos de correo electrónico en Communications Mining es utilizar el conector EWS de Communications Mining, pero también hay otras opciones disponibles. Dado que utilizamos datos que ya están en la plataforma, la configuración de la ingestión de datos no forma parte de este tutorial. Puedes obtener más información sobre todas las opciones de ingestión de datos disponibles aquí.

Lógica empresarial

Nos gustaría automatizar este proceso:

Un equipo de clasificación convierte cada correo electrónico en un ticket de soporte. Esto requiere rellenar los campos del ticket con información del correo electrónico (por ejemplo, un ID de cliente). A continuación, cada ticket se añade a la cola del flujo de trabajo correspondiente.

Por el bien de este tutorial, supongamos que nuestras colas de flujo de trabajo son "Renovación", "Cancelación", "Administrador" y "Urgente". Correos electrónicos relacionados con tareas de renovación, cancelación y administración (p. ej. cambios de dirección) deben ir a las colas respectivas, mientras que todos los correos electrónicos urgentes deben ir a la cola "Urgente", independientemente del tema.

Supongamos también que cada correo electrónico puede contener un ID de cliente (ya sea en el asunto o en el cuerpo del correo electrónico). El ID de cliente debe extraerse para que pueda utilizarse al crear un ticket desde el correo electrónico. Pero como los clientes a veces se olvidan de incluir el ID de cliente, queremos que este campo sea opcional para que se pueda crear un ticket incluso si no hay un ID de cliente presente.

Figura 5. Comentario revisado con la etiqueta "Cancelación" asignada y el campo general "ID de cliente" extraído

Para poder clasificar los correos electrónicos en las cuatro colas de flujo de trabajo, el modelo se ha entrenado para predecir las etiquetas "Renovación", "Cancelación", "Administrador" y "Urgente". Para extraer el ID de cliente, se ha configurado un campo general "ID de cliente". (Communications Mining viene con muchos tipos de campos generales prediseñados; se pueden añadir más tipos de campos generales en función de las necesidades de tu integración específica. Puede ver una lista de los campos generales disponibles actualmente aquí y obtener más información sobre cómo solicitar nuevos tipos de campos generales aquí).

Ahora podemos crear una asignación entre las etiquetas predichas recibidas de Communications Mining y la cola del flujo de trabajo en la que debe ir el correo electrónico:

IF number of labels == 0 THEN put email into "Uncategorised" queue
IF one of labels is "Urgent" THEN put email into "Urgent" queue
ELSE
    IF number of labels == 1 THEN put email into the respective queue
    ELSE put email into "Uncategorised" queue

Hemos tomado algunas decisiones por el bien del tutorial:

• Además de las cuatro colas de flujo de trabajo existentes, hay una cola especial "Sin categorizar". Si el modelo no puede proporcionar una predicción, colocamos el correo electrónico allí para que se procese manualmente. Alternativamente, podríamos haber elegido una cola existente que debería tratar con todos los correos electrónicos no categorizados, por ejemplo, "Administrador".
• Si un correo electrónico tiene más de una etiqueta del conjunto de ["Renewal", "Cancellation", "Admin"], significa que contiene varias solicitudes. Elegimos poner estos correos electrónicos en la cola "Sin categorizar", quizás porque no esperamos recibir muchos de ellos. Alternativamente, podríamos haber creado una cola de "Solicitudes complejas".

En un escenario de la vida real, debes basar tales decisiones en los requisitos específicos de tu caso de uso.

Entrenamiento de modelos

Para consultar las predicciones de un modelo, es necesario tener un modelo entrenado. Un modelo se entrena anotando algunos de los datos que has ingerido. Dado que se requieren varias horas de anotación para producir un modelo que funcione bien, utilizaremos datos preanotados en este tutorial para que no tengas que entrenar tu propio modelo.

En un escenario de la vida real, un entrenador de modelos debe tener un buen conocimiento del dominio de los datos. Por ejemplo, el usuario de un buzón de soporte sería un buen entrenador de modelos para etiquetar los datos procedentes de ese buzón. El entrenamiento debe realizarse con cuidado para producir un modelo que funcione bien y no esté sesgado. Para ello, Communications Mining proporciona recursos de formación y ofrece talleres de formación práctica.

Manejo de excepciones

Incluso un modelo con buen rendimiento ocasionalmente proporcionará resultados incorrectos, ya sea al no predecir una etiqueta o al predecir la etiqueta incorrecta. Una de las mejores formas de mejorar el modelo es anotar los correos electrónicos en los que el modelo no funciona bien. Por este motivo, queremos tener un bucle de comentarios para estos correos electrónicos:

Para cada correo electrónico, tu aplicación comprueba si las etiquetas obligatorias y los campos generales están presentes. En caso afirmativo, crea un ticket en la cola de flujo de trabajo adecuada. Si no es así, realiza una segunda solicitud de API a Communications Mining para marcar el correo electrónico como una excepción "sin predicción". Del mismo modo, debería haber una forma de que los usuarios que procesan los tickets informen de los tickets mal categorizados para que los correos electrónicos correspondientes puedan marcarse en Communications Mining como una excepción de "predicción incorrecta".

Nuestro diseño muestra bucles de comentarios para ambos tipos de excepciones.

Sistemas posteriores

Nuestro diseño muestra las colas de flujo de trabajo de forma abstracta. En realidad, podrías estar enviando los correos electrónicos directamente a una plataforma CRM, utilizar un agente de mensajes como Kafka, o incluso simplemente mover los correos electrónicos de la carpeta de la bandeja de entrada a una subcarpeta. Para los fines de este tutorial, haremos una simulación de las colas, pero te recomendamos que desarrolles tu integración de prueba de extremo a extremo.

Comprender la API de transmisión

Para recuperar los correos electrónicos entrantes junto con las etiquetas previstas y los campos generales extraídos, utilizaremos la API de transmisión que te permite definir una secuencia de comentarios basada en un conjunto de datos, una versión del modelo anclada y filtros de comentarios opcionales, y para iterar a través de ellos en una forma con estado.

Cada resultado de la respuesta de la secuencia contendrá un comentario, una lista de etiquetas previstas y una lista de campos generales. Esto se pasa como una estructura JSON como se ve a continuación:

{
"comment": {...},
"entities": [...],
"labels": [...],
    ...
}

La siguiente sección explica cómo interpretar correctamente las etiquetas predichas en cada respuesta de flujo.

Puntuaciones de umbrales de confianza

Puntuaciones de confianza

El punto final de la secuencia devolverá las etiquetas predichas junto con una puntuación de confianza (un número entre 0 y 1). Por ejemplo, el siguiente fragmento sería para predicciones de "Cancelación" y "Administrador" con confianzas de aproximadamente 0,84 y 0,02 respectivamente:

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

Para interpretar correctamente dicho resultado, debes determinar la puntuación de confianza mínima en la que tratarás la predicción como diciendo "sí, se aplica la etiqueta". A este número lo llamamos umbral de puntuación de confianza.

Precisión y recuperación

Para entender los umbrales de confianza, debes estar familiarizado con los términos precisión y recuperación. Puedes encontrar una explicación de estos términos en nuestras páginas de soporte. Brevemente, una alta precisión se relaciona con una baja tasa de falsos positivos (es decir, es más probable que sus resultados sean precisos), y una alta recuperación se relaciona con una baja tasa de falsos negativos (es decir, es menos probable que se pierda resultados relevantes).

Umbral de confianza

El umbral de confianza para una etiqueta corresponde a un equilibrio específico entre precisión y recuperación. A menos que tu modelo funcione perfectamente, tener una alta precisión sacrificará algo de recuperación y, por el contrario, tener una alta recuperación sacrificará algo de precisión. Estas compensaciones se visualizan como una curva de recuperación de precisión para cada etiqueta en la página Validación.

Figura 6. Curva de recuperación de precisión de una etiqueta

Con el control deslizante interactivo, puedes encontrar rápidamente el umbral deseado: mueve el control deslizante hacia la derecha para optimizar la precisión, o hacia la izquierda para optimizar la recuperación, hasta que encuentres la precisión y la recuperación que coincidan con los requisitos de tu aplicación. El valor de umbral mostrado será el umbral deseado. Si quieres obtener más información sobre la funcionalidad de la página de validación, consulta las páginas de soporte.

Nota:

Si observas la página Validación, es posible que notes que las formas de las curvas de recuperación de precisión son diferentes para cada etiqueta. Esto le da una pista sobre cómo elegiremos los umbrales: elegiremos un umbral individual para cada etiqueta. Esto es especialmente importante en las aplicaciones de automatización en las que se debe garantizar el mejor rendimiento.

Umbrales de ejemplo

Para nuestra aplicación de muestra, elegiremos una compensación equilibrada entre precisión y recuperación para nuestras etiquetas "Renovación", "Cancelación" y "Administrador", y optimizaremos la recuperación para la etiqueta "Urgente" (para que sea menos probable que perder correos electrónicos urgentes). (Ten en cuenta que, debido a las continuas mejoras en el rendimiento ML subyacente, en el momento en que estés realizando este tutorial, los valores de precisión y recuperación en el umbral seleccionado pueden ser ligeramente diferentes de los que se muestran aquí).

Figura 7. Precisión y recuperación de etiquetas de administrador

Figura 8. Precisión y recuperación de la etiqueta de cancelación

Figura 9. Precisión y recuperación de la etiqueta de renovación

Figura 10. Precisión y recuperación de etiquetas urgentes

Usaremos los siguientes valores de umbral para el resto del tutorial.

Admin: 0.898 (corresponds to 100% precision at 100% recall)
Cancellation: 0.619 (corresponds to 100% precision at 100% recall)
Renewal: 0.702 (corresponds to 100% precision at 100% recall)
Urgent: 0.179 (corresponds to 83% precision at 100% recall)

Ahora podemos aplicar los umbrales a nuestro ejemplo. La etiqueta "Cancelación" se aplica desde 0.8374786376953125 > 0.619. La etiqueta "Administrador" no se aplica desde 0.0164003014564514 < 0.898.

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

Para facilitar este proceso, la API de Streams te permite especificar los umbrales de tus etiquetas en la configuración de Stream. Si se especifica, solo se devuelven las etiquetas con valores por encima de su umbral.

En un escenario de la vida real, el rendimiento objetivo de recuperación de precisión se decidirá por la combinación de los requisitos empresariales y el rendimiento del modelo histórico. Por ejemplo, si una etiqueta ha alcanzado históricamente un 85 % de precisión con un 55 % de recuperación, puedes decidir invertir más tiempo en entrenarla hasta un 90 % de precisión con un 55 % de recuperación. A continuación, fijarás la nueva versión del modelo, elegirás nuevos umbrales y actualizarás la configuración de tu aplicación.

Crea tu aplicación

Una vez finalizado nuestro diseño, estamos listos para comenzar a construir nuestra aplicación.

Anclar su modelo

Ve a la página Modelos y fija el modelo haciendo clic en el botón "Guardar". Una vez anclado el modelo, puedes empezar a acceder a él a través de la API.

Nota:

Si quieres seguir esta parte del tutorial utilizando un conjunto de datos anotado diferente, debes asegurarte de que está suficientemente anotado. En particular, un conjunto de datos con solo unos pocos ejemplos anotados producirá un modelo que no devolverá predicciones para la mayoría de los comentarios.

Figura 11. Anclar la versión del modelo haciendo clic en el botón "Guardar"

Configuración de transmisión

En la mayoría de los casos, basta con especificar el nombre de la transmisión, el nombre del conjunto de datos y la versión del modelo, y las etiquetas que te interesan. Para obtener una lista completa de opciones, consulta la referencia.

Para cada etiqueta, debes especificar un umbral. Consulta la sección anterior de este tutorial sobre cómo elegir umbrales de etiquetas.

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "stream": {
        "name": "<my-stream-name>",
        "model": {
          "version": <my-model-version>,
          "label_thresholds": [
            {
              "name": [
                "Parent Label",
                "Child Label"
              ],
              "threshold": <my-label-threshold>
            },
            {
              "name": [
                "Label Without Parent"
              ],
              "threshold": <my-label-threshold>
            }
          ]
        }
      }
    }'

Bucle de recuperación y avance

Ahora puedes utilizar tu transmisión para obtener comentarios de Communications Mining. Ten en cuenta que los tamaños de lote muy bajos (como la obtención de lotes de 1 comentario) afectarán a la velocidad a la que se obtienen los comentarios.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/fetch' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "size": <my-stream-batch-size>
    }'

La posición inicial de la transmisión se establece en su hora de creación. Para fines de desarrollo, suele ser útil recuperar los comentarios que se crearon antes de la transmisión. Para ello, puedes establecer la transmisión en una marca de tiempo específica.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/reset' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "to_comment_created_at": "<YYYY-MM-DDTHH:MM:SS>"
    }'

Si vuelves a ejecutar la solicitud fetch ahora, se recuperará a partir de la misma posición. Para recuperar el siguiente lote de comentarios, debes confirmar el lote anterior con una solicitud advance . En la solicitud advance , debes proporcionar un sequence_id que puedes encontrar en tu respuesta fetch .

El bucle fetch-and-advance garantiza que no omitas comentarios accidentalmente si tu aplicación falla durante el procesamiento. Ten en cuenta que tu aplicación debe ser capaz de ver un comentario varias veces en caso de procesar un comentario con éxito pero fallar en el paso de avance.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/advance' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "sequence_id": "<my-sequence-id>"
    }'

Ten en cuenta que debes proporcionar el nombre del conjunto de datos en todas las solicitudes de la API que utilicen la transmisión; esto se debe a que las transmisiones se encuentran en el ámbito de los conjuntos de datos.

Resultados del proceso

La respuesta contendrá comentarios, etiquetas previstas y campos generales, como se describe en las páginas Comentarios y Etiquetas y campos generales . Consulta estas páginas para entender cómo analizar la respuesta.

Manejo de excepciones

Si tu aplicación permite a los usuarios etiquetar elementos que se predijeron incorrectamente, puedes utilizar el punto final de excepción para etiquetar el comentario correspondiente como una excepción en la plataforma. El nombre de la excepción estará disponible como filtro en el conjunto de datos, de modo que un entrenador de modelos pueda revisar y anotar excepciones para mejorar el modelo.

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/exceptions' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "exceptions": [
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        },
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        }
      ]
    }'

¡Listo!

Enhorabuena, ha completado el tutorial de automatización de Communications Mining. Por supuesto, tu propia aplicación de automatización puede ser diferente de lo que se trata aquí. Póngase en contacto con el soporte técnico si tiene alguna pregunta.