ответ (скопирую текст просто, чтобы картинку не вставлять):
Вы абсолютно правы и заметили важную неточность в логике описанного текстового примера.
Эмбеддинг (вектор признаков) считать второй раз обязательно нужно.
Чтобы понять, почему автор статьи выразился некорректно, и как алгоритм работает на самом деле, разберем процесс по шагам:
Что происходит при повторном въезде автомобиля:
Детекция: YOLO находит машину на видео и вырезает номерной знак (или силуэт).
Распознавание номера (OCR): Алгоритм считывает текст номера (например, «А123БТ777»).
Запрос в Redis: Система проверяет, есть ли в базе этот номер. Находит старый лог и сохраненный ранее «эталонный» вектор машины.
⚠️ Расчет нового эмбеддинга (Ваш вопрос): Нейросеть (например, CLIP) обязана заново обработать текущий кадр и получить вектор машины прямо сейчас. Без этого системе просто не с чем будет сравнивать вектор из базы.
Сравнение: Новый вектор сравнивается со старым из Redis по косинусному расстоянию. Если они похожи (например, совпадение > 80%), шлагбаум открывается.
Почему автор написал, что «модель не вызывается»?
Это некорректная формулировка в тексте статьи. Автор перепутал или объединил два разных понятия:
Модель извлечения эмбеддингов (CLIP/ResNet) — ВЫЗЫВАЕТСЯ. Она работает при каждом кадре/въезде, чтобы получить вектор для сравнения.
Модель классификации / Сложнейшая аналитика — НЕ ВЫЗЫВАЕТСЯ. Скорее всего, имелось в виду, что тяжелой нейросети не нужно заново определять марку, точный цвет, год выпуска, искать царапины или сверять авто по огромной внешней базе данных. Все эти метаданные уже привязаны к ID в Redis и мгновенно подтягиваются по ключу.
В чем тогда экономия?
Экономия ресурсов происходит не в момент работы CLIP, а в архитектуре:
Вы экономите на тяжелых классификаторах (не нужно запускать модели классификации марок/цветов).
Если бы номера не было (кейс с медведем в лесу), то расчет эмбеддинга CLIP (условно 10 мс) + поиск в Redis (1 мс) работает в разы быстрее, чем полноценный повторный трекинг и CV-анализ объекта с нуля.
Если вам интересно, мы можем детальнее разобрать оптимизацию кода из статьи или обсудить, как правильно настроить поиск по векторам в Redis. Что именно из этого стоит рассмотреть подробнее?
Приветствую. Сначала выбрать модель получения данных push - инициатива отправителя передать данные, или pull - сервер (ваше приложение) само опрашивает все контроллеры и прочее. Выбрать надо только одну модель, обе не стоит брать (по-крайней мере сразу). Я бы выбрал push модель. А для тех контроллеров, которые ждут чтобы к ним обращались за данными, сделал бы отдельные прокси-программы, которые занимаются их опросом. И здеь важно, что не классы внутри сервера, а именно отдельные исполняемые модули, можно их на скриптовом языке написать для удобства, у них задачка не большая - обращаться к контроллеру периодич-ки и на сервер пересылать.
Дальше, прием данных на сервере. Предлагаю делать через промежуточный циклический буфер, размер расчитывать по времени и объема, пусть на 10 мин, например. Соотвественно, контроллеры присылают данные в разных потоках пусть, пишут каждый в свою позицию в буфере. В другом потоке вы идете по тому же буферу и данные дальше как-то используете - показывайте на экране, сохр в БД и прочее.
не может человек с типом личности как у Миронова играть человека с предпринимательской жилкой.
причем здесь может- не может. Это же кино. Есть такая вещь называется "нравится". Мне вот кино с Мироновым больше нравится, еще нравится когда там текст мигает "это ему кажется", нравится именно своим наличием.
Господа, это вооще - кринж! (слабонервным не открывать)
ну справедливоси ради, дело-то ведь не в руби и не качестве кода, видно по рассказу, что торопились и писали быстро.
что просто пожмотничали покупать готовые данные!
да, в этом все дело. Пожмотил заказчик, а исполнители в лице автора рады бы были спокойно читать файлы готовые xml, а не идти "путем пирата" и вот это все. если б по-нормальному вытаскивали данные с биржи, то было бы время о качестве кода думать и прочем.
Подписывайтесь на канал Технолог Петухов там без цензуры
Подписываемся!
PS: ну нельзя же так. следите немного за языком. у вас не прогеры разве пишут Nordwin и тд. считайте, что вы своих прогеров вот так вот обесценили всех, соотв-но можно подумать и о том, что там они написали, с таким отношением сверху.
упираюсь иногда и так, в этот момент у коллег можно совета спросить, или где-то почерпнуть инфу, не важно. llm сейчас - она про скорость разработки, а не про качество. Как только писание станет никому не нужно, я это замечу, наверно, посыплю голову пеплом и возьму с полки пачку ваших агентов (или что там будет уже на тот момент), или думаете не разберусь потом, я не вижу там ниче сложного.
Еще дополню. Мебель ручной работы посмотрите сколько стоит. Вот с разработкой также будет.
Все просто. Мы с вами ставим на разные "лошади", так сказать. Я ставлю на то, что от ваших услуг рано или поздно (лучше позднее конечно, дороже будет) откажутся, тк вы обоср-сь упретесь в возможности своих агентов, и кусок грязи код ваших агентов придется кому-то править, поддерживать и в итоге переписывать подчистую, - и тут найдут меня, который еще может руками написать, сам.
ллм тоже пользуюсь к слову, но не в таком режиме, а как so продвинутым. бойлерплейт пишется и так не включая головы и достаточно быстро - в теч дня, ну да, не минуты, ну и ладно, некуда торопиться.
на фрилансе и раньше писали достаточно быстро простые вещи, сам заказывал когда-то (давно было, точно до всяких кодопомогаек) сайт магазина, за неделю мне сделали помню.
Приветствую. Делал похожее (пока забросил), напишу свои отличия, может пригодится кому:
- у меня воркеры не лазили в БД, а получали задачи от шедулера. Шедулеров могло быть несколько, у каждого свои воркеры. Воркер не имел доступа к БД, все обновления статусов задач - через шедулер.
- шедулеры занимались пуллингом задач из БД, но с помощью триггеров (на таблице задач висел триггер на появление новых записей).
- задача представляла из себя скрипт (на python либо bash), хранились скрипты задач тоже в БД, в таблице шаблонов
- воркер запускал для каждой задачи дочерний процесс, соотв-но все свои задачи выполнял параллельно.
- воркер ничего не знал конкретно о задаче, кроме скрипта и параметров, и не был как-то специализирован на конкретный вид задач. Соответственно любой воркер мог взять любую задачу. Результат и прогресс выполнения задачи воркер отправлял своему шедулеру.
- если воркер не отвечает, все задачи этого воркера будут перекинуты шедулером на другой воркер, без какого-либо участия БД в этом процессе.
Рад, что стали говорить как надо было сразу. Вот вам для примера статья соседняя (по времени выхода имею ввиду) с вашей https://habr.com/ru/articles/964282/ Почитайте и увидите разницу, и поймете мбыть, что значит своими словами написано.
Здесь тоже торчат уши ллм. Вы можете своими словами отвечать? Вам уже 45 лет. Неужели вы не можете сфорулировать пару слов самостоятельно. Статья ваша - это памятка, ничего нового, все это было прочитано давно уже и руками набрано не раз. Непрошенный совет вам еще - пишите сами, пока есть такая возможность, пока мозги не отсохли еще.
Привет. Нагадил вам в карму, потому что вторая статья от вас - полностью сгенерированная нсетью. На хабре много статей "подправленных" ллм, но с авторским содержанием, у вас же ни одной своей мысли там не видно. Прекращайте это дело. пс: сгенерированным "спасибо" не надо отвечать, уже тошнит видеть это дмо кругом.
я знаю, знаю что 5 лет обучения, n лет практики, и ошибки на млн-ны. Только я не создаю этот градиент, не создаю рын запрос, а плыву в потоке как и все к катастрофе. С этим тоже полностью с вами согласен. Но я не хочу пудрить мозги молодым людям, словами типа "смотрите как много надо учиться, знать, уметь.. чтобы стать Настоящим Инженером" и в итоге получать минимум, и жить в родительском жилье (если повезло).
Мешки на верху пытаются протянуть промышленность на дешевой раб силе еще сколько-то лет. А товарищ в своей статье им вторит - манипуляциями громкими словами пытается загнать людей в тех вузы поднять престиж. Я против этого.
Пусть делают выбор осознанно - доход сантехника/курьера выше - значит так на самом деле нужны инженеры стране.
Нет, не надо так делать. Не надо громких жирных слов, пыли в глаза. Говорите правду, как есть, я сам электронщик (не схемотехник правда, а АСУТП) бывший, отношение (в мое время было 10лет назад) чуть получше чем к работягам и зп на их же уровне.
Хорошо, что меняется в лучшую сторону, но посмотрите на цены в магазине, цены на жилье, тоже ведь все изменилось, на жилье цены выросли в 10 раз относительно 2000х годов.
Это же все вы пишите для молодежи, не для нас уже. А ей в наше время - настоящее время - надо смотреть на оценку профессии, а потом уже на все остальное (престиж, кайф, который проходит со временем и тд).
Отлик в материальном плане будет, когда будет дефицит кадров, когда люди не будут вестить на эту пропаганду о кол-ве творчества, инженер звучит гордо, таблички на дверях и тп.
боты или сотрудники плюсуют, не иначе.
и минусуют неугодных.
ruvds, наставьте плюсиков лучше комменту выше, что вам жалко чтоли)
Приветствую.
Отвечу вам той же монетой:
мой вопрос в гугл ии :
https://habr.com/ru/companies/ruvds/articles/1033870/прочитай эту статью. Я здесь не понял, почему не надо второй раз расчитывать эмбединг для машины со слакбаумом.Всеранвно ведь надо второй раз посчитать?
ответ (скопирую текст просто, чтобы картинку не вставлять):
Вы абсолютно правы и заметили важную неточность в логике описанного текстового примера.
Эмбеддинг (вектор признаков) считать второй раз обязательно нужно.
Чтобы понять, почему автор статьи выразился некорректно, и как алгоритм работает на самом деле, разберем процесс по шагам:
Что происходит при повторном въезде автомобиля:
Детекция: YOLO находит машину на видео и вырезает номерной знак (или силуэт).
Распознавание номера (OCR): Алгоритм считывает текст номера (например, «А123БТ777»).
Запрос в Redis: Система проверяет, есть ли в базе этот номер. Находит старый лог и сохраненный ранее «эталонный» вектор машины.
⚠️ Расчет нового эмбеддинга (Ваш вопрос): Нейросеть (например, CLIP) обязана заново обработать текущий кадр и получить вектор машины прямо сейчас. Без этого системе просто не с чем будет сравнивать вектор из базы.
Сравнение: Новый вектор сравнивается со старым из Redis по косинусному расстоянию. Если они похожи (например, совпадение > 80%), шлагбаум открывается.
Почему автор написал, что «модель не вызывается»?
Это некорректная формулировка в тексте статьи. Автор перепутал или объединил два разных понятия:
Модель извлечения эмбеддингов (CLIP/ResNet) — ВЫЗЫВАЕТСЯ. Она работает при каждом кадре/въезде, чтобы получить вектор для сравнения.
Модель классификации / Сложнейшая аналитика — НЕ ВЫЗЫВАЕТСЯ. Скорее всего, имелось в виду, что тяжелой нейросети не нужно заново определять марку, точный цвет, год выпуска, искать царапины или сверять авто по огромной внешней базе данных. Все эти метаданные уже привязаны к ID в Redis и мгновенно подтягиваются по ключу.
В чем тогда экономия?
Экономия ресурсов происходит не в момент работы CLIP, а в архитектуре:
Вы экономите на тяжелых классификаторах (не нужно запускать модели классификации марок/цветов).
Если бы номера не было (кейс с медведем в лесу), то расчет эмбеддинга CLIP (условно 10 мс) + поиск в Redis (1 мс) работает в разы быстрее, чем полноценный повторный трекинг и CV-анализ объекта с нуля.
Если вам интересно, мы можем детальнее разобрать оптимизацию кода из статьи или обсудить, как правильно настроить поиск по векторам в Redis. Что именно из этого стоит рассмотреть подробнее?
вот и надо было про внутр кухню больше написать, а не скрины делать где какой флажек нажать, чтобы собрать в clion.
про память на жест диске. не на то вы внимание обращаете совсем, важнее сколько опер памяти берет, а брать будет как и электрон, скорее всего.
Смотрим код
Смотрим что такое WebView2
В общем, в статье речь не о том, что надо бы осветить.
Приветствую.
Сначала выбрать модель получения данных push - инициатива отправителя передать данные, или pull - сервер (ваше приложение) само опрашивает все контроллеры и прочее.
Выбрать надо только одну модель, обе не стоит брать (по-крайней мере сразу).
Я бы выбрал push модель.
А для тех контроллеров, которые ждут чтобы к ним обращались за данными, сделал бы отдельные прокси-программы, которые занимаются их опросом. И здеь важно, что не классы внутри сервера, а именно отдельные исполняемые модули, можно их на скриптовом языке написать для удобства, у них задачка не большая - обращаться к контроллеру периодич-ки и на сервер пересылать.
Дальше, прием данных на сервере. Предлагаю делать через промежуточный циклический буфер, размер расчитывать по времени и объема, пусть на 10 мин, например.
Соотвественно, контроллеры присылают данные в разных потоках пусть, пишут каждый в свою позицию в буфере.
В другом потоке вы идете по тому же буферу и данные дальше как-то используете - показывайте на экране, сохр в БД и прочее.
вот пример буфера вам
https://github.com/Tyill/SVisual/blob/master/src/SVServer/src/buffer_data.cpp
причем здесь может- не может. Это же кино.
Есть такая вещь называется "нравится".
Мне вот кино с Мироновым больше нравится, еще нравится когда там текст мигает "это ему кажется", нравится именно своим наличием.
ну справедливоси ради, дело-то ведь не в руби и не качестве кода, видно по рассказу, что торопились и писали быстро.
да, в этом все дело. Пожмотил заказчик, а исполнители в лице автора рады бы были спокойно читать файлы готовые xml, а не идти "путем пирата" и вот это все.
если б по-нормальному вытаскивали данные с биржи, то было бы время о качестве кода думать и прочем.
Зашел и почитал. Дальше будут скрины:
смотрим исходники
общая картина - активности за год не много, наверно, все уже готово и налажено
смотрим проект 4diac-force. Видим 1 инит комит 9мес назад
несколько файлов потыкал - во всех Profactor GmbH, ACIN, fortiss GmbH
кто такие эти Profactor GmbH, ACIN, fortiss GmbH
Вопрос. Где здесь Северсталь собственно?
Недоработка однако
Шучу. Похоже на чудо блин, если реально так моделит двигатель.
Подписываемся!
PS: ну нельзя же так. следите немного за языком. у вас не прогеры разве пишут Nordwin и тд. считайте, что вы своих прогеров вот так вот обесценили всех, соотв-но можно подумать и о том, что там они написали, с таким отношением сверху.
упираюсь иногда и так, в этот момент у коллег можно совета спросить, или где-то почерпнуть инфу, не важно.
llm сейчас - она про скорость разработки, а не про качество.
Как только писание станет никому не нужно, я это замечу, наверно, посыплю голову пеплом и возьму с полки пачку ваших агентов (или что там будет уже на тот момент), или думаете не разберусь потом, я не вижу там ниче сложного.
Еще дополню. Мебель ручной работы посмотрите сколько стоит. Вот с разработкой также будет.
Все просто. Мы с вами ставим на разные "лошади", так сказать.
Я ставлю на то, что от ваших услуг рано или поздно (лучше позднее конечно, дороже будет) откажутся, тк вы
обоср-сьупретесь в возможности своих агентов, икусок грязикод ваших агентов придется кому-то править, поддерживать и в итоге переписывать подчистую, - и тут найдут меня, который еще может руками написать, сам.ллм тоже пользуюсь к слову, но не в таком режиме, а как so продвинутым.
бойлерплейт пишется и так не включая головы и достаточно быстро - в теч дня, ну да, не минуты, ну и ладно, некуда торопиться.
на фрилансе и раньше писали достаточно быстро простые вещи, сам заказывал когда-то (давно было, точно до всяких кодопомогаек) сайт магазина, за неделю мне сделали помню.
Электронной версии книги не увидел на вашем сайте, а если б была - купил бы. (уже давно не читаю бумажные учебники, думаю, не я один такой).
Приветствую.
Делал похожее (пока забросил), напишу свои отличия, может пригодится кому:
- у меня воркеры не лазили в БД, а получали задачи от шедулера.
Шедулеров могло быть несколько, у каждого свои воркеры.
Воркер не имел доступа к БД, все обновления статусов задач - через шедулер.
- шедулеры занимались пуллингом задач из БД, но с помощью триггеров (на таблице задач висел триггер на появление новых записей).
- задача представляла из себя скрипт (на python либо bash), хранились скрипты задач тоже в БД, в таблице шаблонов
- воркер запускал для каждой задачи дочерний процесс, соотв-но все свои задачи выполнял параллельно.
- воркер ничего не знал конкретно о задаче, кроме скрипта и параметров, и не был как-то специализирован на конкретный вид задач.
Соответственно любой воркер мог взять любую задачу.
Результат и прогресс выполнения задачи воркер отправлял своему шедулеру.
- если воркер не отвечает, все задачи этого воркера будут перекинуты шедулером на другой воркер, без какого-либо участия БД в этом процессе.
Вот основные вроде отличия.
Скрытый текст
Все работает без впн. Браузер для новостей не плохо заменяет.
Рад, что стали говорить как надо было сразу.
Вот вам для примера статья соседняя (по времени выхода имею ввиду) с вашей
https://habr.com/ru/articles/964282/
Почитайте и увидите разницу, и поймете мбыть, что значит своими словами написано.
Здесь тоже торчат уши ллм.
Вы можете своими словами отвечать? Вам уже 45 лет. Неужели вы не можете сфорулировать пару слов самостоятельно.
Статья ваша - это памятка, ничего нового, все это было прочитано давно уже и руками набрано не раз.
Непрошенный совет вам еще - пишите сами, пока есть такая возможность, пока мозги не отсохли еще.
Привет.
Нагадил вам в карму, потому что вторая статья от вас - полностью сгенерированная нсетью. На хабре много статей "подправленных" ллм, но с авторским содержанием, у вас же ни одной своей мысли там не видно.
Прекращайте это дело.
пс: сгенерированным "спасибо" не надо отвечать, уже тошнит видеть это дмо кругом.
я знаю, знаю что 5 лет обучения, n лет практики, и ошибки на млн-ны.
Только я не создаю этот градиент, не создаю рын запрос, а плыву в потоке как и все к катастрофе. С этим тоже полностью с вами согласен.
Но я не хочу пудрить мозги молодым людям, словами типа "смотрите как много надо учиться, знать, уметь.. чтобы стать Настоящим Инженером" и в итоге получать минимум, и жить в родительском жилье (если повезло).
Мешки на верху пытаются протянуть промышленность на дешевой раб силе еще сколько-то лет. А товарищ в своей статье им вторит -
манипуляциямигромкими словами пытаетсязагнать людей в тех вузыподнять престиж. Я против этого.Пусть делают выбор осознанно - доход сантехника/курьера выше - значит так на самом деле нужны инженеры стране.
Нет, не надо так делать. Не надо громких жирных слов, пыли в глаза.
Говорите правду, как есть, я сам электронщик (не схемотехник правда, а АСУТП) бывший, отношение (в мое время было 10лет назад) чуть получше чем к работягам и зп на их же уровне.
Хорошо, что меняется в лучшую сторону, но посмотрите на цены в магазине, цены на жилье, тоже ведь все изменилось, на жилье цены выросли в 10 раз относительно 2000х годов.
Это же все вы пишите для молодежи, не для нас уже. А ей в наше время - настоящее время - надо смотреть на оценку профессии, а потом уже на все остальное (престиж, кайф, который проходит со временем и тд).
Отлик в материальном плане будет, когда будет дефицит кадров, когда люди не будут вестить на эту пропаганду о кол-ве творчества, инженер звучит гордо, таблички на дверях и тп.