Învățarea din experiența din lumea reală

Modul în care utilizatorii interacționează cu produsele noastre în lumea reală este o sursă valoroasă pentru antrenamentul modelului. Datele sunt abundente, reflectă distribuția reală a sarcinilor utilizatorilor și surprind corecțiile utilizatorilor și erorile de tool pe care mediile sintetice le pot rata.

O modalitate comună de a învăța din datele din lumea reală este reglarea fină prin eșantionare cu respingere: se evaluează rezultatul fiecărei sesiuni, se păstrează cele cu succes și se antrenează modelul să le imite. Dar un rezultat de succes nu înseamnă că fiecare pas a fost corect, astfel încât imitarea întregii traiectorii riscă să consolideze comportamentele intermediare rele pe lângă cele bune. De asemenea, eliminarea sesiunilor eșuate pierde dovezi critice despre locul în care modelul dă greș.

Combinăm fine-tuningul prin eșantionare cu respingere cu auto-distilarea ghidată de indicii pentru a învăța atât din sesiunile de succes, cât și din cele eșuate. Un indiciu este o scurtă instrucțiune corectivă bazată pe informații pe care modelul le avea deja atunci când a comis greșeala. Pașii utili din sesiunile reușite rămân ținte de imitare, în timp ce indiciile fundamentate transformă greșelile evitabile în ținte de corectare.

Corecțiile utilizatorilor și erorile de tool adaugă o supervizare suplimentară despre ce a mers prost pe parcurs, pe lângă faptul că sarcina a reușit sau nu în cele din urmă. Aplicăm această etapă după învățarea prin întărire în medii sintetice pentru a ajuta la reducerea decalajului dintre acele medii și utilizarea în lumea reală.

În utilizarea în direct, un punct de control GLM-5.2 antrenat ulterior a redus eșecurile apelurilor de unelte cu 21,2% față de un punct de control antrenat anterior. Pentru GLM-5.3, post-antrenamentul a redus eșecurile apelurilor de unelte cu 33,0% și probabilitatea medie estimată de nemulțumire medie sau ridicată a utilizatorilor cu 17,2% față de modelul standard.

Sarcinile sintetice ne permit să creăm probleme controlate cu rezultate ușor de verificat, dar de obicei sunt limitate la un singur prompt și pot acoperi doar scenariile pe care le concepem în mod explicit.

În schimb, utilizatorii din sesiunile din lumea reală aduc instrucțiuni, context și combinații de tool-uri diverse în sesiuni care se desfășoară pe parcursul mai multor runde de interacțiune. O astfel de utilizare în lumea reală generează în mod natural două semnale valoroase ale greșelilor: corecțiile utilizatorilor dezvăluie unde agentul nu a livrat ceea ce și-au dorit, iar erorile de tool arată unde acțiunile sale au eșuat în medii reale. Conducta noastră de eșantionare respectă confidențialitatea utilizatorilor și opțiunile de antrenament prin excluderea sesiunilor cu informații de identificare personală (PII) și de la utilizatorii care au optat pentru excludere.

Prin urmare, datele din lumea reală ne oferă cazuri de eșec pe care un mediu sintetic s-ar putea să nu le expună și vin adesea cu locul unde a avut loc eșecul deja inclus.

La antrenamentul pe date din lumea reală, reglarea fină standard prin eșantionare cu respingere (RFT) selectează sesiunile cu succes pe baza rezultatelor lor finale, fără a utiliza în mod explicit feedbackul de la utilizator și de la tool-uri pentru a distinge acțiunile intermediare bune de cele rele. Un agent poate își poate reveni dintr-un apel de tool greșit sau poate corecta o greșeală după feedbackul utilizatorului și totuși poate oferi ieșirea corectă la sfârșit.

Eliminarea sesiunilor eșuate limitează, de asemenea, eficiența eșantionului. O sesiune care nu ajunge niciodată la un rezultat bun ar putea dezvălui totuși o greșeală clară și evitati-bilă ca semnale utile de antrenament.

Abordăm aceste limitări separând două decizii: ce sesiuni conțin un comportament care merită imitat și ce runde conțin greșeli care merită corectate. Conducta de date ia aceste decizii separat, apoi atribuie rundelor de model unul dintre cele trei tratamente:

