Как построить ДОВЕРИЕ в машинном обучении разумным способом

Машинное обучение становится неотъемлемой частью каждого аспекта нашей жизни. По мере того, как сложность этих систем растет, и они принимают за нас гораздо больше решений, нам необходимо преодолеть самый большой барьер на пути к их внедрению ⚠️; "Как мы можем доверять ЭТОЙ модели машинного обучения?".

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

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

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

Почему трудно ДОВЕРЯТЬ моделям машинного обучения?

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

Много движущихся частей🚴🏻‍♀️ — и код, и данные изменяются необычным образом. В некоторых случаях это даже хуже, поскольку вы являетесь производителем набора данных.
Вывод непредсказуем🎁 — вы не можете охватить все прогнозы, которые ваша модель покажет конечным пользователям. Это можно смягчить, объяснив, почему модель дала такие прогнозы.
Участвует несколько отделов🤼 — обычно несколько ролей имеют разные части, потому что они требуют разных наборов навыков. От приема данных, разработки модели, развертывания модели, мониторинга и использования модели. Эффективное общение и совместная работа — нетривиальная задача.
Тяжелый цикл разработки😫—для создания модели требуется много данных, достаточно вычислительных ресурсов и достаточно времени. Это затрудняет локальное развитие. Вы можете попробовать, использовать дорогие компьютеры или использовать облако. Но все равно петля обратной связи будет достаточно длинной. Если этого недостаточно, код машинного обучения сложно отлаживать.
Системы машинного обучения сложны🤯—они редко оправдывают ожидания пользователей в обычном порядке. В большинстве случаев ваш алгоритм работает, но недостаточно хорошо. Даже определение того, что уместно, а что следует измерять, является нетривиальной задачей. Это усложняется еще и тем, что лучших практик не хватает, да и те не ориентированы на доверие.

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

Взгляд с высоты птичьего полета на здание TRUST

Мы расскажем о каждом этапе жизненного цикла машинного обучения и о том, какие механизмы нам нужно использовать для повышения доверия ♻️:

Определение успеха — определяем, что значит Модель работает хорошо. В этом разделе мы обсудим, как мы оцениваем наши модели и будут ли они приняты.
Подготовка данных — мусор на входе, мусор на выходе(💩+🧠= 💩). В этом разделе мысосредоточены на том, как мы оцениваем наши данные.
Разработка модели — машинное обучение носит экспериментальный характер, и мы получили небольшое право на ошибку. В этом разделе мы описываем, что вам нужно измерять и проверять в автономном режиме при разработке новых моделей.
Системная интеграция — о конвейере машинного обучения и артефактах, которые он создает для производства. В этом разделе основное внимание уделяется обеспечению того, чтобы код, тесты и артефакты соответствовали определенным критериям качества, с большим акцентом на воспроизводимость и автоматизацию.
Развертывание — здесь наши модели впервые сталкиваются с рабочим трафиком. В этом разделе основное внимание уделяется проведению экспериментов с порциями трафика и обеспечению того, чтобы наши модели работали в производственной среде так, как мы ожидаем с точки зрения ценности для бизнеса.
Мониторинг модели — это предотвращение деградации модели. Этот раздел предназначен для выявления потенциальных проблем и предоставления разработчику возможности смягчить их до того, как они негативно повлияют на заинтересованные стороны.
Понимание прогнозов моделей — предоставляет информацию как специалистам по данным, так и заинтересованным сторонам в отношении прогнозов моделей с разной степенью детализации.
Сбор данных — дает возможность со временем улучшаться.

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

Совет № 1. Помните, что это путешествие! Вы должны сосредоточиться на том, что вас больше всего беспокоит, и стремиться к постепенным улучшениям.
Совет №2🏅Четкое и связное общение так же важно, как и техническая «правильность» модели.

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

Определение успеха

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

Самая важная метрика производительности вашей модели — это бизнес-метрика, на которую она должна влиять — Вафик Сайед

