Было у вас когда‑нибудь такое: вы обучали модель, которую считали хорошей, а потом, на реальных данных, эта модель с треском проваливалась? Если так — это значит, что вы совсем не одиноки. Машинное обучение наполнено сложными процессами, управляя которыми очень легко сделать что‑то такое, совсем неочевидное, что приведёт к переобучению модели. Я работаю в сфере машинного обучения около 20 лет. Я видел много примеров вышеописанной ситуации, что подтолкнуло меня к написанию материала «Как избежать „подводных камней“ машинного обучения: руководство для академических исследователей». Этот материал был попыткой уберечь других людей от известных мне проблем машинного обучения.

Вы, правда, не должны верить мне на слово. О подобных проблемах всё чаще сообщают и в научных, и в популярных изданиях. Среди примеров таких публикаций — наблюдение касательно того, что сотни моделей, разработанных в ковидные времена, просто не работают. Ещё один пример — материал о системе контроля качества воды, запущенной в Торонто, которая регулярно сообщала населению о том, что от купания в опасной воде вреда не будета. Много подобных случаев задокументировано в репозитории AIAAIC. Было даже высказано предположение, что подобные оплошности, связанные с машинным обучением, приводят к кризису воспроизводимости в науке. И учитывая то, что в наши дни машинное обучение — это, для многих учёных, один из важнейших инструментов, такая ситуация вызывает ещё и отсутствие доверия к опубликованным результатам научных экспериментов.

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

Обманутые данными

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

В самых худших случаях некачественные данные становятся причиной феномена, известного как «мусор на входе, мусор на выходе» (garbage in garbage out). Это — когда модель успешно обучают и даже могут получить очень хорошие результаты на тестовом наборе данных, а к реальным данным такая модель неприменима. Примеры этого явления можно найти в вышеупомянутом обзоре моделей для диагностики COVID-19. Спешка в разработке инструментов для диагностики заболевания привела к появлению множества общедоступных наборов данных. А позже было обнаружено, что эти данные содержат сигналы, вводящие модели в заблуждение. Это — перекрывающиеся записи, неправильно размеченные и скрытые переменные. Всё это помогло моделям точно разделять входные данные по классам, назначать им метки классов, ничего полезного при этом не изучая.

Возьмём, например, скрытые переменные. Это — признаки, присутствующие в данных, которые позволяют прогнозировать классы, к которым относятся наборы входных данных. Но при этом такие признаки напрямую с соответствующими классами не связаны. Если модель «схватывает» эти переменные в процессе обучения, то будет казаться, что работает она хорошо, но на реальных данных ничего полезного от неё добиться будет нельзя. Например, во многих ковидных наборах данных со снимками грудной клетки пациентов ориентация тела относится к скрытым переменным. Обычно, когда снимки делают больным людям, эти люди находятся в лежачем положении. А люди, пребывающие на момент создания снимка в вертикальном положении, обычно здоровы. В результате модели, изучившие эту скрытую переменную, оказались хороши в выявлении того, в каком положении находится человек, когда ему делают снимок. А вот ковид они диагностируют плохо. Несмотря на то, что эти переменные называются «скрытыми», часто их, в буквальном смысле, видно невооружённым глазом. Было много примеров того, что классификаторы учились распознавать всяческие ограничительные линии, водяные знаки, временные метки, присутствующие на изображениях. Это помогало моделям различать классы предлагаемых им входных данных, не имя при этом необходимости хотя бы взглянуть на сами эти данные.

Похожая проблема — это наличие в данных ложных корреляций. В отличие от скрытых переменных у них нет реальных взаимоотношений с чем‑либо в данных. Это — просто некие паттерны, которые почему‑то коррелируют с метками классов. Классический пример — это «проблема танка». Американские военные, по слухам, пытались обучить нейросеть распознавать танки. Но система распознавала не танки, а погодные условия, так как все снимки танков были сделаны в одно и то же время дня. Взгляните на следующие изображения: модель машинного обучения может распознать все картинки с танками в этом наборе данных, просто взглянув на цвет пикселей, находящихся ближе к верхнему краю изображений, не задумываясь о форме каких бы то ни было объектов. Модель способна показать очень хорошие результаты в процессе обучения и тестирования, а вот на практике она может оказаться совершенно бесполезной.

