Le semantic view hanno bisogno di un IDE: ecco Semantic Studio

Quando un agente AI fornisce a qualcuno una risposta errata, passare dall’ID della richiesta nel monitoraggio al motivo reale dell’errore può richiedere un intero pomeriggio, anche se la soluzione in sé è di solito semplice una volta trovata.

Spesso i problemi degli agenti AI sono legati a definizioni di metriche errate o ad altre istruzioni, di solito all’interno di una semantic view. Uno o due anni fa, le semantic view in Snowflake sono nate come contesto per una singola implementazione di Snowflake Cortex Analyst, e si presumeva che una o due persone conoscessero i dati abbastanza bene da poterli mantenere. Ma dato che gli agenti per i dati sono decollati, le semantic view ora vengono lette da ogni agente AI e da ogni strumento di business intelligence che tocca una metrica, quindi una modifica di una sola riga può avere un impatto su tutti contemporaneamente. L’editor che abbiamo creato per quel primo pubblico era un’unica pagina nella sezione AI & ML dell’interfaccia Snowsight, in qualche modo scollegata da tutto il resto del lavoro che le persone che si occupano di dati stavano svolgendo.

Siamo entusiasti di annunciare che Semantic Studio, l’IDE per le semantic view, è in GA. Porta la creazione delle semantic view in Workspaces, insieme a SQL, notebook e progetti dbt che il team ha già lì, e aggiunge integrazioni avanzate con Snowflake CoCo, controllo delle versioni git e miglioramenti dell’esperienza utente.

Prova oggi Semantic Studio in Snowflake | Leggi la documentazione

In passato, correggere i problemi negli agenti AI era un processo articolato in più fasi. La prima tappa era il controllo del monitoraggio, per trovare i dettagli della richiesta e ottenere il relativo ID. Da lì si apriva la traccia dell’agente AI per capire quale strumento fosse responsabile. Restringere il campo significava leggere l’SQL generato e confrontarlo con una query che si sarebbe scritta autonomamente.

L’editor delle semantic view si trovava in una sezione diversa di Snowsight e si apriva all’inizio del file, perché l’interfaccia non aveva alcun contesto su quale errore dell’agente AI si stesse correggendo. Verificare un’ipotesi su una metrica significava eseguire SQL semantico su una definizione non ancora salvata, quindi si apriva un foglio di lavoro e si scriveva a mano la query che l’agente AI avrebbe generato. Se funzionava, si tornava all’editor, poi all’agente AI e infine al monitoraggio per la conferma.

Quattro superfici diverse per correggere una sola riga, e il lavoro di collegarle tra loro spettava a te.

La nostra telemetria interna mostrava che più della metà degli sviluppatori di agenti AI passava continuamente dall’interfaccia delle semantic view a quella di amministrazione degli agenti AI, e quando abbiamo chiesto a questi sviluppatori cosa rendesse difficile la manutenzione, ciò che descrivevano era proprio questo lavoro, non la modifica in sé.

Correlare tutto questo è un lavoro che vorresti affidare a un agente AI di coding. Semantic Studio porta le semantic view in Workspaces, dove CoCo è attivo nel pannello accanto all’editor. Le tab non sono caricamenti di pagina, quindi passare da una definizione a un eval e al relativo risultato risulta molto più rapido

La sessione inizia sempre nello stesso posto, con un ID di richiesta proveniente dal monitoraggio. Basta fornire l’ID a CoCo per sapere quale metrica ha prodotto il numero e per quale motivo, perché ha accesso contemporaneamente alla configurazione dell’agente AI, alla query eseguita e ai log. La risposta arriva in linguaggio naturale, e puoi semplicemente chiedere di correggere la tua semantic view.

Fidarsi di quella risposta è più facile quando una definizione si trova accanto ai dati che produce. Una definizione può sempre essere verificata facilmente chiedendo a CoCo cosa restituisce, invece di leggere l’espressione e immaginare il risultato.

La correzione arriva come diff (un confronto che mostra cosa verrebbe aggiunto, rimosso o modificato), che puoi accettare o rifiutare. Appare nell’editor visuale o in YAML, e i due restano sempre sincronizzati.

Anche ogni altro agente AI e dashboard che legge quelle metriche riceve la modifica, quindi l’ultima parte del pomeriggio si dedica a distribuirla con attenzione. In Workspaces, una semantic view è un file in un repository di proprietà del team, il che la rende una versione da promuovere piuttosto che un oggetto live da sovrascrivere. Eseguire il set di eval sulla semantic view modificata ti dice innanzitutto se le domande che prima funzionavano continuano a funzionare.

Da quel punto, il workflow è lo stesso di qualsiasi altra cosa che il team rilascia. La modifica viene distribuita come pull request, così qualcun altro legge il diff e il ragionamento dietro di esso, e la CI può eseguire gli eval quando si fa il merge. Il deployment mostra esattamente cosa cambierà e attende una conferma, e un singolo file può puntare separatamente a development, staging e production. Successivamente, la modifica resta nella cronologia con un autore e un motivo associati, e puoi annullarla.

Aprire una semantic view in Snowsight ora porta direttamente a Semantic Studio. Prova Semantic Studio nel tuo account, oppure leggi la documentazione per saperne di più.