Concevoir une mémoire de compétences vérifiables pour un agent

Une mémoire n’est pas un sac de prompts

Dans OptiSkill, la mémoire est construite à partir de trajectoires de modélisation d’optimisation vérifiées par solveur (§§2.1–2.2, pp. 2–6). Cette preuve de domaine est essentielle : un agent ne devrait pas promouvoir une conversation simplement parce qu’elle paraît bien formulée.

La transposition ci-dessous est une recommandation éditoriale. Elle s’inspire de la structure du papier, mais ne reproduit ni son système OR ni ses résultats.

Définir le contrat d’une compétence

Chaque compétence devrait déclarer son contexte d’application, son résultat attendu, les données nécessaires, les actions autorisées, les risques connus et la preuve qui l’a justifiée. Ajoutez une version, une source, un propriétaire et une procédure de retrait.

Séparez deux niveaux :

• une stratégie globale, qui décrit un squelette ou une invariance ;
• une expérience locale, qui décrit un déclencheur, un piège observé et une correction.

Cette séparation reprend la distinction Global Strategy / Step Experience décrite en §2.1, mais l’extension à un agent logiciel généraliste reste une décision de conception, pas un résultat démontré par le papier.

Conserver les succès et les échecs

Un succès fournit une preuve de comportement dans un contexte donné ; un échec aide à documenter une frontière. Enregistrez les deux avec la tâche, la version de l’agent, les outils utilisés, la sortie observée et la raison du verdict. Sans cette paire de référence, il devient difficile de savoir si une compétence corrige réellement un problème ou si elle le déplace.

Utiliser un pool candidat

Ne rendez pas une nouvelle compétence active immédiatement. Conservez-la dans un pool candidat, dédupliquez-la, puis mesurez son support sur des cas similaires. Le mécanisme d’évolution batchée d’OptiSkill (§2.3, pp. 6–8) maintient la banque active fixe pendant le batch et applique support, réparation et régression avant admission.

Pour un agent logiciel, traduisez ces contrôles en questions concrètes : la compétence s’applique-t-elle au bon type de tâche ? améliore-t-elle le cas cible ? casse-t-elle un cas voisin ? élargit-elle les permissions ou la surface d’action ?

Attribuer une fiabilité explicite

Le papier utilise les niveaux high, medium, low et risky (§2.3, pp. 6–8). Reprenez éventuellement ces étiquettes comme vocabulaire de suivi, mais définissez localement leurs critères. Une étiquette n’est pas une preuve : elle doit pointer vers des exécutions, tests ou revues conservés.

Les candidates risquées doivent rester inactives ou être supprimées. Une compétence « probablement utile » qui peut détourner une décision sensible coûte plus cher qu’une mémoire légèrement plus petite.

Ne pas généraliser les résultats

OptiSkill est évalué en OR, avec une couverture initiale surtout LP/MILP et des classes rares sous-couvertes (pp. 12–16). Les auteurs signalent aussi les erreurs de routage, les expériences contre-productives, le coût d’inférence/validation et une évaluation centrée sur la correction vérifiée par solveur. Ces limites empêchent de promettre qu’une mémoire de compétences générale sera fiable par construction.

Source et recommandation

Source consultée le 22 septembre 2026 : Zhao et al., « OptiSkill: A Hierarchical and Evolving SkillBank for LLM-Based Optimization Modeling », arXiv:2609.22987v1, §§2.1–2.3, §§3.5–4 et annexes A–C : page arXiv, PDF. La structure proposée ici est une adaptation éditoriale ; elle ne constitue pas une recette validée pour un agent généraliste.