Многие наборы данных (возможно — большая их часть) содержат ложные корреляции, но они обычно не так очевидны, как эта. Например, о повсеместно используемых бенчмарках для систем компьютерного зрения известно то, что в применяемых в них изображениях имеются группы фоновых пикселей, ложно коррелирующих с метками классов. Это — особая проблема для специалистов по глубокому обучению, работающих с моделями, ёмкость которых позволяет моделировать множество паттернов, присутствующих в данных. Различные исследования показали, что модели глубокого обучения склонны захватывать паттерны ложной корреляции, что делает их менее универсальными. Одно из следствий этого факта — чувствительность таких моделей к атакам, при выполнении которых на вход моделей подают особым образом подготовленные входные данные с целью принуждения моделей к выдаче неправильных предсказаний (Adversarial Attacks). Если модель глубокого обучения основывает свои предсказания на ложных корреляциях, проявляющихся в виде фоновых пикселей изображений, это значит, что выполнение небольших изменений этих пикселей может очень сильно изменить предсказание модели. Для решения этой проблемы модели, при её обучении, можно демонстрировать данные, изменённых подобным образом (Adversarial Training), но это — дорогое удовольствие. Легче будет просто проанализировать модель и выяснить то, какую именно информацию она использует при принятии решений. Например, если карта значимости, созданная с помощью ИИ‑системы, работа которой поддаётся объяснению, указывает на то, что модель обращает особое внимание на что‑либо, находящееся на фоне изображений, тогда такая система, возможно, не будет отличаться хорошей обобщающей способностью.

Иногда проблема заключается не в самих данных, а в их разметке. Особенно сильно это проявляется в тех случаях, когда данные размечают люди. Метки, в итоге, отражают предубеждения, ошибочные предположения или — просто старые добрые ошибки, которые делают люди, размечающие данные. Примеры этой проблемы можно встретить в наборах данных, используемых в качестве бенчмарков для систем классификации изображений, в таких, как MNIST и CIFAR. Обычно в них уровень неправильно размеченных изображений составляет около пары процентов. Это не такой уж и огромный показатель, но показатель это очень даже значимый в тех случаях, когда создатели систем машинного зрения борются за улучшение точности моделей, измеряемое десятыми долями процента. Поэтому, если чья‑то модель показывает результаты, немного превышающие результаты конкурентов — возникает вопрос о том, из‑за чего это так — из‑за реального улучшения, или из‑за «шума моделирования» при разметке данных? Всё может быть ещё хуже при работе с данными, для которых характерна неявная субъективность, например — в задачах классификации тональности высказываний, где есть риск переобучения модели под воздействием конкретных людей, занимающихся разметкой данных.

Ведомые утечками данных

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

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

Рассмотрим простейший пример: центрирование и масштабирование данных. При выполнении этих операций смотрят на диапазон значений каждого признака, а потом используют эту информацию для нормализации данных. Обычно это делается так, чтобы среднее значение равнялось бы 0, а стандартное отклонение — 1. Если это сделать на всём наборе данных перед выделением из него тестовой выборки, тогда при масштабировании обучающих данных будут использоваться сведения о диапазоне значений и распределении значений признаков в тестовой выборке. Это особенно проблематично в том случае, если диапазон тестового набора данных больше, чем диапазон обучающего набора, так как модель вполне может вывести этот факт из усечённого диапазона, представленного в обучающих данных. В результате модель может показать хорошие результаты на тестовом наборе, просто прогнозируя значения, которые больше или меньше тех, которые она видела в процессе обучения. Например, некто работает над задачей прогнозирования цены акций на основе данных в виде временной последовательности. Для решения этой задачи используется модель, принимающая входные данные в диапазоне от 0 до 1. Но в процессе обучения этой модели достаются лишь данные из диапазона от 0 до 0,5. В результате окажется, что такой модели будет не особенно сложно сделать вывод о том, что в будущем цены на акции вырастут.

