Uber QueryGPT: langage naturel vers SQL — 10 minutes réduites à 3

• QueryGPT — Natural Language to SQL at Uber — Uber Engineering Blog, 2024-09-19
• A Deep Dive into QueryGPT: Uber's AI-Powered SQL Generator — Sequel (независимый разбор), 2024

Contexte

Uber est une entreprise pilotée par les données au sens littéral : le prix, l'acheminement, les paiements aux chauffeurs et l'équilibrage de la demande fonctionnent tous sur une plateforme de données qui traite environ 1,2 million de requêtes SQL interactives par mois. Le plus gros consommateur est l'organisation opérationnelle, représentant environ 36 % de toutes les requêtes. Ce sont des milliers d'employés qui ont besoin de données au quotidien, mais pour lesquels SQL n'est pas leur métier principal.

L'analyse interne chez Uber repose sur des milliers de jeux de données, et les tables clés (tier-1) sont passées à plus de 200 colonnes chacune. Rédiger une requête, ce n'est pas seulement de la syntaxe : vous devez trouver les bonnes tables parmi des milliers et comprendre le schéma et la logique métier des champs — comment les dates sont calculées dans un domaine donné, ou ce qu'un drapeau particulier signifie.

QueryGPT est né de manière ascendante, pas par décision exécutive : l'idée a été proposée au hackathon interne Generative AI Hackdays en mai 2023, quand Uber cherchait systématiquement des applications LLM dans l'ensemble de l'entreprise. Du prototype hackathon au service de production décrit dans le billet technique de septembre 2024, l'équipe Data Platform a traversé plus de 20 itérations architecturales.

Le cas est précieux précisément pour son honnêteté technique : Uber a publié non pas une annonce marketing mais une analyse détaillée avec l'évolution des versions, les métriques d'évaluation et les problèmes non résolus — y compris les hallucinations et le non-déterminisme de l'évaluation. L'article est signé par une équipe de huit ingénieurs Data Platform — d'un ingénieur principal aux développeurs axés sur la productivité LLM ; c'est le produit d'une organisation d'ingénierie, pas d'un laboratoire IA. Pour quiconque crée du texte vers SQL pour sa propre entreprise, c'est l'un des documents publics les plus utiles de l'industrie.

Problème

Une requête moyenne prenait environ 10 minutes à son auteur. L'anatomie de ces minutes : trouver les bonnes tables parmi des milliers de jeux de données, donner un sens à un schéma de deux cents colonnes, se rappeler les conventions du domaine (comment filtrer les commandes de test, quel fuseau horaire les dates sont dans) — et seulement alors écrire le SQL lui-même. À l'échelle de centaines de milliers de requêtes par mois, c'est une énorme charge de productivité : les équipes opérationnelles ont passé du temps sur la mécanique des requêtes plutôt que sur l'analyse et les décisions.

L'approche naïve — 'donner simplement le schéma et la question au LLM' — a atteint des limites fondamentales. Le schéma d'une seule grande table consommait 40 à 60 mille tokens, tandis que les fenêtres de contexte des modèles avant l'ère des modèles 128K étaient de 32 mille. Les requêtes joignent souvent plusieurs tables : le schéma n'a pas tenu physiquement dans le modèle, sans parler du coût et de la latence de tels appels.

Le deuxième problème, c'était les gens. Les vrais prompts utilisateur vont de formulations détaillées et riches en mots-clés à des questions de cinq mots avec des fautes de frappe. Un pipeline naïf attendant une entrée bien rangée s'effondre sur le trafic réel : une question courte et sans contexte porte trop peu de signal, soit pour la sélection des tables, soit pour générer du SQL correct.

Et troisièmement : le coût de l'erreur. Le SQL généré qui semble plausible mais utilise une colonne inexistante ou une mauvaise logique métier est pire que pas de réponse — il échoue soit ou, plus dangereusement, retourne des chiffres erronés sur lesquels on prend des décisions. Les utilisateurs, comme le dit l'équipe, ont une barre élevée : les requêtes doivent 'simplement fonctionner'.

Solution

La première version, assemblée au hackathon, était du RAG classique : recherche de vecteurs par k-plus-proches-voisins sur un petit ensemble de 7 tables tier-1 et 20 requêtes SQL de référence, dont 3 tables et 7 exemples ont été intégrés au prompt, plus des instructions avec des conventions spécifiques à Uber (gestion des dates, termes métier). Le prototype a prouvé la demande, mais la précision a chuté sur la variété réelle de questions et de tables — et les plus de vingt itérations suivantes ont transformé 'un prompt avec RAG' en un pipeline d'agents spécialisés.

Le premier mouvement structurel a été les 'workspaces' : des ensembles organisés de tables et d'exemples SQL pour un domaine métier spécifique. La production exécute 12+ workspaces système (Mobilité, Services Essentiels, Ingénierie de Plateforme, IT, Publicités et autres), plus des workspaces personnalisés pour les cas d'usage étroits. La curation est un travail manuel par des experts du domaine, et c'est elle — pas le modèle — qui fournit la plupart du gain de précision : la recherche ne s'exécute pas sur l'ensemble de la plateforme mais au sein d'un sous-ensemble pré-digéré.

Une question passe ensuite par le pipeline. L'Agent Intent classe la requête dans les domaines métier et choisit un workspace, rétrécissant le rayon de recherche RAG. L'Agent Table sélectionne des tables spécifiques — et affiche la liste à l'utilisateur, qui peut la confirmer ou la modifier : l'équipe a ajouté cette étape humaine dans la boucle après des plaintes concernant une mauvaise sélection de tables. L'Agent Column Prune supprime les colonnes non pertinentes des schémas — cela a résolu le problème des tokens : même avec la fenêtre 128K de GPT-4 Turbo (modèle 1106), les schémas complets étaient coûteux et lents, et l'élagage a considérablement réduit la latence et les coûts d'appel. Un 'prompt enhancer' distinct enrichit les formulations d'utilisateur tersées avec du contexte avant la génération.

