Perché i dati di R&D devono stare nel Lakehouse - e perché gli agenti ne hanno bisogno lì

La configurazione

In cellcentric, una joint venture di Daimler Truck e Volvo Group, sviluppiamo e realizziamo sistemi di celle a combustibile a idrogeno per applicazioni pesanti. Il nostro lavoro è fortemente incentrato su R&D, ingegneria e dati. Le domande che si pongono i nostri team raramente trovano risposta in un unico sistema di origine. Spaziano dalla gerarchia dei prodotti alla cronologia di produzione, dalle rilavorazioni alle prove di laboratorio, fino alla telemetria dei test e alla conoscenza del dominio.

Questa è la sfida centrale per l'AI industriale in ambito R&D. Un agente è utile solo se è in grado di ragionare sullo stesso contesto governato di cui un ingegnere ha bisogno per potersi fidare di una risposta: da dove provengono i dati, cosa significano, quanto sono completi, quali avvertenze contano e se l'utente è autorizzato a visualizzarli. Trasformare tutto questo in un contesto pronto per l'AI inizia con la data engineering, ancora prima della selezione del modello.

Ecco perché abbiamo trascorso gli ultimi quattro anni a costruire la nostra infrastruttura dati su Azure e Databricks. Unity Catalog ha fatto parte dell'architettura fin dall'inizio. Lakehouse Federation ha integrato le sorgenti SQL on-premises nel modello lakehouse. Delta Sharing ci ha aiutato a scambiare dati oltre i confini aziendali. Databricks Asset Bundles ci ha fornito un percorso di produzione per pipeline e data product. Il risultato è il Data Hub: il nostro livello di contesto governato per dati e AI, dotato di un'interfaccia utente per i dipendenti e di un server MCP per gli agenti.

Il Data Hub è nato come piattaforma per data product. Col senno di poi, questa base è esattamente il motivo per cui funziona così bene come piattaforma AI.

Il Fuel Cell Passport

Questa base è più facile da spiegare attraverso un singolo data product: il Fuel Cell Passport. Unisce cinque sistemi sorgente aziendali, tra cui SAP S/4HANA, due sistemi MES per la produzione e la rilavorazione, un database di laboratorio e una piattaforma di telemetria IoT. Modella sette livelli gerarchici, dal sistema fino al lotto di materia prima, si aggiorna quotidianamente e utilizza un modello temporale basato sullo stato in modo che i team possano rispondere sia a domande sulla configurazione in un determinato momento sia a domande sull'intera cronologia delle rilavorazioni. I controlli quotidiani sulla qualità dei dati monitorano se il prodotto è sufficientemente completo per supportare le indagini di ingegneria, qualità e produzione. Il nome riflette i concetti di tracciabilità e ciclo di vita di un passaporto di prodotto, ma il Fuel Cell Passport è un data product ingegneristico interno, non un elemento di conformità normativa come l'EU Digital Product Passport (DPP), sebbene la stessa base di tracciabilità potrebbe supportarne uno.

Sembra una classica storia di successo del lakehouse: integrare le sorgenti, modellare il dominio, governare l'accesso, rendere i dati riutilizzabili. Per l'AI, il punto strutturale è il contesto associato: un prodotto governato attorno ai dati modellati.

Il contesto come metrica di qualità

Unity Catalog ci fornisce la struttura governata: tabelle, colonne, proprietà, lineage, classificazioni e autorizzazioni. Il Data Hub aggiunge il livello di prodotto attorno ad essa. Un data product combina proprietà, stato del ciclo di vita, assegnazione del dominio, asset governati collegati e voci di contesto che spiegano a cosa serve il prodotto e come dovrebbe essere utilizzato.

Questa distinzione è fondamentale per l'AI. Gli agenti hanno bisogno di qualcosa di più dei semplici metadati dello schema e di un semplice documento. Devono capire quali domande di business sono supportate da un data product, come si relazionano le tabelle importanti, quali avvertenze contano e quali asset circostanti dovrebbero essere utilizzati con esso. Conserviamo questo contesto più ricco nel livello del data product, incluse ampie voci di catalogo in formato markdown scritte durante il processo di sviluppo, quando il contesto del progetto è ancora fresco.

