В знаменитой статье Google, опубликованной Sculley et al. в 2015 году Скрытый технический долг в системах машинного обучения говорится, что в системах машинного обучения (ML) только небольшой блок является настоящим кодом ML.
Будучи менеджером по продукту для продукта андеррайтинга на основе ИИ, я понял, что код машинного обучения устаревает быстрее, чем молоко.
Время от времени клиент выдвигал новое требование добавить новую переменную (точку данных), и для них это была всего одна новая переменная, но для команды это может стать совершенно новым циклом перестроения модели, проверки зависимостей, а затем запустить модель в производство.
Теперь основные трудности при этом заключаются в том,
- Есть несколько команд, занимающихся инженерами данных, учеными, инженерами по машинному обучению или разработчиками. Инженеры данных могут создавать конвейеры, чтобы сделать данные доступными, в то время как специалисты по данным беспокоятся о построении и улучшении модели машинного обучения. Затем инженерам по машинному обучению или разработчикам придется беспокоиться о том, как интегрировать эту модель и выпустить ее в производство. Как только дело доходит до того, что в процесс вовлечено несколько человек, ошибки неизбежны.
- Теперь все эти команды могут использовать разные инструменты и рабочие процессы, что затрудняет автоматизацию процесса, и в конечном итоге он становится неконтролируемым.
- Управление версиями — еще одна проблема, хотя есть такие инструменты, как Git, которые упрощают работу, но проблема по-прежнему сохраняется в организациях, где они не понимают важности управления версиями и напрямую погружаются в создание моделей машинного обучения и управление ими.
Простое и единственное решение проблемы, описанной выше, состоит в том, чтобы объединить межфункциональные команды и, используя их знания Agile и DevOps, создать комплексную систему машинного обучения. Кроме того, начните использовать такие инструменты, как Git и Jira, чтобы отслеживать, что было доставлено ранее, и что представляет собой новое обновление, чтобы вы могли откатиться в случае, если модели машинного обучения вашей мечты не сработают в производственной среде.
Теперь мы поняли проблему, давайте разберем ее, чтобы найти решение.
- Начнем с данных
Данные должны быть свободны от ошибок и должны быть в форме и форме, которую ожидает Data Scientist, ryt?
Попробуем разобраться в этом.
Я всегда привык думать, что чем больше данных, тем лучше прогноз моделей. Но теперь я знаю, это также создает большую зависимость от источников данных. Чем больше источников, тем сложнее становится эта проблема.
Таким образом, независимо от того, какой вариант архитектуры у вас есть, важно, чтобы данные были легко обнаруживаемыми и доступными. Вы можете использовать архитектуру озера данных, более традиционное хранилище данных, набор потоков данных в реальном времени или архитектуру децентрализованной сетки данных в соответствии с потребностями вашей компании.
Прозрачные и доступные данные помогут специалистам по данным легко определить лучшие характеристики данных.
Теперь данные могут изменяться по двум разным осям: структурные изменения схемы и фактическая выборка данных с течением времени.
Как обсуждалось выше, необходимо управлять правильным управлением версиями данных и должным уведомлением об отклонении данных. Это можно сделать, проверив отклонение данных в результатах модели.
Мы продолжим глубокое погружение и перейдем к обучению воспроизводимой модели в следующей статье.
А пока берегите себя, хорошего дня впереди!
Хотел бы связаться по LinkedIn
