В последние годы искусственный интеллект достиг впечатляющих высот, благодаря развитию глубокого обучения и масштабированию вычислений. Однако несмотря на этот технологический прогресс, область эксплуатации моделей машинного обучения, известная как MLOps, сталкивается с серьёзными вызовами. Необходимость сделать системы машинного обучения надёжными и предсказуемыми стоит особенно остро в каждом промышленном приложении, но особенности ИИ создают уникальные сложности, которые традиционные методы эксплуатации программного обеспечения не способны успешно решить. Эти проблемы влияют на безопасность, качество, управляемость и масштабируемость современных ML-систем и требуют более глубокого осмысления и разработок. В отличие от классических программных систем, где исходный код и конфигурации определяют детерминированное поведение, ML-модели обладают стохастическим характером, а система в значительной мере зависит от данных, на которых модель обучалась.
Это меняет правила игры и ставит под вопрос привычные способы контроля и обновления сервисов. Например, мониторинг "здоровья" классического приложения сводится к проверке отклика на простые запросы, тогда как для ML-систем определить качественную метрику отклика крайне сложно из-за вариативности результатов и зависимости от пользовательского контекста. Одной из наиболее острых проблем в MLOps является измерение качества модели непосредственно в продакшене. Во время разработки модели можно относительно легко оценивать её точность на тестовых данных, но в боевых условиях условия значительно меняются. Многие компании используют традиционные методы, такие как повторное проигрывание известных запросов и опрос пользователей для получения обратной связи, однако эти подходы часто не отражают реальное поведение системы.
К примеру, модель может давать более тонкие, но корректные ответы, которые не совпадают с заранее заданными эталонными значениями, что сбивает с толку автоматические системы оценки. Часто при обновлении моделей применяется метод канареечной отправки новых версий - постепенное увеличение нагрузки на новый вариант с тщательным контролем. Тем не менее волатильность ответа и взаимовлияние нескольких одновременно работающих моделей затрудняют однозначное определение, когда новая модель действительно лучше старой. Из-за этого гарантировать непрерывное качество и отказоустойчивость становится сложнее, а "катастрофические" ошибки в продакшене остаются возможными. Другая важная задача - версионирование моделей и отслеживание их происхождения, или provenance.
В классическом ПО контроль версий давно стандартизирован, но в ML-системах на практике часто невозможно понять, что именно изменилось между двумя версиями модели. Модель тесно связана с исходными данными, схемами их обработки, посттренировочными трансформациями и даже политиками безопасности и фильтрации, которые влияют на поведение. Все эти компоненты должны версионироваться и документироваться, чтобы обеспечить воспроизводимость, прозрачность и юридическое соответствие, но еще не разработаны универсальные стандарты и инструменты для такой сложной задачи. Отсутствие прозрачной истории изменений усложняет расследование инцидентов и повышает риски при развертывании. Множество компаний откладывают внедрение систем управления версиями из-за кажущейся сложности и затрат, но в итоге платят высокую цену в виде трудозатрат на устранение ошибок и снижения доверия пользователей.
Немаловажным аспектом является мониторинг и наблюдаемость моделей в реальном времени. В традиционных ИТ-продуктах мониторинг считается обязательным и развивается десятилетиями, а вот в мире машинного обучения далеко не все компании скрупулезно отслеживают работу своих моделей после запуска. Исследования показывают, что около половины специалистов не мониторят поведение своих моделей в продакшене. Это приводит к тому, что повреждения или ухудшение качества продукции могут оставаться незамеченными до момента серьёзных проблем. Трудности мониторинга связаны с отсутствием стабильных и понятных метрик качества, которые можно было бы постоянно отслеживать и на основе которых строить оповещения.
Кроме того, сложность моделей и постоянное влияние пользовательского поведения делают стандартные методы алертинга с жёсткими порогами малоприменимыми. Также в рамках крупной организации не всегда понятно, какая команда отвечает за мониторинг и реакцию на инциденты, что вносит дисбаланс в процесс поддержки ML-приложений. Не менее серьёзной проблемой является управление эффективностью вычислительных ресурсов и затратами. Аппаратное обеспечение для обучения и вывода моделей, в частности специализированные GPU, остаются дорогостоящими и ограниченными в плане доступности. Традиционные подходы для балансировки нагрузки и оценки стоимости запросов, применяемые в классической ИТ-инфраструктуре, не подходят для ML из-за неоднородности запросов, вариативности сложностей обработки и множества параллельно работающих моделей с разными оптимизациями и назначениями.
Из-за сильной фрагментации ресурсов и необходимости поддерживать резерв и специализацию возникают так называемые "заброшенные" или невостребованные вычислительные емкости, которые существенно снижают рентабельность эксплуатации. Порой компании пытаются частично решить проблему, используя эти ресурсы для пакетной обработки задач с низким приоритетом, но в целом она не устраняет фундаментальную проблему высокой стоимости и низкой гибкости. Очевидной потребностью является разработка новых методов оценки нагрузки, коммутации запросов и планирования емкости для обеспечения максимальной эффективности без ущерба качеству и скорости отклика. Безопасность и конфиденциальность данных в ML-системах образуют ещё фронт нерешённых вопросов. Проблемы с утечками данных и нахождением конфиденциальной информации в ответах моделей сегодня являются реальным риском для компаний и пользователей.
Избавиться от нежелательных выходных данных можно только удаляя соответствующую информацию из обучающих выборок, что влечёт за собой потерю качества и полноты моделей. Попытки защитить модели от атак внедрения (jailbreaking) и манипуляций с запросами пока неэффективны в полной мере. Операционные меры вроде мониторинга, фильтрации и применения сложной логики безопасности работают скорее как усложняющий фактор для злоумышленников, но не дают абсолютной гарантии. В целом, современные ML-системы остаются сложными в управлении в плане безопасности и требуют дальнейших исследований как в архитектуре, так и в практике эксплуатации. Хотя ряд стандартных проблем эксплуатации, как, например, распределённая обработка и резервирование сетевых соединений на этапе обучения моделей, уже получил определённые решения, они зачастую связаны с повышением затрат.
Эти вопросы сейчас считаются второстепенными по сравнению с более фундаментальными задачами управления качеством, безопасностью и эффективностью ML-моделей в боевом окружении. Подводя итог, можно сказать, что MLOps переживает глубокий период трансформации и поиска новых парадигм, пригодных для управления системами со свойственной машинному обучению неопределённостью, масштабностью и зависимостью от данных. Для создания надёжных, эффективных и безопасных ИИ-приложений необходимо разработать новые методы измерения качества, версионирования и мониторинга, а также улучшить инструменты управления ресурсами и повысить уровень безопасности. Поиск таких решений обещает стать краеугольным камнем будущего развития индустрии искусственного интеллекта и машинного обучения, открывая путь к более стабильным и прозрачным системам, которые смогут лучше отвечать на вызовы сложной реальности и интересы пользователей. .
