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

Если вы работаете в академических кругах или в промышленности, вы работаете над проблемами реальной жизни. Данные, над которыми мы работаем, не являются синтетическими, они взяты из реального мира. Работая в наших офисах, абстрагируясь от реальных событий, связанных с нашими проектами, бизнесом или проблемами; мы склонны терять связь с проблемами, которые решаем. Проекты легко увидеть в виде чисел. Статические числовые значения, строки символов и бессмысленные идентификаторы. Мы храним их в двоичном формате, отключенном от реального мира. В этом случае легко забыть, что реальный мир динамичен, как и данные. Проблема начинает возникать, когда мы пренебрегаем или наивно забываем об этой реальности и сосредотачиваемся на наших любимых KPI. Эта история о том, как наши модели машинного обучения остаются статичными, в то время как данные меняются изо дня в день вместе с динамичным миром.

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

Модели создаются на основе снимка мира

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

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

Модели терпят неудачу, когда мир меняется

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

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

Непрерывность исполнения

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

1. Проверки данных в восходящем направлении

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

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

2. Проверки вывода в нисходящем направлении

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

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

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