Pour Gemma-3-27B, 80 dialogues synthétiques suffisent à entraîner les sondes d'activation, mais pas partout

Combien de dialogues synthétiques faut-il pour entraîner une sonde qui surveille le comportement d'un modèle de langage en production ? Les auteurs d'une étude récente publiée sur arXiv cs.LG ont mesuré cela directement. Leur réponse dépend de ce que la sonde surveille précisément. Sur Gemma-3-27B-IT, les sondes pour les « situations à enjeux élevés » et pour les réponses nuisibles à l'utilisateur se retrouvent à quelques centièmes de leur plateau dès 80 exemples. Les sondes qui détectent le non-respect d'une instruction de l'utilisateur en exigent plusieurs fois plus.

Le dispositif expérimental

Une sonde d'activation est un petit classifieur placé au-dessus des représentations internes du modèle. On l'entraîne généralement sur des conversations générées par une autre LLM, et jusqu'ici le budget de cette génération se fixait à l'œil. Les chercheurs ont construit des courbes d'apprentissage sur une plage de 10 à 590 échantillons synthétiques, pour trois concepts : les enjeux élevés, la réponse nuisible à l'humain et la réponse qui ne suit pas l'instruction. La qualité a été mesurée sur 14 distributions mises de côté. Le modèle générateur et le niveau de détail du prompt ont été variés séparément.

Les principaux paramètres de l'étude :

• trois concepts de monitoring : high-stakes, harmful, instruction ;
• quatre modèles de sonde, dont le principal est Gemma-3-27B-IT ;
• 14 distributions d'évaluation mises de côté ;
• de 10 à 590 échantillons synthétiques sur la courbe ;
• l'ordre des concepts selon leur « appétit » en données se maintient sur les trois modèles plus petits et sur des échantillons réels issus du jeu dev.

La couverture plutôt que la difficulté

Pour comparer les courbes, les auteurs ont introduit une grandeur, le half-gain size : le nombre d'échantillons à partir duquel la moitié du gain de qualité final est atteinte. Le concept et la distribution expliquent à eux deux 42–45 % de sa variance. Le générateur, le modèle de sonde et le niveau de détail du prompt n'en expliquent, tous ensemble, que moins de 10 %. Selon ces données, choisir un modèle générateur plus coûteux ou un prompt plus détaillé influe bien moins sur le besoin en données que l'objet même de la surveillance.

Les auteurs écartent l'explication intuitive selon laquelle certains concepts seraient simplement plus difficiles. Si l'on prend chaque « type » de données séparément (un par distribution d'évaluation), le half-gain size médian est de 7 à 11 échantillons synthétiques propres à ce type, et ce de façon identique pour les trois concepts. La difficulté à l'intérieur d'un même type est partout comparable.

Ce qui diffère, c'est la mesure dans laquelle les échantillons d'un type aident sur les autres types du même concept. Le transfert est quasi total pour high-stakes, moins bon pour harmful et le plus faible pour instruction. Les auteurs attribuent à ce déséquilibre l'essentiel de l'écart entre les concepts, tant sur les données générées que sur les données réelles.

Il en découle une conclusion sur le débat « largeur ou profondeur ». L'ancienne recommandation, qui consistait à consacrer le budget de génération à la diversité des types de données plutôt qu'au volume de chaque type, ne vaut pas partout de la même façon. Pour instruction, de nombreux types sont indispensables : aucun type n'en couvre un autre. Pour high-stakes, ils sont presque superflus, puisqu'un seul type couvre les autres.

Que faire du budget de génération

Pour une équipe qui construit un monitoring de déploiement, il est utile de commencer par vérifier le transfert entre types de données plutôt que par choisir un générateur. Si le concept ressemble à high-stakes, quelques dizaines d'exemples bien choisis suffisent, et les dépenses supplémentaires rapportent peu. S'il ressemble à instruction, il faut prévoir dès le départ une diversité de types et compter le volume en centaines. Un modèle générateur coûteux et un prompt ultra-détaillé feront économiser moins qu'on ne le croit : leur contribution à la variance du besoin en données est inférieure à 10 %.

Une réserve : toutes les conclusions reposent sur trois concepts et quatre sondes. Pour d'autres concepts, il faudra mesurer le besoin à nouveau, et la vérification du transfert entre types semble un outil praticable pour cela. Les auteurs ont publié les jeux d'évaluation, les jeux dev et les données générées : on peut donc reproduire les courbes sur sa propre stack sans annotation propre.