да, под наше определение автопилота - и под определение во время оно Илона Маска, Андрея Карпатого и иже с ними, когда они еще то ли не очень понимали, что происходит, то ли мастерски пускали пыль в глаза - ничего из текущего не подходит. Тем не менее наша статья - про то, почему влажные мечты остаются мечтами и тонут в маркетинговых уловках и что с этим можно и нужно сделать с точки зрения технологий.
математика далеко не такая примитивная технология, как ии) и многие задачи математикой решаются быстрее и проще, чем ИИ. тем не менее, ни математика, ни ИИ не способны решить задачу, например, автопилота теми методами, которыми сегодня подобные задачи решаются.
мы эту задачу решили, поскольку мы используем методы не только и не столько математики.
здравствуйте. формально и не вдаваясь в подробности, T‑bits – это единицы информации в TAPe: структурированные элементы вместо на самом деле ничего не значащих пикселей или патчей. T-bits, в отл от пикселей, несут в себе инфу об изображении (реальности). Как именно - ноу-хау, не раскрываем. Подробнее можно узнать на нашем сайте https://comexp.net/what-is-the-theory-of-active-perception (статья на англ)
уважаемый Антра, "отмазываются намеками", возможно, в вашем дворе или в вашем доме - не знаю, где вас воспитывали таким вокабуляром. я же просто не хочу за вас делать вашу работу, а именно - хотя бы погуглить, не говоря уже о более глубоком изучении вопроса. вижу, что вы справились с самым первым шагом - как видите, это оказалось не так сложно. однако поиск информации – не самое сложное, информацию еще нужно проанализировать.
даже в вами предоставленной информации достаточно легко увидеть, что Waymo - это не автопилот, хотя вы вольны спорить о понятиях и утверждать, что это автопилот. В нашем понимании, автопилот – это замена человека. Не знаю водитель ли вы, но человек-водитель может сесть в машину и поехать куда хочет, а не по заранее "известным дорогам, формализованным сценариям, в тщательно оттестированных условиях". У человека нет запрета на "движение по особо плотным, хаотичным участкам города, нестандартным развязкам, сложным строительным зонам". Также человек-водитель может ездить не только "в определенных городах и зонах внутри них, внутри каждой из которой есть очерченный полигон – улицы и кварталы". И так далее. Попробуйте увидеть здесь разницу между роботакси Waymo и автоилотом, заменяющим человека. Если вы ее не видите, то, наверно, дальше дискутировать не о чем. Если же вам все-таки эта разница худо-бедно бросается в глаза, попробуйте задуматься, каков путь нужно проделать до полноценного автопилота, какие технологии для этого нужно, что мешает компании/компаниям сделать именно автопилот.
уважаемый ватару, но разве мы прямым текстом не пишем то же самое: что это разные задачи, но не решаются (и не будут решены) они по причинам, корень у которых - один? далее по тексту. попробуйте прочитать внимательней.
что касается ваших риторических вопросов по поводу Content ID, то на наш взгляд, технология работы с видео и задачи работы с видео гораздо шире, чем сравнение пользовательского контента; и если бы в уважаемом Гугле сумели бы создать систему технологически и экономически эффективную, то они вывели бы ее на рынок, найдя ей другое применение (можете сами предположить, какое); но они этого не делают, потому что у них нет таких технологий. причина, почему нет - описана частично в этой статье, прямым текстом, частично - в других наших статьях
что касается Waymo, то вы заблуждаетесь, намеренно или нет, говоря, что она "отлично ездит на полном автопилоте во многих штатах уже несколько лет" – это строго и сильно ограниченная система со строжайшими же предписаниями; иначе говоря, это – не автопилот в нормальном понимании, ибо автопилот в нормальном понимании – это замена человека-водителя. не будем повторяться, почему Waymo для этого бесконечно далеко
С частью о том, что в тестах COCO это не нужно и разницы оттуда не заметно, частично согласимся, но добавим, что имперически, в YOLO и подобных моделях, аугментации всё-таки нужны - backbone слишком большой для обучения на изначальном количестве данных, и его уменьшение только ухудшает ситуацию, потому что из их архитектур, поверхность для оверфита скалируется одновременно с capacity.
Но вот с чем полностью не согласны - это с предположением о необходимости этого большего базиса в backbone для работы с кастомными датасетами. Аугментации - это всё-таки инвариантность, и слепая инвариативность в кастомных датасетах скорее может привести к большим проблемам в них. Например, если такие вещи как зеркальность или цветовая гамма являются важными деталями в отличии классов друг от друга.
С частью о том, что в тестах COCO это не нужно и разницы оттуда не заметно – мы полностью согласны.
Но вот с чем не согласны - это с предположением о необходимости этого бОльшего базиса в backbone для работы с кастомными датасетами. В теории это звучит более чем осмысленно, да, но на практике возникают проблемы, в основном по двум причинам, в зависимости от кейса тренировки.
спасибо. про аугментацию фидбек полезный, мы посмотрим в эту сторону.
по поводу метрик же – не согласимся.
Цель обучения YOLO - это обучение backbone и дополнительной инфраструктуры над ним (regression голов итд) для обобщенного визуального понимания, что в свою очередь позволяет обучать модель на кастомных датасетах в дальнейшем, не имея при этом 100 тыс. изображений.
Наша цель по сути та же самая, с отличием только в результатах (они объективно лучше) и подходе попросту из нашей архитектуры. Если говорить об этом не уходя в ноу-хау, то в нашем случае backbone – это очень растяжимое понятие, архитектурно их несколько и каждый выполняет свою задачу.
Тезис полностью необоснованный, потому что предполагает, что наш фреймворк и обобщенный пайплайн как таковой не предоставляет возможности аугментации – что совершенно не так. У нас даже в тарифных карточках об этом написано – уже не говоря о том, что аугментация в нашем случае (то есть, в отсутствии огромной поверхности для оверфита) – это забота владельца датасета, если по-хорошему. Мы всё-таки предоставляем модель и удобный UI её тренировки и инференции, а затем ожидаем от пользователей данные. То есть, наш парадигм в том, что для валидации прода существует валидационный сет -- тогда как задачи COCO – это задачи COCO, а никак не задачи общего идеального распознавания 80 классов из датасета. Для общего распознавания (то бишь, за пределами ограничений датасета) у нас есть специальные инструменты для работы пользователей со своими данными, для чего собственно и существует стенд как таковой.
Тезис о том, что YOLO об этом подумали итд – тоже необоснованный. YOLO, как и многие другие модели, вводили и вводят аугментацию как раз-таки из необходимости, а не из заботы о своем фреймворке. При таком количестве параметров, даже с условным freeze=true на их бэкбоуне, аугментации нужны не просто для обеспечения обобщения обучения, а для работы тренировки в целом, за имением числа параметров в десятки и сотни раз выше, чем количество не только тренировочных объектов, но и количества возможных вариаций свойств этих изображений как таковых.
Попытки говорить о том, что "может, поэтому им и нужно столько параметров, и такая сложная архитектура" на фоне этого выглядят ещё забавнее. Концепция понимания визуальных данных – это далеко не "черный ящик" как таковой – и никакой модели не нужны миллионы параметров для понимания концепции блюра изображений, или же скорее – они не должны быть нужны, если её "субстрат" по-настоящему обобщаем. Но он, по всей видимости, НЕ обобщаем у современных моделей.
2. теперь филиппика на ваш пассаж с риторическим приемом "риторические вопросы"
вы реально думаете, что мы о чем-то не в курсе? а на каком основании? вы так решили? только потому, что у нас что-то иначе, чем вы привыкли, как вас учили на каком-нибудь курсе или в какой-нибудь книжке? а может вы просто плохо умеете читать? а думать? а может вы привыкли считать себя умнее других и язык бежит впереди, так сказать, мысли? а может прежде, чем изрекать "мысль" что кто-то о чем-то не подумал/чего-то не знает, лучше задаться вопросом "а как это работает" или даже задать соответствующий вопрос? а может вы не знаете, что считать себя умнее других, а других - глупее себя - это признак глупости?
спасибо. увы, у страны не всегда хорошо складываются отношения с новыми технологиями. радио, вертолеты, телевидение, кибернетика в целом. список длинный. кто первый - того и тапки.
здравствуйте. вы можете посмотреть в целом в интернете, как работать с моделями компьютерного зрения. что касается нас, рекомендуем вам начать с бесплатного тарифа, чтобы в целом освоиться с интерфейсом и пр., а потом докупать тарифы в зависимости от ваших задач. Интерфейс простой, специальных знаний не нужно; для того, чтобы обучить модель на своем датасете, нужно совсем немного изображений. Возникнут вопросы - пишите в поддержку.
Из-за нашего подхода увеличение количества параметров без какой-либо на то причины только увеличивает возможность оверфиттинга для модели. Коротко говоря, мы работаем не с "минимально-возможным" количеством параметров, а скорее с "нужным для задачи" – из-за разницы в парадигмах. Вы можете почитать другие статьи о TAPe в моем профиле.
как думаете, сколько ресурсов компания M.ta потратила на разработку DINOv3? DINOv2? DINO? А сколько YOLO? сколько вообще в мире моделей уровня SOTA? с собственной архитектурой, методами, математикой? сколько их в России? и как думаете, какой у нас штат и сколько мы потратили ресурсов? вы вообще понимаете, что произошло-то?
почему громкую революцию не хотим? хотим. поможете? расскажите о нас знакомым. про третий пункт - перечитайте внимательно статью.
В датасете COCO нет такой вещи как "смазанных" изображений. Мы, в свою очередь, не использовали аугментации в тренировке на COCO, которые на это могли бы повлиять.
Из-за этого уверенность модели на таких изображениях ниже стандартного порога уверенности. Это можно заметить в ответе YOLO на скриншоте в том числе - большая часть боксов имеют уверенность в пределах ниже 0.5. Порог уверенности мы оригинально давали контролировать только на натренированных моделях, потому как сам пайплайн COCO является скорее витриной того, что у нас есть хорошая модель, нежели чем основным продуктом.
Но раз есть к этому интерес, то сейчас мы добавили в UI слайдер для контроля порога уверенности в том числе и для стандартной COCO-модели, можете пробовать.
Здравствуйте. Немного смешной комментарий конкретно со стороны "недостаточно", потому что сразу же возникает вопрос "а недостаточно для кого и чего?".
Базовая модель натренированна на COCO, как и написано на сайте. Это означает, что не означает, что она универсально отлично работает для всех объектов из COCO любых размеров и типов положений.
Условно, если нужна конкретно работа с лодками и результаты здесь не устраивают, то это обозначает необходимость тренировки отдельной модели под эти случаи.
В COCO, к примеру, всего около 1000 лодок – разных типов, размеров итд – возможно, в самом датасете лодок похожих на те, что на картинке, и не было, или же было очень мало.
Короче говоря, дефолтная модель для этой цели не подходит и нужна отдельная тренировка – что мы как раз-таки и предоставляем без проблем.
Ну и также к "недостаточно" – было бы любопытно посмотреть на сравнения с другими моделями на COCO, потому что есть стойкое ощущение, что результат будет хуже.
вы правы в том, что у нас "всё другое". но, надеемся, у вас нет тех же претензий к производителям электрокаров, которые сравнивают свои изделия с классическими моделями автомобилей, когда электродвигатель ведет к изменениям практически всего внутри авто? или можем попробовать в обычный автомобиль – какая у вас любимая марка? – просто "засунуть" электродвигатель и посмотреть, что будет. или давайте считать, что электрокары и авто с ДВС – это разного класса объекты из разных отраслей и разного назначения.
принципы ML мы сохранили. просто мы меняем ML, и продолжим менять.
посмотрите пожалуйста требования к «железу», необходимому, чтобы развернуть хотя бы на YOLO свою модель для своих задач, посчитайте стоимость «железа», обучения, настройки, поддержки, потом поговорим про «бесплатно».
да, под наше определение автопилота - и под определение во время оно Илона Маска, Андрея Карпатого и иже с ними, когда они еще то ли не очень понимали, что происходит, то ли мастерски пускали пыль в глаза - ничего из текущего не подходит. Тем не менее наша статья - про то, почему влажные мечты остаются мечтами и тонут в маркетинговых уловках и что с этим можно и нужно сделать с точки зрения технологий.
Что такое "сильный ИИ" нам неизвестно.
давайте увидим. итак, автопилот - это система, которая заменяет человека-водителя с правами категории B. так пойдет?
математика далеко не такая примитивная технология, как ии) и многие задачи математикой решаются быстрее и проще, чем ИИ. тем не менее, ни математика, ни ИИ не способны решить задачу, например, автопилота теми методами, которыми сегодня подобные задачи решаются.
мы эту задачу решили, поскольку мы используем методы не только и не столько математики.
здравствуйте.
формально и не вдаваясь в подробности, T‑bits – это единицы информации в TAPe: структурированные элементы вместо на самом деле ничего не значащих пикселей или патчей. T-bits, в отл от пикселей, несут в себе инфу об изображении (реальности). Как именно - ноу-хау, не раскрываем. Подробнее можно узнать на нашем сайте https://comexp.net/what-is-the-theory-of-active-perception (статья на англ)
уважаемый Антра, "отмазываются намеками", возможно, в вашем дворе или в вашем доме - не знаю, где вас воспитывали таким вокабуляром. я же просто не хочу за вас делать вашу работу, а именно - хотя бы погуглить, не говоря уже о более глубоком изучении вопроса. вижу, что вы справились с самым первым шагом - как видите, это оказалось не так сложно. однако поиск информации – не самое сложное, информацию еще нужно проанализировать.
даже в вами предоставленной информации достаточно легко увидеть, что Waymo - это не автопилот, хотя вы вольны спорить о понятиях и утверждать, что это автопилот. В нашем понимании, автопилот – это замена человека. Не знаю водитель ли вы, но человек-водитель может сесть в машину и поехать куда хочет, а не по заранее "известным дорогам, формализованным сценариям, в тщательно оттестированных условиях". У человека нет запрета на "движение по особо плотным, хаотичным участкам города, нестандартным развязкам, сложным строительным зонам". Также человек-водитель может ездить не только "в определенных городах и зонах внутри них, внутри каждой из которой есть очерченный полигон – улицы и кварталы". И так далее. Попробуйте увидеть здесь разницу между роботакси Waymo и автоилотом, заменяющим человека. Если вы ее не видите, то, наверно, дальше дискутировать не о чем. Если же вам все-таки эта разница худо-бедно бросается в глаза, попробуйте задуматься, каков путь нужно проделать до полноценного автопилота, какие технологии для этого нужно, что мешает компании/компаниям сделать именно автопилот.
изучите вопрос необходимых условий/ограничений, при которых может работать waymo
я уже написал: мы прямым текстом, черным по белому, в статье пишем об этом. чтобы объяснить вам, придется, видимо, пересказать статью.
что касается waymo: рекомендую изучить пристальней вопрос
уважаемый ватару, но разве мы прямым текстом не пишем то же самое: что это разные задачи, но не решаются (и не будут решены) они по причинам, корень у которых - один? далее по тексту. попробуйте прочитать внимательней.
что касается ваших риторических вопросов по поводу Content ID, то на наш взгляд, технология работы с видео и задачи работы с видео гораздо шире, чем сравнение пользовательского контента; и если бы в уважаемом Гугле сумели бы создать систему технологически и экономически эффективную, то они вывели бы ее на рынок, найдя ей другое применение (можете сами предположить, какое); но они этого не делают, потому что у них нет таких технологий. причина, почему нет - описана частично в этой статье, прямым текстом, частично - в других наших статьях
что касается Waymo, то вы заблуждаетесь, намеренно или нет, говоря, что она "отлично ездит на полном автопилоте во многих штатах уже несколько лет" – это строго и сильно ограниченная система со строжайшими же предписаниями; иначе говоря, это – не автопилот в нормальном понимании, ибо автопилот в нормальном понимании – это замена человека-водителя. не будем повторяться, почему Waymo для этого бесконечно далеко
продолжим:
С частью о том, что в тестах COCO это не нужно и разницы оттуда не заметно, частично согласимся, но добавим, что имперически, в YOLO и подобных моделях, аугментации всё-таки нужны - backbone слишком большой для обучения на изначальном количестве данных, и его уменьшение только ухудшает ситуацию, потому что из их архитектур, поверхность для оверфита скалируется одновременно с capacity.
Но вот с чем полностью не согласны - это с предположением о необходимости этого большего базиса в backbone для работы с кастомными датасетами. Аугментации - это всё-таки инвариантность, и слепая инвариативность в кастомных датасетах скорее может привести к большим проблемам в них. Например, если такие вещи как зеркальность или цветовая гамма являются важными деталями в отличии классов друг от друга.
давайте углубимся, с удовольствием.
С частью о том, что в тестах COCO это не нужно и разницы оттуда не заметно – мы полностью согласны.
Но вот с чем не согласны - это с предположением о необходимости этого бОльшего базиса в backbone для работы с кастомными датасетами. В теории это звучит более чем осмысленно, да, но на практике возникают проблемы, в основном по двум причинам, в зависимости от кейса тренировки.
спасибо. про аугментацию фидбек полезный, мы посмотрим в эту сторону.
по поводу метрик же – не согласимся.
Цель обучения YOLO - это обучение backbone и дополнительной инфраструктуры над ним (regression голов итд) для обобщенного визуального понимания, что в свою очередь позволяет обучать модель на кастомных датасетах в дальнейшем, не имея при этом 100 тыс. изображений.
Наша цель по сути та же самая, с отличием только в результатах (они объективно лучше) и подходе попросту из нашей архитектуры. Если говорить об этом не уходя в ноу-хау, то в нашем случае backbone – это очень растяжимое понятие, архитектурно их несколько и каждый выполняет свою задачу.
сначала ответ про аугментацию:
Тезис полностью необоснованный, потому что предполагает, что наш фреймворк и обобщенный пайплайн как таковой не предоставляет возможности аугментации – что совершенно не так. У нас даже в тарифных карточках об этом написано – уже не говоря о том, что аугментация в нашем случае (то есть, в отсутствии огромной поверхности для оверфита) – это забота владельца датасета, если по-хорошему. Мы всё-таки предоставляем модель и удобный UI её тренировки и инференции, а затем ожидаем от пользователей данные. То есть, наш парадигм в том, что для валидации прода существует валидационный сет -- тогда как задачи COCO – это задачи COCO, а никак не задачи общего идеального распознавания 80 классов из датасета. Для общего распознавания (то бишь, за пределами ограничений датасета) у нас есть специальные инструменты для работы пользователей со своими данными, для чего собственно и существует стенд как таковой.
Тезис о том, что YOLO об этом подумали итд – тоже необоснованный. YOLO, как и многие другие модели, вводили и вводят аугментацию как раз-таки из необходимости, а не из заботы о своем фреймворке. При таком количестве параметров, даже с условным freeze=true на их бэкбоуне, аугментации нужны не просто для обеспечения обобщения обучения, а для работы тренировки в целом, за имением числа параметров в десятки и сотни раз выше, чем количество не только тренировочных объектов, но и количества возможных вариаций свойств этих изображений как таковых.
Попытки говорить о том, что "может, поэтому им и нужно столько параметров, и такая сложная архитектура" на фоне этого выглядят ещё забавнее. Концепция понимания визуальных данных – это далеко не "черный ящик" как таковой – и никакой модели не нужны миллионы параметров для понимания концепции блюра изображений, или же скорее – они не должны быть нужны, если её "субстрат" по-настоящему обобщаем. Но он, по всей видимости, НЕ обобщаем у современных моделей.
2. теперь филиппика на ваш пассаж с риторическим приемом "риторические вопросы"
вы реально думаете, что мы о чем-то не в курсе? а на каком основании? вы так решили? только потому, что у нас что-то иначе, чем вы привыкли, как вас учили на каком-нибудь курсе или в какой-нибудь книжке? а может вы просто плохо умеете читать? а думать? а может вы привыкли считать себя умнее других и язык бежит впереди, так сказать, мысли? а может прежде, чем изрекать "мысль" что кто-то о чем-то не подумал/чего-то не знает, лучше задаться вопросом "а как это работает" или даже задать соответствующий вопрос? а может вы не знаете, что считать себя умнее других, а других - глупее себя - это признак глупости?
спасибо. увы, у страны не всегда хорошо складываются отношения с новыми технологиями. радио, вертолеты, телевидение, кибернетика в целом. список длинный. кто первый - того и тапки.
здравствуйте.
вы можете посмотреть в целом в интернете, как работать с моделями компьютерного зрения. что касается нас, рекомендуем вам начать с бесплатного тарифа, чтобы в целом освоиться с интерфейсом и пр., а потом докупать тарифы в зависимости от ваших задач. Интерфейс простой, специальных знаний не нужно; для того, чтобы обучить модель на своем датасете, нужно совсем немного изображений. Возникнут вопросы - пишите в поддержку.
здравствуйте, спасибо.
Из-за нашего подхода увеличение количества параметров без какой-либо на то причины только увеличивает возможность оверфиттинга для модели. Коротко говоря, мы работаем не с "минимально-возможным" количеством параметров, а скорее с "нужным для задачи" – из-за разницы в парадигмах. Вы можете почитать другие статьи о TAPe в моем профиле.
как думаете, сколько ресурсов компания M.ta потратила на разработку DINOv3? DINOv2? DINO? А сколько YOLO? сколько вообще в мире моделей уровня SOTA? с собственной архитектурой, методами, математикой? сколько их в России? и как думаете, какой у нас штат и сколько мы потратили ресурсов? вы вообще понимаете, что произошло-то?
почему громкую революцию не хотим? хотим. поможете? расскажите о нас знакомым.
про третий пункт - перечитайте внимательно статью.
здравствуйте, спасибо.
В датасете COCO нет такой вещи как "смазанных" изображений. Мы, в свою очередь, не использовали аугментации в тренировке на COCO, которые на это могли бы повлиять.
Из-за этого уверенность модели на таких изображениях ниже стандартного порога уверенности. Это можно заметить в ответе YOLO на скриншоте в том числе - большая часть боксов имеют уверенность в пределах ниже 0.5. Порог уверенности мы оригинально давали контролировать только на натренированных моделях, потому как сам пайплайн COCO является скорее витриной того, что у нас есть хорошая модель, нежели чем основным продуктом.
Но раз есть к этому интерес, то сейчас мы добавили в UI слайдер для контроля порога уверенности в том числе и для стандартной COCO-модели, можете пробовать.
Здравствуйте. Немного смешной комментарий конкретно со стороны "недостаточно", потому что сразу же возникает вопрос "а недостаточно для кого и чего?".
Базовая модель натренированна на COCO, как и написано на сайте. Это означает, что не означает, что она универсально отлично работает для всех объектов из COCO любых размеров и типов положений.
Условно, если нужна конкретно работа с лодками и результаты здесь не устраивают, то это обозначает необходимость тренировки отдельной модели под эти случаи.
В COCO, к примеру, всего около 1000 лодок – разных типов, размеров итд – возможно, в самом датасете лодок похожих на те, что на картинке, и не было, или же было очень мало.
Короче говоря, дефолтная модель для этой цели не подходит и нужна отдельная тренировка – что мы как раз-таки и предоставляем без проблем.
Ну и также к "недостаточно" – было бы любопытно посмотреть на сравнения с другими моделями на COCO, потому что есть стойкое ощущение, что результат будет хуже.
вы правы в том, что у нас "всё другое". но, надеемся, у вас нет тех же претензий к производителям электрокаров, которые сравнивают свои изделия с классическими моделями автомобилей, когда электродвигатель ведет к изменениям практически всего внутри авто? или можем попробовать в обычный автомобиль – какая у вас любимая марка? – просто "засунуть" электродвигатель и посмотреть, что будет. или давайте считать, что электрокары и авто с ДВС – это разного класса объекты из разных отраслей и разного назначения.
принципы ML мы сохранили. просто мы меняем ML, и продолжим менять.
посмотрите пожалуйста требования к «железу», необходимому, чтобы развернуть хотя бы на YOLO свою модель для своих задач, посчитайте стоимость «железа», обучения, настройки, поддержки, потом поговорим про «бесплатно».