decision-cascade apprend à un modèle local à calculer le coût d'une erreur avant d'appeler un LLM externe

Une histoire bien connue : vous construisez un système avec un petit modèle local et un gros modèle externe. Le schéma de routage simple ressemble à ceci : si le modèle local n'est pas sûr de lui, on envoie la requête dans le cloud. Le seuil est généralement choisi au doigt mouillé, disons 0,6. Un mois après sa première publication, l'auteur du projet decision-cascade s'est posé une question dérangeante : pourquoi exactement 0,6 ?

Pourquoi le seuil de confiance est un mauvais critère

La confiance d'un modèle et l'utilité d'une escalade sont deux choses différentes. On peut douter d'une réponse dont l'erreur ne coûte rien, par exemple choisir entre deux options équivalentes. Payer un appel externe n'a alors aucun sens. À l'inverse, on peut être sûr à 0,8 et se tromper à un endroit où le coût d'une erreur est élevé. Le seuil ne fait pas la différence entre ces cas.

C'est pourquoi le projet a introduit une escalade « benefit-aware ». Le moteur compare l'utilité attendue de la réponse locale et celle de l'escalade, en tenant compte du coût de l'erreur et du coût de l'appel au modèle externe. Si le gain de l'affinage est inférieur au coût de l'appel, la cascade reste locale. S'il est supérieur, elle part vers l'extérieur. La décision n'est pas prise par un modèle qui évalue s'il a raison, mais par un système qui calcule s'il vaut la peine de payer pour affiner.

Pour un product manager, c'est un langage clair : une erreur a un prix en argent, en temps ou en réputation, et un appel à un LLM a aussi un prix. L'escalade devient une ligne budgétaire, et non un effet secondaire du réglage d'un seuil.

Ce que montrent les démos et les benchmarks

L'auteur a testé l'approche dans deux jeux locaux où les décisions ont des conséquences. Aux échecs contre Stockfish, 19 % d'escalades comblent la moitié de l'écart avec le mode « toujours réfléchir en profondeur », pour 38 % du coût d'un calcul complet. Dans un labyrinthe façon Pac-Man, une politique prudente obtient 94 % des points avec 33 % d'escalades, soit deux fois plus que la stratégie gloutonne. Personne ne cherche à faire du moteur un grand maître. L'enjeu est ailleurs : l'économie de l'escalade fonctionne là où une décision a un coût.

Il existe par ailleurs une comparaison avec deux modèles « réels », Clef-Flash (9,4B) et Laya (421M), sur des jeux de données publics. Conditions : n=200 et un seul GPU de 16 Go.

• AG News, précision : 87,3 % pour decision-cascade (124M), 85,5 % pour Clef-Flash, 66,2 % pour Laya.
• AG News, latence médiane : 10 ms contre 130 ms pour Clef-Flash et 16 ms pour Laya.
• RouterBench, précision : 54,2 % contre 44,2 % pour Clef-Flash et 31,2 % pour Laya.
• RouterBench, latence médiane : 21 ms contre 170 ms pour Clef-Flash.

Conclusion de l'auteur : un petit modèle doté de têtes entraînées sur des tâches de prise de décision surpasse un concurrent de 9B et fonctionne environ 10 fois plus vite. Sur la génération libre, comme il le reconnaît lui-même, le grand modèle l'emportera. Le script eval/competitors/reproduce_real.sh et les JSON bruts sont disponibles dans les releases : les chiffres peuvent donc être revérifiés.

Intégration et points de vigilance

Pour ceux qui considèrent le projet comme une dépendance, le principal changement est que la version 1.x dispose désormais d'un contrat stable. Le format des packs et les variables DECISION_* ne seront pas cassés sans version majeure ni période de dépréciation. Le projet est disponible sur PyPI, et le démarrage rapide avec l'encodeur par hash prend quelques minutes, sans GPU ni téléchargement de modèles.

Voyons maintenant les limites, que l'auteur énumère lui-même honnêtement. Par défaut, les têtes sont aléatoires ; une qualité significative exige un SFT/RLCD ou un pack de poids prêt à l'emploi. Le modèle de risque n'est utile qu'après avoir accumulé des exemples. La calibration du domaine pour votre cas d'usage reste à faire vous-même. Et n'oublions pas l'échelle des mesures : n=200, des benchmarks assemblés par l'auteur lui-même, il ne s'agit pas d'une évaluation indépendante.

Que faire de tout cela

Même si vous n'installez pas decision-cascade, l'idée se transpose à toute combinaison « modèle bon marché plus modèle coûteux ». Cessez de router sur la seule confiance. Établissez au moins une estimation grossière du coût d'une erreur par type de requête et comparez-la au coût de l'appel. Pour les tâches de classification, de choix d'option et d'évaluation, cela peut réduire fortement les dépenses d'API externe avec une faible perte de qualité. Le projet prévoit un encodeur-transformeur avec masque d'attention des états et une intégration poussée dans les agents de chat. L'auteur demande qu'on lui envoie les cas où la cascade escalade à tort : c'est le moyen le plus utile de tester l'approche en pratique.