Gli agenti generativi promettono di ragionare sui dati, non solo di visualizzarli: pianificano, scrivono query, valutano i risultati e iterano sui dati vivi dell’azienda. Il modello di fondazione non è più la parte difficile; i foundation model su Amazon Bedrock sanno già pianificare workflow multi-step e produrre SQL. La parte difficile sta sotto: i dati. Il “customer” del CRM non è lo stesso record del “customer” del billing, e il “revenue” del team nordamericano non coincide con quello europeo. Un agente con accesso diretto a dati frammentati scrive query tecnicamente valide ma restituisce risposte sbagliate o contraddittorie. Questo post AWS mostra come colmare il gap con un semantic layer costruito con Stardog.
Tre layer di cui un agente ha bisogno
L’architettura poggia su tre componenti. Il model layer è un foundation model che pianifica e scrive query (qui Anthropic Claude Sonnet 4.6 su Bedrock). Il meaning layer è il semantic layer: un’ontologia che dichiara concetti e regole, con una federazione che recupera le righe live da ogni sorgente a query time. L’agent runtime layer è il compute che ospita l’agente, termina le richieste in ingresso e gestisce le credenziali: qui Amazon Bedrock AgentCore, che raccoglie hosting, auth e credential vault in un servizio gestito.
Il semantic layer di Stardog
Il semantic layer è una vista ontology-driven dei dati: l’ontologia cattura concetti, relazioni e regole, mentre i mapping dichiarano come le righe di ogni sorgente diventano istanze di quei concetti. L’agente interroga il layer in SPARQL; Stardog riscrive la query in SQL contro Aurora e Redshift a runtime e unisce i risultati. I dati restano dove sono, non c’è ETL né una terza copia. Il meccanismo chiave è l’IRI template: sia il mapping Aurora sia quello Redshift generano lo stesso identificatore stabile per lo stesso cliente (ad esempio urn:stardog:demos:c360:customer:42), così il join tra i due warehouse è l’accordo sull’IRI, non una pipeline fisica. Le definizioni di business come “big spender” vivono come regole di reasoning, valutate sui dati live a query time.
Governance e integrazione
L’accesso è governato con la named-graph security: si suddivide il mapping in virtual graph (profilo senza PII, solo PII) e si assegnano letture per ruolo. La stessa query SPARQL restituisce risultati diversi a hr_user e marketing_user, senza filtri applicativi né modifiche al warehouse. L’agente Strands si collega a Stardog con un tool SPARQL diretto (Path A) o tramite il server MCP di Stardog Cloud registrato come target del Gateway (Path B, che espone Voicebox). Per la produzione AWS consiglia il prompt caching di Bedrock, dato che l’ontologia viene riusata in ogni chiamata.
- Il semantic layer complementa RAG: molti sistemi in produzione hanno bisogno di entrambi.
- La federazione via virtual graph evita ETL e copie duplicate dei dati.
- Stardog Cloud (SaaS, SLA 99,9%) o self-managed su EKS: la scelta è operativa, non funzionale.
Fonte: Build a semantic layer for agentic AI on AWS with Stardog and Amazon Bedrock AgentCore — https://aws.amazon.com/blogs/machine-learning/build-a-semantic-layer-for-agentic-ai-on-aws-with-stardog-and-amazon-bedrock-agentcore/
Hai qualcosa da aggiungere? Unisciti alla discussione.