LLM: настройка промптов, проверка событий и сравнение кадров

Сначала задача, потом промпт#

Это общий раздел для BOX 3.2 и BOX 5.0. Используйте его независимо от практикума. Набор моделей, доступные типы промптов и расположение отдельных полей определяются установленной конфигурацией; особенности указаны в соответствующих шагах.

LLM позволяет задавать вопросы к изображениям словами: узнать состояние дороги, найти технику, проверить срабатывание или получить больше сведений о нём. Для этих задач нужны разные входные данные и разные правила обработки ответа.

Ниже пять рабочих маршрутов. Это не пять пунктов выпадающего списка: в интерфейсе есть типы «Промпт классификации», «Промпт детекции» и «Промпт верификации». Дополнительный контекст может запрашиваться через механизм верификации, а сравнение требует передачи нескольких кадров. В отдельных поставках доступен также специализированный тип «Стройготовность».

1. Создайте промпт#

Откройте «LLM → Список промптов → Добавить промпт». Дайте понятное название: например, «Сигма — состояние дороги». Выберите подключённую LLM и тип «Промпт классификации». Заполните текст задания и JSON-схему справа.

Сначала сохраните промпт без привязки к камерам. Так удобно проверить его на подготовленных изображениях. В списке видно название модели, тип, даты изменения, число камер и переключатель активности. У выключенного промпта кнопка тестирования недоступна: перед ручным тестом его нужно активировать.

Текст задания объясняет модели, что искать. JSON-схема задаёт машинный формат ответа. Они должны описывать одни и те же поля и допустимые значения. Фраза «ответь в JSON» сама по себе не гарантирует правильную структуру.

2. Классификация по расписанию: дорога и уборка снега#

Классификация отвечает на вопрос о сцене целиком: что сейчас видно на дороге? Планировщик передаёт кадр, модель выбирает состояние и объясняет выбор. Рамки каждого объекта для этой задачи не обязательны.

Для «Сигмы» зададим четыре учебных состояния: «заснежена», «идёт уборка», «очищена», «неразличимо». Это словарь нашего примера, а не встроенный справочник продукта. Если нужно отдельно хранить снежный покров и активность уборки, используйте два признака: уборка и наличие снега могут наблюдаться одновременно.

В настройке запуска связывают промпт, камеру и расписание. Интервал выбирают по задаче: учебные пять минут подходят для наблюдения за уборкой, но могут пропустить короткий эпизод. Учитывайте часовой пояс, рабочие часы и доступность источника. Точное размещение полей расписания зависит от поставки; сохранение промпта само по себе не создаёт периодический запуск.

Проверьте серию ответов с временами кадров. «Сейчас очищена» — состояние одного изображения. Вывод «дорогу убрали между 09:00 и 09:05» требует сопоставления нескольких наблюдений. Не просите модель сравнить с предыдущим кадром, если он не передан.

Опиши состояние дороги на текущем кадре.
Выбери: заснежена; идёт уборка; очищена; неразличимо.
Уборку отмечай только при видимых признаках работы.
Если дорога неразличима, не угадывай состояние.
Объясни выбор по видимым признакам.
Не сравнивай с прошлым кадром: он не передан.

3. Детекция: «Найди все экскаваторы»#

Промпт детекции нужен, когда важен каждый найденный объект и его положение. Модель возвращает координаты, по которым интерфейс рисует bounding box на исходном кадре. Такое задание отличается от классификации «есть ли на стройке техника».

Укажите искомый класс, правила для частично закрытых объектов и формат рамки. В учебном формате ответа используются четыре целых числа [min_x, min_y, max_x, max_y] в диапазоне 0…1000. Это нормализованные координаты: для кадра шириной W значение x=250 соответствует W×250/1000 пикселей. Не смешивайте их с пикселями и форматом [x, y, width, height].