На самом деле, прогнозирование — это такая область машинного обучения, которая особенно сильно предрасположена к утечкам данных. Причина этого кроется в явлении, которое называют ошибкой опережения (look ahead bias). Это происходит в том случае, если информация, к которой у модели не должно быть доступа, попадает в неё из данных, относящихся к будущим периодам, и искусственно улучшает результаты её работы на тестовом наборе данных. Это обычно случается тогда, когда обучающий набор данных содержит образцы, которые взяты из временных промежутков, сильно опережающих те временные промежутки, из которых взяты данные тестового набора. Позже я расскажу о том, когда это происходит, но если вы работаете в этой сфере — я настоятельно рекомендую взглянуть на этот отличный обзор «подводных камней» и рекомендованных методов проверки прогнозных моделей, работающих с временными последовательностями.

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

Удивительно то, что один из самых распространённых механизмов утечки данных даже не имеет общепризнанного названия (среди предложенных названий — overhyping и sequential overfitting). Это, по сути, подход к обучению модели, ориентированный на её подгонку к выдаче хороших результатов на тестовых данных. Представьте себе реализацию сценария работы, показанного на предыдущем рисунке. Модель обучают и проверяют на тестовом наборе данных. Оказывается, что эффективность работы модели ниже желаемой. Модель подвергают дополнительным улучшениям и снова оценивают её эффективность. Если результат снова оказывается неудовлетворительным — всё повторяется до тех пор, пока не получится то, что нужно. Звучит знакомо? Это, конечно, распространённая практика. Но если при разработке модели используют итеративный подход, и после каждой итерации применяют для оценки модели один и тот же набор тестовых данных, это значит, что, по сути, тестовые данные играют роль ориентира при разработке модели. В итоге получается, что модель переобучают под тестовые данные и, вероятно, получают чрезмерно оптимистичные показатели, характеризующие обобщающую способность модели.

Интересно, что именно это происходит тогда, когда исследователи используют распространённые бенчмарки, вроде MNIST, CIFAR и ImageNet. Почти все, работающие над классификацией изображений, применяют эти наборы данных для оценки применяемых ими подходов к классификации. Поэтому неизбежно то, что со временем, в той или иной степени, модели переобучаются под эти бенчмарки. Для того чтобы смягчить эту проблему, всегда полезно использовать различные бенчмарки, а в идеале — пробовать свои модели на наборах данных, которыми никто до этого не пользовался.

Дезинформированные метриками качества моделей

После того, как исследователю удалось создать надёжную модель, её необходимо проверить с помощью надёжных инструментов. На этом этапе работы над моделями очень многое тоже может пойти неправильно. Начнём с неадекватного подбора метрик для оценки качества моделей. Классический пример — оценка точности модели с помощью несбалансированного набора данных. Представьте, что вам удалось обучить модель, которая всегда, независимо от входных данных, выдаёт прогноз, указывающий на одну и ту же метку. Если эта метка соответствует правильному ответу для половины тестовых образцов, это значит, что точность модели равняется 50%. В данном случае это нормально — плохая точность для плохого классификатора. Если эта метка будет соответствовать 90% тестовых образцов — тогда оценка точности модели достигнет 90% — хорошая точность для плохого классификатора. Подобный уровень несбалансированности нельзя назвать малораспространённым в реальных наборах данных, он встречается при работе с несбалансированными наборами данных. Не являются редкостью случаи, когда создают классификаторы, всегда выдающие прогнозы, соответствующие метке, которая встречается в наборе данных чаще всего. В данном случае гораздо лучше будет использовать метрики наподобие F‑score или коэффициента корреляции Мэтьюса (Matthews correlation coefficient, MCC), так как они менее чувствительны к несбалансированности классов. Но свои слабости есть у всех метрик, поэтому лучше будет всегда пользоваться неким «портфолио» метрик, которые позволяют с разных сторон оценить качество модели и разными способами выявить причины её возможных отказов.

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

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

