Isang pinagsasaluhang playbook para sa mapagkakatiwalaang third-party evaluation

Ang mga independiyente at pinagkakatiwalaang evaluation ng third party ay may kritikal na papel⁠ sa pagpapalakas ng safety ecosystem. Isinasagawa ang mga evaluation na ito sa mga frontier model upang magbigay ng karagdagang ebidensya para sa mga pahayag tungkol sa mahahalagang kakayahan at mga safety mitigation. Sa post na ito, ibinabahagi namin ang mga aral na natutunan namin sa ngayon, at inirerekomenda ang mga paraan sa pagdisenyo ng mga evaluation na may wastong pagtatasa sa mga frontier model na inaasahan naming makatutulong sa umuusbong na mga pamantayan sa larangang ito.

Noon, maraming evaluation ang tumuring sa mga modelo na parang chatbot: pinoprompt ng evaluation ang isang modelo na parang user na nagtatanong, sumasagot ang modelo, at hinuhusgahan ng evaluator ang output. Mas marami nang kayang gawin ng mga frontier model ngayon: maaari silang gumamit ng mga tool, subaybayan ang impormasyon sa maraming hakbang, at kumilos sa loob ng mas malaking workflow. Ibig sabihin nito, ang performance ay nakadepende hindi lamang sa modelo, kundi pati sa environment kung saan nagaganap ang gawain, at sa setup na nagpapadali sa mga kilos nito. Ang nakapaligid na setup na ito, na tinatawag naming “harness,” ay maaaring magbago ng mahahalagang aspeto ng performance ng sistema, kabilang ang kung paano ito gumagamit ng mga tool, sumusubaybay ng impormasyon, o bumabawi mula sa mga pagkakamali.

Binabago nito kung paano dapat isagawa ang mga evaluation, at kung ano ang dapat hanapin ng mga mambabasa sa mga ulat ng evaluation. Sa aming pananaw, malinaw na inilalarawan ng mga pinakakapaki-pakinabang na ulat ang dalawang bagay bukod sa mismong resulta: una, tinutukoy nila kung anong pahayag ang idinisenyo upang subukin ng evaluation setup, at ikalawa, ibinabahagi nila ang magagamit na ebidensya na valid ang resulta ng evaluation.

Karaniwang nabibilang sa isa sa tatlong kategorya ang mga pahayag na sinusubok sa mga evaluation¹:

• Capability elicitation: Makatuwiran bang naisasagawa ng isang modelo ang kakayahang sinusuri? 
• Safeguard performance: Gaano katatag ang mga sinubok na safeguard laban sa asal o pag-atakeng sinusuri?
• Paghahambing: Paano nagpe-perform ang iba’t ibang modelo sa ilalim ng magkatumbas na kundisyon?

Kailangan ding ipaliwanag ng mga ulat ng evaluation kung paano sinuri ng mga evaluator ang mga epektong maaaring makaapekto sa validity ng isang resulta. Kabilang dito ang:

• Reward hacking: Pagsasamantala sa mga shortcut sa gawain o scorer, kaya nakakakuha ng kredito ang sistema nang hindi naipapakita ang asal na nilalayong sukatin ng evaluation.
• Refusals: Pagtanggi sa mga paraang nagkukubli sa asal na sinusubok.
• Contamination: Sobrang taas ng performance dahil lumitaw ang mga gawain sa evaluation, mga sagot, o malalapit na baryante sa training data o natuklasan habang may evaluation, gaya sa pamamagitan ng browsing.
• Broken problems: Mababang performance dahil hindi valid ang mga gawain. Maaaring kabilang sa mga dahilan ang hindi patas na scoring (hal., nangangailangan ang tamang sagot ng mga detalyeng implementasyon na hindi sinabi) at mga environment na hindi malulutas (hal., nawawalang mahahalagang file o hindi maaasahang mga tool).
• Sandbagging: Sadyang mababang performance kapag nagpapakita sila ng kamalayang sila ay ine-evaluate.

Napansin namin na lalong mahalaga ang papel ng harness para sa mga sistemang kumikilos sa mas mahahabang trajectory. Kapag nakakagamit ang mga modelo ng mga tool, nakapagpapanatili ng state, at nakakabawi mula sa mga pagkakamali sa maraming hakbang, maaaring baguhin ng harness ang nakikitang antas ng performance, at maaari pa ngang matukoy kung lilitaw ba sa evaluation ang kakayahang sinusuri. Halimbawa, ang harness na nagpapanatili ng state at sumusubok muli sa mga nabigong aksyon ay maaaring magbigay-daan sa isang modelo na matapos ang isang multi-step na gawain na hindi nito kailanman natatapos sa mas simpleng harness.

