Asignación automática de tareas en Jira usando ML

Hola Habr! Mi nombre es Sasha y soy desarrollador de backend. En mi tiempo libre estudio ML y me divierto con los datos de hh.ru.

Este artículo trata sobre cómo nosotros, mediante el aprendizaje automático, automatizamos el proceso de asignación de tareas rutinarias para los evaluadores.

Hh.ru tiene un servicio interno para el que se crean tareas en Jira (se llaman HHS dentro de la empresa) si alguien no trabaja o está trabajando incorrectamente. Además, estas tareas son manejadas manualmente por el líder del equipo de control de calidad Alexey y asignadas al equipo cuya área de responsabilidad incluye el mal funcionamiento. Lesha sabe que las tareas aburridas deben ser realizadas por robots. Por lo tanto, me pidió ayuda con respecto a ML.



El siguiente gráfico muestra la cantidad de HHS por mes. Estamos creciendo y el número de tareas está creciendo. Las tareas se crean principalmente durante las horas de trabajo, algunas por día, y esto debe distraerse constantemente.


Entonces, según datos históricos, es necesario aprender cómo determinar el equipo de desarrollo al que pertenece el HHS. Esta es una tarea de clasificación de varias clases.

Datos

En las tareas de aprendizaje automático, lo más importante son los datos de calidad. El resultado de la solución al problema depende de ellos. Por lo tanto, cualquier tarea de aprendizaje automático debe comenzar con el estudio de los datos. Desde principios de 2015, hemos acumulado alrededor de 7000 tareas que contienen la siguiente información útil:

• Resumen - Título, Descripción breve
• Descripción: una descripción completa del problema
• Etiquetas: una lista de etiquetas relacionadas con el problema
• Reporter es el nombre del creador de HHS. Esta característica es útil porque las personas trabajan con un conjunto limitado de funcionalidades.
• Creado - Fecha de creación
• El cesionario es la persona a quien se le asigna la tarea. La variable objetivo se generará a partir de este atributo.

Comencemos con la variable objetivo. En primer lugar, cada equipo tiene áreas de responsabilidad. A veces se cruzan, a veces un equipo puede cruzarse en desarrollo con otro. La decisión se basará en el supuesto de que el cesionario, que permaneció con la tarea al momento del cierre, es responsable de su solución. Pero necesitamos predecir no una persona específica, sino un equipo. Afortunadamente, todos los equipos en Jira se mantienen y se pueden mapear. Pero hay una serie de problemas con la definición de un equipo por persona:

• no todos los HHS están relacionados con problemas técnicos, y solo estamos interesados ​​en aquellas tareas que pueden asignarse al equipo de desarrollo. Por lo tanto, debe descartar tareas donde el cesionario no es del departamento técnico
• a veces los equipos dejan de existir. También se eliminan del conjunto de entrenamiento.
• Desafortunadamente, las personas no trabajan para siempre en la empresa, y a veces se mueven de un equipo a otro. Afortunadamente, logramos obtener un historial de cambios en la composición de todos los equipos. Al tener la fecha de creación del HHS y el cesionario, puede encontrar qué equipo participó en la tarea en un momento específico.

Después de filtrar datos irrelevantes, la muestra de capacitación se redujo a 4900 tareas.

Veamos la distribución de tareas entre equipos:


Las tareas deben distribuirse entre 22 equipos.

Signos:

Resumen y descripción son campos de texto.

Primero, deben limpiarse del exceso de caracteres. Para algunas tareas, tiene sentido dejar en las líneas caracteres que llevan información, por ejemplo + y #, para distinguir entre c ++ y c #, pero en este caso decidí dejar solo letras y números, porque no encontró dónde podrían ser útiles otros personajes.

Las palabras deben ser lematizadas. La lematización es la reducción de una palabra a un lema, su forma normal (vocabulario). Por ejemplo, gatos → gato. También probé la derivación, pero con la lematización la calidad fue un poco más alta. La tartamudez es el proceso de encontrar la base de una palabra. Esta base se debe al algoritmo (en diferentes implementaciones son diferentes), por ejemplo, por gatos → gatos. El significado del primero y segundo es yuxtaponer las mismas palabras en diferentes formas. Usé el contenedor de python para Yandex Mystem .

Además, el texto debe estar libre de palabras de detención que no llevan una carga útil. Por ejemplo, "era", "yo", "todavía". Pare las palabras que suelo tomar de NLTK .