Ещё одна проблема заключается в предположении о том, что расчёта одного показателя достаточно для измерения эффективности работы модели. Иногда так оно и есть, но чаще всего ИИ‑специалистам приходится работать с моделями, отличающимися стохастическим или нестабильным поведением. Поэтому после каждого сеанса обучения они показывают разные результаты. Или, возможно, при создании модели использовался маленький набор данных, и исследователю просто повезло, когда он взял из него данные для тестирования модели. Для решения обеих этих проблем часто пользуются методами ресемплинга, наподобие метода кросс‑валидации, когда модель обучают и тестируют на разных подмножествах данных, а затем выводят средний показатель эффективности её работы. Правда, применение ресемплинга сопряжено с собственными проблемами. Одна из них заключается в увеличении риска утечки данных. В особенности — при применении операций препроцессинга данных, зависящего от самих этих данных (среди них — центрирование и масштабирование данных, а так же — выбор признаков), когда считается, что такие операции нужно применять лишь однократно, не считаясь с количеством итераций. Но это не так. Подобные операции нужно выполнять на каждой итерации ресемплинга, иначе они могут стать причиной утечки данных. Ниже приведён пример этой проблемы. Здесь показано то, что выбор признаков должен выполняться независимо для двух учебных наборов (выделены синим), используемых на первых двух итерациях кросс‑валидации. Здесь показано и то, что это приводит к тому, что каждый раз выбираются разные признаки.

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

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

Идём глубже

До сих пор я, в основном, говорил об универсальных процессах машинного обучения, но при использовании моделей глубокого обучения можно столкнуться с ещё более серьёзными проблемами. Рассмотрим работу с моделями латентного пространства. Эти модели часто обучают отдельно от предсказательных моделей, которые их используют. Получается, что нет ничего необычного в том, чтобы обучать нечто вроде автоэнкодера, выполняющего извлечение признаков, а затем использовать выход этой модели при обучении следующей модели. Занимаясь подобными вещами очень важно обеспечить, чтобы тестовые данные, используемые в следующей модели, не пересекались бы с обучающими данными, используемыми в автоэнкодере. Это легко может произойти при использовании кросс‑валидации или других методов ресемплинга. Например — при применении различных наборов данных, выбираемых случайным образом, или при отказе от выбора моделей, обученных на одних и тех же блоках учебных данных.

Но по мере того, как модели глубокого обучения становятся всё больше и всё сложнее, усложняется и задача предотвращения подобных утечек данных. Например, если пользуются заранее обученной базовой моделью, может быть невозможно понять — применялись ли данные из тестового набора при обучении этой базовой модели. Это особенно актуально для тех случаев, когда для тестирования своей модели пользуются данными бенчмарков из интернета. Ситуация ещё сильнее ухудшается при использовании композитных моделей. Например, базовую модель типа BERT применяют для кодирования входных данных при тонкой настройке базовой модели типа GPT. В такой ситуации нужно учитывать возможные пересечения наборов данных, используемых при обучении этих двух базовых моделей. И это — в дополнение к возможным пересечениям с собственными данными, используемыми для тонкой настройки модели. На практике некоторые из вышеописанных наборов данных могут быть неизвестны ИИ‑специалисту. А это означает, что у него может не быть уверенности в том, что именно демонстрирует его модель — корректное обобщение данных, или простое воспроизводство того, что она запомнила в процессе предварительного обучения.

Предотвращение проблем

