В Контуре мы решаем самые разные задачи с помощью машинного обучения: распознаем документы и ищем подделки паспортов, анализируем банковские транзакции, предсказываем вероятность банкротства компаний, классифицируем товары, автоматически отвечаем на вопросы в чате, развиваем собственный speech-to-text… и еще десятки проектов, которые привносят в продукты новые фичи или помогают оптимизировать процессы.
Поток идей для ML-проектов огромный, но не все из них стоят того, чтобы за них браться. Некоторые с большей вероятностью принесут результат, а другие изначально обречены на провал.
В этой статье я приведу ответы на вопросы, над которыми стоит задуматься в самом начале, если вдруг вам пришла в голову идея "прикрутить к проекту ML-фичу" (добавить ложечку Data Science / AI / другие модные названия).
Предыстория
Привет! Я ML-разработчик (датасайнтист) из команды, занимающейся автоматизацией техподдержки. Если говорить просто, мы прикручиваем модели машинного обучения, чтобы специалисты техподдержки в Контуре как можно меньше занимались рутиной.
В моей команде 3 датасайнтиста, 3 бэкендера и 1 менеджер разработки. А еще мы очень тесно взаимодействуем с аналитиками из техподдержки, которые по сути стали продолжением нашей команды. Именно они приносят большинство идей по созданию новых проектов и улучшению существующих.
Типичный пайплайн появления новых фичей выглядит так:
Аналитики приходят с новой идеей. Идет обсуждение, насколько эта задача относится к DS, какого уровня качества мы хотим достигнуть, окупятся ли затраты на разработку... Иногда мы сразу говорим, что за разумное время решить задачу нельзя, иначе переходим дальше.
Датасайнтисты делают EDA, то есть пытаются понять, что из себя представляют данные: анализируют, смотрят на различные распределения, строят графики.
Исходя из задач бизнеса, датасайнтисты выбирают DS-метрики, алгоритм и обучают модель. На данном этапе может быть несколько итераций.
Бэкендеры пишут сервис, настраивают датастримы и необходимые интеграции.
Разработчики и датасайнтисты занимаются поддержкой решения.
На каждом из первых 3-х этапов задача может отвалиться (из-за плохой идеи, данных или качества модели, обученной на третьем этапе).
В прошлом году мы столкнулись с проблемой на первом этапе: мы буквально тонули в постоянном потоке гипотез. На встречи про потенциал той или иной идеи уходило много времени, и было видно, что аналитикам не всегда понятно, почему одну гипотезу мы берем в работу, а другую — нет.
Чтобы привнести это понимание, улучшить качество изначальных гипотез и в целом говорить на одном языке, мы устроили две Q&A-сессии, где ответили на вопросы типа:
как понять, есть DS в задаче или нет?
как выглядит идеальный датасет?
как датасайнтисты подбирают метрики?
что такое EDA?...
Я выбрал вопросы, ответы на которые были бы полезны вне зависимости от предметной области, и решил поделиться ими в статье.
Задача
Как понять, есть ML в задаче или нет?
Первое, о чем нужно подумать — подходит ли задача в принципе для машинного обучения. Наводящие вопросы ниже помогут это понять.
Небольшой disclaimer: методы машинного обучения делятся на supervised (с учителем) и unsupervised (без учителя). Но на практике чаще встречаются первые, поэтому в данной статье под машинным обучением я буду иметь в виду его supervised часть.
Есть ли у вас четкая формулировка проблемы с понятным input и output?
Для задачи определения спама в электронном сообщении:
input: отправитель, заголовок и текст письма
output: (письмо является спамом) или 0 (не является)
Для задачи машинного перевода:
input: текст на исходном языке
output: текст на языке перевода
Для определения намерения пользователя в чате:
input: последние n сообщений в чате
output: intent (приветствие, прощание, желание купить продукт, технический вопрос, ...)
И так далее… Любую ML-модель можно представить в виде функции, принимающей input и возвращающей output. Поэтому для начала четко сформулируйте, какие данные вы хотите подавать на вход и что получать на выходе.
Может, есть простое алгоритмизированное решение?
Большинство ML-алгоритмов применяются в ситуации, когда у проблемы нет точного решения или его чрезвычайно трудно закодить. Написать 10000 регулярок или 1 млн выражений if-else будет весьма трудно, и тут нужно посмотреть в сторону ML. Но подумайте, может, приемлемое качество выдаст дюжина?
Например, однажды у нас возникла потребность определять, что пользователь с нами только поздоровался и больше ничего не написал (intent "welcome"). Часть таких пользователей не продолжали общение, а внимание и время оператора тратилось. Нам захотелось автоматизировать этап "приветствия": то есть здороваться и уточнять вопрос ботом. Чтобы распознавать intent "welcome" мы могли бы потратить силы на сбор соответствующего датасета и обучение полноценной ML-модели. Но для начала мы решили сделать простое временное решение в виде регулярки, детектирующей небольшой список фраз вроде "добрый день", "добрый вечер", "здравствуйте". В итоге данного подхода оказалось более чем достаточно (полнота и точность нас полностью устроили). С момента запуска мы пару раз дополнили регулярку, анализируя логи и фидбэк, но это решение все еще успешно работает.
А еще довольно часто неплохой заменой ML оказывается хорошее интерфейсное решение. Пример для того же чатбота: продуманные пункты и переходы в меню, закрывающие большинство вопросов пользователей вместо обработки естественного языка.
Способен ли задачу решить человек?
Хорошая эвристика: может ли человек по заданному input предсказать output? Потому что если нет, скорее всего, качество модели также будет низким.
У нас был пример, когда по ответам на два вопроса от голосового робота ("По какому продукту вы обращаетесь?" и "Какая у вас проблема?") мы хотели научиться предсказывать линию (первая для простых вопросов и вторая для сложных). Провели эксперимент, в котором попросили одного из аналитиков по транскрибациям ответов пользователей (input) предсказать линию (output). Так называемый human level performance (качество предсказаний человека по заданному input) оказался низким. Модель в итоге также показала не лучшее качество.
Данные
Как выглядит идеальный датасет?
В мире Data Science именно данные являются ключевой составляющей (кто бы мог подумать, hehe). Простая модель из классического ML, обученная на хорошем датасете, всегда будет побеждать самую навороченную архитектуру нейросети, которая обучалась на мусоре. Так что же отличает хороший датасет?
Качество и полнота разметки
Supervised методы машинного обучения полагаются на разметку, от качества которой напрямую зависит точность моделей.
Пример: если хотим распознавать на фото кошек, собак и мышей:
в датасете должны быть представлены все 3 вида животных;
для качества модели будет полезно разнообразие в породе животных, фоне, освещенности и так далее;
данные должны содержать как можно меньше шума и противоречий. В этом примере в идеале все фото кошек должны иметь только метки "кошка", собаки — "собака", мыши — "мышь". Этот момент может быть самоочевидным, но зачастую разметку для моделей готовят специальные люди — асессоры. Как и все люди, асессоры могут ошибаться (по невнимательности, усталости и другим причинам). Вот почему для разметки критических задач важно давать один пример на разметку сразу нескольким людям, то есть использовать "перекрытие".
Максимальная приближенность к реальным данным, с которыми модель будет работать в проде
Если вы обучаете классификатор животных исключительно на черно-белых изображениях, наивно надеяться, что он будет хорошо работать на цветных.
Но есть и гораздо менее очевидные детали, например, распределение классов. Приведу пример из собственного опыта. Есть задача автоматической маршрутизации звонков в техподдержку на нужный отдел (продукт) по ответам пользователя на вопросы от голосового робота. В Контуре есть серия продуктов про сдачу отчетности в контролирующие органы, например, «Контур Экстерн».
В даты, предшествующие дедлайнам по сдаче отчетности, нагрузка на техподдержку Экстерна традиционно возрастает, их доля по сравнению с другими продуктами Контура увеличивается. Если обучить модель на периоде, в котором нет сезонов отчетности, то когда те наступят, для модели это станет неожиданностью. Как следствие, точность классификации резко упадет. Поэтому, если в вашей предметной области есть сезонность, важно, чтобы в данных она была представлена.
Количество данных
Ответить заранее на вопрос "Сколько нужно сэмплов в датасете, чтобы получить точность в 90%?" невозможно. Все очень сильно зависит от типа задачи, предметной области, зашумленности данных и еще множества факторов. Кроме того, одним моделям требуются гораздо больше данных, чем другим. Рекомендация: начинайте с того количества, которое можно раздобыть малыми усилиями.
В последние годы активно используется подход под названием transfer learning. Это набор приемов, позволяющих переиспользовать накопленное внутри модели "знание" для решения похожих задач. Он часто применяется в CV (компьютерном зрении) и NLP (обработке естественного языка), при этом уменьшается количество данных, необходимых для обучения..
Например, благодаря transfer learning для обучения нейронки, определяющей, когда в чате было отправлено решение (по тексту чата), нам изначально понадобилась разметка всего 400 чатов. Если бы мы обучали модель такого типа с нуля, для удовлетворительной работы могли понадобиться десятки тысяч примеров.
Для любителей технических деталей
Мы взяли нейронную сеть RuBERT, обученную на русскоязычной википедии и текстах новостей (unsupervised language modelling task).
Зафайнтюнили ее на наш домен, используя данные 1 млн чатов (unsupervised language modelling task).
Зафайнтюнили под конкретную задачу бинарной классификации, используя вручную размеченные 400 чатов (supervised binary classification task: есть в чате решение или еще нет).
Метрики
Как бизнес-метрики превращаются в DS-метрики?
Есть ли у вас метрики, с помощью которых можно оценить успех?
Существует большое количество метрик под разные задачи, и правильный их выбор — важный этап решения. Ошибка здесь может стоить очень дорого. Выбор должен быть осуществлен перед тем, как приступать к обучению моделей.
Правильные метрики позволяют оценить, насколько ваша модель успешно решает поставленную задачу, насколько она окупает ресурсы, потраченные на ее разработку. Кроме того, они понадобятся при последующих итерациях доработок, чтобы сравнить новую версию с предыдущей.
В методологии LeanDS (сайт, телеграм-канал LeanDS) метрики для задачи предлагается выстраивать в своеобразный каскад (пример на картинке), начиная от запроса бизнеса. Цепочка метрик формируется таким образом, что изменения на нижних уровнях позволяют предсказать изменения на верхних.
Заключение
В статье я привел вопросы, над которыми стоит задуматься перед тем, как начать работать над ML-задачей. Надеюсь, они помогут сэкономить время за счет отбрасывания заведомо неудачных гипотез, а также выбрать те, которые с большей вероятностью принесут результат и приблизят к поставленным целям.
Среди вопросов, заданных нам аналитиками, было еще множество интересных:
"как мы выбираем модель"
"почему одни модели строятся за 1 день, а другие — за несколько недель"
"как решение попадает на прод"...
Но это уже тема для следующих статей :)
