В машинном обучении качество данных часто оказывается важнее архитектуры модели. Однако даже в самых выверенных датасетах встречаются ошибки: кошка может быть помечена как собака, а нечеткое изображение — получить неверный тег из-за невнимательности разметчика. Основатель DeepLearning.AI Эндрю Ын разбирает, в каких случаях стоит тратить часы на ручную «чистку» меток, а когда нейросеть способна справиться с шумом самостоятельно.
🛠 Ошибки в разметке: когда «грязный» датасет не является приговором 0:00
В задачах обучения с учителем данные состоят из входных признаков ($X$) и выходных меток ($Y$). В процессе работы над проектом исследователь неизбежно сталкивается с ситуацией, когда часть меток $Y$ в обучающей или проверочной выборке оказывается неверной . Например, в классификаторе «кошка/не кошка» изображение собаки может быть ошибочно помечено как кошка из-за человеческого фактора .
Эндрю Ын разделяет два понятия:
- Mislabeled examples (ошибочно предсказанные примеры): ситуации, когда алгоритм выдает неверный результат.
- Incorrectly labeled examples (некорректно размеченные данные): ситуации, когда сама метка в исходном датасете, поставленная человеком, является ошибочной .
По мнению лектора, современные алгоритмы глубокого обучения обладают высокой устойчивостью (robustness) к случайным ошибкам в обучающей выборке . Если ошибки распределены хаотично (например, разметчик случайно нажал не ту клавишу), их можно игнорировать, если общий объем данных велик, а процент брака относительно низок .
Однако Эндрю Ын подчеркивает критическую угрозу: систематические ошибки. Если разметчик стабильно помечает всех белых собак как «кошек», классификатор неизбежно выучит это ложное правило . В этом случае чистка данных становится обязательной.
📊 Анализ ошибок в проверочной выборке (Dev Set) 2:55
Если вопрос с обучающей выборкой стоит не так остро, то ошибки в проверочной (dev) и тестовой (test) выборках могут серьезно исказить оценку прогресса. Чтобы понять масштаб проблемы, Эндрю Ын рекомендует добавить дополнительный столбец в таблицу анализа ошибок .
Процесс выглядит следующим образом:
- Берется выборка примеров (например, 100 штук), на которых алгоритм ошибся.
- Для каждого случая фиксируется причина: плохая освещенность, необычный ракурс, наличие текста на картинке и т.д.
- Добавляется отдельная категория — «Ошибка разметки» (Incorrect label) .
На конкретном примере лектор показывает, как это влияет на принятие решений. Если общая ошибка модели составляет 10%, а на некорректные метки в проверочной выборке приходится лишь 0,6%, то это лишь 6% от общего числа промахов . В такой ситуации Эндрю считает, что тратить время на исправление меток нецелесообразно: оставшиеся 9,4% ошибок, вызванные другими причинами, заслуживают гораздо большего внимания .
⚖️ Когда исправление меток становится приоритетом 6:28
Ситуация радикально меняется, когда качество модели растет. Если общая ошибка снизилась с 10% до 2%, но доля ошибок из-за разметки осталась на уровне 0,6%, это означает, что уже 30% всех промахов алгоритма вызваны «грязными» данными в проверочном наборе .
В этом случае Эндрю Ын выделяет две основные проблемы:
- Искажение оценки: Вы больше не можете объективно судить, насколько хороша ваша модель.
- Трудности выбора: Если классификатор А имеет ошибку 2,1%, а классификатор Б — 1,9%, но в данных 0,6% ошибок разметки, вы не можете быть уверены, какая модель на самом деле лучше .
Основная цель проверочной выборки — помогать выбирать между альтернативными алгоритмами. Если шум в разметке мешает этому выбору, Эндрю Ын настоятельно рекомендует инвестировать время в ручное исправление меток .
📋 Три золотых правила «чистки» данных 8:18
Если вы решили заняться исправлением меток вручную, лектор предлагает придерживаться следующих принципов:
- Синхронность Dev и Test сетов. Любые изменения в процессе разметки должны применяться одновременно к проверочной и тестовой выборкам. Они должны исходить из одного распределения, чтобы ваши цели (dev) соответствовали итоговому экзамену (test) .
- Проверка правильных ответов. Это самый сложный, но важный пункт. Легко проверять только те примеры, где алгоритм ошибся. Однако ошибки в разметке могут быть и там, где алгоритм «угадал» неверную метку . Если проверять только ошибки, оценка точности модели станет предвзятой и завышенной .
- Приоритетность наборов. Исправлять метки в обучающей выборке (Training set) гораздо менее важно, чем в Dev/Test. Если обучающий набор огромен, допустимо оставить его «как есть», исправив только проверочные данные, даже если это приведет к небольшому расхождению в распределениях .
🧠 Человеческий взгляд против «черного ящика» 11:36
В завершение Эндрю Ын развеивает миф о том, что в эпоху глубокого обучения достаточно просто «скормить данные алгоритму». Несмотря на то что современные нейросети требуют меньше ручного проектирования признаков (hand-engineering), создание практических систем по-прежнему требует глубокого понимания данных человеком .
Эндрю признается, что сам до сих пор тратит часы на ручной просмотр сотен примеров, чтобы понять, какие ошибки совершает модель . По его мнению, несколько часов такого анализа дают больше инсайтов для развития проекта, чем любая автоматическая диагностика, и позволяют правильно расставить приоритеты в работе инженера .
