Недавно я получил некоторое представление о структурировании проектов машинного обучения. Как бы мне хотелось, чтобы у меня было такое понимание, когда мы проводили несколько экспериментов в области машинного обучения в недалеком прошлом. В любом случае, я бы не хотел, чтобы те же камни ударили по кому-либо еще, поэтому ниже приводится суть того, что, как мне кажется, я понял. Не стесняйтесь делиться своими впечатлениями, если вы не полностью согласны или у вас другое понимание.
[чтение 3 мин.]
Типичный путь проекта ML был бы следующим в виде списка ToDo:
- Хорошо подходит для тренировочного комплекта.
- Подходит для Dev Set хорошо.
- Подходит для тестового набора хорошо.
- Хорошие результаты в реальном мире.
Вот список рекомендаций, которые могут помочь команде работать эффективно. Я знаю, что это очень тонкие входные данные, но я думаю, что при итеративной работе это может оказать значительное влияние.
Для общей модели:
- Определите метрики единого расчета, чтобы узнать, какая модель лучше. Вместо двух значений «Точность» и «Напоминание» получите F1-Score как единую метрику.
- Чтобы разделить набор данных, определите правильное разделение между вашим набором для обучения / разработки / тестирования. Я знаю, что разделение на 60–20–20 было стандартной практикой. Если у вас есть хороший набор данных (порядка ~ 100 КБ), вы можете хорошо справиться с разбиением 98–1–1 (да, вы все правильно прочитали). Цель набора Dev - получить репрезентативную выборку, чтобы вы были уверены в производительности вашей модели. Если 10к примеров могут сделать это, зачем переборщить.
Для набора для разработки и тестирования:
- Иметь набор разработчиков и набор тестов из одного и того же дистрибутива. Потратить несколько часов на то, чтобы сделать это правильно, может очень помочь, поскольку мы определенно можем больше полагаться на нашу метрику набора разработчиков. В противном случае вы можете потратить усилия на настройку продукта, о котором клиент не просил.
- Убедитесь, что данные в этих наборах отражают данные, которые вы ожидаете получить в будущем и считаете важным преуспеть. например Если вас больше интересуют HD-изображения, возможно, НЕ будет хорошей идеей оптимизировать вашу модель для некоторого случайного качества изображений, загружаемых из Интернета. Это трещины, которые позже могут вызвать серьезные переделки, обрушив фундамент.
Общая стратегия:
Ортогональность в исполнении: Это, безусловно, один из самых важных мыслительных процессов, который был слишком очевиден, но только после того, как я узнал, как его выполнять, я понял, что мы его упустили.
Часто, работая над проектом ML, мы думаем сразу о слишком многих вещах. И все заканчивают тем, что работают над всеми проблемами. Да, это так плохо, как кажется.
Например, определение единой расчетной метрики и ее улучшение - это совершенно разные проблемы. Точно так же получение большего набора данных и извлечение соответствующих функций - совершенно разные проблемы. Беспокоитесь о них отдельно.
Анализ ошибок:
При анализе ошибок полезно:
- Получите примеры неправильно размеченных наборов для разработчиков (где у вас неправильная классификация).
- Получите распределение отказов (в основном, классифицируйте их, почему это могло быть неправильно классифицировано, и подсчитайте их).
- Отметьте их сложностью, чтобы исправить их против улучшения модели.
Теперь вы лучше понимаете, к чему стремиться.
В качестве бонуса вы можете разделить команды, чтобы исправить эти проблемы ортогонально.
Еще один важный факт, о котором следует помнить в любой момент, - это поддерживать одинаковые распределения набора разработчиков и наборов тестов, если вы изменяете наборы разработчиков. Например, если вы добавляете больше изображений HD в свой набор разработчика, убедитесь, что вы обновили свой тестовый набор, чтобы отразить то же распределение.
Производительность на уровне человека:
Можно использовать интуицию окружающих, если мы изо всех сил пытаемся достичь точности на уровне человека. Это может быть очевидно, но я все же упоминаю о них, так как их можно упустить из-за слишком большого количества движущихся частей.
- Почему человек понял это правильно?
- Лучший анализ смещения / отклонения
- Получите маркированные данные от людей.
Пересмотр показателей:
Рекомендуется пересмотреть свои показатели через определенный период времени и повторно проверить их. Например. Если хорошие результаты на Dev set + Single Evaluation Metrics не отражают успешность вашего продукта, ПЕРЕСМОТРЕТЬ и ИЗМЕНИТЬ метрику, поскольку она больше не служит своей цели.
Вот и все, ребята! Я не уверен, правильно ли я отнесся к той интуиции, которую приобрел, и не узнаю, пока вы не поделитесь своим мнением.
Вместе мы учимся, делимся и открываем.
Первоначально опубликовано на сайте ronakbits.tech 12 октября 2017 г.