Agenti AI orientati alla valutazione: come Zepto scala l'assistenza clienti su Databricks e MLflow

L'impegno di Zepto per un'assistenza clienti affidabile e in tempo reale

Zepto è una delle piattaforme di quick-commerce in più rapida crescita in India, con migliaia di prodotti, una presenza in oltre 60 città e tempi di consegna misurati in minuti. In un settore in cui la velocità è il prodotto stesso, l'assistenza clienti deve muoversi altrettanto rapidamente.

Per soddisfare questa aspettativa, Zepto gestisce l'assistenza clienti tramite un sistema AI multi-agente che elabora oltre centomila ticket al giorno. All'inizio, il team riusciva a creare e rilasciare gli agenti rapidamente. La sfida più complessa consisteva nel mantenere l'affidabilità di tali agenti a fronte della crescita dei volumi, dell'espansione delle categorie e del continuo mutamento del comportamento dei clienti. Zepto ha collaborato con Databricks per trovare una risposta, non rilasciando altri agenti, ma rendendo la valutazione il metodo principale per creare, testare e gestire gli agenti.

Questo blog ripercorre questo percorso: l'architettura del sistema, il framework di valutazione su Databricks e MLflow, i casi d'uso reali in cui ha dimostrato il suo valore, nonché i risultati e le lezioni che ne sono derivati.

Perché l'approccio "rilascia l'agente e basta" fallisce su larga scala

In un business ad alta velocità, l'approccio "rilascia l'agente e basta" funziona solo fino a quando non si scontra con la scalabilità. Con oltre 100.000 ticket al giorno gestiti da agenti AI, anche un tasso di errore dell'1% genera migliaia di risultati negativi e una reale perdita di ricavi ogni singolo giorno.

La pressione è arrivata a ondate irregolari. Eventi meteorologici, il Diwali e l'inizio dell'estate hanno causato forti picchi nel volume dei ticket. L'espansione dai prodotti alimentari all'abbigliamento, all'elettronica e alla bellezza ha introdotto nuovi percorsi di rimborso, cambio e reso. Nel frattempo, una clientela più diversificata e multilingue ha portato a una gamma più ampia di richieste di assistenza, con nuove modalità di errore che emergevano ogni poche settimane.

