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

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

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

Вот три фантастических документа по ML/AI, в которых исследуется этот вопрос:

Также ведутся другие обширные исследования, как в академической, так и в практической сфере.

Технический долг в ML и AI проявляется в трех аспектах: 1) зависимости кода, 2) зависимости данных и 3) зависимости системы. Я просматриваю каждый по очереди.

Зависимости кода

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

запутанность

Пакет ML — это инструмент для смешивания источников данных. То есть модели машинного обучения — это машины для создания запутанности и создания практически невозможной изоляции улучшений. Это называется принципом CACE (произносится как «торт»): Изменение чего-либо меняет все. Ничто не является независимым.

Как погасить его. Существует два способа:

  1. Изолируйте модели и сервисные ансамбли, поддерживая баланс затрат между управлением отдельными моделями и обеспечением модульности, что может уменьшить запутанность.
  2. Разработайте методы получения более глубокого понимания поведения прогнозов модели, разработав инструмент визуализации и метрики по многим измерениям.

Скрытые петли обратной связи

Системы, которые учатся на реальном поведении, должны быть частью цикла обратной связи. Например, система прогнозирования рейтинга кликов (CTR) заголовков новостей на веб-сайте, скорее всего, полагается на клики пользователей в качестве обучающих меток, которые, в свою очередь, зависят от предыдущих прогнозов модели. Это приводит к проблемам при анализе производительности системы.

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

Зависимости данных

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

Зависимости данных могут проникнуть в модель ML несколькими способами:

  • Устаревшие функции. Чаще всего функция Z включается в модель на ранней стадии ее разработки. Со временем добавляются другие функции, которые делают Z в основном или полностью избыточными, но это не обнаруживается.
  • Встроенные функции. Иногда набор функций оценивается и оказывается полезным. Однако под бременем крайнего срока или чего-то подобного все функции в комплекте добавляются к модели вместе. Эта динамика может скрывать функции, которые мало или вообще не добавляют никакой ценности.
  • ǫ-features. Исследователи машинного обучения, естественно, находят удовлетворение в повышении точности модели. Может возникнуть соблазн добавить в модель новую функцию для повышения точности, даже если выигрыш в точности очень мал или когда накладные расходы на сложность могут быть высокими.

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

Системные зависимости

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

Код клея

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

Как это окупить. Склеивающий код можно сократить, выбрав повторную реализацию определенных алгоритмов в более широкой системной архитектуре. Поначалу может показаться, что это слишком дорого — повторная реализация пакета машинного обучения на C++ или Java, который уже доступен в R или MATLAB. Но в полученной системе будет меньше связующего кода для интеграции в общую систему.

Трубопроводные джунгли

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

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

Измерение долга и его погашение

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

Некоторые вопросы, которые следует рассмотреть, включают:

  1. Ухудшает ли улучшение одной модели или сигнала другие?
  2. Как быстро мы сможем добавить новых членов в команду с нашей существующей кодовой базой и архитектурой?
  3. Насколько легко полностью новый алгоритм можно протестировать в полном объеме?

Вот некоторые из подходов, которые команды всегда должны рассматривать как передовой опыт:

  • Рефакторинг кода
  • Усовершенствования модульного тестирования
  • Мертвый код и удаление комментариев
  • Сокращение зависимостей
  • Обзор документации

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

Совмия Рамеш Кумар зарегистрирована в LinkedIn.