Imaginez que vous enseigniez à un robot brillant et super rapide à écrire du code informatique. Ce robot, connu sous le nom de Modèle de Langage Étendu (LLM), a lu presque tous les livres et sites web d'Internet. Il est incroyable pour deviner quels mots devraient suivre, un peu comme une auto-complétion très avancée. Mais voici la partie délicate : le fait qu'un robot écrive du code qui semble correct ne signifie pas qu'il fonctionne réellement. Il pourrait écrire une phrase qui semble parfaite mais qui plante au moment où vous essayez de l'exécuter. Pour corriger cela, les scientifiques utilisent des « benchmarks » (tests de référence), qui sont comme des examens blancs où le code est réellement exécuté contre un ensemble de tests. Si le code réussit les tests, il gagne un point ; s'il plante ou donne une mauvaise réponse, il échoue. La grande question dans ce domaine est la suivante : comment faire en sorte que ces robots ne soient pas seulement intelligents en apparence, mais qu'ils soient réellement assez intelligents pour résoudre de vrais problèmes sans que nous ayons à reconstruire tout leur cerveau ?

Entrez dans une nouvelle étude qui suggère que nous n'avons pas besoin de reconstruire le cerveau du robot. Au lieu de cela, les chercheurs, Erxue Zhou, Jingxiang Meng et Aofan Liu, proposent une astuce ingénieuse en trois étapes appelée RAV (qui signifie Route, Align et Verify — Router, Aligner et Vérifier). Pensez à cela comme à la préparation d'un étudiant pour un examen important. Premièrement, vous ne lui donnez pas simplement un guide d'étude générique ; vous déterminez exactement quel type de problème il est confronté et vous lui donnez le bon type d'indice (Route). Deuxèmement, vous vous assurez que la façon dont vous l'avez enseigné en classe correspond exactement à la façon dont les questions de l'examen sont rédigées, afin qu'il ne soit pas confus par la formulation (Align). Enfin, au lieu de le laisser rendre une seule réponse, vous lui demandez d'écrire dix solutions différentes, de passer une vérification rapide sur chacune d'elles, et de choisir celle qui fonctionne réellement (Verify). L'article suggère qu'en coordonnant ces trois étapes, vous pouvez obtenir de bien meilleurs résultats sans modifier le modèle sous-jacent.

Le tour de magie en trois étapes

Les chercheurs ont testé leur idée sur un ensemble populaire de défis de codage appelé MBPP. Ils ont commencé avec un modèle de codage standard et puissant (Qwen2.5-Coder-7B-Instruct) et ont demandé : « Pouvons-nous rendre ce modèle spécifique meilleur pour réussir les tests simplement en changeant la façon dont nous lui parlons et dont nous choisissons ses réponses ? »

Voici comment fonctionne leur cadre en trois étapes, en utilisant une analogie ludique :

1. Route : Le réceptionniste intelligent
Imaginez un bureau très occupé où un réceptionniste reçoit des milliers de demandes différentes. Si vous dites simplement « Aidez-moi avec un problème », le réceptionniste pourrait donner une réponse générique qui ne convient pas. Mais que se passerait-il si le réceptionniste pouvait regarder votre demande et dire : « Oh, vous traitez une chaîne de lettres ? Utilisons le guide du 'Spécialiste des chaînes de caractères' ! » ou « Vous faites des mathématiques ? Passons au guide du 'Magicien des Maths' ! ».
Dans l'article, il s'agit de l'étape Route. Avant même que le modèle ne commence à écrire du code, un « routeur » léger examine la tâche. Si la tâche concerne la manipulation de texte (comme trouver un palindrome), il utilise un style de prompt spécifique. S'il s'agit de mathématiques ou d'algorithmes, il change de style. Cela garantit que le modèle reçoit la bonne « saveur » d'instructions pour le travail spécifique, plutôt qu'un prompt universel.

2. Align : Le match d'entraînement
Maintenant, imaginez que vous ayez entraîné un joueur de football en utilisant des exercices qui ne ressemblaient en rien au vrai match. Vous avez pratiqué avec un ballon lourd sur un terrain boueux, mais le vrai match se joue avec un ballon léger sur de l'herbe. Le joueur peut être excellent lors des exercices mais médiocre pendant le match. C'est un « décalage ».
Dans le monde de l'IA, les modèles sont souvent entraînés sur un type d'instruction mais testés sur un autre. L'étape Align corrige cela. Les chercheurs ont pris leurs données d'entraînement et ont réécrit les instructions pour qu'elles ressemblent exactement aux prompts « routés » que le modèle verrait lors du test. Ils ont utilisé une technique appelée LoRA (une façon d'enseigner de nouveaux tours au modèle sans réécrire tout son cerveau) pour apprendre spécifiquement au modèle comment répondre à ces nouveaux styles spécifiques aux tâches. C'est comme donner au joueur de football des exercices d'entraînement qui imitent parfaitement les conditions réelles du match.

3. Verify : Le filet de sécurité
Enfin, même avec le meilleur entraînement et les bons indices, le modèle peut encore commettre une erreur lors de sa première tentative. Par le passé, les gens se contentaient souvent de la première réponse donnée par le modèle. Mais et si le modèle pouvait générer dix réponses différentes, et que nous choisissions la meilleure ?
C'est l'étape Verify. Le modèle génère plusieurs versions du code (un « pool de candidats »). Ensuite, le système exécute chaque version contre les tests publics inclus dans le problème. C'est comme un professeur qui corrige dix essais différents et ne rend que celui qui a obtenu un A. Le système choisit le code qui réussit réellement les tests. Si deux codes réussissent, il choisit le plus court. Cette étape transforme un « peut-être » en un « oui ».

Ce qu'ils ont trouvé

Lorsque les chercheurs ont combiné toutes les trois étapes, les résultats ont été impressionnants. Ils ont testé l'intégralité de leur pipeline RAV sur le benchmark MBPP.

• Sur l'ensemble MBPP Sanitized (une version propre du test), leur méthode a obtenu un score de 0,8911.
• Sur l'ensemble MBPP Full (la version complète et plus difficile), ils ont atteint 0,8520.

Pour mettre cela en perspective, le modèle original sans ces astuces a obtenu un score de 0,8276 sur l'ensemble sanitised et de 0,7528 sur l'ensemble full. Cela signifie que la méthode RAV a amélioré le taux de réussite de 6,35 points de pourcentage sur l'ensemble sanitised et de 9,92 points de pourcentage sur l'ensemble full.

La recette secrète : Pourquoi cela fonctionne ensemble

La partie la plus intéressante de l'étude est ce qui s'est passé lorsqu'ils ont testé les étapes seules.

• S'ils ont simplement utilisé Route et Align mais n'ont pas vérifié les réponses (pas de Verify), l'amélioration a été infime. C'était comme avoir un excellent élève qui rend quand même un premier brouillon de ses devoirs sans vérifier les erreurs.
• Cependant, lorsqu'ils ont combiné Route ou Align avec Verify, les scores ont bondi de manière significative.

Cela suggère que Route et Align ne rendent pas nécessairement le modèle capable d'écrire la réponse parfaite dès le premier essai. Au lieu de cela, ils lui permettent d'écrire une meilleure liste d'options. Ils augmentent les chances qu'une réponse correcte soit cachée quelque part dans le tas de code généré. Ensuite, Verify agit comme le détective qui trouve cette réponse correcte cachée et la sélectionne.

Les auteurs ont répété les tests plusieurs fois pour s'assurer que les résultats n'étaient pas dus à la chance. Sur l'ensemble plus difficile « Full », l'amélioration était très stable. Ils ont également vérifié que le modèle n'avait pas simplement mémorisé les réponses des données d'entraînement (un problème appelé « contamination »), et ils n'ont trouvé aucune preuve de cela.

La conclusion

L'article suggère que nous n'avons pas besoin d'inventer un nouveau cerveau de robot géant, super coûteux, pour obtenir un meilleur code. Au lieu de cela, nous pouvons obtenir de bien meilleurs résultats en étant plus intelligents dans la façon dont nous posons les questions (Route), dont nous pratiquons avec le modèle (Align) et dont nous choisissons la réponse finale (Verify). C'est un rappel que parfois, la meilleure façon d'améliorer un système n'est pas de construire un moteur plus gros, mais de régler le conducteur, la carte et le processus de vérification de l'arrivée.