Évaluer une SkillBank sans laisser une mauvaise compétence contaminer les suivantes

Le protocole avant le code

Ce tutoriel est conceptuel : il ne fournit pas de code Gurobi, ne copie pas le dépôt OptiSkill et ne prétend pas reproduire ses benchmarks. Il reprend les étapes décrites en §§2.2–2.3 et dans les annexes B–C (pp. 4–8 et 16–22) pour montrer comment organiser une évaluation.

Étape 1 — Fixer le jeu de cas

Conservez un ensemble de tâches représentatives, une version de l’agent, un budget et un oracle de réussite. Le cas doit permettre de distinguer une sortie correcte d’une sortie seulement plausible. Dans le papier, l’oracle est lié à la vérification par solveur ; pour un autre domaine, il faut définir une preuve équivalente ou déclarer que le transfert n’est pas validé.

Étape 2 — Geler la banque active

Pendant un batch, ne modifiez pas la banque utilisée pour produire les résultats de référence. Les nouvelles stratégies et expériences vont dans un tampon candidat, conformément à l’évolution décrite en §2.3 (pp. 6–8). Ce gel sépare l’évaluation de la production de mémoire et évite qu’une candidate se serve elle-même de preuve.

Étape 3 — Diagnostiquer les échecs

Les catégories d’annexe C (pp. 18–22) fournissent une grille utile : experience_misleading, strategy_misleading, experience_miss, strategy_miss, code_error_only et unresolved. Utilisez-les comme hypothèses de diagnostic, pas comme vérité automatique. Un agent peut mal attribuer la cause ; une revue humaine ou une vérification indépendante reste nécessaire pour les cas importants.

Étape 4 — Construire la candidate

Une candidate doit contenir son déclencheur, son action, sa preuve d’origine, ses conditions d’application et son risque. Dédupliquez et fusionnez les formulations proches avant le test, comme dans §2.2. Gardez le lien entre la candidate et les trajectoires succès-échec qui l’ont motivée.

Étape 5 — Tester trois portillons

Le plan de test doit mesurer au moins :

• support : la candidate s’applique-t-elle à assez de cas du bon type ?
• réparation : améliore-t-elle le cas qui a motivé sa création ?
• régression : dégrade-t-elle des cas auparavant corrects ou élargit-elle le risque ?

Une candidate qui réussit un cas mais introduit des erreurs dans un voisin ne doit pas être activée. L’ablation rapportée dans le registre montre que retirer les contrôles d’admission dégrade la moyenne ; cela reste un résultat des auteurs, non une garantie pour une autre implémentation.

Étape 6 — Admettre ou rejeter

Attribuez une fiabilité, consignez la décision et rendez la candidate active seulement si les seuils préalablement fixés sont atteints. Les niveaux high, medium, low et risky d’OptiSkill peuvent inspirer le registre, mais leurs seuils doivent être définis par votre domaine.

Étape 7 — Mesurer le coût

L’évolution n’est pas gratuite : le papier rapporte une hausse du temps moyen de 34,13 à 36,57 secondes et des tokens de 5 964 à 6 176 (§3.5, pp. 11–12). Notez donc le coût d’inférence et de validation avec la qualité, au lieu de présenter l’admission comme un gain net.

Limites du protocole

Les résultats restent liés à la modélisation OR, à la couverture surtout LP/MILP de la banque initiale, aux erreurs de routage et aux classes rares. Le papier évalue principalement la correction vérifiée par solveur, pas l’efficacité, la stabilité ou l’interprétabilité opérationnelle. Une SkillBank peut aussi récupérer une expérience pertinente mais contre-productive ; les figures et tableaux doivent être consultés avant toute reprise de valeur.

Source

Zhao et al., « OptiSkill: A Hierarchical and Evolving SkillBank for LLM-Based Optimization Modeling », arXiv:2609.22987v1, §§2.2–2.3, §3.5, §4 et annexes B–C, consulté le 22 septembre 2026 : page officielle, PDF officiel. Ce protocole est une adaptation conceptuelle ; aucune reproduction locale n’est revendiquée.