Le dilemme du détective : Pourquoi une solution unique ne convient pas à tous

Imaginez que vous essayiez d'attraper un voleur. Vous engagez un détective brillant qui est un expert pour repérer les voleurs portant des chapeaux rouges. Il est exceptionnel dans son travail, mais si le voleur se présente avec un chapeau bleu, le détective est complètement confus et le laisse passer. Maintenant, imaginez que vous deviez attraper des voleurs avec des chapeaux rouges, des chapeaux bleus, des chapeaux verts et même des chapeaux invisibles. Vous pourriez engager toute une équipe de spécialistes, un pour chaque couleur de chapeau, mais c'est coûteux et complexe à gérer. Alternativement, vous pourriez essayer d'entraîner un « super détective » pour repérer toutes les couleurs de chapeaux à la fois. Mais attention : quand vous essayez d'apprendre tout à une seule personne, elle finit souvent par être confuse et devient moins efficace pour repérer n'importe quel chapeau spécifique que ne l'étaient les spécialistes.

C'est exactement le problème auquel les informaticiens sont confrontés avec la détection de clones de code. Les clones de code sont comme des versions copiées-collées ou légèrement modifiées de programmes informatiques. Ils peuvent être des copies identiques, avoir des variables renommées, ou même être du code écrit dans des langages différents (comme Python vs Java) qui fait la même chose. Récemment, l'IA a commencé à écrire son propre code, créant un nouveau type de « clone » qui ne ressemble en rien au code humain.

Pour trouver ces clones, les chercheurs construisent des modèles de deep learning — des cerveaux informatiques entraînés pour repérer les similitudes. Le problème est que ces modèles sont comme notre détective au chapeau rouge : ce sont des spécialistes. Un modèle entraîné pour trouver des clones dans le code Java échoue souvent lamentablement lorsqu'on lui présente du code Python, et un modèle entraîné sur du code écrit par l'humain se perd face au code généré par l'IA. Cela crée une « crise de fragmentation » où les équipes doivent exécuter des dizaines de modèles différents pour couvrir tous les cas de figure, ce qui est lent et impraticable. La grande question est la suivante : Pouvons-nous combiner ces modèles spécialistes en un seul super-modèle sans avoir à les réentraîner de zéro ?

La magie de la « fusion de modèles » (Model Merging)

