A Practical Guide to Maintaining Machine Learning in Production

eugeneyan

eugeneyan

Start Here Writing Speaking Prototyping About

A Practical Guide to Maintaining Machine Learning in Production

Практическое руководство по поддержке машинного обучения в продакшене

[ machinelearning engineering production ] · 16 min read

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

In the previous post, we discussed six little-known challenges after deploying machine learning. As a recap, here are the six groups:

В предыдущем посте мы обсудили шесть малоизвестных проблем, возникающих после развёртывания машинного обучения. В качестве напоминания, вот эти шесть групп:

Данные: изменения схемы у источников загрязняют данные. Модель: рост сложности затрудняет поддержку. Инженерия: фрагментированная кодовая база, конфигурация и инфраструктура. Реальный мир: смещения, контуры обратной связи и злоумышленники. Структура организации: чрезмерное разделение труда замедляет итерации. Клиенты: частые операционные запросы отвлекают от работы

Previous post: 6 Little-Known Challenges After Deploying ML

Предыдущий пост: 6 малоизвестных проблем после развёртывания ML

This follow-up will share some practices I’ve found useful to maintaining machine learning in production. They are:

В этом продолжении я поделюсь практиками, которые оказались полезными для поддержки машинного обучения в продакшене. Вот они:

Мониторинг обучающих и обслуживающих данных на предмет загрязнения Мониторинг моделей на сбои при переобучении Упрощение инженерии для снижения операционной нагрузки Полезные практики для минимизации контуров обратной связи и смещений Структурирование команд для итераций и инноваций Краудсорсинг обработки клиентских жалоб

With close to 20 suggestions, it can get overwhelming. Fret not, I’ll highlight the top three must-haves and good-to-haves at the end of this post.

С почти 20 рекомендациями всё это может показаться перегруженным. Не волнуйтесь — я выделю три главных must-have и good-to-have практики в конце поста.

We'll go through some practical tools to help with maintaining machine learning in prod.

Мы пройдёмся по практическим инструментам, которые помогут поддерживать машинное обучение в prod.

Monitor Training and Serving Data for Contamination

Мониторинг обучающих и обслуживающих данных на предмет загрязнения

Validate your incoming data. “Data is the New Oil.” “Garbage in, Garbage Out.” These clichés emphasize that clean input data is essential to your system. Here’s how you can monitor your incoming data, starting with the most basic. These checks identify errors upfront and save hours spent unnecessarily fixing your pipeline or decontaminating your feature store.

Валидируйте входящие данные. «Данные — это новая нефть». «Мусор на входе — мусор на выходе». Эти клише подчёркивают: чистые входные данные критически важны для вашей системы. Вот как можно мониторить входящие данные, начиная с самого простого. Эти проверки выявляют ошибки сразу и экономят часы, которые могут уйти на починку пайплайна или очистку feature store.

Check the incoming files (if you receive data via a CSV/TSV/JSON dump). Don’t assume the file format will be consistent—a manual job could be creating them.

Проверяйте входящие файлы (если получаете данные через CSV/TSV/JSON-дамп). Не предполагайте, что формат файла будет стабильным — его может создавать ручная задача.

Правильная ли схема? Все ли ожидаемые колонки на месте? Правильный ли формат? (например, парсится ли он как CSV?) Правильная ли кодировка? (например, соответствует ли она UTF-8?) Разумен ли объём данных? Не сильно ли он больше или меньше предыдущих дампов? Если файл зашифрован — не был ли он подменён, например, через man-in-the-middle атаку?

Check the data’s overall distribution.

Проверьте общее распределение данных.