Все вышеописанные проблемы машинного обучения распространены чрезвычайно широко. Как же их избегать? Один из подходов к борьбе с ними заключается в использовании чек‑листа, контрольного списка. Это — формальный документ, который позволяет специалисту без проблем пройти через сложные участки конвейера машинного обучения и помогает ему выявить потенциальные проблемы своего проекта. В сферах, где системы машинного обучения участвуют в принятии очень важных решений, вроде медицины, уже имеется множество хорошо проработанных чек‑листов, таких как CLAIM. Идею о том, что тем, кто работает в этих сферах, нужно пользоваться подобными чек‑листами, обычно продвигают в профильных журналах.

Но тут мне хотелось бы поговорить о новом контрольном списке — о REFORMS. Это чек‑лист для научных исследований, основанных на машинном обучении. Он составлен 19 исследователями из сфер информатики, науки о данных, математики, социальных наук, из сферы медико‑биологических исследований, пришедших к консенсусу. В число этих исследований вхожу и я. Этот чеклист вышел после недавнего совещания, посвящённого кризису воспроизводимости в научных исследованиях, основанных на машинном обучении. Цель REFORMS — исправление распространённых ошибок, возникающих в конвейерах машинного обучения. В их число входят и ошибки, упомянутые в этой статье. Чек‑лист при этом не зависит от какой‑то определённой предметной области. Он состоит из двух частей: из самого чек‑листа и из поясняющего документа, в котором идёт речь о роли и важности каждого из элементов чек‑листа. Чек‑лист направлен на основные компоненты исследований, основанных на машинном обучении. Он ориентирует тех, кто его использует, на проверку того, чтобы их процессы машинного обучения были бы должным образом спроектированы. А именно — чтобы эти процессы поддерживали бы общую цель исследований, чтобы в них отсутствовали бы распространённые ошибки, и чтобы их результаты могли бы быть проверены независимыми исследователями. Хотя этот чек‑лист направлен на применение машинного обучения в научной среде, многое из того, что в нём есть, применимо и в более широком контексте. Поэтому я рекомендую вам взглянуть на REFORMS даже в том случае, если вы не считаете то, чем занимаетесь, «наукой».

Ещё один подход к уходу от проблем заключается в том, чтобы лучше использовать имеющиеся инструменты. Меня, относительно современного состояния машинного обучения, постоянно беспокоит одна вещь: распространённые инструменты почти ничего не делают для того, чтобы уберечь от ошибок того, кто их использует. То есть — они охотно позволят ИИ‑специалисту разными способами нарушить процесс машинного обучения, не сообщив ему о том, что он что‑то делает не так. Но, тем не менее, они способны помочь в выявлении проблем. В частности — существуют фреймворки для наблюдения за экспериментами, которые автоматически создают записи о характеристиках обучаемых моделей и о том, как именно их обучают. Эти инструменты могут оказаться полезными для выявления чего‑то вроде утечек данных и проблем в виде обучения моделей на тестовых наборах данных. Существует опенсорсный проект такого рода — MLFlow, но имеется и множество коммерческих вариантов. А инструменты MLOps продвигают эту идею ещё дальше и помогают управлять всеми частями рабочего процесса машинного обучения, включая людей.

Итоги

Можно обучить качественную модель, обладающую хорошей обобщающей способностью при работе с новыми для неё данными. Но я не поверил бы в то, что некая модель является именно такой, до тех пор, пока не проверил бы, что с ней не случилось ничего из того, что могло бы пойти не так. Здоровая подозрительность — это хорошо. Стоит проверять обученную модель на предмет того, занимается ли она чем‑то вразумительным. Стоит анализировать применяемые метрики качества модели для того чтобы понять, совершает ли модель ошибки. Стоит калибровать результаты по адекватным базовым показателям, и стоит учитывать возможность использовании чек‑листов, позволяющих убедиться в том, что во время работы над моделью не было упущено из виду что‑то важное.