Ce que nous avons appris sur la formulation de requêtes pour les modèles de langage de grande capacité (LLM) dans le cadre de la conversion de texte en SQL

Chez Actian, nous développons des agents IA capables de transformer automatiquement le langage naturel en SQL. C'est le genre de chose qui semble relever de la magie, mais qui nécessite en réalité un travail d'ingénierie minutieux pour fonctionner correctement. L'une des principales leçons que nous avons tirées : la manière dont on formule la requête au modèle fait toute la différence.

Récemment, nous avons étudié toute une série de stratégies de formulation de prompts. Zero-shot, few-shot, mono-domaine, inter-domaines. Formats de prompts, exemples de données, relations entre les tableaux… nous avons tout testé. Et croyez-moi, nous en sommes ressortis avec des opinions bien arrêtées sur ce qui fonctionne et ce qui ne fonctionne pas.

Ce blog partage certaines de ces connaissances. Que vous développiez votre propre outil de conversion de texte en SQL ou que vous soyez simplement curieux de savoir comment nous procédons chez Actian, poursuivez votre lecture.

Les bases de la formulation (révision rapide)

Quand nous parlons ici de « prompting », voici ce que nous entendons : que devons-nous présenter au modèle linguistique avant de lui demander de générer du code SQL ?

Une invite de commande texte-vers-SQL standard comprend généralement :

• Une brève consigne (« Rédigez une requête SQL en utilisant les tables ci-dessous »).
• Une description de la base de données (noms des tables, colonnes, relations).
• Parfois : exemples de questions + le code SQL correspondant.
• Et puis : la question à laquelle nous voulons une réponse.

Il existe deux configurations courantes :

Chez Actian, nous utilisons les deux, selon ce que utilisateur et les données disponibles.

Le schéma à lui seul ne suffit pas

Dans les invites « zero-shot », il ne suffit pas de simplement énumérer les tables et les colonnes. Nous avons constaté que l'ajout de relations entre les tables (par exemple, des clés étrangères) améliorait considérablement la précision.

Mieux encore : incluez des exemples de valeurs de données. Cela aide le modèle à comprendre à quoi ressemblent les valeurs des colonnes dans la pratique, ce qui est essentiel lorsqu'il s'agit de rédiger des clauses WHERE avec le formatage approprié (par exemple, « USA » ou « The United States of America »).

Nous avons testé différentes façons d'afficher le contenu d'un tableau. La solution retenue ? Un format qui affiche les valeurs de chaque colonne séparément (ce que l'article appelle « SelectCol »). Cette méthode a donné de meilleurs résultats que l'affichage des lignes brutes (« InsertRow ») ou la simple exécution de la requête « SELECT * LIMIT 3 ».

Ainsi, dans la configuration « zero-shot » d'Actian, nous incluons toujours :

• Le schéma complet (CREATE TABLE)
• Relations de clés étrangères
• Quelques valeurs distinctes par colonne

(Et oui, on uniformise tout : minuscules, espacement régulier, pas de mise en forme bizarre.)

Peu d'exemples : plus il y en a, mieux c'est (en général)

Si vous pouvez donner des exemples, n'hésitez pas. Nous avons constaté des améliorations constantes, même avec seulement 1 ou 2 exemples. Et si vous pouvez en donner 4 à 8 de qualité, issus du même domaine ? C'est souvent suffisant pour en tirer la plupart des avantages.

Mais voici le rebondissement :

• Le contenu des tableaux reste important, même lorsqu'il s'agit d'exemples.
• La manière dont vous présentez ce contenu a moins d'importance : le modèle devient moins exigeant dès qu'il a vu quelques exemples.
• Les relations entre les tables (comme les jointures) peuvent être comprises à partir des exemples eux-mêmes.

En mode « single-domain », vous pouvez vous contenter d'un format de schéma plus simple, à condition de fournir des exemples concrets et utiles — mais nous vous recommandons tout de même d'inclure le contenu des tableaux si vous le pouvez.

Les données d'échantillon améliorent la précision

Si vous fournissez également des exemples de valeurs issues du tableau — par exemple, quelques lignes types —, les résultats s'améliorent. Cela aide le modèle à comprendre quel type de valeurs est stocké, ce qui est important pour la rédaction de filtres (par exemple, les clauses WHERE).

Nous avons testé plusieurs façons de le montrer :

• Instructions INSERT brutes
• SELECT * LIMIT 3
• Valeurs distinctes par colonne

La dernière option (valeurs distinctes par colonne) s'est avérée la plus efficace. Elle offre davantage de variété et évite les redondances.

Mais les suggestions ne font pas tout

Voici le problème : même si vous formulez vos instructions avec le plus grand soin, il n'est pas réaliste de s'attendre à ce qu'un modèle de langage de grande capacité (LLM) écrive toujours du code SQL parfait en partant de zéro.

Chez Actian, nous avons compris qu’il ne suffit pas de donner des instructions. Il faut mettre en place un cadre de travail autour de l’agent :

• La possibilité de sauvegarder des requêtes SQL déjà générées — et de les réutiliser lorsqu'un utilisateur une question similaire par la suite.
• Une façon de définir des termes clés (comme ce que signifient réellement « Churn » ou « utilisateur actif utilisateur) et d'intégrer cette définition dans la ligne de commande lorsque cela s'avère pertinent.

Ce type d'infrastructure fait toute la différence en termes de fiabilité et de performances. La suggestion est un point de départ, mais c'est grâce à une gestion et une réutilisation robustes du contexte que le système devient évolutif intelligent.

Et oui, chez Actian, nous menons aussi d'autres projets en coulisses. Nous n'allons pas tout dévoiler pour l'instant… certains d'entre eux font l'objet d'une demande de brevet.

Nous mettons tout en œuvre pour améliorer le fonctionnement de la conversion texte-SQL : nous voulons qu'elle soit plus précise, plus fiable et plus utile pour les équipes chargées des données. La formulation des requêtes n'est qu'une pièce du puzzle, mais c'est une pièce importante.

Si vous développez vos propres outils de gestion des données basés sur des modèles de langage de grande envergure (LLM), nous espérons que cela vous donnera quelques idées. Et si vous souhaitez voir à quoi cela ressemble en production, vous savez où nous trouver 🙂

À propos de l'auteur

À propos de Amra Dorjbayar

Amra Dorjbayar est cofondatrice de Wobby (rachetée par Actian en 2026) et responsable du projet Actian AI Analyst. Ancienne journaliste d'investigation et de données primée, Amra a passé de nombreuses années à dévoiler des histoires à partir de jeux de données complexes. Elle a mis à profit cette expertise pour créer des systèmes d'IA « agents » qui démocratisent l'accès aux données grâce au langage naturel.