Pourquoi une précision de 90 % dans Text-to-SQL est 100 % inutile

Je travaille dans le domaine Analytics depuis plus de 20 ans. À l’époque, cela ne s’appelait pas « analyse », mais plutôt « Business Intelligence » ou même « Systèmes d’aide à la décision ». Les termes changent, des entrepôts de données au Big Data, en passant par les Lakehouses, et désormais avec l’IA, l’essence et la promesse éternelle de l’analyse en libre-service restent les mêmes : extraire la vérité des données pour responsabiliser les utilisateurs sans dépendre d’un membre de l’équipe de données. L’IA sans les humains au courant ? Cela semble controversé.

Avec l’avènement des grands modèles linguistiques (LLM), un cas d’utilisation que je trouve fascinant consiste à développer des interfaces conversationnelles pour discuter avec des bases de données (Text-to-SQL). Le potentiel ici est immense et promet de démocratiser l’accès aux données dans toutes les organisations.

Cependant, pour ce cas d’utilisation spécifique, la solution doit être binaire. Soit ça marche, soit ça ne marche pas.

Une précision de 80, voire 90 %, n’est malheureusement pas suffisante. Donner à vos utilisateurs finaux une application analytique d’IA qui hallucine les tableaux ou interprète mal les filtres n’est pas une blague. Vous ne pouvez pas faire de compromis sur l’exactitude, car cela érode immédiatement la confiance. Et que se passe-t-il lorsqu’un système perd confiance ? Il ne sera pas utilisé. L’adoption diminuera, sans oublier le risque catastrophique que des décisions commerciales soient prises sur la base de données erronées.

La complexité du pipeline RAG

J’ai commencé mes recherches sur ce sujet il y a plus d’un an et demi et il est rapidement devenu clair qu’orchestrer une application robuste Text-to-SQL RAG (Retrieval-Augmented Generation) n’est pas anodin. Vous avez besoin de plusieurs composants dans votre pipeline, fonctionnant en parfaite harmonie :

• Un classificateur d’intention pour détecter le but de la question.
• UN base de données de vecteurs pour stocker le contexte supplémentaire (comme les définitions métier) dont les modèles de langage ont besoin.
• Un modèle d’intégration pour vectoriser ces connaissances supplémentaires.
• UN mécanisme de récupération pour les données stockées.
• Accès à la base de données.
• La possibilité de générer du SQL dans le dialecte spécifique de la base de données.
• Et la capacité de évaluer les résultats.

Cette dernière partie, l’évaluation, est, je crois, souvent omise ou traitée après coup, mais elle constitue peut-être l’élément le plus crucial pour garantir la fiabilité nécessaire dans le cadre d’une entreprise.

BigQuery : une étude de cas sur l’intégration de l’IA native

La gestion de ce pipeline complexe nécessite souvent l’intégration de plusieurs plates-formes. J’ai récemment été impressionné par la façon dont BigQuery a introduit nativement la fusion d’Analytics et d’IA générative dans sa plate-forme.

Vous avez la possibilité de travailler avec votre SQL dans l’IDE BigQuery et d’utiliser Gen AI immédiatement sans passer par une autre plate-forme ou un autre produit. Par exemple : vous pouvez interroger la base de données et les résultats récupérés peuvent être immédiatement envoyés à Gemini (ou via Vertex, vous pouvez également ajouter d’autres modèles). Vous pouvez utiliser Gemini pour classer l’intention, créer des intégrations et les stocker dans les fonctionnalités de base de données vectorielles de BigQuery, effectuer une recherche sémantique et générer du SQL.

Tout cela avec une seule plateforme, sans avoir à gérer plusieurs abonnements.

Bien sûr, comme tout dans la vie, cela a ses inconvénients.

L’un des principaux inconvénients est que BigQuery n’est peut-être pas la base de données la moins chère, et j’ai entendu des histoires de startups où une seule mauvaise requête peut vider votre carte de crédit. Cela ne m’est pas arrivé, mais je peux comprendre comment cela peut arriver. Un autre inconvénient serait que vous soyez entièrement bloqué sur Google. Ce n’est peut-être pas une mauvaise chose ; de la même manière que nous sommes tous enfermés dans Gmail. Peut-être qu’à l’avenir, l’IA sera une marchandise, comme le sont aujourd’hui les e-mails.

