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

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

Предыстория обучения и разделения тестирования

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

Почему?

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

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

Достаточно ли разделения обучения и тестирования?

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

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

Итак, вы просите команду Data Science показать вам модель и данные. Они показывают вам полный набор данных и то, как он был разделен на 70% обучающего и 30% тестового подмножеств, клянясь, что окончательная модель была обучена исключительно на обучающем наборе данных и его показателях производительности, полученных только из тестового набора данных.

Теперь вы чувствуете облегчение. Ничего не может пойти не так. Верно?

Что ж, есть три типичных вещи, которые могут пойти не так.

1. Набор тестовых данных уже использовался ранее.

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

Чтобы это проверить, нужно задать два вопроса.

На каком наборе данных было выполнено первоначальное исследование данных?

Первая часть (и обычно более трудоемкая) в науке о данных - это исследование и обработка данных. Было ли это выполнено до или после разделения данных на обучающие и тестовые наборы данных?

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

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

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

Сколько различных моделей было оценено в тестовом наборе данных?

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

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

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

2. Тестовые данные содержат некоторую утечку данных.

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

Выявить проблемы с утечкой данных не всегда очевидно. На практике это происходит двумя распространенными способами:

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

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

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

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

3. Вы все еще не можете проверить данные из будущего.

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

Можете ли вы по-прежнему верить, что характеристики протестированной модели отразятся на производстве?

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

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

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

По моему опыту в бизнес-контексте, этим аспектом часто пренебрегают. Однако теперь, когда мир пострадали от COVID, это может измениться. Подумайте об обучении модели прогнозирования отмены бронирования отелей непосредственно перед вспышкой COVID (как это сделал я!).

И когда жизнь постепенно вернется к нормальной жизни после COVID, будет все труднее доверять прошлым данным для предсказания будущего без каких-либо корректировок. Но, возможно, это тема для другого поста!