Cet article, intitulé « A Unified Model for Cross-Domain Clone Detection via Model Merging », explore une astuce ingénieuse appelée fusion de modèles. Au lieu de réentraîner un modèle (ce qui nécessite toutes les données d'origine et prend beaucoup de temps), les chercheurs prennent deux ou plusieurs modèles spécialistes déjà entraînés et les « recousent » mathématiquement. Pensez à prendre deux recettes différentes de soupe — une pour la soupe à la tomate et une pour la soupe à la pomme de terre — et essayez de mélanger les ingrédients dans la marmite pour faire une parfaite « soupe Tomate-Pomme de terre » sans cuisiner une nouvelle fournée à partir de zéro.

Les chercheurs ont testé cette idée sur la détection de clones de code. Ils ont pris des modèles qui étaient experts dans la détection de clones d'un même langage et des modèles qui étaient experts dans la détection de clones entre différents langages. Ils ont essayé diverses façons de les mélanger :

1. Moyenne simple : Prendre simplement la moyenne des « cerveaux » des deux modèles.
2. TIES : Une méthode qui décide soigneusement quelles parties des modèles sont en accord et lesquelles sont en désaccord, en gardant les meilleures parties et en écartant les parties conflictuelles.
3. WUDI : Une méthode qui tente de minimiser le « bruit » ou l'interférence entre les deux modèles.
4. Assemblage de couches (Layer Stitching) : Au lieu de mélanger tout le cerveau, ils ont essayé de remplacer des couches spécifiques (comme remplacer les « yeux » d'un modèle par les « oreilles » d'un autre) pour voir s'ils pouvaient construire un hybride meilleur.

La grande découverte : Vous avez besoin de la même « base »

La découverte la plus importante de cette étude est une règle simple : Vous ne pouvez fusionner des modèles avec succès que s'ils sont partis de la même « base ».

Imaginez que vous avez deux chefs cuisiniers. Le Chef A a appris à cuisiner auprès d'un maître chef spécifique (appelons-le « Master UniX »). Le Chef B a appris auprès d'un maître chef complètement différent (« Master CodeBERT »). Si vous essayez de mélanger leurs recettes, les saveurs s'entrechoquent et la soupe a un goût terrible. Cependant, si le Chef A et le Chef B ont tous deux appris de « Master UniX », leurs techniques sont compatibles. Lorsque vous mélangez leurs recettes, elles se marient magnifiquement.

Les chercheurs ont découvert que lorsqu'ils fusionnaient des modèles partageant la même base pré-entraînée (comme deux versions différentes du modèle UniXcoder), le résultat était un puissant détecteur cross-domain. Ce modèle fusionné pouvait repérer des clones dans des scénarios de même langage et de langages différents presque aussi bien que s'il avait été entraîné sur toutes les données à la fois, mais il l'a fait sans avoir besoin de données d'entraînement lors de l'étape de fusion. C'était rapide, prenant moins de cinq minutes sur un seul processeur informatique.

Cependant, lorsqu'ils ont essayé de fusionner des modèles provenant de bases différentes (comme mélanger UniXcoder avec CodeBERT), les résultats étaient désordonnés et peu fiables. Les « saveurs » s'entrechoquaient et le modèle fusionné performait mal. Cela suggère que le modèle « de base » est la colle qui maintient les connaissances fusionnées ensemble.

Le vainqueur surprenant : TIES vs WUDI

Les chercheurs ont également découvert un compromis entre différentes méthodes de fusion.

• WUDI était le meilleur pour trouver des clones dans les types de code qu'il avait déjà vus auparavant (en distribution/in-distribution). C'était le « spécialiste » le plus précis.
• TIES, cependant, était le meilleur « généraliste ». Lorsque les chercheurs ont testé les modèles fusionnés sur des clones générés par l'IA inédits (du code écrit par l'IA que les modèles n'avaient jamais vus auparavant), les modèles fusionnés avec TIES ont obtenu des performances nettement supérieures.

C'est un aperçu crucial. Bien que WUDI soit légèrement plus précis sur les données connues, TIES est plus robuste face à l'inconnu. Les auteurs suggèrent que pour une utilisation dans le monde réel, où l'on peut rencontrer des types étranges et nouveaux de code généré par l'IA, TIES est le choix le plus sûr et le plus pratique.

Battre les géants

L'article a également comparé leurs modèles fusionnés à deux autres approches :

1. Entraînement multi-tâches (Multi-task Training) : C'est la méthode traditionnelle consistant à entraîner un modèle sur toutes les données à la fois. Bien que cela ait bien fonctionné sur les données connues, cela s'est complètement effondré face aux clones générés par l'IA. Il semble que le fait d'essayer de tout apprendre à la fois rende le modèle sujet au « surapprentissage » (overfitting) et lui fasse oublier comment gérer les surprises.
2. Grands Modèles de Langage (LLM) : Les chercheurs ont testé de gigantesques modèles d'IA (comme Qwen et DeepSeek) à qui l'on demandait de détecter des clones simplement en lisant une instruction (zero-shot). Bien que ces géants soient corrects, ils étaient beaucoup plus lents et moins précis que les modèles fusionnés. Les modèles fusionnés étaient des ordres de grandeur plus rapides et plus précis.

Ce qu'il faut retenir

L'article conclut par une recette pratique pour les ingénieurs logiciels :

1. Choisissez un modèle pré-entraîné (comme UniXcoder).
2. Affinez-le (fine-tune) séparément pour chaque domaine spécifique qui vous intéresse (par exemple, une version pour Java, une autre pour Python).
3. Utilisez la méthode TIES pour les fusionner.

Cette approche crée un détecteur unifié qui est rapide, précis et étonnamment bon pour gérer de nouveaux types de clones de code non vus, le tout sans le coût élevé d'un réentraînement ou de la gestion d'une flotte de modèles différents. Cela suggère que dans le monde de l'IA, parfois, la meilleure façon d'avancer n'est pas de construire un cerveau plus gros, mais de combiner intelligemment les cerveaux que vous possédez déjà.