Imită: rundele care nu sunt erori din sesiunile cu succes primesc pierdere obișnuită prin entropie încrucișată (CE), crescând probabilitatea tokenurilor înregistrate.
Corect: atât în sesiunile cu succes, cât și în cele eșuate, rundele de eroare cu un indiciu valid primesc o pierdere prin divergență Kullback–Leibler (KL), direcționând modelul către predicțiile pentru următorul token pe care le face atunci când vede indiciul.
Păstrează ca context: rundele din sesiunile eșuate cărora le lipsește un indiciu validat și rundele marcate ca fiind greșite fără un indiciu validat în niciun tip de sesiune, servesc drept context, dar nu primesc nicio pierdere.

Ca rezultat, sesiunile cu succes pot furniza atât ținte de imitație, cât și de corecție, în timp ce sesiunile eșuate furnizează doar ținte de corecție. Toate rundele rămase, inclusiv ieșirea de sistem, de utilizator și de tool, rămân ca context.

Diagrama de rutare a sesiunii: sesiunile de succes oferă imitație CE și corecții indicate eligibile; sesiunile eșuate oferă doar corecții eligibile. — Rutarea curentă a sesiunii și măștile pentru conținutul asistentului. Sesiunile cu succes contribuie cu ținte de imitație; înregistrările de feedback reținute pot contribui cu corecții indicate chiar și atunci când sesiunea nu are succes. Celălalt conținut rămâne ca context. Sesiunile incomplete sunt excluse. Excepția CE nefinală pentru yield/stop-token nu este trasată, iar această diagramă nu stabilește amestecul folosit de un punct de control anterior.

Partea de imitație folosește RFT standard. Partea corectivă folosește On-Policy Self-Distillation (OPSD): același model acționează ca profesor și elev, profesorului fiindu-i furnizate informații privilegiate. Aici, acele informații privilegiate sunt un scurt indiciu care explică o greșeală evitabilă. Antrenăm elevul să se potrivească cu predicțiile următorului token ale profesorului fără să i se dea indiciul.

Ambele părți contează. Antrenamentul bazat exclusiv pe corecții poate expune o scurtătură: profesorul și elevul pot cădea de acord ignorând contextul în loc să învețe corecția. Termenul CE ancorează antrenamentul la un comportament util, ajutând la descurajarea acordului care provine din ignorarea contextului.

Elevul post-antrenat devine apoi o opțiune de model în Computer. Sesiunile noi din utilizarea live trec prin aceleași filtre de eligibilitate și confidențialitate înainte de a intra într-o altă rundă a conductei de antrenament.

În continuare, trecem prin exemplul concret care conține atât imitație, cât și corecție.

Luați în considerare o sesiune cu succes final în care utilizatorul solicită o comparație a modificărilor asyncio în Python 3.13 folosind documentația oficială. Documentația noastră de tool afirmă că search.web returnează o listă de rezultate, fiecare având un câmp url.

Modelul rulează mai întâi o căutare validă pentru o versiune ca parte a strângerii de dovezi pentru comparație, ceea ce reprezintă un comportament bun de imitat.

Cu toate acestea, următorul apel de execuție a codului tratează în mod incorect acea listă ca pe un dicționar. Tool-ul de cod returnează TypeError: list indices must be integers or slices, not str. Deoarece tipul returnat a fost documentat înainte de apel, este o greșeală pe care modelul ar fi trebuit să o poată evita. Se poate genera un indiciu cu apelul corect pentru a corecta acea acțiune.

Sesiune de codificare ilustrativă: intrările de sistem și de utilizator și erorile de tool rămân context; căutările și apelurile de recuperare înregistrate utile primesc CE într-o sesiune cu succes; o căutare marcată cu eroare în listă primește KL către un profesor căruia i s-a dat un indiciu ancorat. — O sesiune de codificare ilustrativă arată trei roluri de antrenament: intrări exclusiv ca context și ieșiri de tool (gri), imitație CE a apelurilor înregistrate utile (închis) și corecție KL a unei greșeli marcate (turcoaz). Aici, modelul tratează în mod incorect o listă de rezultate de căutare ca pe un dicționar; un indiciu exclusiv pentru profesor ancorat în documentația anterioară a tool-ului ghidează corecția. Țintele CE se aplică numai atunci când sesiunea finalizată este considerată un succes, în timp ce o sesiune eșuată poate furniza în continuare o țintă de corecție KL eligibilă.