Otro enfoque que intento en las tareas de trabajar con texto es una fragmentación de palabras basada en caracteres. Por ejemplo, hay una "búsqueda". Si lo divide en componentes de 3 caracteres, obtendrá las palabras "poi", "ois", "demanda". Esto ayuda a obtener conexiones adicionales. Supongamos que existe la palabra "buscar". La lematización no conduce a "buscar" y "buscar" en una forma general, pero una partición de 3 caracteres resaltará la parte común: "reclamo".

Hice dos fichas. Tokenizer es un método que recibe texto en la entrada, y la salida contiene una lista de tokens, los componentes del texto. El primero resalta palabras y números lematizados. El segundo solo resalta palabras lematizadas, que se dividen en 3 caracteres, es decir en la salida, tiene una lista de tokens de tres caracteres.

Los tokenizadores se usan en TfidfVectorizer , que se usa para convertir datos de texto (y no solo) en una representación vectorial basada en tf-idf . Se le proporciona una lista de filas en la entrada, y en la salida obtenemos una matriz M por N, donde M es el número de filas y N es el número de signos. Cada característica es una respuesta de frecuencia de una palabra en un documento, donde la frecuencia se multa si la palabra aparece muchas veces en todos los documentos. Gracias al parámetro ngram_range TfidfVectorizer, agregué bigrams y trigrams como atributos.

También intenté usar las incorporaciones de palabras obtenidas con Word2vec como características adicionales. La incrustación es una representación vectorial de una palabra. Para cada texto, promedié las incrustaciones de todas sus palabras. Pero esto no dio ningún aumento, por lo que rechacé estas señales.

Para las etiquetas, se utilizó un CountVectorizer . Las filas con etiquetas se alimentan a la entrada, y en la salida tenemos una matriz donde las filas corresponden a las tareas y las columnas corresponden a las etiquetas. Cada celda contiene el número de ocurrencias de la etiqueta en la tarea. En mi caso, es 1 o 0.

LabelBinarizer se presentó para Reporter. Binariza los atributos de uno a todos. Solo puede haber un creador para cada tarea. En la entrada de LabelBinarizer, se envía una lista de creadores de tareas, y el resultado es una matriz, donde las filas son tareas y las columnas corresponden a los nombres de los creadores de tareas. Resulta que en cada línea hay "1" en la columna correspondiente al creador, y en el resto - "0".

Para Creado, se considera la diferencia en días entre la fecha en que se creó la tarea y la fecha actual.

Como resultado, se obtuvieron los siguientes signos:

• tf-idf para Resumen en palabras y números (4855, 4593)
• tf-idf para Resumen en particiones de tres caracteres (4855, 15518)
• tf-idf para Descripción en palabras y números (4855, 33297)
• tf-idf para Descripción en particiones de tres caracteres (4855, 75359)
• Número de entradas para etiquetas (4855, 505)
• signos binarios para Reporter (4855, 205)
• vida útil de la tarea (4855, 1)

Todos estos signos se combinan en una matriz grande (4855, 129478), en la que se llevará a cabo la capacitación.

Por separado, vale la pena señalar los nombres de los signos. Porque algunos modelos de aprendizaje automático pueden identificar características que tienen el mayor impacto en el reconocimiento de clase, debe usar esto. TfidfVectorizer, CountVectorizer, LabelBinarizer tienen métodos get_feature_names que muestran una lista de características cuyo orden corresponde a columnas de matrices de datos.

Selección del modelo de predicción

Muy a menudo XGBoost da buenos resultados. Y comenzó con eso. Pero generé una gran cantidad de características, cuya cantidad excede significativamente el tamaño de la muestra de entrenamiento. En este caso, la probabilidad de reentrenar XGBoost es alta. El resultado no es muy bueno. La alta dimensión es una digestión logística bien digerida. Ella mostró una mayor calidad.

También intenté, como ejercicio, construir un modelo en una red neuronal en Tensorflow usando este excelente tutorial, pero resultó peor que con una regresión logística.

Selección de hiperparámetros

También jugué con los hiperparámetros XGBoost y Tensorflow, pero lo dejo fuera de la publicación, porque El resultado de la regresión logística no fue superado. Al final torcí todos los bolígrafos que podrían ser. Como resultado, todos los parámetros permanecieron predeterminados, excepto dos: solver = 'liblinear' y C = 3.0

Otro parámetro que puede afectar el resultado es el tamaño de la muestra de entrenamiento. Porque Estoy tratando con datos históricos, y en el transcurso de varios años la historia puede cambiar seriamente, por ejemplo, la responsabilidad de algo puede ir a otro equipo, luego los datos más recientes pueden ser más útiles, y los datos antiguos pueden incluso disminuir la calidad. A este respecto, se me ocurrió la heurística: cuanto más antiguos son los datos, menos contribución deben hacer para modelar la capacitación. Dependiendo de la edad, los datos se multiplican por un cierto coeficiente, que se toma de la función. Generé varias funciones para atenuar los datos y utilicé la que dio el mayor aumento en las pruebas.



