Сравнение функций потерь и метрик оценки
В последних нескольких единицах мы начали видеть разрыв в функциях затрат, которые учат модель и метрики оценки, что является тем, как мы оцениваем модель самостоятельно.
Все функции потерь могут быть метриками оценки
Все функции потерь могут быть метриками оценки, хотя и не обязательно интуитивно-понятными метриками. Например, потеря журнала: значения не интуитивно понятны.
Некоторые метрики оценки не могут быть функциями затрат
- Для некоторых метрик оценки сложно стать функциями затрат
- Это связано с практическими и математическими ограничениями
- Иногда вещи не легко вычислять (например, "как мухие что-то есть")
- Функции потерь идеально сглаженные. Например, точность полезна, но если мы немного изменим нашу модель, она не заметит его. Учитывая, что установка является процедурой с большим количеством небольших изменений, это дает впечатление, что изменения не будут привести к улучшению.
- Диаграмма функций потерь с большим объемом неструктурированных данных
- Обновите предыдущие данные в кривых ROC. Для этого необходимо изменить пороговое значение на значение какого угодно типа, но в конечном счете модель будет иметь только одно значение (0,5).
Все не так уж плохо!
Тот факт, что мы не можем использовать любимые метрики в качестве функции потерь, может быть довольно неприятным открытием. Однако есть вверх, однако, что связано с тем, что все метрики являются упрощением того, что мы хотим достичь; нет идеальных. Это означает, что сложные модели часто "обманывают": они находят способ получить низкие затраты, не на самом деле найти общее правило, которое решает нашу проблему. Наличие метрики, которая не действует в качестве функции затрат, дает нам "санность проверка", что модель не нашла способа обмануть. Если мы понимаем, что модель хитрит, мы можем изменить стратегию обучения.
Мы видели это "обман" несколько раз сейчас. Например, если модели сильно перенаправляют обучающие данные, они по сути "запоминают" правильные ответы, а не находят общее правило, которое мы можем успешно применить к другим данным. Мы используем тестовые наборы данных в качестве "проверка sanity" для оценки проверка, что модель не просто сделала это. Мы также видели, что с несбалансированных данных модели иногда могут просто научиться всегда давать тот же ответ (например, false), не глядя на функции, так как в среднем это правильно и дает небольшую ошибку.
Сложные модели также находят и другие обходные пути. Иногда сложные модели могут создавать ложные взаимосвязи и для функции потерь. Например, представьте, что мы пытаемся построить модель, которая может рисовать собак. У нас есть функция потерь, которая проверяет, что изображение имеет коричневый цвет, на нем отображается текстура меха, и оно содержит объект правильного размера. Используя эту функцию потерь, сложная модель может научиться создавать коричневый меховой шарик — не потому что он похож на собаку, но потому что он дает минимум потерь и его легко создать. Если у нас есть внешняя метрика, которая подсчитывает количество ног и голов (которые нельзя легко использовать в качестве функции затрат, потому что это не гладкие метрики), мы заметим быстро, если наша модель обманывает, и переосмыслим, как мы обучаем ее. И наоборот, если альтернативные показатели эффективны для оценки, мы можем быть до определенной степени уверены в том, что модель отражает внешний вид реальной собаки, а не просто стремится обхитрить функцию потерь, чтобы получить низкое значение.