Le prototype SafeQL de KAIST corrige les erreurs SQL de l’IA

Une demande ordinaire — « Trouver le produit le plus vendu de l’année dernière » — peut se heurter à la porte de la base de données si un assistant d’IA fait référence à un seul élément qui n’existe pas. À KAIST, le doctorant Geonho Lee et le professeur Min-Soo Kim ont développé SafeQL, un prototype qui répare la partie défectueuse d’une requête générée par l’IA au lieu de jeter toute la requête. Les résultats ont été présentés à la conférence VLDB, à Boston, aux États-Unis.

Le problème se situe dans le text-to-SQL, le processus qui consiste à transformer des questions du quotidien en SQL, le langage utilisé par les bases de données pour récupérer des informations. Une IA peut pointer vers une table ou une colonne absente, ou joindre des tables de manière incorrecte. La correction classique renvoie l’erreur de la base de données à un LLM — un grand modèle de langage — et lui demande une réécriture complète. Cela peut modifier des sections qui étaient déjà correctes, introduire de nouvelles erreurs et accroître le temps de traitement.

SafeQL lit les retours du système de gestion de base de données pour localiser précisément l’échec : une relation, c’est-à-dire une table ; un attribut, c’est-à-dire une colonne ; une fonction ; ou une valeur. Il recherche ensuite dans un « espace de requêtes sûres » composé de corrections qui peuvent réellement être exécutées sur la base de données, en privilégiant le candidat le plus proche de la requête initialement générée par l’IA. Les options inadéquates sont écartées avant de consommer davantage de temps de recherche. Lorsque l’affinage par recherche ne parvient pas à résoudre l’erreur dans un délai prédéfini, SafeQL fait de nouveau appel au LLM.

L’équipe a testé le système sur BIRD et Spider, deux benchmarks pour l’interrogation de bases de données par l’IA. Sur BIRD, SafeQL a résolu les erreurs d’exécution de jusqu’à 87,4 % des requêtes SQL initialement erronées et amélioré la précision d’exécution de jusqu’à 5,8 points de pourcentage par rapport à la référence non affinée. Comparé à la régénération de la requête entière, il a réduit l’utilisation de tokens jusqu’à 15,1 fois et la latence d’affinage jusqu’à 29,6 fois.

Pour les entreprises qui traitent d’importants volumes de demandes concernant les ventes, les clients ou les stocks, le changement concret est simple : un assistant peut conserver la partie d’une requête qui fonctionne et réparer celle qui échoue. L’équipe estime que cela pourrait réduire le coût et le temps de traitement des systèmes d’IA d’entreprise et favoriser une automatisation plus fiable. L’étude décrit une implémentation PostgreSQL et des résultats sur benchmarks, tandis que l’usage en entreprise reste une application attendue plutôt qu’un déploiement rapporté ; le système peut toujours se rabattre sur le LLM lorsque sa recherche ne parvient pas à terminer la réparation.