Недавно я сделал несколько презентаций на конференции о том, как мы думаем о скорости при разработке систем машинного обучения в Monzo. В этом посте рассказывается о некоторых моментах, о которых я говорил в своих выступлениях, а также о том, что мы делаем в команде машинного обучения Monzo для ускорения нашей собственной работы.

Скорость - это не то слово, которое обычно ассоциируется с командами машинного обучения. Когда мы говорим и пишем о достижениях в области машинного обучения, часто мы делаем акцент на проблеме, алгоритмическом подходе и результатах, но не упоминаем время, которое потребовалось для этого.

Имеет ли значение скорость в машинном обучении?

Я помню, как однажды разговаривал с исследователем машинного обучения, который работал в большой компании. Он рассказал мне, что группа разработчиков продукта обратилась к нему с очень интересной идеей, связанной с резюмированием текста. Он начал изучать проблему и в течение 12 месяцев сделал очень значительный вклад - вплоть до публикации статей по этой теме на конференциях высшего уровня. Я спросил его, воплотились ли его идеи в рассматриваемом продукте. К сожалению, ответ был отрицательным: к тому времени, как его исследование было завершено, команда разработчиков уже отошла от этой проблемы и больше не была заинтересована в ее решении 😭.

Я слышал много вариантов этой истории: все они отражают несогласованность темпа работы между группами разработки продуктов и машинного обучения. В конечном итоге это приводит к тому, что исследования в области машинного обучения никогда не выходят за рамки лаборатории. И все же лучший показатель воздействия на машинное обучение, если вы работаете в учреждении, не занимающемся исследованиями, - это то, можете ли вы использовать его для помощи своим клиентам, а это значит, что вам придется отказаться от него.

Скорость имеет значение. Это выходит за рамки размышлений о минимально жизнеспособных продуктах (и эквиваленте в машинном обучении «используйте логистическую регрессию, прежде чем использовать нейронную сеть»); это скорость всего жизненного цикла для создания систем машинного обучения.

Я затронул эту тему с четырех сторон, когда недавно говорил об этом:

🚢 Быстрое развертывание моделей в производстве

Быстрое развертывание моделей в производственной среде - одно из главных препятствий на пути эффективного машинного обучения. Во многих компаниях это сводится к тому, кому доверяют выполнение этой работы; Часто «ученые» конструируют и обучают модель, а затем передают ее «инженерам» для запуска в производство. Это неявно развивает менталитет «перебросить через стену»: люди, обучающие моделей, не должны думать о том, насколько сложно было бы доставить модели, а люди, которые занимаются выпуском моделей, могут перебросить модель обратно через стену, если она не ведет себя так, как она должен. Самая распространенная жалоба, которую я получал от ученых, была примерно такой: «Я обучил эту модель несколько месяцев назад и просто сижу здесь, ожидая ее отправки» и Инженеры возражают, что они не получают признания за то, что проделали всю тяжелую работу по обеспечению того, чтобы производственный вывод действительно происходил. Разочаровывающий опыт повсюду.

В Monzo специалисты по машинному обучению используют свои собственные модели. Мы обеспечиваем это, сосредоточив внимание на наших инструментах. Мы поставили перед собой цель: если вы можете написать predict() функцию для модели машинного обучения, вы также сможете безопасно развернуть модель в производственной среде. Чтобы сделать это возможным, мы создали cookiecutter шаблон микросервиса, который используют специалисты по машинному обучению: он направляет их через небольшой набор параметров (например, «какую библиотеку ML вы используете?»), А затем создает все, что им нужно, за вычетом небольших битов. , как и сама функция predict(). Теперь мы можем создать и развернуть сервис за несколько часов - сразу после того, как закончим обучение модели. Ученый не должен ждать, пока другие закончат работу, и может реализовать идею на всем пути от проверки до развертывания.

🔍 Быстрая проверка ненадлежащего поведения

В прошлом году, после повторного запуска нашей системы поиска на экране справки, очень частый вопрос, который мы получали от продуктовых команд, звучал так: Когда я ищу X, почему не появляется статья Y? Пытаться объяснить алгоритмы машинного обучения достаточно сложно - диагностировать незначительные нарушения поведения оказалось еще сложнее. Что-то пошло не так с нашим конвейером данных, нашей моделью или тем, как мы обрабатываем результаты в дальнейшем?

Это тип проблемы, которая может заставить нас остановиться: это не тот вид вещей, для которого мы могли бы писать модульные (или интеграционные) тесты, и это не то, в чем проблема сразу же решается. Чтобы быстро решить эту проблему, мы начали писать проверочные тесты: это набор довольно простых входных данных (например, переезд домой), которые имеют очевидные выходы (статья Обновление моего домашнего адреса), которые мы ожидайте, что наша производственная система машинного обучения сможет возвращаться при составлении прогнозов. Они работают в производственной среде: они интегрированы в то, как мы обновляем вложения, которые хранятся в системе, и предотвращают выполнение обновлений, если ожидаемые прогнозы терпят неудачу (также мы получаем уведомление в Slack ⚠️).

Отслеживание онлайн-производительности моделей машинного обучения выходит за рамки того, что мы традиционно делаем при развертывании программного обеспечения - написание проверочных тестов - еще одно небольшое улучшение, которое помогло нам быть в курсе того, как эти системы работают онлайн.

♻️ Быстрое перепрофилирование моделей для решения новых задач

