Бывала у вас такая ситуация. Выходит новая нейронная сеть и все руководство начинает требовать внедрить её? Половина коллег восторженно рассказывает о новом слое который позволил повысить точность сети? YoloV(N+1)? LLAMA100?

Изначальную версию статьи я публиковал на Медиуме. Так что в каком-то смысле перевод с улучшениями, но авторский.

Вот недавно вышел Qwen2 и YOLOV10. Пора менять? Нет больше хайпа с ML чем выход новых моделей. Каждый ролик про выход новой YOLO собирает массу просмотров. Все хотят менять свои модели! Как быть? Внедрять?

В этой статье я попробую рассказать как не поддаваясь хайпу и принимать взвешенные решения. Поговорим про ситуацию замены сети на аналогичную. Если сеть умеет что-то принципиально новое - скорее относится к компетенции продакт оунеров. И вопрос там стоит: "Нужен ли нам новый функционал"? 

Так что говорить будем о ситуациях типа:

• YOLOv(N)->YOLOv(N+1)

• MobileNetV(N)->MobileNetV(N+1)

• LLAMA->LLAMA2

Цель

Начнём с самого важного. Определить цель внедрения новой сети. Цель "новизна ради новизны" - очень плохо окупается. Когда приходит ресерчер с горящими глазами - это не очень хорошо выглядит для бизнеса. Какие могут быть более адекватные цели?

1. Ваша текущая нейронная сеть плохо работает, вам нужно минимум X, чтобы система заработала, а у вас Y?

2. Вы всегда стараетесь оптимизировать ваши модели. На это есть отдельный бюджет заложенный сверху (тут может не быть логики).

3. Ваша точность напрямую связана с вашим доходом/расходами.

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

5. LLM based модели - знание о окружающем мире, о новых объектах и событиях

6. Вам нужно надувать щёки и эмитировать AI деятельность.  

7. Вы ещё не выбрали модели и вам нужно проанализировать возможные варианты.

Может есть ещё пару-тройка адекватных причин. Но в целом всё упирается в ситуации где есть прямая связь точности с деньгами. Причины 2 и 6 - не будем даже рассматривать. К ML это не имеет отношения. Но часто встречается...
Про знание об окружающем мире тоже нечего добавить. Если это критично - то надо менять.

Начнём с кейсов завязанных на точность.

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

Если вы видите что вышел новый супер большой трансформер - то вам нужно его тестировать только если в вашем проде крутиться такая же большая модель. Сравнивать с ResNet-18, конечно, можно. Но главный вопрос - а почему вы раньше этого не сделали, если можете утяжелить модель.

Для достижения продуктовой точности не хватает ΔX%

Бывает что у вас есть явное понимание: "улучшение точности на ΔX поможет продукту работать лучше!". Но...

Нужно понимать что смена модели на аналогичную по перформансу примерно того же поколения никогда не даст значительный буст.

Замена ResNet (2015) на ConvNext (2023) может уменьшить ошибку на классификации. Но почти никогда это не будет “уменьшить ошибку в 2 раза”. Для сравнимого размера модели это где-то 5%-10%. Если вы меняете аналогичные модели соседних лет - разница будет минимальной. Для моделей с большой разницей лет:

ResNet-50 (76.1) vs ConvNeXt-T (82.1). Много ли это?
Это уменьшает ошибку на 6% от первоначальных ~24%. При этом ¾ ошибки останутся прежними. Значит ошибок будет примерно на 25% меньше. Это хорошо, но обычно не x2 или x3 от точности. Ещё более грустно если ваше точность уже больше 99%. Было 99,6% точности для ResNet-50, стало, вероятно, 99,7%.

Но как же красивые графики? Yolov10 лучшая!!

Но. Посмотрите многочисленные сравнения YOLOv8|YOLOv9|YOLOv10, etc (1, 2). Эта точность не там где вы ожидаете:

1. Граница детекции чуть чуть более аккуратная

2. Чуть чуть лучше детекция работает для очень маленьких объектов

3. Чуть чуть стабильнее работают болшие объекты

С LLM может быть то же самое. Лучше метрики на каком-то специфическом датасете? Может быть за счет поддержки других языков, которые вам не нужны в проде. А для 95% распределения ничего не меняется. И детекция в первую очередь определяется дататсетом. LLM модель не будет разбираться лучше в медицине если у вас не было медицинских датасетов в обучении. 

Результат. Очень редко улучшения точности на dX можно добиться через смену модели. Это может чуть чуть улучшить метрики но и всё. Есть ли способы улучшить более ощутимо? См ниже.

Улучшения точности как процесс

Вы хотите улучшить перформанс модели так как ошибки напрямую влияют на ваш доход. Я вас поздравляю! Это очень редкая задача у Data Sientist'ов. Когда можно тратить время на оптимизацию сетей и процессов. Хотел бы напомнить, что перед тем как выбирать более мощную модель надо проверить несколько других подходов которые часто докидывают больше:

1. Исследовали ли вы ошибки? Можно ли собрать больше примеров с характерными ошибками? Часть добавление в датасет системных ошибок - это самый лучший способ улучшения точности. Так ошибку можно понизить даже на несколько порядков.

2. Пробовали ли вы тренировать более мощные модели? Это дает возможность оценить максимальную точность/насколько вы к ней близки. И если такая модель сильно точнее - настроить дистилляцию.

3. Пробовали ли вы оптимизировать аугментации под вашу задачу? Часто люди забывают что смотря на ошибки можно через аугментации качественно бустануть точность. Или наоборот, отключить аугментации которые ухудшают качество.

4. Пробовали ли вы оптимизировать LR/оптимайзер/функции потерь? Опять же, часто это забывают но тут может таиться больше точности чем в смене модели.

   Если вы уже пробовали все эти вещи - имеет смысл заняться тестированием других моделей.

Выбор модели с нуля/оптимизиация перформанса для существующего пайплайна

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

Что ещё не надо забывать

Квантизация - очень часто разные модули будут иметь разную точность после квантизации. И топовая модель может перестать топово перформить. Не забудьте проверить всё после квантизации.

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

Препроцессинг. Иногда правильный выбор подготовки данных может влиять на скорость/точность. Стандартный препроцессинг YOLOv8, YOLOv5 вот такой:

А если использовать на прямоугольниках и учить на них - будет быстрее:

Есть много других штук как пропроцессинг данных может улучшить вам модель.

Отличие теста от прода. Помните что корректная обучающая выборка куда важнее чем правильная модель. Следите за актуальностью обучающего датасета.

Хотите максимизировать качество при фиксированном перформансе? Помните что есть способы поиска оптимальной архитектуры на железки. Есть несколько компаний которые специализируются на этом. Есть несколько OpenSource решений. Но первое обычно дорого, а второе муторно и нестабильно.

Небольшое саммари 

Нужно ли обновлять вашу модель? В целом нужно. Но хайпа тут реально больше чем реальной работы.

И немного подвала

Эта статья есть в формате видео, если кому-то так проще воспринимать:

А больше на тему ML, железа и оптимизаций я пишу вот тут.