Come Databricks distribuisce i modelli di frontiera a 12.000 dipendenti fin dal primo giorno

Fornire ai nostri dipendenti l'accesso alle funzionalità di AI di frontiera è una priorità assoluta per Databricks e, di conseguenza, per noi è importante che possano utilizzare i nuovi modelli non appena sono disponibili. Allo stesso tempo, non è banale offrire a oltre 12.000 persone un accesso rapido a un nuovo modello, perché:

1. I modelli commercializzati come "di frontiera" spesso non lo sono. Ad esempio, Opus 5.0 era più costoso e ha ottenuto punteggi di qualità inferiori, sia quantitativi che qualitativi, tra i nostri ingegneri rispetto a Opus 4.8. Migrare a un modello che rappresenta un passo indietro rispetto alla frontiera può danneggiare significativamente un'azienda, anziché aiutarla. In base alla nostra esperienza, è necessaria grande attenzione nella valutazione dei modelli prima di migrare i carichi di lavoro in massa verso i nuovi modelli.
2. Un uso ingenuo di un nuovo modello può far lievitare i costi. Quando abbiamo rilasciato GPT Astra a un gruppo di controllo senza alcuna misura di contenimento dei costi, lo sviluppatore medio ha speso il 60% in più rispetto a prima di avere accesso ad Astra. Un aumento improvviso dei costi del 60% con una popolazione di utenti superiore a 10.000 è molto difficile da gestire per la pianificazione aziendale. Una volta compreso meglio per quali attività Astra è straordinariamente efficace, siamo stati in grado di orientarne l'utilizzo per ridurre in modo sostanziale i costi complessivi.

Questo post illustra una serie di tecniche che abbiamo adottato per offrire alla maggior parte dei dipendenti di Databricks l'accesso "Day 1" ai nuovi modelli, consentendoci al contempo di valutare se questi modelli siano effettivamente validi cavalli di battaglia a lungo termine. Queste tecniche si affidano fortemente a Unity Gateway per rilasciare, valutare e integrare i nuovi modelli in modo adattivo. La settimana del 21 settembre è stata un banco di prova fondamentale per queste capacità, quando Opus 5, GPT-6 Sol e GPT-Luna sono stati rilasciati in rapida successione. Durante quella settimana, Databricks ha fornito a tutti i dipendenti l'accesso fin dal primo giorno e, entro il terzo giorno, avevamo raccolto dati sufficienti per confermare che questi modelli si trovavano sulla frontiera dell'efficienza, procedendo quindi a integrarli nella nostra infrastruttura più ampia.

Il ciclo di vita del rilascio dei modelli

 A grandi linee, i rilasci dei nuovi modelli in Databricks passano attraverso una pipeline strutturata come segue:

1. Rendere immediatamente disponibili i nuovi modelli a tutti i dipendenti, su base "sperimentale".
2. Limitare l'uso dei nuovi modelli in base a un budget per utente.
3. Dopo aver raccolto dati sufficienti, decidere se promuovere il modello in produzione (o persino impostarlo come predefinito).

Fase 1: Rendere immediatamente disponibili i nuovi modelli

Per semplificare la gestione dei modelli tra provider di modelli chiusi e aperti, sfruttiamo il nostro Databricks Unity Gateway per tutto l'uso interno. Questo è il nostro hub centrale per la governance dell'AI, la gestione dei costi e l'osservabilità, quindi è naturale partire da qui.

Il Gateway è il punto in cui consentiamo a tutti i dipendenti di accedere al modello appena rilasciato. La configurazione lato server, tuttavia, non è sufficiente. I nostri dipendenti utilizzano Claude Code, Codex e il meta-harness Omnigent sui loro laptop, e dobbiamo distribuire loro la nuova configurazione del modello.

