Уроки, полученные при работе с реальными конвейерами машинного обучения

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

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

Фон

С тех пор, как Latch начал производство замков пять лет назад, мы прошли через несколько итераций аппаратного и микропрограммного обеспечения. В результате у нас есть широкий ассортимент умных замков, установленных в зданиях по всей стране. Эти устройства, по большей части, питаются от батареек AA, которые обеспечивают все «умные» функции, такие как доступ к своей квартире с помощью смартфона. Поэтому важно обеспечить своевременную замену батарей до того, как устройство разрядится.

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

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

Урок №1 - При работе с незнакомым набором данных спросите совета у экспертов.

Когда мы начали визуализировать кривые использования батареи для нескольких устройств одновременно, мы заметили кое-что странное. Для некоторых замков процент заряда батареи резко снизился - на 10–20% - за короткий промежуток времени, а затем вернулся к прежнему уровню.

Сначала мы были изрядно озадачены. Должны ли мы просто игнорировать эти эпизоды как ошибочные показания? Это проблема с нашими данными, и если да, насколько она серьезна?

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

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

Урок №2 - показатели эффективности машинного обучения не всегда отражают ценность бизнеса

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

Поэтому мы потратили немного времени на просмотр нашего набора для проверки и попыток понять, как прогнозы модели переводятся в конкретные пользовательские сценарии. Сколько раз мы недооценивали оставшийся срок службы батареи? Если персонал здания потратил неделю на замену батарей, каковы шансы, что они полностью разрядятся?

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

Урок №3. Единственная константа - это изменение (в данных)

«Нет ничего хуже, чем присматривать за ИИ»

- я, придумывая цитату, чтобы добавить к этой статье

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

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

Дальнейшие действия

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

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