Demander à un LLM d'« écrire un meilleur code » à plusieurs reprises permet-il d'obtenir un meilleur code ?

• Cette expérience teste si demander à un LLM de « écrire un meilleur code » à plusieurs reprises améliore réellement le code.
• L'exemple de base s'inspire d'un mème de la fonction de génération d'images DALL-E de ChatGPT demandant de rendre le résultat « plus ...-like ».

Expérience de prompts répétitifs simples

• Un prompt de codage Python a été donné à Claude 3.5 Sonnet pour résoudre un problème simple mais optimisable.
• Implémentation de base
  • Trouver la différence entre le minimum et le maximum parmi un million d'entiers aléatoires entre 1 et 100 000 dont la somme des chiffres vaut 30
  • L'implémentation simple a pris 657 ms (en utilisant la conversion str de Python)
• Itération #1
  • J'ai demandé à Claude d'« écrire un meilleur code » afin d'améliorer le code
  • Claude a refactorisé le code sous forme de classe Python et de manière orientée objet, et a pré-calculé la somme des chiffres pour tous les nombres
  • 2,7 fois plus rapide
• Itération #2
  • Claude a encore optimisé le code en utilisant le multithreading et des opérations numpy vectorisées
  • 5,1 fois plus rapide
• Itération #3
  • Le code est devenu plus complexe et est revenu à la conversion de chaînes de caractères
  • 4,1 fois plus rapide
• Itération #4
  • Claude a utilisé la bibliothèque Python numba pour appeler le compilateur JIT et utilisé asyncio pour implémenter la parallélisation
  • Amélioration de la vitesse jusqu'à 100 fois
  • Plutôt qu'un code « transformé de manière cosmique », le résultat est devenu un code surdimensionné de type « entreprise »

Application du prompt engineering

• Le prompt engineering est nécessaire pour optimiser les sorties du LLM
• Claude 3.5 Sonnet a une forte capacité à suivre les instructions de prompt, et il peut produire de meilleurs résultats si les consignes sont claires
• Au lieu de simplement dire « écrire un meilleur code », un prompt système avec des consignes précises a été utilisé
• Prompt initial
  • La définition de ce qu'est un « code optimisé » a été détaillée (algorithme, parallélisation, minimisation du code inutile, etc.)
  • Optimisation de la digit sum avec Numba dès l'implémentation initiale → 59 fois plus rapide
• Itération #1
  • Claude a ajouté la parallélisation, mais a introduit une opération de décalage de bits bizarre (pour l'hexadécimal), entraînant un bug
  • Les performances sont tombées à 9,1 fois
• Itération #2
  • Claude a essayé d'améliorer les performances avec des opérations SIMD, mais continue d'utiliser un mauvais décalage de bits.
  • Exécution 65 fois plus rapide que l'implémentation initiale
• Itération #3
  • Claude a optimisé les performances avec une table de hachage
  • Exécution 100 fois plus rapide que l'implémentation initiale
• Itération #3
  • Claude a corrigé le décalage de bits incorrect, ce qui a légèrement dégradé les performances
  • Exécution 95 fois plus rapide que l'implémentation initiale

Conclusion

• Même avec un prompt ambigu comme « écrire un meilleur code », une amélioration progressive est possible
• Avec du prompt engineering, en précisant clairement la direction souhaitée (opérations numériques, JIT, parallélisation, etc.), on obtient plus vite du code plus évolué
• Les idées d'optimisation automatisées peuvent révéler de nouveaux outils (comme numba), mais l'ingénieur doit toujours valider les bugs et les utiliser de manière sélective
• Dans un système opérationnel réel, les contraintes métier et les besoins de vérification sont trop importants pour écrire directement tout le code proposé par un LLM
• Cette expérience concerne le code Python, mais dans des intégrations avec d'autres langages (comme Rust via PyO3), les idées d'optimisation d'un LLM ont également un potentiel d'application

[GN⁺]

Commentaires Hacker News

• En matière d\u2019optimisation de code, il est efficace de tester d\u2019abord si un nombre est plus petit que la borne minimale ou plus grand que la borne maximale. Cela permet de le faire avant de calculer la somme des chiffres et d\u2019accroître la vitesse de 5,5x. Il est possible de le faire avec numpy sans utiliser Numba.

• Les LLM comme GPT fournissent souvent des résultats de qualité moyenne au départ, et l\u2019auteur affirme qu\u2019on peut obtenir de meilleurs résultats grâce à certaines consignes.

• Les LLM sont des moteurs de simulation contextuelle, car ils simulent des modèles du monde réel via la prédiction de texte. Pour une prédiction textuelle précise, un modèle fidèle au monde réel est nécessaire.

• Les LLM ont tendance à être orientés vers la rédaction de code pour débutants, et il est efficace de spécifier les paquets et de demander un code simple.

• Sur Android/Kotlin, ChatGPT est inefficace et appelle fréquemment des méthodes invalides ou obsolètes.

• Il est important de commencer une session de code par une « planification ouverte » plutôt que par « la rédaction de code ». Il faut clarifier les hypothèses du LLM et ajuster le plan avant d\u2019écrire du code.

• Il explique comment supprimer et réinstaller complètement PostgreSQL sur Debian tout en préservant le répertoire de données, afin de garder la base de données existante.

• L\u2019optimisation de code peut ne pas être bonne trop tôt; il vaut mieux n\u2019optimiser que si nécessaire.

• Demander à plusieurs reprises de «\u00a0mieux coder\u00a0» peut dégrader les performances. Cela peut rendre la solution inutilisable.

• Les calculs sur LiveCode sont plus rapides que sous Python, avec une explication de la manière de calculer des sommes via des boucles.