Nous avons divisé par deux les commandes du modèle. La précision n'a pas bougé.
Auspex lançait presque deux fois plus de commandes que nécessaire. Un simple budget a suffi.
Quand Auspex diagnostique une panne, le modèle lance des commandes en lecture seule sur le réseau : lire la topologie, vérifier les VLAN, pinger un équipement. Chaque commande prend du temps. En test, nous avons vu le modèle en lancer bien plus que nécessaire.
Ce qui n'allait pas
Notre première idée était un manque d'information. Peut-être que le modèle continuait à chercher parce qu'il ne comprenait pas le réseau. Nous lui avons donc donné une carte de la topologie dès le départ. Rien n'a changé. Le vrai problème était plus simple : le modèle ne savait pas quand s'arrêter.
La solution
Nous avons ajouté un budget à la boucle qui pilote le modèle. Il a deux seuils :
- À 20 commandes, le modèle reçoit un court rappel : donne la cause la plus probable. Si les preuves suffisent, termine. Sinon, fais un seul appel de plus.
- À 35 commandes, l'exécution s'arrête.
Chaque seuil ne se déclenche qu'une fois. Dans nos premiers essais, répéter le rappel faisait dérailler le modèle.
Le résultat
Nous avons mesuré sur 89 questions de l'examen. Le modèle a utilisé 48 % de commandes en moins, a résolu exactement autant de pannes, et plus aucune exécution n'a touché la limite. Le changement est sorti dans auspex-cli v0.3.3. Pour revenir à l'ancien comportement, il suffit de AUSPEX_TOOL_BUDGET=0.
La leçon
Tous les problèmes d'un modèle ne demandent pas plus d'entraînement. Parfois, la solution est dans le programme qui l'entoure. Une petite règle a économisé la moitié du travail sans rien coûter en précision.