Prezicerea comportamentului modelului înainte de lansare prin simularea implementării
Folosirea contextelor realiste de conversație pentru estimarea mai bună a comportamentului nedorit al modelului înainte de lansare.
Înainte de a lansa un model nou, laboratoarele trebuie să înțeleagă nu doar ce poate face acesta, ci și cum este probabil să se comporte în utilizarea din lumea reală, inclusiv unde ar putea introduce riscuri noi. Acest lucru devine și mai important pe măsură ce capabilitățile cresc. Ca parte a revizuirii noastre de siguranță înainte de implementare, folosim evaluări țintite, red-teaming și alte verificări pentru a înțelege comportamentul modelului. Am început acum să folosim o metodă de simulare a implementărilor de modele înainte ca acestea să aibă loc, care adaugă un semnal complementar: o previzualizare asemănătoare implementării a modului în care se poate comporta un model candidat înainte de a ajunge la utilizatori.
Simularea implementării este o metodă de simulare a unei implementări viitoare înainte ca aceasta să aibă loc. Facem acest lucru reluând conversații anterioare într-un mod care protejează confidențialitatea, cu un nou model candidat. Acest lucru ne permite să studiem cum răspunde noul model în contexte realiste înainte de lansare, inclusiv dacă apar comportamente nedorite noi și cât de des pot apărea.
În mai multe implementări Thinking din seria GPT‑5, Simularea implementării ne-a îmbunătățit estimările ratelor de comportament nedorit al modelului, a ajutat la evidențierea unor forme noi de nealiniere înainte de lansare și a contribuit la reducerea riscului ca modelele să își poată da seama că sunt testate. Am aplicat metoda și unor lansări agentive dificile, arătând că se poate extinde dincolo de chatul standard la setări de agent mai complexe care implică utilizarea de instrumente și că poate fi folosită și pentru evaluarea riscurilor înainte de implementările interne de modele.
Am folosit deja informații din Simularea implementării în timpul dezvoltării modelului pentru a identifica puncte oarbe în evaluările tradiționale și pentru a ghida măsurile de atenuare și deciziile de implementare. Pe măsură ce facem pipeline-ul mai ușor de rulat, ne așteptăm ca acesta să joace un rol mai mare în procesul viitor de dezvoltare a modelelor.
Evaluările înainte de implementare folosite în industrie constau, în general, dintr-un amestec de solicitări sintetice, scrise manual sau de producție, selectate intenționat pentru a fi dificile, cu severitate ridicată sau adversariale. Aceste evaluări au avut, în general, două obiective interconectate: evaluarea modului în care răspunde modelul când este supus testelor de stres în situații cu șanse foarte mici de a apărea în traficul de implementare și obținerea unei înțelegeri generale a comportamentelor nedorite ale modelului, inclusiv găsirea unor comportamente nedorite noi și prezicerea frecvențelor lor la momentul implementării.
Deși evaluările tradiționale rămân esențiale pentru primul obiectiv, Simularea implementării reprezintă un pas semnificativ înainte în privința celui de-al doilea obiectiv pentru riscurile care nu sunt de coadă lungă (în experimentele noastre, nu ne putem aștepta ca abordarea noastră să măsoare comportamente care apar cu o frecvență mai mică de 1 la 200.000 de mesaje). Forța Simulării implementării vine din evitarea unor provocări centrale ale evaluărilor tradiționale:
- Acoperire: este dificil să avem încredere că solicitările de evaluare vor acoperi toate tipurile posibile de comportament nedorit al modelului. Măsurarea unor tipuri noi de comportament nedorit necesită crearea de evaluări noi și cunoașterea daunelor care trebuie măsurate. Acest lucru poate necesita mult timp și muncă, iar evaluările se pot satura în timp.
- Biasuri de selecție: evaluările tradiționale sunt, în general, construite având în vedere comportamente nedorite specifice ale modelului, selectate în moduri care favorizează contexte ce au apărut anterior. Acest lucru poate face estimările lor mai puțin informative despre incidența acestor comportamente pe întreaga amploare a distribuției de implementare.
- Recunoașterea ca teste de către modele: modelele au devenit tot mai capabile să determine că sunt testate, ceea ce le poate distorsiona comportamentul și măsurătorile noastre ulterioare privind siguranța lor. Deși multe dintre evaluările tradiționale pe care le folosim la OpenAI sunt, de asemenea, extrase din traficul de producție și nu suferă de această problemă, aceasta este o preocupare comună pentru multe evaluări tradiționale folosite în industrie.
Tehnica principală din spatele Simulării implementării este simplă: luăm conversații recente din implementare, eliminăm răspunsul inițial al asistentului din modelul mai vechi și îl regenerăm cu un model candidat care urmează să fie lansat. Evaluăm completările căutând noi moduri de eșec și estimăm frecvența comportamentului nedorit la momentul implementării pe baza frecvenței din această distribuție asemănătoare implementării. Putem efectua aceleași măsurători după lansare pe traficul real de implementare, ceea ce ne permite să ne validăm prognozele înainte de implementare.
Simularea implementării atenuează semnificativ cele trei limitări enumerate mai sus: biasul de eșantionare este abordat folosind o distribuție de solicitări de evaluare reprezentativă pentru utilizarea recentă. Simularea implementării cu solicitări reprezentative poate atenua și preocupările privind acoperirea: obținem o acoperire mai mare a comportamentelor nedorite ale modelului prin simpla simulare a unui volum mai mare de trafic. Acest compromis între calcul și acoperire este important, deoarece face ca nivelul de calitate al acestei axe de evaluare a riscului să se scaleze odată cu calculul, nu cu efortul manual necesar pentru a construi mai multe evaluări. Modelele nu par nici să poată distinge între conversațiile obținute prin simularea implementării și traficul real de implementare.
Figura 1: prezentare generală a pipeline-ului nostru de Simulare a implementării
Domeniu | Evaluări tradiționale | Simularea implementării |
Acoperire | Mai bună pentru riscuri cu prevalență scăzută, dar severitate ridicată, pentru care vrem să ne asigurăm că avem acoperire | Mai bună pentru înțelegerea spectrului de riscuri pe care este probabil să le vedem în traficul de implementare |
Reprezentativitate / bias | Axate pe evaluarea riscurilor țintite trecute sau prezise, chiar și pentru comportamente cu prevalență extrem de scăzută în implementare | Reprezentativă pentru riscurile care apar peste o anumită prevalență în traficul curent de implementare |
Conștientizarea evaluării | Indicii de test potențial evidente (de ex., cu date sintetice), cu excepția cazului în care evaluările sunt create cu date de implementare | Contextul asemănător implementării pare să atenueze semnificativ conștientizarea evaluării |
Efort | Distribuțiile și configurațiile personalizate de solicitări necesită mult mai mult efort manual | Necesită un cost unic de infrastructură, apoi reutilizează prefixe din implementare și evaluatori din comportamente nedorite cunoscute |
Comparație de nivel înalt între evaluările tradiționale și Simularea implementării
Pentru a evalua Simularea implementării, am preînregistrat predicții pentru frecvența la momentul implementării a 20 de tipuri de comportament nedorit pentru GPT‑5.4 Thinking. Am derulat și studii retrospective în alte implementări ale modelelor Thinking din seria GPT‑5. Comportamentele modelului pe care le analizăm acoperă atât nealinierea, cât și categoriile de conținut nepermis pe care le-am raportat în fișele de sistem (de ex., modelul minte despre instrumente sau produce conținut sexual nepermis). Deși pentru aceste rezultate urmărim doar 20 de categorii de comportament nedorit al modelului și căutăm doar comportamente nealiniate noi, Simularea implementării este o tehnică generală care ar putea fi aplicată pentru a simula orice proprietate a modelului la momentul implementării.
Traficul de producție pe care l-am folosit provenea tot de la modele Thinking din seria GPT‑5. Înainte de a rula evaluările, am eliminat automat identificatorii legați de cont și informațiile identificabile. În conformitate cu politica noastră de confidențialitate, am analizat doar traficul ChatGPT de la utilizatori care permit folosirea datelor lor pentru îmbunătățirea modelului. Raportăm doar constatări agregate din aceste evaluări. În total, am analizat aproximativ 1,3 milioane de conversații de-identificate în implementările de la GPT‑5 Thinking până la GPT‑5.4, acoperind perioada august 2025–martie 2026.
Evaluăm calitatea evaluării riscurilor înainte de implementare, produsă de Simularea implementării, în trei moduri principale:
- Acoperirea taxonomiei: auditarea post-lansare a scos la iveală comportamente nealiniate importante care lipseau din taxonomia noastră inițială a comportamentelor negative?
- Acuratețe direcțională: simularea a prezis corect dacă prevalența în implementare va crește sau va scădea pentru comportamente cunoscute?
- Calibrarea ratei: estimările noastre dinaintea implementării au fost apropiate de ratele pe care le-am observat ulterior în implementare? Obținerea unei calibrări bune a ratei necesită mai mult decât acuratețe direcțională, ceea ce face ca acesta să fie cel mai înalt standard de calitate posibil.
Măsurăm și cât de bine își pot da seama modelele că se află într-o evaluare în timpul Simulării implementării și testăm cât de robustă este metoda la diferite forme de trafic de implementare și la setări dificile de utilizare a instrumentelor.
În toate implementările modelelor de raționament din seria GPT‑5, Simularea implementării a depășit bazele de referință bazate pe prompturi dificile în determinarea ratei reale de risc, a reușit să evidențieze hackingul calculatorului înainte de lansare și a părut potențial imposibil de distins de implementarea reală pentru model.
Prezentare generală a predicțiilor noastre. Pentru o vizualizare a tuturor predicțiilor privind implementările modelelor de raționament din seria GPT‑5, consultă Figura 2. Predicțiile pentru GPT‑5.4 Thinking au fost preînregistrate, în timp ce celelalte au fost predicții retroactive. Per ansamblu, predicțiile noastre au avut o eroare multiplicativă mediană de 1,5x (de exemplu, dacă rata comportamentului nedorit este de 10 la 100.000, acest lucru ar corespunde unei estimări a ratei de 15 sau 6,67 la 100.000). Deși erorile de coadă ale metodei noastre pot fi de aproximativ 10x mai mari, ne așteptăm ca acestea să poată fi reduse semnificativ prin îmbunătățiri suplimentare ale pipeline-ului nostru de simulare, așa cum se discută mai jos.
Figura 2. Predicții ale frecvenței în Simularea implementării pentru comportamentul nedorit la momentul implementării, pe baza datelor din implementări anterioare. Notația 5.1 → 5 indică faptul că reeșantionăm prefixe din GPT‑5 cu GPT‑5.1, adică simulăm implementarea GPT‑5.1 pe baza datelor din GPT‑5. Cea mai mare rată a comportamentului nealiniat a fost „hackingul calculatorului” în GPT‑5.1, despre care am discutat anterior(se deschide într-o fereastră nouă).
Compararea predicțiilor Simulării implementării cu reperele. Cele mai importante categorii de estimat corect pentru evaluările riscului înainte de implementare sunt cele care au schimbări mari ale incidenței după implementarea modelului (de ex. >= 1,5x). Pe acest subset, Simularea implementării este substanțial mai bună decât reperele atât la prezicerea faptului că un anumit comportament nedorit va crește sau va scădea ca prevalență odată cu implementarea unui model (Figura 3, stânga), cât și la estimarea incidenței sale exacte la momentul implementării (Figura 3, dreapta). Folosim două repere principale: un reper Solicitări dificile, pe care îl folosim în prezent pentru fișele de sistem și deciziile de lansare, și un reper naiv care folosește ratele din implementarea anterioară ca estimări pentru noul model.
Figura 3. Simularea implementării prezice atât direcția schimbărilor de incidență (stânga), cât și ratele exacte de producție (dreapta) mai bine decât evaluările statice.
Surse ale erorii de simulare în pipeline-ul nostru. Am studiat și sursele actuale de eroare din pipeline-ul nostru. Mai precis, erorile mari de coadă fac pipeline-ul mai puțin demn de încredere pentru deciziile de implementare: de exemplu, când vedem o creștere mare prezisă a unui comportament nedorit de un anumit tip, dacă se știe că pipeline-ul are chiar și ocazional erori mari, acest lucru ridică îndoieli dacă estimarea este fiabilă sau un artefact al pipeline-ului. Există două surse principale de eroare posibilă:
- Eroare de fidelitate a mediului de reeșantionare: pentru a estima cu acuratețe ratele de producție, pipeline-ul nostru de simulare trebuie să fie cât mai realist posibil. Aceasta este parțial o problemă de inginerie (eșantionarea din model folosind aceleași pipeline-uri folosite pentru traficul de producție) și parțial o provocare interesantă pentru instrumentele care au nevoie de acces de citire/scriere la resurse externe aflate în schimbare constantă (de ex., căutări web sau interacțiuni cu fișiere locale). Putem izola eroarea de fidelitate a simulării comparând predicțiile dintr-o implementare reală cu simularea acesteia (adică simulând implementarea modelului deja implementat).
- Eroare de deplasare a distribuției solicitărilor: o preocupare majoră privind Simularea implementării este că implementarea oricărui model va cauza o schimbare distribuțională a intrărilor, mai ales dacă utilizatorii se adaptează la noile posibilități ale modelului. Izolăm eroarea de distribuție a solicitărilor comparând estimările atunci când simulăm implementarea folosind solicitări recente față de solicitări din implementarea realizată.
După cum se vede în Figura 4, constatăm că o fracțiune mare a erorii din pipeline-ul nostru – mai ales pentru erorile de coadă – se datorează în prezent fidelității simulării. Aceasta este o veste bună, deoarece ne așteptăm ca fidelitatea simulării să fie, în general, mai ușor de îmbunătățit decât reducerea deplasării distribuției solicitărilor. Constatăm, de asemenea, că eroarea de deplasare a distribuției solicitărilor poate fi redusă folosind cele mai recente date din implementarea anterioară. Mai multe detalii se găsesc în lucrarea de cercetare.
Figura 4: fidelitatea mediului de reeșantionare pare să fie cea mai mare sursă de eroare în estimările noastre, mai ales pentru cele mai extreme erori.
Auditarea automată a găsit singura nealiniere nouă introdusă în aceste implementări. În fereastra de implementare pe care am studiat-o, pipeline-ul nostru de auditare automată bazat pe implementări simulate ar fi scos la iveală „hackingul calculatorului” înainte de lansare, acesta fiind singura nealiniere nouă pe care am identificat-o în traficul ChatGPT analizat. Hackingul calculatorului este o formă de hacking al recompensei care implică folosirea de către model a unui instrument de browser ca pe un calculator, prezentând acțiunea ca pe o căutare. Aceasta nu înseamnă că auditarea la scară largă va prinde fiecare eșec nou, dar arată de ce contează contextele realiste: ele pot provoca comportamente pe care seturile de evaluare mai înguste poate nu le scot niciodată direct la iveală, chiar dacă nu erau prezente în traficul inițial folosit pentru a inițializa simularea.
Un alt avantaj al folosirii contextelor asemănătoare implementării este că pot reduce distorsiunile care apar atunci când modelele recunosc că sunt testate. În cercetări anterioare, noi, precum și alții(se deschide într-o fereastră nouă), am constatat că modelele sunt adesea conștiente de momentele în care sunt testate. De exemplu, modelele pot raționa în lanțul lor de gândire despre ce anume li se testează, ce ar putea plăcea unui evaluator și – dacă se comportă necorespunzător – dacă vor fi prinse. Acest lucru ridică o problemă pentru evaluările alinierii: dacă un model se comportă bine doar pentru că crede că este testat, cum construim încrederea că se va comporta în siguranță odată ce află că a fost implementat?
Arătăm că Simularea implementării reduce substanțial nivelurile de conștientizare a evaluării manifestate de modele față de evaluările tradiționale care nu se bazează pe date reale de implementare. Măsurăm conștientizarea evaluării în trei moduri: cerând unui model să clasifice dacă o traiectorie a provenit din producție sau dintr-o evaluare, monitorizând lanțul de gândire pentru afirmații explicite despre faptul că este evaluat pentru aliniere, precum și pentru metagaming(se deschide într-o fereastră nouă): orice raţionament despre supraveghere. Traficul de implementare simulat s-a potrivit îndeaproape cu traficul real de implementare în toate cele trei măsuri. De exemplu, GPT‑5.2 a etichetat traficul real de producție ca asemănător unei evaluări în 5,4% din cazuri și traficul simulat în 5,1% din cazuri, în timp ce evaluările tradiționale (precum SWE-Bench sau MonorepoBench, compuse în principal din exemple sintetice) au fost clasificate ca evaluări aproape 100% din timp.
Figura 5. Comparație privind conștientizarea evaluării: traficul real de producție și traficul simulat arată rate similare pentru detectarea evaluării, conștientizarea verbalizată a evaluării alinierii și metagaming, în timp ce seturile tradiționale de evaluare raportează rate mult mai mari.
Pentru a testa dacă metoda s-ar putea extinde dincolo de modurile standard de chat, am studiat și simularea implementărilor pentru setări dificile de codare agentivă. Mai precis, folosim 120.000 de traiectorii agentive interne ale angajaților din GPT‑5.4 pentru a simula implementarea internă a agenților de codare bazați pe GPT‑5.5. Acest lucru servește două scopuri: arată cum simularea implementării poate fi folosită și pentru evaluarea riscurilor în implementări interne și demonstrează că este posibil să se obțină o fidelitate ridicată a simulării chiar și în setări agentive, prin simularea atentă a instrumentelor.
Mai sus am discutat că fidelitatea simulării este una dintre principalele surse de eroare din pipeline-ul nostru actual. Una dintre provocările în realizarea unor simulări de implementare realiste este că instrumentele trebuie să acționeze în moduri realiste, chiar și atunci când au nevoie de acces de citire/scriere la resurse externe aflate în schimbare constantă (de ex., căutări web sau interacțiuni cu fișiere locale).
Acest lucru este deosebit de dificil pentru setări precum implementările agentive: o singură traiectorie de agent poate depinde de sute de apeluri de instrumente, de starea depozitului, de răspunsuri din rețea sau de eșecuri tranzitorii. Acest lucru face ca reeșantionarea cu acces la instrumente reale să fie atât dificilă, cât și potențial periculoasă. Având în vedere acest lucru, în loc să aplicăm apeluri de instrumente sistemelor live, le simulăm cu un alt LLM. Arătăm că oferirea de posibilități suplimentare acestui LLM este esențială pentru realism și, prin urmare, pentru calitatea estimării.
Oferim modelului simulator de instrumente lansarea originală a ultimului tur, depozitul de la momentul conversației, o bază de date cu perechi apel de instrument/răspuns și conectori doar în citire. Într-un test în care un discriminator a încercat să distingă lansările simulate de cele reale, realismul s-a îmbunătățit de la o rată de câștig de 11,6% la 49,5%, aproape de nivelul de șansă de 50%.
Figura 6: realismul reeșantionării poate deveni aproape imposibil de distins de eșantionarea reală chiar și în contexte cu utilizare intensă a instrumentelor, atunci când apelurile de instrumente sunt simulate cu posibilități sporite.
Ca dovadă suplimentară a fidelității simulării, atunci când simulăm traficul de raționament GPT‑5.4 Codex cu GPT‑5.4, ratele de nealiniere se află, aproximativ, în limitele barelor de eroare. În schimb, în testarea noastră înainte de implementare, GPT‑5.5 a fost mai nealiniat în majoritatea categoriilor.
Figura 7: cu simularea instrumentelor, ratele de comportament pentru conversațiile reeșantionate cu GPT‑5.4 și traficul real de producție GPT‑5.4 sunt destul de similare – indicând o fidelitate ridicată a mediului de reeșantionare. Consultă fișa de sistem GPT‑5.5(se deschide într-o fereastră nouă) pentru mai mult context despre categorii.
Aceste rezultate sugerează că Simularea implementării se poate extinde la setări complexe de agent atunci când mediul de instrumente înconjurător este simulat cu fidelitate suficientă.
O întrebare firească este dacă auditorii externi pot obține unele dintre aceleași beneficii fără acces la traficul privat de producție. Am testat acest lucru cu 100.000 de conversații WildChat folosite ca prefixe. WildChat a fost mai puțin precis decât datele recente de producție OpenAI, dar totuși informativ: datele recente de producție au avut o eroare multiplicativă medie mai mică decât WildChat (1,75× față de 2,44×), în timp ce WildChat a rămas adesea la aproximativ 3× față de ratele de producție și a identificat modelul mai bun la rate peste nivelul șansei. Vedem evaluările de tip WildChat ca pe un complement promițător la Simularea implementării rulată de dezvoltatori. Consultă această postare de blog despre Aliniere(se deschide într-o fereastră nouă) însoțitoare pentru mai multe rezultate pe acest punct.
Simularea implementării este un complement, nu un înlocuitor, pentru evaluările adversariale, red-teaming și analiza țintită a riscurilor de coadă. Detectarea unor comportamente nedorite ale modelului se bazează pe monitorizabilitatea lanțului de gândire: dacă modelele viitoare raționează mai puțin lizibil, omit pași cheie sau învață să își ascundă intenția, este posibil să nu putem detecta aceste forme de comportament nedorit. În plus, deoarece datele de producție sunt private, dezvoltatorii au în prezent acces mai puternic la contexte reprezentative decât auditorii externi. Seturi de date publice mai bune ar putea reduce acest decalaj.
Simularea implementării este cel mai utilă pentru comportamentele care apar suficient de des încât să fie prezente în prefixele eșantionate. Este puțin probabil ca un eșec care apare o dată la zece milioane de conversații să fie descoperit într-o rulare cu un milion de eșantioane, astfel că evaluările adversariale, red-teamingul și analiza țintită a riscurilor de coadă rămân necesare. În prezent, ne concentrăm pe simularea unui singur răspuns al asistentului, deoarece, în experimentele preliminare, nu am constatat îmbunătățiri semnificative ale estimărilor noastre prin simularea mai multor ture. Aceasta poate fi o direcție importantă pentru îmbunătățirea fidelității simulării în viitor.
Metoda depinde și de distribuția prefixelor — amestecul de conversații care sunt reeșantionate. Traficul istoric poate să nu se potrivească modului în care utilizatorii interacționează cu un model mai capabil după o schimbare majoră de produs, lansarea unui nou instrument, un eveniment mondial sau o schimbare sezonieră. Analiza din lucrarea completă sugerează că această problemă poate fi atenuată folosind cele mai recente date disponibile.
Simularea implementării este o nouă abordare a evaluării riscurilor înainte de implementare, care ajută laboratoarele de vârf și evaluatorii să prezică modul în care modelele lingvistice se pot comporta în lumea reală și să înțeleagă riscurile pe care le prezintă înainte de implementare. Ea completează evaluările de siguranță existente, red-teaming și analiza țintită prin adăugarea unui strat de predicție mai asemănător producției, care poate îmbunătăți estimările comportamentului la implementare, reduce efectele de conștientizare a evaluării și face verificabile după lansare predicțiile de dinaintea implementării. Folosită alături de evaluările tradiționale, Simularea implementării poate ajuta ca evaluarea riscurilor modelului să devină mai realistă, mai cantitativă și mai utilă pentru deciziile de implementare.
Autor
Continuă să citești
