Недавно я получил некоторое представление о структурировании проектов машинного обучения. Как бы мне хотелось, чтобы у меня было такое понимание, когда мы проводили несколько экспериментов в области машинного обучения в недалеком прошлом. В любом случае, я бы не хотел, чтобы те же камни ударили по кому-либо еще, поэтому ниже приводится суть того, что, как мне кажется, я понял. Не стесняйтесь делиться своими впечатлениями, если вы не полностью согласны или у вас другое понимание.

[чтение 3 мин.]

Типичный путь проекта ML был бы следующим в виде списка ToDo:

  1. Хорошо подходит для тренировочного комплекта.
  2. Подходит для Dev Set хорошо.
  3. Подходит для тестового набора хорошо.
  4. Хорошие результаты в реальном мире.

Вот список рекомендаций, которые могут помочь команде работать эффективно. Я знаю, что это очень тонкие входные данные, но я думаю, что при итеративной работе это может оказать значительное влияние.

Для общей модели:

  • Определите метрики единого расчета, чтобы узнать, какая модель лучше. Вместо двух значений «Точность» и «Напоминание» получите F1-Score как единую метрику.
  • Чтобы разделить набор данных, определите правильное разделение между вашим набором для обучения / разработки / тестирования. Я знаю, что разделение на 60–20–20 было стандартной практикой. Если у вас есть хороший набор данных (порядка ~ 100 КБ), вы можете хорошо справиться с разбиением 98–1–1 (да, вы все правильно прочитали). Цель набора Dev - получить репрезентативную выборку, чтобы вы были уверены в производительности вашей модели. Если 10к примеров могут сделать это, зачем переборщить.

Для набора для разработки и тестирования:

  • Иметь набор разработчиков и набор тестов из одного и того же дистрибутива. Потратить несколько часов на то, чтобы сделать это правильно, может очень помочь, поскольку мы определенно можем больше полагаться на нашу метрику набора разработчиков. В противном случае вы можете потратить усилия на настройку продукта, о котором клиент не просил.
  • Убедитесь, что данные в этих наборах отражают данные, которые вы ожидаете получить в будущем и считаете важным преуспеть. например Если вас больше интересуют HD-изображения, возможно, НЕ будет хорошей идеей оптимизировать вашу модель для некоторого случайного качества изображений, загружаемых из Интернета. Это трещины, которые позже могут вызвать серьезные переделки, обрушив фундамент.

Общая стратегия:

Ортогональность в исполнении: Это, безусловно, один из самых важных мыслительных процессов, который был слишком очевиден, но только после того, как я узнал, как его выполнять, я понял, что мы его упустили.

Часто, работая над проектом ML, мы думаем сразу о слишком многих вещах. И все заканчивают тем, что работают над всеми проблемами. Да, это так плохо, как кажется.

Например, определение единой расчетной метрики и ее улучшение - это совершенно разные проблемы. Точно так же получение большего набора данных и извлечение соответствующих функций - совершенно разные проблемы. Беспокоитесь о них отдельно.

Анализ ошибок:

При анализе ошибок полезно:

  • Получите примеры неправильно размеченных наборов для разработчиков (где у вас неправильная классификация).
  • Получите распределение отказов (в основном, классифицируйте их, почему это могло быть неправильно классифицировано, и подсчитайте их).
  • Отметьте их сложностью, чтобы исправить их против улучшения модели.

Теперь вы лучше понимаете, к чему стремиться.

В качестве бонуса вы можете разделить команды, чтобы исправить эти проблемы ортогонально.

Еще один важный факт, о котором следует помнить в любой момент, - это поддерживать одинаковые распределения набора разработчиков и наборов тестов, если вы изменяете наборы разработчиков. Например, если вы добавляете больше изображений HD в свой набор разработчика, убедитесь, что вы обновили свой тестовый набор, чтобы отразить то же распределение.

Производительность на уровне человека:

Можно использовать интуицию окружающих, если мы изо всех сил пытаемся достичь точности на уровне человека. Это может быть очевидно, но я все же упоминаю о них, так как их можно упустить из-за слишком большого количества движущихся частей.

  • Почему человек понял это правильно?
  • Лучший анализ смещения / отклонения
  • Получите маркированные данные от людей.

Пересмотр показателей:

Рекомендуется пересмотреть свои показатели через определенный период времени и повторно проверить их. Например. Если хорошие результаты на Dev set + Single Evaluation Metrics не отражают успешность вашего продукта, ПЕРЕСМОТРЕТЬ и ИЗМЕНИТЬ метрику, поскольку она больше не служит своей цели.

Вот и все, ребята! Я не уверен, правильно ли я отнесся к той интуиции, которую приобрел, и не узнаю, пока вы не поделитесь своим мнением.

Вместе мы учимся, делимся и открываем.

Первоначально опубликовано на сайте ronakbits.tech 12 октября 2017 г.