DataTalksClub - Building an ML System; Behind the Scenes

eugeneyan

eugeneyan

Начать здесь Статьи Выступления Прототипирование О себе

DataTalksClub - Building an ML System; Behind the Scenes

DataTalksClub — Создание ML-системы: закулисье

[ machinelearning production ] · 5 min read

[ machinelearning production ] · 5 мин чтения

This week, I had the opportunity to give a behind the scenes tour of building a machine learning system for Southeast Asia’s largest hospital group, at the DataTalks.Club conference. The video is available below. We’ll discuss a few key points in this post.

На этой неделе у меня была возможность провести закулисный тур по созданию системы машинного обучения для крупнейшей больничной группы Юго-Восточной Азии на конференции DataTalks.Club. Видео доступно ниже. В этом посте мы обсудим несколько ключевых моментов.

• • •

• • •

Overall design: From data to endpoint, and back to data

Общая архитектура: от данных к эндпоинту и обратно к данным

Design of the machine learning system, from data to model endpoint.

Архитектура системы машинного обучения: от данных до эндпоинта модели.

The grey dashed line (on the left) separates the hospitals’ environment from ours. Hospitals store the data, include patient, doctor, and case information. This data is periodically extracted, encrypted, and transported to our SFTP server. We then decrypt, validate, and store the raw, unstructured data (e.g., CSVs, parquet files, etc.) in our staging area. The raw data is then parsed and stored in our RDBMS.

Серая пунктирная линия (слева) отделяет среду больниц от нашей. Больницы хранят данные, включая информацию о пациентах, врачах и случаях лечения. Эти данные периодически извлекаются, шифруются и передаются на наш SFTP-сервер. Затем мы расшифровываем, валидируем и сохраняем сырые, неструктурированные данные (например, CSV, parquet-файлы и т. д.) в нашей staging-зоне. Сырые данные затем парсятся и сохраняются в нашей RDBMS.

The data science workflow reads the data (from the tabular databases) and puts it through the pipeline, including data preparation, feature engineering, machine learning, and model validation. (For more details, please view the talk.)

Воркфлоу data science читает данные (из табличных баз) и пропускает их через пайплайн, включающий подготовку данных, feature engineering, машинное обучение и валидацию модели. (Подробности — в самом докладе.)

The trained model is stored in our model store. Models can take various formats, such as pickle files, library-specific formats (e.g., PyTorch), or Docker images that include serving code. These models are then pushed to the publishing server, which versions and deploys the models. Model versioning lets us easily rollback model deployments, providing an insurance policy (in case a deployment goes awry).

Обученная модель сохраняется в нашем хранилище моделей. Модели могут иметь различные форматы, например pickle-файлы, форматы конкретных библиотек (например, PyTorch) или Docker-образы со встроенным кодом сервинга. Эти модели затем отправляются на publishing-сервер, который версионирует и развёртывает их. Версионирование моделей позволяет легко откатывать развёртывания, что служит страховкой (на случай, если деплой пойдёт не так).

Each hospital has a unique model endpoint and stores the predictions received (we also log these predictions on our end). This completes the entire cycle and provides a feedback loop to validate and improve model performance.

У каждой больницы есть свой уникальный эндпоинт модели, и она сохраняет полученные предсказания (мы также логируем эти предсказания на своей стороне). Это замыкает весь цикл и обеспечивает обратную связь для валидации и улучшения качества модели.

Logging and monitoring is done via the ELK stack, orchestration via Airflow, and endpoint publishing via Jenkins. Implementation was done in Python and deployed on Azure (a common cloud provider used by healthcare organizations in Southeast Asia).

Логирование и мониторинг ведутся через стек ELK, оркестрация — через Airflow, публикация эндпоинтов — через Jenkins. Реализация выполнена на Python и развёрнута в Azure (распространённом облачном провайдере, используемом организациями здравоохранения в Юго-Восточной Азии).

Most prod systems should use time-based validation

Большинство продакшен-систем должны использовать валидацию по времени