Решение об этих показателях должно быть принято до того, как мы приступим к какой-либо работе. Эти решения по метрикам и ключевым показателям эффективности окажут ОГРОМНОЕ влияние на весь жизненный цикл вашей модели. От разработки модели, интеграции и развертывания, а также мониторинга в производствеи сбора данных.

Предупреждение №1⚠️ Не относитесь к этому шагу легкомысленно! Грамотно выбирайте показатели модели и бизнес-показатели в зависимости от вашей проблемы.
Предупреждение № 2⚠️ «Идеальный» показатель (идеальное соответствие) может меняться со временем.
Совет №1: используйте простые, наблюдаемые и атрибутивные показатели.
Совет #2🏅собирайте метрики на ранней стадии. Никому не нравится потом искать строки в логах!

Следующим шагом к укреплению доверия является забота о наших данных. Как гласит известная цитата «мусор на входе, мусор на выходе» (💩+🧠= 💩)

Забота о ваших данных

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

Неверные данные приведут к ошибочным моделям. Это, в свою очередь, повлияет на последующие услуги неконтролируемым (и почти всегда негативным) образом. — Кевин Бабиц

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

Предупреждение №1⚠️ Качеству данных никогда не уделяется достаточно внимания и приоритета 🔍.
Совет №1🏅базовые проверки качества данных помогут вам далеко🚀. Наиболее заметными проблемами являются отсутствие данных, нарушение диапазона, несоответствие типов и актуальность.
Совет #2🏅Вы должны сбалансировать проверку из разных частей конвейера. Проверка источника может выявить более скрытые проблемы именно тогда, когда они происходят. Но его охват ограничен, поскольку вы можете исследовать только этот конкретный источник; вместо этого вы можете проверить выходные данные в конце конвейера, чтобы охватить больше места.
Совет № 3🏅после базового качества данных проверки посмотрите, как ведущие технологические компании подходят к качеству данных.
Совет #4🏅после базовой проверки качества данных вы можете позаботиться о "управление данными".

Следующим шагом к построению доверия является этап разработки модели.

Разработка модели

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

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

Показатели обучения — этот механизм оценки использует показатели производительности на основе исторических данных. Он включает в себя такие показатели, как точность, полнота, откалибрована ли модель или все, что мы определили.
Бизнес-показатели. Этот механизм оценки использует показатели эффективности на основе исторических данных. Сюда входят такие показатели, как CTR, доход или все, что мы определяем.
Метрики Guardrail – этот механизм оценки использует метрики производительности, представляющие ограничения, наложенные на модели. Он включает в себя такие показатели, как максимальное время вывода, минимальная пропускная способность, максимальный размер модели и т. д.
Справедливость и предвзятость. Является ли результат предвзятым в отношении определенной группы населения с точки зрения эффективности? Мы вообще заботимся об этом?
Тестирование — тестирование должно быть сосредоточено как на артефактах, так и на процессе (в отличие от предыдущих методов). Вы можете проверить правильность отдельных компонентов (в основном бизнес-логики). Кроме того, вы можете проверить, ломается ли ваша модель, и протестировать ранее встречавшиеся ошибки. Наконец, вы можете проверить, насколько хорошо разные компоненты взаимодействуют друг с другом в конвейере машинного обучения. Поскольку это огромная тема без надлежащих ресурсов, скоро я опубликую о ней целую запись в блоге.

Совет #1. Используйте системы отслеживания экспериментов, такие как ClearML или MLflow, чтобы отслеживать все параметры ваших моделей, которые вы использовали.
Совет №2 🏅при работе с конфиденциальными средами может оказаться полезным уровень политик. Этот слой добавляет логику к вашим прогнозам, чтобы исправить их. Это может быть чрезвычайно полезно при аномальных событиях.
Совет №3🏅соблюдайте правила гигиены. Используйте методы удержания, перекрестной проверки и выборки.
Совет №4 🏅измеряйте показатели обучения, бизнеса и ограждений по всему набору данных и предопределенным сегментам.
Совет №5🏅 из-за динамической природы машинного обучения тестирование еще более важно.
Предупреждение №1⚠️ опасайтесь утечки данных.
Предупреждение №2⚠️ будьте осторожны с переоценкой и недооценкой.

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

