Imparare dall'esperienza reale

Il modo in cui gli utenti interagiscono con i nostri prodotti nel mondo reale rappresenta una preziosa fonte per l'addestramento dei modelli. I dati sono abbondanti, riflettono l'effettiva distribuzione dei task degli utenti e catturano le correzioni degli utenti e i fallimenti degli strumenti che gli ambienti sintetici potrebbero tralasciare.

Un modo comune per imparare dai dati del mondo reale è il fine-tuning con campionamento di rigetto: giudicare il risultato di ciascuna sessione, conservare quelle riuscite e addestrare il modello a imitarle. Tuttavia, un risultato riuscito non significa che ogni passaggio fosse corretto, quindi imitare l'intera traiettoria rischia di rafforzare i comportamenti intermedi negativi oltre a quelli positivi. Lo scarto delle sessioni non riuscite comporta inoltre la perdita di prove fondamentali su dove il modello risulta carente.

Combiniamo la messa a punto tramite campionamento di rigetto (rejection sampling fine-tuning) con l'auto-distillazione guidata da suggerimenti per imparare sia dalle sessioni riuscite che da quelle non riuscite. Un suggerimento (hint) è una breve istruzione correttiva basata su informazioni che il modello possedeva già al momento dell'errore. I passaggi utili delle sessioni riuscite rimangono obiettivi di imitazione, mentre i suggerimenti fondati trasformano gli errori evitabili in obiettivi di correzione.

Le correzioni degli utenti e gli errori degli strumenti aggiungono supervisione su cosa è andato storto lungo il percorso, oltre a stabilire se il task ha avuto successo in ultima analisi. Applichiamo questa fase dopo l'apprendimento per rinforzo in ambienti sintetici per contribuire a colmare il divario tra tali ambienti e l'uso nel mondo reale.

Nell'uso in tempo reale, un checkpoint successivo post-addestrato di GLM-5.2 ha ridotto i fallimenti delle chiamate agli strumenti del 21,2% rispetto a un checkpoint addestrato in precedenza. Per GLM-5.3, il post-addestramento ha ridotto i fallimenti delle chiamate agli strumenti del 33,0% e la probabilità media stimata di insoddisfazione dell'utente media o alta del 17,2% rispetto al modello standard.

I task sintetici ci consentono di creare problemi controllati con risultati facili da verificare, ma sono in genere limitati a un singolo prompt e possono coprire solo gli scenari che progettiamo esplicitamente.

Al contrario, gli utenti nelle sessioni del mondo reale portano istruzioni, contesti e combinazioni di strumenti diversi in sessioni che si sviluppano su più turni di interazione. Tale utilizzo nel mondo reale produce naturalmente due preziosi segnali di errore: le correzioni degli utenti rivelano dove l'agente non è riuscito a fornire ciò che desideravano, e gli errori degli strumenti mostrano dove le sue azioni sono fallite in ambienti reali. La nostra pipeline di campionamento rispetta la privacy e le scelte di addestramento degli utenti escludendo le sessioni con informazioni di identificazione personale (PII) e provenienti da utenti che hanno scelto di non partecipare.

I dati del mondo reale ci offrono quindi casi di errore che un ambiente sintetico potrebbe non esporre e spesso includono già l'indicazione di dove si è verificato l'errore.

Durante l'addestramento su dati del mondo reale, il fine-tuning con campionamento di rigetto (RFT) standard seleziona le sessioni riuscite in base ai loro risultati finali, senza utilizzare esplicitamente il feedback degli utenti e degli strumenti per distinguere le buone azioni intermedie da quelle cattive. Un agente può riprendersi da una chiamata di strumento errata o correggere un errore dopo il feedback dell'utente e comunque fornire l'output corretto alla fine.

Scartare le sessioni fallite limita anche l'efficienza campionaria. Una sessione che non raggiunge mai un buon risultato potrebbe comunque rivelare un errore chiaro ed evitabile come utile segnale di addestramento.

Affrontiamo queste limitazioni separando due decisioni: quali sessioni contengono comportamenti che vale la pena imitare e quali turni contengono errori che vale la pena correggere. La pipeline di dati prende queste decisioni separatamente, quindi assegna ai turni del modello uno dei tre trattamenti:

Imita: i turni non errati nelle sessioni riuscite ricevono l'ordinaria loss di entropia incrociata (CE), aumentando la probabilità dei token registrati.
Corretto: sia nelle sessioni riuscite che in quelle non riuscite, i turni di errore con un suggerimento valido ricevono una loss di divergenza di Kullback–Leibler (KL), spingendo il modello verso le previsioni del token successivo che formula quando vede il suggerimento.
Mantieni come contesto: i turni in sessioni non riuscite che mancano di un suggerimento convalidato, e i turni errati contrassegnati senza un suggerimento convalidato in entrambi i tipi di sessione, servono come contesto ma non ricevono alcuna loss.

Di conseguenza, le sessioni riuscite possono fornire sia obiettivi di imitazione che di correzione, mentre le sessioni non riuscite forniscono solo obiettivi di correzione. Tutti i turni rimanenti, inclusi l'output di sistema, dell'utente e dello strumento, rimangono come contesto.

Diagramma di instradamento della sessione: le sessioni riuscite forniscono imitazione CE e correzioni con suggerimenti idonee; le sessioni non riuscite forniscono solo correzioni idonee. — Instradamento della sessione corrente e maschere dei contenuti dell'assistente. Le sessioni riuscite contribuiscono agli obiettivi di imitazione; i record di feedback conservati possono contribuire alle correzioni con suggerimenti anche quando la sessione non ha successo. Gli altri contenuti rimangono come contesto. Le sessioni incomplete sono escluse. L'eccezione CE non finale yield/stop-token non è illustrata e questo diagramma non stabilisce la miscela utilizzata da un checkpoint precedente.

La parte di imitazione utilizza l'RFT standard. La parte correttiva utilizza On-Policy Self-Distillation (OPSD): lo stesso modello funge da docente e da studente, e al docente vengono fornite informazioni privilegiate. In questo caso, tali informazioni privilegiate consistono in un breve suggerimento che spiega un errore evitabile. Addestriamo lo studente a corrispondere alle previsioni del token successivo del docente senza che gli venga fornito il suggerimento.

Entrambe le parti sono importanti. L'addestramento basato solo sulla correzione può esporre a una scorciatoia: docente e studente possono concordare ignorando il contesto anziché imparare la correzione. Il termine CE ancora l'addestramento a un comportamento utile, contribuendo a scoraggiare l'accordo derivante dall'ignorare il contesto.

Lo studente post-addestrato diventa quindi un'opzione di modello in Computer. Le nuove sessioni derivanti dall'uso dal vivo passano attraverso gli stessi filtri di idoneità e privacy prima di entrare in un altro ciclo della pipeline di addestramento.

Successivamente, esaminiamo un esempio concreto che contiene sia l'imitazione che la correzione.

Consideriamo un'eventuale sessione riuscita in cui l'utente chiede un confronto delle modifiche ad asyncio in Python 3.13 utilizzando la documentazione ufficiale. La nostra documentazione sugli strumenti afferma che search.web restituisce un elenco di risultati, ciascuno con un campo url.

Il modello esegue prima una ricerca valida per una versione come parte della raccolta di prove per il confronto, il che costituisce un buon comportamento da imitare.

Tuttavia, la successiva chiamata di esecuzione del codice tratta erroneamente quell'elenco come un dizionario. Lo strumento di codice restituisce TypeError: list indices must be integers or slices, not str. Poiché il tipo di ritorno è stato documentato prima della chiamata, si tratta di un errore che il modello avrebbe dovuto essere in grado di evitare. È possibile generare un suggerimento con la chiamata corretta per correggere tale azione.

Sessione di programmazione illustrativa: l'input di sistema e utente e gli errori degli strumenti rimangono contesto; le chiamate di ricerca e recupero registrate utili ricevono la CE in una sessione riuscita; una ricerca in elenco errata contrassegnata riceve la KL verso un docente a cui è stato fornito un suggerimento basato sui dati. — Una sessione di programmazione illustrativa mostra tre ruoli di addestramento: input solo contesto e output degli strumenti (grigio), imitazione CE delle chiamate registrate utili (scuro) e correzione KL di un errore contrassegnato (verde acqua). Qui, il modello tratta erroneamente un elenco di risultati di ricerca come un dizionario; un suggerimento riservato al docente basato sulla documentazione degli strumenti precedente guida la correzione. Gli obiettivi CE si applicano solo quando la sessione completata viene giudicata riuscita, mentre una sessione non riuscita può comunque fornire un obiettivo di correzione KL idoneo.

