Dai dati al dialogo: come S&P Global Energy ha reso conversazionale il suo patrimonio di dati strutturati con Databricks Genie Agents e MCP

L'obiettivo di S&P Global era migliorare radicalmente il modo in cui i clienti scoprono e utilizzano gli insight nei nostri prodotti di dati e ricerca. Sebbene la ricerca e la sintesi basate sull'AI siano importanti, il valore aziendale maggiore deriva dal consentire un processo decisionale più rapido attraverso l'accesso in linguaggio naturale a dati affidabili, analisi cross-commodity più ricche e la capacità di collegare insight che tradizionalmente esistono in linee di business separate. Gli agenti AI aiutano i clienti a scoprire relazioni, generare ricerche in modo più efficiente e trarre informazioni utili da un insieme di informazioni più ampio rispetto a quanto fosse possibile in precedenza.   —Priyanka John, Vice President, S&P Global Energy

Se hai mai provato a rendere disponibile un patrimonio di dati strutturati ampio e complesso ad agenti e assistenti AI, probabilmente ti sarai scontrato con lo stesso ostacolo che abbiamo incontrato noi: gli agenti sono efficaci solo quanto il contesto a cui possono accedere, e i dati aziendali raramente risiedono in un unico luogo ordinato e ben documentato.

In S&P Global Energy, i nostri dati coprono prodotti chimici, greggio, prodotti raffinati, gas ed energia elettrica, gas naturale liquefatto (LNG) e altro ancora — e ogni commodity è di per sé una ricca famiglia di dataset. Il solo LNG include specifiche degli impianti, carichi, interruzioni, fondamentali di domanda e offerta, netback, prezzi storici e di previsione, e contratti. I prodotti chimici coprono capacità, produzione, utilizzo, commercio, domanda per uso finale e per derivato, variazione delle scorte e bilanci di domanda-offerta a livello di paese e regione. Le nostre altre commodity seguono modelli simili. Questi dati risiedono su Databricks e su diverse fonti non Databricks.

Il nostro obiettivo era ambizioso ma semplice da definire: rendere l'intero patrimonio di dati strutturati disponibile per il consumo esterno da parte di agenti AI tramite il Model Context Protocol (MCP) — in modo che gli agenti e gli assistenti dei nostri clienti, così come i nostri, potessero porre domande in linguaggio naturale e ottenere risposte affidabili e governate.

Abbiamo valutato diversi approcci. Quello che ha funzionato meglio per noi, con un ampio margine, è stato Databricks Genie Agents, esposti come server MCP gestiti, composti in bundle specifici per dominio con un livello proxy MCP.

In questo post scoprirai:

• In che modo i nostri esperti di dominio (SME) curano Genie Agents mirati — uno per gruppo di dataset all'interno di ciascuna commodity — senza scrivere una singola riga di codice dell'agente.
• In che modo ciascun Genie Agent diventa automaticamente un server MCP governato, pronto per essere collegato a qualsiasi client o agente compatibile con MCP.
• Come utilizziamo un proxy basato su FastMCP per comporre più server MCP Genie in endpoint compositi per domande cross-dominio.
• Perché questa architettura ha ridotto drasticamente il nostro time-to-market per i prodotti di dati basati sull'AI.

I Genie Agents consentono ai nostri esperti di dominio di trasformare direttamente in prodotto la loro conoscenza dei dati. Ciò che prima richiedeva un intero ciclo di sviluppo ora richiede pochi giorni, e ogni risposta rimane all'interno del nostro perimetro di governance. —Priyanka John, Vice President, S&P Global Energy

La sfida: i dati strutturati sono facili da archiviare, difficili con cui dialogare

I modelli linguistici di grandi dimensioni sono straordinariamente bravi nella conversazione e nel ragionamento, ma non possono rispondere a domande sui tuoi dati a meno che tu non crei un ponte verso di essi. Per i dati aziendali strutturati, quel ponte ha storicamente significato una delle seguenti opzioni:

1. Pipeline text-to-SQL create manualmente — potenti, ma fragili. Ogni modifica dello schema, ogni nome di colonna ambiguo, ogni definizione di metrica specifica del dominio (“Cosa conta come giorno di interruzione?”) diventa un'attività di engineering.
2. API personalizzate per caso d'uso — ogni nuovo modello di domanda richiede un nuovo endpoint, un nuovo sprint, una nuova release.
3. Esportazione di dati in strumenti AI esterni — il che duplica i dati, ne compromette la freschezza ed esce dal perimetro di governance.

