6 Little-Known Challenges After Deploying Machine Learning

eugeneyan

eugeneyan

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

6 Little-Known Challenges After Deploying Machine Learning

6 малоизвестных проблем, возникающих после деплоя машинного обучения

[ machinelearning engineering production ] · 14 min read

[ machinelearning engineering production ] · чтение на 14 мин

Deploying machine learning is hard.

Деплой машинного обучения — это сложно.

That’s what I thought. Then I realised it gets harder after deployment.

Так я думал. А потом понял, что после деплоя становится ещё сложнее.

Hey, building and deployment is still a challenge for me. Running machine learning experiments, writing production-grade code, and integrating with infra and engineering; oh, don’t forget the unit tests. All that’s not easy. Thankfully, it’s getting more painless with better tools (e.g., SageMaker, AI Platform, Azure ML) and open-source libraries.

Да, разработка и деплой по-прежнему остаются для меня вызовом. Проведение ML-экспериментов, написание production-кода, интеграция с инфраструктурой и инженерными системами; ах да, не забудьте про юнит-тесты. Всё это непросто. К счастью, это становится менее болезненным благодаря более удобным инструментам (например, SageMaker, AI Platform, Azure ML) и open-source-библиотекам.

Yet, there’s not much on what happens after deployment. There’re good academic papers (referenced below) though they’re less accessible to laymen. To address this, I’ll share my experience with real-world examples. It’s a work in progress and not an exhaustive list, but I hope it raises awareness on machine learning post-deployment.

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

I’ll discuss this from the bottom-up: starting with data, then models and engineering, then aspects external to the system (i.e., the real world, org structure, users).

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

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

Feel free to skip ahead. In the next spost, we’ll discuss how to tackle these challenges.

Можете смело перематывать вперёд. В следующем посте мы обсудим, как справляться с этими проблемами.

Follow-up post: A Practical Guide to Maintaining Machine Learning

Продолжение: A Practical Guide to Maintaining Machine Learning

Once you deploy in prod, you can't break. Unlike in dev.

Как только вы развернули систему в prod, она не имеет права ломаться. В отличие от dev.

1: Schemas Change When They Shouldn’t (& vice versa)

1: Схемы меняются, когда не должны (и наоборот)

Machine learning systems are dependent on data. Unstable upstream data will affect your system’s performance. Some of these are just annoying outages or delays that require you to manually run your pipeline. Others are more damaging and difficult to discover.

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

Here’s an example: Imagine you have a column for gender with two values, male and female. To be more politically correct, frontend adds Transgender, Other, and Prefer not to say to the dropdown list. They also update male -> Male and female -> Female. The prod database now has these new—never seen before—values.

Вот пример: представьте, что у вас есть колонка gender с двумя значениями, male и female. Чтобы быть политкорректнее, фронтенд добавляет в выпадающий список Transgender, Other и Prefer not to say. Заодно меняют male -> Male и female -> Female. Теперь в production-базе появились эти новые — ранее невиданные — значения.

Your data pipelines chug along without complaints. Your feature encoders set these unknown values to null. Your models are resilient to the entire gender column being null and don’t break. However, your system’s online performance degrades, especially in use cases where gender is important (e.g., customer segmentation, personalized recommenders, etc.)

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

(Unexpected) pipeline consumers may impose constraints. Your data pipelines store intermediate processed data in tables, which you make available to the whole org. As you iterate, you add data columns that improve ML performance and remove the redundant ones. One day, you get an angry email, asking why a (dropped) column is no longer available—it’s from a previously unknown consumer of your data.

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

The quick, short-term fix is to restore that data column and placate that angry consumer. However, this adds additional compute time and cost to your pipeline—with no benefits to your systems! Now, there are delays in your model’s daily refresh and your team has to bear the additional cost.

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

Big picture-wise, your pipelines (and ML system) are now entangled. Consumers of your data have imposed constraints—you no longer have full autonomy to update your data pipelines. Further, all systems relying on your pipeline, including yours, end up stuck in poor overall local optima.

В масштабе картины ваши пайплайны (и ML-система) теперь переплетены. Потребители ваших данных навязали ограничения — у вас больше нет полной автономии в обновлении пайплайнов. Более того, все системы, опирающиеся на ваш пайплайн, включая вашу, оказываются застрявшими в плохом общем локальном оптимуме.