La pipeline di addestramento prevede quattro fasi: selezione delle sessioni e valutazione dei relativi risultati, identificazione degli errori e creazione di suggerimenti da feedback degli utenti ed errori degli strumenti, generazione delle probabilità del token successivo sia dal docente che dallo studente e addestramento del modello con una loss CE e KL combinata.

La pipeline di campionamento estrae da un sottoinsieme di sessioni Computer reali, idonee per l'addestramento, servite da GLM 5.2. Le esclusioni per il rifiuto dell'addestramento e quelle legate ai dati personali della pipeline vengono applicate prima di selezionare gli esempi per questo flusso di lavoro.

Il processo di screening iniziale seleziona i candidati valutati 4 o 5 su una scala di difficoltà dei task a cinque punti da parte di un giudice LLM e li divide in 2 gruppi:

Il gruppo di feedback degli utenti contiene sessioni con un effettivo follow-up da parte dell'utente o un flag di insoddisfazione da medio ad alto. Troviamo questi follow-up ad alta intenzione particolarmente utili per l'apprendimento: gli utenti stanno attivamente cercando di completare un task e le loro correzioni individuano con precisione ciò che il modello ha mancato.
Il gruppo di errori degli strumenti contiene sessioni con chiamate fallite segnalate da controlli basati su regole, escludendo guasti dell'infrastruttura riconosciuti e autorizzazioni negate.

Due giudici LLM valutano quindi il risultato finale rispetto alla richiesta dell'utente; entrambi i giudici devono restituire un verdetto positivo affinché la sessione sia etichettata come "riuscita". Per i casi che forniscono artifact, la fase dei risultati può ricostruire e ispezionare il riscontro, ricorrendo ai giudizi basati sul testo se tale fase fallisce. Le sessioni classificate come incomplete, come il lavoro in attesa dell'utente, vengono escluse.

Questo passaggio identifica le potenziali fonti di segnali di apprendimento; tuttavia, non tutti gli errori sono attribuibili al modello, poiché alcuni derivano da istruzioni ambigue o guasti dell'infrastruttura. La successiva annotazione determina quali errori candidati siano effettivamente evitabili e adatti all'addestramento.

Consideriamo una sessione di esempio nel gruppo di feedback degli utenti, in cui l'utente chiede: "How do I find my w3 on paychex". Il modello tratta "w3" come un errore di digitazione per W-2, cerca le istruzioni per W-2 e spiega come trovare quel modulo. Il follow-up dell'utente, "I meant the W-3 transmittal form," identifica l'errore, anche se la sessione alla fine ha successo.

Il reclamo aiuta a individuare l'errore, ma la causa principale è la decisione precedente di reinterpretare "w3" come W-2. La richiesta originale rende l'errore evitabile: il modello avrebbe potuto preservare W-3 o chiedere chiarimenti. Si scopre che l'ultimo turno dell'assistente prima del reclamo è la causa principale solo circa la metà delle volte.

La nostra pipeline di annotazione mappa causa ed effetto in modo sistematico all'interno di ciascuna sessione di feedback degli utenti. L'annotatore seleziona prima un requisito mancante o un'intenzione supportata dal contesto precedente. Tre giudici LLM identificano quindi i turni responsabili, richiedendo che almeno due concordino su un determinato turno. A volte una dichiarazione precedente stabilisce esplicitamente il requisito. In altri casi, nessuna singola dichiarazione precedente lo fa, ma più parti della conversazione precedente rendono congiuntamente deducibile il comportamento inteso. Questo design consente di collegare un reclamo a un precedente errore radice anziché attribuirlo esclusivamente all'ultima risposta.

Prima di accettare un suggerimento, la pipeline verifica anche che le sue affermazioni correttive derivino da informazioni disponibili prima del turno contrassegnato. Tali controlli mirano a ridurre il bias del senno di poi, in cui una nuova preferenza rivelata nel reclamo viene trattata come qualcosa che il modello avrebbe già dovuto conoscere.

In questo esempio, il suggerimento dice al modello di cercare il modulo di trasmissione W-3 su Paychex anziché W-2, o di chiedere quale modulo intenda l'utente se la richiesta è ambigua. La correzione prende di mira l'interpretazione e la decisione di ricerca precedenti, non solo la risposta finale. Il turno originale rimane invariato; l'annotazione aggiunge is_bad_turn: true e un hint non vuoto.