Непрерывная интеграция (CI)

В классическом программном обеспечении все ломается, и нам нужно защищать себя. Один из классических способов защитить себя — КИ. Мы проводим все наши тесты, включая тесты работоспособности, модульные тесты, интеграционные тесты и сквозные тесты 🏗️.

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

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

Чтобы получить желаемые артефакты, нам нужно сделать весь наш конвейер воспроизводимым. Хотя это тяжело. Нам нужно уменьшить случайность (внедрение семян) и отслеживать используемые параметры модели (данные, код, артефакты). Вы можете использовать системы отслеживания экспериментов, такие как ClearML или MLflow.

Совет #1🏅Google написал отличное руководство о том, как выполнять непрерывную интеграцию в проекты машинного обучения.
Совет профессионала №2🏅воспроизводимость является ключевым фактором.
Совет профессионала №3🏅проведите надлежащий код-ревью.
Предупреждение⚠️ Выбор автоматического переобучения моделей в каждом CI зависит от подъема, который это даст вашей модели и того, сколько это будет стоить вашей компании. Снизить риск можно с помощью выключателя и переобучить только по определенным критериям.

Следующим шагом к построению доверия является развертывание. На этом этапе наши релиз-кандидаты видят некоторый производственный трафик, пока они не станут «достойными» замены существующих моделей.

Развертывание: путь к производству

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

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

Теневое развертывание — в этом механизме мы запускаем как существующую модель, так и модели-кандидаты на одних и тех же данных (или их части). Но мы обслуживаем только прогнозы из существующей модели. Это несколько консервативный подход, но он довольно распространен из-за своей простоты. Это довольно ограничено в случаях, когда вы не получаете истинной истины как для ошибки, так и для успеха.
A/B тестирование —в этом механизме мы запускаем как существующую модель, так и модели кандидатов и разделяем их на статические сегменты. Все модели, включая кандидатов, служат прогнозам. После достаточного трафика или времени результаты эксперимента должны сойтись, и вы сможете оценить, какая модель дает наибольшую ценность. Это имеет смысл только в том случае, если есть лучший вариант, который последовательно работает.
Многорукий бандит —в этой форме развертывания мы динамически запускаем как существующую модель, так и модели-кандидаты в отдельных сегментах. Это увеличивает распределение между различными моделями. Он отдает предпочтение более эффективным моделям.

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

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

Совет №1🏅Вы можете использовать несколько механизмов развертывания вместе.
Совет №2🏅 Надейтесь на лучшее и готовьтесь к худшему. У вас всегда должен быть план отката, даже если он составляется вручную.
Внимание!⚠️ провалить эксперимент очень просто.

Следующим шагом к построению доверия является осмысление производственного трафика. Мы будем следить за нашими моделями и давать интерпретацию прогнозов наших моделей.

Осмысление производственного трафика

Мониторинг модели

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

В классическом программном обеспечении мы бы писали журналы, вели аудит и отслеживали аппаратные показатели, такие как ОЗУ, ЦП и т. д. 🦾. Кроме того, мы хотели бы отслеживать показатели использования нашего приложения, такие как количество запросов в секунду 📈.
В приложениях для машинного обучения нам нужно все, что использует классическое программное обеспечение, и даже больше. Нам нужно отслеживать статистические атрибуты входных данных и прогнозов 🤖. Кроме того, каждый сегмент может вести себя по-разному. Таким образом, нам нужна возможность нарезать и нарезать разные сегменты 🍰.

Наиболее распространенная деградация, которую мы должны отслеживать, — это дрейф (несколько видов дрейфа):

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

