Anthropic Performance Take‑Home : Benchmark open‑source

Qu’est‑ce que le Performance Take‑Home d’Anthropic ?

Anthropic a récemment publié un dépôt Performance Take‑Home sur GitHub qui invite la communauté à relever un challenge d’optimisation réel. Le but est simple : écrire du code qui accomplit une tâche spécifique en moins de cycles d’horloge que le benchmark fixé par Claude Opus 4.5 en un test de 2 heures. Le dépôt est volontairement dépourvu de fonctionnalités avancées afin que tout le monde démarre à partir du même point de référence lent.

*« L'original take‑home était un test de 4 heures qui commence proche du contenu de ce dépôt. Après que Claude Opus 4 ait surpassé la plupart des humains à ce point, il a été mis à jour pour un test de 2 heures, débutant avec du code qui a atteint 18532 cycles (7,97 fois plus rapide que le dépôt initial). » – Extrait du README

Pourquoi s’y intéresser ?

• Benchmarking d’IA en pratique – Si vous êtes ingénieur IA, cela vous donne un moyen concret de mesurer les performances d’un système par rapport à un modèle de pointe.
• Expérience prête pour le travail – Anthropic invite explicitement les soumissions qui battent le record : « Si vous optimisez en dessous de 1487 cycles, surpassant la meilleure performance de Claude Opus 4.5 au lancement, envoyez-nous un e‑mail à performance‑[email protected]. »
• Opportunité d’apprentissage – Le dépôt illustre l’optimisation Python réel, la structuration des tests et les pièges liés à la triche en modifiant le harness de test.

Anatomie du dépôt

Le dépôt est volontairement simple. Voici un aperçu de sa structure :

├─ .gitignore          # Ignorés standards
├─ Readme.md            # Description du challenge & benchmarks
├─ perf_takehome.py     # Implémentation de référence (ligne de base lente)
├─ problem.py          # Logique du problème (algorithme central)
├─ watch_trace.py      # Simple helper de profilage
├─ watch_trace.html     # Visualisation HTML des données de trace
└─ tests/
   ├─ __init__.py
   ├─ submission_tests.py  # Runner qui affiche le compte de cycles
   └─ ... (fixtures & scripts d’aide)

Fichiers clés

• problem.py – Le cœur algorithmique ; vous le modifierez si vous voulez changer la façon dont le problème est résolu.
• perf_takehome.py – Un wrapper pratique qui exécute les tests et affiche le compte de cycles.
• tests/submission_tests.py – La seule chose que vous devez exécuter pour valider votre solution.

Exécution des tests

Le dépôt est livré avec un harness de test minimal. Exécutez les commandes suivantes à la racine du dépôt :

# Vérifiez que votre répertoire tests n’a pas été altéré
git diff origin/main tests/
# Exécutez le benchmark et affichez le compte de cycles
python tests/submission_tests.py

Si la sortie est vide après la commande git diff, vous n’avez pas modifié les fichiers de test — c’est un contrôle de sécurité contre les pratiques de « tricherie ». La seconde commande affiche quelque chose comme :

Total cycles: 18532

Votre mission est de réduire ce nombre.

Comment battre le benchmark

1. Commencez par la ligne de base – Clonez le dépôt et lancez les tests. Notez votre compte de cycles.
2. Profilez d’abord – Utilisez watch_trace.py ou un profiler standard (p. ex. cProfile) pour repérer les points chauds.
3. Micro‑optimisez – Les gains typiques proviennent de :
4. Éliminer les boucles inutiles
5. Utiliser les fonctions intégrées plutôt que du code Python pur
6. Éviter les recherches globales dans les boucles serrées
7. Ajustements algorithmique – Dans certains cas, une meilleure structure de données ou un algorithme plus adapté peut réduire de gros blocs de cycles.
8. Vérifiez le multi‑core – Le dépôt désactive explicitement le support multi‑core ; toute tentative de tricher sur le nombre de cœurs sera signalée comme tricherie.
9. Validez – Après chaque ajustement, relancez tests/submission_tests.py pour vérifier le nouveau compte de cycles.
10. Soumettez – Une fois en dessous de 1487, envoyez une pull‑request + une note attestant de la validation des tests.

Pièges courants

• Modification des fichiers de test – Même un petit changement peut diminuer drastiquement les cycles, mais cela est interdit.
• Ré‑implémentation du harness de test – Répliquer le harness dans votre code pour contourner les vérifications est considéré comme tricherie.
• Ignorer les cas limites – Les tests couvrent un ensemble complet de scénarios ; les ignorer conduit à des soumissions échouées.

Nombres de benchmark

Pour le contexte, voici les comptes de cycles enregistrés que Anthropic a utilisé comme référence :

Votre objectif est de finir en dessous du seuil 1487.

Au-delà du challenge

Même si vous ne parvenez pas à battre le record, le processus enseigne :

• Compétences de profilage – Comment isoler les goulets d’étranglement en Python.
• Pensée algorithmique – Équilibrer temps vs. espace.
• Reproductibilité – L’importance d’un harness de test propre.

Vous pouvez également expérimenter avec le dépôt en ajoutant vos propres tests, ou en transférant la logique vers un autre langage. N’hésitez pas à forker et partager vos découvertes avec la communauté.

Réflexions finales

Le Performance Take‑Home d’Anthropic est plus qu’un simple exercice de code ; c’est un aperçu de l’ingénierie réelle qui sous-tend les modèles linguistiques de pointe. Que vous visiez un poste dans un laboratoire d’IA de premier plan ou que vous aimiez simplement maximiser les performances de Python, ce dépôt fournit un défi concret et mesurable.

Maintenant que vous avez la carte, il est temps de mettre les mains à la pâte. Clonez le dépôt, profilez, ajustez et voyez si vous pouvez battre la barre des 2 heures. Bonne chance !