С частью о том, что в тестах 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 свою модель для своих задач, посчитайте стоимость «железа», обучения, настройки, поддержки, потом поговорим про «бесплатно».
Идей, которые оказали влияние на ML, много, и перцептрон Розенблатта - отличная идея. И идея Хинтона с огрнаичением как слоев, так и связей, направленности хода этого потока информации - тоже хорошая идея, следующий этап развития ML. Но мы говорим о другом. Мы применили совершенно новые принципы к работе с изображением и видео, создали собственную архитектуру, и уже применили ее, например, для такой функции, как detection. И мы утверждаем, что именно эти наши принципы мы и применили) Там нет ничего от Yolo, DiNo, ViT, сверточных сетей. Мы применяем наши принципы и показываем конечный работающий продукт. И не просто работающий, а работающий гораздо эффективней. Кажется, перцептрон Розенблатта этим похвастаться не может.
Вы рассказали, как работают сверточные сети. Мы знаем, как они работают. Можно описать, как работают ViT, у них есть свои способы, есть у кого-то другие способы. Но речь совсем не про это. Если говорить про свертку, то в нашем случае мы говорим не просто про отсутствие свертки, а про то, что TAPe противоположен сверточным операциям. В чем именно противоположна и как она работает - описывать не будем. А то что при помощи свертки сегодня и пытаются бороться с многообразием пикселей, которые мешают выделять значимые признаки - ну да, это неплохой вариант, но он был уже реализован во всяких OpenCV, традиционных ML, YOLO. Мы применяем другие методы, не связанные со сверткой. Результаты можете посмотреть опять-таки здесь https://monitor.comexp.net/detect и если нужен будет ключ - поделимся.
Про технологии терминаторов. Мы для себя сформировали новое направление, которое называем Язык Мышления. Мышление, мы считаем, это эффективный процесс. Кто-то считает, что математика и ML эффективней. Мы считаем, что физическое/биологическое, прошедшее миллионы-миллиарды лет эволюции, наверно сформировано достаточно оптимально и неплохо бы это попытаться повторить:)
Насчет редукционизма - да. У нас есть по всему этому поводу прекрасный альманах (англоязычный), который мы подготовили для начала для себя. Читайте на здоровье (вот здесь - конкретно про редукционизм, точнее холизм)
векторы или, точнее, признаки, выделяются из каждого кадра. так как выделяются они очень быстро, и в процессе их выделения основной ресурс уходит на то, чтобы, условно, открыть картинку в каком-то виде. снимать с нее признаки – требуется минимальный ресурс. поэтому мы снимаем с каждого кадра, а уж что и как мы потом в результате используем - это отдельный разговор.
рассуждать категориями действительно ли признаки универсальны мы можем только таким способом: мы снимаем эти признаки тем способом, которым мы снимаем эти признаки для любой из задач, нам (и вам) известных.
как мы формируем эти признаки, которые вы называете векторами – мы, конечно, рассказывать не будем.
чем докажем? у нас реализованы продукты с характеристиками, недоступными любой другой технологии/компании. можно почитать на сайте, в статьях. Например, поиск видео по видео (RVS). Или, например, применение методов TAPe в ML. Вот ссылка, нужен будет ключ - пишите https://monitor.comexp.net/detect Можете поработать со своими классами.
Пиксели не то чтобы ненавистны нам. Мы говорим о том, что пиксели разбивают изображение на незначимые элементы, что кратно усложняет/удорожает (во всех смыслах) работу с изображением (и тем более с видео).
Насчет того, что он станет "толстым": почему? Нет, не станет:) Если вы на что-то смотрите, и описываете это что-то словами, состоящими из букв любого языка, то что в данном случае может считаться более толстым описанием? Более подробное описание некой картинки, которую вы видите? Не становится в данном случае толстым, потому что языко-математический механизм не меняется. Он может быть более детализирован в случае той или иной задачи.
Мы к сожалению не знаем, что вы искали. Вы же, наверно, имеете представление, как работает поиск? Гугл/Яндекс иже с ними когда-то начинали с того, что индексировали сайты - и после индексации эти сайты можно было найти. Начинали они с определенных сайтов и с их ограниченного числа. Нельзя на просторах интернета просто "что-то". Нужна база и индекс по этой базе. В нашем случае мы логично (для нас) пошли путем индексации фильмов, сериалов, ТВ шоу по рейтингу IMDB. Сейчас у нас больше 360 тыс проиндексированных фильмов. С отрывом - самая большая библиотека проиндексированных видео в мире, по которой мы можем мгновенно искать видео. Плюс у нас еще есть функция поиска по ТВ. Вы можете воспользоваться нашим API, накидать туда какое-то кол-во видео контента и потестировать. Или через наш виджет, который можете попробовать на своем сайте. Мы не утверждали, что создали "Гугл по видео". Мы создали инструмент, который к этому "гуглу по видео" приведет.
Вы как будто исходите из предпосылки, что мы не знаем, почему собственно выбрали двоичную систему. Но мы как раз знаем)
Вы рассуждаете в предметных областях, вам знакомых, и это понятно. Отсылки к советскому наследию, аналоговым схемам и т.д. Всё это довольно хорошо описано, изучено и, на наш взгляд, в контексте TAPe описывает происходящее неверно). Неверно именно с точки зрения той картины, в рамках которой мы работаем.
Не хочется вести дискуссию в логике «квантовость»,«аналоговость» — просто потому, что для нас эта ветка бесперспективна. Объяснять, почему именно мы так считаем, особого смысла тоже не видим: мы занимаемся своим делом и движемся по своей траектории. Пусть эта бесперспективность (для нас) спокойно реализуется сама. Если когда‑нибудь существующие TAPe‑механизмы и алгоритмы действительно понадобится положить на что‑то, что будет называться «квантовым» железом, мы вернёмся к этому в тот момент, когда это действительно станет нужно. Аналоговость — где‑то в той же корзине.
Сегодня слово «квантовость» настолько аморфно, что местами уже похоже на амёбу: формально как будто что‑то есть, но в практическом смысле всё это пока довольно сыро. Все эти шрёдингеровские коты, гейзенберги, алгоритмы Шора, канадские стартапы формата «deep‑что‑то» — вокруг них до сих пор идут споры, где там реальная квантовость, а где нет. Разговоры про кубиты, ионы и прочее сейчас больше похожи на зачаточную стадию чего‑то будущего, в сторону чего мы просто осознанно не смотрим.
У нас есть конкретные результаты, к которым мы шли шаг за шагом и продолжаем идти. Про эти результаты мы в том числе здесь рассказываем. В этой точке вы можете либо принять их как есть, либо считать, что мы всё это придумали, или, как сказал один из наших потенциальных клиентов, «всё это сейчас за вас пишет ChatGPT». Мы не собираемся бить себя пяткой в грудь и доказывать, что мы не мошенники и не дилетанты — это ваше право так думать. Тот же чел продолжил «если представить, что вы действительно сделали это на своей истории, минуя ChatGPT или, скажем, YOLO, получается, вам надо было выдать Нобелевскую премию еще вчера». Эта гипотеза нам, честно говоря, нравится больше:) хотя за Нобелевкой мы не гоняемся по вполне приземлённым причинам. Троичность, кубиты, аналоговость и прочие ярлыки – это все мимо.
Гораздо интереснее другой вопрос: в какой момент при переходе к двоичности (0/1, −1/1 и т.п.) произошло «отдискретивание», и не было ли там заведено некое явление, которое в итоге использовали минимально. Наша тейповая идея не вступает в противоречие ни с кубитами, ни с дискретностью, ни с тезисом о том, что кодирование в 0/1 эффективно. Вопрос только: эффективнее по сравнению с чем и за счёт чего именно? Для нас очевидно, что в момент перехода к 0/1 по дороге потеряли несколько важных нюансов. Здесь мы можем разве что слегка подтолкнуть вас к тому, в какую сторону мы сами рассуждаем.
С нашей точки зрения, в двоичности проявилась очень маленькая часть гораздо более крупного явления, извините, вселенского масштаба — дихотомии. В 0/1 эта дихотомия присутствует, но реализована в минимальном возможном виде.
Именно она, дихотомия, создаёт всю вычислительную конструкцию, на данный момент построенную на двоичности.
Но дихотомия существенно мощнее, чем то, как она используется в классической двоичной архитектуре. Потеря «поздних» дихотомических операций приводит к тому, что любой элемент, описанный как последовательность нулей и единиц, не содержит внутри себя явных дополнительных структурных связей. Каждый раз их приходится извлекать заново. Да, эти структуры там есть, и практика показывает, что их можно найти — но за очень немалые усилия.
А есть другие способы, мы их открыли, мы их знаем и мы их применяем. Мы как-то проводили тестирование видеокарт NVIDIA, индексировали видео с помощью методов TAPe. Загрузка декодера у нас стремится к 100 %, а ядра, наоборот, практически не используются. Потому что TAPe. Чтобы загрузить все эти тысячи ядер на 100 %, нам потребовались бы тысячи кодировщиков/декодировщиков, чтобы обеспечить ядра достаточным объемом информации. Но таких видеокарт не существует, все они обрабатывают информацию через 0/1, и поэтому всем им нужны сложносочиненные ядра в огромном количестве, чтобы обрабатывать инфу дедовским методом) А нам - не нужны. Кстати, напишем об этом отдельную статью, спасибо за идею.
здравствуйте. вы с какой целью хотите пощупать? Сейчас мы либо даём платный доступ (после бесплатных тестов) к готовым продуктам, либо используем TAPe‑стек под кастомные решения, где критичны ограничения по данным и ресурсам. В обоих случаях использование наших моделей позволяет на порядки сократить расходы на тяжёлую ИИ‑инфраструктуру при сохранении SOTA‑уровня точности.
не для open ai осталось 18 месяцев, а для AI или по крайней мере его текущей версии, ярким представителем который и является open ai:)
Что может им помочь? Принципиально другие подходы к вычислениям и обработке информации, да и переосмысление самого понятия "информация".
Как принцип ML в широком смысле неплох (нет, не велик, именно неплох, хотя за него и "раздают" Нобелевские премии), но переход от него к понятию AI это просто авантюра и голословные заявления, сродни заявлений о полётах к далёким звёздам при текущем развитии космических технологий.
Возможно в принципе?- ну, наверное.
Есть теории на этот счёт? - куча, выбирай любую, все пока не исследованы.
Есть технологии? - ну, может где-то и лежит уже парочка, в закромах..
Воплощения в текущих "устройствах"? - ха-ха-ха. 31 век - никак не раньше, если вообще возможно хоть когда- нибудь ...
Если оптимизация I-фреймов даёт на 5% лучше сжатие при прочих равных, то ты на объёмах какого-нибудь YouTube на эти 5% сможешь себе самолёт купить.
оптимизация I-фреймов, которую здесь представляет эксперимент, заключалась бы в стратегии их расположения во время энкодинга. это позволило бы очень сильно уменьшить кол-во расчётов, необходимых для самого по себе энкодинга, а также позволило бы сжимать видео намного эффективнее – просто потому что поисковая стратегия лучшего их расположения лучше и быстрее
продолжим:
С частью о том, что в тестах 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 свою модель для своих задач, посчитайте стоимость «железа», обучения, настройки, поддержки, потом поговорим про «бесплатно».
Идей, которые оказали влияние на ML, много, и перцептрон Розенблатта - отличная идея. И идея Хинтона с огрнаичением как слоев, так и связей, направленности хода этого потока информации - тоже хорошая идея, следующий этап развития ML. Но мы говорим о другом. Мы применили совершенно новые принципы к работе с изображением и видео, создали собственную архитектуру, и уже применили ее, например, для такой функции, как detection. И мы утверждаем, что именно эти наши принципы мы и применили) Там нет ничего от Yolo, DiNo, ViT, сверточных сетей. Мы применяем наши принципы и показываем конечный работающий продукт. И не просто работающий, а работающий гораздо эффективней. Кажется, перцептрон Розенблатта этим похвастаться не может.
Вы рассказали, как работают сверточные сети. Мы знаем, как они работают. Можно описать, как работают ViT, у них есть свои способы, есть у кого-то другие способы. Но речь совсем не про это. Если говорить про свертку, то в нашем случае мы говорим не просто про отсутствие свертки, а про то, что TAPe противоположен сверточным операциям. В чем именно противоположна и как она работает - описывать не будем. А то что при помощи свертки сегодня и пытаются бороться с многообразием пикселей, которые мешают выделять значимые признаки - ну да, это неплохой вариант, но он был уже реализован во всяких OpenCV, традиционных ML, YOLO. Мы применяем другие методы, не связанные со сверткой. Результаты можете посмотреть опять-таки здесь https://monitor.comexp.net/detect и если нужен будет ключ - поделимся.
Про технологии терминаторов. Мы для себя сформировали новое направление, которое называем Язык Мышления. Мышление, мы считаем, это эффективный процесс. Кто-то считает, что математика и ML эффективней. Мы считаем, что физическое/биологическое, прошедшее миллионы-миллиарды лет эволюции, наверно сформировано достаточно оптимально и неплохо бы это попытаться повторить:)
Насчет редукционизма - да. У нас есть по всему этому поводу прекрасный альманах (англоязычный), который мы подготовили для начала для себя. Читайте на здоровье (вот здесь - конкретно про редукционизм, точнее холизм)
векторы или, точнее, признаки, выделяются из каждого кадра. так как выделяются они очень быстро, и в процессе их выделения основной ресурс уходит на то, чтобы, условно, открыть картинку в каком-то виде. снимать с нее признаки – требуется минимальный ресурс. поэтому мы снимаем с каждого кадра, а уж что и как мы потом в результате используем - это отдельный разговор.
рассуждать категориями действительно ли признаки универсальны мы можем только таким способом: мы снимаем эти признаки тем способом, которым мы снимаем эти признаки для любой из задач, нам (и вам) известных.
как мы формируем эти признаки, которые вы называете векторами – мы, конечно, рассказывать не будем.
чем докажем? у нас реализованы продукты с характеристиками, недоступными любой другой технологии/компании. можно почитать на сайте, в статьях. Например, поиск видео по видео (RVS). Или, например, применение методов TAPe в ML. Вот ссылка, нужен будет ключ - пишите https://monitor.comexp.net/detect Можете поработать со своими классами.
Пиксели не то чтобы ненавистны нам. Мы говорим о том, что пиксели разбивают изображение на незначимые элементы, что кратно усложняет/удорожает (во всех смыслах) работу с изображением (и тем более с видео).
Насчет того, что он станет "толстым": почему? Нет, не станет:) Если вы на что-то смотрите, и описываете это что-то словами, состоящими из букв любого языка, то что в данном случае может считаться более толстым описанием? Более подробное описание некой картинки, которую вы видите? Не становится в данном случае толстым, потому что языко-математический механизм не меняется. Он может быть более детализирован в случае той или иной задачи.
Мы к сожалению не знаем, что вы искали. Вы же, наверно, имеете представление, как работает поиск? Гугл/Яндекс иже с ними когда-то начинали с того, что индексировали сайты - и после индексации эти сайты можно было найти. Начинали они с определенных сайтов и с их ограниченного числа. Нельзя на просторах интернета просто "что-то". Нужна база и индекс по этой базе. В нашем случае мы логично (для нас) пошли путем индексации фильмов, сериалов, ТВ шоу по рейтингу IMDB. Сейчас у нас больше 360 тыс проиндексированных фильмов. С отрывом - самая большая библиотека проиндексированных видео в мире, по которой мы можем мгновенно искать видео. Плюс у нас еще есть функция поиска по ТВ. Вы можете воспользоваться нашим API, накидать туда какое-то кол-во видео контента и потестировать. Или через наш виджет, который можете попробовать на своем сайте. Мы не утверждали, что создали "Гугл по видео". Мы создали инструмент, который к этому "гуглу по видео" приведет.
Вы как будто исходите из предпосылки, что мы не знаем, почему собственно выбрали двоичную систему. Но мы как раз знаем)
Вы рассуждаете в предметных областях, вам знакомых, и это понятно. Отсылки к советскому наследию, аналоговым схемам и т.д. Всё это довольно хорошо описано, изучено и, на наш взгляд, в контексте TAPe описывает происходящее неверно). Неверно именно с точки зрения той картины, в рамках которой мы работаем.
Не хочется вести дискуссию в логике «квантовость»,«аналоговость» — просто потому, что для нас эта ветка бесперспективна. Объяснять, почему именно мы так считаем, особого смысла тоже не видим: мы занимаемся своим делом и движемся по своей траектории. Пусть эта бесперспективность (для нас) спокойно реализуется сама. Если когда‑нибудь существующие TAPe‑механизмы и алгоритмы действительно понадобится положить на что‑то, что будет называться «квантовым» железом, мы вернёмся к этому в тот момент, когда это действительно станет нужно. Аналоговость — где‑то в той же корзине.
Сегодня слово «квантовость» настолько аморфно, что местами уже похоже на амёбу: формально как будто что‑то есть, но в практическом смысле всё это пока довольно сыро. Все эти шрёдингеровские коты, гейзенберги, алгоритмы Шора, канадские стартапы формата «deep‑что‑то» — вокруг них до сих пор идут споры, где там реальная квантовость, а где нет. Разговоры про кубиты, ионы и прочее сейчас больше похожи на зачаточную стадию чего‑то будущего, в сторону чего мы просто осознанно не смотрим.
У нас есть конкретные результаты, к которым мы шли шаг за шагом и продолжаем идти. Про эти результаты мы в том числе здесь рассказываем. В этой точке вы можете либо принять их как есть, либо считать, что мы всё это придумали, или, как сказал один из наших потенциальных клиентов, «всё это сейчас за вас пишет ChatGPT». Мы не собираемся бить себя пяткой в грудь и доказывать, что мы не мошенники и не дилетанты — это ваше право так думать. Тот же чел продолжил «если представить, что вы действительно сделали это на своей истории, минуя ChatGPT или, скажем, YOLO, получается, вам надо было выдать Нобелевскую премию еще вчера». Эта гипотеза нам, честно говоря, нравится больше:) хотя за Нобелевкой мы не гоняемся по вполне приземлённым причинам. Троичность, кубиты, аналоговость и прочие ярлыки – это все мимо.
Гораздо интереснее другой вопрос: в какой момент при переходе к двоичности (0/1, −1/1 и т.п.) произошло «отдискретивание», и не было ли там заведено некое явление, которое в итоге использовали минимально. Наша тейповая идея не вступает в противоречие ни с кубитами, ни с дискретностью, ни с тезисом о том, что кодирование в 0/1 эффективно. Вопрос только: эффективнее по сравнению с чем и за счёт чего именно? Для нас очевидно, что в момент перехода к 0/1 по дороге потеряли несколько важных нюансов. Здесь мы можем разве что слегка подтолкнуть вас к тому, в какую сторону мы сами рассуждаем.
С нашей точки зрения, в двоичности проявилась очень маленькая часть гораздо более крупного явления, извините, вселенского масштаба — дихотомии. В 0/1 эта дихотомия присутствует, но реализована в минимальном возможном виде.
Именно она, дихотомия, создаёт всю вычислительную конструкцию, на данный момент построенную на двоичности.
Но дихотомия существенно мощнее, чем то, как она используется в классической двоичной архитектуре. Потеря «поздних» дихотомических операций приводит к тому, что любой элемент, описанный как последовательность нулей и единиц, не содержит внутри себя явных дополнительных структурных связей. Каждый раз их приходится извлекать заново. Да, эти структуры там есть, и практика показывает, что их можно найти — но за очень немалые усилия.
А есть другие способы, мы их открыли, мы их знаем и мы их применяем. Мы как-то проводили тестирование видеокарт NVIDIA, индексировали видео с помощью методов TAPe. Загрузка декодера у нас стремится к 100 %, а ядра, наоборот, практически не используются. Потому что TAPe. Чтобы загрузить все эти тысячи ядер на 100 %, нам потребовались бы тысячи кодировщиков/декодировщиков, чтобы обеспечить ядра достаточным объемом информации. Но таких видеокарт не существует, все они обрабатывают информацию через 0/1, и поэтому всем им нужны сложносочиненные ядра в огромном количестве, чтобы обрабатывать инфу дедовским методом) А нам - не нужны. Кстати, напишем об этом отдельную статью, спасибо за идею.
обратите внимание, что я ни слова не сказал про аналоговость
здравствуйте. вы с какой целью хотите пощупать? Сейчас мы либо даём платный доступ (после бесплатных тестов) к готовым продуктам, либо используем TAPe‑стек под кастомные решения, где критичны ограничения по данным и ресурсам. В обоих случаях использование наших моделей позволяет на порядки сократить расходы на тяжёлую ИИ‑инфраструктуру при сохранении SOTA‑уровня точности.
не для open ai осталось 18 месяцев, а для AI или по крайней мере его текущей версии, ярким представителем который и является open ai:)
Что может им помочь? Принципиально другие подходы к вычислениям и обработке информации, да и переосмысление самого понятия "информация".
Как принцип ML в широком смысле неплох (нет, не велик, именно неплох, хотя за него и "раздают" Нобелевские премии), но переход от него к понятию AI это просто авантюра и голословные заявления, сродни заявлений о полётах к далёким звёздам при текущем развитии космических технологий.
Возможно в принципе?- ну, наверное.
Есть теории на этот счёт? - куча, выбирай любую, все пока не исследованы.
Есть технологии? - ну, может где-то и лежит уже парочка, в закромах..
Воплощения в текущих "устройствах"? - ха-ха-ха. 31 век - никак не раньше, если вообще возможно хоть когда- нибудь ...
оптимизация I-фреймов, которую здесь представляет эксперимент, заключалась бы в стратегии их расположения во время энкодинга. это позволило бы очень сильно уменьшить кол-во расчётов, необходимых для самого по себе энкодинга, а также позволило бы сжимать видео намного эффективнее – просто потому что поисковая стратегия лучшего их расположения лучше и быстрее
https://monitor.comexp.net/?scenario=cluster
вот, если любопытно. принимает любое видео (кроме .avi), обрабатывает через DBSCAN с параметрами по умолчанию и отдаёт обратно разбиение.