Du jeu de données
au modèle entraîné.

Longueurs en tokens Qwen 3.5 de la séquence complète : system + user + préambule assistant + SQL cible + <|im_end|>. P95 et P99 utilisent le rang le plus proche.

Vert : meilleure valeur Qwen de la colonne. Rouge : moins bonne valeur Qwen. GPT‑5.6 Luna est exclu de ces repères.

Pour rappel, nous avions sur les modèles de base :

Les pourcentages correspondent à l’execution accuracy sur les 1 034 exemples de validation :

Bien que le meilleur score de validation soit obtenu avec r=32 et α=64, son avantage reste limité. Il ne justifie pas nécessairement un adaptateur plus grand, donc davantage de paramètres LoRA à entraîner, lorsque les configurations plus légères produisent des résultats très proches. Nous retenons donc le plus petit couple, r=8 et α=16, pour la suite des essais.

Le jeu d’entraînement sera découpé en quatre volumes : 25 %, 50 %, 75 % et 100 %. Les sous-ensembles seront imbriqués (25% ⊂ 50% ⊂ 75% ⊂ 100%) et construits par échantillonnage contrôlé selon les db_id et la difficulté Spider (easy, medium, hard, extra) : chaque base et chaque niveau de difficulté y contribueront proportionnellement à leur nombre d’exemples. Cela permet de conserver une diversité raisonnablement représentative des bases, schémas et requêtes à chaque niveau.

Spider ne fournit pas directement ces niveaux de difficulté dans ses fichiers train. Ils sont recalculés à partir de l’AST SQL gold avec les règles de son évaluateur officiel, qui classe chaque requête en easy, medium, hard ou extra.

Meilleure Execution Accuracy observée sur le jeu de validation pour chaque volume d’entraînement :

Commençons d’abord par regarder où notre modèle fait le plus d’erreurs.

Le run entraîné sur 100 % des données est évalué sur les 1 034 exemples de validation. Les niveaux de difficulté sont calculés avec les règles de l’évaluateur officiel Spider.

Nous allons maintenant tenter quatre expériences (A, B, C et D), en faisant varier la nature des données ajoutées et le type de bases concernées :

Objectif commun : 5 000 nouvelles paires d'exemples par dataset (question en français - requête SQL attendue).

Pipeline de création des 100 bases fictives

Pipeline de création des nouvelles données d’entraînement

Les quatre expériences ajoutent 5 000 exemples synthétiques au train Spider initial (8 651 exemples), avec la même configuration Qwen 3.5 2B, LoRA r=8 · α=16, learning rate 1e-4 et 3 époques. Le tableau retient le meilleur checkpoint de chaque expérience sur les 1 034 exemples du jeu de validation.

Execution Accuracy sur les 1 034 exemples de validation, ventilée selon la difficulté Spider. Le nombre entre parenthèses correspond aux requêtes correctes sur le total de la catégorie.

La cause se trouve dans notre pipeline de génération. Pour que le classifieur Spider accepte les requêtes, les prompts envoyés à GPT-5.6 Luna imposaient une seule forme de SQL par difficulté. Ces requêtes sont difficiles pour le classifieur, mais pas pour le modèle.

Or ces opérations absentes sont justement celles que le modèle rate. Sur les 347 erreurs du baseline (comparaison stricte), 75 sont des erreurs no such column, souvent une colonne cherchée dans la mauvaise table lors d’une jointure.

Deux éléments rendaient aussi la lecture de 06.2 difficile :

• Le bruit de mesure. Un simple changement d’hyperparamètre fait déjà basculer environ 90 exemples de validation, sur 1 034. Un écart de 1 ou 2 points sur un seul run ne prouve donc rien.
• Un évaluateur trop strict. Il compare les résultats dans l’ordre exact, y compris l’ordre des lignes sans ORDER BY et celui des colonnes. Une comparaison façon Spider, sans ordre des lignes quand la référence n’a pas d’ORDER BY et avec colonnes permutables, ajoute environ 3 points à tous les runs, sans changer leur classement.

A2 reprend les conditions du dataset A (146 bases existantes, 5 000 exemples, tous niveaux, au prorata de chaque base). Seule la méthode de génération change :

• Plus de forme imposée. Chaque prompt montre 16 exemples réels du train Spider, pris sur d’autres bases, et demande pour chacun une paire de même structure sur la base cible.
• Des valeurs réelles. Le prompt contient 3 lignes par table, pour que les valeurs utilisées dans les filtres existent.
• Un juge différent. La question posée est : un expert écrirait-il une requête au résultat identique ? Les conventions de Spider sont acceptées, et les paires rejetées sont écartées plutôt que réécrites. Le juge est Claude Haiku 5.5, testé au préalable contre GPT-5.6 Terra sur 168 paires.

Le niveau extra représente 15,8 % de l’export contre 20,3 % dans le train Spider, car le juge le rejette plus souvent. Les contrôles de résultat vide ne s’appliquent pas aux 7 bases Spider livrées sans aucune ligne.

Les 5 000 paires de A2 retrouvent la diversité de Spider : 1 030 structures SQL distinctes contre 1 012 sur un échantillon de même taille, 41,6 % de JOIN (43,6 % dans Spider), 21,4 % d’ORDER BY (20,2 %) et 6,6 % d’opérations ensemblistes (6,4 %). Seules les requêtes à 2 JOIN ou plus restent en retrait, à 14,0 % contre 18,6 %.

Nous comparons A2 au train Spider seul avec deux graines aléatoires, à l’époque 3 et avec la même configuration que 06.2. Les deux graines n’ont pas tourné sur la même machine : il ne faut donc comparer les runs qu’à l’intérieur d’une même graine.

Exemples gagnés et perdus et IC 95 % en comparaison façon Spider. L’intervalle provient d’un bootstrap par base de validation. Le test de McNemar apparié donne p < 0,01 sur les deux paires.

Par difficulté Spider, en comparaison stricte :

Par type de requête, en comparaison façon Spider et en moyenne sur les deux graines :

Un même exemple peut compter dans plusieurs lignes. Les petites catégories restent peu précises. Erreurs no such column : 75 → 60 en graine 42, 74 → 52 en graine 7.