Машина провела у погрузочных ворот больше времени, чем ожидалось. По журналу склада видно время прибытия и закрытия задания, но непонятно, какая часть ушла на ожидание, подготовку груза и саму погрузку. Чтобы разобраться, руководитель вручную просматривает запись камеры и сопоставляет её с событиями WMS.
Cosmos Reason 3 в составе NVIDIA Video Search and Summarization можно рассмотреть как основу помощника для такого разбора. Ниже — предлагаемая схема: из видео выделяются наблюдаемые события, строится временная шкала, а возможные причины задержки проверяются по записи и данным склада. Это проектная архитектура, а не подтверждённый результат внедрения.
Начните с одних ворот и понятных событий #
Выберите камеру, на которой различимы нужная зона, автомобиль и перемещение груза. Для пилота достаточно одного типа операции. Попытка сразу описывать все процессы склада усложнит определения и проверку результата.
До подключения модели договоритесь, что означает каждое событие. «Прибыл на территорию» и «занял ворота» могут происходить в разных местах и в разное время. «Погрузка закончилась» тоже требует определения: последнее перемещение груза, закрытие кузова или освобождение ворот — разные моменты.
Полезная первая цепочка: автомобиль занял зону, началось видимое перемещение груза, активная работа прервалась, работа возобновилась, зона освободилась. Если событие не различимо на выбранном ракурсе, его нельзя включать в обязательный автоматический результат только потому, что оно есть в регламенте склада.
Разделите модель и систему работы с видео #
Cosmos Reason 3 — семейство моделей для анализа визуального контекста. Хранение записей, получение потоков, поиск, сводки и работа с заданиями требуют отдельных компонентов. В документации NVIDIA Real-Time VLM описаны варианты Cosmos Reason 3 и способы их подключения в VSS.
В актуальных release notes VSS представлены сценарии поиска, сводок и складских операций. Наличие такого профиля помогает выбрать отправную точку, но не задаёт автоматически определения событий для ваших ворот, камер и WMS.
Для первой проверки можно работать с архивными фрагментами, на которых известен результат. Потоковая обработка добавляет вопросы непрерывной нагрузки и пропусков. Её разумно подключать после того, как качество выделения событий подтверждено на записи.
Привяжите видео к заданию склада #
Каждому фрагменту нужны идентификатор камеры, ворота, начало и конец записи, часовой пояс и сведения о возможных разрывах. Часы камеры и WMS должны быть сопоставлены. Иначе разница между временем движения в кадре и отметкой системы может оказаться обычным смещением часов.
Связь с заданием можно получить из реестра назначения ворот и интервала работы. Не обязательно начинать с распознавания номера автомобиля. Если одновременно обслуживаются несколько заданий, правило сопоставления нужно определить явно и сохранять неоднозначность для ручного разбора.
В записи события храните тип, временной интервал, ссылку на исходный фрагмент, краткое наблюдение и способ проверки. Пример формулировки: «В выбранной зоне не видно перемещения груза между двумя эпизодами активной погрузки». Это наблюдение, которое можно проверить, а не готовый вывод о причине простоя.
Стройте временную шкалу из проверяемых фрагментов #
Длинную запись удобно делить на ограниченные интервалы. Для событий у границы фрагмента нужен контекст соседнего участка: начало движения может попасть в один интервал, а его завершение — в другой. Размер фрагментов и перекрытие выбирают на собственных примерах с учётом длительности операций и возможностей системы.
При объединении результатов учитывайте пересечение интервалов. Одно и то же перемещение, найденное в двух соседних фрагментах, не должно превращаться в две операции. Итоговое событие должно сохранять ссылки на исходные участки, чтобы спорное объединение можно было проверить.
Модельному заданию лучше задавать узкий вопрос: отметить начало и окончание видимого перемещения груза у выбранных ворот, перечислить паузы и указать, где уверенного наблюдения нет. Общая просьба «объясни, почему склад работает медленно» смешает наблюдения с догадками.
Длительности вычисляйте обычным кодом по принятым временным меткам. Для интервалов с неполной записью результат должен быть помечен как неполный. Отсутствие найденного события не равнозначно отсутствию работы: система могла не получить или не распознать нужный участок.
Причина задержки обычно требует данных WMS #
Камера может показать неподвижный автомобиль, очередь у ворот или длительную паузу между перемещениями. Она не обязательно показывает готовность документов, завершение комплектации или согласование замены товара. Эти сведения нужно получать из соответствующих систем.
Сопоставьте временную шкалу с событиями склада: назначение ворот, готовность задания, завершение комплектации, разрешение отгрузки. Это позволяет сформулировать проверяемую гипотезу. Например, машина уже стояла у ворот, а подтверждение готовности груза появилось позднее начала её ожидания.
Даже совпадение по времени ещё не доказывает причинную связь. Руководитель должен видеть основание гипотезы и альтернативные объяснения. Отчёт удобнее строить из трёх частей: наблюдение на видео, сопутствующее событие системы и вопрос для проверки.
По результату разбора можно создать предметную задачу: уточнить порядок назначения ворот или проверить момент регистрации готовности груза. Автоматически менять складской регламент на основании одной модельной сводки не следует. Сначала важно убедиться, что обнаружено повторяющееся обстоятельство, а не исключение.
Измеряйте ошибки на рабочем ракурсе #
Подготовьте размеченные эпизоды с обычной погрузкой, перекрытием обзора, плохим освещением и несколькими объектами в зоне. Добавьте паузы разной природы и фрагмент с потерянной записью. Приёмка должна проверять и найденные события, и случаи, где помощник обязан признать недостаток сведений.
Отдельно оценивайте пропущенные события, ложные события и ошибку времени начала и окончания. Хорошее описание одного кадра не подтверждает точность длительности всей операции. Если важный момент регулярно закрыт кузовом, потребуется другой ракурс или другой источник события.
В release notes VSS описаны ограничения, связанные с пропусками структурированных событий и перегрузкой обработки. Для вашего проекта это означает необходимость отличать техническую полноту данных от содержательного результата. Успешный ответ сервиса сам по себе не доказывает, что все эпизоды учтены.
Как выбрать объём пилота #
Фиксируйте выбранную модель и формат весов, параметры видео, число одновременно обрабатываемых записей и задержку результата. Потребность в GPU зависит от этой конфигурации; обещать обработку всего архива на имеющемся компьютере без измерений нельзя.
Начальный результат пилота — проверяемая шкала для одного процесса и понятная доля корректно выделенных событий. Затем можно оценить время руководителя на разбор задержки, число полезных подтверждённых гипотез и повторяемость найденных причин. Количество просмотренных моделью часов видео показывает нагрузку, но не пользу для склада.
Если нужные события уже точно фиксируют датчики и WMS, видео может остаться средством выборочного объяснения спорных ситуаций. Если же часть процесса видна только на записи, модельный помощник стоит оценивать именно на этой недостающей информации.
Проверьте одну погрузочную операцию #
NetLabCS поможет определить видимые события, связать их с WMS и организовать проверку временной шкалы в пилоте видеоаналитики с искусственным интеллектом для склада. Для обсуждения разбора погрузки подготовьте схему ворот, описание событий склада и разрешённые учебные фрагменты записи — оценим, какая информация доступна камере и как принимать результат анализа.
