DataTalksClub - Building an ML System; Behind the Scenes
Юджин Ян рассказывает о выступлении на конференции DataTalks.Club, где он описал архитектуру ML-системы, построенной для крупнейшей больничной группы Юго-Восточной Азии. Данные из больниц шифруются, передаются на SFTP-сервер, проходят через staging-зону и RDBMS, далее идут в data science пайплайн с подготовкой данных, feature engineering и валидацией модели. Для логирования используется ELK-стек, оркестрация на Airflow, публикация эндпоинтов через Jenkins, всё развёрнуто в Azure. Автор подчёркивает важность time-based валидации вместо случайного разбиения, отдельных моделей для каждой больницы (вместо одной общей) и общения с доменными экспертами. Главный вывод: машинное обучение составляет менее 20% усилий — методология, инженерные практики и понимание задачи важнее самого ML.
DataTalksClub — Создание ML-системы: закулисье
[ machinelearning production ] · 5 мин чтения
На этой неделе у меня была возможность провести закулисный тур по созданию системы машинного обучения для крупнейшей больничной группы Юго-Восточной Азии на конференции DataTalks.Club. Видео доступно ниже. В этом посте мы обсудим несколько ключевых моментов.
• • •
Общая архитектура: от данных к эндпоинту и обратно к данным
Архитектура системы машинного обучения: от данных до эндпоинта модели.
Серая пунктирная линия (слева) отделяет среду больниц от нашей. Больницы хранят данные, включая информацию о пациентах, врачах и случаях лечения. Эти данные периодически извлекаются, шифруются и передаются на наш SFTP-сервер. Затем мы расшифровываем, валидируем и сохраняем сырые, неструктурированные данные (например, CSV, parquet-файлы и т. д.) в нашей staging-зоне. Сырые данные затем парсятся и сохраняются в нашей RDBMS.
Воркфлоу data science читает данные (из табличных баз) и пропускает их через пайплайн, включающий подготовку данных, feature engineering, машинное обучение и валидацию модели. (Подробности — в самом докладе.)
Обученная модель сохраняется в нашем хранилище моделей. Модели могут иметь различные форматы, например pickle-файлы, форматы конкретных библиотек (например, PyTorch) или Docker-образы со встроенным кодом сервинга. Эти модели затем отправляются на publishing-сервер, который версионирует и развёртывает их. Версионирование моделей позволяет легко откатывать развёртывания, что служит страховкой (на случай, если деплой пойдёт не так).
У каждой больницы есть свой уникальный эндпоинт модели, и она сохраняет полученные предсказания (мы также логируем эти предсказания на своей стороне). Это замыкает весь цикл и обеспечивает обратную связь для валидации и улучшения качества модели.
Логирование и мониторинг ведутся через стек ELK, оркестрация — через Airflow, публикация эндпоинтов — через Jenkins. Реализация выполнена на Python и развёрнута в Azure (распространённом облачном провайдере, используемом организациями здравоохранения в Юго-Восточной Азии).
Большинство продакшен-систем должны использовать валидацию по времени
Разница между случайным разбиением и разбиением по времени.
В большинстве продакшен-систем данные имеют ярко выраженный временной аспект. Поэтому использование случайного train-test разбиения или кросс-валидации даст чрезмерно оптимистичный результат. Это было особенно актуально для наших данных, где у многих пациентов было больше одного визита, и случайное разбиение могло привести к тому, что будущие визиты в больницу используются для предсказания прошлых визитов. Поэтому вместо этого следует использовать разбиение по времени.
Однако есть и исключения. Например, классификатор товаров, который категоризирует продукты на основе изображения или текста (например, заголовка, описания). Связь между изображениями/текстом и категорией товара, скорее всего, стабильна во времени. Поэтому, вероятно, разница между случайным разбиением и разбиением по времени будет небольшой.
Утечки данных происходят, если мы не используем валидацию с разбиением по времени.
Разные советы и ключевые выводы
Во время Q&A организатор конференции Алексей заметил, что слайды с разными советами и ключевыми выводами, возможно, самые важные. Я согласен. Вот краткое изложение:
Три простых тезиса, оказавших непропорционально большое влияние на итоговые результаты.
Уделяйте время обучению у доменных экспертов и пользователей. Разрабатывая и улучшая нашу систему, я посещал больницы и наблюдал, как медсёстры и сотрудники стоек используют свою старую систему, а затем и нашу новую. Это помогло мне узнать о предположениях и эвристиках, которые они применяли при работе с системами, и дало представление о новых признаках (для нашей ML-модели), которые снизили ошибку. Я также консультировался с администраторами больниц, чтобы лучше понять и очистить данные — это тоже помогло снизить ошибку.
Больше данных и/или признаков != лучшая модель. Изначально я планировал использовать все данные из разных больниц для построения единой модели — я предполагал, что модель сможет выучить особенности каждой больницы. Это оказалось не так (или, возможно, мои модели были недостаточно мощными). Построение отдельной модели для каждой больницы работало намного лучше (то есть существенно меньшая ошибка). В ретроспективе это логично, поскольку больницы отличались ценовой категорией (например, 5-звёздочный отель против государственной больницы), специализацией по операциям и заболеваниям, врачами и т. д.
Правильные инженерные практики облегчают жизнь. Помимо инженерных практик в коде (например, тестов, линтинга, проверки типов и т. д.), внедрение версионирования артефактов модели позволяло нам откатывать «дефектные» модели, если бы это понадобилось (но не понадобилось). Docker помог нам инкапсулировать и горизонтально масштабировать эндпоинты моделей, а ELK-стек обеспечил столь необходимую видимость по всему пайплайну. Всё это значительно упростило развёртывание и эксплуатацию ML-системы.
Машинное обучение — это менее 20% усилий; методология и инженерный процесс важнее. Большая часть улучшений системы пришла из общения со стейкхолдерами для понимания задачи, определения правильных прокси-метрик и осмысления данных. Кроме того, как показывает архитектурная схема, машинное обучение — это лишь небольшая часть всей системы. И я не затрагивал темы инфраструктуры, сетей, поддержки, мониторинга и т. д.
Я делился похожим мнением в ответ на вопрос Vicki Boykis, и некоторые люди, кажется, со мной согласились.
Большая часть импакта происходит за пределами кода.• Выбор правильных задач для решения• Определение прокси-метрик, соответствующих реальному миру• Быстрое изучение существующих решений• Проектирование простейшей системы для сложной задачи• Поддержка с минимальными операционными издержками— Eugene Yan (@eugeneyan) 6 февраля 2021
• • •
Распространённое узкое место, которое я вижу в стартапах и SME, — это чрезмерный фокус на применении машинного обучения к батч-данным, обычно CSV-файлам, что даёт искусственно сильные результаты, переобученные и невоспроизводимые в продакшене. Надеюсь, этот доклад помог лучше понять, как этого избежать и разработать продакшен-уровневую ML-систему.
Спасибо @Al_Grigor за приглашение выступить на конференции @DataTalksClub! Было приятно поделиться тем, что происходило за кулисами при создании ML-системы для крупнейшей больничной группы Юго-Восточной Азии. Видео и резюме 👇https://t.co/KQDKGVOvMK— Eugene Yan (@eugeneyan) 11 февраля 2021
Если вы нашли это полезным, пожалуйста, цитируйте материал так:
Yan, Ziyou. (Feb 2021). DataTalksClub - Building an ML System; Behind the Scenes. eugeneyan.com. https://eugeneyan.com/speaking/machine-learning-in-healthcare/.
или
@article{yan2021healthcare, title = {DataTalksClub - Building an ML System; Behind the Scenes}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Feb}, url = {https://eugeneyan.com/speaking/machine-learning-in-healthcare/} }
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.