Una richiesta W-3 viene interpretata erroneamente come W-2; un reclamo successivo viene ricondotto alla decisione di ricerca precedente e confrontato con le prove precedenti. — Una sessione reale che mostra come un reclamo viene ricondotto a un errore precedente, con la procedura di annotazione sovrapposta. L'utente ha chiesto "w3" su Paychex, ma il modello lo ha trattato come un errore di battitura per W-2 e ha cercato il modulo sbagliato. Il consenso dei proponenti individua la causa principale, mentre due controlli di convalida valutano se le prove precedono l'errore e se le affermazioni del suggerimento derivano dalle informazioni disponibili in quel momento. Le annotazioni accettate preservano il testo originale e aggiungono contrassegni e suggerimenti, anziché obiettivi riscritti.

Consideriamo un'altra sessione nel gruppo degli errori degli strumenti con una chiamata di ricerca in cui l'agente effettua la ricerca con recency_filter: "year", ma lo strumento la rifiuta perché i valori consentiti sono "day", "week" o "month". Si tratta di una chiara violazione dello schema.

Il percorso degli errori degli strumenti utilizza regole deterministiche per gli errori noti e il giudizio del modello per i casi ambigui. Da solo, un messaggio di errore non è sufficiente per attribuire la colpa al modello; una correzione valutata deve indicare qualcosa che il modello avrebbe potuto conoscere dallo schema dello strumento, dalle istruzioni di sistema o dalla conversazione precedente.

Una chiamata di ricerca utilizza il valore non valido recency_filter year; un suggerimento basato sui dati istruisce il modello a utilizzare un valore elencato o a omettere un campo facoltativo. — L'argomento di ricerca non valido del report illustra la procedura attuale per gli errori degli strumenti. Lo schema rende questo errore evitabile; una semplice interruzione non lo farebbe. La chiamata originale rimane nel record e riceve un suggerimento basato sui dati. Il suggerimento consente un valore elencato o un'omissione se il campo è facoltativo; non richiede "month" per ogni richiesta.

Qui, il suggerimento nomina la chiamata fallita, include l'errore di convalida e istruisce il modello a utilizzare un valore consentito o a omettere il campo se facoltativo.

Una volta contrassegnato un turno, il sistema di addestramento esegue lo stesso checkpoint due volte: una volta come insegnante e una volta come studente. L'insegnante vede il suggerimento; lo studente no.

Entrambi i passaggi utilizzano il teacher forcing, in cui forniamo al modello la sessione registrata anziché consentirgli di scegliere nuovi token. Il passaggio in avanti produce comunque una distribuzione completa del token successivo a ogni passaggio, ma è sempre condizionata dal prefisso fisso della registrazione, non dai token di rollout.

Per l'esempio di ricerca, lo stesso modello assegna una probabilità molto più alta a "month" e minore a "year" quando riceve il suggerimento. L'addestramento utilizza questo spostamento distribuzionale come obiettivo soft.

Lo stesso modello valuta un turno registrato con e senza un suggerimento; le probabilità del docente disaccoppiato forniscono gli obiettivi KL mentre la CE ancora l'imitazione. — Due passaggi, un set di pesi. Entrambi i passaggi valutano la continuazione registrata; solo il docente riceve suggerimenti. Le sue probabilità del token successivo disaccoppiate guidano lo studente attraverso la KL in avanti. Obiettivi CE separati ancorano l'imitazione. Entrambe le loss alimentano un singolo aggiornamento dei pesi. I suggerimenti precedenti possono rimanere nel segmento corrente del docente; nessun passaggio genera una risposta di addestramento sostitutiva.

Le previsioni del docente sono disaccoppiate o a gradiente interrotto (stop-gradient): forniscono un obiettivo ma non ricevono un aggiornamento attraverso il passaggio del docente. Dopo il passaggio dello studente, un passo dell'ottimizzatore aggiorna il modello condiviso.

La loss CE tratta i token registrati selezionati per l'imitazione come obiettivi di ground-truth e penalizza il modello per aver assegnato loro basse probabilità. Ciò crea un obiettivo di imitazione rigido.

Alla posizione del token $i$ , sia $p_i(v)$ la probabilità dello studente del token $v$ nell'intero vocabolario $V$ . Il token successivo registrato nella risposta o nella chiamata dello strumento è $y_i$ , la distribuzione di target one-hot è $r_i$ .

r_i(v)=\mathbf{1}[v=y_i]

