Андела спонсировала этот пост.
Это первая из двух статей.
Что происходит, когда ваша система машинного обучения тихо выходит из строя, и никто этого не замечает? В отличие от традиционных систем, которые выходят из строя громко и очевидно, системы ИИ имеют тенденцию выходить из строя тихо и незаметно. Они не всегда выдают ошибки, протоколируют трассировку стека или вызывают оповещения. Вместо этого они постепенно деградируют – незаметно и со временем – пока ущерб не будет нанесен.
Эта тихая неудача может иметь разрушительные последствия.
Представьте себе систему рекомендаций, которая начинает дрейфовать из-за устаревших введенных функций и продолжает выдавать нерелевантные предложения в течение нескольких недель. Или модель классификации изображений, которая получает поврежденные данные переобучения и начинает неправильно классифицировать элементы высокого риска, но продолжает предоставлять прогнозы, не поднимая флага. Или еще хуже: чат-бот службы поддержки клиентов, который возвращает все более бессвязные ответы из-за несоответствия версий модели, и никто этого не замечает, пока доверие пользователя не потеряется.
Это не гипотетические сценарии; они часто встречаются в жизненном цикле систем искусственного интеллекта и машинного обучения (ML).
Конвейеры искусственного интеллекта по своей сути хрупкие:
- Они зависят от вышестоящих источников данных, которые могут изменить структуру без предупреждения.
- Они полагаются на распределенные асинхронные рабочие процессы, которым не хватает встроенной отказоустойчивости.
- Они постоянно развиваются (посредством переобучения, обновления моделей, разработки функций), но часто без надежных гарантий регрессии.
А инструменты, которые мы используем для мониторинга традиционного программного обеспечения — показателей ЦП, задержки запросов, журналов ошибок — не фиксируют этих скрытых ухудшений. На первый взгляд трубопровод может выглядеть здоровым, но при этом незаметно выдавать вредные и неточные результаты.
Вот тут-то и приходит на помощь хаос-инжиниринг.
Хаос-инжиниринг, популяризированный Netflix, предполагает намеренное внесение ошибок в систему, чтобы наблюдать, как она ведет себя в условиях стресса. Цель состоит не в том, чтобы вызвать сбой, а в том, чтобы укрепить уверенность в способности системы противостоять сбоям.
До сих пор хаос-инжиниринг широко применялся к инфраструктуре — сетям, контейнерам, API — но следующий рубеж — системы искусственного интеллекта и машинного обучения.
Почему хаос-инжиниринг важен для искусственного интеллекта
Хаос-инжиниринг традиционно возникал как способ проверки устойчивости распределенных систем. Подумайте о том, как Netflix случайным образом отключает серверы с помощью Chaos Monkey, чтобы гарантировать, что сервис сможет пережить реальные сбои. Разработанные инструменты и методы были сосредоточены на наблюдаемых низкоуровневых инфраструктурных неисправностях:
- Имитация сетевых разделов или высокой задержки для проверки таймаутов микросервисов.
- Уничтожение модулей или контейнеров Kubernetes для проверки механизмов аварийного переключения служб.
- Вызов конфликта ресурсов (например, регулирование ЦП), чтобы измерить реакцию автомасштабирующих устройств. Это жизненно важные тесты, но они в основном касаются доступности системы и отказоустойчивости на уровне инфраструктуры.
Системы искусственного интеллекта выходят из строя по-другому и более опасно
В конвейерах AI/ML сбои редко бывают двоичными. Системы не обязательно перестают отвечать или выдают исключения, когда что-то ломается. Вместо этого система продолжает работать, но не так, как вы думаете.
Эти системы деградируют тонким, скрытым и зачастую бесшумным образом:
- Устаревшие наборы данных: конвейер переобучения может извлечь устаревший или неправильно помеченный набор данных, в результате чего модель будет хорошо выглядеть на тестовых данных, но будет совершенно неточной в рабочей среде.
- Искаженные функции ввода: Смещение признаков происходит, когда текущие данные вывода расходятся с обучающим распределением. Ваша модель по-прежнему работает, но прогнозы со временем становятся менее надежными.
- Ошибка зависимости внешнего API: Многие современные системы машинного обучения полагаются на внешние API для расширения возможностей (погода, геолокация, языковой перевод). Если API молча возвращает частичные или искаженные данные, ваша логика разработки функций может выйти из строя, не вызывая оповещения.
- Несоответствие версий модели: новая версия модели развертывается без обновления последующих клиентов или конфигурации. Модель предоставляет прогнозы, но потребитель интерпретирует их неправильно, поскольку ожидает другой схемы вывода.
- Регрессии качества данных: Представьте, что ваша исходная система начинает регистрировать «нулевое значение» для критического поля. Сбоя в инфраструктуре нет, но ваша модель машинного обучения теперь работает с мусорными входными данными.
Что делает сбои ИИ такими опасными?
Зачем вносить хаос в конвейеры машинного обучения?
Потому что тестирование сценариев сбоя ИИ в промежуточных средах часто является нетривиальной задачей:
- Вы не всегда можете воспроизвести реальный дрейф функций.
- Трудно смоделировать перебои в восходящем потоке данных в «песочнице».
- Большинство исследователей данных тестируют свои модели, предполагая, что мир ведет себя так, как ожидалось.
Внося целенаправленный хаос в ваши конвейеры машинного обучения, вы укрепляете уверенность в том, что ваша система сможет обнаруживать, обрабатывать или корректно отказывать в условиях неизбежной неопределенности. Это включает в себя:
- Проверка того, обнаруживают ли ваши уровни проверки данных аномалии.
- Проверка резервных механизмов при обслуживании модели
- Измерение поведения детекторов дрейфа в шумных условиях
- Наблюдение за влиянием на бизнес обслуживания устаревших моделей
Устойчивость ИИ — это не только время безотказной работы; речь идет о достоверности ваших прогнозов. Вот почему хаос-инжиниринг в МО больше не является обязательным. Это важнейшая часть развертывания надежных аналитических данных производственного уровня.
Распространенные виды сбоев в конвейерах машинного обучения
Конвейеры машинного обучения — это сложные многоэтапные системы, состоящие из сбора данных, разработки функций, обучения моделей, проверки, развертывания и мониторинга. В отличие от традиционного программного обеспечения, эти конвейеры часто выходят из строя незаметно — без исключений, предупреждений или очевидных сбоев.
Вместо того, чтобы пойти вниз, они идут не так, как надо, тихо и коварно.
Давайте разберем наиболее распространенные виды сбоев, как они выглядят и как вы можете намеренно протестировать их, используя принципы хаос-инжиниринга.
1. Сбои при приеме данных
Каждая модель ML хороша настолько, насколько хороши данные, которые она обучает и использует. Прием данных часто является первым и самым хрупким этапом конвейера. Если он выйдет из строя (тихо или катастрофически), ваш трубопровод может стать бесполезным, даже если он кажется работоспособным.
Что может пойти не так:
- Ответы API задерживаются или являются неполными.
- Вышестоящие системы молча удаляют поля или меняют схемы.
- Кодировки файлов, часовые пояса и форматы изменяются без предварительного уведомления.
Что тестировать:
- Имитировать отсутствующие или задержанные данные (например, задержку файла S3 или тайм-аут API). Внедряйте искаженные записи в озеро или поток данных.
- Замените живые входные данные статическими/устаревшими наборами данных, чтобы имитировать задержку конвейера.
2. Функциональные инженерные ошибки
Конвейеры функций хрупкие и часто недостаточно протестированные. Небольшая проблема с преобразованием может вызвать дрейф данных, снизить точность модели или даже сделать прогнозы бессмысленными.
Что может пойти не так:
- Значения функций отображаются в новых форматах (истина или «истина»). Новые категории появляются в категориальных столбцах.
- Производные функции рассчитываются по-разному при обучении и выводе.
Что тестировать:
- Вставьте NaN (не число) или неожиданные строки в столбцы объектов.
- Удалите часто используемую функцию из вашего рабочего конвейера.
- Имитируйте невидимые категории в производственных данных.
3. Сбои в обучающих данных
Обучение — это то, где модель учится «понимать» мир. Если данные обучения ошибочны, модель уверенно обучается неправильному поведению.
Что может пойти не так:
- Метки смещены из-за неправильных объединений или фильтров.
- Старые данные непреднамеренно повторно используются из кэша.
- Утечка данных загрязняет наборы проверки.
Что тестировать:
- Перетасуйте метки случайным образом и измерьте падение точности.
- Вносите образцы с неправильной маркировкой в контролируемых количествах.
- Отключите класс от обучения и посмотрите, как отреагирует модель.
4. Ошибки версии модели и развертывания
Модель CI/CD все еще развивается. Несоответствие версий между обучающими, обслуживающими и клиентскими системами — это бомба замедленного действия.
Что может пойти не так:
- Более новая модель имеет другую схему вывода, но не имеет последующих обновлений.
- При откате развертывается более старая модель без надлежащей проверки.
- Модель обучена на неправильном наборе функций.
Что тестировать:
- Разверните намеренно несовместимую версию модели.
- Имитируйте отсутствующие метаданные в реестре модели.
- Произвольно меняйте теги модели, чтобы проверить дальнейшее влияние.
5. Ошибки обслуживания и вывода
Модель в производстве — это не просто файл, это работающий сервис. Он может сломаться из-за проблем с инфраструктурой, ошибок сериализации или просто запуска в неправильной среде.
Что может пойти не так:
- Зависимости между средой обучения и обслуживания не совпадают.
- Ограничения графического процессора/процессора приводят к тайм-аутам.
- Ошибки сериализации не обнаруживаются тестами.
Что тестировать:
- Введите случайную задержку в ответах сервера модели.
- Измените версии Python/Numpy в обслуживающих контейнерах.
- Отбрасывайте критические функции во время вывода и отслеживайте поведение.
6. Мониторинг, дрейф и поломки контура обратной связи
Многие сбои в машинном обучении остаются незамеченными просто потому, что никто не смотрит на правильные показатели. Если вы не следите за качеством прогнозов или отклонением данных, вы летите вслепую.
Что может пойти не так:
- Детекторы дрейфа неправильно настроены или отключены.
- Петли обратной связи являются неполными или смещенными.
- Бизнес-ключевые показатели ухудшаются, а технические информационные панели остаются зелеными.
Что тестировать:
- Внедрите управляемый занос в часть реального трафика.
- Имитируйте искажение обратной связи, исключая определенные группы пользователей.
- Временно отключите оповещения, чтобы проверить задержку обнаружения.
Выход за пределы хрупкости: следующий шаг в обеспечении устойчивости машинного обучения
Сложность и присущие современным конвейерам машинного обучения зависимости — от приема данных до обслуживания моделей — делают их уникально уязвимыми к сбоям. Будь то дрейф данных, неожиданное изменение API в облачной службе или упущенный из виду скачок задержки из хранилища функций, ожидание возникновения инцидента — это верный путь к катастрофе в производстве.
Применяя хаос-инженерию для систем искусственного интеллекта, вы можете решать проблемы, а не просто реагировать на них. Это может повысить уверенность в том, что модели и конвейеры будут вести себя так, как ожидается, даже если ключевые компоненты подвергаются нагрузке или полностью выходят из строя. Цель состоит не в том, чтобы просто увидеть, как что-то ломается; это создание надежных систем.
Во второй части этой серии мы перейдем от теории к практике, углубляясь в практические шаги по введению хаоса в наиболее чувствительные части вашего стека MLOps для повышения устойчивости производственного уровня.
Andela предоставляет крупнейшую в мире частную рыночную площадку для талантов удаленных технологий, управляемую платформой на базе искусственного интеллекта для управления полным жизненным циклом найма по контракту. Andela помогает компаниям масштабировать команды и быстрее реализовывать проекты в специализированных областях: разработка приложений, искусственный интеллект, облако, данные и аналитика. Узнайте больше Последние новости от Анделы ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Тинега — старший инженер DevOps и технолог в Andela, частной глобальной торговой площадке для технических талантов. Тинега начал свою карьеру в сфере технологий в 2018 году после получения стипендии Google Africa Developer Scholarship — программы обучения Анделы в партнерстве с Google. Тинега… Читать далее от Тинега Ончари
