CourionAI
FR
Newsletter
← Toutes les actus
ai-basics 3 min de lecture

Ce conseil sur la langue dans laquelle les codes d'IA sont les meilleurs ? Il s'effondre sur le vrai travail

Dan Luu a réitéré l'affirmation populaire selon laquelle les langages dynamiques sont moins chers pour les agents de codage. Sur deux tâches importantes, l’effet a disparu et le deuxième critère le plus cité s’est avéré dépassé.

Un panneau de papier plié montrant des sommets spectaculaires, la même feuille se dépliant largement pour révéler que les barres sont presque de niveau

Il existe un conseil selon lequel si vous souhaitez qu’un agent de codage d’IA soit bon marché et efficace, vous devez choisir un langage compact et typé dynamiquement. Le propre résumé de l’IA de Google le répète. Dan Luu, un ingénieur ayant une longue expérience dans la analyse des revendications populaires, a effectué ses propres tests. Sur tout ce qui ressemble à une véritable œuvre, l’effet disparaît.

L’affirmation initiale provenait d’un benchmark mesurant le nombre de tokens, les petits morceaux de texte qu’un modèle lit, écrit et est facturé, différentes langues doivent résoudre les problèmes de Rosetta Code. Il a trouvé un écart de 2,6 fois entre C, le pire, et Clojure, le meilleur, et une victoire encore plus importante pour le langage de tableau J, à environ 70 tokens par solution. L’objection de Luu est directe : un problème que vous pouvez résoudre en 70 tokens n’est pas un problème. La majeure partie du travail consiste à imprimer la réponse.

Il a donc construit deux tests plus difficiles. Dans la première, les agents ont reçu la spécification de compression zstd et ont été invités à implémenter un décodeur fonctionnel, sans accès à Internet et sans vue des tests. Dans la seconde, ils ont reçu le benchmark du convertisseur de documents Pandoc et ont été notés par rapport à des tests qu’ils n’avaient jamais vus. Dans les deux cas, aucun gagnant clair n’est apparu entre les langages statiques et dynamiques. Avec un effort de raisonnement plus élevé, plusieurs langages statiques sont arrivés en tête. Les langages denses et obscurs qui semblaient si impressionnants sur les problèmes de jouets ont mal fonctionné, ce qui correspond à une explication simple : les laboratoires d’IA consacrent leurs efforts de formation aux langages que les gens utilisent réellement.

Qu’est-ce qu’il y a derrière

La partie la plus utile de l’article est l’autopsie des autres références citées. Un test y a exécuté un exécutable sur un chemin qui n’existait pas, donc chaque exécution de Rust a échoué. Une exécution ultérieure de Go a “corrigé” ce problème en créant un lien symbolique vers son propre binaire, ce qui signifiait que chaque test ultérieur dans chaque langue exécutait silencieusement le programme Go. L’auteur de l’benchmark a conclu que Rust rencontre des difficultés car il s’agit d’un langage difficile. Bien noté, Rust obtient une note parfaite. Deux autres tests présentaient une erreur de copier-coller qui les faisait réussir, peu importe ce que faisait le code.

Luu fait également attention à son propre travail. Il note qu’il a corrigé plus d’une centaine de bogues de configuration et s’attend à ce qu’il en reste davantage, et il refuse de faire des réclamations sur les langues individuelles de deux tâches. Le seul modèle qu’il défendra est faible mais cohérent : les langues les plus populaires ont tendance à produire des résultats plus corrects et moins chers.

Ce que cela signifie pour vous: Ne changez pas de langue, car un tableau indique qu’un agent y serait moins cher. Restez fidèle à quelque chose de courant et bien pris en charge. Plus largement, c’est une bonne leçon sur la manière dont les tests d’IA tournent mal : un résultat frappant sur de petits problèmes cesse généralement de l’être dès que le problème devient suffisamment important pour avoir de l’importance. Lorsque vous en voyez un, demandez à quel point les tâches étaient difficiles.

Sources

Sources: https://danluu.com/pl-tokens/

Article suivant

Le créateur de Redis a créé un modèle vidéo chinois sur un Mac. Les Européens ne sont pas autorisés à l'utiliser

Salvatore Sanfilippo a publié h3.c, un moteur C et Metal qui exécute MiniMax H3 nativement sur Apple Silicon. La propre licence du modèle exclut l'UE, le Royaume-Uni, les États-Unis et la Corée du Sud du déploiement local.

Un petit ordinateur de bureau projetant une bande d'images de film, entourée d'une palissade avec des poteaux frontières rayés