Массивы bboxes и labels должны иметь одинаковую длину: каждой рамке соответствует одна метка. Если экскаваторов нет, верните два пустых массива. Не рисуйте одну общую рамку вокруг нескольких машин.

В типовой схеме детекции также требуются is_event, is_violation, primary_category, secondary_category и description. Коды категорий выбирают из перечня, предусмотренного вашей поставкой. Обнаружение экскаватора само по себе не означает нарушение: это решается условием задачи.

• Проверьте кадры с одной машиной, несколькими машинами и без экскаваторов.
• Проверьте маленький объект вдали и частичное перекрытие.
• Сверьте число рамок, метки и их положение на исходном изображении.
• Отдельно проверьте ответ на изображение с похожей техникой.

Найди все видимые экскаваторы.
Для каждого верни bbox всей машины и метку excavator.
Не включай краны, погрузчики и грузовики.
Координаты: целые 0…1000, [min_x,min_y,max_x,max_y].
Для частично закрытого объекта обведи видимую часть;
если тип техники неразличим — не угадывай.
Не добавляй несуществующие объекты. Верни JSON по схеме.

4. Верификация: модель проверяет событие вместо оператора#

Обычный детектор уже сформировал событие «человек без каски». Верификация получает его изображение и проверяет конкретный признак. Если в поставке настроено автоматическое применение результата, эту проверку выполняет LLM вместо оператора.

Выберите «Промпт верификации». Форма показывает другой формат ответа: comment и event_confirmation_status. Есть настройка «Рисовать прямоугольник события»: рамка помогает указать, кого именно нужно проверить на кадре с несколькими людьми. Это рамка исходного события, а не новая детекция LLM.

В задании опишите критерий: каска отсутствует у выделенного человека, только если его голова действительно различима. Каска у соседа, закрытая голова или предмет в руке не отвечают на этот вопрос. Комментарий должен объяснять наблюдение.

Допустимые значения event_confirmation_status берите из схемы и настроек установленной версии. Не подставляйте вместо них значения is_violation: у этих режимов разные форматы ответа. Перед включением автоматического решения проверьте, как ответ меняет статус исходного события и что сохраняется в истории.

• Подтверждаемое событие: признак нарушения хорошо виден.
• Ложное срабатывание: нужный предмет защиты присутствует.
• Недостаточно данных: голова закрыта или слишком мала.
• Техническая ошибка: ответ не получен либо не прошёл обработку.

5. Дополнительный контекст: какая марка автомобиля?#

На КПП детектор обнаружил автомобиль. «Сигме» нужно дополнить карточку маркой и видимыми признаками машины. Событие отправляется через механизм верификации, но задача модели здесь — описать объект, а не повторно решать, существует ли автомобиль.

Промпт должен явно ограничить объект: «Определи марку автомобиля, выделенного рамкой». Попросите опираться на читаемый шильдик или достаточно характерные видимые признаки, отдельно обозначать предположение и отвечать «не удалось определить», если изображения недостаточно. Не требуйте назвать модель и год выпуска любой ценой.

Пояснение и статус события — разные результаты. Для такого маршрута настройте обработку ответа так, чтобы дополнительный комментарий не отменял и не подтверждал событие вопреки назначению задачи. Если обработчик обязательно применяет event_confirmation_status, сначала установите предусмотренный правилами обработки способ для сохранения исходного решения; произвольный код «без изменений» может не поддерживаться.

Простой комментарий через верификацию и отдельный расширенный процесс «Контекст» с тегами, нормативными источниками и рекомендациями — разные уровни возможностей. Наличие первого не означает, что весь расширенный процесс включён в поставку.

Рассмотри автомобиль, выделенный рамкой события.
Укажи его марку и видимые признаки, на которых основан ответ.
Если марка неразличима, напиши «не удалось определить».
Не оценивай нарушение и не делай выводов о владельце.
Результат нужен как дополнительный контекст к событию.

6. Несколько кадров: сдвиг камеры и оставленные предметы#