Sa talahanayan sa ibaba, ibinubukod namin ang tatlong uri ng pahayag na maaaring gustong gawin ng mga evaluator at ang harness na sa tingin namin ay kailangan ng bawat uri ng pahayag.

Kasinglakas lamang ng elicitation sa likod ng mga ito ang mga capability claim: kailangang piliin ng mga evaluator ang harness na pinakaangkop sa gawain at sa kakayahang sinusubukang sukatin ng evaluation. Maaaring tama ang isang standardized harness para sa paghahambing ng mga sistema sa magkaparehong kundisyon, ngunit maaari nitong maliitin ang kakayahan kapag iniiwan nito ang mga partikular na feature ng harness na tumutulong sa modelo na gawin ang gawain. Halimbawa, ipinapakita ng performance ng GPT‑5.5 sa mga cyber range ng OpenAI kung paano maaaring makabuluhang baguhin ng pagpili ng harness ang nasusukat na kakayahan sa mga gawaing nangangailangan ng mahaba at maraming hakbang na paggamit ng tool: mas mahusay ang performance ng modelo kapag gumagamit ang harness ng compaction⁠ upang mapanatili ang kontekstong mahalaga sa gawain habang humahaba ang interaksyon. Ipinapakita nito na para sa ilang modelo, ang harness na walang compaction ay hindi sapat na nakapag-e-elicit ng performance.

Ipinapakita rin ng iba pang nailathalang evaluation² na binabago ng mga pagpili sa harness at budget ang mga resulta ng evaluation. Ang pagtaas ng test-time compute ay maaaring makabuluhang magbago sa kakayahang nailalabas ng isang evaluation, lalo na sa mga domain kung saan madaling beripikahin ang tagumpay, gaya ng maraming cyber task. Sa evaluation ng UK AISI sa cyber range⁠(magbubukas sa bagong window), ang pagtaas ng budget mula 10M tungo sa 100M token ay nagpahusay ng performance nang hanggang 59%, at patuloy pa ring tumataas ang performance sa pinakamataas na budget na sinubok. Ang pagdedetalye nito ay nagpapadaling unawain ang evaluation: ipinapakita nito sa mga mambabasa kung paano nakadepende ang resulta sa sinubok na elicitation setup. Kapag patuloy pang gumagaling ang performance sa dagdag na budget, dapat ilarawan ang score bilang performance sa ilalim ng harness at budget na iyon, hindi bilang nasukat na pinakamataas na hangganan ng kakayahan. Madalas na nakadepende sa resources ang kakayahan sa halip na isang nakapirming dami na maaaring malinis na masukat nang isang beses lang. Kung saan masusukat ang tagumpay sa paulit-ulit na mga pagtatangka, dapat ding isaalang-alang ng mga ulat ang inaasahang gastos sa bawat matagumpay na paglutas, hindi lamang ang success rate sa isang nakapirming token budget. Mapapadali nito ang pag-unawa sa tindi: maaaring may praktikal na kahulugan pa rin ang mababang success rate kung pasok sa kaugnay na threat model ang gastos ng paulit-ulit na mga pagtatangka. Para sa mga capability claim, ang maiiwasang under-elicitation ay kabiguan sa pagsukat: kung pinipigilan ng harness o budget ang sistema na ipakita ang asal na kaya naman nitong ilabas, hindi nasusukat ng score ang kine-claim na kakayahan. Kung naitulak na ng mga evaluator ang elicitation hanggang sa abot ng posible at patuloy pa ring gumagaling ang performance, dapat malinaw itong sabihin ng mga ulat at linawin na ang resulta ay pagtatayang lower bound lamang.