The difference between a random-split and a time-based split.

Разница между случайным разбиением и разбиением по времени.

In most production systems, our data will have a strong temporal aspect. Thus, using random train-test split or cross-validation will give an overly optimistic result. This was especially so in our data where many patients had more than one visit, and a random split might lead to using future hospital visits to predict past hospital visits. Thus, a time-based split should be used instead.

В большинстве продакшен-систем данные имеют ярко выраженный временной аспект. Поэтому использование случайного train-test разбиения или кросс-валидации даст чрезмерно оптимистичный результат. Это было особенно актуально для наших данных, где у многих пациентов было больше одного визита, и случайное разбиение могло привести к тому, что будущие визиты в больницу используются для предсказания прошлых визитов. Поэтому вместо этого следует использовать разбиение по времени.

There are exceptions to this though. For example, a product classifier which categorizes products based on image or text (e.g., title, description). The relationship between the images/text and product classification is likely stable over time. Thus, there probably isn’t much difference between a random-split or a time-based split.

Однако есть и исключения. Например, классификатор товаров, который категоризирует продукты на основе изображения или текста (например, заголовка, описания). Связь между изображениями/текстом и категорией товара, скорее всего, стабильна во времени. Поэтому, вероятно, разница между случайным разбиением и разбиением по времени будет небольшой.

Data leaks happen if we're not using a time-based validation split.

Утечки данных происходят, если мы не используем валидацию с разбиением по времени.

Miscellaneous tips and key takeaways

Разные советы и ключевые выводы

During the Q&A, the conference organizer, Alexey, chimed that the slides on miscellaneous tips and key takeaways were probably the most important. I agree. Here’s a brief rundown:

Во время Q&A организатор конференции Алексей заметил, что слайды с разными советами и ключевыми выводами, возможно, самые важные. Я согласен. Вот краткое изложение:

Three simple bullet points that had outsized impact on overall outcomes.

Три простых тезиса, оказавших непропорционально большое влияние на итоговые результаты.

Take time to learn from domain experts and users. While developing and improving our system, I visited the hospitals and observed the nursing and counter staff use their existing system, and eventually, our new system. This helped me learn about the assumptions and heuristics they adopted while using the systems, providing insight into new features (for our ML model) that reduced error. I also consulted hospital administrators for advice on how to better understand and clean the data—this also helped reduce error.

Уделяйте время обучению у доменных экспертов и пользователей. Разрабатывая и улучшая нашу систему, я посещал больницы и наблюдал, как медсёстры и сотрудники стоек используют свою старую систему, а затем и нашу новую. Это помогло мне узнать о предположениях и эвристиках, которые они применяли при работе с системами, и дало представление о новых признаках (для нашей ML-модели), которые снизили ошибку. Я также консультировался с администраторами больниц, чтобы лучше понять и очистить данные — это тоже помогло снизить ошибку.

More data and/or features != better model. My initial approach was to use all the data from the various hospitals to build a single model—I assumed the model could learn about the idiosyncrasies of each hospital. This was not the case (or perhaps my models were underpowered). Building a separate model for each hospital worked much better (i.e., significantly lower error). In hindsight, this makes sense as each hospital was different in price point (e.g., 5-star hotel vs. public hospital), surgery and disease specialization, doctors, etc.

Больше данных и/или признаков != лучшая модель. Изначально я планировал использовать все данные из разных больниц для построения единой модели — я предполагал, что модель сможет выучить особенности каждой больницы. Это оказалось не так (или, возможно, мои модели были недостаточно мощными). Построение отдельной модели для каждой больницы работало намного лучше (то есть существенно меньшая ошибка). В ретроспективе это логично, поскольку больницы отличались ценовой категорией (например, 5-звёздочный отель против государственной больницы), специализацией по операциям и заболеваниям, врачами и т. д.

Proper engineering practices make life easier. Beyond engineering practices in our code (e.g., test cases, linting, type checking, etc.), adopting version control on model artifacts let us rollback “defective” models if we ever needed to (we never did). Docker helped us encapsulate and horizontally scale our model endpoints, while the ELK stack provided much-needed visibility across our entire pipeline. All this made deploying and operating the ML system much easier.

