Comments 21
А увеличение у вас базового количества параметров (от 100К) не увеличит качество? По понятным причинам, хочется еще более впечатляющих результатов.
здравствуйте, спасибо.
Из-за нашего подхода увеличение количества параметров без какой-либо на то причины только увеличивает возможность оверфиттинга для модели. Коротко говоря, мы работаем не с "минимально-возможным" количеством параметров, а скорее с "нужным для задачи" – из-за разницы в парадигмах. Вы можете почитать другие статьи о TAPe в моем профиле.
Неплохо, конечно, но явно недостаточно. Спасибо за открытый доступ к модели.
Здравствуйте. Немного смешной комментарий конкретно со стороны "недостаточно", потому что сразу же возникает вопрос "а недостаточно для кого и чего?".
Базовая модель натренированна на COCO, как и написано на сайте. Это означает, что не означает, что она универсально отлично работает для всех объектов из COCO любых размеров и типов положений.
Условно, если нужна конкретно работа с лодками и результаты здесь не устраивают, то это обозначает необходимость тренировки отдельной модели под эти случаи.
В COCO, к примеру, всего около 1000 лодок – разных типов, размеров итд – возможно, в самом датасете лодок похожих на те, что на картинке, и не было, или же было очень мало.
Короче говоря, дефолтная модель для этой цели не подходит и нужна отдельная тренировка – что мы как раз-таки и предоставляем без проблем.
Ну и также к "недостаточно" – было бы любопытно посмотреть на сравнения с другими моделями на COCO, потому что есть стойкое ощущение, что результат будет хуже.
1) А минусы-то какие по сравнению с "большими" моделями? Или только плюсы без минусов?
2) А почему "громкую" революцию не хотите, раз весь мир обогнали?
И статьи только на Хабре...
3) Наверное, заявлять про "выше уровня SOTA" в заголовке, а далее писать про "сопоставимый" с SOTA - не очень корректно.
как думаете, сколько ресурсов компания M.ta потратила на разработку DINOv3? DINOv2? DINO? А сколько YOLO? сколько вообще в мире моделей уровня SOTA? с собственной архитектурой, методами, математикой? сколько их в России? и как думаете, какой у нас штат и сколько мы потратили ресурсов? вы вообще понимаете, что произошло-то?
почему громкую революцию не хотим? хотим. поможете? расскажите о нас знакомым.
про третий пункт - перечитайте внимательно статью.
Спасибо что дали доступ попробовать. Сравнил вашу модель и YOLO26s (по табличке выше вы вроде круче по mAP50–95):
Ваша модель:
YOLO:
Почему так получилось?
Вам же написали, оно руду умеет распознавать, а вы тут картинки из пинтереста суете) это не для вас модель а для тех у кого много денег и мало опыта, вы и сами справитесь)
здравствуйте, спасибо.
В датасете COCO нет такой вещи как "смазанных" изображений. Мы, в свою очередь, не использовали аугментации в тренировке на COCO, которые на это могли бы повлиять.
Из-за этого уверенность модели на таких изображениях ниже стандартного порога уверенности. Это можно заметить в ответе YOLO на скриншоте в том числе - большая часть боксов имеют уверенность в пределах ниже 0.5. Порог уверенности мы оригинально давали контролировать только на натренированных моделях, потому как сам пайплайн COCO является скорее витриной того, что у нас есть хорошая модель, нежели чем основным продуктом.
Но раз есть к этому интерес, то сейчас мы добавили в UI слайдер для контроля порога уверенности в том числе и для стандартной COCO-модели, можете пробовать.
О боже, вы не используете аугментацию? То есть ваша модель заточена чисто под датасет с его идеальной разметкой, и не в курсе что в реальном мире картинка может быть искажена, уменьшена в 100x раз, заблюрена, обрезана и т.д. А вот в YOLO об этом подумали при разработке своего фрейворка обучения. Может, поэтому им и нужно столько параметров, и такая сложная архитектура? Все же заявляться на SATA рановато, там много параметров кроме успешных тестов COCO val.
сначала ответ про аугментацию:
Тезис полностью необоснованный, потому что предполагает, что наш фреймворк и обобщенный пайплайн как таковой не предоставляет возможности аугментации – что совершенно не так. У нас даже в тарифных карточках об этом написано – уже не говоря о том, что аугментация в нашем случае (то есть, в отсутствии огромной поверхности для оверфита) – это забота владельца датасета, если по-хорошему. Мы всё-таки предоставляем модель и удобный UI её тренировки и инференции, а затем ожидаем от пользователей данные. То есть, наш парадигм в том, что для валидации прода существует валидационный сет -- тогда как задачи COCO – это задачи COCO, а никак не задачи общего идеального распознавания 80 классов из датасета. Для общего распознавания (то бишь, за пределами ограничений датасета) у нас есть специальные инструменты для работы пользователей со своими данными, для чего собственно и существует стенд как таковой.
Тезис о том, что YOLO об этом подумали итд – тоже необоснованный. YOLO, как и многие другие модели, вводили и вводят аугментацию как раз-таки из необходимости, а не из заботы о своем фреймворке. При таком количестве параметров, даже с условным freeze=true на их бэкбоуне, аугментации нужны не просто для обеспечения обобщения обучения, а для работы тренировки в целом, за имением числа параметров в десятки и сотни раз выше, чем количество не только тренировочных объектов, но и количества возможных вариаций свойств этих изображений как таковых.
Попытки говорить о том, что "может, поэтому им и нужно столько параметров, и такая сложная архитектура" на фоне этого выглядят ещё забавнее. Концепция понимания визуальных данных – это далеко не "черный ящик" как таковой – и никакой модели не нужны миллионы параметров для понимания концепции блюра изображений, или же скорее – они не должны быть нужны, если её "субстрат" по-настоящему обобщаем. Но он, по всей видимости, НЕ обобщаем у современных моделей.
2. теперь филиппика на ваш пассаж с риторическим приемом "риторические вопросы"
вы реально думаете, что мы о чем-то не в курсе? а на каком основании? вы так решили? только потому, что у нас что-то иначе, чем вы привыкли, как вас учили на каком-нибудь курсе или в какой-нибудь книжке? а может вы просто плохо умеете читать? а думать? а может вы привыкли считать себя умнее других и язык бежит впереди, так сказать, мысли? а может прежде, чем изрекать "мысль" что кто-то о чем-то не подумал/чего-то не знает, лучше задаться вопросом "а как это работает" или даже задать соответствующий вопрос? а может вы не знаете, что считать себя умнее других, а других - глупее себя - это признак глупости?
Насчет перекладывания заботы об аугментации на пользователя - это вы зря. Собирать большие датасеты - это тяжелая работа, и если есть возможность автоматизировать хотя бы базовые вариации, нужно это использовать.
А мой скептицизм вызван способом сравнения моделей по разным метрикам. У вас пайплайн очень туманный (вы работаете не с пикселями а с каким-то TAPE), модель закрытая, непонятно как вы считаете параметры. Единственная метрика, которую вы показали - это mAP90 , но цели обучения у YOLO и вас разные.
спасибо. про аугментацию фидбек полезный, мы посмотрим в эту сторону.
по поводу метрик же – не согласимся.
Цель обучения YOLO - это обучение backbone и дополнительной инфраструктуры над ним (regression голов итд) для обобщенного визуального понимания, что в свою очередь позволяет обучать модель на кастомных датасетах в дальнейшем, не имея при этом 100 тыс. изображений.
Наша цель по сути та же самая, с отличием только в результатах (они объективно лучше) и подходе попросту из нашей архитектуры. Если говорить об этом не уходя в ноу-хау, то в нашем случае backbone – это очень растяжимое понятие, архитектурно их несколько и каждый выполняет свою задачу.
Ну вот давайте углубимся в "обобщенное визуальное понимание" - моя мысль была о том, что YOLO накаплиавют бОльший базис в backbone, чтобы их модель работала с реальным миром, где могут быть разнообразные визуальные искажения. Если при обучении меняли цвета или добавляли шум, то их backbone умеет с этим работать и удовлетворит больше пользователей в иотге. Но ценой бОльшего размера / сложности. Но в тестах COCO это по сути не нужно, и этой разницы не будет видно.
давайте углубимся, с удовольствием.
С частью о том, что в тестах COCO это не нужно и разницы оттуда не заметно – мы полностью согласны.
Но вот с чем не согласны - это с предположением о необходимости этого бОльшего базиса в backbone для работы с кастомными датасетами. В теории это звучит более чем осмысленно, да, но на практике возникают проблемы, в основном по двум причинам, в зависимости от кейса тренировки.
продолжим:
С частью о том, что в тестах COCO это не нужно и разницы оттуда не заметно, частично согласимся, но добавим, что имперически, в YOLO и подобных моделях, аугментации всё-таки нужны - backbone слишком большой для обучения на изначальном количестве данных, и его уменьшение только ухудшает ситуацию, потому что из их архитектур, поверхность для оверфита скалируется одновременно с capacity.
Но вот с чем полностью не согласны - это с предположением о необходимости этого большего базиса в backbone для работы с кастомными датасетами. Аугментации - это всё-таки инвариантность, и слепая инвариативность в кастомных датасетах скорее может привести к большим проблемам в них. Например, если такие вещи как зеркальность или цветовая гамма являются важными деталями в отличии классов друг от друга.
Как можно воспользоваться вашей моделью для распознавания гистологических препаратов?
здравствуйте.
вы можете посмотреть в целом в интернете, как работать с моделями компьютерного зрения. что касается нас, рекомендуем вам начать с бесплатного тарифа, чтобы в целом освоиться с интерфейсом и пр., а потом докупать тарифы в зависимости от ваших задач. Интерфейс простой, специальных знаний не нужно; для того, чтобы обучить модель на своем датасете, нужно совсем немного изображений. Возникнут вопросы - пишите в поддержку.
Поздравления! Даёшь стране лепту в её суверенитет
Тихая-тихая мировая революция. Мы сделали модель распознавания для любых задач компьютерного зрения – и выше уровня SOTA