Системы рекомендаций, беспилотные автомобили и распознавание голоса — все это требует значительной степени нечеткости. По моему опыту, Product и QA обычно обращаются к своему эксперту по машинному обучению, чтобы сказать, хороша ли модель. Это такая же хорошая идея, как попросить инженера подписать собственный код. Неизбежно, продукт вернется к эксперту по машинному обучению с некоторой вариацией: «Я использовал вашу модель и получил такой результат… почему?» Ничто, по словам эксперта по машинному обучению, не будет удовлетворительным.
Итак, давайте поговорим о том, как мы должны думать о контроле качества моделей, и ответим на вопрос: «Как мне узнать, достаточно ли хороша эта модель для продукта?»
Это важный вопрос, тем более, что машинное обучение берет на себя все больше и больше продукта. Риск ошибиться как никогда высок. Обычный процесс контроля качества, включая автоматизированное тестирование, плохо работает с моделями. Это связано с тем, что нормальный контроль качества основан на проверке характеристик продукта. Если вы попросите типичного руководителя отдела контроля качества написать план тестирования Not Hotdog, вы получите кучу тестов, которые, по сути, сводятся к тому, чтобы указать приложению на вещи и посмотреть, правильно ли оно все делает. Естественно, это мало что скажет вам о том, насколько хороша ваша модель и поможет ли она вашим клиентам. Неправильно понять, как вы заставляете Amazon Alexa просыпаться, когда этого не должно быть.
Типы ошибок
К счастью, в области машинного обучения есть ряд метрик, используемых для оценки моделей, но они не очень часто используются в обычном тестировании и работе с продуктом. Давайте рассмотрим их и то, насколько они важны в разных контекстах.
Ошибка типа I (ложные срабатывания)
Каждый, кто случайно разбудил своего голосового помощника, сталкивался с ошибкой первого рода. Он отреагировал на то, на что не должен был реагировать. Иногда это обсуждается с точки зрения точности, которая в случае не хот-дога представляет собой процент случаев, когда, если приложение находит хот-дог, оно действительно находит хот-дог.
Это основная метрика, которую следует свести к минимуму, когда ложная активация сопряжена с большим риском, чем ложная неактивация.
Ошибка типа II (ложноотрицательные результаты)
Несмотря на то, как сообщается, неспособность Uber должным образом отреагировать на велосипедиста на дороге является примером ложноотрицательного результата или ошибки типа II. Он не отреагировал на то, на что должен был отреагировать. Тот факт, что он неправильно обозначен в статьях, просто показывает, как далеко нам еще предстоит зайти. Подобно точности, это иногда обозначается как отзыв. В случае Не хот-дог отзыв — это процент случаев, когда приложение находит хот-дог всякий раз, когда ему показывают хот-дог.
Это важно в тех случаях, когда неспособность реагировать сопряжена с большим риском, чем бездействие. Риск того, что беспилотный автомобиль не отреагирует на объект на своем пути, намного выше, чем риск не реагировать ни на что. Мы бы предпочли читать душераздирающие статьи о беспилотном автомобиле, который остановился посреди дороги, потому что машина остановилась из-за белки.
Погрешность
Иногда вас не интересует, является ли что-то хот-догом или нет. Иногда вы оцениваете число, например время в пути или отток клиентов. В этих случаях важно понимать предел погрешности, который является мерой того, насколько далека от истинного значения модель, вероятно, предскажет. Иногда это называют точностью.
В числовой оценке это обычно единственная мера, которая должна иметь значение в настройках обеспечения качества. В мире машинного обучения есть далеко, гораздо больше способов думать об этом, но QA, вероятно, должен придерживаться предела погрешности для большинства вещей.
Как установить критерии приемлемости
Если бы мы жили в идеальном мире, мы могли бы установить критерии приемлемости на нулевую ошибку, и все разошлись бы по домам. В реальном мире ошибка — это неотъемлемая часть жизни, особенно в стохастических условиях. В задачах классификации снижение требований к точности часто приводит к ухудшению отзыва, поэтому знайте, какой из них важнее для вашего продукта.
Кроме того, решите, какой риск взять на себя. Помните, когда продукт работает для миллионов клиентов, даже ошибка с вероятностью 0,001% может означать, что она происходит тысячи раз в день.
Это метрики, которые должны быть установлены на собраниях по продукту с участием заинтересованных сторон и могут быть оценены вашим комплектом тестирования, когда модель построена для прохождения/непрохождения. Это гораздо лучший способ оценки моделей, чем прямой просмотр результатов.
Удачи! Кроме того, если вы столкнетесь с какими-либо интересными практиками в этой области, которые я не описал, пожалуйста, кричите на меня в твиттере.
