In che modo FactSet ha ridotto l'addestramento e il deployment dei modelli da giorni a ore con Databricks AI Runtime

Il sistema Text-to-Formula (TTF) di FactSet ha un compito ingannevolmente difficile: prendere una richiesta in linguaggio naturale da un professionista degli investimenti e trasformarla nella formula corretta di FactSet Query Language (FQL).

Inizialmente FactSet ha sviluppato TTF basandosi sulla retrieval-augmented generation (RAG), utilizzando il recupero di informazioni per trovare esempi e dati pertinenti per una determinata richiesta. Ma con l'aumento dell'utilizzo, le query sono diventate più specializzate e le formule più complesse, e l'approccio ha raggiunto un limite di qualità. FactSet ha iniziato a integrare modelli open sottoposti a fine-tuning nella sua architettura di Compound AI, consentendo al team di addestrare i modelli sulla struttura e sui pattern di FQL anziché fare affidamento principalmente sulla retrieval durante l'inferenza. Nei suoi primi lavori su TTF, FactSet ha riscontrato che l'integrazione di modelli con fine-tuning riduceva la latenza end-to-end di circa il 60%.

Con l'evoluzione del sistema, anche il ruolo del fine-tuning è cambiato. FactSet ha accumulato più dati di addestramento e ha iniziato ad aggiornare i suoi modelli regolarmente, trasformando quello che era un flusso di lavoro sperimentale in una parte ricorrente dello sviluppo di TTF. Oggi, il team esegue il fine-tuning dei modelli all'incirca ogni due o tre settimane.

Quando il fine-tuning diventa parte del ciclo di rilascio

L'addestramento ogni poche settimane modifica i requisiti dell'infrastruttura. Preparare un ambiente e configurare il calcolo GPU può essere gestibile per un esperimento occasionale. Ripetere quel lavoro ogni volta che nuovi dati o un nuovo modello sono pronti per essere testati aggiunge overhead direttamente al ciclo di sviluppo.

Anche i requisiti dei modelli possono cambiare da un esperimento all'altro. FactSet ha lavorato con modelli basati su Llama e continua a valutare modelli open più recenti. Modelli, lunghezze dei prompt e caratteristiche degli output differenti possono richiedere configurazioni di calcolo diverse; pertanto, vincolare l'ambiente di addestramento a una configurazione GPU fissa renderebbe più difficile l'adattamento man mano che il team sperimenta.

FactSet utilizza Databricks AI Runtime per eseguire questi carichi di lavoro di fine-tuning su un'infrastruttura GPU serverless. Gli ingegneri possono scegliere le risorse di calcolo in base ai requisiti di un particolare ciclo di addestramento, senza dover prima effettuare il provisioning e la configurazione dell'ambiente GPU sottostante.

Mantenere l'addestramento all'interno del ciclo di sviluppo

Il flusso di lavoro di addestramento di TTF affianca inoltre dati, sperimentazione, gestione dei modelli e governance già in esecuzione su Databricks. FactSet utilizza MLflow per tracciare lo sviluppo e gli esperimenti dei modelli, mentre i dati sottostanti rimangono gestiti all'interno del proprio ambiente Lakehouse esistente.

L'esecuzione del fine-tuning con AI Runtime mantiene l'addestramento GPU all'interno di tale flusso di lavoro. Gli ingegneri possono lavorare con dati soggetti a governance, addestrare un nuovo modello, tracciare gli artefatti risultanti e procedere verso il deployment senza dover gestire uno stack GPU separato per il fine-tuning. Per FactSet, questo ha ridotto il tempo necessario per configurare, addestrare e distribuire un modello TTF personalizzato da giorni ad ore.

Databricks AI Runtime ha semplificato notevolmente il processo di addestramento di un modello Text To Formula (TTF) personalizzato. Senza la necessità di configurare l'infrastruttura o subire ritardi, è stato facile scegliere le giuste risorse di calcolo in base alla dimensione del prompt e alla generazione di token di output. Ciò ci ha permesso di muoverci rapidamente, mantenere i nostri flussi di lavoro Lakehouse e distribuire un modello di alta qualità con una governance completa, riducendo il tempo di configurazione, addestramento e deployment del modello da giorni a ore.—Nikhil Sunderraj, Principal Machine Learning Engineer, FactSet Research Systems, Inc.

Progettare per modelli in continua evoluzione

La capacità di cambiare modello ha fatto parte dell'evoluzione di TTF fin dall'inizio. La RAG avanzata, e in particolare il fare affidamento esclusivamente su modelli ospitati esternamente, diventa un collo di bottiglia per mantenere la precisione e la latenza con l'aumentare dei consumi e delle formule più complesse. La RAG ha funzionato finché il sistema non ha riscontrato formule più complesse. I modelli open sottoposti a fine-tuning hanno fornito a FactSet un altro modo per migliorare la qualità e la latenza. Ora, man mano che si rendono disponibili nuovi modelli, il team può valutarli rispetto al carico di lavoro anziché considerare definitiva la scelta del modello attuale.

Lo stesso TTF sta diventando più specializzato. Man mano che FactSet accumula più dati, il team sta esplorando ulteriori modelli con fine-tuning per attività quali la scomposizione delle query, l'estrazione dei componenti e l'identificazione delle librerie. Ciò crea maggiori opportunità di utilizzare il modello più adatto a ciascuna parte del flusso di lavoro, ma rende anche più importante un addestramento rapido e ripetibile.

Un cambio di modello è molto più facile da testare quando non richiede di ricostruire l'ambiente di addestramento attorno ad esso. Con il calcolo GPU disponibile su richiesta tramite AI Runtime, il lavoro di ingegneria si sposta verso gli aspetti che influenzano realmente TTF: quale modello utilizzare, come addestrarlo e se la versione risultante migliora l'applicazione.

Inoltre, la pipeline di fine-tuning è stata realizzata su Databricks Lakeflow Jobs e Pipelines come un framework plug-and-play e riutilizzabile, progettato per essere facilmente adottato per diverse attività TTF e da altri team con uno sforzo di configurazione minimo, fornendo una base standardizzata che riduce le difficoltà di onboarding e accelera l'integrazione.

Rendere pratica la scelta del modello

I modelli open si stanno evolvendo rapidamente. Il modello che oggi offre il giusto equilibrio tra qualità, latenza e costo potrebbe non essere quello desiderato da un team tra sei mesi. Preservare la possibilità di scegliere il modello richiede quindi molto di più della semplice capacità di scaricare un nuovo insieme di pesi. Il flusso di lavoro di addestramento e deployment circostante deve rimanere al passo.

L'esperienza di FactSet con TTF mostra come questo si traduca in produzione. Il team può continuare a testare nuovi modelli open man mano che i dati e l'applicazione si evolvono, mentre AI Runtime fornisce un'infrastruttura GPU serverless all'interno dei flussi di lavoro Databricks esistenti. Invece di dedicare giorni alla configurazione, all'addestramento e al deployment di ogni iterazione, FactSet può completare tale ciclo in poche ore.

Per un sistema che viene riaddestrato ogni poche settimane, questa differenza si amplifica. I nuovi dati possono confluire prima in un nuovo modello e gli ingegneri possono dedicare una quota maggiore di ciascuna iterazione al miglioramento di TTF, anziché alla preparazione dell'infrastruttura necessaria per addestrarlo.

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