Questo ha cambiato il nostro modo di pensare alla qualità dei dati. La completezza e la freschezza sono ancora importanti, ma non sono più sufficienti. Per i dati pronti per l'AI, la copertura del contesto è diventata una metrica di qualità di prim'ordine.

Nel nostro marketplace, ogni data product ha un badge di copertura del contesto. Mostra se sono presenti le descrizioni delle tabelle e quanta documentazione a livello di colonna esiste nelle tabelle associate al prodotto. Il badge ha reso la metrica visibile e azionabile. La copertura è aumentata perché gli ingegneri potevano vedere direttamente la lacuna nell'interfaccia del prodotto in cui i dati sarebbero stati consumati.

La metrica non pretende di aver risolto ogni ambiguità semantica. È un indicatore pratico che rende visibile il contesto mancante in tempo utile per correggerlo. Storicamente, la copertura del contesto è migliorata perché il badge ha trasformato la documentazione da un compito di pulizia a posteriori a qualcosa che gli ingegneri potevano vedere, misurare e migliorare come parte del rilascio.

Oggi abbiamo 27 data product pubblicati, tutti con una ricca documentazione in formato markdown. I prodotti pubblicati hanno una copertura media dei commenti di colonna del 90%, con la maggior parte dei commenti generati con il supporto dell'AI durante il lavoro di data engineering e revisionati dall'ingegnere prima del merge. La voce del catalogo aggiunge un altro livello di contesto: un riepilogo dettagliato in markdown del flusso di lavoro di sviluppo, delle decisioni di dominio, delle relazioni tra le tabelle, delle avvertenze e delle modalità previste per l'utilizzo del prodotto.

Il cambiamento importante è che la documentazione diventa parte del flusso di lavoro di ingegneria, per poi essere disponibile come contesto di prodotto strutturato per la persona o l'agente successivo che dovrà analizzare i dati.

Un'UI per gli umani, un MCP per gli agenti

Il Data Hub è il livello che rende fruibile questo substrato. Per gli utenti umani, è un marketplace e un workbench. I dipendenti possono scoprire i data product, visualizzare i proprietari e lo stato del ciclo di vita, aprire dashboard e app collegate, interrogare i dati governati da Unity Catalog e utilizzare un'interfaccia di chat per l'esplorazione in linguaggio naturale. Per i client AI, lo stesso contesto è esposto tramite MCP. Qualsiasi assistente o agente di codifica compatibile con MCP può accedere agli stessi metadati di Unity Catalog e al contesto dei data product utilizzati dal Data Hub.

Il modello di governance

L'architettura è deliberatamente costruita attorno a un unico modello operativo. L'identità fluisce attraverso il sistema. L'accesso ai dati rimane governato. Le chiamate a modelli e strumenti sono osservabili. Tracce e valutazioni alimentano il miglioramento continuo.

Questo funziona solo perché la governance è stata integrata nella piattaforma fin dall'inizio. La proprietà della produzione, il deployment e il consumo sono aspetti distinti. Gli ingegneri modificano le pipeline e le definizioni dei prodotti tramite codice revisionato e percorsi di deployment governati. I consumatori, inclusi gli agenti, non ricevono identità di scrittura in produzione. Accedono ai dati tramite il Data Hub, le dashboard, Genie, gli strumenti SQL o MCP utilizzando l'identità dell'utente autenticato, con Unity Catalog che prende la decisione finale sull'autorizzazione.

Questa distinzione è ciò che rende governabile l'accesso degli agenti. Un agente può ragionare sullo stesso contesto di prodotto visto da un utente e può chiamare strumenti per conto dell'utente, ma non può diventare un writer di produzione né aggirare Unity Catalog con una credenziale di backend condivisa. Se l'utente non ha accesso a una tabella, a una colonna mascherata o a una vista governata, l'agente incontra lo stesso limite. Questo modello operativo ci consente di permettere agli agenti di accedere ai dati senza creare un secondo percorso meno sicuro all'interno della piattaforma.

