Un ghid comun pentru evaluări de încredere realizate de terți

Evaluările independente, de încredere, realizate de terți joacă un rol critic⁠ în consolidarea ecosistemului de siguranță. Aceste evaluări sunt efectuate pe modele de vârf pentru a oferi dovezi suplimentare pentru afirmațiile despre capacități critice și măsuri de atenuare a riscurilor de siguranță. În această postare, împărtășim lecțiile pe care le-am învățat până acum și recomandăm abordări pentru proiectarea evaluărilor care pot aprecia în mod valid modelele de vârf, sperând că acestea vor contribui la informarea standardelor emergente din domeniu.

Anterior, multe evaluări tratau modelele ca pe niște chatboți: evaluarea formula o solicitare către un model ca și cum ar fi fost un utilizator care pune o întrebare, modelul răspundea, iar un evaluator judeca rezultatul. Modelele de vârf de astăzi pot face mult mai mult: pot folosi instrumente, pot urmări informații de-a lungul multor pași și pot acționa într-un flux de lucru mai amplu. Aceasta înseamnă că performanța depinde nu doar de model, ci și de mediul în care are loc sarcina și de configurația care îi facilitează acțiunile. Această configurație din jur, pe care o numim „cadru de execuție”, poate schimba aspecte-cheie ale performanței sistemului, inclusiv modul în care folosește instrumentele, urmărește informațiile sau se recuperează după greșeli.

Acest lucru schimbă modul în care trebuie efectuate evaluările și ceea ce ar trebui să caute cititorii în rapoartele de evaluare. În opinia noastră, cele mai utile rapoarte descriu explicit două lucruri dincolo de rezultatul în sine: în primul rând, precizează ce afirmație a fost concepută să testeze configurația evaluării și, în al doilea rând, prezintă dovezile disponibile că rezultatul evaluării este valid.

Afirmațiile testate în evaluări se încadrează de obicei în una dintre trei categorii¹:

• Elicitarea capacității: poate un model să producă în mod plauzibil capacitatea evaluată? 
• Performanța măsurilor de protecție: cât de robuste sunt măsurile de protecție testate împotriva comportamentului sau atacului evaluat?
• Comparație: cum se comportă modele diferite în condiții echivalente?

Rapoartele de evaluare trebuie, de asemenea, să explice cum au verificat evaluatorii efectele care ar putea afecta validitatea unui rezultat. Acestea includ:

• Reward hacking: exploatarea unor scurtături în sarcină sau în mecanismul de notare, astfel încât sistemul primește credit fără a demonstra comportamentul pe care evaluarea este menită să îl măsoare.
• Refuzuri: refuzul în moduri care ascund comportamentul testat.
• Contaminare: supraperformanță deoarece sarcinile de evaluare, răspunsurile sau variante apropiate au apărut în datele de antrenare ori au putut fi descoperite în timpul evaluării, de exemplu prin navigare.
• Probleme defecte: subperformanță deoarece sarcinile sunt invalide. Motivele pot include notare incorectă (de ex., răspunsul corect necesită detalii de implementare nedeclarate) și medii imposibil de rezolvat (de ex., fișiere critice lipsă sau instrumente nesigure).
• Sandbagging: subperformanță deliberată atunci când modelul arată că este conștient că este evaluat.

Am observat că rolul cadrului de execuție este deosebit de important pentru sistemele care acționează pe traiectorii mai lungi. Când modelele pot folosi instrumente, pot menține starea și se pot recupera după greșeli de-a lungul multor pași, cadrul de execuție poate schimba nivelul de performanță observat și poate chiar determina dacă capacitatea evaluată apare sau nu în evaluare. De exemplu, un cadru de execuție care păstrează starea și reîncearcă acțiunile eșuate poate permite unui model să finalizeze o sarcină în mai mulți pași pe care același model nu o finalizează niciodată într-un cadru de execuție mai simplu.