В прошлом году Monzo пережила непростой период, когда время ответа службы поддержки клиентов в несрочных случаях составляло дни, а не часы. За этим сплотилась вся компания: инженеры, дизайнеры и юристы отказались от того, что они делали, чтобы отвечать клиентам.

Чтобы дать возможность всей компании отвечать клиентам, был создан набор тематических очередей; идея заключалась в том, что легче научить кого-то отвечать на один тип вопросов, чем отвечать на какие-либо вопросы. Нашу команду спросили, можем ли мы настроить способ определения того, о чем говорят клиенты, и соответственно автоматически назначать запросы очередям. Обычно команды машинного обучения начинают здесь с обычных вопросов (например, какие данные у нас есть?) И методов (например, обучения классификатора). Однако это не была просьба запустить проект по классификации текста: это была просьба о том, чтобы что-то работало и развернулось.

Одна из систем, которые мы уже использовали в то время, давала рекомендации агентам службы поддержки клиентов - она ​​смотрела на то, что сказали клиенты, и возвращала рекомендации, для которых из множества различных сохраненных ответов может быть уместно использовать. Например, если клиент говорит: «Я забыл свой PIN-код», система рекомендует ответ, содержащий все сведения о том, как его восстановить. Эта система явно не категоризирует запросы; он сопоставляет вопросы с рекомендуемыми ответами на основе метрики сходства. Однако рекомендуемые ответы можно легко сопоставить с категориями!

Поэтому мы быстро перепрофилировали рекомендации этой системы для решения проблемы классификации очередей: мы заключили рекомендации в if операторы для перенаправления запросов в очереди в зависимости от того, какой ответ был рекомендован. Это было развернуто менее чем за день!

Этот урок запомнился нам с тех пор: объединение механизмов правил с моделями машинного обучения можно использовать для быстрого создания, контекстуализации или перепрофилирования системы принятия решений.

⏰ Измерение времени до получения результатов, а не результатов

В упомянутых выше системах используется архитектура кодировщика, опубликованная в 2017 году (на основе Attention is all you need paper). Работая над этим, мы почувствовали, что в целом мы использовали преимущества последних исследований при создании наших систем. Затем, в 2018 году, появились глубокие предварительно обученные языковые модели (такие как ELMo, ULMFit, BERT), которые начали занимать первое место в различных исследовательских задачах, и многие из них были с открытым исходным кодом. Каждые несколько месяцев состояние дел менялось. Как команда, не занимающаяся исследованиями и занимающаяся созданием систем, как мы можем идти в ногу с такими темпами исследований?

Мы решили поставить перед собой задачу: изучить, как эти техники могут работать с таким количеством различных проблем НЛП, сколько мы сможем найти, за очень короткое время (пару недель). Типичный подход, который я использовал здесь раньше, заключается в том, чтобы начинать новый проект для каждой идеи: анализировать данные, понимать / уточнять проблему, обучать и оценивать модели и настраивать, пока что-то не станет выглядеть многообещающим. При таком подходе мы не могли оценить десятки идей за две недели. Вместо этого, вместо того, чтобы пытаться ответить на вопрос «Каков наилучший результат, который я могу получить?», Мы разработали нашу работу вокруг «сколько времени потребуется, чтобы получить результат?»

Смена нашей точки зрения привела нас к высоко модульному подходу к нашей работе с НЛП. Мы построили конвейер, который создает наборы данных контролируемого обучения из всех данных нашего чата: мы просто указываем ему то, что мы хотим прогнозировать, и даем ему некоторые дополнительные аргументы, чтобы настроить, как мы хотим, чтобы текст обрабатывался. Этот инструмент полностью отделен от всего, что связано с машинным обучением; для этого мы создали ряд шаблонов записных книжек Colab, которые принимают (в качестве входных) набор данных, а затем запускают его с помощью определенного алгоритма (например, ULMFit). Наш руководящий принцип заключался в том, что любой должен иметь возможность указать блокнотом на свой набор данных, а затем запустить все ячейки, чтобы получить результат.

Многие из проведенных нами экспериментов дали плохие результаты - и мы их выбросили. Однако конвейеры, которые мы использовали для их получения, остались и развиваются и регулярно используются для генерации данных, обучающих все наши модели. Этот опыт изменил мой взгляд на исследования времени: это время потрачено не зря, если мы узнаем о новых вещах и разрабатываем инструменты, которые позволяют нам быстро применять его (если мы также хорошие результаты, это бонус!).

⬇️ Выводы

Есть известная цитата, которую я часто слышал: Чтобы увеличить свой успех, удвойте частоту неудач (похоже, это сказал Томас Ватсон). Это так же верно в отношении машинного обучения, как и в любом другом месте.

В команде машинного обучения Monzo мы думали об этом с точки зрения скорости нашей работы. Речь идет не о том, чтобы срезать углы, быть менее строгими или пропускать важные этапы работы. Скорость - это настройка себя для быстрого получения результатов, быстрого перепрофилирования систем, быстрой проверки поведения в сети и быстрого развертывания в производственной среде.

В этом посте рассказывается о нескольких историях, которые сформировали наши взгляды на скорость, но работа над этим всегда продолжается. Будут новые посты! Он основан на этих двух разговорах:

  • Ускорение развития машинного обучения Апрель 2019 г., Сетевое мероприятие Xcede Data Science Networking. Лондон.
  • Использование глубокого обучения для поддержки операций клиентов Март 2019 г., Саммит ReWork Deep Learning in Finance. Лондон.

Слайды моего выступления вы можете найти здесь; напишите в твиттере, если у вас есть какие-либо мысли!