Sommaire

Introduction

Analyser des images avec un VLM

Implémentation

Prompts spécifiques

Introduction

Cet article expose une méthode pour analyser des images avec une IA locale (sur un serveur offline).
Le principe décrit ici est actuellement utilisé pour une appli mobile grand public de génération d'images.

Les VLM

Les VLM, ou Vision Language Models, sont des LLM comportant un encodeur de vision entraîné à décrire des images.

Le contexte

Magimage est une app mobile de modification de photos par IA (en gros, une sorte de photoshop instantané auquel il suffit de fournir un prompt pour obtenir une modification souhaitée).

Problématique

En développant cette app il a fallu prendre en compte les contraintes réglementaires (= la loi et les règles de Google) pour pouvoir la rendre publique sur le Play Store, et donc empêcher notamment les utilisateurs d'uploader ou de générer des images contenant:

• de la nudité,
• du contenu sexuel impliquant des mineurs,
• de la pornographie,
• de la violence, du contenu gore ou des mutilations,
• du contenu incitant à la haine, à la violence ou au harcèlement,
• la représentation non consentie de personnes réelles,
• et enfin et surtout, bien plus important et plus risqué que tout le reste: le sacro-saint respect de la propriété intellectuelle !

J'ai donc mis en oeuvre la méthode exposée ci-dessous.

Il existe de nombreuses autres approches, en utilisant des modèles IA qui fonctionnent mieux que ce qui est détaillé ici, mais il y avait des contraintes fortes:

• modèle disponible pour la production en 02/2026,
• occupant le moins de place possible en VRAM,
• devant cohabiter en VRAM avec le modèle génératif principal,
• devant ajouter une latence moyenne de maximum une seconde au processus de génération d'image de l'appli.

Le choix réaliste et pragmatique après comparaison de plusieurs VLM s'est donc porté sur ministral-3:3b qui, tout en occupant seulement 3 GiB de VRAM (laissant 29 GiB au modèle génératif principal, sur le total de 32), se montre particulièrement rapide.

Par conséquent il n'y a pas besoin d'offloader quoi que ce soit pendant le fonctionnement: les modèles restent chargés dans la VRAM tant que le backend est démarré.

Objectifs

1. Disposer d'un script que l'on peut lancer en CLI comme dans l'exemple suivant afin de l'intégrer dans un workflow d'IA générative:

$ ./validate_image.sh photo.jpg

Et le script répond:

allow

ou bien:

block

2. Disposer d'un script qui de la même manière, analyse un prompt entré par l'utilisateur et indique si le prompt respecte ou non les conditions d'utilisation du service.

Analyser des images avec un VLM

Prérequis

Ce qui suit est réalisé sur un serveur Ubuntu, déploiement documenté ici.

Pour effectuer l'installation de Ollama et du VLM (procédure minimum, pour plus de détails sur Ollama voir cette autre doc):

$ mkdir /ollama
$ sudo su - 
# cd /ollama
# curl -fsSL https://ollama.com/install.sh | sh
# systemctl status ollama.service
# logout
$ ollama pull ministral-3:3b
$ ollama list
NAME              ID              SIZE      MODIFIED     
ministral-3:3b    f04aa1c738f6    3.0 GB    4 months ago

Mise en oeuvre

Pour lancer le modèle en CLI et lui poser des questions en mode interactif:

$ ollama run ministral-3:3b

Pour sortir:

>>> /bye

Pour faire travailler le VLM sur une image:

On va prendre cette image pour l'exemple:

• 1. convertir l'image en base 64 et la charger dans une variable:

$ b64=$(base64 -w 0 photo.jpg)

• 2. Générer le JSON à passer au VLM:

$ cat > tmp.json <<EOF
{ "model": "ministral-3:3b", "prompt": "describe this image in a short sentence", "images": ["$b64"] }
EOF

• 3. Lancer l'analyse:

