Чего именно мы пытаемся достичь? Действительно ли новая архитектура модели изменит правила игры? Насколько сильно этот новый набор данных повлияет на точность модели? Вот некоторые вопросы, с которыми типичная команда машинного обучения сталкивается ежедневно. Но важно не увязнуть в тонкостях и всегда возвращаться к подходу из первых принципов. Учитывая скорость, с которой появляются новые исследовательские работы, специалистам по ML/Data/CV важно иногда отходить на второй план и немного больше думать об общей картине.

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

Установление целей и вариантов использования

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

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

Стратегия данных

  1. Сбор данных →Использование готовых наборов данных или создание набора данных с нуля? : Этот шаг кажется решающим для развития любой существенной интеллектуальной собственности.
  2. Маркировка данных → Ручная или автоматическая аннотация?: Это решение в основном зависит от размера наборов данных и стоимости маркировки.
  3. Серверная часть данных → Хранение, индексирование и доставка. Обычно для хранения используется AWS S3, в то время как команды, как правило, создают собственный уровень (обычно на основе Python) для обслуживания данных.

Стратегия модели

  1. Учебная среда →Pytorch или Tensorflow? : Большая часть кода, сопровождающего недавно опубликованные исследовательские работы, похоже, находится в PyTorch, что способствует его использованию в сообществе. Простота использования делает его чрезвычайно привлекательным для быстрого прототипирования. Дополнительные слои поверх PyTorch (например, Lightning, Fast AI) упрощают создание прототипов новых моделей.
  2. Учебная инфраструктура → AWS или самодельные графические установки или и то, и другое? : В идеале комбинация обоих кажется оптимальной для быстрорастущих стартапов. Если этот флажок не установлен, затраты на AWS могут накапливаться очень быстро. Поэтому важно разработать POC (доказательство концепции) локально, прежде чем запускать большие учебные задания на AWS.
  3. Готовые модели для установления базового уровня (при наличии)
  4. Изучение компромисса между точностью и скоростью → Этот блог подробно описывает, как EfficientNet делает именно это.
  5. Поиск нейронной архитектуры → В этом блоге рассказывается о том, как можно использовать NAS в конкретных случаях, чтобы значительно уменьшить размер сети при сохранении точности.

Стратегия развертывания

  1. В облаке → Обычно веб-приложения размещаются на AWS, и модель будет работать в многопоточном режиме на нескольких экземплярах GPU.
  2. На встроенном устройстве → Мобильные телефоны, ASICS/FPGA или другие наборы микросхем. В то время как iPhone предлагает безболезненный опыт развертывания моделей ML, Android и другие устройства обычно требуют более настраиваемых решений, хотя сейчас это начало меняться.
  3. Совместимость моделей → Эта проблема обычно возникает при развертывании на встроенных устройствах. Некоторые операции машинного обучения могут не поддерживаться оборудованием, что влияет на стратегию модели для адаптации к изменениям.
  4. Согласованность кода → Эта проблема обычно возникает при развертывании на встроенных устройствах. Если в модель включена дополнительная логика, ее необходимо протестировать в автономном и онлайн-режиме, чтобы обеспечить согласованность.
  5. Обратная связь по скорости → Быстрое прототипирование может выявить некоторые недостатки в конструкции модели, вызывающие проблемы с задержкой. Это влияет на стратегию модели.

Стратегия тестирования качества

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

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