Créer une couche sémantique pour l'IA à base d'agents avec EDB Postgres AI et Amazon Bedrock AgentCore
Dans un billet publié sur le blog d'AWS, les auteurs montrent comment construire une couche sémantique pour des agents d'IA avec EDB Postgres AI et Amazon Bedrock AgentCore. Un agent développé avec Strands Agents tourne sur AgentCore Runtime et l'interroge pour répondre à des questions de type « client 360 » (C360). La couche sémantique, appelée SemKB, est une base de connaissances sémantique créée par l'extension AIDB, directement dans la base Postgres opérationnelle. Les définitions métier s'écrivent avec de simples instructions COMMENT ON, complétées par la fonction aidb.createsemanticalias. Les clés étrangères servent à reconstituer automatiquement les chemins de jointure. Le catalogue d'outils d'AIDB est exposé à l'agent via le point d'accès MCP (Model Context Protocol) intégré à EDB, placé derrière un Application Load Balancer puis enregistré comme cible MCP dans AgentCore Gateway. Les données viennent du Stardog C360 Knowledge Kit, chargé dans un schéma « c360 » : quatre tables (customers, locations, products, purchases) et une vue dérivée, big_spender. Claude sur Amazon Bedrock fait office de modèle.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'intérêt tient à l'endroit où s'applique la gouvernance. Les droits ne reposent pas sur une consigne glissée dans le prompt système, mais sur les mécanismes natifs de Postgres : rôles, GRANT au niveau des colonnes et sécurité au niveau des lignes. Deux rôles qui posent la même question à l'agent obtiennent donc des réponses différentes, alors que le prompt, le catalogue d'outils et le code de l'agent restent identiques. Chaque exécution SQL est en outre tracée en OpenTelemetry et stockée sous forme de lignes dans le schéma aidb_otel, ce qui permet d'auditer le comportement de l'agent avec du SQL ordinaire. Pour les équipes qui exploitent déjà Postgres, le sens des données reste ainsi à côté des données, sans plateforme sémantique distincte à synchroniser et à sécuriser.
Ce billet prolonge une série qui a traité le même cas d'usage C360 avec le graphe de connaissances de Stardog, la virtualisation de données de Denodo, le modèle dimensionnel d'AtScale et les modèles liés de Strategy Mosaic. Toutes reprennent le même cadre en trois couches : un modèle qui planifie et écrit les requêtes, une couche de sens qui explique ce que représentent les données, et un runtime qui héberge l'agent et contrôle identité et accès. Ici, AgentCore Gateway gère l'autorisation entrante et AgentCore Identity conserve les identifiants sortants vers les outils. La couche de sens est la seule à changer. Elle doit lever des ambiguïtés que les noms de colonnes ne révèlent pas : l'État d'un client ne figure pas dans la table customers mais dans locations, accessible par la clé étrangère customers.location, et la colonne purchases.price enregistre le total de la commande, pas un prix unitaire. Des commentaires bien rédigés permettent à l'agent d'éviter ces erreurs d'interprétation.
Pas d'impact direct sur la France/UE