Maaaring maliitin ng pagsubok sa safeguard kung magtatagumpay ang isang pag-atake, at gaano ito kalubha, kapag hindi isinasaalang-alang ang mga resource na available sa mga umaatake, kabilang ang mga custom harness. Sa cyber evaluation ng UK AISI sa GPT‑5.5⁠(magbubukas sa bagong window), nakakita ang kanilang expert red teaming ng isang universal jailbreak na naglabas ng lumalabag na cyber content sa mga mapaminsalang query na ibinigay ng OpenAI, kabilang sa mga multi-turn agentic setting. Gumamit sila ng Codex upang gumawa ng custom harness para palakasin ang attack performance ng modelo: isinama nito ang isang reusable na pattern ng pag-bypass sa safeguard sa interaksyon, pinanatili ang pattern na iyon sa iba’t ibang turn at block, at inilapat ito sa mga mapaminsalang cyber query na ibinigay ng OpenAI. Dapat tumugma ang pagsubok sa safeguard sa adversary. Kung ang pahayag ay tungkol sa tibay laban sa maling paggamit ng eksperto, dapat suriin ng pagsubok ang pinakamalakas na kapani-paniwalang end-to-end na estratehiya ng pag-atake sa ilalim ng itinakdang budget, kabilang ang anumang harness na kailangan upang mapanatili at magamit muli ang estratehiyang iyon. Kung hindi, nanganganib na maging mali ang pagkaka-calibrate ng mga resulta: magagawa lamang nilang suportahan ang mas makitid na pahayag tungkol sa resistensya sa mas simpleng prompting, hindi makita kung gaano kalubha ang pag-atake at ang posibilidad ng tagumpay nito kapag naisakatuparan na ang paraan ng elicitation, at mapalaki rin ang posibilidad o tindi ng problema kung bibigyan ng sobrang budget.

May tamang panahon at lugar para sa mga paghahambing gamit ang standardized harness, ngunit dapat maging tahasan ang mga evaluator kung bakit angkop ang paggamit ng pare-parehong hanay ng mga harness at kung anong pahayag ang kaya nitong suportahan. Ang time-horizon evaluation ng METR⁠(magbubukas sa bagong window) ay isang halimbawa ng mas malawak at angkop na nakapirming evaluation setup: idinisenyo ito upang makagawa ng mga resultang maihahambing sa iba’t ibang sistemang sinusuri nito. Tinutukoy ng METR ang isang karaniwang outcome, ang tipikal na tagal ng isang gawaing pantao kung saan inaasahang magtatagumpay ang isang AI agent sa isang ibinigay na antas ng pagiging maaasahan. Inilalapat nito ang pinagsasaluhang task suite, paraan ng scoring, paraan ng fitting, at maliit na hanay ng mga reusable scaffold gaya ng Triframe at ReAct⁠(magbubukas sa bagong window) sa loob ng bawat batch ng mga pagtatayang magkakasamang iniuulat. Nang palawakin ng METR ang task suite at ilipat ang evaluation infrastructure mula sa framework na tinatawag na Vivaria patungo sa tinatawag na Inspect, iniulat nito ang pagbabago (update sa Time Horizon 1.1⁠(magbubukas sa bagong window)) at muling in-evaluate ang mga modelo sa ilalim ng bagong evaluation setup. Iyan ang halaga ng isang standardized evaluation setup, kabilang ang pare-parehong hanay ng harness: maaari nitong bigyan ng kumpiyansa ang mga mambabasa na ang pagkakaiba sa mga score ay tunay na sumasalamin sa pagkakaiba ng mga sistemang inihahambing, sa halip na pagbabago sa setup ng pagsukat.

Inirerekomenda namin na sabihin ng mga ulat ng evaluation ng third party kung anong uri ng pahayag ang nilalayong suportahan ng kanilang evaluation setup; ilarawan kung gaano kalapit ang sinubok sa mas malawak na pahayag na iyon; ilarawan ang mga pagpili sa harness na humubog sa resulta; idetalye kung kailan nagbabago ang mga pagpiling iyon sa pagitan ng mga evaluation; at magsama ng sumusuportang ebidensya upang ipakita kung paano nalikha ang resulta at kung gaano ito nagje-generalize sa pahayag.

Habang nagiging mas may kakayahan ang mga modelo, mas nagiging madaling mapagkamalan ang kahulugan ng mga evaluation score. Kung ihahambing sa tunay na kakayahan, maaaring artipisyal na bumaba ang mga evaluation score kung nakikilala ng isang modelo na ine-evaluate ito at estratehikong nagpapakita ng mababang performance. Maaari ring tumaas ang mga ito kung sinasamantala ng modelo ang isang shortcut sa gawain, prompt, scorer, o harness. Maaari rin silang mabaluktot ng contamination (kung saan alam na ng modelo o mahahanap nito ang sagot nang hindi nilulutas ang gawain) o ng mga “broken” na problemang malabo, mali ang scoring, hindi malulutas, o madaling daanan ng mga hindi sinasadyang shortcut. Dahil dito, dapat ipares ng mga ulat ng evaluation ang mga pangunahing score sa talakayan ng mga panganib na ito, upang matasa ng mga mambabasa kung ang mga score ay sumasalamin sa nilalayong asal.

