Un exemple Python publié le 25 septembre par le développeur Allan Riordan Boll étend à des images une requête de décision inspirée de Jev. Pour chaque image de webcam, le script pose brièvement des questions à un modèle de vision, puis convertit les probabilités du jeton suivant en réponse oui/non, en choix ou en score. Il s’agit d’un habillage indépendant, pas d’une fonction de vision de Jev ni d’un test de son modèle.
Pour les développeurs, l’intérêt tient aux limites de cette technique. Un modèle de vision peut répondre à une question contrainte sans rédiger de description, mais les probabilités des options renvoyées dépendent de la consigne, des jetons disponibles et du modèle. L’article propose un exemple fonctionnel à examiner, pas une étude de précision.
Le grand changement
- Ce qui a changé : Un développeur a appliqué aux images, avec des modèles de vision généralistes, le format de petites décisions associé à Jev. L’image est jointe à chaque requête et une réponse d’une seule lettre transforme une question visuelle en valeur exploitable par un logiciel.
- Pourquoi c’est important : Les développeurs peuvent modifier par écrit le critère visuel et obtenir un résultat typé sans créer un classificateur d’images distinct pour chaque question. L’exemple porte sur la présence visible de personnes ou de plantes, le cadre intérieur ou extérieur et la luminosité ; il ne démontre pas la fiabilité de ces jugements avec d’autres caméras ou dans d’autres scènes.
- À surveiller : La question pratique est de savoir si le modèle et le point de terminaison choisis renvoient assez régulièrement les scores des jetons correspondant aux options requises. Il faut mesurer ensemble le débit d’images et la qualité des décisions sur des images représentatives avant qu’un résultat de webcam ne déclenche une action.
Comment fonctionne la décision à partir d’une image
Le guide de démarrage rapide de Jev de TypeSafe AI documente un state et un ensemble de questions typés : noul pour une valeur oui/non, choice pour des options nommées et score pour des niveaux ordonnés. Le script de Boll reprend ces noms et ajoute un champ attachments contenant un tableau de chemins d’images ou d’URL de données base64. Ce champ est une extension de l’auteur à l’objet de requête ; le guide Jev cité décrit l’état textuel, mais ne documente pas ce champ comme entrée de l’API Jev.
Pour chaque question, le script construit une consigne avec des options repérées par des lettres, par exemple [A] true et [B] false. Il demande au modèle de répondre par la meilleure lettre et lit les logprobs du premier jeton de sortie dans le champ top_logprobs. Il exponentie les logprobabilités renvoyées, normalise les poids entre les lettres proposées et les associe au type de question. Un résultat de type choice renvoie l’option au poids le plus élevé et sa distribution. Un résultat de type noul renvoie le poids associé à true. Un résultat de type score renvoie une moyenne pondérée des niveaux ordonnés. Le script rejette une réponse si les jetons correspondant aux options omises pourraient encore avoir un poids important.
L’image accompagne chaque question. L’exemple envoie des requêtes distinctes au lieu d’obtenir toutes les réponses dans un seul appel au modèle. Le chemin OpenAI utilise l’API Responses avec input_image, top_logprobs et message.output_text.logprobs ; le chemin local llama.cpp utilise Chat Completions avec un élément de contenu image_url et des logprobabilités. Le guide d’OpenAI sur les images documente les URL de données d’image en base64, et sa référence de l’API Responses décrit les logprobabilités de sortie ainsi que la limite de 20 alternatives renvoyées par position de jeton. La documentation du serveur llama.cpp décrit les URL d’image dans son interface de chat. Ces sources étayent le format des requêtes ; nous n’avons pas exécuté l’exemple sur l’un ou l’autre point de terminaison.
Ce que mesure l’exemple avec webcam
Le script capture une image avec OpenCV, l’encode en JPEG et pose quatre questions : voit-on une personne ou une plante, la scène est-elle à l’intérieur ou à l’extérieur, et quel est son niveau de luminosité ? Un processus en arrière-plan évalue une image à la fois pendant que l’aperçu continue. La configuration de la caméra utilise Linux V4L2 : le fichier publié n’est donc pas directement utilisable comme configuration webcam portable sans modification. Le texte de l’article parle de trois questions par image, mais le code publié en contient quatre ; le décompte présenté ici se fonde sur le code.
Boll rapporte environ une image évaluée par seconde avec un modèle Gemma 4 12B QAT exécuté localement sur une RTX 3090, et environ 0,2 image par seconde avec GPT-6 Luna hébergé. Il avance que les connexions répétées pourraient contribuer au résultat obtenu avec l’hébergement. L’article ne présente pas de comparaison contrôlée du matériel, du réseau, de la taille des images, de la mise en cache, de la précision ou du temps de requête. Ces chiffres décrivent la configuration et le code de l’auteur, pas un classement général de la vitesse des modèles. OpenAI indique que GPT-6 Luna accepte les images, et ses instructions sur les modèles indiquent que Luna prend en charge le réglage de raisonnement none utilisé dans l’exemple.
Pour adapter le script, un développeur peut commencer par des vérifications concrètes : confirmer que le modèle accepte les images et expose les alternatives requises pour le premier jeton ; vérifier si toutes les lettres d’option apparaissent ; puis évaluer les décisions obtenues sur des images étiquetées provenant de la caméra ou du jeu de données visé. Les poids normalisés sont relatifs aux jetons des lettres proposées. À eux seuls, ils ne mesurent pas la probabilité qu’un jugement visuel soit correct. Le livre de recettes plus ancien d’OpenAI sur les logprobs explique le principe des probabilités de jetons, mais il est archivé et peut contenir des exemples d’API obsolètes.
Cet habillage montre aussi ce qu’un résultat typé laisse à la charge du logiciel applicatif. Le modèle juge l’image fournie selon le critère formulé. L’application choisit les images, gère les scores manquants et décide si un résultat peut déclencher une action en toute sécurité. L’exemple de Boll affiche un tableau ; il ne décrit ni action automatisée ni déploiement mesuré.
Sources et lectures complémentaires
- Allan Riordan Boll, « A Jev-like wrapper for LLMs, including vision models », 25 septembre 2026 : exemple Python original, processus webcam et cadences rapportées par l’auteur. Le texte parle de trois questions par image, tandis que le code en définit quatre. Les temps ne proviennent pas d’un benchmark indépendant ou contrôlé.
- TypeSafe AI, Jev quick start : documente l’état textuel et les types de questions
noul,choiceetscore. Il ne documente pas le champ personnaliséattachmentscomme fonction de l’API Jev. - OpenAI, Images and vision : documente
input_image, les URL d’image et les URL de données base64 comme entrées visuelles. La documentation de l’API Responses décritmessage.output_text.logprobset la limite du nombre d’alternatives renvoyées. - OpenAI, GPT-6 Luna model and model guidance : confirme la prise en charge des images et le réglage de raisonnement
none; les instructions sur les modèles détaillent la compatibilité des paramètres. Ces documents ne vérifient pas le débit rapporté par l’auteur du billet. - Documentation du serveur llama.cpp : décrit son point de terminaison de chat compatible avec OpenAI et les entrées image_url. La prise en charge du backend et la liste des jetons renvoyés restent à vérifier avec la version et le modèle exacts utilisés.
- OpenAI Cookbook: Using logprobs : présente les probabilités de jetons. OpenAI indique que cet exemple de recette est archivé et que certaines informations peuvent être obsolètes pour les modèles ou API actuels.