При сравнении модель должна получить сами изображения, а не только просьбу «сравни с прошлым». В форме тестирования промпта детекции есть «Текущий кадр» и кнопка «+ Добавить кадр», которая добавляет «Предыдущий кадр». В форме классификации этой кнопки нет. Тип выбирают при создании: в сохранённом промпте это поле недоступно для изменения. Явно укажите в задании роль каждого изображения, его время и интервал; не полагайтесь только на порядок загрузки. Автоматический подбор опорных кадров проверяется отдельно в настройке решения.

Для контроля сдвига камеры попросите сравнить неподвижные ориентиры: углы зданий, столбы, разметку. Движение машины, тень или снег не равны изменению направления камеры. Если изменился масштаб, наклон или поле зрения, это нужно описать отдельно. Точный угол в градусах требует калибровки; обычное текстовое сравнение его не гарантирует.

Для оставленного предмета сначала спрашиваем, какой объект появился и где он находится. Далее проверяем сохранение на последовательных кадрах и длительность по временам наблюдений. Одна пара кадров показывает изменение сцены; она не доказывает, что предмет бесхозный, и не устанавливает непрерывное присутствие между снимками.

В тестовый набор включите неизменную сцену, смену освещения, движение людей, частичное перекрытие, появление предмета и реальное изменение ракурса. Проверьте, не перепутала ли модель порядок «до» и «после».

Переданы кадры одной камеры:
текущий — 08:01:17; предыдущий — 08:00:17.
Интервал 60 секунд. Сопоставь их по временным меткам.
Опиши различия по неподвижным ориентирам.
Отдельно перечисли появившиеся и исчезнувшие предметы.
Отдели изменение ракурса от движения объектов и освещения.
Если сопоставить кадры нельзя, объясни почему.
Не называй предмет оставленным только по факту появления.

7. Проверяем ответ, а не только запуск#

В списке промптов нажмите «Протестировать», загрузите исходный кадр и запустите обработку. Для сравнения добавьте остальные кадры до запуска. По завершении откройте результат и историю ответов. Сопоставьте исходное изображение, сырой ответ модели и то, что система из него сохранила.

Сначала проверяем технический успех: запрос завершён, ответ разобран, обязательные поля присутствуют, значения допустимы. Затем смысловой: модель описывает именно видимые объекты, рамки стоят правильно, решение соответствует заданию. Корректный JSON может содержать ошибочное наблюдение, а хороший текст — не пройти машинную обработку.

Для сравнения версий сохраняйте один и тот же набор кадров и ожидаемые результаты. Меняйте по одному условию: модель, промпт или схему. Записывайте длительность, долю технических ошибок, ложные подтверждения и случаи, где данных недостаточно.

8. «Ошибка обработки» не всегда означает недоступность LLM#

Если ответ модели виден, запрос мог дойти до LLM, а ошибка возникла позже — при разборе JSON, проверке схемы или сохранении. Если ответа нет, проверяйте доступность модели, очередь, тайм-аут и входные файлы. По одной общей надписи причину определить нельзя.

В учебном тесте причина установлена по деталям ошибки: обработчик отклонил значения primary_category и secondary_category. Ответ модели и JSON были получены, но коды из шаблона не входили в действующий справочник категорий. Исправлять нужно согласованно текст задания и JSON-схему, затем повторять запрос на тех же кадрах.

Для автоматической верификации заранее определите судьбу события при сбое: повторить запрос, оставить без решения или передать оператору. Это правило обработки ошибок конкретной конфигурации, а не универсальное поведение всех версий. Ошибка и ответ «признак неразличим» не должны трактоваться как подтверждение нарушения.

Для классификации сохраняйте время последнего успешного наблюдения. Старый ответ «дорога очищена» не описывает состояние после нового снегопада. Для контекста не подменяйте пустой ответ вымышленной маркой, а для сравнения не сравнивайте случайные кадры разных камер.