Предположим, у нас есть кто-то, строящий прогностическую модель, но он не обязательно хорошо разбирается в надлежащих статистических или машинных принципах обучения. Может быть, мы помогаем этому человеку, когда он учится, или, возможно, этот человек использует какой-то пакет программного обеспечения, который требует минимальных знаний для использования.
Теперь этот человек вполне может признать, что реальный тест основан на точности (или любой другой метрике) данных вне выборки . Однако меня беспокоит то, что есть много тонкостей, о которых нужно беспокоиться. В простом случае они строят свою модель и оценивают ее на основе данных обучения и оценивают ее на основе данных о проведенном тестировании. К сожалению, иногда бывает слишком легко вернуться назад и настроить какой-либо параметр моделирования и проверить результаты на тех же «тестовых» данных. На этом этапе эти данные больше не являются истинными данными вне выборки, и переобучение может стать проблемой.
Одним из возможных способов решения этой проблемы было бы предложить создать множество наборов данных вне выборки, чтобы каждый набор тестируемых данных мог быть отброшен после использования и не использоваться повторно вообще. Это требует большого количества управления данными, особенно, что разделение должно быть выполнено перед анализом (таким образом, вам нужно было бы знать, сколько разделений заранее).
Возможно, более традиционный подход - это перекрестная проверка в k-кратном порядке. Однако в некотором смысле это теряет различие между наборами данных «обучение» и «тестирование», которые, я думаю, могут быть полезны, особенно для тех, кто еще учится. Также я не уверен, что это имеет смысл для всех типов прогнозирующих моделей.
Есть ли какой-то способ, который я упустил, чтобы помочь преодолеть проблему переоснащения и проверки утечки, оставаясь при этом не совсем понятным для неопытного пользователя?
Ответы:
Вы правы, это серьезная проблема в машинном обучении / статистическом моделировании. По сути, единственный способ действительно решить эту проблему - сохранить независимый набор тестов и сохранить его до завершения исследования и использовать его для окончательной проверки.
Тем не менее, неизбежно люди будут смотреть на результаты тестового набора, а затем соответственно менять свою модель; однако это не обязательно приведет к улучшению производительности обобщения, поскольку разница в производительности разных моделей может быть в значительной степени обусловлена конкретной выборкой тестовых данных, которые мы имеем. В этом случае, делая выбор, мы фактически переоцениваем ошибку теста.
Способ ограничить это состоит в том, чтобы сделать дисперсию ошибки теста настолько малой, насколько это возможно (т.е. изменчивость ошибки теста, которую мы увидим, если бы мы использовали разные выборки данных в качестве набора тестов, взятых из одного и того же базового распределения). Этого легче всего достичь, используя большой набор тестов, если это возможно, или, например, начальную загрузку или перекрестную проверку, если данных недостаточно.
Я обнаружил, что подобный перебор в выборе модели намного сложнее, чем это принято считать, особенно в отношении оценки производительности, см.
GC Cawley и NLC Talbot, Чрезмерная подгонка при выборе модели и последующая систематическая ошибка выбора при оценке производительности, Journal of Machine Learning Research, 2010. Research, vol. 11, стр. 2079-2107, июль 2010 г. (www)
Проблема такого рода особенно влияет на использование эталонных наборов данных, которые использовались во многих исследованиях, и на каждое новое исследование косвенно влияют результаты более ранних исследований, поэтому наблюдаемая эффективность, вероятно, будет чрезмерно оптимистичной оценкой истинного выполнение метода. Я пытаюсь обойти это, чтобы посмотреть на множество наборов данных (чтобы метод не был настроен на один конкретный набор данных), а также использовать несколько случайных тестов / обучающих сплитов для оценки производительности (чтобы уменьшить дисперсию оценки). Однако результаты все еще нуждаются в предостережении о том, что эти критерии были переоценены.
Другой пример, где это происходит, - соревнования по машинному обучению с таблицей лидеров, основанной на проверочном наборе. Некоторые конкуренты неизбежно продолжают возиться со своей моделью, чтобы подняться дальше вверх по таблице лидеров, но затем оказываются в самом низу финального рейтинга. Причина этого заключается в том, что их множественный выбор переопределил набор проверки (эффективно изучая случайные изменения в небольшом наборе проверки).
Если вы не можете сохранить статистически чистый набор тестов, то я боюсь, что двумя лучшими вариантами являются: (i) сбор новых данных для создания нового статистически чистого набора тестов или (ii) предупреждение о том, что новая модель была основана на выбор, сделанный после наблюдения за ошибкой тестового набора, поэтому оценка производительности, скорее всего, будет иметь оптимистичный уклон.
источник
Один из способов убедиться в этом - убедиться, что вы закодировали все, что вы делаете, чтобы соответствовать модели, даже «переделывая». Таким образом, когда вы запускаете процесс несколько раз, скажем, через перекрестную проверку, вы сохраняете согласованность между запусками. Это гарантирует, что все потенциальные источники вариации будут охвачены процессом перекрестной проверки.
Другая жизненно важная вещь - обеспечить репрезентативную выборку в обоих наборах данных. Если ваш набор данных не является представителем того типа данных, который вы ожидаете использовать для прогнозирования, то вы мало что можете сделать. Все моделирование основывается на предположении, что «индукция» работает - вещи, которые мы не наблюдали, ведут себя как вещи, которые мы наблюдали.
Как правило, избегайте сложных процедур подбора моделей, если (i) вы не знаете, что делаете, и (ii) вы не попробовали более простые методы и обнаружили, что они не работают, и как комплексный метод исправляет проблемы с простым методом. «Простой» и «сложный» означают «простой» или «сложный» для человека, выполняющего примерку. Причина, по которой это так важно, заключается в том, что это позволяет вам применить то, что я люблю называть «тестом нюха», к результатам. Результат выглядит правильно? Вы не можете «нюхать» результаты процедуры, которую вы не понимаете.
ПРИМЕЧАНИЕ: следующая, довольно длинная часть моего ответа основана на моем опыте, который находится в области , где возможно большое. Я почти уверен, что нижеследующее не относится к случаям илиN>>p p N≈p N<p
Когда у вас большая выборка, разница между использованием и отказом от данного наблюдения очень мала, если ваше моделирование не слишком «локально». Это связано с тем, что влияние данной точки данных обычно имеет порядок . Таким образом, в больших наборах данных остатки, которые вы получаете от «удержания» набора тестовых данных, в основном такие же, как и остатки, которые вы получаете от его использования в наборе обучающих данных. Вы можете показать это, используя обычные наименьшие квадраты. Остаток, который вы получите от исключения го наблюдения (т. Е. Какой будет ошибка набора тестов, если мы поместим наблюдение в набор тестов), составляет , где - это остаток тренировки, а1N i etesti=(1−hii)−1etraini etraini hii является рычагом й точки данных. Теперь у нас есть то, что , где - количество переменных в регрессии. Теперь, если , то для любого чрезвычайно трудно быть достаточно большим, чтобы сделать заметную разницу между ошибками тестового набора и обучающего набора. Мы можем взять упрощенный пример, предположим, что (перехват и переменная), матрица проектирования - (как обучающий, так и проверочный наборы), а рычаг -i ∑ihii=p p N>>p hii p=2 1 N×p X
Где , и . Наконец, является стандартизированной переменной-предиктором и измеряет, сколько стандартных отклонений от среднего. Итак, мы знаем с самого начала, что ошибка тестового набора будет намного больше, чем ошибка обучающего набора для наблюдений «на краю» обучающего набора. Но это опять-таки в основном тот репрезентативный вопрос - наблюдения «на краю» менее репрезентативны, чем наблюдения «в середине». Кроме того, это для порядка . Так что если у вас есть наблюдений, даже еслиx¯¯¯=N−1∑ixi x2¯¯¯¯¯=N−1∑ix2i s2x=x2¯¯¯¯¯−x¯¯¯2 x~i=xi−x¯¯¯sx xi 1N 100 x~i=5 (выброс в x-пространстве по большинству определений), это означает , и ошибка теста занижена с коэффициентом всего . Если у вас большой набор данных, скажем, , он еще меньше, , что меньше . Фактически, для наблюдений вам потребуется наблюдение для того, чтобы сделать оценку ошибки тестового набора, используя ошибку обучающего набора.hii=26100 1−26100=74100 10000 1−2610000 1% 10000 x~=50 25%
Таким образом, для больших наборов данных использование тестового набора не только неэффективно, но и не нужно, пока . Это относится к OLS, а также приблизительно применимо к GLM (подробности для GLM различны, но общий вывод тот же). В более чем измерениях «выбросы» определяются наблюдениями с большими показателями «основного компонента». Это можно показать, написав где - (ортогональная) матрица собственных векторов для с матрицей собственных значений . Мы получаем гдеN>>p 2 hii=xTiEET(XTX)−1EETxi E XTX Λ hii=zTiΛ−1zi=∑pj=1z2jiΛjj zi=ETxi является основным компонентом оценки для .xi
Если ваш тестовый набор имеет наблюдений, вы получите матричную версию , где и - строки матрицы проекта в тестовом наборе. Итак, что касается регрессии OLS, вы уже знаете, какие ошибки были бы в «наборе тестов» для всех возможных разбиений данных на обучающие и тестовые наборы. В этом случае ( ) нет необходимости разбивать данные вообще. Вы можете сообщать об ошибках набора тестов «лучший случай» и «наихудший случай» практически любого размера, фактически не разбивая данные. Это может сэкономить много времени и ресурсов ПК.k etest{k}=(Ik−H{k})−1etrain{k} H{k}=X{k}(XTX)−1XT{k} X{k} N>>p
По сути, все это сводится к использованию штрафного термина для учета разницы между ошибками обучения и тестирования, такими как BIC или AIC. Это эффективно дает тот же результат, что и при использовании тестового набора, однако вы не обязаны выбрасывать потенциально полезную информацию. С помощью BIC вы аппроксимируете данные для модели, которая математически выглядит следующим образом:
Обратите внимание, что в этой процедуре мы не можем оценить какие-либо внутренние параметры - каждая модель должна быть полностью указана или ее внутренние параметры интегрированы. Однако мы можем сделать это похожим на перекрестную проверку (используя определенную функцию потерь), многократно используя правило продукта, а затем ведя журнал результатов:Mi
Это предполагает форму перекрестной проверки, но там, где обучающий набор постоянно обновляется, по одному наблюдению за раз из набора тестов - аналогично фильтру Калмана. Мы прогнозируем следующее наблюдение из тестового набора, используя текущий обучающий набор, измеряем отклонение от наблюдаемого значения, используя условную логарифмическую вероятность, а затем обновляем обучающий набор, чтобы включить новое наблюдение. Но обратите внимание, что эта процедура полностью переваривает все доступные данные, и в то же время гарантирует, что каждое наблюдение проверяется как случай «вне выборки». Он также инвариантен, поскольку не имеет значения, что вы называете «наблюдением 1» или «наблюдением 10»; результат один и тот же (вычисления могут быть проще для некоторых перестановок, чем для других). Функция потерь также является «адаптивной» в том смысле, что если мы определим L i iLi=log[p(yi|y1…yi−1MiI)] , тогда резкость зависит от , потому что функция потерь постоянно обновляется новыми данными.Li i
Я бы предположил, что оценка прогностических моделей таким способом будет работать достаточно хорошо.
источник
Я полагаю, что единственный способ гарантировать это, что кто-то еще имеет данные испытаний . В отношениях между клиентом и консультантом этим можно управлять довольно легко: клиент дает консультанту набор обучения, на котором строятся модели, и в рамках этого набора консультанта консультант может разделить данные любым необходимым способом, чтобы убедиться, что переобучение не происходят; впоследствии модели возвращаются клиенту для использования в их тестовых данных.
Для отдельного исследователя очевидно, что наилучшей практикой будет подражать этой установке. Это будет означать выдачу некоторых данных для проверки после того, как будет выполнен весь выбор модели. К сожалению, как вы говорите, это не практикуется многими людьми, и это даже случается с людьми, которые должны знать лучше!
Однако в конечном итоге это зависит от того, для чего используется модель. Если вас интересует только прогнозирование по этому единственному набору данных, то, возможно, вы можете превзойти все, что захотите? Однако, если вы пытаетесь продвигать свою модель как модель, которая хорошо обобщает, или используете модель в каком-то реальном приложении, то, конечно, это имеет большое значение.
Существует второстепенный вопрос , который я думал , что я должен упомянуть, что в том , что даже если вы будете следовать все процедуры правильно, вы можете в конечном итоге с моделями, которые overfitted, из - за данных , не будучи по- настоящему н.о.р. . Например, если в данных имеются временные корреляции, то, если вы возьмете все свои тренировочные данные со времен 1-3 и проведете тестирование по времени 4, то вы можете обнаружить, что ошибка прогноза больше ожидаемой. В качестве альтернативы могут существовать специфические для эксперимента артефакты, такие как используемое измерительное устройство или совокупность субъектов в экспериментах на людях, которые приводят к тому, что обобщение моделей будет хуже, чем ожидалось.
источник
view
установки соответствующих разрешений базы данных, когда некоторые команды имеют доступ к тестовым данным, а другие - к тестовым слепым.Это очень хороший вопрос и очень тонкая проблема. Конечно, есть ошибки с плохим умыслом, которые происходят от того, что кто-то пытается вас обмануть. Но есть более глубокий вопрос о том, как избежать случайной утечки и избежать честных ошибок.
Позвольте мне перечислить некоторые практические передовые практики. Все они происходят от честных ошибок, которые я сделал в какой-то момент:
источник
Многие важные моменты были освещены в превосходных ответах, которые уже даны.
В последнее время я разработал этот личный контрольный список для статистической независимости тестовых данных:
В моей области есть еще один специфический тип утечки данных: мы делаем пространственно разрешенную спектроскопию биологических тканей. Эталонная маркировка тестовых спектров должна быть скрыта от спектроскопической информации, даже если соблазнительно использовать кластерный анализ, а затем просто выяснить, к какому классу относится каждый кластер (это будут тестовые данные с полуснадзором, которые не независимый вообще).
И последнее, но не менее важное: при проверке кода при повторной выборке я фактически проверяю, не приводят ли вычисленные индексы к набору данных, чтобы они не приводили к отбору строк теста у обучающихся пациентов, дней и т. Д.
Обратите внимание, что «разделение не выполнено для обеспечения независимости» и «разделение перед выполнением любого вычисления, которое включает в себя более одного случая», также может происходить с тестированием, в котором утверждается, что используется независимый набор тестов, и последнее, даже если аналитик данных Слепой к ссылке на тестовые случаи. Эти ошибки не могут произойти, если данные испытаний будут удерживаться до тех пор, пока не будет представлена окончательная модель.
* Я использую пациентов как верхнюю иерархию данных только для простоты описания.
** Я аналитик-химик: дрейф инструментов - известная проблема. Фактически, частью проверки методов химического анализа является определение того, как часто необходимо проверять калибровки по проверочным образцам, и как часто необходимо повторять калибровку.
FWIW: На практике я имею дело с приложениями, где
Лично мне еще не приходилось встречать приложение, в котором для разработки классификатора я получаю достаточно независимых случаев, чтобы позволить отложить правильный независимый набор тестов. Таким образом, я пришел к выводу, что правильно выполненная проверка повторной выборки является лучшей альтернативой, пока метод находится в стадии разработки. Надлежащие валидационные исследования, в конечном счете, должны быть выполнены, но это огромная трата ресурсов (или результаты не будут содержать никакой полезной информации из-за отклонений), делая это, пока разработка метода находится в стадии, когда вещи все еще изменяются.
источник
Если я правильно помню, некоторые из конкурсов по прогнозированию (например, Netflix или те, что на Kaggle) используют эту схему:
Есть тренировочный набор, с «ответами». Существует тестовый набор № 1, на который исследователь дает ответы. Исследователь узнает их счет. Существует набор тестов № 2, на который исследователь дает ответы, НО исследователь не узнает их оценки. Исследователь не знает, какие случаи предсказания находятся в # 1 и # 2.
В какой-то момент набор № 2 должен стать видимым, но вы по крайней мере ограничили загрязнение.
источник
В некоторых случаях, таких как предикторы на основе биологических последовательностей, недостаточно гарантировать, что случаи не появляются в более чем одном наборе. Вам все еще нужно беспокоиться о зависимости между наборами.
Например, для предикторов на основе последовательностей необходимо удалить избыточность, обеспечив, чтобы последовательности в разных наборах (включая разные наборы перекрестной проверки) не разделяли высокий уровень сходства последовательностей.
источник
Я бы сказал, что «перекрестная проверка в k-кратном порядке» является правильным ответом с теоретической точки зрения, но ваш вопрос кажется больше об организационных и обучающих материалах, поэтому я отвечу по-другому.
Когда люди «еще учатся», часто думают, что они учатся «быстро и грязно» применять алгоритмы и все «дополнительные» знания (мотивация проблемы, подготовка набора данных, проверка, анализ ошибок, практические ошибки и т. Д.). ) будут изучены «позже», когда они «более подготовлены».
Это совершенно неправильно.
Если мы хотим, чтобы учащийся или кто-либо другой понимал разницу между тестовым набором и тренировочным набором, худшее - дать два набора двум разным ребятам, как если бы мы думали, что «на этом этапе» «дополнительные знания» вредны. Это похоже на водопадный подход в разработке программного обеспечения - несколько месяцев чистого проектирования, затем несколько месяцев чистого кодирования, затем несколько месяцев чистого тестирования и, в конце концов, результат жалкого отбрасывания.
Обучение не должно идти как водопад. Все части обучения - проблемная мотивация, алгоритм, практические навыки, оценка результатов - должны собираться вместе небольшими шагами. (Подобно гибкому подходу в разработке программного обеспечения).
Возможно, все здесь прошли через ml-class.org Эндрю Нга - я бы назвал его курс примером здорового , если хотите, стиля обучения - такого, который никогда не вызовет вопроса о том, «как убедитесь, что тестовые данные не проникают в тренировочные данные ".
Обратите внимание, что я, возможно, совершенно неправильно понял ваш вопрос, поэтому извиняюсь! :)
источник