Ognuno di questi approcci condivide lo stesso problema: le persone che comprendono meglio i dati — i nostri SME e analisti — non sono le stesse che creano il livello di accesso. Ogni insight doveva passare attraverso un backlog di engineering. Il nostro time-to-market per una nuova esperienza di dati conversazionali si misurava in mesi.

Avevamo bisogno di un approccio in cui gli esperti di dominio potessero curare e pubblicare direttamente l'accesso conversazionale ai dati, l'engineering potesse standardizzare il modo in cui gli agenti si connettono e la governance rimanesse centralizzata. Questo è esattamente ciò che ci hanno offerto i Genie Agents insieme a MCP.

L'architettura: Genie Agents come livello semantico, MCP come contratto

La nostra architettura ha tre livelli e ogni livello è gestito dalle persone più adatte a farlo. Il diagramma sopra mostra il flusso end-to-end — incluso ciò che si trova all'interno della rete di S&P Global Energy e ciò che si trova nell'ambiente client esterno.

Livello 1: gli SME curano un Genie Agent per gruppo di dataset

È qui che inizia la magia e, in particolare, non richiede codice.

I nostri SME iniziano selezionando le tabelle rilevanti per un dominio aziendale:

• Se le tabelle risiedono già in Databricks, le utilizzano direttamente tramite Unity Catalog.
• Se i dati risiedono in una fonte non Databricks, li importano tramite i connettori di Lakehouse Federation — senza spostamento di dati né pipeline duplicate. Le tabelle federate appaiono accanto alle tabelle native ed ereditano la stessa governance.

Quindi raggruppano le tabelle correlate e creano un Genie Agent per gruppo di dataset — non un unico enorme agente per commodity. Ogni sottocategoria di una commodity diventa un Genie Agent mirato a sé stante. All'interno dell'LNG, ad esempio:

• LNG Assets & Contracts Genie Agent — asset, operatori, previsioni di capacità e contratti a lungo termine
• LNG Cargo Genie Agent — tracciamento dei carichi, fixture, origini/destinazioni e termini commerciali
• LNG Tenders Genie Agent  — gare d'appalto con emittenti, volumi e finestre di consegna
• LNG Outages Genie Agent — interruzioni ed eventi di manutenzione con impatto sulla capacità
• LNG Supply & Demand Genie Agent — fondamentali con suddivisioni regionali e cronologia degli scenari
• LNG Netbacks Genie Agent — netback da prezzi degli hub, noli, boil-off e perdite
• LNG Prices Genie Agent — curve dei prezzi storici e di previsione

Ogni altra commodity segue lo stesso modello con le proprie sottocategorie. I prodotti chimici, ad esempio, dispongono di Genie Agents a livello di gruppo per capacità, produzione, utilizzo della capacità, commercio, domanda per uso finale e per derivato, variazione delle scorte e bilanci di domanda-offerta a livello di paese e regione; il greggio, i prodotti raffinati e il gas ed energia elettrica sono organizzati in modo simile. Il risultato è una flotta di Genie Agents piccoli e con un ambito ben definito, anziché una manciata di strumenti AI disconnessi e dispersivi.

All'interno di ciascun agente, gli SME aggiungono il contesto che rende il text-to-SQL effettivamente funzionante nel mondo reale: descrizioni di tabelle e colonne, query di esempio, asset affidabili per metriche ad alto rischio e definizioni aziendali (ad esempio, lo "stoccaggio galleggiante è definito come carichi inattivi per 3 o più giorni in imbarcazioni che viaggiano al di sotto di una velocità di soglia"). Questo è il passaggio che le soluzioni text-to-SQL generiche saltano — ed è il passaggio che determina se gli utenti si fideranno o meno delle risposte.

L'intuizione organizzativa chiave: la cura dei dati è diventata un'attività di dominio, non un'attività di ingegneria. La persona che sa cosa significa "floating storage" in un contesto LNG è la stessa che insegna a Genie cosa significa.

Livello 2: ogni agente Genie è automaticamente un server MCP

Ecco dove Databricks ha fatto il lavoro più pesante per noi. Ogni agente Genie viene esposto come server MCP gestito da Databricks pronto all'uso, presso un endpoint del tipo:

https://<workspace-hostname>/api/2.0/mcp/genie/{genie_space_id}

Non c'è nulla da distribuire e nulla da ospitare. Ciascun server espone un'interfaccia di strumenti ridotta e pulita, essenzialmente due strumenti per agente:

1. Uno strumento di query (genie_query_space): l'agente invia una domanda in linguaggio naturale all'agente.
2. Uno strumento di risposta (genie_poll_response): l'agente esegue il polling con lo stesso ID conversazione e ID messaggio per recuperare la risposta completa non appena è pronta, inclusi il codice SQL generato e il set di risultati.