È qui che entra in gioco Unity Gateway CLI (UG CLI). La UG CLI è già in esecuzione sul laptop di tutti, distribuita tramite il nostro Mobile Device Management. Ogni volta che qualcuno avvia Claude Code, Codex o Omnigent, la UG CLI viene eseguita per verificare la presenza di nuovi modelli, strumenti e competenze, e aggiorna la configurazione dell'harness locale. UG ci consente anche di designare centralmente i modelli predefiniti rispetto a quelli sperimentali, preparare i modelli per lo smart routing e raccogliere tracce per valutare il rollout di ciascun modello.

Abbiamo configurato Unity Gateway to inviare configurazioni sperimentali per Opus 5.5 e Sol 6. Questi modelli ora appaiono con questo tag, in modo che i dipendenti possano selezionarli sapendo però che si tratta di un nuovo modello che potrebbe non essere il migliore della categoria o non rimanere disponibile per sempre:

L'output del modello / Claude Code indica chiaramente Opus 5.5 come Sperimentale

Fase 2: Limitare l'utilizzo tramite un budget per utente

In precedenza abbiamo scritto di come configuriamo i budget per utente per la spesa legata all'AI. Da allora, abbiamo ampliato la nostra architettura di budget totale per includere quattro budget principali, ciascuno definito su base utente:

1. Massimo mensile: ogni utente ha un limite di spesa mensile complessivo per tutti i modelli.
2. Limite giornaliero per sessioni fuori controllo: ogni utente ha un limite massimo giornaliero, che può essere aumentato direttamente in Slack per evitare spese accidentali dovute a una sessione fuori controllo.
3. [Novità!] Budget per la frontiera della qualità: allochiamo una determinata quota del budget mensile ai modelli più avanzati sulla frontiera della qualità, come GPT Astra e Claude Fable. (Al momento Fable non è distribuito internamente a causa delle politiche di conservazione dei dati di Anthropic, ma stiamo lavorando a stretto contatto per implementare la loro nuova politica). Ciò riflette l'intenzione che questi modelli non debbano essere utilizzati come strumenti quotidiani, ma selezionati per attività specializzate per le quali sono particolarmente indicati, in modo da giustificare un costo da 2 a 3 volte superiore rispetto al livello di qualità successivo.
4. [Novità!] Budget sperimentale: un'altra quota del budget mensile è allocata per l'utilizzo di modelli nuovi e non testati. In questo caso, miriamo a bilanciare la velocità di adozione con il rischio di esporre su larga scala un modello che non si trova sulla frontiera dell'efficienza.

Il primo giorno del lancio del modello, abbiamo reso disponibili Opus 5.5 e Sol 6 a tutti i dipendenti tramite Unity Gateway e li abbiamo associati al budget sperimentale. Abbiamo poi utilizzato i giorni successivi per raccogliere dati e decidere come procedere: rimuovere il tag sperimentale o escludere il modello dal catalogo visibile ai nostri sviluppatori.

Panoramica della configurazione del budget, che mostra i quattro budget

Fase 3: Promuovere o scartare il modello

Per determinare se il modello si trova sulla frontiera dell'efficienza, ci basiamo su tre segnali:

1. Dati di benchmark: disponiamo di una serie di benchmark privati che testano un insieme di attività, inclusi benchmark offline come il ragionamento sui documenti, la ricerca nello spazio di lavoro e il nostro prodotto Genie, oltre a benchmark online in cui eseguiamo due modelli affiancati e confrontiamo i risultati per la creazione di pull request. Continuiamo a espandere e ottimizzare questi benchmark; in un mondo ideale, i nostri benchmark sono sufficienti per determinare rapidamente il costo e la qualità di qualsiasi nuovo rilascio di modello.
    
2. Qualità segnalata dagli utenti: il rilascio del modello sperimentale fornisce una grande quantità di dati aneddotici su come le persone valutano il nuovo modello. Riscontriamo che un gruppo di power user è impaziente di provare i nuovi modelli e confrontare le proprie esperienze su Slack e tramite le risposte ai sondaggi.
    