Contre les hallucinations (les tables et colonnes inexistantes sont le principal mode de défaillance), l'équipe utilise un mode de chat itératif où l'utilisateur affine la requête, et expérimente avec un agent de validation qui trouve et corrige récursivement les erreurs dans le SQL généré.

Le système d'évaluation mérite une attention particulière. L'équipe a assemblé un ensemble 'golden' de paires question→SQL à partir des vrais logs du service sur tous les domaines et l'exécute en deux modes : Vanilla (le chemin complet de la question à SQL) et Découplé (intention et tables pré-établies, pour mesurer les composants isolément). Les signaux : précision de l'intention, chevauchement des tables sélectionnées avec la référence (0–1), succès de l'exécution de la requête, retour de résultat non vide et un score de similarité basé sur LLM par rapport au SQL de référence. Une trouvaille séparée : les exécutions d'évaluation sont non-déterministes, avec jusqu'à ~5 % de variance entre les exécutions sans changements de code — l'équipe suit donc les modèles d'erreur sur de longues périodes plutôt que de réagir aux variations de métriques.

Résultat

QueryGPT produit des requêtes suffisamment fiables en environ 3 minutes contre ~10 minutes de rédaction manuelle — environ 70 % de temps économisé par requête. En version limitée, le service enregistre environ 300 utilisateurs actifs quotidiens, dont 78 % disent que les requêtes générées réduisent le temps qu'ils auraient passé à écrire à la main. À l'échelle de la plateforme de 1,2 million de requêtes par mois, le potentiel d'évolution est évident — mais l'équipe se déploie délibérément graduellement, et dans ses apprentissages publiés, elle nomme explicitement le choix du bon public initial (personas) comme une leçon en soi : commencer où le bénéfice est le plus élevé et où les besoins en SQL sont routiniers — avec les équipes opérationnelles, pas avec les ingénieurs données, qui ont le moins besoin d'un brouillon LLM.

Les apprentissages publiés de l'équipe sont tout aussi importants. Premièrement : les LLM fonctionnent excellemment comme classificateurs sur des tâches étroites — un pipeline d'agents spécialisés (intention → tables → colonnes) surpasse systématiquement un seul grand prompt. Deuxièmement : la question de l'utilisateur seule est insuffisante comme entrée pour la génération ; elle doit être enrichie de contexte avant l'appel du modèle. Troisièmement : la multiplicité des réponses (la même question est correctement résolue avec différentes tables et styles SQL) rend l'évaluation automatisée intrinsèquement floue — d'où un juge LLM et une comparaison visuelle par rapport à la référence au lieu d'une correspondance binaire/pas de correspondance.

Encadrez les chiffres correctement : 10 et 3 minutes sont les estimations de l'équipe Uber ; 78 % est l'auto-report des utilisateurs, pas une mesure au chronomètre ; le service était en version limitée à la publication. Uber ne publie ni un pourcentage de précision de génération ni un impact financier — et, selon notre avis, c'est plus honnête que les extrapolations de blogs tiers qui présentent le cas avec des centaines de milliers d'heures économisées.

Selon nous, la principale leçon transférable de QueryGPT est que le texte vers SQL en production est 20 % de modèle et 80 % d'ingénierie de contexte : workspaces de domaine organisés, élagage de schéma, enrichissement de prompt et discipline d'évaluation sur un ensemble golden. Tout cela se transfère à n'importe quelle entreprise avec une grande plateforme de données — et ne nécessite ni votre propre modèle ni l'échelle d'Uber. La deuxième leçon est le rythme : du hackathon à la production, cela a pris plus d'un an et 20+ itérations. Les équipes attendant du texte vers SQL 'fonctionner dans un sprint' sous-estiment précisément la longue traîne de l'ajustement du domaine, pas la difficulté des LLM.

Leçons

1. Le texte vers SQL en production est un pipeline d'agents spécialisés (intention → tables → colonnes), pas un seul grand prompt : les LLM sont les plus fiables comme classificateurs sur des tâches étroites.
2. Les workspaces organisés avec des exemples SQL par domaine surpassent le fait de donner au modèle le schéma entier : l'investissement principal est la curation manuelle par les experts du domaine.
3. L'élagage du schéma (Column Prune) concerne à la fois la précision et le coût : moins de tokens — moins cher, plus rapide, mieux ; même une fenêtre 128K n'annule pas l'économie de contexte.
4. L'entrée de l'utilisateur ne peut pas aller dans le modèle telle quelle : les vraies questions vont de verbeuses à cinq mots avec des fautes de frappe, et un 'prompt enhancer' avant la génération est obligatoire.
5. Humain dans la boucle au bon endroit : la confirmation de l'utilisateur sur la sélection de la table a été ajoutée après de vraies plaintes — une étape peu coûteuse qui supprime la principale source d'erreur.
6. Évaluez sur un 'ensemble golden' construit à partir de vrais logs, en mesurant les composants isolément ; et attention au non-déterminisme de l'évaluation LLM (~5 % entre les exécutions) — suivez les modèles d'erreur, pas les variations de métriques.
7. L'encadrement honnête de la qualité est 'un brouillon suffisamment fiable en 3 minutes', pas 'du SQL parfait' : un humain reste en tant que relecteur — une condition de confiance, pas une faiblesse du produit.

Questions fréquentes