By Саи Гита, эксперт в области Big Data Engineering и Data Science.

Ассоциация Рандеву архитектура предложенный Тедом Даннингом и Эллен Фридман в их книге о Логистика машинного обучения было прекрасным решением, которое я нашел для конкретной архитектурной проблемы, над которой работал. Я искал проверенный шаблон проектирования или архитектурный шаблон, который помог бы мне запускать модели Challenger и Champion вместе удобным для сопровождения и поддержки способом. Архитектура рандеву была значительно полезнее в мире больших данных, потому что вы имеете дело с тяжелыми данными и большими конвейерами.

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

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

Модель Дрифт

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

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

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

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

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

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

Модели чемпионов-претендентов

Как правило, модель в производстве называется Чемпион модель. И любая другая модель, которая, кажется, хорошо работает в ваших небольших испытаниях и готова к запуску в производство, является Претендент модель. Эти модели Challenger были предложены, потому что мы предполагаем, что они могут работать лучше, чем модель Champion. Но как мы это докажем?

Модель чемпиона обычно работает со всеми входящими данными для предоставления прогнозов. Однако на каких данных работает модель Challenger?

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

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

Типичный альфа-бета-конвейер будет выглядеть так:

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

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

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

Это будет выглядеть примерно так:

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

Некоторые из основных последствий — это время и усилия по созданию этих конвейеров снова и снова без уверенности, что модель Challenger действительно будет работать так, как ожидалось. Процесс CI/CD, развертывание, мониторинг, механизмы аутентификации и т. д. — лишь некоторые из них. Кроме того, другие затраты связаны с инфраструктурой, которая должна быть дважды подготовлена.

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

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

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

Рандеву Архитектура

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

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

Часть 1:

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

Часть 2:

Это инфраструктура обмена сообщениями, такая как Kafka, которая вступает в игру, привнося чувство асинхронности. Данные, подготовленные как признаки, публикуются на шине сообщений. Теперь каждая модель слушает эту шину сообщений и срабатывает, выполняя себя с подготовленными данными. Эта шина сообщений обеспечивает здесь архитектуру plug-and-play.

Часть 3:

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

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

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

Часть 4:

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

Оттуда процесс рандеву подбирает баллы и решает, что нужно сделать, как описано в части 5.

Часть 5:

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

Итак, здесь мы добились двух вещей:

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

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

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

Да, другим критерием может быть время или задержка. Если нам нужно получить результат, скажем, менее чем за 5 секунд, процесс ожидает все результаты от моделей до 5 секунд, сравнивает только их и возвращает лучшие данные. Несмотря на то, что на 6-й секунде возвращается другая модель, которая могла работать намного лучше, она игнорируется, поскольку не соответствует критериям задержки.

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

Заключение

Благодаря внедрению асинхронности через шины сообщений был введен уровень развязки, дающий возможность включать модели plug-and-play в жесткий конвейер данных.

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

Обзор

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

1. Можно использовать различные критерии, чтобы решить, какие оценки, выходные данные или прогнозы могут быть отправлены из процесса прогнозирования. Эти критерии могут быть основаны на задержке, производительности модели или просто на основе времени.
2. Он предоставляет возможность динамически определять и изменять эти критерии в процессе рандеву. Вы можете поднять его на другой уровень, введя здесь механизм правил.
3. Это дает возможность заставить все данные пройти через все конвейеры или выбрать только подмножество для прохождения через множество конвейеров. Например, если у вас есть бакалейные товары и товары общего назначения, для которых вы прогнозируете, бакалейные товары могут проходить через собственные модели Чемпиона и Претендента, в то время как товары общего назначения, которые обычно продаются медленно, могут иметь свои собственные конвейеры.
4. Он также обеспечивает возможность одновременного запуска множества моделей без перестройки или повторного развертывания значительной части конвейера больших данных. Помимо экономии усилий и времени, также оптимизируются затраты на инфраструктуру.

Рекомендации

1. Логистика машинного обучения Тед Даннинг; Эллен Фридман — 3-я глава «Архитектура рандеву для машинного обучения»
2. Статья о todatascience.com"Архитектура Rendezvous для науки о данных в производстве» Ян Тейхманн

Оригинал, Перемещено с разрешения.

Bio: Саи Гита (@saigeethamn) — архитектор с опытом создания стратегических дорожных карт и инноваций на основе потребностей предприятия и передовых технологий. Специалист по большим данным, обладающий знаниями в области науки о данных, который может преодолеть разрыв между двумя мирами и обеспечить успех любой инициативе по работе с большими данными на вашем предприятии.

Связанный:

• До свидания, большие данные. Привет, массивные данные!
• Полное руководство по переобучению моделей
• Скрытый риск искусственного интеллекта и больших данных