Системы машинного обучения прекрасны. В настоящее время используется множество форм и форм алгоритмов машинного обучения. Различные модели кластеризации, такие как k-средние, методы прогнозирования, такие как деревья, или более продвинутые методы глубокого обучения, страдают от технического долга. В традиционной разработке программного обеспечения технический долг имеет отчетливый запах. В дополнение к «традиционным» проблемам разработки программного обеспечения системы машинного обучения также сталкиваются с новыми проблемами. В следующих абзацах представлены различные технические долги, обнаруженные в системах машинного обучения.
1. Инкапсуляция
Изоляция различных программных компонентов считается хорошей практикой. Инкапсуляция объектов упрощает обслуживание кода, снижая риск будущих изменений (независимо от их цели).
Запутанность
Модели машинного обучения неразрывно связаны с данными. Различные функции по-разному влияют на модель. Если входное распределение одной функции изменяется, то выходные данные модели также могут измениться. Модель связывает все входы, поэтому ни один вход не является действительно независимым. Чтобы решить эту проблему, рекомендуется отслеживать входные функции, а также выходные данные модели, чтобы замечать изменения с течением времени. Если что-то изменится, это может быть показателем того, что пришло время обновить модель.
Каскадная коррекция
Иногда модель ведет себя не так, как нам хотелось бы. Чтобы решить эту проблему, мы можем добавить установщик, калибровку, эвристику или пороговые значения. Эти исправления могут накапливаться в корректирующем слое, который скрывает особые случаи, которые модель не могла правильно обработать. По мере увеличения слоя становится все труднее отличить модель от всего остального, что ее окружает. Улучшение небольших частей системы может привести к глобальным потерям. Решение этой проблемы состоит в том, чтобы создать модель, которая корректирует все, вместо того, чтобы соединять несколько слоев сверху.
Недекларированные клиенты
Как правило, нет ограничений на то, кто может использовать выходные данные модели. Разрешение различным системам использовать выходные данные модели может привести к непреднамеренным и плохо понятным зависимостям. Иногда могут возникать скрытые петли обратной связи. Чтобы предотвратить это, необходимо установить более жесткие ограничения доступа для отслеживания зависимостей использования.
2. Зависимости данных
Зависимости кода можно изучать с помощью статического анализа. Однако подобных инструментов для анализа данных нет. Это может привести к нарастанию цепочек зависимостей, которые трудно распутать.
Нестабильные зависимости данных
Данные могут потребляться из другой системы машинного обучения, которая со временем может меняться. Исходная модель обеспечивает распределение результатов, которое может измениться при обновлении модели. В этом случае будут затронуты последующие модели. Это усложняет определение источника изменений. Решением было бы отслеживать версии для каждой из моделей и специально маркировать каждую модель. Однако это, в свою очередь, усложняет поддержку нескольких сигналов с течением времени.
Недостаточно используемые зависимости данных
Недостаточно используемые зависимости данных — это входные сигналы, которые мало улучшают модель. Более того, изменения в этих сигналах могут привести к непреднамеренному влиянию на конечный результат. Может случиться так, что функция имела смысл в прошлом, но сейчас, фактически не используется, она все еще находится в модели. Другими эффектами недоиспользования входных данных, приводящими к проблемам, могут быть коррелированные функции или объединенные функции. Функции, которые обеспечивают незначительное повышение производительности с неясной релевантностью, включаются за счет сложности модели и накладных расходов.
Статический анализ зависимостей данных
Как и в случае с традиционным кодом, существуют инструменты для статического анализа данных. Это необходимо для отслеживания изменений, миграций и, при необходимости, принудительных обновлений. Это может сделать автоматические проверки, чтобы убедиться, что правильные деревья зависимостей разрешены правильно.
3. Петли обратной связи
Модели машинного обучения обычно со временем влияют на собственное поведение. Априори сложно оценить, насколько сильно это повлияет на модель. Эти петли обратной связи трудно оценить и устранить, особенно когда это происходит с течением времени.
Циклы прямой обратной связи
Напрямую модель влияет на собственные будущие обучающие данные. Одним из способов решения этой проблемы является применение рандомизации. Другой способ — оставить части данных нетронутыми.
Скрытые циклы обратной связи
Прямые циклы обратной связи сложно выявить и устранить, но еще труднее со скрытыми циклами обратной связи. Скрытые состоят из двух или более систем, которые влияют друг на друга через реальный мир. Например, две разные инвестиционные компании разработали два разных алгоритма инвестирования. Оба их действия находятся под сильным влиянием друг друга и могут влиять на поведение друг друга при покупке/продаже.
4. Антипаттерны системы машинного обучения
Как бы красиво это ни звучало, любая модель машинного обучения — это лишь часть всего необходимого кода. Необходима вся предварительная обработка данных, фильтрация и постобработка, которые часто недооцениваются.
Связующий код
Объединение всей системы в одно решение препятствует улучшению. Это затрудняет анализ, обновление и настройку отдельных частей.
Конвейерные джунгли
Этот антишаблон возникает, когда новые сигналы и источники информации обнаруживаются и добавляются последовательно без осторожности.
Мертвые экспериментальные кодовые пути
В рабочем коде обычно создаются новые ветки выполнения для проверки новых гипотез или экспериментов с новыми методами. Однако со временем это создает сложность кода, которую необходимо убрать, иначе это может привести к фатальным ошибкам. Хорошей практикой кодирования является регулярное изучение всех веток и удаление неиспользуемых.
Долг абстракции
Похоже, в сообществе машинного обучения нет единого мнения относительно правильной абстракции. Map-reduce стала преобладающей абстракцией; однако кажется, что шаблон сервера параметров более надежен.
Общие запахи
Запах на нескольких языках. По возможности избегайте использования разных языков для одной и той же системы. В противном случае это увеличивает его сложность. Запах прототипирования возникает, когда производственная система масштабируется из небольших прототипов. Прототипы не всегда отражают реальность полномасштабной системы.
Задолженность по конфигурации
Непонятное место, где может скрываться технический долг системы машинного обучения, — конфигурация. Большая система имеет множество параметров конфигурации, таких как параметры обучения алгоритма, методы предварительной и последующей обработки, процедуры проверки и т. д. Легко допустить ошибки конфигурации, которые могут привести как минимум к растрате вычислительной мощности или даже к более серьезным производственным ошибкам. Излишние настройки должны быть обнаружены и удалены. В идеале можно было бы легко представить, как различные конфигурации влияют на систему.
Работа с изменениями во внешнем мире
Системы машинного обучения часто разрабатываются для взаимодействия с реальным миром. Это дорого обходится. Плата за взаимодействие с реальным миром заключается в том, что данные реального мира малостабильны и могут измениться.
Фиксированные пороги в динамических системах
Как правило, пороги выбираются вручную. Однако это отнимает много времени и не масштабируется. Наилучший способ выбрать пороговые значения — установить проверку удержания для автоматической корректировки значения.
Мониторинг и тестирование
Модульное тестирование используется для разработки программного обеспечения, но для систем машинного обучения это сложно. Нельзя предсказать фиксированные значения, если система предназначена для адаптации к новым распределениям входных данных с течением времени. Как упоминалось выше, можно отслеживать входные и выходные распределения значений и выдавать предупреждения в случае их изменения. В случае значительного изменения, возможно, стоит пересмотреть и, при необходимости, обновить систему. Некоторые ручные ограничения также могут быть установлены. Возможно, имеет смысл запретить торговым алгоритмам инвестировать все деньги в одну акцию или запретить им устанавливать учетную цену до смехотворных сумм.
Другие сферы задолженности, связанной с отмыванием денег
Задолженность по тестированию данных
Как уже упоминалось ранее, тестирование данных как минимум на выбросы имеет решающее значение для нормального функционирования системы. Более продвинутые методы оценки распределения данных полезны для более тонких изменений.
Долг воспроизводимости
Воспроизводимость важна для реального использования систем машинного обучения. После разработки модель должна работать так же, как и реальные данные, как это было на этапе разработки.
Задолженность по управлению процессами
По мере увеличения количества систем ручное управление отнимает все больше времени. Поэтому важно попытаться упростить и исключить ручные шаги и создать более оптимизированные пайплайны.
Культурный долг
Не должно быть жесткой границы между инженерным и исследовательским отделами. Они оба должны взаимодействовать и сотрудничать. Это помогает снизить сложность системы и повысить воспроизводимость; таким образом, что приводит к долгосрочному улучшению состояния системы.
Я надеюсь, что этот пост поможет вам помнить о типах долгов, возникающих в системах ML, и о том, как их избежать или, по крайней мере, свести к минимуму.
[1] Скалли Д., Холт Г., Головин Д., Давыдов Э., Филлипс Т., Эбнер Д., Чаудхари В., Янг М., Креспо Дж. Ф. и Деннисон, Д. (2015). Скрытый технический долг в системах машинного обучения. Достижения в системах обработки нейронной информации, 28, 2503–2511.
Понравилось? Также я публикую видео в своем личном блоге. У тебя есть вопросы? Напишите мне в Twitter или LinkedIn. Эта история была первоначально опубликована по адресу https://rocreguant.com/hidden-technical-debt-in-machine-learning-systems-paper-summary/2088/