Conducta de antrenament are patru etape: selectarea sesiunilor și evaluarea rezultatelor lor, identificarea greșelilor și crearea de indicii din feedbackul utilizatorilor și erorile de tool, generarea probabilităților pentru următorul token atât de la profesor, cât și de la elev, și antrenarea modelului cu o pierdere combinată CE și KL.

Lanțul de eșantionare extrage dintr-un subset eligibil pentru antrenare de sesiuni Computer din lumea reală, servite de GLM 5.2. Excluderile de tip opt-out pentru antrenare și cele legate de PII ale lanțului sunt aplicate înainte de selectarea exemplelor pentru acest flux de lucru.

Procesul de screening inițial selectează candidații evaluați cu 4 sau 5 pe o scară de dificultate a sarcinilor în cinci puncte de către un judecător LLM și îi împarte în 2 grupe:

Grupul de feedback al utilizatorului conține sesiuni cu o continuare genuină din partea utilizatorului sau un indicator de nemulțumire de la mediu la ridicat. Găsim aceste urmăriri cu intenție ridicată deosebit de utile pentru învățare: utilizatorii încearcă în mod activ să ducă la bun sfârșit o sarcină, iar corecțiile lor indică exact ceea ce a ratat modelul.
Grupul de erori de tool conține sesiuni cu apeluri eșuate semnalate de verificări bazate pe reguli, excluzând defecțiunile de infrastructură recunoscute și autorizarea refuzată.

Două modele de evaluare LLM evaluează apoi livrarea finală în raport cu solicitarea utilizatorului; ambii judecători trebuie să returneze un verdict pozitiv pentru a eticheta o sesiune drept „cu succes”. Pentru cazurile care livrează artefacte, etapa de rezultat poate reconstrui și inspecta livrarea, revenind la judecățile bazate pe text dacă etapa respectivă eșuează. Sesiunile clasificate drept incomplete, cum ar fi lucrul care așteaptă după utilizator, sunt excluse.

Acest pas identifică sursele potențiale de semnale de învățare; totuși, nu orice eroare este atribuibilă modelului, deoarece unele decurg din instrucțiuni ambigue sau defecțiuni ale infrastructurii. Adnotarea ulterioară determină care greșeli candidate sunt efectiv evitabile și potrivite pentru antrenament.

Luați în considerare o sesiune eșantion din grupul de feedback al utilizatorului, în care utilizatorul întreabă: „How do I find my w3 on paychex”. Modelul tratează „w3” ca pe o greșeală de scriere pentru W-2, caută instrucțiuni pentru W-2 și explică cum se găsește formularul respectiv. Urmărirea din partea utilizatorului, „I meant the W-3 transmittal form,” identifică greșeala, chiar dacă sesiunea reușește în cele din urmă.

Plângerea ajută la localizarea greșelii, dar cauza principală este decizia anterioară de a reinterpreta „w3” ca W-2. Solicitarea originală face greșeala evitabilă: modelul ar fi putut păstra W-3 sau ar fi putut cere clarificări. Se dovedește că ultima rundă a asistentului dinaintea plângerii este cauza principală doar în aproximativ jumătate din cazuri.

Conducta noastră de adnotare mapează cauza și efectul în mod sistematic în cadrul fiecărei sesiuni de feedback din partea utilizatorului. Evaluatorul filtrează mai întâi pentru o cerință ratată sau o intenție susținută de contextul anterior. Trei judecători LLM identifică apoi rundele responsabile, necesitând ca cel puțin doi să fie de acord cu privire la o anumită rundă. Uneori, o declarație anterioară stabilește în mod explicit cerința. În alte cazuri, nicio declarație prioritară unică nu face acest lucru, dar mai multe părți din conversația precedentă fac în mod comun inferabil comportamentul intenționat. Acest design le permite să conecteze o plângere la o greșeală de bază anterioară în loc să o atribuie exclusiv ultimului răspuns.

Înainte de a accepta un indiciu, conducta verifică, de asemenea, dacă pretențiile sale corective decurg din informațiile disponibile înainte de runda marcată. Aceste verificări sunt menite să reducă biasul de retrospecție, unde o nouă preferință dezvăluită în plângere este tratată ca ceva ce modelul ar fi trebuit să știe deja.

În acest exemplu, indiciul îi spune modelului să caute formularul de transmitere W-3 pe Paychex în loc de W-2, sau să întrebe ce formular intenționează utilizatorul dacă solicitarea este ambiguă. Corecția vizează interpretarea anterioară și decizia de căutare, nu doar răspunsul final. Runda originală rămâne neschimbată; adnotarea adaugă is_bad_turn: true și un hint nevid.