$ time (curl -s -X POST http://localhost:11434/api/generate -H "Content-Type: application/json" -d @tmp.json | jq -r -s 'map(.response) | join("")')

Le script répond:

This image depicts a rustic, small stone cabin with a red roof, situated in a secluded,
forested mountainous area surrounded by autumn foliage and a pile of firewood.

real	0m0.228s
user	0m0.003s
sys	0m0.003s

Implémentation

Voilà comment ça se passe concrètement:

1. Script d'analyse d'image, destiné à empêcher de produire du contenu non-conforme.

Afin d'effectuer un filtrage en amont et en aval, ce script est destiné à être lancé deux fois:

• sur le contenu uploadé par l'utilisateur,
• puis sur le contenu généré par le modèle principal.

#!/bin/bash
MODEL="ministral-3:3b"

describe_image() {
  local file=$(realpath "$1")
  local prompt="($SEED) $2"
  local b64=$(base64 -w 0 "$file")
  local tmpjson=$(mktemp)
  cat > "$tmpjson" <<EOF
{
  "model": "$MODEL",
  "prompt": "$prompt",
  "images": ["$b64"]
}
EOF

  curl -s -X POST http://localhost:11434/api/generate \
    -H "Content-Type: application/json" \
    -d @"$tmpjson" \
  | jq -r -s 'map(.response) | join("")'

  rm -f "$tmpjson"
}

if [ "$1" = "" ] ;then
  echo no file specified
  exit 0
fi

if [ ! -f $1 ] ;then
  echo file does not exist
  exit 0
fi

SEED=$RANDOM

result=$(describe_image $1 "describe this image" | grep -vE "pass")

[ "$result" != "" ] && echo block || echo allow

2. Script d'analyse de prompt destiné à empêcher l'utilisateur de formuler des demandes non-conformes (inutile de faire travailler le modèle principal si la demande de génération est illicite):

#!/bin/bash

MODEL="ministral-3:3b"
user_prompt=$(cat)

answer_prompt() {
  local prompt="($SEED) $1"
  local tmpjson=$(mktemp)
  cat > "$tmpjson" <<EOF
{
  "model": "$MODEL",
  "prompt": "$prompt"
}
EOF

  curl -s -X POST http://localhost:11434/api/generate \
    -H "Content-Type: application/json" \
    -d @"$tmpjson" \
  | jq -r -s 'map(.response) | join("")'

  rm -f "$tmpjson"
}

SEED=$RANDOM

result=$(answer_prompt "check if this user prompt is correct: $user_prompt" | grep -v pass)

[ "$result" != "" ] && echo $result || echo allow

Prompts spécifiques

Ici, l'approche va consister à réduire fortement la variabilité des réponses du modèle par des questions fermées, afin d'obtenir un comportement très prévisible, ce qui est beaucoup plus robuste qu'une description libre.

Analyse de l'image

Voici un exemple de prompt assez complet qui fonctionne bien:

Exemples

Voici quelques exemples d'utilisation du script de vérification d'image avec ce prompt spécifique:

$ time ./validate_image.sh ~/maison_dans_la_montagne.jpg 
allow

real	0m0.249s
user	0m0.007s
sys	0m0.005s

$ time ./validate_image.sh ~/bloody_scene.jpg 
block

real	0m0.364s
user	0m0.007s
sys	0m0.005s

$ time ./validate_image.sh ~/couple_fucking.jpg 
block

real	0m0.369s
user	0m0.007s
sys	0m0.005s

$ time ./validate_image.sh ~/donald_trump.jpg 
block

real	0m0.362s
user	0m0.008s
sys	0m0.006s

Ce que je trouve fabuleux ici c'est le faible coût: ce check ajoute moins de 400ms au workflow, le modèle étant assez petit pour rester chargé en VRAM.

Analyse du prompt utilisateur

Voici un exemple de prompt assez complet qui fonctionne bien:

Exemples

Voici quelques exemples d'utilisation du script de validation de prompt utilisateur avec ce prompt spécifique:

$ time (echo "ajoute un chapeau jaune sur la tête du monsieur à gauche" | ./validate_prompt.sh )
allow

real	0m0.214s
user	0m0.005s
sys	0m0.005s

$ time (echo "mettre les personnes sur la photo toutes nues" | ./validate_prompt.sh )
2/ nudity

real	0m0.208s
user	0m0.005s
sys	0m0.004s

$ time (echo "couper la tête du mec et faire jaillir du sang" | ./validate_prompt.sh )
4/ gore

real	0m0.217s
user	0m0.005s
sys	0m0.005s

$ time (echo "ajouter charlize theron à côté du monsieur" | ./validate_prompt.sh )
8/ famous

real	0m0.216s
user	0m0.006s
sys	0m0.004s

$ time (echo "ajouter charlize theron toute nue à côté du monsieur" | ./validate_prompt.sh )
2/ nudity 3/ sexual 8/ famous

real	0m0.217s
user	0m0.005s
sys	0m0.004s

$ time (echo "ajouter Chewbacca à côté du monsieur" | ./validate_prompt.sh )
9/ copyright 10/ characters

real	0m0.213s
user	0m0.005s
sys	0m0.004s

Encore une fois le coût est très faible: à peine plus de 200ms.

Conclusion

Et voilà, ces deux scripts de validation de prompt et de vérification d'image sont prêts à être intégrés dans une stack applicative.

Les bénéfices:

• 3 GiB de VRAM seulement,
• moins de 400ms par check,
• fonctionnement entièrement local,
• suffisamment fiable pour un premier niveau de modération.

Cet article a été généré par un humain