Debido a esto, la calidad de la clasificación aumentó en un 3%

Evaluación de calidad

En los problemas de clasificación, debemos pensar en lo que es más importante para nosotros: ¿ precisión o integridad ? En mi caso, si el algoritmo está mal, entonces no hay nada malo, tenemos muy buen conocimiento entre los equipos y la tarea se transferirá a los responsables, o al principal en el control de calidad. Además, el algoritmo no comete errores al azar, pero encuentra un comando cercano al problema. Por lo tanto, se decidió tomar el 100% para completar. Y para medir la calidad, se eligió la métrica de precisión: la proporción de respuestas correctas, que para el modelo final fue del 76%.

Como mecanismo de validación, primero utilicé la validación cruzada: cuando la muestra se divide en N partes y la calidad se verifica en una parte, y el entrenamiento se realiza en el resto, y así N veces, hasta que cada parte esté en la función de prueba. El resultado se promedia. Pero en mi caso, este enfoque no encajaba, porque El orden de los datos está cambiando y, como ya se sabe, la calidad depende de la frescura de los datos. Por lo tanto, estudié todo el tiempo en los viejos, y fui validado en los nuevos.

Veamos qué comandos confunde el algoritmo con mayor frecuencia:



En primer lugar están Marketing y Pandora. Esto no es sorprendente ya que El segundo equipo surgió del primero y se llevó la responsabilidad de muchas funcionalidades. Si considera al resto del equipo, también puede ver los motivos asociados con la cocina interna de la empresa.

A modo de comparación, quiero mirar modelos aleatorios. Si asigna una persona responsable al azar, la calidad será de aproximadamente el 5%, y si para la clase más común, entonces - 29%

Los signos mas significativos

LogisticRegression para cada clase devuelve coeficientes de atributo. Cuanto mayor sea el valor, mayor será la contribución que este atributo hizo a esta clase.

Debajo del spoiler, la salida de los principales signos. Los prefijos indican de dónde provienen los signos:

• sum - tf-idf para Resumen en palabras y números
• sum2 - tf-idf para resumen en divisiones de tres caracteres
• desc - tf-idf para Descripción en palabras y números
• desc2 - tf-idf para Descripción en particiones de tres caracteres
• laboratorio - campo de etiquetas
• rep - Reportero de campo

Las señales reflejan aproximadamente lo que están haciendo los equipos.

Uso del modelo

Con esto, se completa la construcción del modelo y es posible construir un programa sobre la base.


El programa consta de dos scripts de Python. El primero construye un modelo, y el segundo hace predicciones.

1. Jira proporciona una API a través de la cual puede descargar tareas ya completadas (HHS). Una vez al día, se inicia el script y los descarga.
2. Los datos descargados se convierten en etiquetas. Primero, los datos se superan para entrenamiento y prueba y se envían al modelo ML para su validación, para garantizar que la calidad no comience a disminuir de principio a comienzo. Y luego, la segunda vez, el modelo recibe capacitación sobre todos los datos. Todo el proceso dura unos 10 minutos.
3. El modelo entrenado se guarda en el disco duro. Usé la utilidad eneldo para serializar objetos. Además del modelo en sí, también es necesario guardar todos los objetos que se utilizaron para obtener las características. Esto es para obtener carteles en el mismo espacio para el nuevo HHS.
4. Usando el mismo eneldo, el modelo se carga en el script para la predicción, que se ejecuta una vez cada 5 minutos.
5. Ir a Jira para el nuevo HHS.
6. Recibimos los letreros y los pasamos al modelo, que devolverá para cada HHS el nombre de la clase, el nombre del equipo.
7. Encontramos a la persona responsable del equipo y le asignamos una tarea a través de la API de Jira. Puede ser un probador, si el equipo no tiene un probador, entonces es un líder del equipo.

Para que el programa sea conveniente de implementar y tenga las mismas versiones de biblioteca que durante el desarrollo, los scripts se empaquetan en un contenedor Docker.

Como resultado, automatizamos el proceso de rutina. La precisión del 76% no es demasiado grande, pero en este caso las fallas no son críticas. Todas las tareas encuentran a sus ejecutantes, y lo más importante, para esto, ya no necesita distraerse varias veces al día para comprender la esencia de las tareas y buscar a los responsables. ¡Todo funciona automáticamente! ¡Hurra!