Ang mga harness, budget, tool, tuntunin sa scoring, monitor, at mga proseso ng review ay lahat nakaaapekto kung nilulutas ba ng isang agent ang nilalayong gawain, iniiwasan ito, minememorya ito, o nilulusutan ito. Ginagawang nakikita ng isang mapagkakatiwalaang ulat ang mga pagsusuring iyon: dapat suriin ng mga evaluator ang mga sample para sa mga asal na ito sa tuwing nagpapatakbo ng assessment.

Reward hacking

Ang reward hacking ay nangangahulugang pagkamit ng matataas na evaluation score sa mga paraang hindi sumasalamin sa nilalayong kakayahan. Dito, ang alalahanin ay na nakakakuha ng kredito ang sistema sa pamamagitan ng pagsasamantala sa gawain, scorer, prompt, o harness sa halip na sa paggawa ng trabahong nilalayong sukatin ng evaluation. Ipinapakita ng evaluation ng METR sa GPT 5.4⁠(magbubukas sa bagong window) kung bakit ito mahalaga: kahit nagtagumpay ang modelo sa mga gawain sa antas na sa unang tingin ay katumbas ng humigit-kumulang 13-oras na time horizon, ipinakita ng human review na ang ilan sa mga tagumpay na iyon ay mula sa reward hacking, at nang rebisahin ang mga resulta upang isama lamang ang mga pagkakataong walang reward hacking, bumaba ang tantiya sa humigit-kumulang 6 na oras. Dapat tasahin ng mga evaluator ang pangangailangan para sa ganitong mga pag-aayos at, kapag kailangan ang mga ito, malinaw na iulat ang mga iyon: mas kapaki-pakinabang ang isang pagtataya ng kakayahan kapag nakikita ng mga mambabasa kung aling mga tila tagumpay ang hindi isinama, bakit hindi isinama ang mga iyon, at gaano kalaki ang pagdepende ng resulta sa paghatol na iyon.

Refusals

Maaari ring magpakita ng mababang performance ang mga modelo sa mga capability evaluation dahil sa safeguards. Maaaring mas mababa ang evaluation performance ng isang modelo kaysa sa kaya nito dahil tumatanggi ito sa mga gawain sa evaluation sa halip na tapusin ang mga ito. Dahil dito, dapat ipaliwanag ng mga ulat kung bahagi ba ng mga resulta ng evaluation ang mga refusal at kung oo, ilan sa mga sample ang nakompromiso dahil dito.

Contamination

Pinakamahalaga ang contamination para sa mga pampubliko o muling ginamit na benchmark⁠. Kung lumilitaw ang mga gawain, sagot, o malalapit na baryante sa training data o mahahanap ng isang agent na may browsing, maaaring sumasalamin ang performance sa memorya o retrieval sa halip na sa performance ng modelo. Dapat hangga’t maaari ay mas piliin ng mga evaluator ang mga pribado o bagong binuong gawain at subukin kung inuulit ng mga modelo ang mga detalyeng partikular sa gawain bago ito lutasin.

Broken problems

Kabilang sa broken problems ang mga sitwasyong gaya ng problemang hindi sinasadyang hindi malulutas. Sapat na karaniwan⁠(magbubukas sa bagong window) ang broken problems kaya dapat silang ituring na karaniwang panganib sa validity. Kabilang dito ang maling ground truth, malalabong prompt, nawawalang file, hindi matatag na serbisyo, hindi patas na pamantayan sa scoring, at mga environment na naglalantad ng mga shortcut gaya ng mga nakatagong answer file o history ng repository na naglalaman ng ground-truth patch.

Sandbagging

Ang sandbagging ng isang modelo o sistema ay nangangahulugang estratehikong mababang performance kapag ang malakas na performance ay sasalungat sa ilang layunin. Sinubok ito ng evaluation ng Apollo sa GPT‑5.5⁠(magbubukas sa bagong window) sa pamamagitan ng paglikha ng kontekstong naunawaan ng modelo na ang matataas na evaluation score ay maaaring mag-trigger ng unlearning o humarang sa deployment. Tama pa ring sumagot ang GPT‑5.5, na nagpapahiwatig ng kaunting ebidensyang asal ng estratehikong mababang performance³. Ngunit nagdagdag ng mahalagang konteksto ang kanilang review ng reasoning traces: nakakita ang Apollo ng katamtaman-o-mas-mataas na palatandaan ng alignment-evaluation awareness sa 52% ng mga sample sa sandbagging condition, kumpara sa 0% sa mga counterfactual. Pinapakomplika ng ebidensyang iyon ang interpretasyon ng resulta, ngunit sa huli ay nagbibigay ito ng mas maraming signal sa mga mambabasa: nakikita nila kapwa ang nakapagpapalubag-loob na resulta sa asal at ang dahilan para mag-ingat sa sobrang pagbibigay-kahulugan dito.

