17 agosto 2026/Lettura: 8 minProdotto e tecnologia
Creare un livello di contesto interno per gli agenti AI in Snowflake
Le aziende moderne raccolgono e gestiscono milioni di fonti dati e segnali in tutta la propria organizzazione. In Snowflake usiamo internamente Snowflake per monitorare su scala i nostri sistemi aziendali e la telemetria dei prodotti, attraverso ogni singola query, warehouse e click. Ma senza una comprensione condivisa, petabyte di dati grezzi diventano una fonte di risposte contrastanti, anziché una base solida per l’azione.
Per sfruttare i nostri dati su scala sia per gli utenti umani sia per gli agenti AI, curiamo un livello semantico interno. In questo post spieghiamo come abbiamo creato il nostro livello di contesto utilizzando la semantica e le best practice che abbiamo appreso lungo il percorso.
Figura 1: L’ambiente interno di Snowflake utilizza un livello semantico per consentire a qualsiasi entità di interrogare dati coerenti e accurati.
Il collo di bottiglia non sono mai stati i dati: era il contesto
L’immensa quantità di telemetria interna offre un potenziale straordinario, ma la stessa complessità di scala rende frustranti le modalità di errore. Prendiamo una domanda all’apparenza semplice come: “Che cos’è un cliente attivo?” Questa domanda potrebbe produrre risposte diverse a seconda della tabella e delle differenti definizioni delle metriche:
Attivo è WHERE days_since_last_login < 30 dalla tabella login_counts
Attivo è WHERE credits_consumed > 0 and account_type != ‘TRIAL’ dalla tabella customers
Attivo è COUNT(DISTINCT account_id) senza identificatore di regione dalla tabella customers_with_accounts
In base ai nostri casi d’uso interni e a quanto riscontrato presso i clienti, l’onere di chiarire il significato dei dati ricade solitamente sui team di data science: Gli utenti progettano le query e le verificano con un data scientist di riferimento, che evidenzia errori e criticità.
Il problema dell’allineamento peggiora in modo esponenziale con l’AI. Nuove metriche e fonti dati vengono create a una velocità incredibile, generando lacune informative persino per gli analisti più esperti. Se un Cortex Agent riporta un numero e una dashboard legacy ne mostra un altro, nessuno sa di quale fonte fidarsi.
Un’unica definizione per ogni interfaccia AI e BI
Ogni interfaccia necessita di un significato coerente, ovvero di un contesto, per i propri dati: un obiettivo raggiungibile grazie a un livello semantico. Una vista semantica è un oggetto di livello superiore posizionato tra i consumatori a valle e le tabelle di dati grezzi, che traduce la logica aziendale governata in schemi fisici di database.
Anziché esporre direttamente le tabelle grezze a dashboard o agenti AI, la vista semantica standardizza il flusso di dati dalle tabelle fisiche a fatti, dimensioni e metriche. In questo modo, persone e strumenti dispongono di un contesto coerente sul significato dei dati prima ancora di interrogarli.
Figura 2: Le viste semantiche combinano nomi logici, metriche e metadati AI al di sopra delle tabelle fisiche per alimentare i consumi a valle.
Gli agenti AI ottengono due vantaggi principali quando utilizzano le viste semantiche per interrogare dati su scala:
Esecuzione più rapida: Gli agenti che interrogano dati grezzi perdono tempo a cercare, comprendere e campionare più fonti dati. Su larga scala, questi processi possono incidere pesantemente sul tempo di esecuzione. Utilizzando le viste semantiche, invece, gli agenti possono passare direttamente all’esecuzione SQL.
Costi inferiori: Gli agenti utilizzano i token in modo molto più efficiente quando sfruttano le relazioni tra le tabelle e i dati di join presenti nelle viste semantiche. Grazie alla materializzazione, l’SQL semantico sfrutta in modo nativo i dati pre-aggregati, riducendo l’elaborazione ripetuta.
Con un’architettura dati orientata alla semantica, i vantaggi si moltiplicano rapidamente in tutto lo stack:
Maggiore accuratezza: fornisce ai modelli un contesto aziendale preciso. Nei test di benchmark di AtScale, l’aggiunta del contesto semantico ha portato l’accuratezza text-to-SQL dal 20% a oltre il 90% su 40 domande aziendali basate su TPC-DS.
Un’unica fonte di verità: sostituisci le semantiche isolate e specifiche dei singoli strumenti con un unico livello semantico.
Governance inclusa: sfrutta in modo nativo i controlli degli accessi di Snowflake sulle viste semantiche e sugli oggetti metrica.
Vero self-service: consenti a qualsiasi utente di porre in autonomia domande ad hoc in linguaggio naturale.
"Con le Semantic View otteniamo un golden layer, un'unica API affidabile per i nostri dati. Con le materializzazioni delle viste semantiche, questa API semantica è ora disponibile per tutti i consumer downstream, inclusi i casi d'uso in cui le prestazioni delle query sono critiche. Le query provenienti da dashboard, sistemi AI e workflow ad hoc possono ora essere eseguite attraverso la stessa API dati affidabile."
Zachary Blackwood
Staff Data Scientist, Snowflake
Il team interno di product data science di Snowflake utilizza un agente che sfrutta il livello semantico interno per rispondere alle domande sui prodotti provenienti dall’intera azienda. Solo nel mese di luglio 2025, oltre 400 utenti interni distinti hanno eseguito più di 5400 query tramite l’agente di product data science e il livello semantico. Nello stesso arco temporale, oltre 5600 dipendenti interni, in tutti i team e agenti Snowflake, hanno eseguito più di 320.000 query utilizzando l’ampio livello semantico nei settori sales, HR, supporto e in altre aree.
Figura 3: Con un livello semantico unificato, tutti gli strumenti e le interfacce ottengono un significato dei dati unico, coerente e governato.
Best practice per il livello semantico
Gestire le versioni, testare e valutare le viste semantiche
Il livello semantico deve essere trattato con lo stesso rigore riservato al software di produzione. Grazie all’integrazione nativa di Snowflake con data build tool (dbt), siamo in grado di gestire in modo completo il controllo delle versioni, la peer review e le procedure di integrazione e distribuzione continue (CI/CD) per le nostre metriche. Sebbene in Snowflake sviluppiamo le viste semantiche principalmente tramite codice, utilizziamo l’interfaccia utente per effettuare test e suggerire miglioramenti che si integrano con il nostro codice. Poiché l’interfaccia utente e il codice sottostante sono perfettamente sincronizzati, gli utenti possono facilmente passare dalla creazione di una vista nell’interfaccia utente Snowflake al commit dei campi nei repository.
Per valutare le viste semantiche, dovevamo accedere alle domande che le persone pongono concretamente. Una fonte di alto valore per le valutazioni è rappresentata dai riquadri delle dashboard più utilizzate, creati e usati proprio per rispondere a domande specifiche. Registriamo inoltre le domande più comuni per affinare i nostri set di valutazione.
Prioritizzare le prestazioni con il data engineering
Se il tuo livello semantico si basa su query lente e tabelle strutturate male, anche i tuoi agenti AI saranno lenti. All’inizio abbiamo provato a puntare una vista semantica verso più tabelle di eventi grezzi contenenti miliardi di righe. Ogni volta che un utente poneva una domanda, la vista scansionava ed eseguiva il join di queste tabelle, causando una latenza enorme.
In un primo momento, abbiamo creato e gestito direttamente i nostri slice pre-aggregati tramite le Dynamic Tables. Ogni dashboard disponeva del livello di aggregazione e del dettaglio necessari. Tuttavia, estendendo la copertura semantica per supportare nuove domande e domini, abbiamo dovuto aggiungere manualmente nuove pipeline e tabelle, trovandoci a gestire un patrimonio di dati in rapida crescita.
Grazie alle materializzazioni delle viste semantiche, possiamo modellare le viste semantiche direttamente su tabelle sorgente ad alto dettaglio e definire quali combinazioni di dimensioni e metriche debbano garantire risposte rapide. Snowflake gestisce in background questi slice in modo intelligente, riducendo i tempi di risposta.
Inoltre, abbiamo utilizzato Snowflake CoCo per tracciare e perfezionare i nostri processi semantici e di dati, grazie alle sue funzionalità integrate per le viste semantiche progettate appositamente per questi casi d’uso.
Curare con precisione e instradare in modo intelligente
Un livello semantico disordinato e incoerente vanifica l’obiettivo di standardizzare le metriche. Per le aree di prodotto chiave su cui vengono eseguite frequenti query, curiamo le viste semantiche (tramite CoCo) per rispondere a quesiti specifici. Ogni query viene registrata all’interno di Snowflake, compresi i risultati restituiti. In questo modo, possiamo sviluppare facilmente nuove viste semantiche e query verificate per estendere continuamente la copertura in base alle richieste degli utenti.
Per l’instradamento intelligente, i Cortex Agent scansionano automaticamente tutte le viste semantiche utilizzando le nostre istruzioni di instradamento personalizzate per individuare il contesto corretto per una determinata query. Infine, per un’ampia copertura della long tail dei dati, ci affidiamo a Cortex Sense, che valuta i dati in tutto il nostro ambiente per instradare le domande verso i set di dati pertinenti.
Crea oggi stesso il tuo livello semantico
I dati grezzi non rispondono alle domande: è il contesto a farlo. Il livello semantico agisce come un “golden layer”, definendo la logica aziendale un’unica volta per alimentare ogni dashboard, app Streamlit e Cortex Agent nell’azienda orientata agli agenti.
È possibile iniziare a creare una vista semantica utile con un solo file. Nota: in questo esempio utilizziamo YAML, ma la definizione delle viste semantiche tramite SQL è pienamente supportata.
name: account_activity_model
tables:
- name: daily_account_usage
base_table:
database: core
schema: metrics
table: daily_account_usage
dimensions:
- name: region
expr: region
data_type: VARCHAR
description: "The geographic region of the account." # AI metadata
synonyms: ["location", "geography", "area"] # AI metadata
metrics:
- name: compute_spend
expr: SUM(credits_used)
description: "The total number of Snowflake credits consumed." # AI metadata
synonyms: ["cost", "spend", "credits used", "usage"] # AI metadata
verified_queries: # AI metadata
- name: total_spend
question: "What is the total compute spend?"
use_as_onboarding_question: true
sql: |
SELECT
SUM(credits_used) AS compute_spend
FROM core.metrics.daily_account_usage
ORDER BY compute_spend DESC
Ora è possibile interrogare direttamente la vista semantica tramite SQL standard, senza doversi preoccupare dei join sottostanti o dei nomi delle colonne grezze:
SELECT
region,
AGG(compute_spend) as compute_spend
FROM account_activity_model
GROUP BY region
ORDER BY compute_spend DESC;
Per migliorare le prestazioni, possiamo anche materializzare questa vista semantica per pre-aggregare le metriche (compute_spend) lungo le dimensioni (region):
ALTER SEMANTIC VIEW account_activity_model SET MAX_STALENESS = '1 hour';
ALTER SEMANTIC VIEW account_activity_model
ADD MATERIALIZATION spend_by_region
WAREHOUSE = semantic_wh
AS
DIMENSIONS
region
METRICS
compute_spend;
Le viste semantiche Snowflake sono interoperabili anche con Apache Ossie™ (in incubazione). Ossie è lo standard open neutrale rispetto ai vendor per i modelli semantici e di contesto aziendale. Ciò consente di utilizzare la propria semantica con lo strumento e la piattaforma che si preferisce. Anche se i modelli semantici sono archiviati altrove, è sempre possibile leggerli in Snowflake con una singola chiamata di funzione:
SELECT SYSTEM$READ_OSSIE_YAML_FROM_SEMANTIC_VIEW('db.schema.account_activity');
La semantica costituisce la base condivisa per l’intero stack di AI e analisi dei dati. Inizia subito a creare un’unica fonte di verità governata con Snowflake e continua a seguirci: nel prossimo post analizzeremo casi reali di clienti che utilizzano la semantica in produzione.