O cerere W-3 este interpretată greșit ca W-2; o plângere ulterioară este urmărită până la decizia de căutare anterioară și verificată în raport cu dovezile anterioare. — O sesiune reală care arată cum o plângere este urmărită înapoi la o greșeală anterioară, cu procedura de adnotare suprapusă. Utilizatorul a cerut „w3” pe Paychex, dar modelul l-a tratat ca pe o greșeală de scriere pentru W-2 și a căutat formularul greșit. Consensul propunerii localizează cauza principală, în timp ce două verificări de ancorare evaluează dacă dovezile preatează greșeala și pretențiile indiciului decurg din informațiile disponibile în acel moment. Adnotările acceptate păstrează textul original și adaugă marcaje și indicii, în loc de ținte rescrise.

Luați în considerare o altă sesiune din grupul de erori de tool cu un apel de căutare în care agentul caută cu recency_filter: "year", dar tool-ul îl respinge deoarece valorile permise sunt „day”, „week” sau „month”. Aceasta este o încălcare clară a schemei.

Calea erorii de tool utilizează reguli deterministe pentru greșelile cunoscute și judecata modelului pentru cazurile ambigue. Doar un mesaj de eroare nu este suficient nici pentru a blama modelul; o corecție evaluată trebuie să indice ceva ce modelul ar fi putut ști din schema tool-ului, instrucțiunile de sistem sau conversația anterioară.

Un apel de căutare folosește valoarea invalidă recency_filter year; un indiciu ancorat instruiește modelul să folosească o valoare din listă sau să omită un câmp opțional. — Argumentul de căutare invalid din raport ilustrează procedura curentă pentru erorile de tool. Schema face această greșeală evitabilă; o întrerupere singură nu ar face-o. Apelul original rămâne în înregistrare și primește un indiciu ancorat. Indiciul permite o valoare listată sau omisiunea dacă câmpul este opțional; nu impune „month” pentru fiecare cerere.

Aici, indiciul numește apelul eșuat, include erorile de validare și instruiește modelul să folosească o valoare permisă sau să omită câmpul dacă este opțional.

Odată ce o interacțiune este marcată, antrenorul rulează același punct de control de două ori: o dată în rolul de profesor și o dată în cel de elev. Profesorul vede indiciul, elevul nu.

Ambele treceri utilizează ghidarea profesorului (teacher forcing), unde alimentăm modelul cu sesiunea înregistrată în loc să îl lăsăm să aleagă tokenuri noi. Trecerea înainte produce în continuare o distribuție completă a următorului token la fiecare pas, dar este întotdeauna condiționată de prefixul fix din înregistrare, nu de tokenurile de rulare.

Pentru exemplul de căutare, același model atribuie o probabilitate mult mai mare pentru „month” și mai mică pentru „year” atunci când primește indiciul. Antrenamentul folosește această deplasare distribuițională ca țintă flexibilă.

Același model punctează o rundă înregistrată cu și fără indiciu; probabilitățile profesorului detașat furnizează ținte KL în timp ce CE ancorează imitația. — Două treceri, un singur set de ponderi. Ambele treceri punctează continuarea înregistrată; doar profesorul primește indicii. Probabilitățile sale detașate pentru următorul token ghidează elevul prin KL înainte. Țintele CE separate ancorează imitația. Ambele pierderi alimentează o singură actualizare a ponderilor. Indiciile anterioare pot rămâne în segmentul curent al profesorului; nicio trecere nu generează un răspuns de antrenament de înlocuire.

Predicțiile profesorului sunt detașate sau cu gradient oprit: ele furnizează o țintă, dar nu primesc o actualizare prin trecerea profesorului. După trecerea elevului, un pas de optimizare actualizează modelul partajat.

Pierderea CE tratează tokenurile înregistrate selectate pentru imitație ca ținte de adevăr absolut și penalizează modelul pentru atribuirea unor probabilități scăzute acestora. Acest lucru creează o țintă de imitație rigidă.

La poziția de token $i$ , fie $p_i(v)$ probabilitatea elevului pentru tokenul $v$ din vocabularul complet $V$ . Următorul token înregistrat din răspuns sau apelul de tool este $y_i$ , distribuția țintă one-hot este $r_i$ .

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

