Come ERGO Hestia ha ridotto il time-to-market con Lakebase e Mosaic AI Model Serving

Creare la prossima generazione di pricing in tempo reale

ERGO Hestia, una delle principali compagnie assicurative polacche, gestisce una piattaforma di pricing su larga scala che supporta oltre 100 modelli e 1.000 variabili. Come uno dei maggiori utenti polacchi di Databricks, ERGO Hestia ha sviluppato solide competenze nel pricing millisecondo all'avanguardia e in una velocità di esecuzione leader del settore.

Tuttavia, poiché il team persegue costantemente la prossima grande innovazione nella tecnologia assicurativa, ha individuato un'opportunità per massimizzare ulteriormente i ricavi introducendo funzionalità B2C in tempo reale. Sebbene l'architettura esistente fosse altamente funzionale, il passaggio a continui aggiornamenti dei modelli e a una reattività istantanea verso i clienti ha rivelato una nuova sfida: mantenere la velocità di innovazione all'aumentare della complessità. Il team aveva ormai padroneggiato l'arte del pricing competitivo ed era pronto a fare da apripista per la prossima generazione di erogazione del pricing in tempo reale.

Sulla base di una stretta e proficua collaborazione, ERGO Hestia e Databricks hanno discusso congiuntamente come migliorare la precedente architettura per la prossima generazione di pricing in tempo reale. Questa straordinaria collaborazione ha portato all'evoluzione della piattaforma utilizzando Lakebase per fornire un Online Feature Store insieme a Mosaic AI Model Serving Endpoints per mantenere tutti i dati e la logica all'interno dell'ecosistema Databricks. Questa architettura mantiene sia i dati che il model serving all'interno del lakehouse, eliminando i sistemi esterni e riducendo i tempi di deployment dei modelli. Unificando la governance tramite Unity Catalog, il team integra la gestione dei dati e dei modelli per garantire la piena tracciabilità e la conservazione a lungo termine dei dataset di addestramento storici e delle versioni dei modelli. Questa architettura fornisce agli esperti di pricing un audit trail affidabile per garantire che ogni decisione rimanga completamente tracciabile e verificabile, mantenendo al contempo le massime prestazioni dei modelli. In definitiva, questa trasformazione consente al team di accelerare la velocità di innovazione e rispondere rapidamente alle condizioni di mercato, continuando a far progredire i propri modelli di pricing all'avanguardia.

La sfida: scalare la velocità senza aumentare gli attriti

