AWS présente Text-to-SQL sur Amazon Bedrock pour traduire des questions métier en SQL

AWS a publié une analyse détaillée d'une solution Text-to-SQL sur Amazon Bedrock, qui traduit les questions métier en langage naturel en requêtes SQL et retourne immédiatement la réponse de manière compréhensible. Ce n'est pas un nouveau produit distinct, mais une architecture pratique pour les entreprises qui ont des données mais manquent encore de réponses rapides aux questions commerciales.

Pourquoi le BI est Limité

AWS explique le problème simplement : même dans les entreprises ayant une analytique robuste, les utilisateurs se heurtent encore à un goulot d'étranglement en attendant les analystes ou font face aux limitations des tableaux de bord préétablis. Si une question dépasse un rapport pré-assemblé, vous avez besoin de jointures, de tranches de temps, de métriques calculées et de connaissance de la logique interne des tables. Pour la vente, les finances ou les opérations, cela signifie perdre des heures ou même des jours sur une requête unique qui ne justifie pas un développement séparé en soi.

Selon AWS, c'est ici que le BI en libre-service standard commence à patiner. Le langage naturel dans les interfaces BI fonctionne bien avec des couches sémantiques préparées, mais a du mal avec les tables brutes, la terminologie interne et les métriques qui sont calculées différemment dans chaque entreprise. C'est pourquoi AWS propose de construire non seulement un générateur SQL, mais un système qui comprend le contexte métier : ce que représente le chiffre d'affaires, comment le pipeline est calculé et quelles tables peuvent être jointes ensemble.

Comment Fonctionne le Pipeline

Au cœur de l'architecture se trouve Amazon Bedrock comme couche d'inférence et d'orchestration, plus un graphe de connaissances pour le contexte métier et un entrepôt analytique pour l'exécution des requêtes. Le Runtime AgentCore joue un rôle central : il reçoit la question, décide si elle doit être décomposée en sous-tâches, appelle la recherche de contexte, déclenche la génération SQL et retourne la réponse finale. Pour les entreprises, c'est important car la logique n'est pas codée en dur dans un seul prompt : elle peut être décomposée en étapes séparées et contrôlée à chaque phase.

• classification de la question comme simple ou complexe
• recherche du contexte métier via GraphRAG
• génération SQL en format structuré
• validation déterministe de la requête avant exécution
• synthèse de la réponse en langage naturel basée sur les résultats de la requête

Pour le contexte, AWS utilise une combinaison d'Amazon Neptune et d'OpenSearch : le graphe stocke les relations entre les tables, colonnes, métriques, termes et hiérarchies au sein de l'entreprise. Ensuite, le système effectue une recherche vectorielle sur les descriptions et les valeurs, traverse les relations du graphe et fournit au modèle uniquement les tables, champs, chemins de jointure et règles métier pertinents. Pour les questions complexes, l'architecture peut exécuter plusieurs agents en parallèle et sélectionner le résultat le plus fiable par vote majoritaire.

Production et Contrôle

La partie la plus pratique du post ne concerne pas le LLM, mais les couches de protection. AWS souligne spécifiquement que les prompts seuls ne peuvent pas capturer de manière fiable le SQL sémantiquement incorrect : une requête peut être syntaxiquement valide mais produire un résultat dangereux ou simplement faux. Par conséquent, après la génération SQL, elle est vérifiée avec des validateurs déterministes au niveau AST.

Si le système détecte un risque—par exemple, un scan trop large, une agrégation incorrecte ou des filtres nécessaires manquants—il corrige automatiquement la requête et réessaie. Le deuxième sujet est la latence et les accès. Selon les données d'AWS, les requêtes SQL simples dans un tel schéma sont généralement générées en environ 3 à 5 secondes, bien que le temps total dépende du modèle, de la taille du graphe de connaissances et de la vitesse de l'entrepôt.

Pour maintenir l'interactivité, AWS recommande de paralléliser les sous-tâches, d'économiser les tokens et de ne pas gonfler le contexte de l'agent. En parallèle, l'architecture inclut immédiatement les filtres Row-Level Security pour que les utilisateurs ne voient que les lignes auxquelles ils ont déjà accès selon les règles d'entreprise.

Ce Que Cela Signifie

AWS montre effectivement que Text-to-SQL cesse d'être une démonstration en sandbox et devient un modèle d'ingénierie pour les scénarios BI réels. La principale conclusion n'est pas que le LLM peut écrire SQL, mais qu'un système fonctionnel nécessite un graphe de connaissances, des vérifications, une orchestration et un contrôle d'accès. Pour les équipes qui souhaitent donner à l'entreprise une interface de chat avec les données, c'est un bon point de référence : moins de magie, plus d'infrastructure et de règles.