Reducimos a la mitad los comandos del modelo. La precisión no cambió.
Auspex ejecutaba casi el doble de comandos de los necesarios. Un presupuesto sencillo lo resolvió.
Cuando Auspex diagnostica un fallo, el modelo ejecuta comandos de solo lectura en la red: lee la topología, revisa las VLAN, hace ping a un equipo. Cada comando lleva tiempo. En las pruebas vimos que el modelo ejecutaba muchos más de los necesarios.
Qué fallaba
Primero pensamos que le faltaba información. Quizá seguía buscando porque no entendía la red. Así que le dimos un mapa de la topología desde el principio. No cambió nada. El problema real era más simple: el modelo no sabía cuándo parar.
La solución
Añadimos un presupuesto al bucle que ejecuta el modelo. Tiene dos umbrales:
- A los 20 comandos, el modelo recibe un breve recordatorio: indica la causa más probable. Si la evidencia basta, termina. Si no, haz una sola llamada más.
- A los 35 comandos, la ejecución se detiene.
Cada umbral se activa una sola vez. En las primeras pruebas, repetir el recordatorio desviaba al modelo.
El resultado
Lo medimos en 89 preguntas del examen. El modelo usó un 48% menos de comandos, resolvió exactamente los mismos fallos y ninguna ejecución volvió a tocar el límite. El cambio salió en auspex-cli v0.3.3. Para volver al comportamiento anterior, basta con AUSPEX_TOOL_BUDGET=0.
La lección
No todos los problemas de un modelo se arreglan con más entrenamiento. A veces la solución está en el programa que lo rodea. Una regla pequeña ahorró la mitad del trabajo sin perder precisión.