Aiguiller les demandes avec un petit classifieur entraîné, pas avec des mots-clés
Envoyer chaque demande au plus gros modèle est lent ; l'envoyer au plus petit est faux. Un aiguilleur décide, et le premier aiguilleur habituel est une liste de mots-clés. Nous avons mesuré le nôtre face à plus simple que lui et face à un petit classifieur entraîné. Les chiffres ont changé la conception.
Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.
Ce que vous y gagnez. Un aiguilleur juste 84 fois sur 100 au lieu de 64, qui répond en 20 ms environ sur le processeur, et une méthode pour savoir si le vôtre bat la règle la plus simple possible.
1. Mesurer d'abord face à la référence bête
Sur 237 vraies demandes, chacune étiquetée facile, standard ou difficile, en validation croisée :
| Aiguilleur | Justes |
|---|---|
| hasard, en respectant la fréquence des classes | 59,5 % |
| recherche par mots-clés | 63,7 % |
| toujours « standard » | 72,6 % |
| classifieur entraîné | 84,0 % |
La vraie barre n'était pas le hasard : c'était « répondre toujours la classe la plus fréquente ». Notre aiguilleur par mots-clés était en dessous. Mesurez cette référence avant de célébrer quoi que ce soit.
2. D'où est venu le gain
Des demandes « faciles » : les mots-clés en trouvaient 2 sur 35, le classifieur 34 sur 35, sans aucun faux positif. C'est là que les petits modèles peuvent prendre le relais, et c'est de là que vient la vitesse. Latence : 18 à 27 ms pour une demande, 3,8 ms chacune en lot.
3. Trois décisions imposées par les chiffres
- Pas de repli sur la confiance. Le classifieur battait les mots-clés à tous les niveaux de confiance : se replier sur les mots-clés en cas de doute dégradait le résultat. Le repli ne sert que si le classifieur est en panne.
- Une calibration a été écartée alors qu'elle donnait 86,9 % : elle ne prédisait plus jamais « difficile ». Trois points achetés en abandonnant la classe dont les erreurs coûtent de la qualité.
- « Difficile » reste faible (13 sur 30) : trente exemples ne suffisent pas. Récoltez-en davantage avant de vous y fier.
4. La leçon plus large : le catalogue d'outils
Mesurer les demandes a révélé autre chose : notre catalogue d'outils pesait 19 157 jetons pour 58 outils, payés à chaque tour. Charger les outils selon l'intention en économise environ 73 %. Et nos agents de code livrent des demandes de fusion acceptées avec six outils (lire, écrire, modifier, chercher, lister, shell) : 2 182 jetons. La question n'était plus « comment réduire », mais « pourquoi 58 ».
Pièges
llama-server ignore enable_thinking à la racine de la requête : le modèle a réfléchi sur 844 caractères et n'a rien répondu. Seul chat_template_kwargs: {"enable_thinking": false} le coupe (1,7 s au lieu de 9,6). À travers certaines passerelles la forme racine marche, en direct non.
Un aiguilleur sans journal ne progresse jamais : enregistrez chaque demande et le modèle qui a répondu, sinon votre jeu d'entraînement ne grandit pas.
Utile ? Dites-nous ce qu'il faut mesurer ensuite.