Кодирование и перекрестная проверка

Aug 18 2020

Недавно я задумался о правильном использовании кодирования в схеме перекрестной проверки. Обычно рекомендуемый способ кодирования функций:

  1. Разделить данные на набор для обучения и тестирования (удержания)
  2. Установите энкодер (или LabelEncoderили OneHotEncoder) на поезд.
  3. Преобразуйте поезд и испытательный комплект с помощью встроенного кодировщика.

Утверждается, что этот способ предотвращает утечку данных. Однако во время перекрестной проверки это, кажется, часто опускается. Предположим, я выполняю перекрестную проверку на вышеупомянутом наборе поездов. Если я кодирую набор поездов, а затем выполняю перекрестную проверку, он на самом деле не имитирует шаги, описанные выше. Разве кодирование не должно выполняться «в рамках» перекрестной проверки? Например, предполагая, что мы выполняем 5-кратную перекрестную проверку, не следует ли нам размещать кодировщик в 4 раза и преобразовывать в 5-кратном на каждом этапе перекрестной проверки? Я считаю, что это то, что обычно делается в целевой кодировке, но не на самом деле с меткой или горячим кодированием.

Поэтому мои вопросы таковы:

  1. Правильно ли я говорю о необходимости размещать кодировщик в 4 раза, а не в 5-м диапазоне проверки на каждом этапе перекрестной проверки, если мы действительно хотим предотвратить переобучение?
  2. Если нет, то почему действительно необходимо выполнять все 3 шага, упомянутые ранее, при работе с набором для обучения и тестирования (удержания)?

Ответы

1 Erwan Aug 18 2020 at 07:50

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

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

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

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

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