Многие думают, что публикация модели — это просто: завершил обучение, загрузил файл, написал описание, и дело с концом.
Но те, кто действительно работал с продуктами, знают, что самые сложные моменты начинаются только после запуска.
Данные обновились — нужно переобучение; параметры изменились — необходимо выпустить новую версию; если пользователи сообщают, что результаты ухудшились, нужно выяснить, что именно изменилось. Здесь есть часто игнорируемый парадокс: все хотят, чтобы модель обновлялась быстро, но боятся, что одно обновление может сломать ранее работающие функции.
Поэтому я всегда считал, что хостинг моделей не должен быть просто облачным хранилищем. Действительно полезная платформа должна позволять разработчикам знать, что изменилось в каждой версии, кто продолжает использовать старые версии, и можно ли протестировать новую версию перед запуском.
Model Hub от OpenGradient в этом плане больше похож на систему публикации моделей.
Можно сначала создать независимый репозиторий для модели, а затем публиковать разные релизы, например, v1.00, v1.01, v2.00. В каждой версии можно хранить файлы модели, конфигурации и описания, а не просто заменять старую модель при загрузке нового файла.
Процесс работы тоже довольно гладкий.
Разработчик обучает модель для прогнозирования рисков, сначала экспортирует в формате ONNX, создает репозиторий в Model Hub и загружает v1.00. Затем он может прямо в веб-песочнице протестировать, подтвердить, что входные данные и результаты не имеют явных проблем, и зафиксировать использование этой версии в приложении.
Позже, когда данные для обучения обновляются, можно продолжить публикацию v1.01, четко указав изменения и дав возможность некоторым приложениям протестировать новую версию. Старая версия остается, и обновление не делает все продукты, использующие ее, одновременно неработоспособными. Команда также может использовать Python SDK и CLI, чтобы интегрировать загрузку модели в свои процессы обучения или публикации.
Конечно, даже если номер версии написан красиво, это не доказывает, что модель надежна. Конвертация в ONNX может привести к расхождениям, новые данные могут ухудшить результаты, в конечном итоге все сводится к тестированию и реальным результатам использования.
Но, по крайней мере, это решает очень практическую проблему: модель — это не одноразовый файл, а программное обеспечение, требующее долгосрочного обслуживания. Умение объяснять каждое изменение зачастую важнее, чем шум при первом запуске.
$OPG @OpenGradient #OPG
Но те, кто действительно работал с продуктами, знают, что самые сложные моменты начинаются только после запуска.
Данные обновились — нужно переобучение; параметры изменились — необходимо выпустить новую версию; если пользователи сообщают, что результаты ухудшились, нужно выяснить, что именно изменилось. Здесь есть часто игнорируемый парадокс: все хотят, чтобы модель обновлялась быстро, но боятся, что одно обновление может сломать ранее работающие функции.
Поэтому я всегда считал, что хостинг моделей не должен быть просто облачным хранилищем. Действительно полезная платформа должна позволять разработчикам знать, что изменилось в каждой версии, кто продолжает использовать старые версии, и можно ли протестировать новую версию перед запуском.
Model Hub от OpenGradient в этом плане больше похож на систему публикации моделей.
Можно сначала создать независимый репозиторий для модели, а затем публиковать разные релизы, например, v1.00, v1.01, v2.00. В каждой версии можно хранить файлы модели, конфигурации и описания, а не просто заменять старую модель при загрузке нового файла.
Процесс работы тоже довольно гладкий.
Разработчик обучает модель для прогнозирования рисков, сначала экспортирует в формате ONNX, создает репозиторий в Model Hub и загружает v1.00. Затем он может прямо в веб-песочнице протестировать, подтвердить, что входные данные и результаты не имеют явных проблем, и зафиксировать использование этой версии в приложении.
Позже, когда данные для обучения обновляются, можно продолжить публикацию v1.01, четко указав изменения и дав возможность некоторым приложениям протестировать новую версию. Старая версия остается, и обновление не делает все продукты, использующие ее, одновременно неработоспособными. Команда также может использовать Python SDK и CLI, чтобы интегрировать загрузку модели в свои процессы обучения или публикации.
Конечно, даже если номер версии написан красиво, это не доказывает, что модель надежна. Конвертация в ONNX может привести к расхождениям, новые данные могут ухудшить результаты, в конечном итоге все сводится к тестированию и реальным результатам использования.
Но, по крайней мере, это решает очень практическую проблему: модель — это не одноразовый файл, а программное обеспечение, требующее долгосрочного обслуживания. Умение объяснять каждое изменение зачастую важнее, чем шум при первом запуске.
$OPG @OpenGradient #OPG
