Пример на Python, опубликованный 25 сентября разработчиком Алланом Риорданом Боллом расширяет запрос для принятия небольших решений в стиле Jev, добавляя вложения с изображениями. Он отправляет каждый кадр веб-камеры модели зрения вместе с короткими вопросами, а затем преобразует вероятности следующего токена в ответ «да/нет», вариант выбора или оценку. Это независимая обёртка, а не функция Jev для работы с изображениями или проверка модели Jev.

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

Главное изменение

  • Что изменилось: Разработчик применил к изображениям формат небольших решений, связанный с Jev, используя универсальные модели зрения. Изображение прикрепляется к каждому запросу, а односимвольный ответ превращает зрительный вопрос в значение, которое может обработать программа.
  • Почему это важно: Разработчики могут менять критерий оценки изображения в тексте и получать типизированный результат, не создавая отдельный классификатор для каждого вопроса. В этом примере рассматриваются видимые люди и растения, обстановка и яркость; он не устанавливает, насколько надёжно эти оценки переносятся на другие камеры и сцены.
  • За чем следить: Практический вопрос — возвращает ли выбранная модель и конечная точка API нужные оценки альтернативных токенов с достаточной стабильностью для задачи. Пропускную способность кадров и качество решений нужно измерять вместе на репрезентативных изображениях, прежде чем результат веб-камеры будет запускать какое-либо действие.

Как работает решение по изображению

Краткое руководство Jev от TypeSafe AI описывает state и набор типизированных questions: noul для значения «да/нет», choice для именованных альтернатив и score для упорядоченных уровней. Скрипт Болла использует эти названия и добавляет массив attachments с изображениями — путями к файлам или URL данных в формате base64. Это дополнение автора к его собственному объекту запроса; в цитируемом кратком руководстве Jev описано текстовое состояние, но не поле вложений как вход API Jev.

Для каждого вопроса скрипт формирует варианты, обозначенные буквами, например [A] true и [B] false. Модель просят ответить наиболее подходящей буквой, а скрипт считывает logprobs первого выходного токена top_logprobs. Затем он преобразует логарифмические вероятности в обычные, нормализует веса перечисленных букв и сопоставляет их с типом вопроса. Для типа choice возвращается вариант с наибольшим весом и распределение весов. Для типа noul возвращается вес варианта true. Тип score возвращает среднее значение, взвешенное по упорядоченным уровням. Скрипт отклоняет ответ, если пропущенные токены вариантов всё ещё могут иметь существенный вес.

Изображение передаётся вместе с каждым вопросом. В примере отправляются отдельные запросы, а не один общий вызов модели. В варианте OpenAI используется Responses API с input_image, top_logprobs и message.output_text.logprobs; локальный вариант на llama.cpp использует Chat Completions с image_url в элементе содержимого и логарифмическими вероятностями. Руководство OpenAI по изображениям описывает URL изображений в формате base64; в справочнике Responses API описаны вывод logprobs и максимум в 20 альтернатив для одной позиции токена. Документация сервера llama.cpp описывает URL изображений в его интерфейсе чата. Эти источники подтверждают схему запроса; мы не запускали пример ни на одном из этих двух API.

Что показывает пример с веб-камерой

Скрипт захватывает кадр через OpenCV, кодирует его в JPEG и задаёт четыре вопроса: виден ли человек или растение, находится ли сцена в помещении или на улице и насколько она яркая. Фоновый процесс анализирует по одному кадру, пока идёт предпросмотр. Настройка камеры использует Linux V4L2, поэтому опубликованный файл не является переносимой конфигурацией веб-камеры без изменений. В тексте статьи говорится о трёх вопросах на кадр, но опубликованный код содержит четыре; здесь число взято из кода.

Болл сообщает примерно о одном обработанном кадре в секунду при локальном запуске квантованной Gemma 4 12B QAT на RTX 3090 и примерно о 0,2 кадра в секунду при использовании облачной GPT-6 Luna. Автор предполагает, что на облачный результат могут влиять повторные подключения. В публикации нет контролируемого сравнения оборудования, сети, размера изображений, кэширования, точности или времени запросов. Эти цифры относятся к настройке и коду автора, а не к общему ранжированию скорости моделей. OpenAI указывает, что GPT-6 Luna принимает изображения, а в её руководстве по модели сказано, что Luna поддерживает использованную в примере настройку рассуждений none.

Разработчику, который адаптирует скрипт, стоит сначала проверить: принимает ли модель изображения и предоставляет ли нужные оценки альтернатив первого токена; присутствуют ли все буквы вариантов; затем измерить решения на размеченных изображениях с нужной камеры или набора данных. Нормализованные веса относятся к перечисленным буквенным токенам. Сами по себе они не являются измеренной вероятностью правильности зрительной оценки. В архивном руководстве OpenAI по logprobs объясняется идея вероятностей токенов, однако пример помечен как устаревший и может содержать неактуальные примеры API.

Эта обёртка также показывает, какие задачи остаются за приложением после получения типизированного результата. Модель оценивает переданное изображение по заданному критерию. Приложение выбирает кадры, обрабатывает отсутствие оценок и решает, достаточно ли безопасен результат для действия. В примере Болла выводится таблица; автоматические действия или измеренное применение в реальной системе не описаны.

Источники и дополнительная литература