Um exemplo em Python publicado em 25 de setembro pelo desenvolvedor Allan Riordan Boll amplia uma solicitação de decisão no estilo Jev com anexos de imagem. Ele envia cada quadro da webcam a um modelo de visão, junto com perguntas curtas, e converte as probabilidades dos próximos tokens do modelo em uma resposta sim ou não, uma escolha ou uma pontuação. O exemplo é um wrapper independente, não um recurso de visão do Jev nem um teste do modelo do Jev.

O aspecto útil para desenvolvedores está no limite da técnica. Um modelo de visão pode responder a uma pergunta restrita sem escrever uma descrição, mas as probabilidades das opções retornadas dependem do prompt, das alternativas de tokens disponíveis e do modelo. A publicação oferece um padrão funcional para inspeção, não um estudo de precisão.

A grande mudança

  • O que mudou: Um desenvolvedor aplicou a imagens o formato de decisões pequenas associado ao Jev, usando modelos gerais de visão. A imagem é anexada a cada solicitação, enquanto uma resposta de uma letra transforma uma pergunta visual em um valor que o software consegue processar.
  • Por que isso importa: Desenvolvedores podem alterar por texto o critério visual e receber um resultado tipado sem criar um classificador de imagens separado para cada pergunta. O exemplo abrange pessoas e plantas visíveis, ambiente interno ou externo e luminosidade; não demonstra com que confiabilidade essas avaliações se aplicam a outras câmeras ou cenas.
  • O que acompanhar: A decisão prática é saber se o modelo e o endpoint escolhidos retornam as pontuações das alternativas de primeiro token exigidas com consistência suficiente para a tarefa. Antes de usar um resultado da webcam para acionar algo, é preciso medir conjuntamente a taxa de quadros e a qualidade das decisões em imagens representativas.

Como funciona a decisão sobre a imagem

O guia de início rápido do Jev, da TypeSafe AI documenta um state e um conjunto de questions: noul para um valor sim ou não, choice para alternativas nomeadas e score para níveis ordenados. O script de Boll usa esses nomes e acrescenta o campo attachments com uma lista de caminhos de imagens ou URLs de dados em base64. Esse campo é uma extensão dele ao objeto de solicitação; o guia de início rápido citado descreve o estado em texto e não o documenta como entrada da API do Jev.

Para cada pergunta, o script monta um prompt com opções identificadas por letras, como [A] true e [B] false. Ele pede ao modelo que responda com a melhor letra e lê o primeiro token da saída, com seu top_logprobs. Em seguida, eleva as probabilidades logarítmicas retornadas à exponencial, normaliza os pesos entre as letras listadas e os mapeia de volta para o tipo da pergunta. Um choice retorna a opção com maior peso e sua distribuição. Um noul retorna o peso de true. Um score retorna uma média ponderada dos níveis ordenados. O script rejeita uma resposta se tokens de opção omitidos ainda puderem ter peso relevante.

A imagem é fornecida com cada pergunta. O exemplo envia solicitações separadas em vez de obter todas as respostas em uma única chamada ao modelo. A implementação para OpenAI usa a Responses API com input_image, top_logprobs e message.output_text.logprobs; a implementação local com llama.cpp usa Chat Completions com um item de conteúdo image_url e probabilidades logarítmicas. O guia de imagens da OpenAI documenta URLs de dados de imagem em base64, e a referência da Responses API documenta a saída de probabilidades logarítmicas e o máximo de 20 alternativas retornadas por posição de token. A documentação do servidor do llama.cpp documenta URLs de imagem na interface de chat. Essas fontes sustentam o padrão de solicitação; não executamos o exemplo em nenhum dos dois endpoints.

O que o exemplo com webcam mede

O script captura um quadro com OpenCV, codifica-o como JPEG e faz quatro perguntas: se há uma pessoa ou planta visível, se o ambiente é interno ou externo e qual é a luminosidade. Um processo em segundo plano avalia um quadro por vez enquanto a prévia continua. A configuração de câmera usa Linux V4L2; portanto, o arquivo publicado não fornece uma configuração de webcam portátil sem adaptações. O texto do artigo diz que são três perguntas por quadro, mas o código publicado contém quatro; a contagem aqui se baseia no código.

Boll relata cerca de um quadro avaliado por segundo com um modelo Gemma 4 12B QAT servido localmente em uma RTX 3090, e cerca de 0,2 quadro por segundo usando o GPT-6 Luna hospedado. Ele sugere que conexões repetidas podem contribuir para o resultado do serviço hospedado. A publicação não apresenta uma comparação controlada de hardware, rede, tamanho da imagem, cache, precisão ou tempo de solicitação. Esses números descrevem a configuração e o código do autor, não uma classificação geral de velocidade dos modelos. A OpenAI lista o GPT-6 Luna como compatível com entrada de imagem, e as orientações para modelos dizem que o Luna é compatível com a configuração de esforço de raciocínio none usada pelo exemplo.

Para quem adaptar o script, as primeiras verificações são concretas: confirmar se o modelo aceita imagens e expõe as alternativas exigidas para o primeiro token; verificar se todas as letras de opção aparecem; e avaliar as decisões retornadas em imagens rotuladas da câmera ou do conjunto de dados pretendido. Os pesos normalizados são relativos aos tokens de letras listados. Sozinhos, não são probabilidades medidas de que uma avaliação visual esteja correta. O cookbook antigo de logprobs da OpenAI explica a ideia de probabilidades de tokens, mas está marcado como arquivado e pode conter exemplos de API desatualizados.

Este wrapper também esclarece o que um resultado tipado deixa a cargo do código da aplicação. O modelo avalia a imagem fornecida segundo o critério escrito. A aplicação escolhe os quadros, lida com pontuações ausentes e decide se algum resultado é seguro o bastante para gerar uma ação. O exemplo de Boll exibe uma tabela; não relata uma ação automatizada nem uma implantação medida.

Fontes e leituras complementares