Un stagiaire Databricks enseigne à l'IA comment améliorer la correction rapide de code
Tout comme les humains affinent leurs compétences par la pratique itérative et l’apprentissage de leurs erreurs, les modèles d’intelligence artificielle sont désormais entraînés à perfectionner leur art dans des domaines complexes comme la réparation de code. Cette boucle de rétroaction fondamentale était au cœur d’un récent projet de stage d’été chez Databricks, visant à élever les capacités de son assistant de code. L’initiative s’est concentrée sur l’enseignement à un “modèle de récompense” spécialisé pour discerner et prioriser les corrections de code optimales, une étape cruciale dans la construction d’un outil de développement sophistiqué.
L’innovation principale est la fonction “Quick Fix” de Databricks, intégrée de manière transparente dans ses Notebooks et éditeurs SQL. Conçue pour des résolutions rapides et hautement fiables, Quick Fix cible les problèmes courants tels que les erreurs de syntaxe, les noms de colonnes mal orthographiés et les problèmes simples d’exécution. Lorsqu’un développeur rencontre une erreur, Quick Fix entre en action, analysant le code problématique et son message d’erreur associé. Il exploite ensuite un grand modèle linguistique (LLM) pour générer rapidement une solution ciblée, généralement en une à trois secondes.
Bien que Quick Fix ait déjà fourni une assistance précieuse, le défi consistait à améliorer sa précision. Même après qu’une correction ait été générée et ait passé les vérifications syntaxiques de base, comment le système pouvait-il garantir que c’était la solution la plus pertinente et la plus précise pour l’utilisateur ? La réponse est apparue grâce à une technique connue sous le nom d’“échantillonnage best-of-k”. Cette approche implique la génération de plusieurs suggestions de correction potentielles, puis l’emploi d’un modèle de récompense sophistiqué pour évaluer et sélectionner la meilleure option unique.
Le projet a englobé à la fois l’ingénierie backend et la recherche expérimentale. La phase initiale s’est concentrée sur l’extension du système Quick Fix pour générer un large éventail de suggestions en parallèle. Cela impliquait d’expérimenter diverses invites et informations contextuelles, y compris des techniques comme le raisonnement en “chaîne de pensée”, le raisonnement basé sur les sorties prédites et des variations dans les invites système, ainsi qu’un contexte de base de données sélectif. Bien que ces méthodes aient amélioré la qualité et la variété des suggestions, elles ont également introduit un certain degré de délai de traitement, soulignant un compromis critique entre la qualité de la sortie et la vitesse opérationnelle.
Une fois que plusieurs suggestions ont été générées, l’étape suivante consistait à identifier la plus prometteuse à présenter à l’utilisateur. Une première tentative a impliqué un simple système de vote majoritaire, qui, malgré de bonnes performances lors de tests isolés, n’a pas produit d’améliorations significatives lors des tests A/B utilisateurs en situation réelle et n’a donc pas été déployé. La solution plus efficace a consisté à développer et à entraîner des modèles de récompense dédiés. Ces modèles ont été conçus pour prédire quelles corrections proposées les utilisateurs accepteraient et exécuteraient avec succès. Il est intéressant de noter que le processus de développement a utilisé à la fois des méthodes d’apprentissage automatique traditionnelles, telles que la régression logistique et les arbres de décision boostés par gradient (en utilisant spécifiquement le package LightGBM), ainsi que des grands modèles linguistiques plus contemporains et affinés.
Une découverte notable est ressortie de l’évaluation : pour la tâche spécifique de prédiction de l’acceptation et de la réussite d’exécution par l’utilisateur, les modèles d’apprentissage automatique classiques ont obtenu des performances comparables à celles des LLM affinés, plus gourmands en ressources, lors des évaluations hors ligne. Le modèle d’arbre de décision, en particulier, s’est avéré très efficace. Son succès a été attribué au fait que, pour les types d’erreurs que Quick Fix aborde, les modifications de code qui semblent correctes le sont souvent. Les caractéristiques clés qui ont éclairé ses décisions comprenaient la similarité entre la ligne de code originale et la correction générée, ainsi que le type d’erreur spécifique rencontré.
Compte tenu de ses performances comparables et, surtout, de son temps d’inférence considérablement plus rapide, le modèle d’arbre de décision LightGBM a finalement été choisi pour être déployé en production. La vitesse est primordiale pour Quick Fix ; les suggestions doivent apparaître presque instantanément, avant qu’un développeur ne puisse intervenir manuellement, car tout délai réduit le nombre d’erreurs pouvant être résolues rapidement. La taille compacte du modèle LightGBM l’a également rendu remarquablement économe en ressources et plus facile à intégrer dans l’infrastructure existante. Grâce à une combinaison d’optimisations de modèles et d’infrastructure, le temps d’inférence moyen a été considérablement réduit de près de cent fois. Cette implémentation de l’approche best-of-k, associée au modèle de récompense, a conduit à une augmentation mesurable du taux d’acceptation interne de Databricks, se traduisant directement par une qualité supérieure et une expérience plus fluide pour les utilisateurs, tout en maintenant la latence du système dans des limites acceptables.