Содержание:
Часть 1: Создание автоматизированного оценщика покемонов: введение
Часть 2: вы здесь
В первой статье этой серии мы ознакомились с основными аспектами покемонов, относящимися к созданию автоматизированного рейтинга покемонов, который предсказывает соревновательный уровень Smogon для покемонов. Однажды уже выполнив эту задачу, какова была наша производительность по сравнению с другими попытками и подходами? Эта статья длиннее, чем я рассчитывал, так что извините за это. Тем не менее, я думаю, что этот объем стоит всестороннего обзора литературы по всей этой проблеме.
Было всего несколько попыток выполнить эту задачу, с которыми я столкнулся до сих пор, пытаясь понять, насколько хорошо работает моя модель, что является признаком того, насколько велик потенциал для улучшения. Первый подход, с которым я столкнулся, имел прекрасную страницу, на которой они объясняли уроки, которые они извлекли из своей попытки решить нашу общую задачу.
Этот подход немного печален по причинам, которые я объясню позже, но, несмотря на это, я думаю, что у них есть несколько действительно впечатляющих идей. Можно заметить, что распределение шрифтов по уровням (как вы можете видеть на приведенной выше диаграмме) вводит в заблуждение. Казалось бы, покемоны Драконьего и Психического типа намного сильнее других, поскольку их очень много на уровне Убер (самом высоком). Тем не менее, именно легендарные покемоны обычно относятся к типу экстрасенсов и / или драконов. Поскольку легендарные покемоны, как правило, намного сильнее среднего, они гораздо чаще появляются на высоких уровнях, таких как Ubers; именно поэтому на высоком уровне, таком как Uber, существует искусственно большое количество таких типов. Это иллюстрирует два великих принципа науки о данных:
- Мы не должны просто принимать визуализацию данных за чистую монету, но использовать ее в качестве отправной точки для получения еще более точных сведений о наших данных.
- Корреляция не является причинно-следственной связью! (например, корреляция между уровнем Uber и большим количеством психических и драконьих покемонов НЕбытьПРИЧИНОЙ психических и драконьих покемонов по своей природе настолько сильны, но из-за того, что они более распространены среди легендарных покемонов, которые ДЕЙСТВИТЕЛЬНО более сильны)
Они заметили, что общая базовая статистика, вероятно, является наиболее важным и очевидным атрибутом для приблизительной оценки силы покемонов и относительной силы различных уровней, как это чудесно показано на правой диаграмме выше. В моем проекте я также обнаружил, что статистика является наиболее важным аспектом для определения силы покемона. Конечно, модель, основанная только на статистике, мало что нам скажет, поскольку мы уже можем сортировать покемонов по их статистике, и, очевидно, есть много других аспектов, которые делают их более или менее конкурентоспособными. Они заметили две вещи, которых я не заметил:
- Они использовали анализ аномалий, чтобы обнаружить, что 14 покемонов имели базовую общую статистику, которая отличалась более чем на 2 стандартных отклонения от средней базовой общей статистики их классифицированного уровня. Судя по диаграмме, они полностью относятся к уровням PU и NU (две нижние и крайние правые ячейки, у которых есть маленькие точки-выбросы ниже и выше них), поэтому я думаю, что понимание, которое это дает, весьма ограничено. Тем не менее, идея применения анализа аномалий, подобного этому, великолепна.
- Различные наборы диаграмм для каждой статистики могут рассказать о различных тактиках, используемых на каждом уровне. Например, атака и специальная атака довольно хорошо масштабируются в зависимости от уровня, но защитные характеристики ниже в UU и NU, чем в соседних уровнях (что указывает на, возможно, более атакующий стиль игры в UU и NU).
Мы также поделились своим мнением об использовании столбчатых диаграмм с накоплением вместо круговых диаграмм, потому что столбчатые диаграммы с накоплением намного лучше для сравнения. На круговых диаграммах очень сложно определить разницу между классами одинакового размера, но с гистограммами вы можете четко видеть, какие столбцы больше, поскольку столбцы сравниваются более организованно и рядом друг с другом, даже с небольшими различиями:
Еще одно существенное отличие от моего подхода заключается в том, что они представили задачу как регрессию (косвенно классифицируя по уровням на основе непрерывных результатов регрессии). Я ненадолго попробовал регрессию в своей работе, когда тестировал различные модели, но обнаружил, что результаты были крайне неточными с бессмысленными коэффициентами по сравнению с моделями классификации, которые я использовал, поэтому вместо этого я выбрал более прямые методы классификации. Тем не менее, я считаю, что их подход к задаче регрессии демонстрирует большую проницательность, и что если кто-то хочет попробовать сделать регрессионную версию автоматизированного оценщика покемонов, то им следует следовать двум основным идеям подхода, изложенным г-ном Вадивелу. :
- Они должны преобразовать результаты от 0 до n-1 (где n — мощность набора уровней), используя умноженную сигмовидную функцию или что-то подобное. Это была умная идея, чтобы получить результаты регрессии, которые также ограничены.
- Они должны измерять ошибку регрессии с помощью MAE (средняя абсолютная ошибка), а не MSE (средняя квадратичная ошибка). MSE в большей степени наказывает за большие ошибки, но для нашей задачи это не важно. Конкретного понятия расстояния между уровнями не существует, поскольку уровни действительно дискретны, поэтому наказание за более крупные ошибки, вероятно, не имеет смысла. MAE, как правило, обеспечивает лучшую точность классификации, поскольку он рассматривает все ошибки в равной степени как ошибки, каковыми они и являются в данном случае.
Однако, основываясь на моем собственном большем успехе в классификации и на том факте, что между уровнями все равно нет конкретного расстояния (как я уже упоминал выше при сравнении MAE и MSE), я склонен думать, что классификация является более подходящим подходом к эта задача, чем регрессия. Тем не менее, это еще предстоит тщательно проверить.
Ранее я упомянул кое-что грустное об этом подходе, и печаль происходит от того факта, что этот подход отказался от задачи до того, как она была начата!
В конечном итоге эта задача оказалась непригодной для машинного обучения. По сути, пространство функций было слишком большим, а взаимодействие между функциями было слишком сложным для обучения модели с учетом небольшого обучающего набора. Другими словами, есть много примеров покемонов, которые находятся на своем конкретном уровне из-за некоторой уникальной комбинации их типа, способностей, движений и характеристик, которые сильно отличаются от других покемонов на этом уровне.
Мой подход, а также подход нескольких других исследователей позволили достичь примечательных результатов, поэтому я думаю, что этот исследователь, к сожалению, слишком рано сдался. Я думаю, что ошибка, которую они совершают, заключается в том, что они рассматривают науку о данных через призму перфекционизма (о чем я предупреждал в Части 1). Такой перфекционизм часто приводит к аналитическому параличу и пораженческим установкам. Маловероятно, что модель машинного обучения идеально (или близко к идеальному) предскажет что-то столь же сложное и динамичное, как соревновательные уровни покемонов, что не позволяет нам сделать вывод, что задача не подходит для машинного обучения. Мы должны попробовать более творческие и абстрактные подходы, поскольку явно соревнующиеся игроки в покемонов имеют несколько удобных способов измерения конкурентной эффективности покемонов по сравнению с другими. И я бы хотел, чтобы они пошли дальше в своем подходе, поскольку было бы полезно понять, насколько хорошо модель регрессии может работать в этой задаче.
Этот подход другого исследователя (Пурто) позволил продвинуться дальше в решении задачи, а также обнаружил некоторые ключевые идеи. В целом, тот факт, что они продвинулись к получению реальных результатов, является признаком того, что они не поддались тому же перфекционизму в науке о данных, что и предыдущий подход, но этот второй подход также был немного более поверхностным и небрежным в нескольких отношениях. Это ограничивает то, что мы можем извлечь из этого, но также предлагает некоторые предостерегающие истории.
Пурто разбил задачу разработки функций для оценщика покемонов на те же четыре компонента, которые мы сделали во введении: характеристики (HP, атака, защита, специальная атака, специальная защита, скорость), тип, способности и движения. Они также применили мудрый подход к «нормализации» различных функций, которые они использовали. Для некоторых алгоритмов, особенно тех, которые основаны на расстоянии, а не на дереве, важно «нормализовать» признаки, чтобы их значения попадали в один и тот же числовой диапазон. Если мы не «нормализуем», то классификатор будет неправильно взвешивать объекты большего масштаба как более важные, чем объекты меньшего масштаба (что может нанести ущерб важности объектов меньшего масштаба и привести к их неправильному игнорированию). В конце концов, Пурто попытался использовать несколько моделей, но наиболее успешными из них были LinearSVC и SVC (классификатор опорных векторов), которые на самом деле основаны на расстоянии, поэтому этот шаг нормализации был критическим.
Сначала они порядково кодировали типы, но Пурто быстро понял абсурдность этой стратегии (которая в основном говорит о том, что одни типы иерархически лучше других без всякой причины, запутывая любую модель, которую вы делаете). Их лучшая точность в обработке типов была достигнута, когда они добавили несколько столбцов для суммирования информации о типах, как показано на рисунке выше. Сначала они пытались включить эту сводную информацию в типы как столбцы с горячим кодированием, но включение всей этой информации одновременно фактически СНИЖАЕТ точность. Это происходит из-за проклятия размерности: включение в наш набор данных слишком большого количества признаков (т. ближе к количеству наблюдений/строк в наших данных). Это также приводит к тому, что модели труднее измерить, как наблюдения группируются вместе, поскольку все наблюдения начинают казаться более равноудаленными.
Другими словами, чем выше наши данные (больше наблюдений/строк, чем функций/столбцов), тем легче нашей модели машинного обучения учиться на заданных функциях. Таким образом, мы должны балансировать между включением достаточно информативных функций и исключением неинформативных функций, которые увеличивают проклятие размерности, не добавляя предсказательной силы. Обширные данные — одна из ключевых проблем, с которыми мы будем иметь дело при создании автоматизированного оценщика покемонов. Существует так много данных о каждом покемоне (почти 20 типов, сотни способностей и почти 1000 ходов), что если мы не обобщим эту информацию в гораздо меньшем количестве признаков, то у нас будет больше признаков, чем покемонов для категоризации, что нанесет вред нашему мышлению. модели машинного обучения».
Для данных о типах покемонов у Пурто было хорошее решение, позволяющее сделать данные менее широкими: включить ТОЛЬКО сводную информацию о типе и удалить все запутанные столбцы с горячим кодированием для каждого типа, и достичь большей точности. Мы сделаем что-то очень похожее на Пурто с типами, но решение Пурто для способностей и ходов неубедительно и менее эффективно. Сначала они просто убрали способности, поняв, что они тоже не могут быть закодированы порядком, но потом решили дать способностям рейтинг от 0 до 4, исходя из того, насколько они сильны по мнению автора.
Затем они могли бы просто создать одну функцию (столбец), дающую каждому покемону один рейтинг способностей, основанный на их самой сильной способности. Это решает проблему широких данных, но довольно произвольным образом, и это показывает: увеличение точности менее чем на 1% (едва значительное) от включения способностей таким образом, несмотря на то, что способности являются таким критическим аспектом. того, что делает покемона сильным. Оценка способностей по-прежнему кажется очень разумной стратегией разработки признаков, поэтому мы будем использовать аналогичный подход. Тем не менее, учитывая количество существующих конкурентных данных о способностях, мы должны попытаться оценить их более основанным на данных способом, более соответствующим духу Смогона.
Проблема с их подходом к движениям в том, что они вообще не использовали ходы!
Как упоминалось ранее, пул движений покемонов имеет большое значение при определении конкурентной жизнеспособности покемонов. Если бы покемон знал только всплеск (который ничего не делает), например, у него могло бы быть 200 в каждой статистике, и это все равно будет отстой. К сожалению, наши текущие данные на самом деле не имеют пулов перемещений в наших данных, поэтому нам нужно получить данные где-то еще. У Smogon действительно есть данные о пулах движений каждого покемона, но, насколько я могу судить, это было видно только на странице, предназначенной для каждого покемона. Нам пришлось бы очищать каждую страницу отдельно, в результате чего было бы около 1000 запросов, что, вероятно, не лучшая идея. Также существует проблема, как на самом деле использовать movepool. Как мы видели на примере способностей, субъективная оценка пулов движений, скорее всего, не будет очень эффективной. Более того, пулы движений еще сложнее, чем способности! Мне не удалось придумать хороший способ включения пулов перемещений в наши данные, поэтому предоставлю это читателю в качестве упражнения (ха!).
Это «упражнение для читателя» мы решим в следующих нескольких статьях; Информация о перемещениях покемонов имеет решающее значение для понимания их конкурентной жизнеспособности, и любой подход, который пропускает информацию о перемещениях, будет крайне ограниченным. К счастью, соскребать информацию о перемещениях оказалось не так сложно, как представлял себе Поорто, хотя нужно было заметить некоторые вещи, которые можно легко пропустить (нам нужно посмотреть «Просмотр исходного кода» на странице Smogon «StrategyDex», но подробнее об этом см. это в следующей статье).
Есть еще один аспект этой задачи, который мы должны решить: как мы представляем себе и организуем уровни? Как я уже говорил во введении, мы собираемся использовать 7-уровневую систему (я думаю, что это хороший баланс между наличием большого количества классов и при этом их не слишком много). Поорто сначала использовал 15 классов: «LC», «LCBL», «NFE», «Untiered», «PU», «PUBL», «NU», «NUBL», «RU», «RUBL», «UU». , «UUBL», «OU», «Uber» и «AG». Как видите, у них не только огромное количество классов, но они даже рассматривают уровни «BL» (банлист/пограничный) как отдельные классы. Проблема в том, что обычно они довольно маленькие и не являются отдельными официальными уровнями. Учитывая, что уже существует ограниченное количество покемонов (максимум менее 900) и что размеры классов уже очень несбалансированы, построение модели, которая может правильно классифицировать большинство из 15 классов, может оказаться невозможным.
Действительно, их точность была ниже 50% с 15 классами, и многие из меньших классов почти не будут классифицированы правильно, потому что существует слишком мало примеров класса, чтобы модель могла узнать о нем что-либо существенное. Например, из их отчета об ошибках мы можем видеть, что огромное количество покемонов было ошибочно отнесено к категории «без уровней». Это связано с тем, что категория Untiered намного больше, чем большинство других, поэтому, если модель просто бездумно угадывает «Untiered» чаще, у нее будет гораздо больше шансов быть правильной без необходимости делать много различения. В этом проекте возникает еще большая проблема: использование точности в качестве показателя производительности алгоритма.
Точность — это простой и удобный показатель для измерения того, насколько хорошо работает алгоритм, но он работает довольно плохо, когда набор данных несбалансирован. В 15 классах, используемых Poortho, уровни, такие как LC и Untiered, являются массовыми и содержат сотни примеров, тогда как крошечные классы, такие как PUBL и UUBL, имеют менее 20 примеров. Даже более стандартные уровни, такие как NU и RU, довольно малы по сравнению с самыми большими классами. Таким образом, при построении модели для оптимизации точности модель может просто угадывать наиболее распространенные классы гораздо чаще, чем они встречаются на самом деле, и в большинстве случаев она все равно будет правильной, потому что эти классы содержат больше покемонов, чем другие классы. Просто используя очевидно бесполезную стратегию угадывания наиболее распространенных классов гораздо чаще, чем они встречаются на самом деле, классификатор может иметь точность, которая кажется респектабельной (даже если классификатор будет иметь очень небольшую практическую ценность из-за его бездумной стратегии). И, как я уже упоминал, Untiered и LC очень часто появляются в неправильных предположениях модели, так что модель, кажется, терпит неудачу именно в этом отношении. Это связанное видео дает краткое объяснение того, почему оценка F1 будет гораздо более надежной метрикой для использования в наших моделях, которую нельзя обмануть на основе бесполезных стратегий, поэтому оценка F1 — это то, что мы будем использовать в нашем проекте.
Проницательно заметив проблему с кардинальностью ярусов, Пурто понизил кардинальность ярусов до 3: «LC+NFE», «Untiered+PU+NU+RU», «UU+OU+Uber+AG». Таким образом, в основном у них есть только 3 класса: не полностью развитые покемоны, несколько слабые покемоны и очень сильные покемоны. Это привело к значительному повышению точности, но это неадекватное решение по нескольким причинам:
- Они также добавили столбец данных о том, полностью ли эволюционировал покемон или нет. Поскольку почти все покемоны, которые не полностью эволюционировали, находятся на уровнях LC или NFE, они будут классифицированы как «LC + NFE», и модели не нужно будет изучать что-либо существенное. Это дает искусственно завышенную точность без какого-либо понимания. Это также делает самый низкий класс практически бессмысленным, поэтому он в основном преобразуется в задачу 2 класса с дополненной точностью: задачу 2 класса, которая получает бесплатное преимущество в точности на основе класса LC + NFE, которому в основном говорят правильные ответы. столбец данных без того, чтобы модели приходилось делать практически какие-либо выводы из статистики, набора текста или способностей.
- Задача 2 класса намного проще за счет меньшей информативности. Если все, что мы знаем, это то, что покемон относительно слаб или относительно силен, то это не даст дизайнерам покемонов (формальным или неформальным) ничего конкретного для работы при разработке покемонов.
- Увеличение балла F1 (или средневзвешенного балла F1 по всем классам) имеет гораздо большее значение, чем повышение точности, поскольку точность часто вводит в заблуждение в несбалансированных классах.
Несмотря на все эти проблемы, я думаю, Поорто заметил еще одну весьма полезную цель этого проекта:
Одна из проблем с соревновательной игрой заключается в том, что метагейму требуется некоторое время, чтобы уладиться. То есть, когда появляются новые покемоны, метагейму требуется некоторое время, чтобы адаптироваться к присутствию нового покемона. Например, Game Freak только что выпустила дополнительный контент для Pokémon Sword and Shield под названием «Остров доспехов», который представил в игре много новых покемонов, в результате чего соревновательная сцена стала довольно нестабильной. Подобный инструмент помог бы ускорить этот период адаптации. Используя этот инструмент, можно было бы относительно легко определить относительную силу нового покемона, что привело бы к более стабильной соревновательной сцене и более здоровой мета-игре в целом.
У академических исследователей Девина Наваса и Дилана Донохью из Фордхэмского университета был еще один подход. Это самый простой из всех подходов, но он демонстрирует несколько важных моментов и имеет очень странные и небрежные аспекты, поэтому я быстро расскажу о нем.
Они использовали только 4 функции: индивидуальные характеристики (технически это 6 функций, но это всего лишь одна концепция), общая базовая статистика (все 6 характеристик суммируются), количество слабостей типов и количество сопротивлений типам. Хотя мне нравится простота этого подхода, мы можем быстро увидеть его ограничения: он постоянно неправильно классифицирует покемонов, таких как Дитто, Дарманитан-Галар и Мимикью, намного ниже, чем они должны быть, поскольку они не очень хороши в четырех используемых функциях. Вместо этого именно их способности и приемы делают их настолько хорошими, насколько они есть. Это очень конкретно показывает, почему нам НЕОБХОДИМО умение и перемещать информацию, чтобы ее можно было обобщить и представить в модели.
Тем не менее, статистика и информация о типе все еще могут многое нам сказать: модель Фордхэма, как правило, была гораздо более точной, когда речь идет о более низких уровнях, таких как PU, и самых высоких уровнях, таких как Uber, поскольку они гораздо более различны, как правило, почти всегда соответствуют друг другу. с чрезвычайно высокими или чрезвычайно низкими характеристиками (но не всегда!). Мы также увидим более высокие оценки в более экстремальных классах (т. е. Uber на верхнем уровне и ZU на нижнем уровне) для нашей модели. Однако исследователи из Фордхэма совершили ту же ошибку, что и Поорто, использовав точность как способ оценки модели, потому что точность ненадежна для задач, связанных с сильно несбалансированными классами. Они также использовали точность, но оценка F более идеальна, потому что она уравновешивает крайности припоминания и точности, что значительно усложняет ее использование.
Эта несбалансированная проблема класса еще более усугубляется включением в них ненужных уровней: Ubers, Overused (OU), Underused Borderline (UUBL), Underused (UU), Rarely Used Borderline (RUBL), Rarely Use (RU), Never Used Borderline (NUBL). ), Никогда не используется (NU) и Частично используется (PU). Это 9, что не является неразумным числом, но оно по-прежнему включает те уровни «BL», у которых так мало примеров, что они не могут быть реально последовательно изучены моделью (и сами по себе они не являются значимыми метаиграми). Точность для этих классов, как правило, была довольно низкой, что вполне понятно, за исключением одного алгоритма с несколькими подозрительными результатами, которые мы вскоре обсудим.
Для этой задачи они использовали всего 297 покемонов. Даже 700+ (как мы с Поорто использовали) — это небольшой набор данных, поэтому я не уверен, почему они уменьшили размер набора данных Pokémon до 297. Кроме того, нет никакой прозрачности относительно того, какой набор данных они использовали, поэтому повторение чего-то очень подобный их эксперимент был бы невозможен.
Они пробовали стратегии с 10-кратной перекрестной проверкой и наборами тестов соответственно. Стратегии тестовых наборов, похоже, имеют более высокую точность по всем направлениям, что имеет смысл, поскольку 10-кратная перекрестная проверка в этом случае не сработает. С менее чем 300 покемонами и крайне несбалансированными классами многие фолды будут иметь исчезающе мало примеров для некоторых классов. Перекрестная проверка была бы почти бесполезна для этих классов, и гораздо худшие результаты, полученные при 10-кратной перекрестной проверке, подтверждают это утверждение. Если мы используем перекрестную проверку, мы должны использовать гораздо меньше «сгибов», чем это, чтобы мы получили достаточно большие репрезентативные выборки из каждого класса, чтобы иметь реальную согласованность между различными сгибами.
Также трудно понять, почему они использовали перекрестную проверку только для одних подходов и только набор тестов для других. Эти стратегии можно легко использовать вместе: перекрестная проверка обычно используется во время обучения модели, а тестовый набор строго не используется во время обучения, а скорее используется для проверки производительности с данными, которые никогда ранее не использовались моделью. Тот факт, что они даже не использовали набор тестов для своих примеров перекрестной проверки, означает, что мы понятия не имеем, как эти модели будут обобщаться на невидимые данные, и меня также беспокоит то, что они неправильно использовали набор тестов в примерах, где они был один.
Используя алгоритм ближайшего соседа (Lazy IBk) и набор тестов, исследователи сообщают о 100% точности! Если верить этому, то задача должна быть закончена, так как она была более или менее совершенно решена. Не было бы причин тратить наше время на дальнейшую работу над этим. Однако даже сами исследователи в это не верят:
Прогоны с использованием тестового набора без недостаточной выборки имели самую высокую точность для J48 и Lazy IBk, хотя мы полагаем, что это могло быть результатом переобучения, о чем свидетельствует прогон Lazy IBk для этого набора с точностью 100,0%…
Ленивый IBk имел точность 100,0% для этого прогона, что, как мы предположили, было результатом переобучения обучающей выборки, поэтому мы решили считать этот результат ошибочным (таблица I).
Причина, по которой мы используем тестовый набор в машинном обучении, заключается в том, чтобы увидеть, как наша модель работает с данными, на которых модель не обучалась и никогда не видела. Если мы только видим, насколько хорошо модель справляется с классификацией данных, которые она уже видела, то мы понятия не имеем, как она будет работать с невидимыми данными. Очень легко получить модель с очень высокой производительностью при обучении, только для того, чтобы она переобучилась и работала очень плохо на тестовых данных, что делает ее бесполезной. Таким образом, то, как модель работает при обучении, не может считаться хорошим показателем того, как модель работает в целом, и исследователи машинного обучения обычно относятся к этому очень серьезно.
Хотя я понимаю, что исследователи из Fordham признают что-то странное в их 100% точности, их заявления не имеют смысла с точки зрения того, как наборы тестов обычно используются в практике машинного обучения. Например, они либо дают нам точность на тестовом наборе, либо на обучающем наборе. Если они дают точность на тестовом наборе, то переобучение на тренировочном наборе не должно иметь значения. Даже если модель подходит к тренировочному набору, она еще не видела тестовый набор, поэтому точность тестового набора все равно должна быть действительным показателем ее производительности (а не ошибкой). Если они дают точность обучения, то производительность 100% имеет больше смысла (легко подогнать модель под шум, чтобы она правильно классифицировала все обучающие примеры), но она ничего не говорит нам о реальной производительности модели.
Поскольку они признают, что эта 100-процентная точность является ошибочной и происходит от переобучения, то, похоже, они допустили ошибку, записав точность модели на данных обучения, а не ее точность на данных тестирования (в качестве альтернативы им пришлось бы обучать модель). модель на данных тестирования для переоснащения, чтобы повлиять на результат, что также является неправильной практикой). Это, к сожалению, делает все их точности ненадежными в отношении реальной производительности модели и, следовательно, не очень информативными. Поскольку они также используют кураторский непрозрачный набор данных из менее чем 300 покемонов (также без прозрачного кода в репозитории GitHub) для задачи, которую нельзя повторить экспериментально, их результаты, как правило, не заслуживают доверия.
Я также получил такие 100% (или очень близкие к 100%) точности данных обучения с моделями, которые я пробовал (KNN и Random Forest), но я считал эти точности обучения ненадежными и не сообщал о них как о репрезентативных. истинная производительность моей модели на невидимых данных. Для логистической регрессии моя модель не показала особенно хороших результатов даже во время обучения, как это произошло в статье Фордхэма (показано в разделе «Сводка результатов и результаты производительности моей связанной записной книжки Jupyter)». Все эти сходства также предполагают, что исследователи из Фордхэма использовали точность обучения, а не точность тестирования.
В конечном счете, мы можем узнать, насколько хорошо работает наша модель, только проверив ее производительность на тестовом наборе, на котором модель никогда не обучалась (так что никакое переоснащение не может скрыть окончательную производительность). Тем не менее, я думаю, что подход Фордхэма продемонстрировал некоторые важные принципы, которые помогут нам двигаться вперед, и было важно понять результаты в контексте.
Настройтесь на более короткую статью о том, как я собирал данные для этого проекта! Мы также обсудим самые сложные моменты его очистки, чтобы все это можно было более или менее легко воспроизвести. Желаю хорошей недели!
