Introduzione
Perplexity ha pubblicato uno studio post‑training in cui il modello alla base, GLM 5.2, viene ulteriormente addestrato su sessioni utente reali, includendo anche quelle non riuscite. L’obiettivo è ridurre gli errori di chiamata a tool, migliorare la robustezza dell’agente e trasformare gli sbagli in segnali di apprendimento mediante hint‑guided self‑distillation (OPSD).
Perché il filtraggio basato solo sul risultato fallisce
Il tradizionale rejection sampling fine‑tuning (RFT) seleziona solo le sessioni con esito positivo, ignorando le traiettorie intermedie. Un risultato corretto non garantisce che ogni passo sia stato eseguito senza errori: l’agente può recuperare da una chiamata di tool errata e comunque fornire la risposta giusta. Imitare l’intera traiettoria “di successo” rischia di consolidare l’errore originale, mentre scartare le sessioni fallite elimina evidenze preziose su errori evitabili.
Approccio di Perplexity: imitazione, correzione e contesto
Il team ha introdotto due decisioni distinte: quali sessioni contengono comportamenti da imitare e quali turni contengono errori da correggere. Ogni turno dell’assistente riceve uno dei tre trattamenti seguenti:
- Imita: i turni privi di errore nelle sessioni riuscite ricevono una perdita di cross‑entropy (CE).
- Correggi: i turni con errore, accompagnati da un hint validato, ricevono una perdita di Kullback‑Leibler (KL).
- Mantieni come contesto: i turni residui rimangono nell’input ma non generano perdita.
Le sessioni riuscite forniscono sia target di imitazione sia di correzione, mentre le sessioni non riuscite forniscono solo target di correzione.
Come un hint diventa un segnale di training
Un hint è una breve istruzione correttiva basata su informazioni già note al modello. Ad esempio, una chiamata di ricerca con il parametro recency_filter impostato a “year” (valore non permesso) genera un hint che segnala l’errore, riporta il messaggio di validazione e suggerisce un valore ammissibile (es. “day”, “week”, “month”).
L’On‑Policy Self‑Distillation (OPSD) utilizza due passate del modello GLM 5.2 sullo stesso turno: la prima (teacher) vede l’hint, la seconda (student) no. Entrambe operano con teacher forcing, quindi non viene generata una risposta sostitutiva. Le probabilità dei token del teacher, staccate dal grafo, fungono da soft target per il student tramite KL forward.
La perdita complessiva è (CE + λ × KL) / N, dove N è il numero di token imitati. Con λ = 0 si ottiene il classico SFT; il termine CE resta fondamentale perché un addestramento basato solo sulla correzione potrebbe far convergere teacher e student ignorando il contesto.
Tracciamento degli errori reali
Il pipeline seleziona sessioni di “Computer” eleggibili per il training servite da GLM 5.2, escludendo dati contenenti informazioni personali identificabili e utenti che hanno opt‑out. Un giudice LLM mantiene solo i compiti valutati 4 o 5 su una scala di difficoltà a 5 punti; due giudici devono approvare la consegna finale per considerare una sessione riuscita.
Per il feedback degli utenti, tre giudici LLM identificano il turno responsabile; almeno due devono concordare. Questo è cruciale perché il turno finale prima di un reclamo è la causa radice solo circa la metà delle volte. Ogni hint viene verificato rispetto alle informazioni disponibili prima dell’errore, riducendo il bias retrospettivo.
Esempio: un utente chiede il proprio “w3” su Paychex; il modello interpreta erroneamente “W‑2” e cerca il modulo sbagliato. L’hint punta all’interpretazione errata, non solo alla risposta finale.
Valutazioni e risultati preliminari
Effetto degli hint prima del training: su 985 turni con errore di tool tenuti da parte, il modello base, senza modifica, evitava il fallimento originale nel 93,7 % dei casi con hint, rispetto al 75,1 % senza hint. La percentuale di azioni corrette è passata dal 60,6 % all’82,3 %.
Riduzione degli errori offline: i tassi di errore di tool registrati erano 2,79 % per il GLM 5.2 stock, 1,35 % per RFT solo, e 0,87 % per il checkpoint RFT + OPSD. Si segnala che i dati di training differivano, quindi non è un confronto ablation perfettamente allineato.
Risultati live (A/B test): ogni condizione ha coinvolto circa 100 000 utenti. Un confronto tra un