Crear la estructura de taxonomía

Uno de los factores más fundamentales que determinarán el rendimiento de tu modelo, así como lo bien que cumple tus objetivos empresariales, es la estructura de tu taxonomía, incluido lo que captura cada una de las etiquetas que contiene.

Por lo tanto, es importante pensar en la estructura de taxonomía de destino antes del entrenamiento del modelo. Dicho esto, debes tener un grado de flexibilidad para adaptarlo, expandirlo y mejorarlo según sea necesario a medida que avanzas en el entrenamiento. Esto es lo que llamamos el enfoque de entrenamiento basado en datos.

En última instancia, las etiquetas de la taxonomía y los ejemplos de entrenamiento proporcionados para cada etiqueta deben crear una representación precisa y equilibrada del conjunto de datos en su conjunto. Pero cada etiqueta también debe ser valiosa, al representar claramente de alguna manera los mensajes para los que se predice.

Si las etiquetas se utilizan para capturar conceptos muy amplios, vagos o confusos, no solo es más probable que tengan un mal rendimiento, sino que es menos probable que proporcionen valor empresarial. Esto puede ser para proporcionar información útil sobre ese concepto, o para ayudar a que un proceso se automatice total o parcialmente en sentido descendente.

Ejemplo de una estructura de taxonomía

Este es un ejemplo de una taxonomía de alto nivel con etiquetas típicas aplicables en varios casos de uso o industrias. No todos serán aplicables a tu modelo.

Ejemplo de un caso de uso real

Una empresa recibe cada año millones de correos electrónicos en diferentes bandejas de entrada de los clientes sobre una multitud de problemas, consultas, sugerencias, quejas, etc.

Esta empresa decide aumentar su eficiencia operativa, la estandarización de procesos y la visibilidad de lo que sucede en su negocio convirtiendo automáticamente estos correos electrónicos de los clientes en tickets de flujo de trabajo. Estos pueden ser rastreados y accionados, utilizando procesos específicos y dentro de los plazos establecidos.

Para ello, deciden utilizar la plataforma para interpretar estas comunicaciones entrantes no estructuradas y proporcionar una clasificación con respecto al proceso y subproceso con el que se relaciona el correo electrónico. Esta clasificación se utiliza para actualizar el ticket de flujo de trabajo que se creará automáticamente utilizando un servicio de automatización, y garantizar que se enruta al equipo o individuo correcto.

Para garantizar que este caso de uso tenga el mayor éxito posible, y para minimizar el número de excepciones (clasificaciones incorrectas o correos electrónicos que la plataforma no puede clasificar con confianza), cada correo electrónico entrante debe recibir una predicción segura que tenga una etiqueta principal y una etiqueta secundaria, es decir, [Proceso X] > [Subproceso Y].

Estructurar la taxonomía

Dado que el objetivo es clasificar cada correo electrónico entrante con un [Proceso] y un [Subproceso], cada etiqueta de la taxonomía debe ajustarse a este formato:

Qué deben capturar las etiquetas

En este caso de uso, cualquier correo electrónico que no tenga una predicción segura tanto para una etiqueta principal como para una secundaria podría ser una excepción, enviado para revisión manual y creación de tickets. Alternativamente, si tiene una predicción de etiqueta principal de alta confianza, pero no una predicción de etiqueta secundaria segura, esta podría usarse para enrutar parcialmente el correo electrónico o crear un ticket, con algo de trabajo manual adicional para añadir el subproceso relevante.

Si imaginamos que lo primero es cierto, y cada correo electrónico sin una predicción de alta confianza en forma de [Proceso] > [Subproceso] se convierte en una excepción manual, queremos asegurarnos de que todos los ejemplos que proporcionamos para cada etiqueta cuando entrenar el modelo refleja este formato.

Cada etiqueta principal de la taxonomía debe estar relacionada con un proceso amplio relevante para el contenido de los correos electrónicos, por ejemplo, Facturación. Cada etiqueta secundaria debe ser un subproceso más específico que se encuentre bajo una etiqueta principal, por ejemplo, Facturación > Solicitud de estado.

Nota: Cada etiqueta debe ser específica en lo que intenta capturar.

Las etiquetas extremadamente amplias, como Consulta general o Todo lo demás, pueden ser muy poco útiles si se utilizan para agrupar muchos temas distintos y no hay un patrón claro o puntos en común entre los ejemplos anclados.

En este caso de uso, tampoco proporcionarían mucho valor empresarial cuando se creara un ticket de flujo de trabajo y se clasificara como Consulta general o Todo lo demás. Alguien tendría que leerlo atentamente para entender de qué se trata y si era relevante para su equipo antes de poder actuar.

Esto anula cualquier beneficio de ahorro de tiempo y no proporcionaría una MI útil para la empresa sobre el trabajo que los equipos estaban realizando.

Nota: Este es solo un ejemplo de cómo puedes estructurar una taxonomía para un caso de uso específico, este no es un enfoque único para todos. Cada proyecto requerirá una taxonomía única de etiquetas, que depende en gran medida de tu caso de uso, conjunto de datos y objetivos específicos.