“All your (data)base are belong to us” - Eugene Yan

«All your (data)base are belong to us» — Eugene Yan

Data Leaks are introduced. Data leakage occurs when some form of the label (aka target variable) “leaks” into the feature data. This leads to artificially good results during offline evaluation, but poor performance in a live environment.

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

Suppose you’re building a model to estimate a patient’s hospital bill. Patients request an estimation at the point of admission (or when they're shopping around). A key feature in your model is the estimated hospitalization_days (provided by the admitting doctor); this is stored in the production database. One day, someone decides to update the hospitalization_days column with the actual number of days hospitalised.

Предположим, вы строите модель для оценки больничного счёта пациента. Пациенты запрашивают оценку в момент поступления (или когда сравнивают варианты). Ключевой признак вашей модели — предполагаемое hospitalization_days (которое указывает принимающий врач); оно хранится в production-базе. Однажды кто-то решает обновить колонку hospitalization_days фактическим числом дней госпитализации.

Now, your model trains on the actual length of stay which would never be available at the point of admission—this is a data leak. During training, the model gives (actual) hospitalization_days a high weight, overfits, and performs well in offline evaluation. During serving, it continues to weigh (estimated) hospitalization_days highly, resulting in poor production accuracy. Such data leaks and training-serving skew can be difficult to detect.

Теперь ваша модель обучается на фактической длительности пребывания, которая никогда не была бы доступна в момент поступления, — это утечка данных. Во время обучения модель присваивает (фактическому) hospitalization_days высокий вес, переобучается и хорошо показывает себя в офлайн-оценке. Во время работы она продолжает придавать большой вес (предполагаемому) hospitalization_days, что приводит к низкой точности в production. Такие утечки данных и расхождение между обучением и инференсом (training-serving skew) бывает трудно обнаружить.

2: Unwanted Model Interactions (Internal & External)

2: Нежелательные взаимодействия моделей (внутренние и внешние)

Too many features makes your model different to maintain. After launching the prototype, an easy route to performance improvements is to add more features–this usually leads to improved accuracy. We seldom reassess if all the features are still useful. Over time, many features become redundant, with (or without) the addition of other features.

Слишком много признаков усложняет сопровождение модели. После запуска прототипа лёгкий путь к улучшению производительности — добавить больше признаков; это обычно повышает точность. Мы редко переоцениваем, все ли признаки по-прежнему полезны. Со временем многие признаки становятся избыточными, с добавлением других признаков (или без него).

It can be expensive to maintain data pipelines for these redundant features. These redundancies also add unnecessary dependencies and complexity to your model, making it harder to maintain and iterate on.

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

Other models influence your model performance. Often, your model is exposed to customers together with several other models.

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

Take the home page of an e-commerce app for example. Your recommender is one of many widgets on it. There’s also an overall widget ranker that determines which widget gets more visibility. Widgets that increase certain metrics (e.g., click-thru, conversion, revenue) are displayed closer to the top.

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

Recently, your recommender performance has worsened. Why? Is it degrading on its own? Are other recommenders performing better and drawing away engagement? Or was there a change in the widget ranker’s algorithm? These interaction effects make it difficult to understand a model’s online performance and make improvements.

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

3: Infra & Codebase is Messy (read: Chaotic)

3: Инфраструктура и кодовая база захламлены (читай: хаотичны)

Machine learning systems often have poor engineering practices. I’ll be honest—if I build an ML system end-to-end, my coding practices are not going to be as “best practice” as my engineering brothers-in-arms.

В ML-системах часто плохие инженерные практики. Признаюсь честно: если я строю ML-систему от начала до конца, мои практики кодирования будут не настолько «best practice», как у моих собратьев по оружию из инженерии.

Poor engineering practices have different “smells”. Glue-code is one such smell—they do one-off jobs such as dumping data from S3 to your database or vice versa. My codebase also smells of multiple programming languages. Python is the de facto for machine learning while Scala (and Spark) for big data processing. There’s also bits of SQL scattered here and there. And some legacy UI tools that are too tightly woven in.

Плохие инженерные практики «пахнут» по-разному. Glue-код (склеивающий код) — один из таких запахов: он выполняет разовые задачи вроде выгрузки данных из S3 в вашу базу или наоборот. Моя кодовая база также пахнет несколькими языками программирования. Python — де-факто стандарт для машинного обучения, а Scala (и Spark) — для обработки больших данных. Тут и там разбросаны кусочки SQL. А ещё есть легаси UI-инструменты, слишком плотно вплетённые внутрь.

These different languages and codebases will require different infrastructure and skill sets to support. Over the long term, it becomes expensive to maintain and improve upon. On the other hand, attempting to rewrite everything in Java or some other enterprise language is a non-starter. Still trying to figure this balance out.

Эти разные языки и кодовые базы требуют разной инфраструктуры и наборов навыков для поддержки. В долгосрочной перспективе их становится дорого сопровождать и улучшать. С другой стороны, попытка переписать всё на Java или другом enterprise-языке — заведомо безнадёжна. Я всё ещё пытаюсь нащупать этот баланс.

Configuration code is often messy or non-existent. As you develop your ML system, you find the need to add “magic” numbers. What are examples of these? The threshold to convert probabilities to 1s and 0s in classification. The days of historical data to train your model on. And of course, all the optimized machine learning hyper params.

Конфигурационный код часто захламлён или вовсе отсутствует. По мере разработки ML-системы вы обнаруживаете необходимость добавлять «магические» числа. Какие тут примеры? threshold (порог) для преобразования вероятностей в единицы и нули в классификации. Число days исторических данных, на которых обучается модель. И, конечно, все оптимизированные гиперпараметры (params) машинного обучения.

In the worst case, you find these magic numbers sprinkled in the production code. A slight improvement would have them in configuration files. Or you might be using MLflow to manage them. As your ML system grows, the config code grows larger than the ML code.

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

How can we manage these voluminous configs? How do we onboard someone new to them? When we make changes, how do we know they’re correct (and prevent prod from breaking)? It’s a bigger challenge than it appears.

Как управлять этими объёмными конфигами? Как вводить в них нового человека? Когда мы вносим изменения, как убедиться, что они корректны (и не сломают prod)? Это более серьёзный вызов, чем кажется.

“Data matures like wine, applications like fish” - James Governor

«Данные созревают как вино, приложения — как рыба» — James Governor

Infrastructure environments don’t cooperate. You’ve tried a new machine learning library and offline evaluation results are amazing. Also, the new release of Spark 2.x fixes a key pain point and you want to start using it ASAP. (For example, before Spark 2.3, raw prediction probabilities were not available for some model implementations.)

Инфраструктурные окружения не сотрудничают. Вы попробовали новую ML-библиотеку, и результаты офлайн-оценки потрясающие. К тому же новый релиз Spark 2.x устраняет ключевую боль, и вы хотите начать им пользоваться как можно скорее. (Например, до Spark 2.3 сырые вероятности предсказаний были недоступны для некоторых реализаций моделей.)

Unfortunately, your infra team is unable to support your requests. To serve your new machine learning library in prod, they need to update the API servers. To use Spark 2.x, they need to wait for their cloud/Hadoop distro to support it. And update the cluster. And perform regression testing. It’ll be a couple days (read: weeks).

К сожалению, ваша инфраструктурная команда не может удовлетворить ваши запросы. Чтобы запустить вашу новую ML-библиотеку в prod, им нужно обновить API-серверы. Чтобы использовать Spark 2.x, им нужно дождаться, пока их облачный/Hadoop-дистрибутив начнёт его поддерживать. И обновить кластер. И провести регрессионное тестирование. На это уйдёт пара дней (читай: недель).

But hey, that’s not too bad. Could be worse. You might’ve updated the code, deployed it, and broke everything for a day or two. You could have caused a P0 outage where the CEO is notified and everyone drops everything to roll back.

Но, эй, это не так уж плохо. Могло быть и хуже. Вы могли бы обновить код, задеплоить его и сломать всё на день-два. Вы могли вызвать сбой уровня P0, при котором уведомляют CEO и все бросают всё ради отката.

In short, once your system is in production, you’ll have to rely on the prod environment and can’t cowboy in dev anymore.

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

4: Real-World Bias and Bad Guys Come Knocking

4: Смещение реального мира и приход злоумышленников

Real-world data doesn’t cooperate. It changes. Contrast this with your machine learning model. Once trained, ML models are static (unless they’re updated via online learning). They learn (fixed) assumptions about the world—based on the training data—and don’t change them.

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

What happens when those assumptions no longer hold? Data drift. This occurs when your input data (during prediction) becomes progressively different from your training data over time. Real-world data is dynamic but your model is static.

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

We've seen an example of structural drift (e.g., schema change); this occured when the gender column was updated. The example of hospitalization_days, where the value changes from estimated to actual demonstrates semantic drift–the meaning of the data has changed but the structure (i.e., schema) hasn't.

Мы уже видели пример структурного дрейфа (например, изменение схемы); он произошёл, когда обновилась колонка gender. Пример с hospitalization_days, где значение меняется с предполагаемого на фактическое, демонстрирует семантический дрейф — смысл данных изменился, а структура (то есть схема) нет.

In benign instances, model performance degrades and CTR drops a bit. It’s far more damaging if it leads to a loss in finances or worse, lives.

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

Feedback loops can cause a vicious cycle. In production, your model affects the real world, which affects your model, which affects the real world … you get what I mean. (Yes, Minority Report)

Петли обратной связи могут запустить порочный круг. В production ваша модель влияет на реальный мир, который влияет на вашу модель, которая влияет на реальный мир… вы поняли, о чём я. (Да, Minority Report)

Here’s an example: A forecasting model predicts how much inventory a supermarket chain should hold each week. The model is penalised for holding excess inventory, so it consistently underestimates. As a result, stores often sell the forecasted amount and go out of stock. The ML model learns based on the (decreasing) sales data and continues to underestimate. But on paper, it looks really accurate.

Вот пример: модель прогнозирования предсказывает, сколько запасов сети супермаркетов следует держать каждую неделю. Модель штрафуется за избыточные запасы, поэтому она стабильно занижает прогноз. В результате магазины часто продают спрогнозированный объём и оказываются без товара. ML-модель учится на (снижающихся) данных о продажах и продолжает занижать. Но на бумаге она выглядит очень точной.

Another example. Let’s consider a ranking system. Products that rank high today get high engagement. Because they had high engagement, they continue to rank high tomorrow. This makes it almost impossible for new products to get traffic. Such feedback loops are tricky to detect and control for in model training.

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

Adversaries (the academic term for bad guys). Adversaries will probe and try to trick your model if it’s profitable. In a ranking system, sellers will try to get counterfeit or poor quality products to rank high, even going as far as buying their own products. Phishers try to get past email spam detectors. Fraudsters try to outsmart anti-money laundering systems.

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

These adversaries will reverse engineer your models and monitor which of their attempts worked. As they probe, they also (deliberately) introduce data which your model will learn from. As a result, the training data is polluted and prod performance decreases.

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

5: Org Issues - Priorities Clash; Diffused Responsibility

5: Организационные проблемы — столкновение приоритетов; размытая ответственность

More teams will get involved (with conflicting priorities). As part of data science, you want to innovate and deploy the best performing (and likely computationally most expensive) machine learning. Engineering wants stability and lower cost of maintenance. Business wants results fast (read: today, but ideally yesterday), constraining the time and resources available for long-term innovation (slight overgeneralization).

Подключается больше команд (с конфликтующими приоритетами). Как часть data science вы хотите внедрять инновации и развёртывать самое производительное (и, вероятно, наиболее затратное по вычислениям) машинное обучение. Инженерия хочет стабильности и меньшей стоимости сопровождения. Бизнес хочет результатов быстро (читай: сегодня, а в идеале — вчера), ограничивая время и ресурсы, доступные для долгосрочных инноваций (лёгкое преувеличение).

You’ll have to consider the bigger picture as you iterate on your ML system that is now in prod. This means not having the fanciest, highest-performing model because it requires 10x more compute for 0.5% gain. This means shipping in 2 – 3 months instead of 2 – 3 years. It’ll be a challenge to balance these different stakeholder priorities in your roadmap.

Вам придётся учитывать общую картину, итерируя над вашей ML-системой, которая теперь в prod. Это означает отказ от самой навороченной, самой производительной модели, потому что она требует в 10 раз больше вычислений ради 0,5% прироста. Это означает выпуск за 2–3 месяца вместо 2–3 лет. Балансировать эти разные приоритеты стейкхолдеров в вашем роадмапе будет непросто.

More people are now required for each update meeting. When someone reported a bug in the initial production prototype, you fixed it single-handedly in a day. Now, to fix a bug or add a new feature, you need a meeting with the product manager, a data engineer, a software engineer, and a QA—if you’re lucky, this meeting can happen within days.

Теперь на каждое совещание по обновлению требуется больше людей. Когда кто-то сообщал о баге в исходном production-прототипе, вы в одиночку исправляли его за день. Теперь, чтобы исправить баг или добавить новую функцию, вам нужно совещание с продакт-менеджером, дата-инженером, инженером-программистом и QA — и если повезёт, это совещание состоится в течение нескольких дней.

In most mature organizations, work is divided across specialised roles. Let’s consider this in the context of machine learning. To add input data columns:

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

Дата-инженеру нужно обновить пайплайны данных и feature store. Затем дата-сайентист обновляет ML-код и запускает офлайн-оценку. Далее инженер «продакшенизирует» код (нельзя же позволить дата-сайентистам сломать prod!). Наконец, специалист по контролю качества (QA) запускает набор тестов и стресс-тесты.

This division of labour leads to increased coordination costs and wait time as tasks pass from one person to another. The result? Increased friction, reduced development and deployment velocity. This makes it a challenge to iterate fast once in production.

Это разделение труда приводит к росту координационных издержек и времени ожидания, поскольку задачи передаются от одного человека к другому. Результат? Возросшее трение, сниженная скорость разработки и деплоя. Из-за этого быстро итерировать после выхода в production становится непросто.

“What one programmer can do in one month, two programmers can do in two months” - Frederick P. Brooks

«То, что один программист может сделать за один месяц, два программиста сделают за два месяца» — Frederick P. Brooks

6: With Users, You Have to Provide Customer Service

6: С пользователями приходится оказывать клиентскую поддержку

Consumers will spot flaws and demand fixes. Because there’re so many users of your product, the flaws of machine learning quickly become apparent. Most machine learning applications approximate human-level ability—and mistakes—but at a much larger scale. Things can blow up fast.

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

One infamous example is the Google Gorilla. In 2015, Google’s photo classifier mistakenly labelled black people as gorillas. Two years on, Google still hasn’t found a satisfying–GG. I’ve experienced similar incidents where customers were recommended adult toys on product pages (don’t ask me how, it’s trained on user behaviour data). This was a concern, especially for conservative Muslim countries, especially for parents.

Один печально известный пример — «горилла» от Google. В 2015 году фотоклассификатор Google по ошибке пометил чернокожих людей как горилл. Два года спустя Google так и не нашёл удовлетворительного решения — GG. Я сталкивался с похожими инцидентами, когда клиентам на страницах товаров рекомендовали секс-игрушки (не спрашивайте как, модель обучена на данных о поведении пользователей). Это вызывало беспокойство, особенно в консервативных мусульманских странах, особенно у родителей.

With millions of users, the (enviably low) 0.001% error rates affect thousands. You’ll receive the gift of feedback and the expectation of a quick fix.

При миллионах пользователей (завидно низкие) 0,001% ошибок затрагивают тысячи. Вы получите подарок в виде обратной связи и ожидание быстрого исправления.

People need to know why. Let me first qualify by saying that, in most use cases, this probably won’t happen. Weather forecasts, movie recommendations, route planning—we use them daily and don’t question them. We acclimatize to machine learning apps the more often we use them, especially if the utility is high and repercussions low.

Людям нужно знать почему. Сначала оговорюсь: в большинстве сценариев этого, скорее всего, не случится. Прогнозы погоды, рекомендации фильмов, прокладка маршрутов — мы пользуемся ими ежедневно и не ставим их под сомнение. Мы привыкаем к ML-приложениям тем сильнее, чем чаще ими пользуемся, особенно если польза высока, а последствия незначительны.

However, there are instances where we need an explanation.

Однако есть случаи, когда нам нужно объяснение.

Imagine walking into a hospital looking for a standard heart valve procedure. Your google-jitsu suggests this typically costs 60 thousand. However, the hospital’s (opaque) algorithm estimates a bill thrice that amount. Woah, wait, why?! Does the model foresee complications? Is it my age or medical history? Is it my smoking?

Представьте, что вы приходите в больницу за стандартной процедурой на сердечном клапане. Ваш google-jitsu подсказывает, что это обычно стоит 60 тысяч. Однако (непрозрачный) алгоритм больницы оценивает счёт втрое выше. Стоп, погодите, почему?! Модель предвидит осложнения? Дело в моём возрасте или истории болезни? В том, что я курю?

People can’t help but worry, even if it’s just an estimation and has no impact on the final bill. Compare this to machine learning algorithms that do affect people’s lives, such as getting rejected for a loan or insurance. In these cases, the need to know why is far stronger and our machine learning systems should be able to provide that.

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

People care about privacy and how their data is used. The more data machine learning systems have, the better they learn, the better they serve. On the other hand, people want to control their data. They don’t want their personal data being used to discriminate or target them (e.g., ads). They don’t want embarrassing details online.

Людям важна приватность и то, как используются их данные. Чем больше данных у ML-систем, тем лучше они обучаются и тем лучше обслуживают. С другой стороны, люди хотят контролировать свои данные. Они не хотят, чтобы их персональные данные использовались для дискриминации или таргетинга (например, рекламой). Они не хотят, чтобы неловкие подробности были в сети.

This leads to regulations, such as the EU’s General Data Protection Regulation (GDPR). It aims to give individuals control over their personal data and affects how many industries operate, especially social media and online ads. If you have users from the EU, you’ll also face this challenge in your machine learning ops.

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

Where to go from here?

Куда двигаться дальше?

At the start of this post, you likely thought one of the following:

В начале этого поста вы, вероятно, думали одно из следующего:

«Деплой был самой сложной частью». «Деплой — это только начало».

Whichever group you were in, I hope this increased your awareness of machine learning challenges post-deployment. I spent years on these issues and have (thankfully) found some straightforward ways to fix–or, in many cases, prevent–them. More in the next post.

К какой бы группе вы ни принадлежали, надеюсь, это повысило вашу осведомлённость о проблемах машинного обучения после деплоя. Я провёл годы над этими вопросами и (к счастью) нашёл несколько простых способов их исправить — или, во многих случаях, предотвратить. Подробнее в следующем посте.

References

Ссылки

Machine Learning: The High Interest Credit Card of Technical Debt Rules of Machine Learning: Best Practices for ML Engineering Hidden Technical Debt in Machine Learning Systems On Challenges in Machine Learning Model Management Data Lifecycle Challenges in Production Machine Learning: A Survey Continuous Delivery for Machine Learning Why Machine Learning Models Degrade In Production Versioning for End-to-End Machine Learning Pipelines

Thanks to Yang Xinyi, Stew Fortier, Richie Bonilla, and Joel Christiansen for reading drafts of this.

Спасибо Yang Xinyi, Stew Fortier, Richie Bonilla и Joel Christiansen за прочтение черновиков.

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

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

Yan, Ziyou. (May 2020). 6 Little-Known Challenges After Deploying Machine Learning. eugeneyan.com. https://eugeneyan.com/writing/challenges-after-deploying-machine-learning/.

Yan, Ziyou. (May 2020). 6 Little-Known Challenges After Deploying Machine Learning. eugeneyan.com. https://eugeneyan.com/writing/challenges-after-deploying-machine-learning/.

or

или

@article{yan2020challenge, title = {6 Little-Known Challenges After Deploying Machine Learning}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {May}, url = {https://eugeneyan.com/writing/challenges-after-deploying-machine-learning/} }

@article{yan2020challenge, title = {6 Little-Known Challenges After Deploying Machine Learning}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {May}, url = {https://eugeneyan.com/writing/challenges-after-deploying-machine-learning/} }

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

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