Un autre inconvénient est le manque de traçabilité granulaire du coût des tokens et d’une sorte de « simulation LLM » pour le développement ; vous ne voulez pas vraiment utiliser le LLM très coûteux à votre stade de développement.

Si les inconvénients ci-dessus vous conviennent, vous obtenez un produit magnifique qui combine plusieurs outils en une seule plate-forme cloud capable de gérer massivement le Big Data.

J’ai créé le dépôt suivant qui faisait partie du hackathon Kaggle, où j’ai exploré plus en détail ces fonctionnalités natives de BigQuery. Pour plus d’informations, veuillez visiter le dépôt ici :

https://github.com/garyzava/bigq-ethereum-rag

La pièce manquante : une évaluation rigoureuse

Revenons maintenant aux frameworks d’évaluation. Des plates-formes comme BigQuery simplifient architecturemais ils ne résolvent pas automatiquement le précision problème. Je vois plusieurs solutions, mais la plupart d’entre elles manquent de capacités d’évaluation robustes.

Si nous acceptons que Text-to-SQL doit être binaire (correct ou incorrect), nous avons besoin de stratégies d’évaluation qui reflètent la réalité désordonnée des données d’entreprise, et non les environnements vierges des ensembles de données académiques ou de démonstration.

L’évaluation d’un système Text-to-SQL est notoirement difficile en raison de la nature déclarative de SQL et de la complexité de votre schéma de base de données. A-t-il des milliers de tables ? Ces tableaux sont-ils bien documentés ? Probablement pas. Les conventions de dénomination sont-elles cohérentes dans toutes les tables ? Deux requêtes peuvent sembler syntaxiquement complètement différentes (par exemple, des ordres de jointure différents, des alias ou l’utilisation de CTE) tout en produisant des résultats identiques.

Pour véritablement comparer votre application RAG pendant le développement et en production, vous devez utiliser les bonnes métriques.

Des mesures qui comptent

Pour en revenir à la promesse de la BI ou de l’analyse en libre-service, cela signifie que l’utilisateur final compte à 100 % sur lui-même ; malheureusement, il n’y a pas d’humain ni d’expert en données pour valider les résultats. Pour cette raison, nous devons établir une IA ou un cadre d’évaluation explicable avec un ensemble de métriques pour mesurer la qualité du SQL généré.

1. Le passage à la précision d’exécution (EX) : Les premiers benchmarks reposaient sur Exact Match (EM), qui comparait la chaîne SQL prédite à la vérité terrain. Cette solution était profondément erronée, car elle pénalisait les variations syntaxiques valides. La norme moderne est la précision d’exécution (EX). Cette métrique exécute à la fois le SQL prédit et le SQL « Gold » (vérité terrain) par rapport à la base de données réelle et compare les ensembles de résultats renvoyés. Cela valide correctement les requêtes quelle que soit la façon dont elles sont écrites.
2. Évaluation ciblée : Dans les contextes d’entreprise, une requête peut renvoyer des colonnes supplémentaires non essentielles (par exemple, une colonne ID utilisée pour une jointure). Une précision d’exécution stricte pourrait marquer cela comme un échec. « L’évaluation ciblée basée sur l’exécution » permet une comparaison plus nuancée, en vérifiant si les colonnes et les valeurs cibles sont correctes, tout en étant plus indulgente envers les données superflues ou l’ordre des lignes.
3. La métrique « Soft-F1 » : Pour atténuer la nature binaire de la précision d’exécution (où une mauvaise cellule échoue à l’ensemble du test), Soft-F1 est de plus en plus utilisé. Cette métrique fournit un crédit partiel en calculant le chevauchement entre les résultats prédits et ceux de l’or. Si une requête renvoie 99 lignes correctes sur 100, Soft-F1 reflète des performances élevées, alors que EX renverrait 0. Ceci est crucial pour le débogage.
4. LLM en tant que juge : Parfois, l’exécution est impossible (par exemple, données privées manquantes, erreurs d’environnement). Dans ces cas, un LLM avancé peut être invité à comparer la logique sémantique du SQL prédit avec le Gold SQL. Bien que moins objectif que l’exécution, il est fortement corrélé au jugement humain.

Spider 2.0 : la réalité des entreprises