În tabelul de mai jos, separăm trei tipuri de afirmații pe care evaluatorii ar putea dori să le facă și cadrul de execuție pe care credem că îl necesită fiecare tip de afirmație.

Afirmațiile despre capacitate sunt doar atât de puternice pe cât este elicitarea din spatele lor: evaluatorii trebuie să aleagă cadrul de execuție care se potrivește cel mai bine sarcinii și capacității pe care evaluarea încearcă să o măsoare. Un cadru de execuție standardizat poate fi potrivit pentru compararea sistemelor în condiții identice, dar poate subestima capacitatea atunci când omite caracteristici specifice ale cadrului de execuție care ajută modelul să îndeplinească sarcina. De exemplu, performanța GPT‑5.5 pe intervalele cibernetice ale OpenAI arată cum alegerea unui cadru de execuție poate schimba semnificativ capacitatea măsurată în sarcini care necesită utilizarea îndelungată, în mai mulți pași, a instrumentelor: modelul are performanțe mai bune când cadrul de execuție folosește compactare⁠ pentru a păstra contextul relevant pentru sarcină pe măsură ce interacțiunea devine mai lungă. Acest lucru demonstrează că, pentru anumite modele, un cadru de execuție care omite compactarea ar elicita insuficient performanța.

Alte evaluări publicate² arată, de asemenea, că alegerile privind cadrul de execuție și bugetul schimbă rezultatele evaluării. Creșterea resurselor de calcul la momentul testării poate schimba semnificativ capacitatea pe care o elicitează o evaluare, mai ales în domenii în care succesul este ușor de verificat, cum ar fi multe sarcini cibernetice. În evaluarea intervalelor cibernetice a UK AISI⁠(se deschide într-o fereastră nouă), creșterea bugetului de la 10M la 100M de tokenuri a îmbunătățit performanța cu până la 59%, iar performanța era încă în creștere la cel mai mare buget testat. Detalierea acestui lucru face evaluarea mai ușor de interpretat: le arată cititorilor cum depinde rezultatul de configurația de elicitare testată. Când performanța continuă să se îmbunătățească odată cu buget suplimentar, scorul ar trebui descris ca performanță sub acel cadru de execuție și acel buget, nu ca un plafon măsurat al capacității. Capacitatea depinde adesea de resurse, mai degrabă decât să fie o cantitate fixă ce poate fi măsurată clar o dată pentru totdeauna. Acolo unde succesul poate fi măsurat pe încercări repetate, rapoartele ar trebui să ia în considerare și costul așteptat per rezolvare reușită, nu doar rata de succes la un buget fix de tokenuri. Acest lucru poate face gravitatea mai ușor de interpretat: o rată scăzută de succes poate fi totuși relevantă în practică dacă costul încercărilor repetate se încadrează în modelul de amenințare relevant. Pentru afirmațiile despre capacitate, subelicitarea evitabilă este un eșec de măsurare: dacă cadrul de execuție sau bugetul împiedică sistemul să manifeste un comportament pe care altfel l-ar putea produce, scorul nu măsoară capacitatea afirmată. Acolo unde evaluatorii au împins elicitarea cât de departe a fost fezabil și performanța este încă în creștere, rapoartele ar trebui să spună acest lucru clar și să precizeze limpede că rezultatul este doar o estimare de limită inferioară.

