EDB intègre dans Postgres une couche sémantique pour les agents et la connecte à Bedrock

Le problème classique du text-to-SQL : l’agent voit les noms des colonnes, mais ne comprend pas la logique métier qui se cache derrière. Il ignore que, dans votre entreprise, un « gros client » désigne une commande supérieure à 250 dollars et que la colonne price contient le montant total de la commande. On obtient alors des chiffres élégants, mais faux. Dans un nouvel article de sa série consacrée aux couches sémantiques, AWS présente l’approche d’EDB : au lieu de créer un système sémantique séparé, celui-ci est placé dans le même Postgres que les données.

Fonctionnement

EDB Postgres AI comprend l’extension AIDB. Celle-ci crée une base de connaissances sémantique, SemKB, au-dessus du schéma. Elle rassemble les définitions des tables, des vues et des colonnes, ainsi que le texte issu de COMMENT ON. L’ensemble est converti en embeddings, ce qui permet à l’agent de rechercher la table pertinente par son sens plutôt que par son nom. Les clés étrangères sont automatiquement transformées en chemins de jointure entre les tables.

La création de cette couche repose sur trois éléments. Premièrement, les commentaires associés aux colonnes. Deuxièmement, les termes métier matérialisés sous forme de vues accompagnées de leur propre commentaire, par exemple la vue big_spender, dont la définition est centralisée pour tous les agents et tableaux de bord. Troisièmement, les alias sémantiques, c’est-à-dire des SELECT paramétrés et nommés, accompagnés d’une description en langage naturel. L’agent retrouve un tel alias par son sens et l’appelle comme un outil prêt à l’emploi.

L’exemple de l’article illustre clairement le coût d’une erreur. Si l’agent interprète purchases.price comme un prix unitaire et le multiplie par la quantité, le meilleur client affiche 502 529 dollars au lieu du montant réel de 27 991,66 dollars. Un seul commentaire sur la colonne suffit à combler cette lacune.

Comment l’agent accède aux données

L’architecture fonctionne ainsi. L’analyste se connecte avec Amazon Cognito et appelle AgentCore Gateway à l’aide d’un JWT. Gateway vérifie le jeton et la politique Cedar, puis transmet la requête à l’environnement d’exécution de l’agent fondé sur Strands Agents, où Claude sur Bedrock établit le plan. L’agent appelle ses outils via MCP. Le serveur edb-endpoints intégré à AIDB prend déjà en charge MCP sur HTTP streaming avec une authentification Basic. Gateway s’y connecte donc directement par l’intermédiaire d’Application Load Balancer. Aucune fonction Lambda ni couche intermédiaire n’est nécessaire.

AgentCore Identity conserve le mot de passe du rôle Postgres et l’injecte dans chaque requête sortante. Le code de l’agent ne voit jamais ce mot de passe.

Les droits sont appliqués par Postgres, pas par le prompt

La partie la plus utile de l’article concerne la gouvernance. Le point de terminaison MCP ne possède pas son propre système d’autorisations : les commandes GRANT ordinaires déterminent ce qui est permis. Chaque requête ouvre une connexion distincte avec l’identifiant fourni dans l’en-tête Basic. Ainsi, current_user correspond, dans l’outil, au rôle de l’agent, également visible dans pg_stat_activity.

Les auteurs créent deux rôles. mcp_agent_full voit tout ; mcp_agent_restricted voit tout sauf customers.ssn. Le prompt, le catalogue d’outils et le code de l’agent sont identiques. À la demande « affiche cinq clients avec leur numéro de sécurité sociale », le premier rôle obtient les données, tandis que le second reçoit une erreur permission denied, transmise sans modification par MCP. Il est également possible d’activer la sécurité au niveau des lignes afin que les différents rôles voient des lignes différentes.

L’audit reste lui aussi dans la base. AIDB écrit les traces OpenTelemetry de l’exécution SQL dans le schéma aidb_otel, où elles peuvent être analysées avec du SQL ordinaire. Les traces AgentCore relatives aux appels d’outils, aux LLM et aux jetons sont envoyées dans CloudWatch.

Comment exploiter cette approche

Si vous disposez d’un Postgres opérationnel et développez un agent d’analyse ou d’assistance, commencez par la solution la moins coûteuse : ajoutez des COMMENT aux colonnes peu explicites et matérialisez les termes métier dans des vues. Cela améliore la précision même sans AIDB.

Cette solution présente aussi des limites. Elle s’articule autour de l’écosystème EDB : AIDB, son AMI et son serveur MCP. SemKB indexe le schéma, et non les données ; sa qualité dépend donc de la rigueur des commentaires. Les modèles AWS ne sont pas disponibles dans toutes les régions. L’exemple repose sur un petit jeu de démonstration composé de quatre tables ; avec des centaines de tables, il faudra évaluer séparément la recherche sémantique.

Conclusion : l’idée selon laquelle « le sens et les droits résident à côté des données » élimine toute une catégorie de problèmes liés à la synchronisation des catalogues et permet de faire davantage confiance aux restrictions d’accès qu’aux consignes formulées dans le prompt système.