L'identità parte da Azure AD e fluisce attraverso il Data Hub in Databricks utilizzando lo scambio di token OAuth 2.0, il pattern di passaggio dei token "on-behalf-of" (per conto di) che Databricks descrive nella sua architettura di governance degli agenti. Un utente che interroga una tabella tramite l'UI, un agente che chiama uno strumento SQL e un'area di lavoro Genie richiamata come chiamata a uno strumento governato operano tutti all'interno dello stesso limite di autorizzazione. Se l'utente non può accedere ai dati sottostanti, non può farlo nemmeno l'agente che agisce per suo conto. Questo è il modello di accesso che consente al Data Hub di essere utile senza trasformarsi in un sistema di governance parallelo.

Sul fronte dell'AI, eseguiamo agenti personalizzati su Databricks Model Serving, utilizziamo Claude tramite le API di Foundation Model e richiamiamo le aree di lavoro Genie come strumenti governati dove opportuno. L'architettura MCP è ibrida per progettazione: l'MCP gestito da Databricks offre un accesso governato alle funzionalità di Databricks come le chiamate agli strumenti Genie, mentre il nostro MCP fornisce il livello di contesto più ricco (metadati di Unity Catalog, oggetti di data product e markdown del catalogo), oltre agli strumenti specifici per il business che gli agenti richiamano in aggiunta. Gli agenti hanno bisogno di entrambi.

Osservabilità e valutazione

L'osservabilità è il punto in cui l'architettura diventa operativa. Unity AI Gateway ora instrada il traffico dei modelli di base nel nostro ambiente. Con una piccola modifica al client del modello, le chiamate al modello di Data Hub passano attraverso un unico livello di governance e osservabilità con tracciamento dell'utilizzo e tabelle di inferenza abilitate. Poiché le richieste e le risposte arrivano nelle tabelle Delta di Unity Catalog, possono essere analizzate con gli stessi pattern SQL che già utilizziamo per i dati aziendali.

Il tracciamento di MLflow ci offre il livello successivo di visibilità. Standardizziamo le tracce tra i nostri adattatori di agenti in modo che ogni interazione possa essere ispezionata come un percorso di esecuzione strutturato: chiamate al modello, chiamate agli strumenti, passaggi intermedi e risposte finali. Oltre a queste tracce, eseguiamo un framework di valutazione continua con valutatori di correttezza deterministica e SQL-grounding, valutatori di costo sensibili alla cache e valutatori basati su LLM-judge allineati con esperti di dominio. Lo scopo è più ampio del semplice test delle modifiche agli agenti. Lo stesso livello di contesto richiede una valutazione: il markdown può allontanarsi dalle pipeline e dalle definizioni delle tabelle, i prompt di sistema si evolvono, i contratti degli strumenti cambiano e le ipotesi di dominio invecchiano. Le tracce e le valutazioni (eval) ci consentono di testare insieme l'agente, gli strumenti e il contesto su cui si basa, prima che influenzino il comportamento in produzione.

Per la prima volta, l'azienda dispone di un unico punto di accesso governato che consente ai dipendenti di scoprire quali prodotti di dati esistono e di interagire con essi in linguaggio naturale, nel rispetto degli stessi controlli di accesso dei dati sottostanti.

Lo stesso pattern, all'interno del ciclo di sviluppo

Lo stesso pattern ha cambiato anche il nostro modo di creare.

Il nostro flusso di lavoro di ingegneria ora include agenti all'interno del ciclo di sviluppo. Lo strumento di codifica esatto è meno importante del pattern: un ingegnere lavora in un ambiente di sviluppo assistito dall'AI, connesso alle funzionalità di Databricks e al nostro MCP del livello di contesto. Quando l'ingegnere lavora su un prodotto di dati, l'agente può ispezionare i metadati pertinenti di Unity Catalog, leggere la documentazione esistente del prodotto, comprendere il contesto del progetto circostante e aiutare a strutturare pipeline, test, descrizioni delle tabelle e voci di catalogo in markdown. L'ingegnere rimane responsabile della revisione e dell'unione (merge), ma l'agente è presente nel momento in cui il contesto è più ricco.

Questa tempistica è fondamentale. La documentazione scritta a posteriori è spesso incompleta perché il contesto del progetto è già andato oltre. La documentazione scritta durante lo sviluppo cattura i ragionamenti, le definizioni e le avvertenze che renderanno utili i dati in seguito e, una volta revisionata e sottoposta a commit, diventa il contesto per il flusso di lavoro successivo.