Каждый вид дрейфа находит разные проблемы и использует разную информацию.

Кроме того, во многих сценариях вы также должны следить за ними:

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

Существует множество инструментов, таких как fiddler-ai, arize и aporia, которые могут помочь вам в этом. Вы можете углубиться в разницу между ними в этом сообщении в блоге.

Совет №1🏅спросите заинтересованные стороны об их наихудшем сценарии и соответствующим образом отразите эти опасения в показателях.
Совет №2🏅старайтесь писать стабильные тесты. Пусть тесты работают на вас, а не наоборот.
Совет № 3🏅соблюдайте гигиену мониторинга, например, делайте оповещения действенными и используйте информационную панель.
Предупреждение. #1⚠️ Остерегайтесь усталости оповещений.
Предупреждение №2⚠️ Остерегайтесь постепенных изменений и соответствующим образом планируйте свои оповещения.
Предупреждение # 3⚠️ Не сосредотачивайтесь на предвзятости и обнаружении аномалий, если только это не критично для вашего сценария.

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

Понимание прогнозов моделей

Модели рассматривались как черный ящик 🗃 из-за отсутствия интерпретируемости.

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

Это особенно проблематично в тех случаях, когда предел погрешности невелик❗. Например, некоторые клиницисты не решаются развертывать модели машинного обучения, даже если их использование может быть выгодным. Интерпретируемость имеет свою цену💰. Существует компромисс между сложностью модели и интерпретируемостью.Например, логистическая регрессия может быть вполне интерпретируемой, но она может работать хуже, чем нейронная сеть.

Есть как глобальная, когортная, так и локальная объяснимость:

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

Большинство инструментов, таких как лайм и шап, поддерживают все это🔧🔨.

Совет №1. Вам следует начать с интерпретируемой модели, которая упрощает отладку и может оказаться достаточно хорошей.
Совет №2. понять и использовать их в качестве проверки работоспособности при будущей разработке модели и CI.

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

Сбор новых точек данных

Как мы видели ранее, модели ветшают и через некоторое время становятся бесполезными 💩.
По мере появления новых паттернов и трендов модель сталкивается со все большим количеством точек данных, которых она не видела на этапе обучения👨‍🦯. Некоторые из них превращаются в ошибки, которые со временем могут легко накапливаться, и вы обнаружите, что ваша компания быстро теряет деньги.

Чтобы справиться с этим, вы должны кормить свои модели новыми помеченными данными. Вы должны использовать мониторинг, чтобы определить, какие модели вы должны переобучить, и когда вы должны переобучить свои модели ♾️. Размеченные данные могут принимать различные формы. В некоторых случаях вы получите наземную правду с задержкой, только часть помеченных данных (из-за предвзятости) или вообще не получите наземной истины 🔮.

Критерии переобучения моделей зависят от подъема, который он принесет вашей модели, и от того, сколько это будет стоить вашей компании. Это компромисс между человеческими ресурсами, затратами на облако и ценностью для бизнеса ⚖️.

Предупреждение № 1⚠️ Впереди много проблем, включая качество данных, конфиденциальность, масштабирование, стоимость и многое другое.
Предупреждение № 2⚠️ модель со временем ухудшится. как мир меняется. Подготовьтесь к этому.
Совет №1🏅собирайте только те данные с метками, которые вам нужны. Никто не осмелится удалить огромный кусок ненужных данных.
Совет № 2🏅объем автоматизации, который вы получили от системной интеграции, напрямую влияет на объем необходимого переобучения.

Последние слова

В этой статье мы начали с объяснения, почему трудно доверять моделям машинного обучения. Я создал блок-схему, которая обобщает защитные механизмы на каждом этапе. Я называю это «Поток машинного обучения TRUST».

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

Спасибо Джаду Кадану, Алмогу Баку и Рону Ициковичу за рецензирование этого поста и за то, что сделали его более понятным.