В теории использование машинного обучения (ML) помогает сократить участие человека в процессах и операциях, перераспределять ресурсы и уменьшить затраты. Насколько это работает в условиях конкретной компании и сферы деятельности? Как показывает наш опыт — работает.
На определенном этапе развития мы в компании «ВТБ Капитал» столкнулись с острой необходимостью сократить время на обработку запросов в техническую поддержку. После анализа возможных вариантов было решено применить ML-технологию для категоризации обращений от бизнес-пользователей Calypso, ключевой инвестиционной платформы компании. Быстрая обработка таких запросов крайне важна для высокого качества ИТ-сервиса. Помочь в решении этой задачи мы попросили наших ключевых партнеров – компанию EPAM.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/e28/f7d/526/e28f7d5263a91215e33aeb0cc3e1d77e.png)
Итак, запросы в службу поддержки поступают по e-mail и трансформируются в тикеты в Jira. Затем специалисты поддержки вручную классифицируют их, расставляют приоритеты, вносят дополнительные данные (например, из какого отдела и локации поступил запрос, к какому функциональному блоку системы он относится) и назначают исполнителей. Всего используется порядка 10 категорий запросов. Это, к примеру, может быть просьба проанализировать какие-либо данные и предоставить автору запроса информацию, добавить нового пользователя и т.д. Причем действия могут быть как стандартными, так и нестандартными, поэтому очень важно сразу правильно определить тип запроса и назначить выполнение на нужного специалиста.
Важно отметить: «ВТБ Капитал» хотел не только разработать прикладное технологическое решение, но и оценить возможности различных представленных на рынке инструментов и технологий. Одна задача, два разных подхода, две технологические платформы и три с половиной недели: каким оказался результат?
Основой для разработки прототипа стал подход, предложенный командой EPAM, и исторические данные — порядка 10000 тикетов из Jira. Основное внимание было сосредоточено на 3 обязательных полях, которые содержит каждый такой тикет: Issue Type (тип проблемы), Summary («шапка» письма или тема запроса) и Description (описание). В рамках проекта планировалось решить задачу анализа текста из полей Summary и Description и по его результатам автоматически определять тип запроса.
Именно особенности текста в этих двух полях тикета стали главной технической сложностью при анализе данных и разработки моделей ML. Так, поле Summary может содержать достаточно «чистый» текст, но включающий в себя специфические слова и термины (как пример — CWS reports not running). Для поля Description, напротив, характерен более «грязный» текст с обилием специальных символов, обозначений, бэкслэшей и остатков нетекстовых элементов:
Кроме того, в тексте нередко сочетаются несколько языков (преимущественно, естественно, русский и английский), могут встречаться бизнес-терминология, рунглиш и программистский сленг. И конечно, поскольку запросы нередко пишутся в спешке, то в обоих случаях не исключены опечатки и орфографические ошибки.
Технологии, выбранные командой EPAM, включали в себя Python 3.5 для разработки прототипа, NLTK + Gensim + Re для процессинга текста, Pandas + Sklearn для анализа данных и разработки моделей и Keras + Tensorflow как фреймворк глубокого обучения и бэкэнд.
С учетом возможных особенностей изначальных данных для извлечения признаков из поля Summary были построены три представления: на уровне символов, сочетания символов и отдельных слов. Каждое из представлений использовалось как вход в рекурентную нейронную сеть.
В свою очередь в качестве представления для поля Description были выбраны статистика служебных символов (важна для обработки текста с использованием восклицательных знаков, слэшей и т.д.) и средние значения строк после фильтрации служебных символов и «мусора» (для компактного сохранения структуры текста), а также представление на уровне слов после фильтрации стоп-слов. Каждое представление выступало в качестве входа в нейронную сеть: статистика в полносвязную, построчное и на уровне слов – в рекурентную.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/c5d/221/c44/c5d221c4466592b74a3dca8896422c1f.jpg)
В данной схеме в качестве рекурентной сети использовалась нейронная сеть, состоящая из двунаправленного (bidirectional) GRU слоя с рекурентным и обычным dropout’ом, пулинга скрытых состояний рекурентной сети с применением слоя GlobalMaxPool1D и полносвязного (Dense) слоя с дропаутом. Для каждого из входов строилась своя «голова» нейронной сети, а затем они объединялись через конкатенацию и замыкались на целевую переменную.
![](https://habrastorage.org/r/w780q1/webt/yb/j8/rz/ybj8rz-kwdlpkaryk7ubulu1sdo.jpeg)
Для получения финального результата объединенная нейронная сеть возвращала вероятности принадлежности конкретного запроса к каждому из типов. Данные были разбиты на пять блоков без пересечений: модель строилась по четырем из них и проверялась на пятом. Так как каждому запросу может быть присвоен только один тип запроса, то правило для принятия решения было простым — по максимальному значению вероятности.
Второй прототип, в качестве базы для которого было взято предложение, подготовленное командой «ВТБ Капитал», представляет собой приложение на Microsoft .NET Core с библиотеками Microsoft.ML для реализации алгоритмов машинного обучения и Atlassian.Net SDK для взаимодействия с Jira через REST API. Основой для построения ML-моделей также стали исторические данные – 50000 Jira-тикетов. Как и в первом случае, машинное обучение охватило поля Summary и Description. Перед использованием оба поля также проходили «очистку». Из письма пользователя удалялись приветствия, подписи, история переписки и нетекстовые элементы (например, изображения). Кроме того, с помощью встроенного в Microsoft ML функционала из текста на английском языке вычищались стоп-слова, не имеющие значения для процессинга и анализа текста.
В качестве алгоритма машинного обучения был выбран Averaged Perceptron (бинарная классификация), который дополняется методом One Versus All для обеспечения многоклассовой классификации
Ни одна ML-модель не может (возможно, пока) обеспечить 100% точность результата.
Алгоритм Прототипа №1 обеспечивает долю правильной классификации (Accuracy), равную 0,8003 от общего количества запросов, или 80%. При этом значение аналогичной метрики в ситуации, когда предполагается, что правильный ответ будет выбран человеком из двух представленных решением, достигает 0,901, или 90%. Безусловно, встречаются кейсы, где разработанное решение работает хуже или не может дать правильный ответ – как правило, в силу очень короткого набора слов или специфичности информации в самом запросе. Свою роль играет и пока недостаточно большой объем тех данных, которые использовались в процессе обучения. По предварительной оценке увеличение объема обрабатываемой информации даст возможность повысить правильность классификации еще на 0.01-0.03 пункта.
Результаты лучшей модели в метриках точности (Precision) и полноты (Recall) оцениваются так:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/590/113/485/5901134851d1ef471b408b822f9fbece.png)
Если оценить качество модели в целом для различных типов запросов с помощью ROC-AUC-кривых, то результаты выглядят следующим образом.
Запросы на действие (Action Request) и анализ информации (Analysis/Task Request)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/8cd/e6e/91c/8cde6e91c38a64200cc9b2f3aacd8282.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/676/f1f/422/676f1f42271c204c29f88f0b97117b2c.png)
Запросы на изменение бизнес-данных (Business Data Request) и на изменения (Change Request)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/02f/112/19c/02f11219cfed8c8d208451fd8300c928.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/253/b65/e65/253b65e654d1e8ccfd4fd82e56dee3a6.png)
Запросы на разработку (Development Request) и на предоставление информации (Inquiry Request)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/1fb/baa/dc6/1fbbaadc6b999322eeab9d5adbb43e50.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/65c/198/a17/65c198a179739383a644a0729e2b74b0.png)
Запросы на создание нового объекта (New Object Request) и добавление нового пользователя (New User Request)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/ef0/cb1/4ed/ef0cb14ede844161eb4864846ec7cdbc.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/b7c/03b/d02/b7c03bd020031e48decf95b443acc302.png)
Производственный запрос (Production Request) и запрос, связанный с поддержкой UAT/DEV (UAT/Dev Support Request)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/2f5/ee9/88b/2f5ee988bab691e1f7e67bf169a1f0a5.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/cde/011/ab0/cde011ab09ecf38bda207371821824d3.png)
Примеры правильной и ошибочной классификации для некоторых типов запросов приведены ниже:
Запрос на предоставление информации (Inquiry Request)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/5fa/15d/3ad/5fa15d3add0120d38fe87c0aa6fe9e27.png)
Запрос на изменение (Change Request)
Correct classification
Misclassification
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/b14/ba6/4ae/b14ba64ae7a950fcf2b778607b1e7d9d.png)
Запрос на действие (Action request)
Correct classification
Misclassification
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/830/f31/bd7/830f31bd786c90325c3bee5dd66af9cd.png)
Производственный запрос (Production Issue)
Correct Classification
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/7bd/41b/15f/7bd41b15fe79a94cfa7d4702ac245e5a.png)
Misclassification
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/80d/b28/1b7/80db281b7baa5306e16d4b2018a7dab2.png)
Хорошие результаты показал и второй прототип: ML примерно в 75% случаев правильно определяет тип запроса (метрика Accuracy). Возможность для улучшения показателя связана с повышением качества исходных данных, в частности, устранением случаев, когда одни и те же запросы были отнесены к разным типам.
Каждый из реализованных прототипов показал свою эффективность, и сейчас в опытно-промышленную эксплуатацию в «ВТБ Капитал» запущена комбинация из двух разработанных прототипов. Небольшой эксперимент с ML меньше чем за месяц и с минимальными затратами дал возможность компании познакомиться с инструментарием машинного обучения и решить важную прикладную задачу по классификации обращений пользователей.
Полученный разработчиками EPAM и «ВТБ Капитал» опыт – помимо применения для дальнейшего развития реализованных алгоритмов для обработки запросов пользователей — может быть переиспользован при решении самых разных задач, связанных с потоковой обработкой информации. Движение небольшими итерациями и охват одного процесса за другим позволяет постепенно осваивать и комбинировать различные инструменты и технологии, выбирая хорошо себя показавшие варианты и отказываясь от менее эффективных. Это интересно для ИТ-команды и в тоже время помогает получать результаты, важные для управления и бизнеса.
На определенном этапе развития мы в компании «ВТБ Капитал» столкнулись с острой необходимостью сократить время на обработку запросов в техническую поддержку. После анализа возможных вариантов было решено применить ML-технологию для категоризации обращений от бизнес-пользователей Calypso, ключевой инвестиционной платформы компании. Быстрая обработка таких запросов крайне важна для высокого качества ИТ-сервиса. Помочь в решении этой задачи мы попросили наших ключевых партнеров – компанию EPAM.
![](https://habrastorage.org/getpro/habr/post_images/e28/f7d/526/e28f7d5263a91215e33aeb0cc3e1d77e.png)
Итак, запросы в службу поддержки поступают по e-mail и трансформируются в тикеты в Jira. Затем специалисты поддержки вручную классифицируют их, расставляют приоритеты, вносят дополнительные данные (например, из какого отдела и локации поступил запрос, к какому функциональному блоку системы он относится) и назначают исполнителей. Всего используется порядка 10 категорий запросов. Это, к примеру, может быть просьба проанализировать какие-либо данные и предоставить автору запроса информацию, добавить нового пользователя и т.д. Причем действия могут быть как стандартными, так и нестандартными, поэтому очень важно сразу правильно определить тип запроса и назначить выполнение на нужного специалиста.
Важно отметить: «ВТБ Капитал» хотел не только разработать прикладное технологическое решение, но и оценить возможности различных представленных на рынке инструментов и технологий. Одна задача, два разных подхода, две технологические платформы и три с половиной недели: каким оказался результат?
Прототип №1: технологии и модели
Основой для разработки прототипа стал подход, предложенный командой EPAM, и исторические данные — порядка 10000 тикетов из Jira. Основное внимание было сосредоточено на 3 обязательных полях, которые содержит каждый такой тикет: Issue Type (тип проблемы), Summary («шапка» письма или тема запроса) и Description (описание). В рамках проекта планировалось решить задачу анализа текста из полей Summary и Description и по его результатам автоматически определять тип запроса.
Именно особенности текста в этих двух полях тикета стали главной технической сложностью при анализе данных и разработки моделей ML. Так, поле Summary может содержать достаточно «чистый» текст, но включающий в себя специфические слова и термины (как пример — CWS reports not running). Для поля Description, напротив, характерен более «грязный» текст с обилием специальных символов, обозначений, бэкслэшей и остатков нетекстовых элементов:
Dera colleagues,
Could you please explain to us what is the difference between FX_Opt_delta_all and FX_Opt_delta_cash risk measures?
!01D39C59.62374C90_image001.png!)
Кроме того, в тексте нередко сочетаются несколько языков (преимущественно, естественно, русский и английский), могут встречаться бизнес-терминология, рунглиш и программистский сленг. И конечно, поскольку запросы нередко пишутся в спешке, то в обоих случаях не исключены опечатки и орфографические ошибки.
Технологии, выбранные командой EPAM, включали в себя Python 3.5 для разработки прототипа, NLTK + Gensim + Re для процессинга текста, Pandas + Sklearn для анализа данных и разработки моделей и Keras + Tensorflow как фреймворк глубокого обучения и бэкэнд.
С учетом возможных особенностей изначальных данных для извлечения признаков из поля Summary были построены три представления: на уровне символов, сочетания символов и отдельных слов. Каждое из представлений использовалось как вход в рекурентную нейронную сеть.
В свою очередь в качестве представления для поля Description были выбраны статистика служебных символов (важна для обработки текста с использованием восклицательных знаков, слэшей и т.д.) и средние значения строк после фильтрации служебных символов и «мусора» (для компактного сохранения структуры текста), а также представление на уровне слов после фильтрации стоп-слов. Каждое представление выступало в качестве входа в нейронную сеть: статистика в полносвязную, построчное и на уровне слов – в рекурентную.
![](https://habrastorage.org/getpro/habr/post_images/c5d/221/c44/c5d221c4466592b74a3dca8896422c1f.jpg)
В данной схеме в качестве рекурентной сети использовалась нейронная сеть, состоящая из двунаправленного (bidirectional) GRU слоя с рекурентным и обычным dropout’ом, пулинга скрытых состояний рекурентной сети с применением слоя GlobalMaxPool1D и полносвязного (Dense) слоя с дропаутом. Для каждого из входов строилась своя «голова» нейронной сети, а затем они объединялись через конкатенацию и замыкались на целевую переменную.
![](https://habrastorage.org/webt/yb/j8/rz/ybj8rz-kwdlpkaryk7ubulu1sdo.jpeg)
Для получения финального результата объединенная нейронная сеть возвращала вероятности принадлежности конкретного запроса к каждому из типов. Данные были разбиты на пять блоков без пересечений: модель строилась по четырем из них и проверялась на пятом. Так как каждому запросу может быть присвоен только один тип запроса, то правило для принятия решения было простым — по максимальному значению вероятности.
Прототип №2: алгоритмы и принципы работы
Второй прототип, в качестве базы для которого было взято предложение, подготовленное командой «ВТБ Капитал», представляет собой приложение на Microsoft .NET Core с библиотеками Microsoft.ML для реализации алгоритмов машинного обучения и Atlassian.Net SDK для взаимодействия с Jira через REST API. Основой для построения ML-моделей также стали исторические данные – 50000 Jira-тикетов. Как и в первом случае, машинное обучение охватило поля Summary и Description. Перед использованием оба поля также проходили «очистку». Из письма пользователя удалялись приветствия, подписи, история переписки и нетекстовые элементы (например, изображения). Кроме того, с помощью встроенного в Microsoft ML функционала из текста на английском языке вычищались стоп-слова, не имеющие значения для процессинга и анализа текста.
В качестве алгоритма машинного обучения был выбран Averaged Perceptron (бинарная классификация), который дополняется методом One Versus All для обеспечения многоклассовой классификации
Оценка результатов
Ни одна ML-модель не может (возможно, пока) обеспечить 100% точность результата.
Алгоритм Прототипа №1 обеспечивает долю правильной классификации (Accuracy), равную 0,8003 от общего количества запросов, или 80%. При этом значение аналогичной метрики в ситуации, когда предполагается, что правильный ответ будет выбран человеком из двух представленных решением, достигает 0,901, или 90%. Безусловно, встречаются кейсы, где разработанное решение работает хуже или не может дать правильный ответ – как правило, в силу очень короткого набора слов или специфичности информации в самом запросе. Свою роль играет и пока недостаточно большой объем тех данных, которые использовались в процессе обучения. По предварительной оценке увеличение объема обрабатываемой информации даст возможность повысить правильность классификации еще на 0.01-0.03 пункта.
Результаты лучшей модели в метриках точности (Precision) и полноты (Recall) оцениваются так:
![](https://habrastorage.org/getpro/habr/post_images/590/113/485/5901134851d1ef471b408b822f9fbece.png)
Если оценить качество модели в целом для различных типов запросов с помощью ROC-AUC-кривых, то результаты выглядят следующим образом.
Запросы на действие (Action Request) и анализ информации (Analysis/Task Request)
![](https://habrastorage.org/getpro/habr/post_images/8cd/e6e/91c/8cde6e91c38a64200cc9b2f3aacd8282.png)
![](https://habrastorage.org/getpro/habr/post_images/676/f1f/422/676f1f42271c204c29f88f0b97117b2c.png)
Запросы на изменение бизнес-данных (Business Data Request) и на изменения (Change Request)
![](https://habrastorage.org/getpro/habr/post_images/02f/112/19c/02f11219cfed8c8d208451fd8300c928.png)
![](https://habrastorage.org/getpro/habr/post_images/253/b65/e65/253b65e654d1e8ccfd4fd82e56dee3a6.png)
Запросы на разработку (Development Request) и на предоставление информации (Inquiry Request)
![](https://habrastorage.org/getpro/habr/post_images/1fb/baa/dc6/1fbbaadc6b999322eeab9d5adbb43e50.png)
![](https://habrastorage.org/getpro/habr/post_images/65c/198/a17/65c198a179739383a644a0729e2b74b0.png)
Запросы на создание нового объекта (New Object Request) и добавление нового пользователя (New User Request)
![](https://habrastorage.org/getpro/habr/post_images/ef0/cb1/4ed/ef0cb14ede844161eb4864846ec7cdbc.png)
![](https://habrastorage.org/getpro/habr/post_images/b7c/03b/d02/b7c03bd020031e48decf95b443acc302.png)
Производственный запрос (Production Request) и запрос, связанный с поддержкой UAT/DEV (UAT/Dev Support Request)
![](https://habrastorage.org/getpro/habr/post_images/2f5/ee9/88b/2f5ee988bab691e1f7e67bf169a1f0a5.png)
![](https://habrastorage.org/getpro/habr/post_images/cde/011/ab0/cde011ab09ecf38bda207371821824d3.png)
Примеры правильной и ошибочной классификации для некоторых типов запросов приведены ниже:
Запрос на предоставление информации (Inquiry Request)
![](https://habrastorage.org/getpro/habr/post_images/5fa/15d/3ad/5fa15d3add0120d38fe87c0aa6fe9e27.png)
Запрос на изменение (Change Request)
Correct classification
![](https://habrastorage.org/getpro/habr/post_images/54a/1c1/85c/54a1c185c2593817368c6c7df5854181.png)
Misclassification
![](https://habrastorage.org/getpro/habr/post_images/b14/ba6/4ae/b14ba64ae7a950fcf2b778607b1e7d9d.png)
Запрос на действие (Action request)
Correct classification
![](https://habrastorage.org/getpro/habr/post_images/830/f31/bd7/830f31bd786c90325c3bee5dd66af9cd.png)
Misclassification
![](https://habrastorage.org/getpro/habr/post_images/830/f31/bd7/830f31bd786c90325c3bee5dd66af9cd.png)
Производственный запрос (Production Issue)
Correct Classification
![](https://habrastorage.org/getpro/habr/post_images/7bd/41b/15f/7bd41b15fe79a94cfa7d4702ac245e5a.png)
Misclassification
![](https://habrastorage.org/getpro/habr/post_images/80d/b28/1b7/80db281b7baa5306e16d4b2018a7dab2.png)
Хорошие результаты показал и второй прототип: ML примерно в 75% случаев правильно определяет тип запроса (метрика Accuracy). Возможность для улучшения показателя связана с повышением качества исходных данных, в частности, устранением случаев, когда одни и те же запросы были отнесены к разным типам.
Подводим итоги
Каждый из реализованных прототипов показал свою эффективность, и сейчас в опытно-промышленную эксплуатацию в «ВТБ Капитал» запущена комбинация из двух разработанных прототипов. Небольшой эксперимент с ML меньше чем за месяц и с минимальными затратами дал возможность компании познакомиться с инструментарием машинного обучения и решить важную прикладную задачу по классификации обращений пользователей.
Полученный разработчиками EPAM и «ВТБ Капитал» опыт – помимо применения для дальнейшего развития реализованных алгоритмов для обработки запросов пользователей — может быть переиспользован при решении самых разных задач, связанных с потоковой обработкой информации. Движение небольшими итерациями и охват одного процесса за другим позволяет постепенно осваивать и комбинировать различные инструменты и технологии, выбирая хорошо себя показавшие варианты и отказываясь от менее эффективных. Это интересно для ИТ-команды и в тоже время помогает получать результаты, важные для управления и бизнеса.