boucle-d-optimisation-avec-benchmark

Boucle d'optimisation avec benchmark

Utilisez cette compétence pour convertir « rends-le 20x plus rapide » ou « essaie 50 optimisations récursives » en une boucle de mesure bornée qui peut réellement améliorer un système.

Ligne de base requise

N'optimisez pas tant que ces éléments n'existent pas :

• l'opération en cours d'optimisation ;
• la porte de correction qui doit rester verte ;
• la métrique : temps d'exécution, latence p95, lignes/s, coût/exécution, mémoire, taux d'erreur ;
• la référence actuelle ;
• le budget de recherche : nombre maximum de variantes, temps maximum, dépense maximale, impact maximal sur les données.

Si l'utilisateur demande un objectif irréaliste, conservez l'ambition mais rendez la boucle bornée et mesurable.

Boucle

1. Mesurez la référence.
2. Identifiez les goulots d'étranglement à partir des preuves.
3. Générez des variantes qui testent une seule hypothèse chacune.
4. Exécutez les variantes avec la même forme d'entrée.
5. Rejetez les variantes qui échouent aux tests de correction, de sécurité ou de reproductibilité.
6. Promouvez la variante la plus rapide et sûre.
7. Codifiez le chemin gagnant dans un script, une commande, un test, une configuration ou un document.
8. Réexécutez la référence et le gagnant pour confirmer la différence.

Tableau des variantes

Suivez les variantes comme ceci :

Variante  | Hypothèse           | Commande                     | Temps | Correct ? | Notes
référence | chemin actuel        | npm run job                  | 120s  | oui       | stable
lot-500   | moins d'allers-retours | npm run job -- --batch 500  | 42s   | oui       | gagnant
parallèle-8 | plus de travailleurs | npm run job -- --workers 8  | 31s   | non       | limité par taux

Recherche récursive

Pour les travaux récursifs ou d'hyperparamètres :

• persistez chaque exécution dans un registre ;
• comparez avec le dernier gagnant accepté, pas seulement avec l'exécution précédente ;
• conservez une validation de rétention ou une relecture ;
• arrêtez lorsque l'amélioration est dans le bruit, que la correction échoue, que le coût dépasse le budget, ou que la recherche commence à modifier plus de variables qu'elle ne peut en expliquer.

Utilisez des expressions comme « meilleure variante sûre mesurée » plutôt que « optimum global » sauf si l'espace de recherche a été réellement exhaustif.

Porte de promotion

Une variante ne peut devenir la nouvelle valeur par défaut que lorsque :

• les tests de correction passent ;
• l'écart de performance est répété ou expliqué ;
• le retour en arrière est évident ;
• le changement est encodé dans le contrôle de source ou un runbook durable ;
• le résumé final inclut les commandes et mesures exactes.