Сколько строк? Количество строк не должно скакать день ото дня. Есть ли null'ы в колонках, где их быть не должно? Не появился ли резкий рост (или падение) доли null'ов в какой-либо колонке? Есть ли дубли в первичных ключах (например, ID клиента, ID товара)? (В зависимости от того, как вы делаете join'ы, дубли могут раздуть количество строк)

Check the features’ distributions.

Проверьте распределения фич.

Для непрерывных фич: разумны ли минимум и максимум? Например, возраст не должен быть ниже 0 или выше разумного порога. Не качаются ли базовые агрегаты (медиана, среднее, межквартильный размах) день ото дня? Для категориальных фич: постоянны ли уникальные значения? Если для пола ожидаются значения Male, Female и Undeclared, то не должно быть дополнительных вроде male или Married. Также — схожа ли доля каждого значения? Для timestamp-фич: тот же ли формат? Это всё ещё dd-mm-yyyy, или какой-то американский DBA изменил его на mm-dd-yyyy? Также разумны ли диапазоны дат? В большинстве случаев у вас не должно быть дат из XVIII века или из будущего.

If you want to get fancy, perform statistical checks

Если хочется чего-то посерьёзнее — выполняйте статистические проверки

Постоянны ли корреляции между фичами и таргетами? Резкий рост указывает на утечку данных; постепенное снижение — на дрифт данных. Обнаруживайте изменения с помощью тестов однородности, ANOVA и анализа временных рядов. То же ли распределение по полу? Используйте chi-squared test, чтобы (не) подтвердить нулевую гипотезу. (Однако если данных много, статистическая значимость может встречаться часто.)

Here’s a recent article on how Uber monitors data quality via multi-dimensional time series and principal component analysis.

Вот недавняя статья о том, как Uber мониторит качество данных с помощью многомерных временных рядов и метода главных компонент.

Check for training-serving skew. It’s often caused by discrepancies between training data and input data during serving, leading to disparity in model performance during training and serving.

Проверяйте training-serving skew. Чаще всего он вызван расхождениями между обучающими данными и входными данными при обслуживании, что приводит к разнице в производительности модели между обучением и боевой эксплуатацией.

When serving, log the input data before and after processing and do some checks.

В режиме обслуживания логируйте входные данные до и после обработки и выполняйте проверки.

Похожи ли serving-данные на training-данные? Если serving-данные более разреженные, то training-данные могут незаметно обогащаться (например, недостающая демографическая информация о клиенте импьютируется для ежедневных отчётов). Идентична ли обработка фич при обучении и обслуживании? Расхождения возникают, когда при обучении (batch) и обслуживании (отдельный запрос) используется разный код.

Minimize training-serving skew by training on served features. If you’re logging data and features during serving, consider using them as training data. To clarify, use historical processed features (during serving) to train your model. This ensures your model learns on data it would receive and predict on during serving—no more training-serving skew.

Минимизируйте training-serving skew, обучая модель на обслуживаемых фичах. Если вы логируете данные и фичи во время обслуживания, рассмотрите их использование как обучающих данных. Уточним: используйте исторически обработанные фичи (полученные при обслуживании) для обучения модели. Это гарантирует, что модель учится на тех же данных, которые она будет получать и предсказывать в продакшене — никакого training-serving skew.

As an extra benefit, you can simplify and shrink your training pipeline. E.g., previous ETL jobs to stitch together clickstreams for training data are no longer needed. Just train on the served features.

В качестве бонуса это упрощает и сокращает обучающий пайплайн. Например, прежние ETL-задачи для сшивания кликстримов под training-данные больше не нужны. Просто обучайтесь на обслуживаемых фичах.

Monitor Models for Misbehaviour When Retraining

Мониторинг моделей на сбои при переобучении

Prune redundant features periodically. After adding features and finding improved model performance, take the extra time to check if all the features are still important. Excluding these redundant features will simplify your model and reduce data pipeline computation cost, with minimal impact on model performance.

Периодически отсеивайте избыточные фичи. Добавив фичи и обнаружив улучшение качества модели, потратьте дополнительное время на проверку — все ли фичи по-прежнему важны. Исключение избыточных упростит модель и снизит затраты на пайплайн данных при минимальном влиянии на качество.

Permutation importance is a cheap way to do this—we simply shuffle each column and assess the change in model performance. An alternative, drop-column importance, iteratively drops each column and retrain and evaluate the model—it’s more expensive as we retrain the model on each iteration, but it’s more accurate.

Permutation importance — дешёвый способ это сделать: мы просто перемешиваем каждую колонку и оцениваем изменение качества модели. Альтернатива, drop-column importance, итеративно отбрасывает каждую колонку, переобучает и оценивает модель — это дороже, поскольку на каждой итерации модель переобучается, зато точнее.

Validate your model before deploying. This is one of my favourites because of its simplicity and effectiveness. When retraining your model, keep a validation hold-out; this could be the latest seven days of data or more, depending on the sample size required. Retrain on the rest of the data.

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

For example, in a product ranker, how does the model perform on the validation set based on the usual ranking metrics (e.g., AUC, NDCG, recall@k)? Also, does it perform better than a naive baseline (e.g., sorting product based on yesterday’s sales)?

Например, в ранжировщике товаров: как модель ведёт себя на валидационном сете по обычным метрикам ранжирования (AUC, NDCG, recall@k)? И превосходит ли она наивный baseline (например, сортировку товаров по вчерашним продажам)?

If the model fails the validation checks above, your pipeline should break and not release the model. Better to have a stale model in production than a misbehaving one. If the model passes the validation check, retrain the model on the whole dataset and release it.

Если модель не проходит валидационные проверки, ваш пайплайн должен сломаться и не выпустить модель. Лучше иметь устаревшую модель в продакшене, чем неисправную. Если модель проходит проверки — переобучите её на полном датасете и выкатывайте.

You could get more in-depth by comparing the predictions of the previous and current model. If your previous model ranks a product at 10,000th but your current model ranks it at 1st, something seems off. This can apply to various types of machine learning problems, be it ranking (difference in rank), classification (difference in probability), and regression (difference in numeric prediction).

Можно копнуть глубже, сравнив предсказания предыдущей и текущей модели. Если предыдущая модель ранжирует товар на 10 000-м месте, а текущая — на 1-м, что-то не так. Это применимо к разным типам задач ML: ранжирование (разница в ранге), классификация (разница в вероятности), регрессия (разница в численном предсказании).

Shadow release your model. You can do this by running your model in production, running some live traffic through it, and logging the outcomes.

Делайте shadow-релиз модели. Это можно сделать так: запустите модель в продакшене, пропустите через неё часть боевого трафика и логируйте результаты.

What is the latency, stability, and error rate—this tells us if the model is production-ready (especially important if there was a big change, such as changing the model from decision trees to neural networks). How do the live predictions perform in terms of metrics (e.g., recall, precision)? Are there more false negatives or false positives?

Какова латентность, стабильность и частота ошибок — это покажет, готова ли модель к продакшену (особенно важно при больших изменениях, например, переходе с деревьев решений на нейросети). Как боевые предсказания выглядят по метрикам (recall, precision)? Больше ли false negatives или false positives?

When applied together, the above two practices ensure end-users do not notice model changes unless there is an improvement.

Применяемые вместе, эти две практики гарантируют, что конечные пользователи не заметят изменений модели, если только это не улучшение.

Monitor your model health. As a first step, check for model staleness. When was the last time you refreshed the production model?

Мониторьте здоровье модели. Первый шаг — проверка устаревания модели. Когда вы в последний раз обновляли продакшен-модель?

Then, take it further by inspecting the model for bias or incorrect learning. This is easier now with tools for model interpretability such as LIME and SHAP. If it’s a loan approval model, does it bias against certain genders, age groups, or ethnicities? (Though I would argue that, in the first place, such data shouldn’t be considered.) How do the most important features change from day-to-day? If a feature jumps in importance, it could suggest a data leak.

Затем копайте глубже — проверяйте модель на смещения или некорректное обучение. Сейчас это проще благодаря инструментам интерпретируемости моделей, таким как LIME и SHAP. Если это модель одобрения кредитов — есть ли смещения против определённых полов, возрастных групп или этничностей? (Хотя я бы поспорил, что таких данных вообще не должно быть в расчёте.) Как меняется важность ключевых фич день ото дня? Если важность фичи резко выросла, это может указывать на утечку данных.

This SHAP summary plot shows sex, passenger class, and age were most important as features.

Этот SHAP summary plot показывает, что sex, passenger class и age были самыми важными фичами.

Meta-analysis on offline vs offline metrics. How well do your offline metrics correlate with online improvements? Does an increase in AUC or NDCG in offline evaluation lead to an increase in click-through rate or conversion rate online?

Мета-анализ offline-метрик против online-метрик. Насколько ваши offline-метрики коррелируют с online-улучшениями? Приводит ли рост AUC или NDCG при офлайн-оценке к росту CTR или конверсии онлайн?

For example, Etsy found AUC to be a good metric to assess CTR while this KDD paper found large discrepancies between offline and online performance of models due to evaluation metrics.

Например, Etsy обнаружили, что AUC — хорошая метрика для оценки CTR, а в этой статье на KDD были обнаружены большие расхождения между offline- и online-качеством моделей из-за метрик оценки.

We make many decisions based on offline evaluation metrics, such as during experimentation and model validation before release. Investing in finding dependable offline metrics will continuously pay dividends.

Мы принимаем множество решений на основе offline-метрик — например, при экспериментах и валидации модели перед релизом. Инвестиции в поиск надёжных offline-метрик будут окупаться непрерывно.

(An aside: When measuring online performance, focus on what your system can have a direct impact on, such as clicks, purchases, bounce rate. Consider indirect metrics (e.g., user return rate, daily average users) only after you grok the direct metrics. Avoid delayed and big-picture metrics (e.g., user satisfaction, traffic growth)—there could be multiple confounding factors for these.)

(К слову: при измерении online-качества фокусируйтесь на том, на что ваша система может напрямую влиять — клики, покупки, bounce rate. Косвенные метрики (например, retention, daily active users) рассматривайте только после того, как разберётесь с прямыми. Избегайте отложенных и общих метрик (удовлетворённость пользователей, рост трафика) — у них может быть много мешающих факторов.)

Simplify Engineering to Reduce Operational Burden

Упрощение инженерии для снижения операционной нагрузки

Log your configuration details. This extends to both experimentation and production workflows. Model hyperparams? Log it. The threshold to convert probabilities to binary? Log it. The period of historical training data used? Log it. Heck, might as well log the commit hash too.

Логируйте детали конфигурации. Это касается как экспериментальных, так и продакшен-воркфлоу. Гиперпараметры модели? Логируйте. Порог конвертации вероятностей в бинарные значения? Логируйте. Период исторических обучающих данных? Логируйте. Чёрт возьми, логируйте даже хэш коммита.

I’ve found MLflow to be a lightweight library for this purpose. With a small amount of additional code, you can log configurations, code commits, and results (e.g., evaluation metrics, graphs, sample CSVs). All accessible in a centralised dashboard. Here’s a previous post on it.

Я считаю MLflow лёгкой библиотекой для этой цели. Небольшим объёмом дополнительного кода вы сможете логировать конфигурации, коммиты кода и результаты (метрики оценки, графики, sample CSV). Всё доступно в централизованном дашборде. Вот предыдущий пост об этом.

Serve your models via containers. Or VMs, if that’s more of your thing. The intent is to remove variability between training and serving environments. No more “But it runs on my machine…” troubles.

Обслуживайте модели через контейнеры. Или VM, если вам так больше нравится. Цель — устранить различия между средами обучения и обслуживания. Никаких больше «но у меня на машине работает…».

Docker seems to be the de facto container technology now. It enables "build once, run everywhere", and scales well horizontally. Good articles on docker for machine learning deployment here and here.

Docker сейчас де-факто стал контейнерной технологией. Он обеспечивает принцип «собери один раз — запусти везде» и хорошо масштабируется горизонтально. Хорошие статьи про Docker для деплоя машинного обучения здесь и здесь.

Build in rollback capability. If, for some reason, a refreshed model passes the above data and model validation checks but misbehaves when deployed, you’ll want to quickly revert. This rollback capability is your insurance policy.

Заложите возможность отката. Если по какой-то причине обновлённая модель прошла проверки данных и валидацию, но плохо ведёт себя после деплоя, вы захотите быстро откатиться. Эта возможность отката — ваш страховой полис.

If you’re using Docker containers to serve, this is straightforward—just pick up the previous working container from the repository and deploy it to replace the faulty model. Keep working images from previous deployments in your repository, seven or more if resources permit.

Если вы обслуживаете модели через Docker-контейнеры — это просто: возьмите предыдущий рабочий контейнер из репозитория и задеплойте его взамен неисправной модели. Храните рабочие образы предыдущих деплоев в репозитории — семь или больше, если позволяют ресурсы.

This ensures you immediately fix the problem for customers. Once the pressure is off, you’ll be able to better focus on digging into the root cause and resolving it.

Это позволяет немедленно устранить проблему для клиентов. Когда давление спадёт, вы сможете спокойнее разобраться с первопричиной и устранить её.

Make a conscious effort to keep things simple. Start simple. Keep your system simple as long as possible. Complexity will creep in—beat it back. Here’s how one successful start-up did it:

Сознательно держите всё простым. Начинайте с простого. Держите систему простой так долго, как только можно. Сложность будет подкрадываться — отбивайтесь. Вот как это сделал один успешный стартап:

When Instagram was acquired in 2012, it had a 13-person team serving tens of millions of users. It scaled and kept operational burden per engineer low by sticking to proven technologies instead of new, shiny ones. When other startups adopted trendy NoSQL data stores and struggled, Instagram kept it lean with battle-proven and easy to understand PostgreSQL and Redis.

Когда Instagram купили в 2012-м, у них была команда из 13 человек, обслуживавшая десятки миллионов пользователей. Они масштабировались и удерживали низкую операционную нагрузку на инженера, придерживаясь проверенных технологий вместо новых модных. Пока другие стартапы внедряли модные NoSQL-хранилища и мучились с ними, Instagram оставался поджарым с проверенными в боях и понятными PostgreSQL и Redis.

For machine learning systems, start with simple, interpretable models, minimal features, and no ensembling. Have model refreshes at a bearable cadence (e.g., weekly or daily) and don’t spring for real-time updates right off the bat. Start with a general model that works for most users before moving to personalisation.

Для ML-систем начинайте с простых, интерпретируемых моделей, минимального набора фич и без ансамблей. Обновляйте модель с приемлемой частотой (например, еженедельно или ежедневно) — не бросайтесь сразу делать real-time обновления. Начните с общей модели, работающей для большинства пользователей, прежде чем переходить к персонализации.

Useful Practices to Minimize Feedback Loops and Bias

Полезные практики для минимизации контуров обратной связи и смещений

Use positional features to avoid feedback loops. This neat trick reduces much of the bias where a user’s interactions depend on the item’s rank.

Используйте позиционные фичи, чтобы избежать контуров обратной связи. Этот изящный приём устраняет значительную часть смещения, при котором взаимодействия пользователя зависят от позиции элемента.

In ranking or recommendation, the position of the item (e.g., product, advertisement) affects how likely users will click on it. A higher ranked item is naturally clicked more. How do you control for this real-world bias in the training data?

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

By including positional features. During training, the model will learn to weigh these features highly, given the high correlation with CTR. Then, during serving, when determining the item rank, you can drop these positional features or set it to a constant.

Через включение позиционных фич. При обучении модель научится придавать им большой вес из-за высокой корреляции с CTR. Затем, при обслуживании, при определении ранга элемента, эти позиционные фичи можно отбросить или установить в константу.

Learn thresholds from data. Fixed thresholds for binarizing probabilities can be tricky to maintain and vulnerable to data drift. Instead, consider learning it with each model refresh.

Обучайте пороги по данным. Фиксированные пороги для бинаризации вероятностей сложно поддерживать, и они уязвимы к дрифту данных. Вместо этого подумайте об их обучении при каждом обновлении модели.

For example, what are your production requirements? Do you need 95% recall? Or minimal false positives? Or a good balance? Evaluate which thresholds (e.g., in Python, [x/100 for x in range(1, 100, 1)]) meets those requirements and use it in production.

Например, каковы ваши требования продакшена? Нужен ли recall 95%? Или минимум false positives? Или хороший баланс? Оцените, какие пороги (например, в Python — [x/100 for x in range(1, 100, 1)]) удовлетворяют этим требованиям, и используйте их в продакшене.

Audit a sample of your data periodically. Monthly or weekly is good. This is especially important the next set of training data includes these predictions. If your predictions have many errors, and are then used as training data, this could lead to a vicious cycle.

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

For example, if you’re classifying product reviews daily for spam, offensive language, and personal details, erroneous predictions go on to become the next set of (incorrect) training data.

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

What you’ll want to do is take a small sample of reviews (e.g., 1% - 5%) and have people go through them. Are there obvious errors or new types of fraud emerging? Is there a general pattern to them? Once you find these error patterns, you can get the misclassified reviews via logic or regex to relabel them. Then, you can relabel other misclassifications via active learning.

Что нужно сделать — взять небольшую выборку отзывов (например, 1–5%) и попросить людей их просмотреть. Есть ли очевидные ошибки или появляются ли новые виды мошенничества? Есть ли общая закономерность? Найдя такие паттерны ошибок, можно по логике или регулярным выражениям отобрать неправильно классифицированные отзывы и переразметить их. После этого можно переразметить другие ошибки через active learning.

Structure Teams for Iteration and Innovation

Структурирование команд для итераций и инноваций

Have your data scientists do end-to-end. I’ll admit, this is not a popular opinion as most tech teams move toward division of labour. But, hear me out.

Пусть data scientists работают end-to-end. Признаю, это непопулярное мнение — большинство технических команд движутся к разделению труда. Но выслушайте меня.

A generalist (or if you prefer, full-stack) data scientist can perform diverse functions: communicate with stakeholders to define the right problem, develop prototypes and production code, and deploy and measure. This increases learning, innovation, and iteration speed. It also encourages individual ownership and reduces diffusion of responsibility.

Универсальный (или, если хотите, full-stack) data scientist может выполнять разные функции: общаться со стейкхолдерами, чтобы определить правильную проблему, разрабатывать прототипы и продакшен-код, деплоить и измерять. Это ускоряет обучение, инновации и итерации. Это также поощряет личную ответственность и снижает «размывание ответственности».

Netflix has full-cycle developers and it worked well. Stitch Fix starts with a full-stack data scientist model and only specialise when necessary.

У Netflix есть full-cycle разработчики, и это хорошо работает. Stitch Fix начинает с модели full-stack data scientist и переходит к специализации только при необходимости.

Caveat: This practice assumes good tooling and infrastructure support. Spark instances should be easy to spin up, automatic failover and rollback should be in place, and A/B tests should be simple to start. With these, your generalist data scientists can focus on machine learning system development.

Оговорка: Эта практика предполагает наличие хорошего тулинга и инфраструктурной поддержки. Spark-инстансы должны легко поднимать, автоматическое failover и rollback — настроены, A/B-тесты должны запускаться легко. С этим ваши универсальные data scientists могут сосредоточиться на разработке ML-систем.

If you cannot have end-to-end data scientists, have end-to-end teams. I get it, end-to-end data scientists are rare (though I would argue they’re not unicorns; you can find as well as make them). If so, build end-to-end teams instead.

Если не можете иметь end-to-end data scientists — имейте end-to-end команды. Я понимаю — end-to-end data scientists редки (хотя я бы поспорил, что они не «единороги»; их можно как найти, так и вырастить). Если так — стройте end-to-end команды.

Have your PM, data scientists, and engineers sit together (after this pandemic blows over). Ensure teams align the same goals of fast iteration and shipping. Have processes that minimize coordination and communication costs (i.e., have quick, informal discussions instead of scheduling meetings).

Посадите PM, data scientists и инженеров рядом (после того как пандемия утихнет). Убедитесь, что у команд общие цели быстрых итераций и поставки. Постройте процессы, минимизирующие издержки координации и коммуникации (например, быстрые неформальные обсуждения вместо запланированных митингов).

Define clear interfaces between each role. If different teams own different parts of the machine learning process, ensure that people don’t just “throw code over the wall”. Set clear expectations and interfaces for deliverables.

Определите чёткие интерфейсы между ролями. Если разные команды владеют разными частями ML-процесса, убедитесь, что люди не «перебрасывают код через стену». Установите чёткие ожидания и интерфейсы для поставляемых результатов.

For example, the deliverable for data engineers could be timely updates in the database—this is the input interface for data scientists. The data scientists then build their machine learning models and deliver a docker container with a model.predict() API—this is their output interface.

Например, поставка data engineers — это своевременные обновления в БД; это входной интерфейс для data scientists. Data scientists, в свою очередь, строят свои ML-модели и поставляют Docker-контейнер с API model.predict() — это их выходной интерфейс.

Crowdsource the Handling of Customer Complaints

Краудсорсинг обработки клиентских жалоб

Make it easy for others to take action. This includes customer service agents, account managers, and policymakers. You can accomplish this via simple user interfaces (UI) to input product and customer IDs; these are then stored in a database.

Облегчите другим возможность действовать. Это касается агентов клиентской поддержки, account-менеджеров и регуляторов. Этого можно добиться через простые интерфейсы (UI), куда можно ввести ID товара и клиента; эти данные затем хранятся в БД.

Are customers complaining about inappropriate products in recommendations or search results? Let agents blacklist the product ID via the UI. Does a customer have privacy concerns? Again, add their ID via the UI. Does an account manager want to increase a new product’s visibility? Add the product ID via the UI to give it a temporary boost (this helps with cold-start products too). Or better yet, build a new ad business and crowdsource boosting to sellers.

Клиенты жалуются на неуместные товары в рекомендациях или поиске? Дайте агентам возможность блокировать ID товара через UI. У клиента есть опасения о приватности? Снова — добавляйте его ID через UI. Account-менеджер хочет повысить видимость нового товара? Добавьте ID товара через UI, чтобы временно его бустить (это помогает и с cold-start товарами). А ещё лучше — постройте новый рекламный бизнес и отдайте буст на краудсорсинг продавцам.

Help operations staff understand model outputs.When machine-learning decisions have repercussions, people will want an explanation. Help your frontline agents understand and explain decisions to customers. I’ve found SHAP force plots useful for this. LIME is also a good alternative.

Помогите операционному персоналу понимать выводы модели. Когда у ML-решений есть последствия, люди захотят объяснений. Помогите вашим фронтлайн-агентам понимать и объяснять решения клиентам. Я считаю SHAP force plots полезными для этого. LIME тоже хорошая альтернатива.

Here’s an example where we predict passenger survivability from the famous Titanic dataset. For this passenger, we see that gender and age had a big positive influence on survivability—after all, women and children first. Her having a 3rd class cabin had a negative impact—lower class cabins are in the lower decks and thus further away from the lifeboats.

Вот пример, где мы предсказываем выживаемость пассажиров на знаменитом датасете Titanic. Для этой пассажирки видно, что пол и возраст оказали большое положительное влияние на выживаемость — в конце концов, женщин и детей пропускают первыми. Каюта третьего класса оказала негативное влияние — каюты нижних классов располагаются на нижних палубах, дальше от спасательных шлюпок.

This SHAP force plot shows being female and low in age improved survivability.

Этот SHAP force plot показывает, что быть female и быть молодой по age повышало выживаемость.

Some (Important) Practices I Didn’t Discuss

Некоторые (важные) практики, которые я не обсудил

There were a few key points I skipped. They’ve been well covered in other resources; nonetheless, I thought I should briefly mention them here.

Есть несколько ключевых пунктов, которые я опустил. Они хорошо освещены в других источниках; тем не менее, я подумал, что стоит их кратко упомянуть.

Стандартные инженерные практики: сюда входят code reviews, ваш набор тестов (юнит-тесты, интеграционные, инфраструктурные) и нормальная документация. Я бы расширил это и до методологических ревью. Корректна ли SQL-логика? Был ли train-validation split сделан правильно (без утечек данных)? A/B (и bandit) тестирование: они де-факто для релиза онлайн-продуктов и фич. Не пропускайте их (если только не уверены, что делаете). Усталость от уведомлений: (я не очень понимал, куда это вписать). При нормальном мониторинге команда может начать получать много алертов. Слишком много — и их перестанут замечать, что сводит мониторинг на нет. Подкручивайте баланс precision-recall — приоритизируйте алерты с высокой precision и ценностью (т.е. критически влияющие на клиентский опыт).

That’s a Lot; How should We Prioritise?

Это много; как расставить приоритеты?

I didn’t plan for this post to be so overwhelming. Let me conclude with the top three must-haves and good-to-haves here (disclaimer: my start-up experience influenced these and they’re likely subjective).

Я не планировал делать пост таким перегруженным. Давайте подведу итог тремя главными must-have и good-to-have практиками (оговорка: на это повлиял мой стартап-опыт, и они, скорее всего, субъективны).

IMHO, these are must-haves in most teams:

ИМХО, это must-have для большинства команд:

Валидация модели перед деплоем: моя любимая практика. Одной проверкой вы устраняете большинство сбоев ML до деплоя. Валидация входных данных: базовые проверки идут далеко — количество строк, наличие ошибочных дубликатов, доля null'ов. Затем — проверка диапазонов числовых и date-колонок, а также уникальных значений категориальных. Простой откат: эта страховка позволяет команде быстро итерироваться и деплоить, прокладывая путь к CI/CD. Деплой сломал prod посреди ночи? Без проблем — откатили и чините утром.

Next, here are three good-to-haves:

А вот три good-to-have:

Пусть data scientists работают end-to-end: по моему опыту, это сильно сокращает время разработки, ускоряет обучение и инновации и создаёт культуру ответственности. Инвестируйте в data science тулинг: иметь шаблонные Docker-контейнеры для разработки и деплоя ML-моделей. Поднять централизованный MLflow-сервер для шаринга и ревью результатов. Airflow отлично подходит для планирования задач с зависимостями. Инвестируйте в тулинг клиентской поддержки: стройте инструменты, которые дают агентам поддержки возможность решать самые частые задачи (например, блокировка товаров, объяснение исходов). Это сокращает количество ad hoc запросов и тушения пожаров вашей командой.

References

Источники

Rules of Machine Learning: Best Practices for ML Engineering

Thanks to Yang Xinyi, Marianne Tan, and Stew Fortier for reading drafts of this.

Спасибо Yang Xinyi, Marianne Tan и Stew Fortier за прочтение черновиков.

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

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

Yan, Ziyou. (May 2020). A Practical Guide to Maintaining Machine Learning in Production. eugeneyan.com. https://eugeneyan.com/writing/practical-guide-to-maintaining-machine-learning/.

Yan, Ziyou. (May 2020). A Practical Guide to Maintaining Machine Learning in Production. eugeneyan.com. https://eugeneyan.com/writing/practical-guide-to-maintaining-machine-learning/.

or

или

@article{yan2020maintain, title = {A Practical Guide to Maintaining Machine Learning in Production}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {May}, url = {https://eugeneyan.com/writing/practical-guide-to-maintaining-machine-learning/} }

@article{yan2020maintain, title = {A Practical Guide to Maintaining Machine Learning in Production}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {May}, url = {https://eugeneyan.com/writing/practical-guide-to-maintaining-machine-learning/} }

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

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