L'entropia incrociata misura quanto bene lo studente predice quel token registrato. Con un target one-hot, si riduce alla log-probabilità negativa assegnata a $y_i$ .

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

La maschera CE $m_i^{\mathrm{CE}}$ è $1$ dove il token deve essere imitato e $0$ altrimenti. La somma sulle posizioni selezionate fornisce la loss di imitazione.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

La loss KL utilizza invece l'intera distribuzione di probabilità del token successivo del docente $q_i$ come obiettivo di correzione soft. Il contesto del docente include il suggerimento corrente e qualsiasi suggerimento precedente conservato in quel segmento di addestramento; il contesto dello studente è sempre privo di suggerimenti.

La maschera KL $m_i^{\mathrm{KL}}$ è $1$ dove il token deve essere corretto e $0$ altrimenti; le maschere CE e KL non si sovrappongono. In queste posizioni, la KL in avanti penalizza il disaccordo tra il docente e lo studente nell'intero vocabolario:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Entrambi i termini condividono un unico denominatore anziché essere normalizzati separatamente. Questo denominatore conta il totale dei token selezionati per l'imitazione nell'intero batch di addestramento. Il peso $\lambda$ controlla il contributo dell'addestramento correttivo rispetto all'imitazione.

Questa normalizzazione condivisa si adatta all'interfaccia a denominatore singolo della nostra infrastruttura di addestramento e ripristina la loss SFT standard quando $\lambda=0$ , semplificando i confronti di base. Poiché i token CE sono molto più abbondanti dei token KL, l'uso di un denominatore condiviso evita anche di assegnare a singoli token KL pesi sproporzionatamente grandi in batch con pochi token contrassegnati.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

Applicati agli esempi precedenti, i turni contenenti la confusione W-3/W-2 e la chiamata di ricerca non valida ricevono la KL. Altri contenuti dell'assistente non contrassegnati in una sessione riuscita ricevono comunque la CE. Altri contenuti dell'assistente in una sessione non riuscita vengono conservati come contesto ma non ricevono né CE né KL.

Le nostre valutazioni rispondono a due domande distinte. Primo, un suggerimento aiuta effettivamente il modello a correggere un errore quando il suggerimento è presente? Secondo, l'addestramento aiuta il modello a evitare quell'errore in seguito, senza il suggerimento? La prima verifica se i suggerimenti forniscono utili segnali di addestramento. La seconda verifica se il modello impara da essi.

Testiamo la prima domanda prima dell'esecuzione dell'addestramento per assicurarci che i suggerimenti possano effettivamente allontanare il modello dagli errori.

Abbiamo rigenerato i turni di feedback degli utenti contrassegnati con e senza un suggerimento, utilizzando lo stesso modello base GLM-5.2 a temperatura zero. Un giudice cieco vede il reclamo successivo, ma né il suggerimento né la condizione che ha prodotto la risposta.

Nell'esempio W-3, il suggerimento sposta la probabilità del token successivo verso "3" e lontano da "2" dopo il prefisso "W-".

Le probabilità del token successivo dopo W- si spostano verso 3 anziché 2 quando il modello base invariato riceve un suggerimento. — Un suggerimento preserva il modulo W-3 richiesto. Le barre mostrano le probabilità medie del token successivo in otto passaggi in avanti; i baffi mostrano l'intervallo osservato, non un intervallo di confidenza. Entrambe le condizioni utilizzano il modello base invariato.

Su un campione riservato più ampio di 40 turni supportato da prove precedenti esplicitamente dichiarate, la quota giudicata corretta o sulla buona strada sale dal 40,0% senza suggerimento al 75,0% con un suggerimento. Su altri 40 turni supportati da intenti dedotti, sale dal 32,5% all'80,0%.

Convalida dei suggerimenti: i tassi di correzione o di progressione aumentano dal 40,0% al 75,0% per le prove esplicite e dal 32,5% all'80,0% per l'intento dedotto. — Convalida dei suggerimenti, non valutazione post-addestramento. Gli stessi 40 turni contrassegnati in ciascun gruppo di prove vengono rigenerati con e senza un suggerimento utilizzando il GLM-5.2 invariato a temperatura zero. Il giudice vede il reclamo ma non il suggerimento o la condizione. I conteggi sono derivati dai tassi e dalle dimensioni dei campioni del report; gli intervalli di confidenza non sono riportati.