Questo pattern a due strumenti, di tipo "chiedi e poi interroga" (ask-then-poll), si rivela ideale per i carichi di lavoro degli agenti: le domande vengono eseguite in modo asincrono su un SQL warehouse e l'agente esegue il polling con l'ID conversazione e l'ID messaggio restituiti dallo strumento di query finché la risposta non è pronta.

Altrettanto importante è il fatto che questi server gestiti sono governati da Unity Catalog. Un agente Genie (o l'utente che lo utilizza) può accedere solo agli agenti e alle tabelle sottostanti che ha il permesso di visualizzare. L'autenticazione è gestita dalla piattaforma. Non abbiamo dovuto creare un livello di sicurezza per il nostro accesso all'AI; abbiamo ereditato quello che già avevamo.

Livello 3: composizione di gruppi di agenti Genie in bundle di commodity con un proxy FastMCP

Un solo agente Genie per gruppo di dataset mantiene ogni agente focalizzato e accurato. Ma le reali domande di business incrociano regolarmente diversi gruppi: "In che modo le recenti interruzioni a Sabine Pass hanno influito sui premi dei carichi in Asia?" tocca contemporaneamente sia gli agenti Genie Outages e Cargo, e domande cross-commodity come "In che modo i prezzi della nafta influenzano i margini di produzione chimica?" coinvolgono sia gli agenti Genie Refined Products e Chemicals.

Invece di creare un unico agente gigante (il che riduce la qualità delle risposte) o costringere ogni client a configurare una dozzina di server separati, abbiamo utilizzato le funzionalità di proxy e composizione di FastMCP per creare endpoint MCP compositi (in genere uno per commodity), montando i server MCP Genie a livello di gruppo di quella commodity dietro un singolo server con strumenti dotati di namespace. I compositi di livello superiore possono raggruppare diverse commodity nello stesso modo:

from fastmcp import FastMCP

# Each group-level Genie Agent is a managed MCP server on Databricks 
cargo = FastMCP.as_proxy(genie_mcp_config(“lng_cargo_agent_id”), name=“cargo”) 
outages = FastMCP.as_proxy(genie_mcp_config(“lng_outages_agent_id”), name=“outages”) 
netbacks = FastMCP.as_proxy(genie_mcp_config(“lng_netbacks_agent_id”), name=“netbacks”) 

# Compose the group Genies into one commodity bundle 
lng = FastMCP(name=“lng-composite”) 
lng.mount(cargo, prefix=“cargo”)
lng.mount(outages, prefix=“outages”)
lng.mount(netbacks, prefix=“netbacks”) 

# The same pattern repeats for Chemicals, Crude Oil, Refined Products, Coal …

(Frammento illustrativo: adattalo alla tua versione di FastMCP e alla configurazione di autenticazione).

Il risultato: un agente si connette a un singolo endpoint composito per commodity e vede un set curato di strumenti di gruppo (cargo_genie_query_agent, outages_genie_query_agent, netbacks_genie_query_agent e così via), ciascuno associato alla sua controparte genie_poll_response. L'LLM dell'agente decide a quale gruppo Genie indirizzare una domanda, o distribuisce una domanda cross-group su più agenti, per poi sintetizzare i risultati.

Questo ci ha offerto il meglio di entrambi i mondi: agenti Genie a livello di gruppo mirati e ad alta precisione alla base, e un accesso conversazionale ampio, a livello di commodity e di intero patrimonio di dati, in cima.

Cosa è cambiato per il business

Per i nostri stakeholder aziendali, i dettagli tecnici sopra descritti si traducono in alcuni risultati molto concreti.

Il time-to-market è crollato. In precedenza, la creazione di una nuova esperienza di dati conversazionali richiedeva un intero ciclo di sviluppo: requisiti, progettazione delle API, ingegnerizzazione text-to-SQL, test, implementazione. Con questa architettura, il lancio di un nuovo gruppo di dataset (o di un'intera commodity) richiede solo che un SME crei e curi i relativi agenti Genie: l'endpoint MCP esiste nel momento stesso in cui viene creato l'agente.

Gli SME sono diventati editori, non richiedenti. Gli esperti di dominio che comprendono i carichi di LNG o i bilanci di domanda e offerta di prodotti chimici non devono più aprire ticket per rendere visibili i propri dati; curano un agente Genie e questo è subito attivo. L'impegno ingegneristico si è spostato dalla creazione di livelli di accesso personalizzati al mantenimento di un unico livello proxy leggero e riutilizzabile.

La governance è integrata. Ogni domanda posta da un agente passa attraverso i permessi di Unity Catalog, su tabelle governate (native o federate), con una completa verificabilità. Rendere i dati disponibili per l'AI non ha significato renderli disponibili al di fuori dei nostri controlli.

Un unico modello di integrazione, molti consumatori, sia all'interno che all'esterno dell'azienda. Poiché l'MCP è uno standard aperto, gli stessi endpoint compositi servono i nostri agenti interni, le nostre esperienze di AI rivolte ai clienti e, aspetto fondamentale, i nostri clienti esterni, che possono connettere i propri agenti e assistenti compatibili con MCP direttamente ai dati governati di S&P Global Energy. Abbiamo costruito il ponte una sola volta; ogni client MCP, interno o esterno, può attraversarlo.

La qualità delle risposte è misurabile e rimane tale. In un settore in cui i dati su prezzi, forniture e contratti guidano decisioni reali, gli utenti devono potersi fidare di ogni risposta e calcolo. I benchmark degli agenti Genie offrono ai nostri SME un modo integrato per definire domande di test che rispecchiano il modo in cui gli utenti pongono effettivamente le domande (comprese molteplici formulazioni della stessa domanda) e valutano automaticamente l'accuratezza dell'agente rispetto a risposte verificate. Altrettanto importante è il fatto che i benchmark possono essere eseguiti nuovamente dopo qualsiasi perfezionamento delle istruzioni, dei dati o della logica di business, in modo da mantenere l'accuratezza nel tempo. Il risultato è un efficiente ciclo continuo di qualità: cura, benchmark, miglioramento e nuovo benchmark per garantire che i nostri agenti rimangano accurati man mano che i nostri dati e le domande dei clienti si evolvono.

Lezioni apprese e best practice

Alcuni spunti pratici tratti dal nostro percorso, per i team che stanno valutando una strada simile:

1. Mantieni gli agenti Genie mirati e ben curati. La qualità delle risposte è massima quando un agente copre uno specifico dominio di dati con istruzioni chiare e query di esempio. Resisti alla tentazione di creare un agente per commodity o, peggio ancora, un unico agente per governarle tutte. Riunisci invece più domini di dati a livello di MCP.
2. Utilizza Lakehouse Federation prima di creare pipeline. Per le origini non Databricks, la federazione ci ha permesso di raggiungere un livello "conversazionale" senza un singolo nuovo processo ETL. Potrai sempre materializzare i percorsi caldi in un secondo momento.
3. Investi nel livello semantico. Le descrizioni delle colonne, le definizioni di business e le query di esempio verificate sono ciò che separa una demo da un prodotto. Questo è tempo ben speso per gli SME.
4. Assegna namespace chiari ai tuoi strumenti compositi. Quando un agente vede strumenti provenienti da molti gruppi Genie, i prefissi come cargo_ e outages_ aiutano l'LLM a indirizzare correttamente le domande.
5. Misura la fiducia, non solo la latenza. Abbiamo monitorato la frequenza con cui gli SME concordavano con il codice SQL generato da Genie durante la fase di cura: è il miglior indicatore predittivo dell'adozione dell'esperienza da parte degli utenti aziendali.

Conclusione

Il nostro obiettivo era rendere l'intero patrimonio di dati strutturati (che spazia da LNG, prodotti chimici, greggio, prodotti raffinati, gas ed energia e altro ancora) disponibile per gli agenti di AI in modo sicuro, accurato e rapido. Con gli agenti Genie di Databricks come livello semantico curato dagli SME, i server MCP gestiti come contratto di integrazione a zero implementazione e un proxy FastMCP per la composizione cross-domain, abbiamo ottenuto esattamente questo:

• Velocità: i nuovi domini di dati conversazionali diventano attivi in pochi giorni, anziché in interi cicli di sviluppo, accelerando notevolmente il nostro time-to-market.
• Accuratezza: Gli agenti specializzati per dominio e curati da SME forniscono risposte di cui gli utenti aziendali possono davvero fidarsi.
• Governance: Unity Catalog mette in sicurezza ogni domanda, sia sui dati nativi che su quelli federati, senza alcuno stack di sicurezza parallelo da gestire.
• Apertura: Un unico bridge conforme allo standard MCP serve ogni agente attuale e futuro, interno o esterno.

Il cambiamento più profondo, tuttavia, è di tipo organizzativo: le persone che comprendono i dati sono ora quelle che ne pubblicano l'accesso. Questo, più di qualsiasi singola tecnologia, è ciò che ha trasformato i nostri dati strutturati da qualcosa che gli utenti interrogano a qualcosa con cui possono semplicemente dialogare.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale