Optimiser l'apprentissage en contexte : des exemples en or pour les LLM
Les Grands Modèles de Langage (LLM) sont devenus essentiels dans diverses applications, et une technique clé pour guider leur comportement sans un réentraînement extensif est l’Apprentissage en Contexte (In-Context Learning, ICL). Cette méthode consiste à fournir à un LLM des exemples de paires entrée-sortie, lui permettant d’inférer le modèle ou le format souhaité avant d’aborder une nouvelle tâche. Les stratégies vont du “one-shot” (un seul exemple) au “few-shot” (plusieurs exemples) et à la “chaîne de pensée” (démontrant un raisonnement étape par étape).
Considérez une requête simple : demander à un LLM, “Quel animal fait le son ‘meuh’ et de quel type est-il ?” Sans guidance, un LLM comme ChatGPT pourrait fournir une réponse verbeuse, incluant des détails superflus sur d’autres types d’animaux. Cependant, en faisant précéder la requête d’exemples comme “Utilisateur : Quel animal fait le son ‘ouaf’ et de quel type est-il ? Assistant : Chien, mammifère” et “Utilisateur : Quel animal fait le son ‘miaou’ et de quel type est-il ? Assistant : Chat, mammifère”, le LLM apprend à produire le format concis et souhaité : “Vache, mammifère.” Cela démontre la puissance de l’ICL pour orienter la sortie d’un LLM sans le processus gourmand en ressources de réglage fin du modèle lui-même.
Bien que l’ICL soit très efficace pour améliorer les performances et la précision des LLM, il souffre d’un inconvénient majeur : sa fragilité. Le succès de l’ICL est remarquablement sensible aux exemples spécifiques choisis, à leur ordre et même à de légers changements de format. Cela est dû au fait que l’ICL opère davantage par correspondance de motifs superficielle que par une véritable compréhension conceptuelle. Pour des tâches complexes comme la réparation de code ou la conversion du langage naturel en requêtes SQL, une légère altération dans la sélection des exemples peut impacter drastiquement la précision. Le défi principal devient alors : comment sélectionner systématiquement des exemples qui aident réellement le LLM, plutôt que n’importe quels exemples ?
Pour aborder cette question critique, l’article de recherche de Google DeepMind, “AuPair: Golden Example Pairs for Code Repair”, introduit une approche systématique de sélection d’exemples, spécifiquement pour la correction de code buggé. Contrairement aux méthodes traditionnelles qui reposent sur la sélection aléatoire ou les recherches de similarité à partir d’un pool pré-curaté, AuPair se concentre sur la génération et l’extraction des paires d’exemples “dorées” les plus efficaces.
La méthodologie d’AuPair se déroule en deux phases distinctes. La première phase, la Génération de Paires d’Exemples, vise à créer une vaste collection de “paires de réparation” candidates. Elle commence par un ensemble de données de problèmes de codage qui incluent des cas de test. Un LLM est invité à générer une solution initiale (une “hypothèse”). Si cette hypothèse est partiellement correcte, elle est utilisée comme point de départ. L’étape cruciale consiste à demander au LLM de corriger ce code défectueux, en utilisant une invite “few-shot” informée par un petit ensemble de paires de réparation existantes, sélectionnées aléatoirement. Si la correction générée par le LLM améliore l’hypothèse originale, cette “hypothèse → correction” devient une paire candidate. Ingénieusement, si la correction est toujours imparfaite, elle est réintroduite dans le processus comme un nouveau code “défectueux”, créant des chaînes d’améliorations incrémentales. Cette boucle itérative et auto-améliorante est répétée des milliers de fois, construisant un riche pool de paires candidates couvrant divers types de bugs et leurs solutions.
La deuxième phase, l’Extraction de Paires Dorées, se concentre sur l’identification des paires les plus impactantes de ce pool généré. Cela implique un processus en deux étapes : mesurer l’efficacité, puis appliquer un algorithme de sélection glouton. Pour mesurer l’efficacité, AuPair crée un ensemble de données de validation de problèmes de code défectueux. Chaque paire de réparation candidate est ensuite utilisée comme un exemple “one-shot” pour générer une correction pour chaque problème de l’ensemble de validation. La correction résultante est testée par rapport aux cas unitaires, produisant un score. Ce processus génère une “matrice de qualité” complète, cartographiant la manière dont chaque paire candidate aide à résoudre divers problèmes de validation. L’efficacité étant quantifiée, un algorithme glouton sélectionne les paires “dorées”. Il choisit la paire candidate qui donne le score moyen le plus élevé sur tous les problèmes de validation. Crucialement, la contribution de cette paire sélectionnée est ensuite “soustraite” de toutes les paires restantes dans la matrice. Cela garantit que les sélections ultérieures sont complémentaires, empêchant la redondance et priorisant les paires qui abordent différents types de problèmes ou offrent des perspectives uniques. Cette sélection itérative se poursuit jusqu’à ce que l’amélioration marginale tombe en dessous d’un seuil défini, ce qui donne une liste ordonnée de paires dorées très efficaces et non redondantes.
L’efficacité d’AuPair a été rigoureusement testée sur sept ensembles de données de problèmes de codage à l’aide de cinq modèles LLM différents. Il a constamment surpassé les approches alternatives comme l’auto-réflexion et l’échantillonnage “best-of-N” en matière de résolution de problèmes. Une découverte notable a été l’efficacité computationnelle supérieure d’AuPair : seulement 12 paires dorées ont atteint la même performance que 32 paires sélectionnées aléatoirement, ce qui représente une amélioration de 2 à 3 fois. De plus, les paires dorées générées sur un ensemble de données (CodeForces) ont démontré de solides performances sur des ensembles de données entièrement différents (HackerEarth et AtCoder), soulignant leur transférabilité au sein du même domaine.
Malgré ses résultats prometteurs, AuPair a des limites. La génération initiale de paires d’exemples candidates, avec son processus de réparation itératif et de nombreux appels LLM, exige des ressources computationnelles substantielles. De plus, la méthode repose fortement sur des métriques d’évaluation quantifiables, telles que les tests unitaires pour le code, qui peuvent ne pas être facilement disponibles dans tous les domaines. Elle suppose également que des exemples complémentaires conduiront systématiquement à de meilleures performances, une hypothèse qui, bien que valide pour les problèmes de codage, pourrait ne pas être universelle. Enfin, AuPair a été évalué par rapport à des problèmes de concours structurés, laissant sa performance sur des bases de code plus complexes et réelles comme une question ouverte.
Néanmoins, AuPair représente un bond significatif dans l’optimisation de l’apprentissage en contexte pour des domaines spécifiques. En allant au-delà de la sélection arbitraire d’exemples vers une approche systématique pour identifier des modèles véritablement efficaces, il améliore les performances et l’efficacité des LLM. Bien qu’il nécessite un investissement computationnel initial considérable et des métriques d’évaluation spécifiques au domaine, la transférabilité avérée de ses “paires dorées” entre les ensembles de données suggère un retour sur investissement valable. Cette recherche ouvre la voie à l’application de techniques de sélection d’exemples intelligentes similaires à d’autres tâches complexes, telles que la génération de texte en SQL, où l’efficacité des exemples peut être systématiquement mesurée et organisée.