Недавно я принимал участие в Сеченовском хакатоне в качестве эксперта, сидел на предзащите у команд и давал свои комментарии, делал замечания и пытался направить их идеи в нужном направлении.
Я встречал множество схожих фраз, которые натолкнули меня на написание этого поста, вот некоторые их них:
"У модели точность 88, хотим, чтобы было 95, сейчас доучиваем".
"У конкурентов точность 90, наше конкурентная преимущество, что у нас 92".
Оценка качества модели - это тот случай, когда ты можешь сделать 100 измерений и все еще не быть уверенным в том, как твоя модель работает. В этом посте попробую отметить те моменты, о которых стоит подумать, прежде чем называть какие-либо цифры.
1. Бизнес цели. Любая задача начинается с постановки цели. Если мы говорим про бизнес, то ваша модель должна решать определенные задачи, создавая тем самым денежный поток. Нужно очертить границы того качества, которое будет являться необходимым для получения профита от участия машинного обучения и при этом также важно понимать границы, когда уже можно остановиться поднимать качество, ведь каждый новый процент обычно стоит все дороже.
Пример:
Когда я работал в СБЕРе моя модель таргетирования рекламных рассылок имела ROC-AUC около 0.6 (чуть лучше подброса монетки), что в итоге приносило компании несколько десятков миллионов в месяц. ROC-AUC 0.6 является ужасной метрикой, но в этой задаче даже такие показатели были выше необхоимого и давали профит бизнесу.
2. Тестирование. Не хочется говорить о train, val, test, потому что это достаточно примитивная схема. Поговорим в целом о тестировании, какие вопросы стоит держать в голове.
Переносимость. Модель может работать по-разному на разных доменах, поэтому стоит изучать std на бутстрапе, стоит иметь несколько тестовых датасетов, собранных из разных источников и иметь хотя бы один такой источник, который не присутствовал в обучающей выборке.
Сложность и уверенность. Тестовый датасет нужно собирать вручную, добавляя туда сложные случаи, которые могут вызывать затруднения у модели. Также много времени необходимо посвятить тому, чтобы удостовериться в качестве разметки этого датасета. И безусловно убедиться в отсутвии утечек в обучающий сет.
Распределение классов. Момент, вызывающий споры, я себе на него отвечаю так. Чтобы понять работает ли твоя модель в вакууме - делим тест 50 на 50, чтобы понять как она будет вести себя в продакшене - делим в соответствии с распределением на реальных данных. Опять же, для ответа на оба вопроса даже на одном датасете можно позаниматься бутстрапированием.
Метатестирование. Если задача подразумевает то, что ответ модели - это не сам продукт, а только его составляющая, которая будет далее преобразована какой-то бизнес логикой во что-то человекочитаемое - стоит проверить качество работы именно финального результата. Качество обнаружения признаков рака молочной железы, не всегда напрямую говорит верно ли будет итогово выставлен BI-RADS, например. Более того, такой подход будет лучше интерпретироваться, чем просто некая точность в вакууме.
3. Выбор метрики. Для каждой бизнес задачи требуется грамотно выбирать свои метрики. Не буду здесь писать о несбалансированных классах и прочих знаниях junior специалистов, просто в очередной раз напоминаю, что стоит потратить определенное время, чтобы, в идеале, иметь еще и интерпертируемую метрику. Недавно, кстати, нашел очевидную метрику, но до этого я ей не пользовался p4.
4. Сравнение. Тут все просто. Сравнение называется честным только в том случае, если все параметры эксперимента одинаковы. Скорость - на одинаковом железе и схожем качестве работы моделей, при сравнении качества - идентичные данные. Это верно как при сравнения со своими предыдущими наработками, так и при сравнении со сторонними разработчиками.
Мои посты получаются большими, и мне кажется, что это может отталкивать читателей. Что вы думаете про размер постов, стоит ли попробовать как-то поменять формат? Пишите комментарии и конечно же жду ваших реакций и репостов!
#технологии #эйай
@lechim_ai