Il problema di fondo è il gap di affidabilità. I sistemi agentici operano come workflow multi-fase (classificazione dell'intento, recupero delle informazioni, analisi degli input, ragionamento decisionale, chiamata di strumenti transazionali e generazione di risposte), pertanto gli errori possono emergere in qualsiasi punto del percorso, non solo nella risposta finale.

Questo gap di affidabilità si è tradotto in problemi concreti:

• Gli errori erano invisibili finché i clienti non si lamentavano
• Le correzioni erano lente
• La risposta finale nascondeva gli errori interni
• Mancava un metodo strutturato per bilanciare costi, prestazioni e qualità dell'agente
• La progettazione dell'agente non considerava tutte le prospettive critiche degli stakeholder
• Era difficile garantire l'affidabilità a fronte di una rapida evoluzione degli agenti

L'obiettivo è diventato chiaro: progettare un framework di valutazione su Databricks e MLflow in modo che funga da infrastruttura AI di base su cui creare e gestire gli agenti.

Perché un framework di valutazione e i relativi risultati

Un solido framework di valutazione influisce direttamente su cinque assi di idoneità alla produzione:

• Affidabilità: garanzie a livello di sistema che gli agenti si comportino correttamente in tutte le fasi, e non solo che la risposta “sembri corretta”
• Velocità: iterazione più rapida e sicura su prompt, policy e modelli, poiché le modifiche vengono sottoposte automaticamente a test di regressione
• Controllo di costi, qualità e prestazioni: capacità di scegliere modelli ottimali, strategie di prompt o strategie di routing ibride per raggiungere il punto di equilibrio ottimale rispetto ai vincoli, con il supporto di dati di valutazione concreti
• Governance: tracce verificabili, baseline di valutazione con controllo di versione e soglie ben definite per il deployment e il rollback. Le decisioni non si basano più sull'istinto (“questa versione sembra migliore”), ma sulle prove (“questa versione supera la baseline sulle metriche concordate”)
• Collaborazione tra gli stakeholder: definizione dei criteri di successo e affidabilità dal punto di vista degli stakeholder, rendendo i compromessi espliciti e misurabili per tutti

Con Databricks + MLflow come spina dorsale della valutazione e un'architettura degli agenti basata innanzitutto sulla valutazione, Zepto ha ottenuto:

Costi ed efficienza

• Oltre l'80% dei ticket interamente gestiti da agenti AI con supervisione umana
• Riduzione del 65% dei costi di supporto o dei ticket di supporto
• Tempo di recupero dell'investimento inferiore a un mese

Qualità e reputazione

• Miglioramento del 20% della soddisfazione del cliente (CSAT)
• Miglioramento dell'8% dell'accuratezza

Prestazioni e operazioni

• Cicli di sviluppo 3 volte più rapidi
• Tempi di risoluzione 4 volte più rapidi

Creare il framework: un doppio ciclo per garantire sicurezza e controllo

Al centro di questo approccio c'è il modello a doppio ciclo: un ciclo di sviluppo e un ciclo di produzione, collegati da un gate di qualità. Questa sezione descrive come questi cicli lavorano insieme.

• Ciclo di sviluppo: in cui si progettano, si ripetono e si valutano le versioni degli agenti per crearle in sicurezza prima del rilascio
• Ciclo di produzione: in cui si monitora il comportamento in tempo reale e si rilevano gli errori per gestire gli agenti in sicurezza
• Ciclo di feedback: in cui gli errori di produzione vengono reintrodotti nello sviluppo per arricchire l'iterazione successiva
• Gate di qualità: controlla il passaggio tra i cicli, decidendo quali versioni sono ammesse in produzione e quali vengono rimandate allo sviluppo per ulteriori miglioramenti

Insieme, questi due cicli garantiscono che gli agenti vengano creati e gestiti sotto controllo. Qualsiasi errore viene catturato automaticamente, segnalato e corretto. Di conseguenza, gli agenti vengono creati in sicurezza, eseguiti sotto controllo e migliorati continuamente per gestire meglio gli errori di produzione nel tempo. Il doppio ciclo è al centro del nostro framework.

Fase 0: Abilitare il tracciamento: agenti trasparenti fin dalla progettazione

Ogni invocazione dell'agente emette una traccia di esecuzione dettagliata che cattura prompt, completamenti, documenti recuperati, chiamate di strumenti, latenze e percorsi decisionali, in modo che l'intero workflow sia osservabile a livello granulare anziché limitarsi a un input e a un output finale.

Abbiamo abilitato questo comportamento con un approccio ibrido utilizzando MLflow. Una singola riga, mlflow.<library>.autolog(), attiva il tracciamento automatico, mentre il decoratore @mlflow.trace aggiunge span personalizzati ovunque sia necessario un maggiore dettaglio. Le tracce vengono emesse in tempo reale come span OpenTelemetry con ID univoci in modo da rimanere componibili, e l'integrazione di MLflow con Unity Catalog centralizza il logging nelle tabelle Delta.

Fase 1: Definire le dimensioni di valutazione: pilastri e gate

Con il tracciamento abilitato, il passo successivo consiste nel comprendere, dal punto di vista di ciascun stakeholder, “Cosa significa per te il successo di questo agente?”. Formalizziamo questo aspetto come pilastri di valutazione, ognuno con gate specifici.

In questo modo, un dibattito tra più stakeholder si trasforma in un contratto condiviso e misurabile. Gli agenti vengono valutati in base alle dimensioni che contano davvero per ciascun stakeholder. I pilastri tipici includono l'esperienza del cliente, l'efficienza operativa, il rischio e la conformità e l'impatto finanziario; ogni pilastro presenta soglie numeriche chiare che devono essere soddisfatte prima del deployment.

Fase 2: Il golden dataset: pietra miliare dell'affidabilità

Il golden dataset è l'unica fonte di verità per valutare il comportamento degli agenti nel ciclo di sviluppo. Dovrebbe:

• Coprire casi normali, limite e di errore che l'agente deve gestire
• Includere le aspettative dei diversi stakeholder acquisite sotto forma di esempi
• Essere ampiamente annotato con metadati (tipo di scenario, linea di business, livello di rischio, ecc.)

Tutti gli stakeholder collaborano alla definizione del dataset; ad esempio, il team della sicurezza contribuisce con esempi di pattern avversari come prompt injection, attacchi all'identità e tentativi di esfiltrazione dei dati. Questo garantisce che l'affidabilità venga misurata sia rispetto a scenari reali sia all'uso ordinario.

I dataset sono una risorsa viva e la loro qualità si consolida nel tempo. Il divario tra l'accuratezza in fase di sviluppo e quella in produzione è di per sé un segnale della qualità del dataset. Zepto ha investito costantemente nei dataset di valutazione di MLflow nell'arco di sei mesi, passando da 500 esempi e un divario di accuratezza dev-prod di 8 punti, a 2.000 esempi e un divario di 2 punti, fino a 5.247 esempi e un divario di 0,4 punti. Ogni ora dedicata alla qualità del dataset fa risparmiare circa dieci ore di debugging in produzione, quindi il golden dataset diventa un moltiplicatore 10x: ogni errore in produzione aggiunge tracce di errore al golden dataset, rendendo il sistema più robusto per tutte le versioni future.

Fase 3: Automatizzare il prompt engineering: generazione e ottimizzazione automatiche

Invece di scrivere i prompt a mano, abbiamo reso il prompt engineering un processo automatizzato e basato sui dati. La progettazione dei prompt è la fase cruciale in cui gli ingegneri trascorrono la maggior parte del tempo, e la qualità dei prompt ha un impatto sproporzionato sulla qualità e sulle prestazioni degli output degli agenti.

Utilizzando l'ottimizzazione dei prompt di MLflow, registriamo un prompt iniziale, generiamo e ottimizziamo le varianti rispetto agli stessi scorer che controllano il deployment, eseguiamo automaticamente valutazioni A/B e distribuiamo il risultato migliore. L'ottimizzatore effettua una riflessione con un modello potente e valuta i candidati in produzione con uno più economico, in modo che la ricerca stessa rimanga attenta ai costi in produzione. Questo ha ridotto la sperimentazione manuale dei prompt, migliorato l'accuratezza e garantito che i miglioramenti dei prompt fossero sempre misurati rispetto al golden dataset prima di arrivare in produzione.

Fase 4: Definire gli scorer e configurare la giuria AI

Con le tracce che fluiscono nel ciclo di produzione, dobbiamo valutarle in base alle dimensioni cruciali per la qualità degli agenti (dimensioni di valutazione). Immagina questo processo come una giuria AI, in cui ogni scorer sfrutta i propri punti di forza. MLflow offre tre opzioni per creare scorer.

• Giudici integrati - scorer pronti all'uso
• Giudici personalizzati - per creare giudici su misura per esigenze specifiche
• Scorer basati su codice - per metriche deterministiche come la latenza degli strumenti o il numero di chiamate agli strumenti

Utilizziamo scorer basati su LLM solo dove è necessario un giudizio di tipo umano e ci affidiamo a regole semplici dove è sufficiente una logica deterministica. Calibriamo i giudici rispetto alle etichette umane per raggiungere un accordo dell'80-90% e utilizziamo più giudici per le decisioni ad alto rischio.

Fase 5: Configurare l'opzionalità del modello

L'opzionalità del modello è un componente fondamentale che consente al framework di passare da un modello proprietario o open source all'altro semplicemente modificando i nomi dei modelli in Databricks. Ciò significa che il ciclo di sviluppo può cercare continuamente una combinazione migliore per trovare il compromesso ottimale tra costi, prestazioni e qualità.

Fase 6: Creare l'auto-regressione

Automatizziamo la valutazione della regressione per creare un ciclo di sviluppo ripetibile, configurabile e scalabile. Qualsiasi modifica attiva l'auto-regressione e, quando l'affidabilità è garantita, il deployment automatico.

Mettendo insieme i vari elementi, una tipica modifica segue questo percorso:

1. Qualcuno modifica la logica, il prompt o il modello dell'agente.
2. Il workflow di valutazione si attiva automaticamente con tre input: la nuova versione dell'agente, il golden dataset e la baseline di produzione attuale.
3. Il sistema esegue le valutazioni e produce metriche per tutti gli scorer e i pilastri.
4. Il quality gate verifica:
   • La nuova versione soddisfa tutti i requisiti (costi, qualità, prestazioni, ecc.)?
   • Offre prestazioni pari o superiori rispetto alla baseline di produzione?
5. In caso positivo, la nuova versione viene promossa in produzione; in caso contrario, viene rifiutata e l'agente esistente continua a gestire il traffico.

Fase 7: Creare il ciclo di produzione - Configurare una rete di sicurezza in tempo reale

Valutare il 100% del traffico è costoso, ma un campionamento uniforme ingenuo al 10% non rileva la maggior parte degli edge case. Abbiamo implementato un campionamento stratificato in cui i tassi di campionamento della valutazione dipendono da clienti di alto valore, nuove funzionalità o flussi modificati di recente, sentiment negativo o alto rischio di escalation, e interazioni basate su immagini o a rischio di frode. Ciò consente di ottenere un campione di valutazione effettivo del 18-20% (~14.400 tracce al giorno) a un costo gestibile, catturando al contempo il 45-60% degli edge case e rilevando i problemi entro 4-6 minuti.

La logica finanziaria è evidente: rispetto a un approccio di campionamento uniforme, la metodologia stratificata ha ottenuto una riduzione dell'86% dei costi di revisione per problema identificato, offrendo al contempo un miglioramento di 9 volte nel rilevamento degli edge case, rendendo il processo di controllo qualità significativamente più efficiente e scalabile.

I risultati della valutazione vengono scritti in tabelle Delta e visualizzati tramite dashboard e regole di avviso in Databricks. Gli avvisi critici (controllati ogni 5 minuti) monitorano cali di accuratezza dell'intent, violazioni di groundedness, alto rischio di escalation e superamenti della latenza P95. Gli avvisi di livello alto/medio monitorano il peggioramento dell'empatia, picchi di costo, tassi di errore degli strumenti, trend del CSAT, tasso di rilevamento delle frodi e latenza multimodale. Ciò consente operazioni di tipo SRE per gli agenti AI: rilevamento rapido, triage e mitigazione.

Lo stack di agenti ad architettura componibile

Un buon framework di valutazione funziona molto meglio se l'architettura dell'agente è progettata fin dall'inizio per essere osservabile e scomponibile. Lo stack di supporto di Zepto è costruito proprio attorno a questa idea.

Una richiesta del cliente, sotto forma di chat o immagine, passa prima attraverso un orchestratore e un router agentici. Il router può passare la gestione a un operatore umano in qualsiasi momento. Al di sotto di esso, il sistema si divide in due tipi di agenti.

Gli agenti verticali sono specialisti, ognuno dei quali gestisce una singola famiglia di intent ben definita:

• WIMO: per il tracciamento degli ordini e domande sull'ETA
• Missing: per ordini non consegnati o parziali
• Expiry: per prodotti confezionati scaduti
• Returns: per lo stato e l'elaborazione dei rimborsi
• Quality: per prodotti freschi non freschi o deteriorati
• Unable to Pay: per problemi relativi a wallet, promozioni e pagamenti
• Generale, come fallback

Gli agenti orizzontali fungono da livelli di supervisione trasversali ai vari casi d'uso:

• Image Deduplication: individua le immagini riutilizzate in diverse segnalazioni
• Item Matching and Image Manipulation Detection: verificano che le immagini caricate corrispondano agli articoli a catalogo e non siano state modificate

Questa separazione offre un duplice vantaggio. Le metriche possono essere calcolate per ciascun agente verticale, come l'F1 dell'intento WIMO o l'accuratezza dell'OCR di scadenza, mentre gli agenti orizzontali possono essere valutati su aspetti trasversali come la precisione nel rilevamento delle frodi, il riutilizzo delle immagini e il rilevamento delle manipolazioni. Ogni componente può essere misurato singolarmente o in combinazione.

Il framework in azione

Quando si lancia per la prima volta un agente IA in produzione, sembra di mandare un tirocinante brillante ma imprevedibile a rappresentare l'azienda. Gli si danno istruzioni sperando per il meglio, ma finché non si trova sotto pressione, si sta essenzialmente navigando al buio.

Fin da subito, ci siamo resi conto che il monitoraggio software tradizionale è del tutto inutile per l'IA. Un agente può avere un uptime del server perfetto e zero errori, pur continuando a ripetere la stessa identica risposta errata a un cliente frustrato. Per gli ingegneri la dashboard è verde, ma per il cliente è un disastro.

Sapevamo di non poter scalare la nostra IA basandoci solo sulla speranza. Avevamo bisogno di un framework di valutazione che non si limitasse a verificare se l'IA stesse parlando, ma che comprendesse effettivamente cosa stesse dicendo e dove stesse sbagliando. Le storie seguenti raccontano i momenti in cui questo framework ha dimostrato il suo valore, provando che un buon sistema di valutazione sblocca funzionalità di prodotto completamente nuove.

Storia 1: L'ETA che non si muoveva mai

Un problema in produzione ha bloccato i rider nel traffico mentre l'agente continuava a rispondere a ciclo continuo "in arrivo tra 10 min", perché leggeva dati memorizzati nella cache. Il cliente chiedeva dove fosse il suo ordine, riceveva la stessa risposta, chiedeva di nuovo e riceveva ancora la stessa risposta.

Il contatore di token (che monitora l'uso dei token) e i sistemi di punteggio degli avvisi hanno rilevato la ripetizione e l'alto rischio di escalation entro 5 minuti, evidenziando tracce di rider fermi con ETA invariati. Questo ha attivato una modifica delle regole. Se un rider rimane fermo per più di 10 minuti, ora l'agente fornisce un aggiornamento onesto e offre in modo proattivo la cancellazione con rimborso completo, invece di ripetere una promessa ormai superata.

Un'intuizione, colta dalla valutazione online, si è trasformata in un'intera linea di funzionalità: cancellazione in caso di ritardo, proposta proattiva di cancellazione durante la carenza di rider, cancellazione automatica se nessun rider viene assegnato entro una finestra temporale stabilita e cancellazione senza domande per i clienti di alto valore.

Storia 2: Rilevare la regressione delle cancellazioni prima dei clienti

Quando Zepto ha aggiunto la gestione delle cancellazioni all'agente WIMO, il modello ha iniziato a confondere tre intenti molto diversi: "dov'è il mio ordine", "voglio cancellare" e "il mio ordine è stato cancellato".

La valutazione di MLflow in fase di sviluppo l'ha rilevato immediatamente. L'accuratezza complessiva dell'intento è scesa da circa il 92,1% all'87,4%, con un punteggio F1 scarso sui nuovi intenti WIMO_CANCEL e WIMO_CANCEL_STATUS. Poiché la regressione è emersa rispetto al golden dataset, nessun cliente l'ha mai vista. L'ottimizzazione dei prompt e gli aggiornamenti del dataset hanno ripristinato l'accuratezza complessiva a circa il 94,2%, superando la baseline originale, con un F1 di tool-calling quasi perfetto sulle API di cancellazione. La funzionalità è andata online con zero rollback.

Storia 3: Calibrare gli agenti multimodali rispetto al giudizio umano

Valutare la qualità dei prodotti freschi è davvero difficile e gli esseri umani non sono sempre d'accordo. La stessa immagine di funghi potrebbe ricevere un punteggio di 2 su 5 da un valutatore e di 3 su 5 da un altro. Abbiamo misurato questo disaccordo con il Kappa di Cohen e lo abbiamo considerato come il nostro limite massimo di affidabilità, poiché nessun modello può essere più coerente degli esseri umani da cui apprende.

Abbiamo anche scoperto che l'IA tendeva a giocare sul sicuro. Se lasciata a se stessa, accumulava punteggi pari a 3 per evitare decisioni difficili, mentre i punteggi umani registravano picchi a 4 e 5. Quindi non ci siamo limitati a ridurre al minimo l'errore rispetto alla media. Abbiamo allineato l'andamento alla distribuzione dei punteggi umani. La valutazione online ha anche fatto emergere casi per i quali il sistema non era stato progettato, come il latte cagliato che viene esposto come prodotto confezionato ma deve essere valutato come un prodotto fresco, o i reclami sul gusto o sull'odore che una foto semplicemente non può mostrare, i quali sono stati indirizzati verso un percorso separato.

Questa baseline calibrata ci consente di decidere quali modelli utilizzare per ciascun tipo di prodotto, come iterare i prompt rispetto al giudizio umano e come calibrare la politica di rimborso per segmento di clientela in base alle prestazioni reali dell'agente.

Storia 4: Chiudere le falle utilizzate per gli abusi

I tentativi di abuso dei rimborsi utilizzavano immagini di catalogo, foto modificate e immagini riutilizzate per più richieste. La pipeline di valutazione multimodale sottoponeva le immagini a controlli di pre-elaborazione per sfocatura, luminosità e risoluzione, le convalidava tramite OCR e poi utilizzava un comitato di tre modelli di visione con regole di consenso per decidere tra l'approvazione automatica e la revisione umana. A questo si aggiungevano il rilevamento delle sfocature, degli screenshot, dei duplicati, la corrispondenza tra immagine e SKU, i controlli tra immagine e motivo dichiarato e la convalida della prova di consegna.

Cosa abbiamo imparato gestendo questo sistema su scala

La gestione di questo framework su scala ci ha insegnato alcuni principi che possono essere generalizzati oltre il quick commerce.

• Non ottimizzare mai una singola metrica. Una volta abbiamo cercato di migliorare l'accuratezza dell'intento in modo isolato e abbiamo visto calare il CSAT. L'ottimizzazione del solo intento ha fatto guadagnare 5 punti di accuratezza dell'intento, ma ha aumentato la latenza del 133% e ha causato la perdita di 0.4 punti di CSAT. Un punteggio composito e multi-obiettivo ha fatto guadagnare 3 punti di intento con solo il 17% in più di latenza e ha aggiunto 0.2 punti di CSAT. Molteplici prospettive, giudici LLM, controlli basati su regole, etichette umane e metriche di produzione creano insieme la verità. Questa ridondanza è una garanzia, non uno spreco.
• I golden dataset sono le fondamenta. Investi presto per ottenere migliaia di esempi diversi e di alta qualità. Monitora il divario tra l'accuratezza in fase di sviluppo e quella in produzione e calibra fino a quando non convergono. Il divario dev-prod è un segnale della qualità del dataset, non un mistero.
• I giudici LLM hanno bisogno di calibrazione. Tratta i giudici come modelli dotati di una propria valutazione. Misura il loro accordo con gli esseri umani, utilizza ensemble per i casi ad alto rischio e ricalibra al variare dei modelli di base.
• La strategia di campionamento conta più del tasso di campionamento. Il campionamento uniforme ingenuo (naive) è economico ma cieco. Il campionamento stratificato focalizzato sui flussi ad alto rischio offre un rilevamento dei problemi migliore di un ordine di grandezza per ogni dollaro speso.
• Automatizza il ciclo di feedback fin dal primo giorno. Rilevamento, etichettatura, riaddestramento, implementazione e monitoraggio dovrebbero essere tutti automatizzati, con ogni errore che arricchisce automaticamente il ciclo di addestramento successivo. Per noi questo ha fatto risparmiare circa 155 ore al mese, l'equivalente di due ingegneri a tempo pieno reindirizzati allo sviluppo di funzionalità.
• Tratta la valutazione come una superficie di prodotto. Le dashboard e le metriche sono utilizzate dai team di supporto, prodotto, frode e operazioni. Devono essere interpretabili e traducibili in azioni concrete, non solo tecnicamente corrette.

Consigli per gli sviluppatori di agenti

Per le organizzazioni che creano sistemi agentici su Databricks, l'esperienza di Zepto suggerisce la seguente roadmap:

• Inizia dalle tracce, non solo dai modelli: applica uno schema di traccia condiviso e registra tutto in Delta
• Rendi le valutazioni di MLflow un passaggio obbligatorio nel CI/CD: nessuna implementazione senza superare la baseline sulle metriche concordate
• Costruisci golden dataset come un asset, con KPI dedicati (dimensioni, divario dev-prod, copertura dei casi limite)
• Utilizza LLM-as-judge per ciò che gli esseri umani giudicano oggi (qualità, empatia, aderenza ai fatti), ma calibra e limita ai segmenti corretti
• Implementa il campionamento stratificato e gli avvisi in tempo reale il prima possibile; integrare la visibilità operativa in un secondo momento è costoso
• Progetta gli agenti affinché siano verticali (specializzati) e orizzontali (di supervisione), in modo da poterli valutare singolarmente e in combinazione

Conclusione

Nella transizione dalle demo sperimentali a un'infrastruttura mission-critical, il vincolo principale si è spostato dalle capacità grezze del modello alla garanzia del sistema. Il percorso di Zepto dimostra che, stabilendo la valutazione come primitiva di sviluppo fondamentale, le organizzazioni possono scalare in modo affidabile gli agenti per gestire decine di migliaia di interazioni quotidiane complesse su input multimodali, supportate da rigorose garanzie su qualità, costi e mitigazione dei rischi.

Databricks e MLflow fungono da substrato essenziale per questa evoluzione, fornendo un'infrastruttura dati incentrata sulle tracce su Unity Catalog e Delta, insieme a una valutazione scalabile, all'ottimizzazione automatizzata dei prompt e a un'integrazione CI/CD fluida. Questo stack componibile, combinato con la flessibilità di scelta del modello, consente ai team di ottimizzare l'equilibrio tra prestazioni e costi per ogni attività specifica.

In definitiva, il vantaggio competitivo risiede nella decisione strategica di considerare la valutazione non come un controllo finale, ma come un'infrastruttura AI fondamentale. Il modello per la gestione di agenti su scala di produzione non è più un mistero; Zepto e Databricks hanno fornito la risposta. La sfida ora è la velocità di adozione. Nel panorama dell'AI in rapida evoluzione, i leader non saranno coloro che aspettano la certezza assoluta, ma coloro che progettano per l'affidabilità fin dal primo giorno.

Per gli sviluppatori che creano agenti destinati a conquistare la fiducia negli ambienti di produzione, questi stessi elementi fondamentali sono pronti su Databricks e MLflow 3. Le organizzazioni che definiranno la prossima frontiera saranno quelle che inizieranno oggi stesso il loro percorso incentrato sulla valutazione.

Crea agenti su Databricks
Inizia con la valutazione e il monitoraggio di MLflow

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