Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Un habillage de vision inspiré de Jev transforme les questions sur les images en choix typés

> Un exemple Python indépendant utilise les probabilités des jetons d’un modèle de vision pour produire des décisions typées à partir d’images. Les cadences de la webcam sont rapportées par l’auteur et la précision n’a pas été évaluée.

By BIG CHANGE Editorial

Published: 2026-09-26T10:09:47.074Z
Updated: 2026-09-26T10:09:47.074Z
Canonical: https://bigchange.ai/blog/jev-like-llm-vision-wrapper-logprobs

![Conceptual charcoal illustration of a webcam clipped to a monitor and facing a leafy plant on a shelf.](https://bigchange.ai/api/media/file/jev-vision-webcam-plant-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

Un [exemple Python publié le 25 septembre par le développeur Allan Riordan Boll](https://allanrbo.blogspot.com/2026/09/a-jev-like-wrapper-for-llms-including.html) é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](https://docs.typesafe.ai/introduction/quickstart) 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](https://developers.openai.com/api/docs/guides/images-vision) documente les URL de données d’image en base64, et sa [référence de l’API Responses](https://developers.openai.com/api/reference/resources/responses/methods/create) 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](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) 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](https://developers.openai.com/api/docs/models/gpt-6-luna), et ses [instructions sur les modèles](https://developers.openai.com/api/docs/guides/latest-model) 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](https://developers.openai.com/cookbook/examples/using_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](https://allanrbo.blogspot.com/2026/09/a-jev-like-wrapper-for-llms-including.html) : 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](https://docs.typesafe.ai/introduction/quickstart) : documente l’état textuel et les types de questions `noul`, `choice` et `score`. Il ne documente pas le champ personnalisé `attachments` comme fonction de l’API Jev.
- [OpenAI, Images and vision](https://developers.openai.com/api/docs/guides/images-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](https://developers.openai.com/api/reference/resources/responses/methods/create) décrit `message.output_text.logprobs` et la limite du nombre d’alternatives renvoyées.
- [OpenAI, GPT-6 Luna model and model guidance](https://developers.openai.com/api/docs/models/gpt-6-luna) : confirme la prise en charge des images et le réglage de raisonnement `none` ; les [instructions sur les modèles](https://developers.openai.com/api/docs/guides/latest-model) 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](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) : 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](https://developers.openai.com/cookbook/examples/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.

## Sources

- [Allan Riordan Boll : A Jev-like wrapper for LLMs, including vision models](https://allanrbo.blogspot.com/2026/09/a-jev-like-wrapper-for-llms-including.html) — Code Python indépendant et observations webcam rapportées par l’auteur. Le code définit quatre questions, alors que le texte autour en annonce trois ; aucun benchmark contrôlé ni étude de précision indépendante.
- [TypeSafe AI : Jev quick start](https://docs.typesafe.ai/introduction/quickstart) — Documente l’état textuel, les types de questions et un exemple de corps de requête. L’auteur du billet ajoute des pièces jointes à son propre objet de requête inspiré de Jev ; ce guide de démarrage ne documente pas ce champ.
- [OpenAI : Images and vision](https://developers.openai.com/api/docs/guides/images-vision) — Documente l’entrée d’images et les URL de données base64. Cette source étaye le format de la requête, pas le débit observé par l’auteur.
- [OpenAI : Create a model response](https://developers.openai.com/api/reference/resources/responses/methods/create) — Documente les entrées d’image, message.output_text.logprobs et jusqu’à 20 logprobabilités principales par position de jeton, parfois moins.
- [OpenAI : GPT-6 Luna et conseils d’utilisation des modèles](https://developers.openai.com/api/docs/models/gpt-6-luna) — Indique que les images sont acceptées et que le niveau d’effort de raisonnement none est pris en charge ; les conseils sur les modèles expliquent les limites des paramètres de logprobs selon le niveau d’effort.
- [README du serveur llama.cpp](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) — Documente le point de terminaison de chat compatible avec OpenAI et l’entrée image_url. Le backend et la version exacte du modèle n’ont pas été testés indépendamment ici.
- [OpenAI Cookbook : Using logprobs](https://developers.openai.com/cookbook/examples/using_logprobs) — Présentation des probabilités de jetons. OpenAI marque cet exemple du cookbook comme archivé et potentiellement obsolète pour les modèles ou API actuels.