Testarea măsurilor de protecție poate subestima dacă un atac poate reuși și cât de grav ar putea fi, atunci când nu ține cont de resursele disponibile atacatorilor, inclusiv de cadre de execuție personalizate. În evaluarea cibernetică GPT‑5.5 a UK AISI⁠(se deschide într-o fereastră nouă), red teaming-ul lor de specialitate a găsit un jailbreak universal care a elicitat conținut cibernetic care încalcă regulile în toate interogările malițioase furnizate de OpenAI, inclusiv în contexte agentive cu mai multe ture. Ei au folosit Codex pentru a crea un cadru de execuție personalizat care să întărească performanța de atac a modelului: acesta a integrat în interacțiune un tipar reutilizabil de ocolire a măsurilor de protecție, a păstrat acel tipar de-a lungul turelor și blocurilor și l-a aplicat în interogările cibernetice malițioase furnizate de OpenAI. Testarea măsurilor de protecție ar trebui să corespundă adversarului. Dacă afirmația privește robustețea la utilizare abuzivă de către experți, testul ar trebui să evalueze cea mai puternică strategie de atac end-to-end credibilă într-un buget definit, inclusiv orice cadru de execuție necesar pentru a păstra și reutiliza acea strategie. În caz contrar, rezultatele riscă o calibrare greșită: ar putea susține doar o afirmație mai îngustă despre rezistența la solicitări mai simple, ar putea rata atât gravitatea atacului, cât și probabilitatea lui de succes odată ce metoda de elicitare este operaționalizată și ar putea, de asemenea, supraestima probabilitatea sau gravitatea unei probleme dacă i se acordă prea mult buget.

Există un timp și un loc pentru comparațiile cu cadre de execuție standardizate, dar evaluatorii ar trebui să fie expliciți cu privire la motivul pentru care este adecvată folosirea unui set consecvent de cadre de execuție și la ce afirmație poate susține acesta. Evaluarea orizontului de timp a METR⁠(se deschide într-o fereastră nouă) este un exemplu de configurație de evaluare mai amplă, fixată în mod adecvat: este concepută pentru a produce rezultate comparabile între sistemele pe care le evaluează. METR definește un rezultat comun, durata tipică a unei sarcini umane la care se prevede că un agent AI va reuși la un anumit nivel de fiabilitate. Aplică un set comun de sarcini, o metodă de notare, o metodă de ajustare și un set mic de structuri reutilizabile precum Triframe și ReAct⁠(se deschide într-o fereastră nouă) în cadrul fiecărui lot de estimări raportate împreună. Când METR a extins setul de sarcini și a mutat infrastructura de evaluare dintr-un cadru numit Vivaria într-unul numit Inspect, a raportat schimbarea (actualizarea Time Horizon 1.1⁠(se deschide într-o fereastră nouă)) și a reevaluat modelele în noua configurație de evaluare. Aceasta este valoarea unei configurații de evaluare standardizate, inclusiv a unui set consecvent de cadre de execuție: îi poate face pe cititori să aibă încredere că o diferență de scoruri reflectă într-adevăr o diferență între sistemele comparate, nu o schimbare a configurației de măsurare.

Recomandăm ca rapoartele de evaluare realizate de terți să precizeze ce tip de afirmație este menit să susțină configurația lor de evaluare; să descrie cât de fidel reflectă ceea ce a fost testat acea afirmație mai amplă; să descrie alegerile de cadru de execuție care au modelat rezultatul; să detalieze când aceste alegeri se schimbă între evaluări; și să includă dovezi de sprijin pentru a arăta cum a fost produs rezultatul și cât de bine se generalizează la afirmația făcută.

Pe măsură ce modelele devin mai capabile, scorurile evaluărilor devin mai ușor de interpretat greșit. În raport cu capacitățile reale, scorurile evaluărilor pot fi reduse artificial dacă un model recunoaște că este evaluat și subperformează strategic. Ele pot fi umflate dacă modelul exploatează o scurtătură în sarcină, solicitare, mecanismul de notare sau cadrul de execuție. Ele pot fi, de asemenea, distorsionate de contaminare (când un model știe deja sau poate găsi un răspuns fără a rezolva sarcina) ori de probleme „defecte” care sunt ambigue, notate incorect, imposibil de rezolvat sau vulnerabile la scurtături neintenționate. Prin urmare, rapoartele de evaluare ar trebui să asocieze scorurile principale cu o discuție despre aceste pericole, astfel încât cititorii să poată aprecia dacă scorurile reflectă comportamentul vizat.