Nell'esempio dell'errore dello strumento di ricerca, un suggerimento sposta effettivamente la massa di probabilità dal token year al token month.

Un suggerimento allontana le probabilità del token successivo del modello base invariato da year e le avvicina al valore consentito month. — Un suggerimento sposta la probabilità verso un valore consentito. Le barre mostrano le probabilità medie del token successivo in otto passaggi in avanti; i baffi mostrano l'intervallo osservato, non un intervallo di confidenza. Entrambe le condizioni utilizzano lo stesso modello base; non viene confrontato alcun checkpoint addestrato.

Su un campione riservato più ampio di 985 turni, rigeneriamo ogni turno quattro volte con e senza un suggerimento utilizzando lo stesso modello base. Un giudice cieco valuta se ciascuna rigenerazione evita il fallimento originale. I suggerimenti aumentano l'evitamento degli errori dal 75,1% al 93,7%, un guadagno accoppiato di 18,6 punti percentuali, e aumentano la quota che adotta l'azione corretta dal 60,6% al 82,3%. I guadagni maggiori si registrano sugli errori che il solo campionamento ripetuto fatica a correggere.

Su 985 turni con errori di strumenti riservati, i suggerimenti aumentano l'evitamento degli errori dal 75,1% al 93,7% e i tassi di azione corretta dal 60,6% al 82,3%. — Convalida dei suggerimenti per gli errori degli strumenti su 985 turni riservati contrassegnati, con quattro rigenerazioni per condizione. Le barre mostrano l'evitamento degli errori e i tassi di azione corretta per il modello base invariato, con e senza suggerimenti. Evitare l'errore preso di mira non stabilisce il successo della chiamata dello strumento o del task.

Testiamo quindi se il modello addestrato commette meno errori senza ricevere suggerimenti. Valutiamo il modello stock e vari checkpoint post-addestramento su attività di benchmark offline e in sessioni utente live, verificando una riduzione dei guasti degli strumenti e della insoddisfazione degli utenti.

La valutazione offline utilizza BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, un set di task rappresentativo di Computer e verifica il caricamento delle skill, la revisione dei documenti e le citazioni in linea. Misuriamo la quota di chiamate a strumenti i cui risultati sono esplicitamente segnalati come errori lungo le traiettorie di valutazione.

In queste valutazioni, il tasso di errore degli strumenti registrato è stato del 2,79% per il GLM 5.2 standard, dell'1,35% per il checkpoint RFT-only e dello 0,87% per un checkpoint RFT-plus-OPSD. Questi checkpoint sono stati addestrati su dati differenti, quindi non si tratta di un'ablazione OPSD con dati abbinati. I risultati dei benchmark a livello di task sono stati misti, pertanto un minor numero di errori degli strumenti non si traduce necessariamente in un miglioramento generale del successo dei task.

Tassi di errore degli strumenti registrati offline: 2,79% per GLM 5.2 standard, 1,35% per RFT-only e 0,87% per RFT più OPSD; i dati di addestramento differiscono. — Tassi di errore degli strumenti offline per i checkpoint GLM-5.2 standard, RFT-only e RFT-plus-OPSD. I dati di addestramento differiscono tra i checkpoint; questo non è un test di ablazione controllato.

Per GLM-5.2, abbiamo eseguito due test A/B separati con circa centomila utenti in ciascuna condizione. Nel primo, un primo checkpoint RFT-plus-OPSD ha registrato un tasso di guasto degli strumenti leggermente inferiore rispetto al GLM 5.2 base, pari al 2,82% contro il 2,94%, sebbene la differenza non fosse statisticamente significativa.

Nel test successivo, abbiamo confrontato due checkpoint RFT-plus-OPSD: uno precedente (checkpoint uno) e uno successivo (checkpoint due). I fallimenti delle chiamate agli strumenti sono scesi dal 2,24% all'1,77% delle chiamate con uno stato registrato. Si è trattato di una riduzione relativa statisticamente significativa del 21,2%. Non abbiamo confrontato direttamente il checkpoint due con il GLM 5.2 standard online.

I risultati del feedback degli utenti sono stati meno conclusivi. Nel secondo esperimento con GLM-5.2, la probabilità media di forte insoddisfazione (media o alta) è stata del 2,58% per il primo checkpoint e del 2,54% per il secondo checkpoint, senza alcuna differenza statisticamente significativa.