Il existe actuellement trois cadres d’évaluation remarquables : Spider 2.0, BIRD (BIg Bench for LaRge-scale Database Grounded Text-to-SQL) et SynSQL (basé sur des données synthétiques). Cependant, l’industrie souffre d’un faux sentiment de sécurité créé par des critères dépassés. Pendant des années, l’industrie s’est appuyée sur Spider 1.0. Il s’est concentré sur de petites bases de données SQLite propres (avec une moyenne de moins de 10 tables). Les modèles atteignaient une précision de plus de 90 %, ce qui laissait croire que le problème était « résolu ».

Le cadre sur lequel je mets toujours l’accent, qui intègre ces mesures modernes et teste véritablement l’état de préparation de l’entreprise, est Araignée 2.0.

Spider 2.0 (publié conjointement avec l’ICLR 2025) est un changement de paradigme, conçu pour combler ce « fossé de réalité » en introduisant les complexités qui brisent les LLM en production :

1. Échelle massive : Les schémas d’entreprise sont énormes. Les bases de données Spider 2.0 contiennent en moyenne 812 colonnes, certaines dépassant 3 000. Cette échelle dépasse souvent les limites contextuelles du LLM, obligeant les modèles à utiliser des stratégies de « liaison de schéma » (récupération) uniquement pour identifier les tables pertinentes avant de générer du SQL.
2. Diversité dialectale : Les vraies entreprises utilisent Snowflake, BigQuery et T-SQL, pas seulement SQLite. Spider 2.0 impose la diversité des dialectes, exigeant que les modèles maîtrisent une syntaxe spécifique (par exemple, la gestion des données JSON imbriquées à l’aide de UNNEST ou FLATTEN).
3. Connaissance externe : La logique métier (comme la définition du « taux de désabonnement ») réside dans la documentation ou les bases de code du projet (comme DBT), et non dans le schéma. Spider 2.0 simule cela en fournissant des fichiers externes (Markdown, YAML) que le modèle doit lire pour étayer son raisonnement.
4. Le flux de travail agent : Fondamentalement, Spider 2.0 modélise le flux de travail d’un ingénieur de données moderne. Il va au-delà de la traduction statique, évaluant la capacité du modèle à explorer le système de fichiers, à lire la documentation, à interagir avec les instances de base de données en direct et à déboguer les erreurs de manière itérative.

La différence de difficulté est flagrante. Les modèles qui dominent Spider 1.0 voient leurs taux de réussite tomber à 10-20 % sur le benchmark complet Spider 2.0, soulignant les lacunes des LLM actuels face à la complexité du monde réel.

Conclusion : la barre binaire pour les données d’entreprise

Le passage de la Business Intelligence à l’analyse basée sur l’IA a été marqué par une abstraction croissante, mais l’exigence fondamentale en matière d’intégrité des données reste inchangée. Même si les promesses du Text-to-SQL sont plus proches que jamais, nous devons résister à l’attrait des scores élevés sur des benchmarks obsolètes.

Atteindre une précision de 90 % peut être intéressant sur le plan académique, mais dans l’entreprise, cela est inutile sur le plan industriel. La barre est binaire : ça marche ou ça brise la confiance.

Alors que des plateformes comme BigQuery simplifient l’intégration de l’IA et des données, il est impératif que nous adoptions simultanément des méthodologies d’évaluation sophistiquées et des benchmarks rigoureux comme Spider 2.0. Ce n’est qu’en testant la réalité désordonnée des données d’entreprise que nous pourrons développer des applications Text-to-SQL suffisamment fiables sur lesquelles l’entreprise peut miser.

En attendant la prochaine fois, j’espère que vous avez trouvé ce sujet aussi fascinant que moi.

Lectures complémentaires

Spider 2.0 : évaluation de modèles de langage sur des flux de travail Text-to-SQL d’entreprise réels Auteurs : Fangyu Lei, Jixuan Chen, Yuxiao Ye, et al. Publié : arXiv (novembre 2024), accepté à l’ICLR 2025 (oral). Lien: https://arxiv.org/abs/2411.07763

Certes, comme pour tout ce qui concerne l’IA de nos jours, cette conversation ne doit pas s’arrêter là. J’aimerais entendre vos contributions et votre point de vue à www.gyza.org