Sophrosyne: Agentic Exploration of Relational Data Systems Needs Moderation

Résumé technique : Sophrosyne – La modération de l'exploration agentique des systèmes de données relationnelles

Énoncé du problème
Les agents Text2SQL alimentés par des modèles de langage étendu (LLM) s'appuient de plus en plus sur des appels d'outils pour explorer les systèmes de données avant de formuler des requêtes SQL. Pour garantir la sécurité et un accès délimité, les systèmes de données exposent ces agents via des surfaces d'API explicites. Les auteurs identent un compromis fondamental dans la conception de ces API :

• API à granularité grossière (Coarse-grained) : Fournissent l'intégralité du schéma de la base de données dès le départ. Bien que cela donne à l'agent une visibilité totale, cela entraîne des coûts de jetons (tokens) prohibitifs car l'agent doit traiter des éléments de schéma non pertinents pour chaque requête.
• API à granularité fine (Fine-grained) : Permettent une exploration progressive (par exemple, lister d'abord les tables, puis inspecter des schémas spécifiques). Bien qu'efficaces en termes de jetons, l'absence de visibilité globale du schéma force les agents à une « sur-exploration ». Les agents, incapables de savoir a priori quelles tables sont pertinentes, inspectent souvent des tables non pertinentes et les incorporent dans la construction de la requête, ce qui conduit à une génération de SQL inexacte.

L'article postule que la majorité des systèmes de données modernes (par exemple, Amazon Redshift, GCP BigQuery, Supabase) exposent des API à granularité fine, rendant par inadvertance les agents vulnérables à la sur-exploration et à une réduction de la précision.

Méthodologie : Le système Sophrosyne
Les auteurs proposent Sophrosyne, un environnement de système de données conçu pour atténuer la sur-exploration dans les contextes d'API à granularité fine sans sacrifier les avantages de coût de l'exploration progressive.

• Mécanisme central (Directives) : Sophrosyne augmente la réponse standard de l'API (spécifiquement l'appel list_tables, qui est typiquement le premier appel d'outil de l'agent) avec des directives. Ces directives informent explicitement l'agent quelles tables sont probablement non pertinentes par rapport à la requête en langage naturel actuelle, limitant ainsi son exploration future.
• Implémentation :
  • Phase hors ligne (Offline) : Un index de recherche hybride (HIcol) est construit sur les noms de colonnes individuels. Cet index combine un index IVF pour la similitude sémantique et un index BM25 pour la correspondance par mots-clés, utilisant des résultats fusionnés via la fusion de rang réciproque (reciprocal rank fusion).
  • Phase en ligne (Online) : Lorsqu'un agent demande une liste de tables, Sophrosyne :
    1. Déduit les noms de colonnes potentiellement pertinents à partir de la requête de l'utilisateur (en utilisant un modèle peu coûteux).
    2. Recherche dans l'index HIcol avec ces noms déduits pour identifier les tables les plus pertinentes.
    3. Calcule l'ensemble des tables non pertinentes (celles qui ne figurent pas dans les résultats de la recherche).
    4. Renvoie la liste standard des tables accompagnée d'une directive énumérant les tables non pertinentes.
• Configuration de l'évaluation : Le système a été évalué à l'aide d'un serveur MCP pour SQLite exposant une API à granularité fine. L'agent (basé sur OpenCode) a été testé sur 157 requêtes du benchmark BIRD LiveSQLBench en utilisant trois modèles : GPT-5.4-mini, GPT-5.4 et Claude Sonnet 4.5.
• Comparaisons de référence (Baselines) : L'étude a comparé trois configurations :
  1. Sans directives (No Directives) : Exposition standard de l'API à granularité fine.
  2. Sophrosyne : Utilise les directives calculées (imparfaites).
  3. Sophrosyne-Oracle : Utilise des directives parfaites dérivées des requêtes SQL de vérité terrain (représentant une limite supérieure de performance).

Résultats clés

• Réduction de la sur-exploration : L'introduction de directives a considérablement réduit le nombre d'appels d'outils exploratoires. Sophrosne a réduit la sur-exploration jusqu'à 4,6× par rapport à la référence. La variante Oracle a réduit cet effet encore davantage.
• Améliorations de la précision : En empêchant les agents d'incorporer des tables non pertinentes dans leur logique, Sophrosyne a amélioré la précision de l'exécution SQL. Les meilleurs résultats ont montré un gain de précision allant jusqu'à 12,4 % (environ 4 points de pourcentage) par rapport à la référence.
• Efficacité des jetons (Tokens) : Bien que l'exploration à granularité fine soit déjà plus efficace que l'approche à granularité grossière, Sophrosyne a réduit davantage la consommation de jetons en limitant les éléments de schéma que l'agent traite. Par exemple, sur Sonnet-4.5, les jetons d'entrée sont passés de 8,74 M à 8,00 M.
• Analyse des coûts : La surcharge pour le calcul des directives (déduction des colonnes et plongements/embeddings) était d'environ 8 cents par exécution. Pour la plupart des modèles (Sonnet-4.5 et GPT-5.4), les économies réalisées grâce à la réduction de l'utilisation des jetons ont compensé cette surcharge. Pour GPT-5.4-mini, la surcharge a légèrement dépassé les économies de base, bien que la précision se soit tout de même améliorée.

Signification et affirmations
L'article affirme être la première étude à catégoriser les surfaces d'API des systèmes de données en types à granularité grossière et fine, et à identifier la sur-exploration comme un symptôme critique du compromis inhérent à la conception des API à granularité fine.

Les auteurs soutiennent que freiner la sur-exploration est essentiel pour l'utilisation efficace des API à granularité fine. Sophrosyne démontre que les environnements de systèmes de données peuvent activement guider le comportement des agents grâce à des directives légères, équilibrant le besoin d'un accès sécurisé et délimité avec le besoin d'une génération de requêtes précise. Ce travail suggère que les futurs agents et systèmes de données ne devraient pas seulement exposer passivement des API, mais devraient activement fournir du contexte (comme des directives) pour modérer l'exploration de l'agent, un concept que les auteurs nomment « Sophrosyne » (la vertu grecque de la prudence et de la modération).

L'article conclut que bien que le calcul de directives parfaites soit difficile, même des directives imparfaites produisent des gains significatifs, et que les travaux futurs pourraient étendre cela aux environnements multi-sources et au conseil de performance (performance hinting).