Un ejemplo de Python publicado el 25 de septiembre por el desarrollador Allan Riordan Boll amplía una solicitud de decisión al estilo de Jev para incluir imágenes adjuntas. Envía cada fotograma de la cámara web a un modelo de visión junto con preguntas breves y luego convierte las probabilidades de los siguientes tokens del modelo en un valor de sí o no, una opción o una puntuación. El ejemplo es una capa independiente, no una función de visión de Jev ni una prueba del modelo de Jev.
Lo útil para los desarrolladores es entender los límites de la técnica. Un modelo de visión puede responder a una pregunta acotada sin redactar una descripción, pero las probabilidades de las opciones devueltas dependen del prompt, de las alternativas de tokens disponibles y del modelo. La publicación ofrece un patrón funcional que se puede examinar, no un estudio de precisión.
El gran cambio
- Qué cambió: Un desarrollador aplicó a imágenes el formato de decisiones breves asociado con Jev, usando modelos de visión de propósito general. La imagen se adjunta a cada solicitud y una respuesta de una letra convierte una pregunta visual en un valor que el software puede procesar.
- Por qué importa: Los desarrolladores pueden cambiar por escrito el criterio visual y recibir un resultado tipado sin crear un clasificador de imágenes independiente para cada pregunta. Este ejemplo abarca la presencia visible de personas o plantas, el tipo de entorno y la luminosidad; no demuestra con qué fiabilidad se transfieren esos juicios a otras cámaras o escenas.
- Qué conviene observar: La decisión práctica consiste en comprobar si el modelo y el endpoint elegidos devuelven de forma suficientemente consistente las puntuaciones de los tokens alternativos necesarios para la tarea. Antes de que una decisión tomada con una cámara web desencadene una acción, hay que medir conjuntamente el rendimiento por fotograma y la calidad de las decisiones con imágenes representativas.
Cómo funciona la decisión a partir de una imagen
La guía de inicio rápido de Jev de TypeSafe AI documenta un state y un conjunto de preguntas tipadas questions: noul para valores de sí o no, choice para alternativas con nombre y score para niveles ordenados. El script de Boll usa esos nombres y añade un arreglo llamado attachments con rutas de imágenes o URL de datos en base64. Ese campo es una ampliación suya del objeto de solicitud; la guía de inicio rápido citada describe el estado de texto y no lo documenta como entrada de la API de Jev.
Para cada pregunta, el script crea un prompt con opciones identificadas por letras, como [A] true y [B] false. Pide al modelo que responda con la mejor letra y lee los logprobs del primer token de salida top_logprobs. Eleva al exponente las probabilidades logarítmicas devueltas, normaliza los pesos entre las letras enumeradas y los asigna al tipo de pregunta correspondiente. Un choice devuelve la opción de mayor peso y su distribución. Un noul devuelve el peso de true. Un score devuelve un promedio ponderado de los niveles ordenados. El script rechaza una respuesta si los tokens de opciones omitidos aún podrían tener un peso significativo.
La imagen se incluye en cada pregunta. El ejemplo envía solicitudes separadas en vez de obtener todas las respuestas en una sola llamada al modelo. La ruta de OpenAI usa la Responses API con input_image, top_logprobs y message.output_text.logprobs; la ruta local de llama.cpp usa Chat Completions con un elemento de contenido image_url y logprobs. La guía de OpenAI sobre imágenes documenta las URL de datos de imagen en base64, y la referencia de Responses documenta la salida de logprobs y un máximo de 20 alternativas devueltas por posición de token. La documentación del servidor de llama.cpp documenta las URL de imágenes en su interfaz de chat. Estas fuentes respaldan el patrón de solicitud; no hemos ejecutado el ejemplo contra ninguno de los dos endpoints.
Qué mide el ejemplo con cámara web
El script captura un fotograma con OpenCV, lo codifica como JPEG y formula cuatro preguntas: si se ve a una persona o una planta, si el entorno es interior o exterior y cuál es su luminosidad. Un proceso en segundo plano evalúa un fotograma a la vez mientras la vista previa sigue activa. La configuración de la cámara usa Linux V4L2, así que el archivo publicado no ofrece una configuración de cámara web portátil sin modificaciones. El texto del artículo dice que se formulan tres preguntas por fotograma, pero el código publicado contiene cuatro; aquí usamos el código como referencia para el recuento.
Boll informa de aproximadamente un fotograma evaluado por segundo con un modelo Gemma 4 12B QAT servido localmente en una RTX 3090, y de aproximadamente 0,2 fotogramas por segundo con GPT-6 Luna alojado. Sugiere que las conexiones repetidas podrían contribuir al resultado del servicio alojado. La publicación no ofrece una comparación controlada del hardware, la red, el tamaño de las imágenes, el almacenamiento en caché, la precisión ni los tiempos de las solicitudes. Esas cifras describen la configuración y el código de este autor, no una clasificación general de la velocidad de los modelos. OpenAI indica que GPT-6 Luna admite entradas de imagen, y su guía de modelos señala que Luna admite el ajuste de razonamiento none utilizado en el ejemplo.
Para adaptar el script, un desarrollador debe hacer primero comprobaciones concretas: confirmar que el modelo acepta imágenes y expone las alternativas requeridas para el primer token; comprobar si aparecen todas las letras de las opciones; y luego evaluar las decisiones devueltas con imágenes etiquetadas de la cámara o el conjunto de datos previstos. Los pesos normalizados son relativos a los tokens de letras enumerados. Por sí solos, no son probabilidades medidas de que un juicio visual sea correcto. El recetario anterior de OpenAI sobre logprobs explica la idea de las probabilidades de tokens, pero está marcado como archivado y puede contener ejemplos de API desactualizados.
Esta capa también aclara qué aspectos de un resultado tipado quedan a cargo del código de la aplicación. El modelo evalúa la imagen proporcionada según el criterio escrito. La aplicación elige los fotogramas, gestiona la ausencia de puntuaciones y decide si algún resultado es lo bastante seguro como para actuar. El ejemplo de Boll imprime una tabla; no describe una acción automatizada ni un despliegue medido.
Fuentes y lecturas adicionales
- Allan Riordan Boll, «Una capa al estilo de Jev para los LLM, incluidos los modelos de visión», 25 de septiembre de 2026: ejemplo original en Python, flujo de trabajo con cámara web y tasas de fotogramas comunicadas por el autor. El texto menciona tres preguntas por fotograma; el código define cuatro. Los tiempos no son una prueba comparativa independiente ni controlada.
- TypeSafe AI, guía de inicio rápido de Jev: documenta el estado de texto y los tipos de preguntas
noul,choiceyscore. No documenta el campo personalizadoattachmentsdel autor como función de la API de Jev. - OpenAI, Imágenes y visión: documenta
input_image, URL de imágenes y URL de datos en base64 para entradas de visión. La referencia de la Responses API describemessage.output_text.logprobsy el límite de alternativas devueltas. - OpenAI, modelo GPT-6 Luna y guía de modelos: confirma la entrada de imágenes y el ajuste de razonamiento
none; la guía de modelos detalla la compatibilidad de parámetros. Estos documentos no verifican el rendimiento por fotograma descrito por el autor del blog. - Documentación del servidor de llama.cpp: describe su endpoint de chat compatible con OpenAI y la entrada de URL de imágenes. Aún habría que comprobar la compatibilidad del backend y las listas de tokens devueltas con la versión y el modelo exactos que se utilicen.
- Recetario de OpenAI, Uso de logprobs: explicación general de las probabilidades de tokens. OpenAI marca esta receta como archivada y advierte que algunos modelos o ejemplos de API pueden estar desactualizados.