Cadrele de execuție, bugetele, instrumentele, regulile de notare, monitoarele și procedurile de revizuire influențează toate dacă un agent rezolvă sarcina vizată, o evită, o memorează sau găsește o cale de a o ocoli. Un raport demn de încredere face aceste verificări vizibile: evaluatorii ar trebui să revizuiască eșantioane pentru aceste comportamente de fiecare dată când se desfășoară o evaluare de ansamblu.

Reward hacking

Reward hacking înseamnă obținerea unor scoruri mari la evaluare în moduri care nu reflectă capacitatea vizată. Aici, preocuparea este că sistemul primește credit exploatând sarcina, mecanismul de notare, solicitarea sau cadrul de execuție, în loc să facă munca pe care evaluarea trebuia să o măsoare. Evaluarea METR a GPT 5.4⁠(se deschide într-o fereastră nouă) arată de ce acest lucru contează: deși modelul a reușit la sarcini într-un ritm care ar fi corespuns la prima vedere unui orizont de timp de aproximativ 13 ore, revizuirea umană a arătat că unele dintre aceste reușite proveneau din reward hacking, iar revizuirea rezultatelor pentru a ține cont doar de cazurile fără reward hacking a redus estimarea la aproximativ 6 ore. Evaluatorii ar trebui să aprecieze necesitatea unor astfel de ajustări și, atunci când sunt necesare, să le raporteze clar: o estimare a capacității este mult mai utilă când cititorii pot vedea care succese aparente au fost descalificate, de ce au fost descalificate și în ce măsură depinde rezultatul de această judecată.

Refuzuri

Modelele pot, de asemenea, să subperformeze în evaluările de capacitate din cauza măsurilor de protecție. Un model poate avea o performanță mai scăzută la evaluare decât ar fi capabil, deoarece refuză sarcinile de evaluare în loc să le finalizeze. Prin urmare, rapoartele ar trebui să explice dacă refuzurile au făcut parte din rezultatele evaluării și, dacă da, câte eșantioane au fost compromise din această cauză.

Contaminare

Contaminarea contează cel mai mult pentru testele de referință publice sau reutilizate⁠. Dacă sarcinile, răspunsurile sau variante apropiate apar în datele de antrenare ori pot fi găsite de un agent cu navigare, performanța poate reflecta memorarea sau regăsirea, nu performanța modelului. Evaluatorii ar trebui să prefere, acolo unde este posibil, sarcini private sau nou construite și să testeze dacă modelele reproduc detalii specifice sarcinii înainte de a o rezolva.

Probleme defecte

Problemele defecte includ situații precum o problemă care, accidental, nu poate fi rezolvată. Problemele defecte sunt suficient de frecvente⁠(se deschide într-o fereastră nouă) încât ar trebui tratate ca un risc standard pentru validitate. Acestea includ adevăruri de referință incorecte, solicitări ambigue, fișiere lipsă, servicii instabile, criterii de notare inechitabile și medii care expun scurtături precum fișiere ascunse cu răspunsuri sau istoricul depozitului care conține patch-ul de referință.

Sandbagging

Sandbagging-ul realizat de un model sau de un sistem înseamnă manifestarea intenționată a unei performanțe mai slabe atunci când o performanță ridicată ar intra în conflict cu un anumit obiectiv. Evaluarea GPT‑5.5 realizată de Apollo⁠(se deschide într-o fereastră nouă) a testat acest comportament prin crearea unui context în care modelul înțelegea că scorurile mari la evaluare ar putea declanșa dezînvățarea sau ar putea împiedica implementarea sa. GPT‑5.5 a continuat totuși să răspundă corect, ceea ce sugerează existența unor dovezi comportamentale reduse privind subperformanța strategică³.Totuși, analiza lanțurilor de raționament a adăugat un context important: Apollo a identificat indicii moderate sau mai puternice de conștientizare a faptului că se află într-o evaluare de aliniere în 52% dintre exemplele din condiția de sandbagging, comparativ cu 0% în scenariile contrafactuale. Aceste dovezi complică interpretarea rezultatului, dar oferă în cele din urmă mai multe informații utile cititorilor: aceștia pot vedea atât rezultatul comportamental încurajator, cât și motivele pentru care nu ar trebui să îl interpreteze excesiv de optimist.

