Шаблоны для управления интерфейсом между специалистами по обработке и анализу данных и инженерными командами
Обычная жалоба как от специалистов по данным, так и от инженеров-программистов и заинтересованных сторон заключается в том, что слишком часто проект не дает результатов, потому что его нельзя развернуть в рабочей среде. Это последняя миля проектов по науке о данных, и это кладбище, или минное поле, или [вставьте сюда зловещую метафору].
Существует множество вариаций типов команд, проектов и организаций, которые сталкиваются с этой проблемой. Вариаций так много, что трудно выделить набор универсальных законов для правильного решения проблемы. В отсутствие универсальных правил, возможно, мы можем действовать как антропологи и просто наблюдать за тем, как решаются эти проблемы.
Вот некоторые из наиболее распространенных шаблонов, применяемых в нескольких организациях.
- Конфигурация — ограниченная модель: файл параметров (например, параметры линейной модели)
- Конфигурация — гибкая модель: структура модели и файл параметров (например, PMML)
- Повторная реализация. Команда инженеров повторно реализует модели в базе исходного кода.
- Двоичный — интерфейс вывода: двоичный и загрузочный код (например, сериализованная модель)
Эти подходы предполагают компромисс между гибкостью моделирования и потенциальными проблемами безопасности или кода. Система производства линейных моделей подразумевает, что специалисты по данным просто предоставляют файл конфигурации с коэффициентами для условий модели, и ничего больше. В программном плане можно нанести очень небольшой ущерб. Принимая во внимание, что, с другой стороны, разрешение специалистам по обработке данных добавлять двоичные файлы в производственную систему означает принятие более высокого уровня риска безопасности.
Сценарии с более высоким риском целесообразны, когда организация хочет воспользоваться преимуществами более гибкого моделирования, что обычно означает меньшую ошибку в направлениях, важных для бизнес-задачи. Риски обычно снижаются за счет запуска моделей в изолированных контейнерных системах. Но, тем не менее, данные должны проходить через модель, а бизнес-операции зависят от ее результатов, поэтому риск никогда не устраняется.
Как решить эту долгосрочную проблему?
Современные организации, похоже, стремятся к сочетанию инструментов и разделения труда. Инструментальный подход использует стандартные конвейеры операций машинного обучения (MLOPs) и шаблоны кода. Эти артефакты кода можно сочетать с инструментами автоматического тестирования и анализа кода, которые выявляют очевидные нарушения процесса.
Решение о разделении труда включает принятие идеи найма инженера по машинному обучению, который применяет инженерную дисциплину в сочетании со знанием того, что требуется моделям машинного обучения. В идеале они будут работать в тандеме с учеными, которые понимают бизнес-проблемы и обладают навыками разработки решений, решающих их. Объединенная команда может предоставить решения, которые находят правильный баланс между производительностью бизнеса и технической стабильностью.
Я говорил с Дэйвом Килпински и Троем Садковски на эту тему в недавнем подкасте на YouTube. Вы можете проверить это здесь.
