|
Как можно скорее организуйте комплексный рабочий конвейер, включающий
и оценку показателей качества.
Оснастите систему измерительными средствами для определения узких мест.
Диагностируйте компоненты, работающие хуже, чем ожидалось, и разберитесь,
чем вызвано плохое качество: переобучением, недообучением или дефектами
данных либо программ.
Основываясь на результатах измерений, шаг за шагом вносите изменения: сбор
новых данных, подстройку гиперпараметров или смену алгоритмов.
В качестве примера мы будем использовать систему транскрипции уличных адре-
сов Street View (Goodfellow et al., 2014d). Цель этого приложения – добавить здания
356
Практическая методология
на карты Google Maps. Разъезжающие по городу автомобили Street View фотографи-
руют здания и в каждой фотографии прикладывают GPS-координаты. Сверточная
сеть распознает адрес дома на каждой фотографии, что позволяет Google Maps занести
местонахождение соответствующего здания в базу данных. История разработки этого
коммерческого приложения дает пример следования рекомендуемой методологии.
Переходим к описанию шагов процесса.
11.1. Показатели качества
Определение целей в терминах метрики ошибок – обязательный первый шаг, потому
что от выбранной метрики ошибок зависят все последующие действия. Кроме того,
вы должны понимать, какой уровень качества желателен.
Помните, что для большинства приложений невозможно достичь полной безоши-
бочности. Байесовская частота ошибок дает минимальную частоту, на которую мы
можем рассчитывать, даже если объем обучающих данных бесконечен и есть возмож-
ность восстановить истинное распределение вероятности. Причина может заклю-
чаться в том, что входные признаки содержат неполную информацию о выходной
величине, или в том, что система принципиально стохастическая. Кроме того, нас
ограничивает конечный объем обучающих данных.
Объем обучающих данных может быть ограничен по разным причинам. Если ваша
цель – построить наилучший возможный продукт или услугу, то обычно можно со-
брать больше данных, но следует сопоставить выигрыш от дальнейшего уменьшения
ошибки со стоимостью сбора дополнительных данных. Для сбора данных нужны вре-
мя, деньги, а возможно, даже страдания людей (если, к примеру, для получения дан-
ных требуются инвазивные медицинские исследования). Если же цель – ответить на
теоретический вопрос о том, какой алгоритм лучше работает на фиксированном эта-
лонном тесте, то в спецификации теста обычно указан обучающий набор, и собирать
дополнительные данные запрещено.
Как определить разумный уровень ожидаемого качества? В академических иссле-
дованиях обычно имеется некоторая оценка частоты ошибок, основанная на ранее
опубликованных результатах эталонного тестирования. При разработке коммерче-
ского продукта у нас есть представление о том, какая частота ошибок необходима,
чтобы приложение можно было считать безопасным, рентабельным или привлека-
тельным для пользователей. После того как реалистические требования к частоте
ошибок сформулированы, в основе всех дальнейших решений должно быть стремле-
ние к достижению этой частоты.
Помимо целевого значения показателя качества, есть еще вопрос о выборе показа-
теля. Для измерения эффективности полного приложения, включающего компонент
машинного обучения, есть несколько показателей качества. Обычно это не то же самое,
что функция стоимости, используемая при обучении модели. В разделе 5.1.2 отмеча-
лось, что принято измерять верность, или, эквивалентно, частоту ошибок системы.
Однако во многих приложениях нужны более содержательные метрики.
Иногда одни ошибки обходятся гораздо дороже других. Например, в системе обна-
ружения почтового спама возможны ошибки двух типов: неправильная классифика-
ция нормального сообщения как спама и неправильный пропуск спама во входящую
почту. Заблокировать нормальное сообщение гораздо хуже, чем пропустить сомни-
тельное. Вместо того чтобы измерять частоту ошибок классификатора спама, хоте-
Показатели качества
357
лось бы измерить некую полную стоимость, в которой стоимость блокировки нор-
мальных сообщений выше стоимости пропуска спама.
Иногда требуется обучить бинарный классификатор, обнаруживающий редкие со-
бытия, например тест для диагностики редкого заболевания. Предположим, что за-
болевание встречается у одного человека на миллион. Мы легко можем получить для
этой задачи распознавания верность 99.9999, просто заставив классификатор всегда
сообщать об отсутствии заболевания. Очевидно, что верность не годится для оценки
качества такой системы. Решить проблему можно, если измерять не верность, а
Do'stlaringiz bilan baham: |