Правильные инженерные практики облегчают жизнь. Помимо инженерных практик в коде (например, тестов, линтинга, проверки типов и т. д.), внедрение версионирования артефактов модели позволяло нам откатывать «дефектные» модели, если бы это понадобилось (но не понадобилось). Docker помог нам инкапсулировать и горизонтально масштабировать эндпоинты моделей, а ELK-стек обеспечил столь необходимую видимость по всему пайплайну. Всё это значительно упростило развёртывание и эксплуатацию ML-системы.

Machine learning is <20% of the effort—the methodology and engineering process are more important. Much of the improvements to the system came from engaging with stakeholders to understand the problem, defining the right proxy metrics, and grokking the data. Also, as the architecture diagram shows, machine learning is really only a small part of the overall system. And I didn’t cover the topics of infra, networking, maintenance, monitoring, etc.

Машинное обучение — это менее 20% усилий; методология и инженерный процесс важнее. Большая часть улучшений системы пришла из общения со стейкхолдерами для понимания задачи, определения правильных прокси-метрик и осмысления данных. Кроме того, как показывает архитектурная схема, машинное обучение — это лишь небольшая часть всей системы. И я не затрагивал темы инфраструктуры, сетей, поддержки, мониторинга и т. д.

I shared a similar sentiment on Vicki Boykis’ question, and some people seemed to agree.

Я делился похожим мнением в ответ на вопрос Vicki Boykis, и некоторые люди, кажется, со мной согласились.

Much of the impact happens outside coding.

• Picking the right problems to solve
• Defining proxy metrics that match the real world
• Learning quickly about existing solutions
• Designing the simplest system to a complex problem
• Maintaining it with minimal ops overhead

Большая часть импакта происходит за пределами кода.• Выбор правильных задач для решения• Определение прокси-метрик, соответствующих реальному миру• Быстрое изучение существующих решений• Проектирование простейшей системы для сложной задачи• Поддержка с минимальными операционными издержками— Eugene Yan (@eugeneyan) 6 февраля 2021

• • •

• • •

A common bottleneck I see in start-ups and SMEs is to focus too much on applying machine learning on batch data, usually CSVs, to achieve artificially strong results that are overfitted and not replicable in production. I hope this talk provided a greater understanding of how to avoid this, and develop a production-grade ML system.

Распространённое узкое место, которое я вижу в стартапах и SME, — это чрезмерный фокус на применении машинного обучения к батч-данным, обычно CSV-файлам, что даёт искусственно сильные результаты, переобученные и невоспроизводимые в продакшене. Надеюсь, этот доклад помог лучше понять, как этого избежать и разработать продакшен-уровневую ML-систему.

Thanks to @Al_Grigor for inviting me to speak at the @DataTalksClub conference! It was a pleasure sharing what went on behind the scenes while building an ML system for Southeast Asia's largest hospital group.

Video and summary 👇https://t.co/KQDKGVOvMK

Спасибо @Al_Grigor за приглашение выступить на конференции @DataTalksClub! Было приятно поделиться тем, что происходило за кулисами при создании ML-системы для крупнейшей больничной группы Юго-Восточной Азии. Видео и резюме 👇https://t.co/KQDKGVOvMK— Eugene Yan (@eugeneyan) 11 февраля 2021

If you found this useful, please cite this write-up as:

Если вы нашли это полезным, пожалуйста, цитируйте материал так:

Yan, Ziyou. (Feb 2021). DataTalksClub - Building an ML System; Behind the Scenes. eugeneyan.com. https://eugeneyan.com/speaking/machine-learning-in-healthcare/.

Yan, Ziyou. (Feb 2021). DataTalksClub - Building an ML System; Behind the Scenes. eugeneyan.com. https://eugeneyan.com/speaking/machine-learning-in-healthcare/.

or

или

@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/} }

@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/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.