Когда алгоритм машинного обучения не достигает уровня человеческих показателей, разработчики часто оказываются перед выбором: за какое из множества улучшений браться в первую очередь? Эндрю Ын, основатель DeepLearning.AI и один из самых авторитетных экспертов в области ИИ, предлагает использовать метод ручного анализа ошибок (Error Analysis). Эта простая, но эффективная процедура позволяет оценить потенциальную пользу от каждой идеи до того, как команда потратит месяцы на её реализацию.
🐾 Проблема «собак-шпионов»: стоит ли тратить время на исправление конкретной ошибки? 0:00
Рассмотрим классический пример: вы разрабатываете классификатор кошек и достигли точности 90%, что означает 10% ошибок на проверочном (dev) наборе данных . Ваш коллега замечает, что алгоритм часто принимает собак за кошек, и предлагает потратить несколько месяцев на сбор новых данных о собаках или проектирование специальных признаков для их исключения .
По мнению Эндрю Ына, прежде чем бросаться в бой, необходимо провести быструю оценку целесообразности этих усилий . Вместо того чтобы рисковать временем, он рекомендует выполнить следующие шаги:
- Соберите около 100 примеров из проверочного набора, на которых алгоритм ошибся .
- Вручную просмотрите эти изображения и подсчитайте, сколько из них на самом деле являются собаками.
Если выяснится, что собаки составляют всего 5% от общего числа ошибок (то есть 5 из 100), то даже полное решение «собачьей проблемы» снизит общую ошибку системы лишь с 10% до 9,5% . Ын называет это «потолком производительности» (ceiling on performance) — верхним пределом того, насколько работа над конкретным направлением может улучшить результат . В данном случае усилия, скорее всего, не оправданы. Однако, если бы собаки составляли 50% ошибок, потенциальное снижение общего уровня ошибки с 10% до 5% сделало бы этот проект приоритетным .
📊 Параллельный анализ: как сравнивать несколько гипотез 5:05
В реальной разработке у инженеров обычно есть сразу несколько идей по улучшению модели. Например, помимо проблемы с собаками, классификатор может ошибаться на крупных представителях семейства кошачьих (львах, пантерах, гепардах) или на размытых (blurry) изображениях .
Для системного подхода Эндрю Ын рекомендует использовать простую таблицу (в Excel или текстовом файле) :
- В строках таблицы перечисляются ошибочно классифицированные изображения (от 1 до 100).
- В столбцах фиксируются категории ошибок: «Собаки», «Крупные кошки», «Размытость».
- Добавляется колонка для комментариев, чтобы фиксировать детали (например, «лев в зоопарке, дождливый день») .
В процессе анализа вы просто ставите галочки в соответствующих столбцах для каждого изображения. По итогам подсчитывается процент вклада каждой категории в общую долю ошибок . Например, если 61% ошибок связан с размытостью снимков, а 43% — с крупными кошками, это явный сигнал, в каком направлении работа будет наиболее продуктивной .
📸 Гибкость в процессе: добавление новых категорий 7:47
Эндрю Ын подчеркивает, что анализ ошибок не должен быть жестко регламентированным процессом. Если во время просмотра ста примеров вы замечаете новую закономерность — например, что фильтры в стиле Instagram или Snapchat мешают распознаванию, — вы можете добавить новый столбец прямо в процессе работы .
Такой метод позволяет:
- Оценить «потолок» улучшений для каждой новой категории .
- Принять решение о распределении ресурсов: если в команде достаточно людей, можно поручить одной группе работу над проблемой размытости, а другой — над крупными кошками .
- Избежать «ручного проектирования» (hand-engineering) там, где оно не даст значимого эффекта .
📝 Итоги и следующие шаги 9:42
Подводя итог, Ын отмечает, что ручной анализ ошибок занимает от нескольких минут до пары часов, но дает бесценное понимание того, куда двигаться дальше . Процедура включает:
- Выборку ошибочных примеров (ложноположительных и ложноотрицательных).
- Категоризацию ошибок по типам.
- Подсчет доли каждой категории.
По словам эксперта, этот процесс часто вдохновляет на новые идеи и направления, которые не были очевидны в начале проекта . Однако иногда в процессе анализа выясняется, что проблема не в алгоритме, а в самих данных — например, когда метки (labels) в проверочном наборе проставлены неверно. Этому вопросу Эндрю Ын посвятил отдельное обсуждение.