Ang malalakas na pahayag ay nangangailangan kapwa ng tamang harness upang mailabas ang asal at ng mga validity check upang maipakitang maayos ang resulta. Ang pananaw namin na bahagi ng resulta ng evaluation ang mga harness at validity check ang humuhubog sa kung paano namin sinusuportahan sa praktika ang mga evaluation ng third party: 

• Nagbabahagi kami ng partikular na gabay sa maximum elicitation sa mga evaluator.
• Hinihiling namin sa mga capability evaluator na gamitin ang Codex bilang karaniwang baseline para sa mga modelo ng OpenAI: dapat kahit paano ay patakbuhin ng mga pagsubok ang baseline sa parehong agentic interface na malamang asahan ng mga user, sa halip na sa pinasimpleng model interface lamang.
• Ginagawa rin naming available ang reasoning traces at iba pang intermediate artifact kung saan kailangan ang mga ito upang tasahin ang panlilinlang, sandbagging, o evaluation awareness. Ginamit ng METR at Apollo ang access na ito sa mga evaluation ng OpenAI mula pa noong GPT‑5. 
• Sa huli, inuuna namin ang pananaliksik upang mas malalim na maunawaan kung kailan at paano makabuluhang binabago ng mga pagpili sa harness ang mga resulta, mula sa pamamahala ng konteksto at tool access hanggang sa retry behavior, scoring, at mga resource budget.

Nilalayon ang mga rekomendasyong ito hindi lamang upang mapabuti ang mga indibidwal na ulat ng evaluation, kundi upang makatulong din sa umuusbong na pambansa ⁠(magbubukas sa bagong window)at internasyonal ⁠(magbubukas sa bagong window)na mga pamantayan para sa evaluation at pag-uulat ng frontier AI. Sa hinaharap, dapat mangailangan ang mga pamantayan sa evaluation ng third party ng sapat na detalye upang maunawaan ng mga tagapagpasya kung anong mga pahayag ang sinusuportahan ng mga partikular na evaluation, anong sistema ang sinubok, paano nailabas ang resulta, at paano sinuri ng mga evaluator ang validity nito. Para sa mga frontier system na sinusubok sa mga gawaing mahalaga ang mga agentic na kakayahan, dapat kabilang sa mga detalye ang mga sumusunod (napapailalim sa anumang alalahanin sa seguridad o pagiging kumpidensyal):

• Ang pahayag: kung ang evaluation ay naghahambing ng mga sistema, nagtataya ng pinakamataas na hangganan ng kakayahan, o sumusubok ng safeguards.
• Nilalaman ng evaluation: sapat na detalye tungkol sa mga gawain o distribusyon ng gawain upang maunawaan ng mga mambabasa kung anong mga kasanayan, asal, o failure mode ang talagang sinusubok ng evaluation.
• Ang sinubok na sistema: ang modelo, setting ng pangangatwiran, tool access, harness, at safeguards.
• Ang budget: mga turn, token, pagtatangka/retry, wall-clock time, gastos sa inference, at kung naaangkop, inaasahang gastos sa bawat matagumpay na paglutas.
• Mga paraan ng elicitation: mga pagpili sa harness na ginamit upang mailabas ang resulta, at kung gaano kalapit ang sinubok sa mas malawak na pahayag na ginagawa.
• Mga validity check: kung paano naghanap ang mga assessor ng reward hacking, evaluation awareness, contamination, refusals, sandbagging at iba pang asal na maaaring makasira sa resulta, kabilang kung paano nakaapekto ang mga nakumpirmang kaso sa scoring o interpretasyon.

Maaaring maliitin ng mga pamantayang hindi isinasaalang-alang ang mga pagpili sa harness o validity check ang kayang gawin ng isang sistema o mapalaki ang kumpiyansa sa isang safety claim. Nananatiling bukas na larangan ng pananaliksik ang pagbuo ng matitibay na harness at mga paraan ng elicitation at dapat itong maging pokus ng karagdagang pagsisiyasat at pamumuhunan.