Entropia încrucișată măsoară cât de bine prezice elevul acel token înregistrat. Cu o țintă one-hot, se reduce la log-probabilitatea negativă atribuită lui $y_i$ .

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

Masca CE $m_i^{\mathrm{CE}}$ este $1$ acolo unde tokenul ar trebui imitat și $0$ în caz contrar. Însumarea peste pozițiile selectate oferă pierderea de imitație.

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

Pierderea KL folosește în schimb distribuția completă de probabilitate a următorului token al profesorului $q_i$ ca țintă de corecție flexibilă. Contextul profesorului include indiciul curent și orice indicii anterioare reținute în acel segment de antrenament; contextul elevului este întotdeauna fără indicii.

Masca KL $m_i^{\mathrm{KL}}$ este $1$ acolo unde tokenul ar trebui corectat și $0$ în caz contrar; măștile CE și KL nu se suprapun. În aceste poziții, KL înainte penalizează dezacordul dintre profesor și elev în întregul vocabular:

\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)}

Ambilor termeni le corespunde un singur numitor în loc să fie normalizați separat. Acest numitor numără tokenurile totale selectate pentru imitație în întregul lot de antrenament global. Ponderarea $\lambda$ controlează contribuția antrenamentului corectiv în raport cu imitația.

Această normalizare partajată se potrivește cu interfața cu un singur numitor a infrastructurii noastre de antrenament și recuperează pierderea SFT standard atunci când $\lambda=0$ , simplificând comparațiile de bază. Deoarece tokenurile CE sunt mult mai abundente decât tokenurile KL, utilizarea unui numitor partajat evită, de asemenea, acordarea unor ponderi disproporționat de mari tokenurilor KL individuale în loturi cu puține tokenuri marcate.

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

Aplicat exemplelor anterioare, rundele care conțin combinația W-3/W-2 și apelul de căutare invalid primesc KL. Alt conținut neetasat al asistentului dintr-o sesiune cu succes primește în continuare CE. Celălalt conținut al asistentului dintr-o sesiune eșuată este reținut ca context, dar nu primește nici CE, nici KL.

Evaluările noastre răspund la două întrebări separate. În primul rând, ajută un indiciu efectiv modelul să corecteze o eroare atunci când indiciul este prezent? În al doilea rând, ajută antrenamentul modelul să evite acea eroare mai târziu, fără indiciu? Prima testează dacă indiciile furnizează semnale utile de antrenament. A doua testează dacă modelul învață din ele.

Testăm prima întrebare înainte ca antrenamentul să ruleze pentru a ne asigura că indiciile pot într-adevăr îndepărta modelul de greșeli.

Am regenerat rundele de feedback marcate de la utilizator cu și fără indiciu, folosind același model de bază GLM-5.2 la temperatura zero. Un judecător orb vede plângerea ulterioară, dar nici indiciul și nici starea care a produs răspunsul.

În exemplul W-3, indiciul deplasează probabilitatea următorului token spre „3” și departe de „2” după prefixul „W-”.

Probabilitățile pentru următorul token după W- se deplasează spre 3, mai degrabă decât spre 2, atunci când modelul de bază neschimbat primește un indiciu. — Un indiciu păstrează formularul W-3 solicitat. Barele arată probabilitățile medii ale următorului token în opt treceri înainte; liniile indică intervalul observat, nu un interval de încredere. Ambele condiții utilizează modelul de bază neschimbat.

Pe un eșantion reținut mai mare de 40 de runde, susținut de dovezi anterioare declarate în mod explicit, ponderea considerată remediată sau pe drumul cel bun crește de la 40,0% fără indiciu la 75,0% cu unul. Pe alte 40 de runde susținute de intenția inferată, aceasta crește de la 32,5% la 80,0%.

Validarea indiciilor: ratele de remediere sau pe drumul cel bun cresc de la 40,0% la 75,0% pentru dovezile explicite și de la 32,5% la 80,0% pentru intenția inferată. — Validarea indiciilor, nu evaluarea post-antrenament. Aceleași 40 de runde marcate din fiecare grup de dovezi sunt regenerate cu și fără indiciu folosind GLM-5.2 neschimbat la temperatura zero. Judecătorul vede plângerea, dar nu și indiciul sau starea. Numătorii sunt derivați din ratele raportului și dimensiunile eșantionului; intervalele de încredere nu sunt raportate.

