Pour trier un ticket ou qualifier une alerte, générer une phrase est souvent une étape de trop. Ibou publie trois modèles ouverts ArseneLupin qui prennent un état en entrée et renvoient des probabilités plutôt qu’un texte à interpréter.

Leur intérêt pour un développeur tient autant au format de sortie qu’au choix de modèles exécutables en local : un petit Qwen, un Qwen plus imposant et une variante fondée sur Mistral.

Que renvoie ArseneLupin à la place d’une réponse rédigée ?

Une requête associe un état — document, ticket, trace ou enregistrement structuré — à plusieurs questions typées. Le type noul tranche entre oui et non, choice sélectionne une option parmi des critères explicites, et score évalue un niveau ordonné. Chaque question reçoit une distribution de probabilités. Le modèle évalue les options sans générer de réponse en langage naturel.

Pour une application de routage, cela évite d’extraire une catégorie d’une phrase libre. ArseneLupin reprend la forme des requêtes System One de TypeSafe, avec un état et un ensemble de questions. Cette proximité facilite la comparaison avec Jev ou Kev, sans dispenser de vérifier l’intégration du serveur et du client choisis.

Quels modèles et formats Ibou met-il à disposition ?

ArseneLupin-mini v1.0 part de Qwen3.5-0.8B : son modèle complet occupe 1,8 Go et sa version GGUF Q8_0, 0,8 Go. ArseneLupin v1.1 repose sur Qwen3.5-4B, avec respectivement 9,3 Go en bfloat16 et 4,5 Go en GGUF Q8_0. ArseneLupinstral v1.0 utilise Ministral 3 8B Instruct ; seul son modèle complet bfloat16 est présenté, pour 17,9 Go de poids et environ 18 Go de mémoire GPU annoncés.

Les trois conservent l’architecture et le tokenizer de leur base. Leur adaptation passe par un fine-tuning LoRA fusionné dans les poids et par une petite tête de lecture qui convertit l’état caché final en probabilité pour chaque option. Le code de service fourni expose la même forme d’API pour les variantes complètes et, lorsqu’elles existent, les versions GGUF. Les modèles sont distribués sous licence Apache 2.0.

Les chiffres permettent-ils de choisir un vainqueur ?

Pas sur un seul tableau. Sur jabr v2, benchmark public de 49 tâches, ArseneLupin v1.1 atteint 88,4 % de précision macro, ArseneLupinstral 85,1 % et le mini 72,4 % ; Jev 1.13 est donné à 97,1 %. À l’inverse, sur un test de transfert vers une décision non entraînée publié par Ibou, les versions Qwen 4B et Mistral obtiennent 92 % et 93 %, contre 85 % pour Jev. Ce dernier test est propriétaire : il ne remplace pas une évaluation sur les données du déploiement envisagé.

Il faut aussi distinguer la bonne option de la bonne probabilité. Dans les tableaux d’Ibou, certaines mesures utilisent un score de Brier, où une valeur plus basse indique de meilleures probabilités. Des fichiers de calibration par workflow sont proposés : ils ajustent les probabilités, pas l’option classée première. Le score Decision Index publié pour ArseneLupin v1.1 concerne l’édition 0.1 ; il ne se compare pas directement aux résultats de l’édition 0.2.1 du classement.

Que change le service local pour la latence ?

Le serveur du modèle Qwen 4B peut lire une seule fois le texte commun aux questions avant d’évaluer leurs options. Ibou annonce, sur une RTX PRO 6000 de 96 Go, 0,12 seconde pour 32 questions oui/non portant sur un texte court avec ce mode, contre 1,69 seconde lorsque les options sont traitées séparément. Ce sont des mesures de l’éditeur sur ce matériel, non une promesse de débit sur un poste local.

Le choix pratique dépend donc de la mémoire disponible, du nombre d’options par requête et de la qualité mesurée sur les propres tickets ou traces de l’application. Le mini réduit nettement l’empreinte des poids ; les résultats publiés montrent aussi ce qu’il concède en précision sur plusieurs jeux de test.