Petit à petit, Google Cloud peaufine les capacités de BigQuery dans sa capacité à générer des requêtes SQL à partir de commentaires en langage naturel. En janvier dernier, le fournisseur a présenté la fonction « Comments to SQL » où les développeurs et les analystes peuvent écrire des instructions en langage naturel dans les commentaires SQL et les faire traduire en les faire traduire en requêtes exécutables dans BigQuery Studio. Aujourd’hui, il lance l’outil QueryData pour améliorer la précision des agents IA qui interrogent des bases de données. Selon Google Cloud, l’exactitude serait « proche de 100% » par rapport la génération de requêtes par certains LLM. Ces derniers peuvent, en raison de leur compréhension limitée des schémas de base de données et de leur raisonnement probabiliste, introduire des inexactitudes.

QueryData nécessite quelques paramétrages. En premier lieu, les utilisateurs doivent d'abord définir ce que Google appelle le « contexte », qui décrit comment les données doivent être consultées et interrogées. Cela implique d'encoder des détails sur les schémas de base de données, y compris des descriptions des tables, des relations et de la signification métier, ainsi que des instructions déterministes qui guident la manière dont les requêtes sont générées ou exécutées. Une fois le contexte et les directives configurés, les utilisateurs se servent du Context Engineering Assistant, un agent dédié de Gemini CLI, pour vérifier de manière itérative la précision des requêtes par rapport au framework Evalbench jusqu’à ce qu’elles soient satisfaites des résultats. Ensuite, il est possible d’intégrer l’outil à des flux de travail pilotés par des agents où il sert de couche d'exécution entre les requêtes des utilisateurs et les bases de données sous-jacentes. L’outil peut être utilisé au sein des agents orientés data propres à Google Cloud, actuellement disponibles dans BigQuery, ou être appelé via des API par les entreprises qui développent des agents personnalisés et des systèmes multi-agents. Pour l’instant, QueryData prend en charge AlloyDB, CloudSQL for MySQL, CloudSQL for PostgreSQL et Spanner.

Un équilibre à trouver entre précision et performance

Selon Pareekh Jain, analyste principal chez Pareekh Consulting, cet outil marque un passage de l’IA basée sur des outils à des agents axés sur les résultats et dotés de garde-fous intégrés, ce qui devrait aider les entreprises à mettre en production des systèmes et des applications multi-agents, et autoriser des « cas d’usage de décisionnel» dans les départements des finances, des opérations et de la supply chain. Celui-ci fait toutefois la mise en garde suivante : si QueryData réduit le besoin d’ingénierie réactive pour les développeurs et améliore la fiabilité lors de l’exécution, il transfère la charge vers la conception initiale et la maintenance continue. « Il faut donc une compréhension explicite du schéma, des instructions déterministes pour chaque source de données et une maintenance continue à mesure que les schémas évoluent, créant de fait une nouvelle catégorie de charge de travail, celle de l’ingénierie de l’accès aux données pour les agents », a-t-il souligné.

« Le compromis est clair : sans QueryData, les systèmes sont plus rapides à développer mais peu fiables en production ; lui, ils sont plus lents à développer mais viables à grande échelle », a-t-il ajouté. Selon M. Jain, en fin de compte, ce compromis influencera les modèles d'utilisation des entreprises, l'adoption étant susceptible d'être la plus forte dans les environnements réglementés et critiques, tout en restant plus lente dans les cas d’usage légers ou expérimentaux.

Une approche moins flexible que la concurrence

De plus, l’analyste fait remarquer que cet outil marque également une stratégie plus large de la part de Google Cloud. « Il montre que la société tente de créer une méthode standard permettant aux agents IA d’accéder aux données et de les utiliser en toute sécurité. Alors qu’OpenAI se concentre sur les API, AWS sur les connecteurs et Microsoft sur des applications comme Copilot, Google se concentre sur la couche de données elle-même, sur la manière dont les agents communiquent réellement avec les bases de données ». Pour lui, « cette approche présente des atouts, notamment grâce à une intégration étroite avec BigQuery et à l’expertise de Google en matière de données. Mais elle comporte aussi des défis, car elle nécessite davantage de configuration initiale et offre moins de flexibilité entre les plateformes. Microsoft, dans ce cas, semble avoir un avantage, puisque ses outils sont déjà intégrés aux applications quotidiennes que les gens utilisent », a-t-il estimé. « Le risque pour Google est que des approches plus simples proposées par AWS ou Microsoft pourraient limiter QueryData à des cas d’usage avancés, au lieu d'en faire une norme couramment adoptée. »