În exemplul de eroare a tool-ului de căutare, un indiciu transferă într-adevăr masa de probabilitate de la tokenul year la tokenul month.

Un indiciu schimbă probabilitățile următorului token ale modelului de bază neschimbat departe de year și spre valoarea permisă month. — Un indiciu deplasează probabilitatea către o valoare permisă. Barele arată probabilitățile medii ale următorului token în opt treceri înainte; liniile indică intervalul observat, nu un interval de încredere. Ambele condiții utilizează același model de bază; nu se compară niciun punct de control antrenat.

Pe un eșantion reținut mai mare de 985 de runde, regenerăm fiecare rundă de patru ori cu și fără indiciu, folosind același model de bază la temperatura zero. Un judecător orb evaluează dacă fiecare regenerare evită eșecul inițial. Indiciile cresc evitarea eșecurilor de la 75,1% la 93,7%, un câștig împerecheat de 18,6 puncte procentuale, și cresc ponderea acțiunilor corectate de la 60,6% la 82,3%. Câștigurile sunt cele mai mari la erorile pe care simpla eșantionare repetată cu greu le poate remedia.

Pe 985 de runde de eroare de tool marcate și reținute, indiciile cresc evitarea eșecurilor de la 75,1% la 93,7% și ratele acțiunilor corectate de la 60,6% la 82,3%. — Validarea indiciilor pentru erorile de tool pe 985 de runde reținute marcate, cu patru regenerări per condiție. Barele arată evitarea eșecurilor și ratele acțiunilor corectate pentru modelul de bază neschimbat, cu și fără indicii. Evitarea greșelii vizate nu stabilește succesul apelului de tool sau al Sarcinii.

Apoi testăm dacă modelul antrenat face mai puține greșeli fără să primească indicii. Evaluăm modelul standard și diverse checkpointuri post-antrenare pe sarcini de benchmark offline și în sesiuni live cu utilizatori, urmărind mai puține eșecuri ale instrumentelor și o nemulțumire mai redusă a utilizatorilor.

Evaluarea offline folosește BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, un set reprezentativ de sarcini Computer și verifică încărcarea de Skill, revizuirea documentelor și citările în text. Măsurăm ponderea apelurilor de tool ale căror rezultate sunt marcate în mod explicit ca erori pe parcursul traiectoriilor de evaluare.

În aceste evaluări, rata erorilor de tool înregistrate a fost de 2,79% pentru GLM 5.2 standard, 1,35% pentru punctul de control exclusiv RFT și 0,87% pentru un punct de control RFT-plus-OPSD. Aceste puncte de control au fost antrenate pe date diferite, deci aceasta nu este o ablație pe date comparabile a OPSD. Rezultatele benchmark-ului la nivel de sarcină au fost mixte, deci mai puține erori de tool singure nu se traduc neapărat într-o îmbunătățire largă a succesului sarcinii.

Ratele erorilor de tool înregistrate offline: 2,79% pentru GLM 5.2 standard, 1,35% pentru RFT exclusiv și 0,87% pentru RFT plus OPSD; datele de antrenament difere. — Ratele erorilor de tool offline pentru punctele de control GLM-5.2 standard, RFT exclusiv și RFT-plus-OPSD. Datele de antrenament diferă între punctele de control; aceasta nu este o ablație cu date controlate.

Pentru GLM-5.2, am rulat două teste A/B separate cu aproximativ o sută de mii de utilizatori în fiecare condiție. În primul, un punct de control RFT-plus-OPSD timpuriu a avut o rată de eșec a tool-urilor ușor mai mică decât GLM 5.2 standard, 2,82% comparativ cu 2,94%, însă diferența nu a fost statistic semnificativă.

În testul ulterior, am comparat două puncte de control RFT-plus-OPSD: unul anterior (punctul de control unu) și unul posterior (punctul de control doi). Eșecurile de apel de tool au scăzut de la 2,24% la 1,77% din apelurile cu o stare înregistrată. Aceasta a fost o reducere relativă de 21,2%, semnificativă statistic. Nu am comparat direct punctul de control doi cu GLM 5.2 standard online.

Rezultatele privind feedbackul utilizatorilor au fost mai puțin concludente. În al doilea experiment cu GLM-5.2, probabilitatea medie de insatisfacție puternică (medie sau ridicată) a fost de 2,58% pentru primul punct de control și de 2,54% pentru al doilea, fără nicio diferență statistic semnificativă.