Due test A/B online separati; solo il confronto tra i checkpoint successivi presenta una riduzione significativa dei fallimenti degli strumenti, senza alcuna variazione significativa nell'insoddisfazione MID+. — Due distinti test A/B live di GLM-5.2. Il checkpoint 1 viene confrontato con il modello base GLM-5.2; il checkpoint 2 viene confrontato con il checkpoint 1. Tra questi due test, solo la successiva riduzione dei guasti degli strumenti è statisticamente significativa. I tassi MID+ indicano le probabilità medie stimate di insoddisfazione media o alta, non il numero di reclami.

Per GLM-5.3, abbiamo confrontato direttamente un checkpoint post-addestrato con il GLM-5.3 standard. I fallimenti delle chiamate agli strumenti sono scesi dal 3,56% al 2,38% delle chiamate con uno stato registrato, con una riduzione relativa del 33,04%. Il tasso MID+, ovvero la probabilità media stimata di insoddisfazione media o alta, è sceso dal 4,12% al 3,41%, con una riduzione relativa del 17,2%. Entrambe le riduzioni erano statisticamente significative.

Test A/B di GLM-5.3: il tasso di fallimento degli strumenti scende dal 3,56% al 2,38% e il tasso MID+, ovvero la probabilità media stimata di insoddisfazione media o alta, scende dal 4,12% al 3,41%. Le riduzioni relative corrette con CUPED sono rispettivamente del 33,04% e del 17,16%. Entrambi gli intervalli sequenziali al 95% escludono lo zero; la metrica di coinvolgimento principale non è significativa. — GLM-5.3 post-addestrato rispetto a GLM-5.3 standard in un test A/B online separato. I tassi di fallimento degli strumenti e MID+, i cambiamenti relativi e gli intervalli di confidenza sequenziali al 95% utilizzano la correzione CUPED. Entrambe le riduzioni sono statisticamente significative. I tassi MID+ calcolano le probabilità medieimate di insoddisfazione media o alta sui thread di follow-up idonei valutati, non il conteggio dei reclami. I tassi di fallimento degli strumenti escludono le chiamate senza uno stato di successo o fallimento registrato.

L'idea centrale è imparare a livello di decisione, non solo di sessione.

Un risultato riuscito può nascondere gli errori e una sessione non riuscita può comunque rivelare come migliorare. Manteniamo il comportamento utile delle sessioni riuscite come àncora, utilizziamo reclami ed errori degli strumenti per identificare i fallimenti evitabili e addestriamo il modello verso le previsioni che compie quando tali errori e correzioni vengono resi espliciti. Il successo fornisce un comportamento da preservare; il fallimento fornisce una direzione per il miglioramento.

L'uso nel mondo reale rende questo approccio particolarmente utile. Gli utenti reali portano obiettivi, vincoli e flussi di lavoro difficili da anticipare in un ambiente sintetico. Le loro correzioni rivelano i requisiti che il modello ha mancato, mentre gli errori degli strumenti espongono le discrepanze tra ciò che il modello ha tentato e ciò che l'ambiente consente. Questi segnali integrano l'addestramento basato sui risultati: anziché chiederci solo se un task ha avuto successo, possiamo chiedere dove il modello ha sbagliato e quali informazioni avrebbero potuto aiutarlo a prendere una decisione migliore.

I limiti sono ugualmente importanti. I giudici possono sbagliare e correggere un turno non garantisce che l'intero compito abbia successo. L'obiettivo non è semplicemente un agente che si riprende dopo una correzione, bensì un agente che necessita di correzioni meno frequentemente.

BibTeX

@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}

Dai dati sintetici a quelli del mondo reale

Imitazione dei passaggi corretti, correzione di quelli errati

Un esempio: una sessione può insegnare entrambe le lezioni

Come funziona l'addestramento

Seleziona le sessioni, quindi giudica il risultato

Trovare gli errori dal feedback degli utenti

Trovare gli errori a partire dagli errori degli strumenti

Due passaggi in avanti

La funzione di loss

La loss CE

Loss KL

Loss combinata

Cosa mostrano le valutazioni

I suggerimenti possono allontanare il modello dagli errori

Feedback degli utenti

Errori degli strumenti

Affidabilità degli strumenti e feedback degli utenti dopo l'addestramento

Valutazione offline

Valutazione online: GLM-5.2

Valutazione online: GLM-5.3

Conclusione

Citazione