Per molti dei nostri flussi di lavoro di R&D e di sviluppo dei processi, ciò che prima richiedeva settimane di integrazione dei dati tra sistemi diversi, definizione dei KPI e strutturazione delle pipeline, ora viene rilasciato in pochi giorni. Il miglioramento si traduce non tanto in un singolo numero di automazione, quanto in una riduzione del tempo che intercorre tra la richiesta di indagine e il prodotto di dati utilizzabile: meno passaggi manuali tra esperti di dominio e ingegneri dei dati, minore ripetizione dell'integrazione dei sistemi di origine, accordi più rapidi sulle definizioni dei KPI e una revisione anticipata delle avvertenze mentre il contesto è ancora fresco. Alcune categorie, in particolare le complesse indagini multi-sorgente che richiedono un'attenta revisione del dominio, richiedono ancora un lavoro notevole, ma in tempi notevolmente più rapidi. Il vantaggio duraturo è cumulativo: ogni prodotto aggiunge alla piattaforma un contesto aziendale revisionato, in modo che l'indagine successiva parta con una parte maggiore del dominio già spiegata.

Databricks sta ora trasformando in prodotto parti di questo pattern. La CLI di codifica di Unity AI Gateway, ucode, instrada gli strumenti di codifica attraverso AI Gateway e collega i server MCP al flusso di lavoro dello sviluppatore. Genie Code porta la codifica agentica e il lavoro sui dati direttamente all'interno delle interfacce di Databricks.

Quali saranno i prossimi sviluppi

Per noi, la prossima fase consiste nel rendere gli agenti consapevoli del contesto operativo che circonda i dati, oltre che delle tabelle stesse. In un'indagine sulla qualità o sulla produzione, un agente dovrebbe essere in grado di recuperare un trend, ispezionare i controlli di qualità dei dati associati al prodotto e importare i log degli allarmi dei macchinari correlati nello stesso intervallo di tempo. La risposta può quindi contenere l'avvertenza che un ingegnere si aspetterebbe: il trend punta in questa direzione, ma questa sezione richiede cautela perché la completezza è stata segnalata e il contesto operativo era anomalo.

La stessa idea si applica al lavoro ricorrente. Oggi, la conoscenza dei processi è frammentata tra runbook, pagine wiki, prompt locali, script, convenzioni del team e abitudini non documentate. Un Skills Marketplace offre a questa conoscenza lo stesso trattamento in piattaforma riservato ai prodotti di dati: proprietà, revisione, controllo delle versioni, stato del ciclo di vita e un luogo centrale in cui gli agenti possono trovare il modo approvato di lavorare. In questo contesto, una skill racchiude le istruzioni, gli strumenti approvati, i modelli, i guardrail e i controlli di valutazione che indicano a un agente come eseguire un'attività ricorrente nel nostro ambiente. Concretamente, risiederebbe nel marketplace insieme ai prodotti di dati che interessa, verrebbe sottoposta a controllo delle versioni e revisionata come il codice, e verrebbe richiamata per nome in modo che l'agente segua ogni volta lo stesso percorso approvato. Una skill potrebbe strutturare un Databricks Asset Bundle specifico per il dominio in un repository remoto, o guidare un ingegnere nella registrazione di un dispositivo IoT e nella trasformazione di log di macchinari disordinati in una pipeline bronze.

Questa è la direzione più ampia per il Data Hub: trarre la stessa lezione dalle fondamenta del lakehouse, governare prima il contesto e applicarlo sia ai dati interrogati dagli agenti sia al lavoro che contribuiscono a svolgere.

Le conclusioni

Ecco perché i dati di R&D appartengono al lakehouse. L'AI industriale ha bisogno di un contesto governato: i dati, il significato, le autorizzazioni, le tracce e il ciclo di feedback in un'unica architettura.

Per cellcentric, rendere pratica l'AI industriale significa fornire agli agenti questo contesto basandosi su fondamenta lakehouse collaudate. Unity Catalog, prodotti di dati, identità, osservabilità e flussi di lavoro degli agenti collaborano per consentire a persone e agenti di analizzare i dati di R&D in modo sicuro. Per noi questo è molto più di una best practice. È il modo in cui stiamo plasmando la prossima generazione di ingegneria guidata dai dati.

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