Două teste A/B online separate; doar comparația ulterioară a punctelor de control are o reducere semnificativă a eșecurilor de tool, fără nicio modificare semnificativă a nemulțumirii MID+. — Două teste A/B live separate cu GLM-5.2. Punctul de control 1 este comparat cu GLM-5.2 standard; punctul de control 2 este comparat cu punctul de control 1. În cadrul acestei testări duble, doar reducerea ulterioară a eșecurilor de tool este statistic semnificativă. Ratele MID+ reprezintă probabilități medii estimate de insatisfacție medie sau ridicată, nu numărul de plângeri.

Pentru GLM-5.3, am comparat un punct de control antrenat ulterior direct cu modelul standard GLM-5.3. Eșecurile apelurilor de unelte au scăzut de la 3,56% la 2,38% din apelurile cu o stare înregistrată, o reducere relativă de 33,04%. Rata MID+, probabilitatea medie estimată de nemulțumire medie sau ridicată, a scăzut de la 4,12% la 3,41%, o reducere relativă de 17,2%. Ambele reduceri au fost semnificative statistic.

Test A/B GLM-5.3: rata eșecurilor de unelte scade de la 3,56% la 2,38%, iar rata MID+, probabilitatea medie estimată de nemulțumire medie sau ridicată, scade de la 4,12% la 3,41%. Reducerile relative ajustate prin CUPED sunt de 33,04% și, respectiv, 17,16%. Ambele intervale secvențiale de 95% exclud zero; metrica principală de implicare nu este semnificativă. — GLM-5.3 antrenat ulterior comparat cu GLM-5.3 standard într-un test A/B online separat. Ratele eșecurilor de unelte și MID+, modificările relative și intervalele de încredere secvențiale de 95% utilizează ajustarea CUPED. Ambele reduceri sunt semnificative statistic. Ratele MID+ reprezintă probabilitățile medii estimate de nemulțumire medie sau ridicată pe firele de discuție eligibile evaluate, nu numărul de reclamații. Ratele eșecurilor de unelte exclud apelurile fără o stare de succes sau eșec înregistrată.

Ideea centrală este de a învăța la nivelul deciziei, nu doar al sesiunii.

Un rezultat de succes poate ascunde greșeli, iar o sesiune eșuate poate dezvălui totuși cum se poate îmbunătăți. Păstrăm comportamentul util din sesiunile cu succes ca punct de ancorare, folosim plângerile și erorile de tool pentru a identifica eșecurile evitabile și antrenăm modelul spre predicțiile pe care le face atunci când acele greșeli și corecții sunt făcute explicite. Succesul oferă un comportament de păstrat; eșecul oferă o direcție pentru îmbunătățire.

Utilizarea în lumea reală face ca această abordare să fie deosebit de utilă. Utilizatorii reali aduc obiective, constrângeri și fluxuri de lucru care sunt greu de anticipat într-un mediu sintetic. Corecțiile lor dezvăluie cerințe pe care modelul le-a ratat, în timp ce erorile de tool expun discrepanțele dintre ceea ce a încercat modelul și ceea ce permite mediul. Aceste semnale completează antrenamentul bazat pe rezultate: în loc să întrebăm doar dacă o sarcină a reușit, putem întreba unde a greșit modelul și ce informații l-ar fi putut ajuta să ia o decizie mai bună.

Limitele sunt la fel de importante. Evaluatorii pot greși, iar corectarea unei singure interacțiuni nu garantează succesul întregii sarcini. Scopul nu este doar crearea unui agent care își revine după o corectare, ci a unui agent care are nevoie de corectare din ce în ce mai rar.

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}
}

De la date sintetice la date din lumea reală

Imită pașii buni, corectează-i pe cei răi

Un exemplu: o sesiune poate preda ambele lecții

Cum funcționează antrenamentul

Selectați sesiunile, apoi evaluați rezultatul

Găsirea greșelilor din feedbackul utilizatorului

Găsirea greșelilor din erorile de tool

Două treceri înainte

Funcția de pierdere

Pierderea CE

Pierderea KL

Pierdere combinată

Ce arată evaluările

Indiciile pot îndepărta modelul de greșeli

Feedback de la utilizator

Erori de tool

Fiabilitatea tool-urilor și feedbackul utilizatorilor după antrenament

Evaluare offline

Evaluare online: GLM-5.2

Evaluare online: GLM-5.3

Concluzie

Citare