3. Monitoraggio dei costi tramite tracce OpenTelemetry: Unity Gateway registra tutte le tracce in una posizione centrale, insieme alle informazioni sui costi. Possiamo confrontare il modo in cui gli utenti pilota hanno speso per la generazione precedente di modelli rispetto ai modelli più recenti su base sessione.  Questo non ci dice necessariamente la qualità, ma ci fornisce una buona misura del costo.

Per Opus 5.5 e Sol 6, tutte e tre le metriche ci mostrano un quadro piuttosto coerente.

I benchmark, come il nostro OfficeQA Pro V2, mostrano che Opus 5.5 si colloca chiaramente sulla frontiera costo/qualità, un enorme passo avanti su entrambi gli assi rispetto a Opus 5. GPT-6 Sol si posiziona a metà strada tra GPT-5.6 Sol e GPT-5.6 Terra sia in termini di costi che di qualità.

I feedback degli utenti concordano ampiamente sul fatto che per le attività di engineering e debugging (la stragrande maggioranza dei nostri early adopter sono ingegneri), Opus 5.5 rappresenta un grande passo avanti in termini di qualità rispetto a Opus 5 e Opus 4.8, e il suo stile di scrittura è decisamente preferito. Al contrario, GPT-6 Sol rappresenta occasionalmente un passo indietro in termini di qualità rispetto a GPT-5.6 Sol.

Il monitoraggio dei costi ci ha permesso di confrontare l'utilizzo degli early adopter con quello dello stesso gruppo una settimana prima. Mantenere la stessa coorte si è rivelato fondamentale, poiché gli early adopter tendono a essere power user dell'AI rispetto agli utenti medi.

Volevamo normalizzare i costi su base $/sessione, poiché gli utenti che provano un nuovo modello a volte aumentano l'utilizzo in termini di numero di sessioni durante la fase di sperimentazione. Abbiamo scoperto che un semplice confronto $/sessione era comunque fuorviante, perché anche la distribuzione delle sessioni stava cambiando: gli early adopter stavano affrontando problemi più complessi con i nuovi modelli rispetto alla loro sessione media.

Di conseguenza, abbiamo stratificato le sessioni in base al fatto che fossero a turno singolo o multiplo e se includessero modifiche ai file, per poi ripesare la distribuzione di conseguenza. La tabella seguente mostra i risultati per Opus 5.5 rispetto a Opus 4.8 e GPT-6 Sol rispetto a GPT-5.6 Sol.

I numeri di GPT non sorprendono più di tanto, dato che il prezzo è stato tagliato del 50%. Tuttavia, siamo stati felici di constatare che Opus 5.5 rappresenta una riduzione significativa dei costi anche per i nostri carichi di lavoro reali, considerando la nostra precedente esperienza con Opus 5.

La nostra decisione

Siamo stati in grado di fornire ai dipendenti l'accesso sperimentale a Opus 5 e GPT-6 Sol e Luna fin dal primo giorno di lancio dei modelli. Nel giro di tre giorni abbiamo raccolto dati sufficienti per confermare che questi modelli si trovavano sulla frontiera dell'efficienza e abbiamo deciso di rimuoverli dal budget sperimentale per inserirli nella circolazione standard come modelli generalmente disponibili.

Nel corso della prossima settimana faremo un ulteriore passo avanti per Opus 5.5, rendendolo il modello predefinito per Claude Code, vista la sua chiara posizione di qualità superiore e costo inferiore rispetto ai suoi predecessori.

La nostra esperienza con GPT-6 Sol suggerisce che non sostituirà GPT-5.6 Sol como modello predefinito per Codex. Tuttavia, includeremo GPT-6 Sol nel toolkit del nostro smart router, dato il suo vantaggio in termini di costi rispetto a 5.6 Sol. 

Nel complesso, abbiamo trovato questo approccio efficace per valutare rapidamente la qualità e il costo dei modelli, consentendoci di adottare rapidamente i modelli più recenti che dimostrano il loro valore. Questa flessibilità è oggi più importante che mai, con nuovi modelli che arrivano quasi quotidianamente.

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