Afirmațiile puternice necesită atât cadrul de execuție potrivit pentru a elicita comportamentul, cât și verificări de validitate care să arate că rezultatul este solid. Viziunea noastră, potrivit căreia cadrele de execuție și verificările de validitate fac parte din rezultatul evaluării, modelează modul în care susținem în practică evaluările realizate de terți: 

• Împărtășim evaluatorilor îndrumări specifice privind elicitarea maximă.
• Le cerem evaluatorilor de capacitate să folosească Codex ca nivel minim comun pentru modelele OpenAI: testele ar trebui cel puțin să ruleze o bază de referință prin aceeași interfață agentivă pe care utilizatorii se vor baza probabil, nu doar printr-o interfață de model redusă.
• De asemenea, punem la dispoziție lanțuri de raţionament și alte artefacte intermediare acolo unde sunt necesare pentru a evalua înșelăciunea, sandbagging-ul sau conștientizarea evaluării. METR și Apollo au folosit acest acces în evaluările OpenAI încă de la GPT‑5. 
• În cele din urmă, prioritizăm cercetarea pentru a înțelege mai profund când și cum alegerile de cadru de execuție schimbă semnificativ rezultatele, de la gestionarea contextului și accesul la instrumente până la comportamentul de reîncercare, notare și bugetele de resurse.

Aceste recomandări sunt menite nu doar să îmbunătățească rapoartele individuale de evaluare, ci și să informeze standardele naționale ⁠(se deschide într-o fereastră nouă)și internaționale ⁠(se deschide într-o fereastră nouă)emergente pentru evaluarea și raportarea AI de vârf. Pe viitor, standardele pentru evaluările realizate de terți ar trebui să ceară suficiente detalii pentru ca factorii de decizie să înțeleagă ce afirmații susțin evaluările specifice, ce sistem a fost testat, cum a fost elicitat rezultatul și cum i-au verificat evaluatorii validitatea. Pentru sistemele de vârf testate pe sarcini în care capacitățile agentive contează, detaliile ar trebui să includă (sub rezerva oricăror preocupări de securitate sau confidențialitate):

• Afirmația: dacă evaluarea compară sisteme, estimează un plafon de capacitate sau testează măsuri de protecție.
• Conținutul evaluării: suficiente detalii despre sarcini sau distribuția sarcinilor pentru ca cititorii să înțeleagă ce abilități, comportamente sau moduri de eșec testează efectiv evaluarea.
• Sistemul testat: modelul, setarea de raţionament, accesul la instrumente, cadrul de execuție și măsurile de protecție.
• Bugetul: ture, tokenuri, încercări/reîncercări, timp de execuție, cost de inferență și, unde este cazul, costul așteptat per rezolvare reușită.
• Metode de elicitare: alegerile de cadru de execuție folosite pentru a scoate la iveală rezultatul și cât de fidel reflectă afirmația mai amplă formulată ceea ce a fost testat.
• Verificări de validitate: cum au căutat evaluatorii reward hacking, conștientizarea evaluării, contaminarea, refuzurile, sandbagging-ul și alte comportamente care ar putea submina rezultatul, inclusiv modul în care cazurile confirmate au afectat notarea sau interpretarea.

Standardele care omit alegerile de cadru de execuție sau verificările de validitate pot subestima ce poate face un sistem sau pot supraestima încrederea într-o afirmație de siguranță. Construirea unor cadre de execuție și metode de elicitare solide rămâne un domeniu deschis de cercetare și ar trebui să fie un punct central pentru investigații și investiții suplimentare.