Содержание статьи
- “гейм-чейнджер” или “апгрейд мозга”?
- Коротко: что такое VLM/MLLM и чем они отличаются от классического CV
- Почему видео сложнее изображения: темпоральность и “что изменилось”
- Экономика и производительность: почему MLLM не может анализировать весь поток
- Главный паттерн ближайших лет: “детекторы → триггер → MLLM”
- Где MLLM/VLM реально сильны: контекст, объяснение, семантика
- Классы задач “длительного характера”: примеры, которые масштабируются экономически
- Как превратить “умный текст” в надежный производственный компонент
- RAG vs fine-tuning в визуальных задачах: где часто ошибаются
- Почему “обесценивания инвестиций” можно избежать: платформа как страховка от технологических волн
- Референс-архитектура платформы видеоаналитики (вендорно-нейтрально)
- Мультимодальность как источник денег: видео + контекст предприятия
- Адвокат дьявола: риски MLLM/VLM и как их приземлить
- Финал: революция в возможностях, эволюция в инженерии — и почему выигрывают платформы
За последний год в видеоаналитике произошло то, что обычно случается раз в десятилетие: на сцену вышли MLLM и их частный случай Visual LLM - модели, которые не просто “видят объекты”, а понимают смысл ситуации. Это звучит как приговор всему, что рынок строил последние 5-10 лет: детекторам, правилам, разметкам, тоннам интеграционного кода, отчетам и “витринам” инцидентов. Если модель может посмотреть на кадр и объяснить, почему это нарушение, какой риск, что делать дальше — то зачем вообще нужна вся эта сложная инфраструктура?
Но вот неприятная правда: да, это технологический сдвиг, и часть старых подходов действительно обесценивается. Однако “конец классической видеоаналитики” — миф, который возникает, когда мы путаем два разных слоя: слой вычислений и слой продукта. MLLM сегодня слишком дорогая, чтобы бесконечно “пережёвывать” весь видеопоток 24/7, а значит — она не заменит детекторы, по крайней мере в ближайшие годы. Она заменит другое: подход к интерпретации и работе с контекстом.
В этой статье я разберу, почему MLLM/VLM — действительно гейм-чейнджер, где их применять экономически разумно уже сейчас, и главное — как выстроить платформенную архитектуру так, чтобы новая волна ИИ не сожгла ваши инвестиции, а превратила их в фундамент для следующего уровня видеоаналитики.
“гейм-чейнджер” или “апгрейд мозга”?
В видеоаналитике случилось то, что обычно происходит тихо — а потом внезапно переворачивает рынок. На сцену вышли VLM/MLLM: модели, которые перестают играть в “угадай объект в рамке” и начинают делать то, чего заказчики на самом деле хотели все эти годы — понимать ситуацию. Не “каска: да/нет”, а “почему это опасно”, “что именно нарушено”, “что произошло до”, “какой риск сейчас”, “что сделать дальше”. Это уже не детекция. Это — интерпретация реальности.
И вот здесь начинается неприятный разговор. Потому что если машина умеет объяснять смысл происходящего, то возникает ощущение, что весь предыдущий пласт индустрии — десятки моделей, сценариев, правил, интеграций, витрин, расследований, целые отделы разметки и поддержки — выглядит как неуклюжая лестница, которую можно выбросить, потому что “появился лифт”. В головах многих это звучит так: “MLLM обесценит все ваши инвестиции в детекторы и внедрения”.
Но рынок сейчас раскалывается на два лагеря. Первый говорит: “Это гейм-чейнджер, старое умерло, делайте всё заново”. Второй отвечает: “Это просто новый модный слой, завтра хайп пройдёт”. Оба упрощают — и оба ошибаются.
Правильный вопрос звучит не “умнее ли MLLM детектора?”. Правильный вопрос — что именно она меняет: продукт, архитектуру и экономику владения. Потому что одно дело — когда модель может красиво рассуждать про смысл, и совсем другое — когда вы можете позволить себе держать её включенной на каждом потоке 24/7, встроить в процессы, измерить качество, обеспечить предсказуемый результат и не разориться на железе.
Чтобы ответить честно — обесценит ли это прежние инвестиции или усилит их — нужно разделить две вещи: технологическую революцию (которая уже произошла) и инженерно-экономическую реальность (которая быстро отрезвляет).
Коротко: что такое VLM/MLLM и чем они отличаются от классического CV
Классический CV: “что на кадре”
Если упростить до сути, традиционная видеоаналитика десятилетиями решала одну задачу: распознать визуальные примитивы и превратить их в понятные системе сигналы. Объект найден → рамка (bbox) → класс → вероятность → дальше правила: “если человек без каски в зоне X — тревога”. Это мощная инженерная конструкция: детекторы, классификаторы, трекинг, зоны, пороги, сценарии, алерты. Она хорошо масштабируется, дешево работает на потоке и отлично подходит для задач типа “видим/не видим”.
Но у неё есть фундаментальное ограничение: классический CV по умолчанию описывает факты пикселей, а не смысл ситуации. Он говорит: “человек”, “каска”, “ограждение”. Но ему трудно ответить на вопросы, которые задает бизнес: “это нарушение или допустимая работа?”, “почему это опасно?”, “что было причиной?”, “какой контекст у действия?”.
VLM/MLLM: “что это значит”
Visual Language Model (VLM) и Multimodal LLM (MLLM) добавляют в компьютерное зрение то, чего ему всегда не хватало: языковую семантику и причинно-следственную интерпретацию. Они умеют связывать объекты и признаки в сцену и объяснять её человеческими категориями: “проход перекрыт”, “объект за ограждением”, “человек выполняет работу и поэтому поза/инструмент нормальны”, “видны признаки того, что зона давно не убиралась”. Это не магия и не “вместо детектора”, это другой уровень абстракции: объекты → отношения → ситуация → вывод.
И именно поэтому вокруг MLLM столько шума: она меняет не только точность распознавания, а тип ответа, который вы получаете от системы. Вместо “сработало правило №17” появляется “объяснение” — а значит, можно строить новые продукты: анализ архива, аудит, рекомендации, обучение, разбор инцидентов, предиктивные гипотезы.
Почему видео сложнее изображения: темпоральность и “что изменилось”
Темпоральные задачи: событие, изменение, состояние
С изображением всё относительно честно: у нас есть один кадр, и мы пытаемся понять, что на нём происходит. Но видео — это не “много картинок”. Видео — это время, а значит появляются сущности, которых в статике просто нет:
- Событие: “человек вошёл”, “техника проехала”, “что-то упало”, “кто-то пересёк границу”.
- Изменение: “появилось препятствие”, “стало грязнее”, “объект исчез”, “зона перестала быть свободной”.
- Состояние: “проход перекрыт уже 20 минут”, “снег не убирали сутки”, “ворота открыты слишком долго”, “в опасной зоне находится человек дольше нормы”.
И вот тут классическая видеоаналитика часто начинает походить на сборку мебели без инструкции: мы пытаемся из детекторов и правил “слепить” время. Трекинг, буферы, окна, пороги, дедупликация, ручная логика “если N раз подряд — считать состоянием”. Это работает, но становится хрупким и дорогим в разработке: малейшая вариативность сцены — и правила начинают либо пропускать, либо шуметь.
MLLM/VLM в этой точке выглядит как эволюционный скачок: вместо бесконечного ручного кодинга переходов “было/стало” появляется возможность сказать системе человеческим языком: “посмотри, что изменилось”, “это состояние сохраняется?”, “похоже ли это на накопление мусора?”, “снег убран или нет?”, “почему это выглядит опасно?”.
“Что изменилось” как новый тип запроса к видеоархиву
Самая недооценённая часть революции — это не онлайн-детекция. Это работа с архивом. До MLLM видеоархив чаще всего был кладбищем терабайтов: “есть записи — если что, найдём вручную”. Максимум — фильтрация по событиям детектора.
Теперь появляется новый, почти “человеческий” способ взаимодействия с видеоданными: запросы смыслом, а не правилами.
Не “покажи все кадры, где bbox каски < threshold”, а:
- “Что изменилось в этой зоне за неделю?”
- “Когда проход стал перекрыт и как долго это длилось?”
- “Есть ли признаки, что уборка не проводилась?”
- “Появлялись ли новые препятствия/разливы/скопления?”
То есть видеоархив превращается из “хранилища доказательств” в источник аналитики — и именно здесь MLLM/VLM дает эффект, который заказчики обычно называют “магией”: система начинает отвечать на вопросы, которые раньше требовали человека с опытом и временем.
И вот на этом месте возникает соблазн сделать радикальный вывод: раз модель умеет понимать время и изменения, значит классические детекторы больше не нужны — пусть MLLM смотрит всё и всегда.
Экономика и производительность: почему MLLM не может анализировать весь поток
MLLM дорогая по вычислениям и контексту, особенно на видео
Вот момент, где любой “всё, старое умерло” разбивается о реальность. Да, MLLM/VLM умеет рассуждать о сцене, понимать контекст и даже ловить изменения во времени. Но у неё есть изъян, который нельзя заигнорировать никакими маркетинговыми слайдами: она прожорлива.
Видео — это не один кадр. Это поток кадров. А значит, чтобы модель “понимала” происходящее, ей нужно либо:
- смотреть много кадров (и держать их в контексте), либо
- смотреть короткие клипы и регулярно повторять анализ, либо
- постоянно пересчитывать состояние и изменения.
В любом варианте цена вопроса растёт на порядок по сравнению с классическими детекторами. И тут мы упираемся не в “можно/нельзя”, а в “сколько это будет стоить на объекте, где сотни камер”. В большинстве реальных внедрений ответ неприятный: анализировать весь поток MLLM’кой 24/7 — экономически бессмысленно.
Реалистичный режим сегодня: редкое семплирование или короткие клипы
Поэтому в проде побеждает не “идеальная философия”, а прагматика. Реалистичный сценарий внедрения сегодня выглядит так:
- семплирование: один кадр раз в десятки секунд или минуты;
- либо короткий клип по триггеру (например, 2–6 секунд до/после события);
- плюс строгие ограничения по объёму контекста, чтобы модель не “съедала” железо и задержки.
И это не слабость технологии — это этап зрелости. Модели ускоряются, квантизуются, оптимизируются, но физику и экономику эксплуатации на больших объектах пока никто не отменил.
Следствие: MLLM идеальна для “длительных состояний” и пост-аналитики, но не для 24/7 на каждом кадре
Из этого следует важный, почти “антихайповый” вывод: MLLM сегодня сильнее всего там, где не нужно смотреть каждую миллисекунду.
Она отлично решает задачи, где важен смысл и контекст, но достаточно наблюдать “пульс” раз в N секунд/минут:
- захламление территории, рост мусора, “стало грязнее”;
- контроль уборки снега/наледи по зонам;
- длительная блокировка проходов/выходов;
- ворота/шлагбаум “слишком долго открыты”;
- разливы/лужи, которые появляются и увеличиваются;
- “опасное состояние сохраняется долго”: человек в опасной зоне, техника стоит в запрещённом месте, ограждение/люк оставлены открытыми.
А ещё сильнее она в пост-аналитике: разбор архива, поиск “когда началось”, “что изменилось”, “какие зоны деградируют”, “почему инциденты повторяются”. Там ценность MLLM максимальна, потому что она превращает терабайты видео в объяснимую аналитику, а не просто в “записи на всякий случай”.
И вот здесь становится понятно: разговор “MLLM заменит детекторы” — это не прогноз, а фантазия. Детекторы дешевле, быстрее и всегда будут нужны как базовый слой мониторинга и триггера. А MLLM — как интеллектуальный уровень, который включается там, где дорого, сложно или бессмысленно пытаться решать задачу только детекторами и правилами.
Главный паттерн ближайших лет: “детекторы → триггер → MLLM”
Если отложить хайп и посмотреть на то, как это будет работать в промышленности, становится ясно: победит не “всё заменить одной моделью”, а архитектура, которая умеет считать деньги. И эта архитектура почти всегда будет выглядеть одинаково:
детекторы → триггер → MLLM.
Детекторы: дешёвые и быстрые “датчики событий”
Классические нейросетевые детекторы — это не “устаревшая технология”, а инженерная основа масштабируемости. Они:
- работают быстро и предсказуемо,
- стоят дешево в пересчёте на поток/камеру,
- легко параллелятся,
- дают понятный сигнал: “что-то произошло” или “что-то похоже на нарушение”.
В реальных проектах детектор — это датчик, который держит “пульс объекта” 24/7. Он может быть не идеальным, но он дешево покрывает весь периметр.
MLLM: дорогой, но умный “интерпретатор и верификатор”
MLLM — это не датчик. Это эксперт, которого вы зовёте на место, когда “что-то непонятно” или “ставка высокая”. Она умеет:
- понять контекст (почему это вообще нарушение / не нарушение),
- связать объекты и отношения (“перекрыт проход”, “опасная зона”, “за ограждением”),
- объяснить вывод человеческим языком,
- и, что важно для бизнеса, верифицировать событие, снижая ложные тревоги.
Но у эксперта есть цена: вычисления, задержки, контекст. Поэтому MLLM нельзя и не нужно держать включенной постоянно. Её нужно включать умно — и именно это и есть “секрет” эффективной видеоаналитики ближайших лет.
Режимы включения MLLM (гейтинг по стоимости)
Вот четыре практичных режима, которые превращают MLLM из дорогой игрушки в промышленный инструмент:
- По тревоге детектора
Детектор сработал → MLLM смотрит один кадр/короткий клип → подтверждает или опровергает → добавляет контекст и объяснение.
Смысл: тратить “дорогой интеллект” только там, где что-то действительно произошло.
- По низкой уверенности
Детектор “сомневается” (низкий score, спорный угол/освещение) → MLLM выступает арбитром.
Смысл: точечно повышать качество там, где обычные пороги превращают систему в генератор шума.
- По конфликту детекторов
Один модуль говорит “нарушение”, другой говорит “норма” (или “каска есть”, но “человек в опасной зоне без допуска”, или “техника стоит”, но “в зоне работы”).
→ MLLM объединяет сигналы и сцену в единый вывод.
Смысл: убрать “споры моделей” и вернуть системе целостность.
- По длительному состоянию (N раз подряд)
Детектор не пытается доказать “смысл”, он лишь фиксирует устойчивый паттерн: состояние сохраняется 5–10–20 минут.
→ MLLM подключается и отвечает на главный вопрос: “что это за состояние и почему оно важно?”.
Смысл: идеальная пара для задач типа “захламление”, “проход перекрыт”, “ворота открыты слишком долго”, “уборка не выполнена”.
В результате получается простая, но мощная конструкция: детекторы обеспечивают масштаб и экономику, а MLLM обеспечивает смысл, контекст и доверие к результату. И это главное: рынок в итоге платит не за “нейросеть”, а за снижение ложных тревог, объяснимость и управляемые процессы.
Где MLLM/VLM реально сильны: контекст, объяснение, семантика
Если смотреть на MLLM как на “детектор на стероидах”, вы неизбежно разочаруетесь: дорого, медленно, местами непредсказуемо. Но если смотреть на неё как на машину смысла, становится понятно, почему она вообще меняет игру. Её сила не в том, что она “находит каску лучше”, а в том, что она понимает ситуацию вокруг каски — и может объяснить это так, чтобы системе доверяли люди.
Контекст и пространственные отношения: “за ограждением”, “перекрыт проход”, “неправильное положение”
Классический CV видит мир набором объектов. MLLM/VLM видит мир как сцену: кто где находится, что чем ограничено, что с чем взаимодействует, что является причиной, а что — следствием. Именно поэтому она сильна в задачах, где важно не наличие объекта, а отношение:
- не “есть ограждение”, а “человек за ограждением / внутри запретной зоны”;
- не “есть предмет”, а “предмет перекрыл проход / перекрыл эвакуационный выход”;
- не “есть люк”, а “люк оставлен открытым / не в правильном положении”;
- не “есть техника”, а “техника стоит в неправильном месте / создает опасную конфигурацию”.
Это тот слой смысла, который детекторами обычно пытаются “достроить” вручную через десятки правил и исключений. MLLM/VLM может схватить его как целое — быстро и, главное, объяснимо.
Объяснимость: “почему это нарушение” + связь с регламентом/инструкцией
В промышленной безопасности и на производстве одной тревоги мало. Настоящий вопрос звучит так: почему это нарушение и что делать? Когда система пишет “нарушение №17”, это раздражает. Когда система пишет “опасно, потому что…” и ссылается на понятную логику, это меняет отношение.
MLLM здесь выступает как “переводчик” между пикселями и процессом:
- добавляет объяснение причин риска;
- может подтянуть контекст из регламента/инструкции и связать наблюдение с правилом;
- помогает делать карточки инцидента “самодостаточными”: кадр/клип + вывод + аргументы.
И это не просто UX. Это про внедряемость: объяснимые инциденты быстрее закрываются, меньше спорят, проще обучать персонал, легче проходить аудит.
Снижение false positives через “понимание ситуации”
Самый дорогой враг видеоаналитики — не пропуски, а ложные тревоги, которые превращают систему в шум. Ирония в том, что классический CV часто ошибается не потому, что “плохо видит”, а потому что “не понимает контекст”.
MLLM/VLM снижает FP там, где важно различить:
- нарушение vs допустимое действие в рамках процесса (“так можно, потому что сейчас выполняется операция”);
- “похоже на каску” vs “это предмет похожий на каску”;
- “человек наклонился” vs “человек выполняет работу”, и т.д.
То есть она работает как второй наблюдатель, который не просто подтверждает детекцию, а проверяет её смысловую состоятельность. В проде это часто даёт эффект сильнее, чем попытки бесконечно “доточить детектор”.
Классы задач “длительного характера”: примеры, которые масштабируются экономически
Вот где заканчиваются презентации и начинается реальная эксплуатация. Если MLLM/VLM сегодня включать на каждый кадр — вы либо разоритесь, либо упрётесь в инфраструктуру. А если включать её умно — на редком семплировании, по триггеру и для анализа состояния — вы получаете максимальную отдачу на каждый “дорогой” вызов модели.
Общий принцип простой: MLLM выгодна там, где событие длится долго, а не вспыхивает на миллисекунды. Потому что для таких задач не нужно смотреть непрерывный поток — достаточно регулярно “снимать температуру” и отвечать на вопрос: состояние сохраняется? меняется? ухудшается?
Чистота / инфраструктура
Это класс “что стало с территорией” — идеальный для редкого анализа, потому что изменения заметны на горизонте минут/часов, а не секунд.
- Захламление, мусор, рост количества предметов в зоне: “стало хуже”, “появились новые препятствия”, “нарушено требование по чистоте/проходимости”.
- Лужи / разливы / утечки: появление и расширение пятна, отслеживание динамики (“увеличивается/стабильно/исчезло”).
- Наледь / снег: контроль уборки по зонам, сравнение “до/после”, фиксация невыполненных работ.
- Открытые люки, двери, ограждения: состояние “должно быть закрыто”, контроль “оставлено открытым слишком долго”.
- Деградация состояния: “зона системно ухудшается” — грязь, пыль, накопления, препятствия. Это уже не тревога, а тренд, который можно показать руководителю.
Почему это работает: MLLM не обязана ловить точный момент появления мусора. Ей достаточно честно ответить: “есть признаки захламления / ухудшения” и подтвердить длительность состояния.
Склад / логистика
Тут ценность в том, что бизнесу важен не “объект”, а проходимость, порядок, доступность и соблюдение норм хранения.
- Блокировка проходов / выходов: “проход перекрыт” → “сколько длится” → “какая критичность (эвакуация/пожарный проезд)”.
- Переполнение зон хранения / неправильные штабеля: устойчивое состояние “слишком плотная загрузка”, “опасная конфигурация”, “нарушены расстояния”.
- Забытые предметы / оборудование: “оставлено в зоне”, “лежит/стоит слишком долго”, “мешает движению или создает риск”.
- Длительные очереди / скопления: не мгновенная “толпа”, а именно устойчивое превышение порога по времени (“стоит 20 минут”).
Здесь MLLM хороша тем, что умеет превращать визуальную картину в управленческий вывод: “узкое место”, “перегрузка”, “барьер”, а не просто “много людей”.
Безопасность / режим
Этот класс — про контроль устойчивого нарушения или подозрительного состояния, когда важен фактор времени.
- Длительное нахождение в опасной зоне: “человек в зоне риска слишком долго” — а не просто “человек попал в кадр”.
- Ворота / шлагбаум ‘слишком долго открыты’: состояние, которое само по себе является нарушением режима или индикатором нештатности.
- Подозрительные объекты ‘стоят долго’: оставленные предметы, транспорт, “нехарактерное присутствие”, которое имеет смысл только при длительности.
В этих задачах семплирование решает экономику: модель не “смотрит поток”, она проверяет состояние и длительность.
Эксплуатация / аудит
Самый недооценённый класс — когда видео становится инструментом контроля качества работ и подготовки доказательной базы.
- “Работа проведена / не проведена”: уборка, обслуживание, проверка состояния, закрытие зон — оценка по визуальным признакам.
- Тренды ухудшения по зоне: накопление проблем, повторяемость инцидентов, “зоны хронического риска”.
- Пост-аналитика архива: “когда началось”, “что изменилось”, “почему повторяется” — видео перестаёт быть просто записью и становится аналитическим источником.
Это именно та точка, где MLLM/VLM превращает “террабайты видео” в управляемые выводы, которые можно включать в отчёты, планы работ и аудит.
Как превратить “умный текст” в надежный производственный компонент
Самый быстрый способ похоронить MLLM в корпоративном внедрении — это оставить её в режиме “поболтать с видео”. На демо это выглядит впечатляюще: модель пишет умные абзацы, рассуждает, объясняет. А в промышленной системе это превращается в хаос: сегодня она формулирует так, завтра иначе; один инженер понимает ответ, другой — нет; интеграция ломается от лишней запятой; аудит спрашивает “где критерии?”, а вы показываете скриншоты.
Если коротко: свободный текст — плохой интерфейс для производственной системы.
Проблема: свободный текст плохо интегрируется и плохо тестируется
В классическом CV всё просто: есть bbox, класс, score, timestamp. Это можно логировать, сравнивать, строить метрики, заводить регрессионные тесты, делать алерты по отклонениям.
В MLLM “по умолчанию” другой мир:
- ответы многословны и вариативны,
- формулировки плавают,
- в одном месте модель “уверена”, в другом осторожничает,
- один и тот же кейс может описываться разными словами.
И самое опасное: вы не можете нормально тестировать текст так, как тестируете детектор. В проде это означает одно — доверие к системе падает, потому что поведение непредсказуемо.
Решение: структурированный вывод (JSON-схемы + валидация)
Чтобы MLLM стала индустриальным модулем, её нужно лишить “романтики” и дать ей строгую роль: выдавать структурированное решение.
Практический рецепт выглядит так:
- JSON schema для каждого сценария
Например:
- event_type (захламление / блокировка прохода / открытый люк / уборка не выполнена)
- severity (низкая/средняя/высокая)
- confidence
- evidence (кадры/временные отметки/клип)
- reason_codes (короткие стандартизированные причины)
- recommended_action (предложенное действие)
- Schema validator на выходе
Ответ не прошёл валидацию → либо повторный запрос, либо fallback (например, запросить уточнение, либо отправить человеку на разбор). Это превращает MLLM из “ораторской модели” в детерминированный API, который можно интегрировать и поддерживать.
- Логирование и трассировка
Сохраняется: вход (кадр/клип/контекст), версия модели, промпт/шаблон, валидированный JSON, тайминги. Это база для качества, расследований и комплаенса.
- Стабилизация ответов
Температура/настройки генерации, фиксированные шаблоны, “reason codes” вместо поэзии — всё, что делает систему повторяемой.
Так MLLM перестаёт быть чат-ботом и становится тем, чем должна быть в видеоаналитике: компонентом принятия решений, встроенным в процесс.
Human-in-the-loop: спорные случаи + источник данных для улучшений
Идеальная картинка “ИИ всё решает сам” заканчивается на первом же споре с производством: “это нарушение или технологическая операция?”, “это мусор или материал?”, “это опасно или допустимо?”.
Поэтому второй обязательный элемент — human-in-the-loop:
- всё, что ниже порога уверенности, идёт на подтверждение;
- всё, что конфликтует с сигналами детекторов или правилами, идёт на разбор;
- всё, что важно по риску (высокая критичность), может требовать подтверждения автоматически.
И главное: каждое подтверждение/опровержение человеком — это не просто “ручная работа”, а разметка нового поколения: пары “вход → правильный JSON-ответ”. Это то топливо, которое потом позволяет:
- улучшать промпты и схемы,
- собирать датасет,
- переходить к fine-tuning на ваших реальных сценах и регламентах.
RAG vs fine-tuning в визуальных задачах: где часто ошибаются
Когда команды впервые пробуют “подружить” MLLM с производством, почти всегда возникает соблазн: давайте просто добавим RAG — подкинем модели инструкции, примеры, пару картинок, и она начнёт отвечать правильно. На текстовых задачах это часто работает. На визуальных — это место, где многие теряют месяцы.
Ловушка визуального RAG: модель может путать “пример” и “целевой кейс”
Визуальный RAG (особенно когда вы кладёте в контекст “похожие изображения”, примеры нарушений, эталоны) опасен тем, что модель начинает вести себя не как строгий классификатор, а как рассказчик. Она может:
- “переносить” детали из примера на текущий кадр,
- уверенно описывать то, чего на сцене нет,
- спутать: это эталон в контексте или это то, что она должна анализировать сейчас.
В итоге вы получаете парадокс: чем больше вы “помогаете” примерами, тем больше модель рискует галлюцинировать и подгонять вывод под то, что увидела в контексте. Для промышленной видеоаналитики это яд: доверие падает, потому что система начинает “додумывать”.
Практический вывод простой: RAG хорошо работает как источник текста (регламенты, определения, пороги, списки), но с визуальными примерами нужно быть крайне аккуратным — и чаще всего держать их не в контексте ответа, а в данных для обучения/валидации.
Когда лучше дообучение: узкие паттерны, специфическая среда, повторяющиеся ошибки
Есть класс задач, где “промптами и RAG” вы не победите. Это задачи, где правильность решения завязана на:
- конкретный объект/среду (ваши камеры, углы, освещение, загрязнение линз, спецодежда, типы техники),
- узкие паттерны (как именно выглядит “неубрано” на вашей площадке, как выглядит “перекрыт проход” в ваших коридорах, как выглядит “правильное положение” люка/ограждения),
- повторяющиеся ошибки модели (одно и то же неверное толкование сценария на десятках объектов).
В таких случаях правильный путь — fine-tuning (часто достаточно лёгких подходов вроде адаптеров/LoRA), потому что вы не хотите каждый раз “уговаривать” модель промптом. Вы хотите, чтобы она стала устойчивой на вашем домене.
Правило “из практики”:
- если ошибка редкая и логическая — лечится промптом/схемой/валидацией;
- если ошибка системная и визуальная — лечится данными и дообучением.
Контур улучшения: сбор данных → fine-tuning → деплой → мониторинг
Чтобы MLLM не осталась “демо-магией”, нужна не магия, а конвейер — как в классическом ML, только с мультимодальностью.
- Сбор данных
Всё начинается с “боевых” кейсов: спорные тревоги, конфликт детекторов, инциденты с разбором. Плюс обязательная фиксация контекста: зона, тип объекта, регламент, “что было правильным ответом”.
- Подготовка датасета “вход → выход”
Вход: кадр/клип + минимально необходимый контекст.
Выход: ваш валидированный JSON по схеме (из раздела 8). Это ключ: вы обучаете не “болтовню”, а структурированное решение.
- Fine-tuning
Маленькие итерации на конкретных сценариях дают больше пользы, чем попытка “натянуть” одну универсальную модель на всё сразу.
- Деплой с версиями и A/B
Версионирование, контроль регрессий, откат. Иначе вы не поймёте, стало лучше или просто “по-другому”.
- Мониторинг и непрерывное улучшение
Логируете не только события, но и качество: где модель сомневалась, где человек не согласился, где выросли FP/FN. Это и есть топливо для следующей итерации.
И вот после этого — когда у вас есть инженерный контур и управляемое качество — можно возвращаться к главному страху рынка.
Почему “обесценивания инвестиций” можно избежать: платформа как страховка от технологических волн
Давайте скажем прямо: страх “всё, что мы построили, завтра станет мусором” — не про технологии. Он про архитектуру. И чаще всего — про отсутствие архитектуры.
Потому что обесценивание инвестиций случается не тогда, когда появляется новая модель. Оно случается тогда, когда ваша текущая система — это набор хрупких скриптов, точечных интеграций и “шаманства” вокруг нескольких детекторов, которые живут как отдельные острова. В такой конструкции любая новая технология действительно выглядит как катастрофа: её невозможно нормально подключить, не сломав всё остальное. И тогда начинается типичный цикл рынка: “перепишем всё заново”, “миграция”, “пилот”, “ещё пилот”, “бюджет закончился”.
Ошибка: воспринимать MLLM как “новую систему вместо старой”
Самая токсичная мысль в этой теме звучит красиво и разрушительно:
“MLLM — это новая система. Старое надо выкинуть.”
И вот что происходит, когда вы в это верите:
- вы пытаетесь заменить детекторы “универсальным интеллектом” (и упираетесь в стоимость/латентность);
- вы тащите MLLM в прод без стандартов, без форматов, без мониторинга (и получаете хаос);
- вы начинаете обсуждать “какую модель выбрать” вместо того, чтобы обсуждать “какую систему строим”.
Это мышление стартап-демо: на одном потоке красиво. В промышленности — самоубийство.
Правильная рамка: MLLM — новый вычислительный блок внутри единой платформы
Есть гораздо более неприятная для “продавцов чудес” правда: MLLM — это не продукт, а вычислительный модуль. Очень мощный, очень дорогой, но всё равно модуль.
И если у вас есть правильная платформа, появление MLLM должно вызывать не панику, а спокойную реакцию инженера:
“Ок, ещё один тип инференса. Ещё один блок в пайплайне.”
То есть вы не “переезжаете на MLLM”. Вы:
- добавляете MLLM как второй уровень (контекст/верификация/архив/объяснение),
- оставляете детекторы как базовый слой мониторинга,
- включаете MLLM по триггерам и экономике (как мы обсуждали).
И вот здесь происходит магия — но не технологическая, а управленческая: вы перестаёте бояться волн. Потому что каждая новая модель — это не “разрушитель ваших инвестиций”, а “ещё один сменный двигатель”, который вы можете поставить в уже существующую машину.
Платформа удерживает ценность: данные, архив, процессы, интеграции, сценарии
Самое смешное (и грустное) в страхе “обнуления” — люди думают, что их инвестиции были в модели. Нет. Их инвестиции были в то, что обычно никто не любит обсуждать на презентациях:
- Данные и видеоархив: подключение камер, хранение, доступ, метаданные, история событий.
- Процессы: кто реагирует, как расследуется, как закрывается инцидент, как строятся отчёты.
- Интеграции: ERP/BI/SCADA/Service Desk/уведомления/мобильные клиенты.
- Сценарии: правила, зоны, политика эскалации, дедупликация, роли.
- Управление жизненным циклом: версии, тесты, мониторинг качества, откат.
И это всё не “устаревает” от появления MLLM. Наоборот — становится ещё ценнее, потому что MLLM наконец может работать с этими слоями как с контекстом и производить результат, который бизнес понимает: объяснение, связь с регламентом, аналитика по трендам.
Поэтому правильный вывод провокационно прост:
если ваши инвестиции “сгорают” от появления новой модели — значит, вы инвестировали не в систему, а в набор разрозненных фич.
Референс-архитектура платформы видеоаналитики (вендорно-нейтрально)
Сейчас будет неприятно — но полезно.
Если у вас сегодня “система видеонаблюдения + несколько разрозненных модулей видеоаналитики” (где-то детектор каски, где-то распознавание номеров, где-то отдельная коробка под периметр) — это не стратегия. Это зоопарк. И он работает ровно до тех пор, пока:
- камер мало,
- сценариев мало,
- люди помнят, где что лежит,
- а стоимость поддержки ещё не взлетела.
Потом начинается классика: каждая новая задача требует нового модуля, каждая интеграция делается заново, отчёты разъезжаются, инциденты живут в разных системах, а “единая картина риска” превращается в серию скриншотов на совещании.
MLLM/VLM просто подсвечивает эту проблему прожектором. Потому что “новый интеллект” нельзя нормально внедрить в хаос. Он либо утонет в интеграциях, либо будет работать как отдельная игрушка “для пилота”. Поэтому если вы всерьёз хотите использовать MLLM — первый вопрос не “какую модель взять”, а есть ли у вас единая платформа, где ваши текущие решения — компоненты.
Ниже — референс-архитектура такой платформы. Вендорно-нейтрально, но по-взрослому: как должна выглядеть система, которая переживёт не только MLLM, но и следующую технологическую волну.
Ingest / медиа-слой: камеры, регистраторы, тепловизоры, аудио, архивы
Это фундамент, который обычно недооценивают. Пока всё маленькое — кажется, что “ну подключили камеру и поехали”. А потом выясняется, что камеры разные, протоколы разные, архивы разные, доступы разные, и половину времени команда тратит не на ИИ, а на борьбу с видео.
Платформа должна уметь:
- подключать потоки и записи из разных источников,
- нормализовать их,
- обеспечивать управление доступом,
- давать стабильный API к медиа — чтобы сверху можно было строить аналитику, не переписывая интеграции каждый раз.
Интеллектуальный архив: видео + метаданные + события + результаты моделей
Если ваш архив — это “террабайты записей на случай расследования”, вы теряете 80% ценности. Современная видеоаналитика требует архива другого типа: видео плюс смысловая разметка.
Интеллектуальный архив хранит:
- ссылки на фрагменты (evidence clips),
- таймлайны событий,
- метаданные зон/камер/объектов,
- результаты детекторов и MLLM (в структурированном виде),
- контекст (регламент, смена, операция, тип зоны).
Это то, что превращает “видео” в “данные” — и делает возможной аналитику, аудит и поиск “что изменилось”.
Слой инференса: оркестрация детекторов/OCR/иных моделей + планировщик вычислений
Вот место, где умирают “зоопарки модулей”. Потому что без оркестрации вы получаете:
- разные форматы входов/выходов,
- разный деплой,
- разные политики обновления,
- и ад на поддержке.
Платформа должна быть “операционной системой” для инференса:
- запускать детекторы разных производителей и типов (CV, OCR, аудио),
- маршрутизировать потоки/фрагменты на нужные модели,
- балансировать ресурсы (edge/on-prem/cloud),
- включать “дорогие” модели по триггерам и экономике, а не постоянно.
Слой MLLM/VLM: контекстная интерпретация, темпоральные проверки, объяснение
MLLM — это не “новый детектор”, а интерпретатор над результатами и над видео/контекстом.
Платформенный слой MLLM должен уметь:
- принимать кадр/клип + результаты детекторов + метаданные сцены,
- делать темпоральные проверки (“состояние длится N минут”, “что изменилось”),
- выдавать объяснение и рекомендации,
- возвращать структурированный результат (JSON), чтобы это можно было интегрировать и тестировать.
Сценарии: визуальная сборка пайплайнов из блоков (детектор → условия → MLLM → действие)
Если сценарии пишутся “в коде” и живут в головах пары инженеров — это не масштабируется. Завтра уйдут люди — и уйдёт система.
Поэтому современная платформа должна давать:
- визуальный/low-code редактор сценариев,
- библиотеку блоков (“детектор”, “условие”, “таймер/состояние”, “MLLM-верификация”, “нотификация”, “создание инцидента”),
- версии сценариев и тестирование на исторических данных.
Это то, что делает внедрение быстрым, а поддержку — управляемой.
События и интеграции: жизненный цикл инцидентов + API/уведомления/web/mobile
Система ценна не тем, что она “нашла”, а тем, что инцидент прожил жизнь:
создан → подтвержден/оспорен → назначен → устранен → закрыт → попал в отчёт.
Платформа должна включать:
- модуль управления инцидентами (статусы, ответственность, SLA, доказательная база),
- уведомления (мессенджеры/почта/мобильные),
- API для интеграций (Service Desk, ERP, BI, системы безопасности),
- единые “витрины” и отчёты, чтобы бизнес видел картину, а не набор разрозненных тревог.
Реестр моделей: версии, политики деплоя, тестирование, мониторинг, мультивендорность
И вот главный “антиобесцениватель” инвестиций: управление моделями как продуктом, а не как файлом на сервере.
Реестр моделей должен обеспечивать:
- версионирование и совместимость с сценариями,
- политики деплоя (где работает: edge/on-prem/cloud),
- A/B и контроль регрессий,
- мониторинг качества (FP/FN, споры, отклонения),
- мультивендорность: подключение и замена моделей без переписывания всей системы.
Если говорить совсем провокационно: платформа — это то, что отделяет “видеоаналитику как эксперимент” от “видеоаналитики как инфраструктуры предприятия”. И именно она позволяет превратить ваши текущие разрозненные модули в компоненты единой системы, а MLLM — в очередной сменный блок, а не в угрозу.
Мультимодальность как источник денег: видео + контекст предприятия
Вот где становится по-настоящему интересно — и одновременно неудобно для всех, кто привык продавать “видеоаналитику” как набор детекторов.
Потому что детекторы — это про нахождение объектов. А деньги обычно лежат не там. Деньги лежат там, где вы превращаете видео в управленческое решение: кто виноват, почему произошло, как предотвратить, где зона деградирует, что поменять в процессе. И вот это начинается ровно в тот момент, когда видео перестаёт быть “картинкой”, а становится частью мультимодального контекста предприятия.
Слияние данных: видео + карточки событий + журналы + инструкции/регламенты
У многих компаний видео — это отдельная вселенная: камеры живут сами по себе, журналы событий — сами по себе, регламенты — в PDF на общем диске, а расследование инцидента — в переписке и Excel. И в этом месте любые разговоры про “ИИ” выглядят как косметика.
MLLM/VLM ломает эту стену, потому что её сила — не только в картинке, а в связывании модальностей:
- видео/кадр/клип как доказательство и источник наблюдений,
- карточка события как структурированная сущность (тип, зона, смена, ответственный, статус),
- журналы/логи (доступы, операции, технологические события, датчики, сервис-деск),
- инструкции и регламенты как база “что считается нарушением и почему”.
И вот тут появляется качественно новая вещь: система начинает отвечать на вопросы не уровня “есть каска?”, а уровня “соответствует ли ситуация регламенту?”, “почему это опасно?”, “что именно нарушено?”, “какое действие требуется?”.
Самый провокационный момент: без этого слияния ваши детекторы — это просто генераторы сигналов. С мультимодальностью они превращаются в продукт, который реально влияет на деньги и риски.
Новые продукты: “аудит по архиву”, аналитика паттернов, рекомендации по зонам риска
Как только вы научились связывать видео с контекстом предприятия, внезапно появляются продукты, которых раньше не было (или они были “ручными услугами” и не масштабировались).
- Аудит по архиву как сервис/функция
Не “посмотрели 20 часов видео и нашли 3 инцидента”, а:
- “покажи все случаи блокировки эвакуационных выходов за месяц”,
- “где чаще всего нарушают порядок хранения”,
- “когда началось ухудшение по зоне и как развивалось”.
Это превращает архив из “страховки” в актив, который можно монетизировать и использовать регулярно.
- Аналитика паттернов
Самое ценное — не отдельный инцидент, а повторяемость:
- какие сценарии чаще всего происходят,
- в каких зонах,
- в какие смены,
- после каких технологических операций,
- с какими первопричинами.
То есть вместо “мы тушим пожары” появляется “мы видим, где пожары возникают системно”.
- Рекомендации по зонам риска
Это следующий уровень, который бизнес слышит лучше всего:
- “перенести разметку/ограждение”,
- “изменить маршрут/зону складирования”,
- “пересмотреть регламент уборки”,
- “переобучить персонал на конкретных типовых ситуациях”.
И да, это уже ближе к “советнику”, чем к “детектору”. Именно тут MLLM начинает приносить эффект уровня снижения потерь, а не “точность распознавания выросла на 3%”.
MLLM монетизируется не в момент распознавания, а в момент, когда вы превращаете видео в управленческое знание. И это невозможно без платформы, которая склеивает видео, события, логи и регламенты в единый контур.
Адвокат дьявола: риски MLLM/VLM и как их приземлить
Давайте без самообмана. MLLM/VLM сейчас продают как “умные глаза”, которые всё понимают и всё объясняют. На демо — да. В промышленности — это, скорее, новый источник ошибок, просто более дорогой, более убедительный и более опасный.
Провокационная правда: самая большая угроза MLLM — не то, что она ошибается, а то, что она умеет ошибаться красиво. И люди склонны ей верить.
Поэтому если вы хотите использовать MLLM в видеоаналитике, вам нужно сделать то, что обычно не любят: включить взрослый режим и заранее “обрезать” у технологии все места, где она может вас подставить.
Галлюцинации/нестабильность → схемы, валидация, тест-наборы, HIL
Первый риск очевиден, но его до сих пор недооценивают: модель может уверенно придумать то, чего нет. Не из злого умысла — так работает генеративная природа.
Если вы отдаёте в прод свободный текст — поздравляю, вы внедрили “оратора”, а не систему. В лучшем случае он будет красноречиво шуметь, в худшем — будет красноречиво обвинять людей в нарушениях.
Приземление тут скучное, но железное:
- строгие JSON-схемы для результата и причин (“reason codes”), а не эссе;
- валидатор на каждый ответ: не прошло — не улетело в процессы;
- тест-наборы и регрессия (как у классического ПО): один и тот же кейс должен давать сопоставимый результат;
- HIL (human-in-the-loop) для спорных случаев и высокой критичности: модель — не судья, а ассистент.
Провокационный вывод: видеоаналитика с MLLM без схем и тестов — это не ИИ. Это риск-менеджмент наоборот.
Стоимость/латентность → гейтинг по триггерам, семплирование, edge-оптимизации
Второй риск бьёт в бюджет и эксплуатацию. MLLM может быть сколь угодно умной, но если её включить “на всё и всегда”, вы очень быстро поймёте, что вы купили не видеоаналитику, а потребителя GPU.
Поэтому “взрослая” архитектура всегда делает одно и то же:
- гейтинг по триггерам: детектор/правила/состояние → только потом MLLM;
- семплирование: кадр раз в N секунд/минут или короткий клип, а не поток;
- edge-оптимизации и ограничения контекста: квантизация, строгие окна, контроль токенов, иначе вы утонете в задержках.
И тут полезно сказать вслух то, о чём многие молчат: MLLM не должна быть “всевидящим глазом”. Она должна быть “экспертом по вызову”.
RAG-ошибки → fine-tuning там, где нужно
Третий риск — это любимая “универсальная таблетка” рынка: “давайте прикрутим RAG”. И на визуальных задачах это место, где команды часто выжигают квартал времени.
Проблема: визуальные примеры в контексте могут вести модель в сторону. Она может путать, что является “примером”, а что — “объектом анализа”, переносить детали и уверенно подгонять вывод под контекст.
Приземление:
- RAG — да, но в первую очередь для текстового контекста (регламент, определения, критерии);
- для устойчивых визуальных паттернов — fine-tuning (часто лёгкий), иначе вы будете бесконечно “уговаривать” модель промптом;
- если ошибка повторяется — это уже не “промпт”, это данные.
Провокационный вывод: RAG — не замена обучению. Это костыль, который часто ломается первым.
Измеримость: “красиво объясняет” ≠ “правильно”
И наконец, самый опасный риск — психологический. MLLM умеет звучать убедительно. И это приводит к катастрофической подмене: команда начинает считать качество по ощущению (“ну вроде разумно объяснила”), а не по фактам.
В промышленности качество — это:
- сколько FP/FN по инцидентам,
- сколько времени экономит расследование,
- насколько снизился шум тревог,
- как изменились показатели безопасности/операций,
- насколько сократился простой/ущерб,
- как меняется риск по зонам.
То есть метрики должны быть на уровне событий и бизнес-исходов, а не на уровне “мне понравился ответ модели”. Иначе вы не внедряете ИИ — вы внедряете красивый генератор текста в критический контур.
если вы не можете измерить пользу MLLM в деньгах, рисках или времени реакции — значит, у вас нет продукта, у вас есть демонстрация.
Финал: революция в возможностях, эволюция в инженерии — и почему выигрывают платформы
Революция: смысл, темпоральность, объяснимость, “аудит как продукт”
Да, это революция — и делать вид, что “просто ещё одна модель”, уже не получится. MLLM/VLM меняют сам язык взаимодействия с видео: вместо “объектов и рамок” появляются смысл, контекст и время. Система начинает отвечать на вопросы уровня “что происходит на самом деле?”, “почему это важно?”, “что изменилось?”, “как это связано с регламентом?”. И это открывает то, о чём заказчики годами говорили как о фантастике: аудит по архиву, аналитика паттернов, рекомендации по зонам риска, обучение по реальным кейсам, доказательная база с объяснениями — не руками, а системно.
Но есть одна неудобная деталь: чтобы революция стала продуктом, а не фейерверком, нужна инфраструктура, которая выдержит нагрузку — техническую, процессную и организационную.
Эволюция: детекторы остаются, MLLM добавляется как слой
И вот здесь начинается взрослая инженерия. Самое важное, что стоит понять: MLLM не отменяет детекторы — она переносит центр тяжести. Детекторы остаются “датчиками” потока: дешёвыми, быстрыми, массовыми. MLLM становится “мозгом по вызову”: интерпретирует, проверяет, объясняет, работает с архивом и длительными состояниями.
То есть происходящее — парадоксально:
- по возможностям — революция,
- по архитектуре внедрения — эволюция.
И именно поэтому “обесценивание инвестиций” не является неизбежным. Оно неизбежно только в одном случае: если у вас нет системы, а есть набор разрозненных модулей, которые невозможно собрать в единый контур.
Главный вывод: не бойтесь новых моделей — стройте систему, в которой “новая технология” = “новый блок”
Вот честный финальный посыл, который обычно не любят, потому что он требует действий и бюджета: вам нужна единая платформа видеоаналитики. Не “ещё один модуль”, не “ещё один пилот”, не “ещё одна коробка с нейросетью”, а платформа, где:
- ваши текущие камеры, архивы и интеграции — это основа, а не зоопарк;
- ваши сегодняшние детекторы — это компоненты единого слоя инференса;
- MLLM/VLM — добавляемый модуль поверх данных, событий и процессов;
- сценарии, валидация, мониторинг и жизненный цикл моделей — управляемая система, а не шаманство.
Да, инвестиции в платформу никто не отменял. Более того — платформа стоит денег, требует дисциплины и зрелости. Но альтернатива дороже: жить в мире вечных “революций”, где каждая новая технология заставляет вас переписывать внедрения, пересобирать интеграции, пересоздавать витрины, заново объяснять бизнесу ценность и снова платить за тот же цикл.
Если говорить совсем прямолинейно: платформа — это страховка от будущего. Это способ пережить любые технологические волны без паники и без сжигания ROI. И это способ выйти победителем: не потому что вы выбрали “самую умную модель”, а потому что вы построили систему, где любая новая модель становится просто очередным блоком.
И вот вопрос, с которым я бы оставил читателя:
вы хотите каждый год “догонять революции” — или хотите однажды построить платформу, которая будет их переживать и превращать в прибыль?
