В рамках специализации по операционному машинному обучению (MLOps) от DeepLearning.AI эксперты рассматривают фундаментальные различия в подходах к разработке моделей в зависимости от типа и объёма данных. Спикер курса, Эндрю Ын (Andrew Ng), предлагает концептуальную матрицу «2х2», которая помогает инженерам определить наиболее эффективную стратегию работы, исходя из того, являются ли их данные структурированными и насколько велик их общий объём.
📊 Матрица проектов машинного обучения: два ключевых измерения 0:01
Для систематизации подходов в ML-инженерии предлагается использовать систему координат, основанную на двух осях :
- Тип данных: неструктурированные (изображения, аудио, текст) против структурированных (записи в базах данных, CSV-файлы).
- Размер набора данных: малые датасеты против больших.
По мнению автора курса, лучшие практики для работы с изображениями могут быть совершенно бесполезны при работе с табличными данными . Это связано прежде всего с когнитивными особенностями человека: люди интуитивно понимают и легко обрабатывают неструктурированные данные, такие как картинки, но гораздо слабее справляются с анализом сотен столбцов в таблицах баз данных .
Что касается размера данных, эксперт вводит условный, но важный порог в 10 000 примеров . По словам спикера, эта граница выбрана потому, что при объёме менее 10 тысяч инженер или небольшая команда ещё могут вручную просмотреть весь набор данных. Если же примеров 100 тысяч или миллион, ручная проверка каждого случая становится физически невозможной .
Примеры для каждого сегмента матрицы:
- Малые неструктурированные: визуальный контроль качества на производстве (например, 100 фотографий поцарапанных телефонов) .
- Малые структурированные: прогнозирование цен на жилье на основе выборки из 50 проданных домов .
- Большие неструктурированные: системы распознавания речи, обученные на 50 миллионах аудиоклипов .
- Большие структурированные: системы рекомендаций для онлайн-магазинов с миллионами пользователей .
🖼️ Неструктурированные данные против структурированных 3:00
Работа с неструктурированными данными (фото, звук, текст) дает инженерам преимущество в виде аугментации данных (data augmentation). Если данных мало, их можно синтезировать :
- Для дефектов на смартфонах можно программно генерировать новые изображения царапин.
- Для аудио можно накладывать на чистую речь различные фоновые шумы, создавая новые тренировочные примеры .
- Для текста начинают появляться новые техники синтеза .
В случае со структурированными данными ситуация сложнее. Спикер утверждает, что гораздо труднее «синтезировать» нового пользователя или несуществующий дом для прогнозирования цен, если в реальности было продано всего 50 домов в данном районе .
Кроме того, человеческая разметка (labeling) более эффективна для неструктурированных данных. Люди легко отличают кошку от собаки, но им гораздо труднее прийти к единому мнению, анализируя две записи в базе данных и пытаясь понять, принадлежат ли они одному и тому же человеку (проблема слияния User ID) . В структурированных данных чаще встречается неопределенность, которая мешает даже экспертам-людям выставить корректную метку .
📉 Маленькие данные против больших: вопрос качества и процесса 4:18
При работе с небольшими наборами данных (менее 10 000 примеров) критически важным становится наличие «чистых» меток (clean labels) .
Аргументация спикера в пользу тщательной ручной проверки:
- Если у вас всего 100 примеров, одна неверная метка — это уже 1% ошибки в данных .
- При малом объёме команда разметчиков обычно невелика (1–3 человека). Если они разошлись во мнениях (например, один пометил объект как «игуана», а другой иначе), им легко собраться в одной комнате, обсудить проблему и выработать единый стандарт .
В случае с «Big Data» (миллионы примеров) акцент смещается с исправления конкретных ошибок на процессы обработки данных (data processes) . Когда разметкой занимаются сотни людей на аутсорсинге (краудсорсинг), невозможно собрать их всех вместе для обсуждения каждой ошибки . В этом случае необходимо:
- Создать небольшую экспертную группу для разработки четких определений и инструкций .
- Транслировать эти стандарты всем исполнителям.
- Тщательно продумать систему сбора и хранения данных, так как переразмечать миллионы объектов после изменения стратегии будет крайне дорого и долго .
🤝 Как выбирать экспертов и нанимать инженеров 8:58
Эндрю Ын делится важным наблюдением относительно найма и получения консультаций. Он считает, что интуиция и навыки инженера лучше всего переносятся внутри одного и того же «квадранта» матрицы .
Советы спикера:
- Ищите экспертов в своем сегменте. Если вы работаете над проектом с малым объёмом структурированных данных, совет специалиста, всю жизнь занимавшегося распознаванием речи на гигантских датасетах, может быть бесполезным или даже вредным .
- Остерегайтесь универсальных правил. Спикер критикует популярные советы в индустрии вроде «для компьютерного зрения всегда нужно минимум 1000 примеров». По его мнению, машинное обучение слишком разнообразно для таких упрощений: автор видел работающие системы CV на 100 примерах и системы распознавания речи на 100 миллионах .
- Адаптивность при найме. При найме ML-инженеров стоит обращать внимание на то, в каком квадранте они работали ранее. Инженер, привыкший к специфике малых данных, быстрее адаптируется к другой задаче из того же сегмента, чем эксперт по «большим данным», внезапно столкнувшийся с необходимостью вручную выверять каждую метку .
В завершение лекции подчеркивается, что именно для малых данных качество (чистота) каждой отдельной точки данных является решающим фактором успеха проекта .