La precedente architettura seguiva un modello logico in cui Databricks inseriva e trasformava i dati di pricing attraverso la sua architettura medallion, per poi esportare i dataset elaborati in un database esterno Azure PostgreSQL. Un livello di adapter intermedio gestiva il caching ed esponeva i dati al motore di pricing. Questo sistema funzionava bene con un throughput moderato. Tuttavia, con la crescita del volume dei dati e l'accelerazione dell'iterazione dei modelli, il modello multi-hop (che spostava i dati fuori dal lakehouse, attraverso un database esterno, un livello di caching e infine all'applicazione) ha iniziato a limitare le prestazioni e l'agilità.

1. Complessità operativa: la manutenzione di un database esterno e di un livello di adapter personalizzato creava un notevole sovraccarico operativo, poiché l'enorme carico di manutenzione dei job di estrazione è emerso come la sfida principale per questi casi d'uso critici. Inoltre, la gestione di una governance dei dati frammentata tra i vari sistemi, tra cui Databricks per l'elaborazione dei dati e PostgreSQL per il serving in produzione, nonché il codice applicativo personalizzato per gestire la logica di richiesta e l'integrazione, rendeva difficile il tracciamento della lineage, compromettendo la conformità e la verificabilità.
2. Velocità di deployment dei modelli: la precedente architettura multi-hop richiedeva una attenta sincronizzazione tra la logica del modello e l'infrastruttura di serving sottostante, creando una dipendenza tecnica da finestre di deployment coordinate. Sebbene il team possedesse già le competenze di pricing per iterare rapidamente, la complessità del database esterno e del livello di adapter faceva sì che gli aggiornamenti venissero spesso pianificati nelle ore non di punta per garantire la stabilità del sistema. Questa orchestrazione specializzata limitava la frequenza degli aggiornamenti durante la giornata lavorativa per evitare rischi di prestazioni nel livello di adapter esterno.
3. Collo di bottiglia nella freschezza dei dati: le ingestioni di grandi volumi di dati creavano vincoli prestazionali che richiedevano un'attenta orchestrazione per evitare di impattare sulle ore di operatività. In particolare, questi aggiornamenti generavano spesso picchi di latenza da 10 a 20 volte superiori nel livello di serving esterno, limitando di fatto l'aggiornamento dei dati a finestre batch pianificate. Per supportare il passaggio strategico al pricing B2C in tempo reale, il team aveva bisogno di un'architettura in grado di offrire una disponibilità continua dei dati durante tutto il giorno, senza questi compromessi operativi.

Per un'organizzazione che gestisce oltre 100 modelli su più di 1.000 variabili in un settore regolamentato, questa frammentazione creava sia attriti operativi che rischi di governance.

La soluzione: consolidamento all'interno del lakehouse

La trasformazione di ERGO Hestia si è basata su tre pilastri tecnici fondamentali che hanno unificato tutte le operazioni all'interno del lakehouse.

Lakebase per il data serving unificato. Databricks Lakebase fornisce un livello transazionale relazionale direttamente sopra le tabelle Delta. Utilizzando le Sync Tables, il team ha abilitato una sincronizzazione continua e automatica tra i dati elaborati e il livello di serving. Ciò ha eliminato la necessità di orchestrazione manuale e di job di estrazione esterni. Il risultato è una singola fonte di verità per i dati di pricing, residente all'interno del lakehouse.

Model Serving Endpoints per l'accesso diretto alle API. Invece di passare attraverso un'applicazione intermedia con un livello di caching separato e un database esterno, i Model Serving Endpoints espongono i dati direttamente all'applicazione del motore di pricing. Questo elimina completamente il livello di adapter e garantisce che la logica di richiesta sia mantenuta nativamente all'interno di Databricks. Le richieste fluiscono dal motore di pricing ai Model Serving Endpoints e viceversa in millisecondi, semplificando l'architettura grazie al consolidamento dell'esecuzione delle query e del data serving in un unico livello gestito.

Model Serving per l'integrazione dell'ecosistema ad alta velocità. I modelli vengono prima registrati in MLflow e poi le versioni migliori vengono registrate in Unity Catalog prima di essere esposte tramite Model Serving Endpoints dedicati. Questa architettura estende le capacità di deployment esistenti fornendo un unico piano governato in cui gli esperti di pricing possono convalidare i modelli rispetto ai dati reali nell'ecosistema Databricks in tempo reale. Possono eseguire più versioni di modelli contemporaneamente per confrontare le prestazioni tramite test A/B e di regressione, mentre l'intero ciclo di vita del modello rimane connesso nativamente alle sorgenti dati sottostanti. Questo approccio garantisce una visibilità completa grazie al tracciamento integrato della lineage e ai controlli di governance che coprono sia i dati che i livelli di model serving in Unity Catalog.

Le pipeline ETL esistenti in Databricks non hanno richiesto modifiche e i dati si sono semplicemente sincronizzati con Lakebase invece di essere estratti in PostgreSQL. Il Model Serving ha potuto utilizzare i modelli GLM e ML esistenti registrati in MLflow, pubblicati su Unity Catalog ed esposti tramite Model Serving Endpoints. Una pipeline CI/CD è stata utilizzata in Azure DevOps per orchestrare i deployment.

Successo attraverso la migrazione incrementale: ridurre i rischi della trasformazione

Invece di un passaggio coordinato e immediato, ERGO Hestia ha adottato un approccio a fasi che ha dato priorità alla sicurezza e alla continuità aziendale. Il team ha iniziato con gli endpoint a minore criticità, convalidando prestazioni e stabilità prima di estendere la soluzione ai sistemi mission-critical. Le operazioni di pricing non hanno subito interruzioni durante l'intero processo.

Fase 1: Proof-of-Concept (Settimane 1–3)

Il team ha convalidato l'architettura con un endpoint di dati piccolo e ben definito che serviva un segmento di portafoglio limitato. Ha sincronizzato la Delta Table esistente con Lakebase e l'ha esposta tramite un endpoint di Model Serving. Un vantaggio fondamentale di Lakebase è l'esclusiva separazione tra calcolo e archiviazione, che ha consentito al sistema di scalare senza sforzo per soddisfare i volumi di picco delle richieste senza alcuna regolazione manuale dell'infrastruttura di calcolo. Databricks ha fornito un'osservabilità integrata per latenza, utilizzo della CPU, throughput e consumo di memoria. I test prestazionali hanno dimostrato che l'architettura ha ampiamente superato le aspettative, con una latenza di 20 ms e un utilizzo della CPU inferiore al 5%, anche sotto un carico elevato di 40 richieste al secondo. Questo primo successo ha eliminato i rischi architetturali prima che il progetto venisse esteso alla produzione.

Fase 2: Deployment in produzione (Settimane 3–6)

Una volta convalidato il PoC, il team ha avviato la migrazione in produzione a partire dagli endpoint a bassa criticità. Man mano che gli endpoint venivano migrati, ognuno offriva risultati coerenti: perfetta coerenza dei dati tra Delta Lake e Lakebase, prestazioni stabili e prevedibili e un numero inferiore di componenti personalizzati richiesti rispetto all'architettura precedente. Con ogni migrazione andata a buon fine, la fiducia degli stakeholder è cresciuta, consentendo al team di accelerare l'espansione verso gli endpoint a maggior rischio.

Fase 3: Suddivisione del traffico e convalida nel mondo reale.

Invece di accettare un'unica data di transizione, ERGO Hestia ha implementato una suddivisione del traffico su scala di produzione: metà della base clienti è stata indirizzata verso i sistemi legacy, l'altra metà verso il nuovo sistema. Questo approccio ha consentito l'osservazione reale del comportamento effettivo degli utenti e dei pattern di carico. I nuovi modelli di pricing hanno offerto una generazione coerente dei preventivi e hanno soddisfatto tutte le aspettative di latenza. Aspetto fondamentale, il team ha potuto verificare che il nuovo sistema gestisse il carico di produzione esattamente come previsto.

Perché questo approccio ha avuto successo: la strategia incrementale ha eliminato i rischi in ogni fase. La convalida a bassa criticità ha prevenuto guasti catastrofici a livello di sistema. I traguardi raggiunti con successo hanno rafforzato la fiducia dell'organizzazione e consentito un'espansione più rapida. La convalida in produzione reale su scala ha confermato che l'architettura funzionava come previsto. In tutte le fasi, le operazioni di pricing sono continuate senza interruzioni e con zero impatto sui clienti.

Risultati di business: accelerare la velocità dell'innovazione

Time-to-market dei modelli accelerato: gli esperti di pricing ora distribuiscono i modelli direttamente all'interno dell'ecosistema Databricks, dove vengono sincronizzati automaticamente con i dati di produzione più recenti. Distribuendo i modelli tramite Mosaic AI insieme al Lakebase Online Feature Store, il team elimina la latenza tipica della sincronizzazione degli output dei modelli esterni con i flussi di dati in tempo reale. Questa integrazione garantisce che l'agilità esistente di ERGO Hestia sia ora supportata da una connessione diretta ad alta velocità tra i dati di mercato in tempo reale e il motore di pricing. La capacità di eseguire questi modelli sincronizzati consente una risposta rapida alle condizioni di mercato e alla pressione competitiva sui prezzi, il che in ultima analisi genera maggiori ricavi per l'organizzazione.

Semplificazione operativa: la complessità operativa è stata sostituita dalla semplicità architetturale. Rimuovendo il database PostgreSQL esterno e lo strato di adattamento, ERGO Hestia ha unificato il proprio stack sotto un unico modello di governance con Unity Catalog. Questa mossa ha eliminato il sovraccarico manuale di patching e pianificazione della capacità, centralizzando al contempo la logica delle richieste di pricing all'interno dell'ecosistema Databricks. Con la logica e i dati che ora risiedono insieme in un ambiente ad alte prestazioni, la capacità ingegneristica si sposta dalla manutenzione del middleware personalizzato alla promozione dell'innovazione dei modelli.

Governance e conformità unificate: in un settore regolamentato, la capacità di dimostrare esattamente cosa ha influenzato una decisione di pricing è fondamentale. Unificando tutti i dati e i modelli di pricing sotto Unity Catalog, ERGO Hestia ottiene audit trail automatici, tracciamento delle versioni e controlli di accesso. La coerenza dei dati viene ora verificata automaticamente lungo l'intera pipeline per garantire che la logica utilizzata nei test corrisponda perfettamente alla logica in produzione. Grazie alla lineage integrata nella piattaforma, la risposta a quale modello ha servito quali clienti durante un periodo specifico è immediata e completamente verificabile. Ciò elimina il lavoro di conformità manuale. I team di conformità possono ora dimostrare esattamente quali dati hanno influenzato ogni decisione di pricing, chi vi ha avuto accesso e quando sono avvenute le modifiche. Tutto viene acquisito automaticamente per eliminare la necessità di ricostruzioni manuali, fornendo al contempo una base di fiducia che consente all'organizzazione di scalare le proprie strategie di massimizzazione dei ricavi in totale sicurezza.

La strada da percorrere: scalare l'innovazione in tutta l'azienda

Il successo del dipartimento Pricing sta definendo un modello per la scalabilità in tutti i domini di pricing. ERGO Hestia sta ora estendendo l'architettura Lakebase e Model Serving a tutta la sua più ampia organizzazione di pricing. Ciascun dominio consoliderà i propri motori decisionali all'interno della piattaforma lakehouse, offrendo modelli e dati come servizi di prim'ordine con una governance unificata.

La convalida iniziale con un endpoint piccolo e a bassa criticità ha dimostrato l'efficacia dell'approccio. Ora l'ufficio Pricing sta passando a carichi di lavoro più grandi e critici e a database di dimensioni maggiori, utilizzando lo stesso playbook incrementale. Dataset con una posta in gioco più alta e modelli complessi richiedono una convalida più rigorosa, ma il pattern di migrazione incrementale rimane invariato.

L'obiettivo è chiaro: dismettere il database esterno Azure PostgreSQL una volta che tutti i domini di pricing saranno migrati con successo a Lakebase. La migrazione di ciascun dominio rafforza la fiducia per il successivo, accelerando la timeline complessiva verso un'infrastruttura di pricing unificata e nativa di Databricks.

Oltre alle operazioni di pricing, il consolidamento di tutti i dati di pricing all'interno del lakehouse sblocca nuove opportunità. Con l'intelligence sul pricing unificata in Databricks, i team possono sfruttare AI/BI Genie per esplorare i pattern di pricing, scoprire insight e rispondere a domande di business ad hoc senza richiedere il supporto del team di ingegneria. Gli stessi dati che alimentano il motore di pricing ora supportano la business intelligence e la discovery basata sull'intelligenza artificiale, moltiplicando il valore dell'investimento nel lakehouse.

Questo pattern collaudato fornisce ora un modello per altre funzioni aziendali per eliminare le dipendenze esterne e accelerare la propria velocità decisionale.

Conclusione

La trasformazione di ERGO Hestia illustra un principio applicabile a tutti i settori: il consolidamento all'interno di una piattaforma unificata accelera la velocità dell'innovazione semplificando al contempo le operazioni. Passando a un'architettura nativa del lakehouse in cui dati e modelli vengono distribuiti direttamente tramite Databricks Lakebase e Model Serving, il dipartimento Pricing è diventato più rapido, affidabile e capace di un'innovazione sostenuta.

In un mercato definito dai millisecondi, l'elemento di differenziazione non è più solo il modello in sé, ma l'architettura che gli consente di reagire alla realtà in tempo reale. I test A/B nativi, i guardrail automatizzati e gli audit trail continui in Unity Catalog garantiscono che ogni decisione rimanga tracciabile ed entro i limiti di rischio stabiliti.

Questa architettura funge da riferimento pratico per la più ampia organizzazione ERGO e per qualsiasi azienda che cerchi di implementare motori di pricing al millisecondo per massimizzare l'impatto sul mercato e la crescita dei ricavi. Per il settore, la questione non riguarda più la possibilità tecnica del pricing in tempo reale, ma la rapidità con cui è possibile adottare l'architettura che lo rende realtà.

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