ယုံကြည်စိတ်ချရသော third-party evaluation များအတွက် မျှဝေထားသော လမ်းညွှန်စာအုပ်

လွတ်လပ်ပြီး ယုံကြည်စိတ်ချရသော third party evaluation များသည် လုံခြုံရေး ecosystem ကို ပိုမိုခိုင်မာစေရန် အရေးပါသော အခန်းကဏ္ဍ⁠ တစ်ရပ်အဖြစ် ပါဝင်သည်။ ဤ evaluation များကို စွမ်းဆောင်ရည်အမြင့်ဆုံး မော်ဒယ်များပေါ်တွင် ပြုလုပ်ပြီး အရေးကြီးသော စွမ်းရည်များနှင့် လုံခြုံရေးလျော့ပါးရေးဆိုင်ရာ အဆိုများအတွက် နောက်ထပ် အထောက်အထားများ ပေးရန် ရည်ရွယ်သည်။ ဤပို့စ်တွင် ယခုအချိန်အထိ ကျွန်ုပ်တို့ သင်ယူထားသော သင်ခန်းစာများကို မျှဝေပြီး၊ နယ်ပယ်အတွင်း ပေါ်ပေါက်လာနေသော စံနှုန်းများကို အထောက်အကူပြုမည်ဟု မျှော်လင့်သည့် စွမ်းဆောင်ရည်အမြင့်ဆုံး မော်ဒယ်များကို မှန်ကန်စွာ အကဲဖြတ်နိုင်သော evaluation များ ဒီဇိုင်းဆွဲရန် နည်းလမ်းများကို အကြံပြုထားသည်။

ယခင်က evaluation အများအပြားသည် မော်ဒယ်များကို chatbot များကဲ့သို့ ဆက်ဆံခဲ့သည် - evaluation က မော်ဒယ်တစ်ခုကို မေးခွန်းမေးနေသော အသုံးပြုသူတစ်ဦးကဲ့သို့ တုံ့ပြန်ညွှန်ကြားချက်ပေးပြီး၊ မော်ဒယ်က ဖြေကြားကာ evaluator က output ကို အကဲဖြတ်သည်။ ယနေ့ခေတ် စွမ်းဆောင်ရည်အမြင့်ဆုံး မော်ဒယ်များသည် ထိုထက် များစွာ ပိုလုပ်နိုင်သည် - ၎င်းတို့သည် tools များကို အသုံးပြုနိုင်ပြီး၊ အဆင့်များစွာအနှံ့ အချက်အလက်ကို မှတ်သားထားနိုင်ကာ၊ ပိုမိုကြီးမားသော workflow တစ်ခုအတွင်း လုပ်ဆောင်နိုင်သည်။ ထို့ကြောင့် စွမ်းဆောင်ရည်သည် မော်ဒယ်တစ်ခုတည်းပေါ်သာ မူတည်ခြင်းမဟုတ်ဘဲ၊ လုပ်ငန်း ဖြစ်ပွားသည့် environment နှင့် ၎င်း၏ လုပ်ဆောင်ချက်များကို အထောက်အကူပြုသော setup ပေါ်တွင်လည်း မူတည်လာသည်။ ကျွန်ုပ်တို့က “harness” ဟု ခေါ်သော ဤပတ်ဝန်းကျင် setup သည် စနစ်၏ စွမ်းဆောင်ရည်အရေးကြီးသော အစိတ်အပိုင်းများကို ပြောင်းလဲစေနိုင်ပြီး၊ tools များကို မည်သို့ အသုံးပြုသည်၊ အချက်အလက်ကို မည်သို့ မှတ်သားထားသည်၊ သို့မဟုတ် အမှားများမှ မည်သို့ ပြန်လည်ကောင်းမွန်လာသည်တို့ ပါဝင်သည်။

ဤအရာကြောင့် evaluation များကို မည်သို့ ဆောင်ရွက်ရမည်နှင့် evaluation report များတွင် စာဖတ်သူများက မည်သည့်အရာများကို ရှာဖွေသင့်သည်ဆိုသည် ပြောင်းလဲသွားသည်။ ကျွန်ုပ်တို့၏ အမြင်အရ အသုံးဝင်ဆုံး report များသည် ရလဒ်ကိုယ်တိုင်အပြင် အချက်နှစ်ချက်ကို တိတိကျကျ ဖော်ပြထားသည် - ပထမ၊ evaluation setup ကို မည်သည့်အဆိုကို စမ်းသပ်ရန် ဒီဇိုင်းလုပ်ထားသည်ကို သတ်မှတ်ပေးပြီး၊ ဒုတိယ၊ evaluation ရလဒ်သည် မှန်ကန်ကြောင်း ပြသနိုင်သော ရရှိနိုင်သည့် အထောက်အထားများကို မျှဝေသည်။

evaluation များတွင် စမ်းသပ်သော အဆိုများသည် ပုံမှန်အားဖြင့် အုပ်စုသုံးခုအနက် တစ်ခုထဲသို့ ကျရောက်သည်¹:

• Capability elicitation: အကဲဖြတ်နေသော စွမ်းရည်ကို မော်ဒယ်တစ်ခုက ယုံကြည်လောက်စွာ ထုတ်ပေးနိုင်ပါသလား။ 
• Safeguard performance: စမ်းသပ်ထားသော safeguards များသည် အကဲဖြတ်နေသော အပြုအမူ သို့မဟုတ် တိုက်ခိုက်မှုအပေါ် မည်မျှ ခိုင်မာသနည်း။
• Comparison: တူညီသော အခြေအနေများအောက်တွင် မတူညီသော မော်ဒယ်များသည် မည်သို့ စွမ်းဆောင်သနည်း။

evaluation report များသည် ရလဒ်၏ မှန်ကန်မှုကို ထိခိုက်စေနိုင်သော သက်ရောက်မှုများကို evaluators များက မည်သို့ စစ်ဆေးခဲ့သည်ကိုလည်း ရှင်းပြရန် လိုအပ်သည်။ ၎င်းတို့တွင် အောက်ပါတို့ ပါဝင်သည် -

• Reward hacking: စနစ်က evaluation တိုင်းတာလိုသော အပြုအမူကို မပြသဘဲ credit ရရှိစေရန် task သို့မဟုတ် scorer အတွင်းရှိ shortcut များကို အသုံးချခြင်း။
• Refusals: စမ်းသပ်နေသော အပြုအမူကို ဖုံးကွယ်သွားစေသည့် ပုံစံဖြင့် ငြင်းဆိုခြင်း။
• Contamination: evaluation လုပ်ငန်းများ၊ အဖြေများ သို့မဟုတ် အလွန်ဆင်တူသော ပုံစံများသည် training data တွင် ပါဝင်နေခြင်း သို့မဟုတ် browsing ကဲ့သို့ evaluation အတွင်း ရှာဖွေတွေ့ရှိနိုင်ခြင်းကြောင့် စွမ်းဆောင်ရည် ပိုမိုမြင့်မားသွားခြင်း။
• Broken problems: လုပ်ငန်းများ မမှန်ကန်သောကြောင့် စွမ်းဆောင်ရည် လျော့နည်းသွားခြင်း။ အကြောင်းရင်းများတွင် မမျှတသော scoring (ဥပမာ - မှန်ကန်သော အဖြေသည် မဖော်ပြထားသော implementation အသေးစိတ်များ လိုအပ်ခြင်း) နှင့် မဖြေရှင်းနိုင်သော environment များ (ဥပမာ - အရေးကြီးသော file များ ပျောက်နေခြင်း သို့မဟုတ် ယုံကြည်မရသော tools များ) ပါဝင်နိုင်သည်။
• Sandbagging: evaluation လုပ်နေကြောင်း သိရှိမှု ပြသသည့်အခါ ရည်ရွယ်ချက်ရှိရှိ စွမ်းဆောင်ရည် လျှော့ချခြင်း။

ပိုရှည်သော trajectories များအပေါ် လုပ်ဆောင်သော စနစ်များအတွက် harness ၏ အခန်းကဏ္ဍသည် အထူးအရေးကြီးကြောင်း ကျွန်ုပ်တို့ တွေ့ရှိထားသည်။ မော်ဒယ်များသည် tools များကို အသုံးပြုနိုင်ပြီး၊ state ကို ထိန်းသိမ်းနိုင်ကာ၊ အဆင့်များစွာအနှံ့ အမှားများမှ ပြန်လည်ကောင်းမွန်လာနိုင်သောအခါ harness သည် မြင်တွေ့ရသော စွမ်းဆောင်ရည်အဆင့်ကို ပြောင်းလဲစေနိုင်ပြီး၊ အကဲဖြတ်နေသော စွမ်းရည်သည် evaluation တွင် လုံးဝ ပေါ်လာမလာကိုပင် ဆုံးဖြတ်နိုင်သည်။ ဥပမာအားဖြင့် state ကို ထိန်းသိမ်းပြီး မအောင်မြင်သော လုပ်ဆောင်ချက်များကို ပြန်ကြိုးစားပေးသော harness တစ်ခုသည် ပိုရိုးရှင်းသော harness တစ်ခုတွင် ဘယ်တော့မှ မပြီးမြောက်နိုင်သော အဆင့်များစွာပါ လုပ်ငန်းတစ်ခုကို မော်ဒယ်တူညီသော်လည်း ပြီးစီးစေနိုင်သည်။

အောက်ပါဇယားတွင် evaluators များက ပြုလုပ်လိုနိုင်သော အဆိုအမျိုးအစား သုံးမျိုးနှင့် အဆိုတစ်မျိုးချင်းစီအတွက် လိုအပ်သည်ဟု ကျွန်ုပ်တို့ ယုံကြည်သော harness ကို ခွဲခြားဖော်ပြထားသည်။

စွမ်းရည်ဆိုင်ရာ အဆိုများ၏ အားကောင်းမှုသည် ၎င်းတို့နောက်ကွယ်ရှိ elicitation အပေါ်သာ မူတည်သည် - evaluators များသည် လုပ်ငန်းနှင့် evaluation တိုင်းတာလိုသော စွမ်းရည်နှင့် အကောင်းဆုံး ကိုက်ညီသော harness ကို ရွေးချယ်ရန် လိုအပ်သည်။ တူညီသော အခြေအနေများအောက်တွင် စနစ်များကို နှိုင်းယှဉ်ရန် standardized harness သည် သင့်တော်နိုင်သော်လည်း၊ မော်ဒယ်အား လုပ်ငန်းကို ဆောင်ရွက်ရာတွင် ကူညီပေးသော သီးခြား harness feature များကို ချန်လှပ်ထားပါက စွမ်းရည်ကို လျော့နည်းဖော်ပြနိုင်သည်။ ဥပမာအားဖြင့် OpenAI ၏ cyber range များပေါ်ရှိ GPT‑5.5 ၏ စွမ်းဆောင်ရည်က harness ရွေးချယ်မှုသည် ကြာရှည်ပြီး အဆင့်များစွာပါသော tool use လိုအပ်သည့် လုပ်ငန်းများတွင် တိုင်းတာထားသော စွမ်းရည်ကို အရေးပါစွာ ပြောင်းလဲစေနိုင်ကြောင်း ပြသသည် - interaction ပိုရှည်လာသည့်အခါ လုပ်ငန်းနှင့် သက်ဆိုင်သော context ကို ထိန်းသိမ်းရန် harness က compaction⁠ ကို အသုံးပြုသောအခါ မော်ဒယ်သည် ပိုကောင်းစွာ စွမ်းဆောင်သည်။ ၎င်းက အချို့သော မော်ဒယ်များအတွက် compaction ကို ချန်လှပ်ထားသော harness သည် စွမ်းဆောင်ရည်ကို လုံလောက်စွာ မထုတ်ဖော်နိုင်ကြောင်း ပြသသည်။

အခြား ထုတ်ဝေထားသော evaluation များ² သည်လည်း harness နှင့် budget ရွေးချယ်မှုများက evaluation ရလဒ်များကို ပြောင်းလဲစေကြောင်း ပြသထားသည်။ စမ်းသပ်ချိန် compute ကို တိုးမြှင့်ခြင်းသည် evaluation က ထုတ်ဖော်လာသော စွမ်းရည်ကို အရေးပါစွာ ပြောင်းလဲစေနိုင်သည်၊ အထူးသဖြင့် cyber task များစွာကဲ့သို့ အောင်မြင်မှုကို အလွယ်တကူ စစ်ဆေးနိုင်သော နယ်ပယ်များတွင် ဖြစ်သည်။ UK AISI ၏ cyber range evaluation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တွင် budget ကို 10M မှ 100M tokens သို့ တိုးမြှင့်လိုက်ခြင်းကြောင့် စွမ်းဆောင်ရည်သည် အများဆုံး 59% အထိ တိုးတက်ခဲ့ပြီး၊ စမ်းသပ်ထားသော အမြင့်ဆုံး budget တွင်ပင် စွမ်းဆောင်ရည်သည် ဆက်လက် တိုးတက်နေဆဲ ဖြစ်သည်။ ဤအချက်ကို အသေးစိတ်ဖော်ပြခြင်းက evaluation ကို ပိုမို နားလည်လွယ်စေသည် - ရလဒ်သည် စမ်းသပ်ထားသော elicitation setup အပေါ် မည်သို့ မူတည်သည်ကို စာဖတ်သူများအား ပြသပေးသည်။ နောက်ထပ် budget ဖြင့် စွမ်းဆောင်ရည် ဆက်လက် တိုးတက်နေသေးပါက score ကို တိုင်းတာထားသော စွမ်းရည်အမြင့်ဆုံးအဖြစ် မဟုတ်ဘဲ ထို harness နှင့် budget အောက်ရှိ စွမ်းဆောင်ရည်အဖြစ် ဖော်ပြသင့်သည်။ စွမ်းရည်သည် တစ်ကြိမ်တည်း သန့်ရှင်းစွာ တိုင်းတာပြီး အပြီးသတ်နိုင်သော တည်ငြိမ်သော ပမာဏတစ်ခုမဟုတ်ဘဲ အရင်းအမြစ်အပေါ် မူတည်လေ့ရှိသည်။ အောင်မြင်မှုကို ထပ်ခါတလဲလဲ ကြိုးစားမှုများအနှံ့ တိုင်းတာနိုင်သောနေရာများတွင် report များသည် တည်ငြိမ်သော token budget တစ်ခုအောက်ရှိ အောင်မြင်မှုနှုန်းတစ်ခုတည်းမဟုတ်ဘဲ အောင်မြင်စွာ ဖြေရှင်းမှုတစ်ခုလျှင် မျှော်မှန်းကုန်ကျစရိတ်ကိုလည်း စဉ်းစားသင့်သည်။ ဤအရာက ပြင်းထန်မှုကို ပိုမို နားလည်လွယ်စေနိုင်သည် - ထပ်ခါတလဲလဲ ကြိုးစားမှုများ၏ ကုန်ကျစရိတ်သည် သက်ဆိုင်ရာ threat model အတွင်း ရှိနေပါက အောင်မြင်မှုနှုန်း နိမ့်သော်လည်း လက်တွေ့တွင် အဓိပ္ပာယ်ရှိနေနိုင်သည်။ စွမ်းရည်ဆိုင်ရာ အဆိုများအတွက် ရှောင်လွှဲနိုင်သော under-elicitation သည် တိုင်းတာမှု ပျက်ကွက်ခြင်းဖြစ်သည် - harness သို့မဟုတ် budget က စနစ်ကို မဟုတ်ရင် ထုတ်ဖော်နိုင်မည့် အပြုအမူကို မပြသနိုင်အောင် တားဆီးပါက score သည် အဆိုပြုထားသော စွမ်းရည်ကို မတိုင်းတာနိုင်ပါ။ evaluators များက elicitation ကို လက်တွေ့ကျသမျှ အထိ တွန်းတင်ထားပြီး စွမ်းဆောင်ရည်သည် ဆက်လက် တိုးတက်နေသေးပါက report များသည် ထိုအချက်ကို ရှင်းလင်းစွာ ဖော်ပြသင့်ပြီး ရလဒ်သည် lower-bound estimate တစ်ခုသာ ဖြစ်ကြောင်းလည်း ရှင်းလင်းစွာ ပြောသင့်သည်။

Safeguard testing သည် custom harness များအပါအဝင် တိုက်ခိုက်သူများ ရရှိနိုင်သော အရင်းအမြစ်များကို မထည့်သွင်းစဉ်းစားပါက တိုက်ခိုက်မှုတစ်ခု အောင်မြင်နိုင်မနိုင်နှင့် ၎င်း၏ ပြင်းထန်မှု မည်မျှရှိနိုင်သည်ကို လျော့နည်းဖော်ပြနိုင်သည်။ UK AISI ၏ GPT‑5.5 cyber evaluation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တွင် ၎င်းတို့၏ ကျွမ်းကျင် ထိုးဖောက်စမ်းသပ်ခြင်း အဖွဲ့သည် OpenAI ပေးထားသော malicious query များအနှံ့၊ multi-turn agentic setting များအပါအဝင်၊ စည်းကမ်းချိုးဖောက်သော cyber content ကို ထုတ်ဖော်စေသည့် universal jailbreak တစ်ခုကို တွေ့ရှိခဲ့သည်။ ၎င်းတို့သည် မော်ဒယ်၏ တိုက်ခိုက်မှုစွမ်းဆောင်ရည်ကို အားကောင်းစေရန် custom harness တစ်ခု ဖန်တီးရာတွင် Codex ကို အသုံးပြုခဲ့သည် - ၎င်းသည် interaction အတွင်း ပြန်လည်အသုံးပြုနိုင်သော safeguard-bypass pattern တစ်ခုကို ထည့်သွင်းပေးပြီး၊ ထို pattern ကို turn များနှင့် block များအနှံ့ ထိန်းသိမ်းကာ၊ OpenAI ပေးထားသော malicious cyber query များအနှံ့ အသုံးချခဲ့သည်။ Safeguard testing သည် adversary နှင့် ကိုက်ညီသင့်သည်။ အဆိုသည် ကျွမ်းကျင် misuse အပေါ် robustness အကြောင်းဖြစ်ပါက test သည် သတ်မှတ်ထားသော budget အောက်တွင် ထို strategy ကို ထိန်းသိမ်းပြီး ပြန်လည်အသုံးပြုရန် လိုအပ်သည့် harness အပါအဝင် ယုံကြည်လောက်သည့် အပြင်းထန်ဆုံး end-to-end attack strategy ကို evaluation လုပ်သင့်သည်။ မဟုတ်ပါက ရလဒ်များသည် miscalibration ဖြစ်နိုင်သည် - ၎င်းတို့သည် ပိုရိုးရှင်းသော prompting အပေါ် ခံနိုင်ရည်ရှိမှုအကြောင်း ပိုကျဉ်းမြောင်းသော အဆိုတစ်ခုကိုသာ ထောက်ခံနိုင်ပြီး၊ elicitation method ကို operationalize လုပ်ပြီးနောက် တိုက်ခိုက်မှု၏ ပြင်းထန်မှုနှင့် အောင်မြင်နိုင်ခြေ နှစ်ခုစလုံးကို လွဲချော်နိုင်သကဲ့သို့၊ budget အလွန်များလွန်းပါက ပြဿနာတစ်ခု၏ ဖြစ်နိုင်ခြေ သို့မဟုတ် ပြင်းထန်မှုကိုလည်း ပိုမိုမြင့်မားစွာ ဖော်ပြမိနိုင်သည်။

standardized harness comparison များအတွက် သင့်တော်သော အချိန်နှင့် နေရာ ရှိသော်လည်း evaluators များသည် တည်ငြိမ်သော harness အစုတစ်ခုကို အသုံးပြုခြင်းသည် အဘယ်ကြောင့် သင့်တော်သည်နှင့် ၎င်းက မည်သည့်အဆိုကို ထောက်ခံနိုင်သည်ကို ရှင်းလင်းစွာ ဖော်ပြသင့်သည်။ METR ၏ time-horizon evaluation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) သည် ပိုမိုကျယ်ပြန့်ပြီး သင့်တော်စွာ တည်ငြိမ်ထားသော evaluation setup ၏ ဥပမာတစ်ခုဖြစ်သည် - ၎င်းကို evaluation လုပ်သော စနစ်များအနှံ့ နှိုင်းယှဉ်နိုင်သော ရလဒ်များ ထုတ်ပေးရန် ဒီဇိုင်းလုပ်ထားသည်။ METR သည် AI အေးဂျင့်တစ်ခုက သတ်မှတ်ထားသော ယုံကြည်စိတ်ချရမှုအဆင့်တွင် အောင်မြင်မည်ဟု ခန့်မှန်းထားသော လူ့လုပ်ငန်းတစ်ခု၏ ပုံမှန်ကြာချိန်ဟူသော common outcome တစ်ခုကို သတ်မှတ်ထားသည်။ ၎င်းသည် အတူတကွ report လုပ်ထားသော estimate အစုတစ်ခုချင်းစီအတွင်း Triframe and ReAct⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ကဲ့သို့ ပြန်လည်အသုံးပြုနိုင်သော scaffold အနည်းငယ်နှင့်အတူ မျှဝေထားသော task suite၊ scoring method နှင့် fitting method ကို အသုံးပြုသည်။ METR သည် task suite ကို ချဲ့ထွင်ပြီး evaluation infrastructure ကို Vivaria ဟုခေါ်သော framework တစ်ခုမှ Inspect ဟုခေါ်သော framework တစ်ခုသို့ ပြောင်းရွှေ့သောအခါ ၎င်းသည် ထိုပြောင်းလဲမှု (Time Horizon 1.1 update⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)) ကို report လုပ်ခဲ့ပြီး မော်ဒယ်များကို evaluation setup အသစ်အောက်တွင် ပြန်လည် evaluation လုပ်ခဲ့သည်။ ၎င်းသည် တည်ငြိမ်သော evaluation setup ၏ တန်ဖိုးဖြစ်ပြီး၊ တည်ငြိမ်သော harness အစုလည်း ပါဝင်သည် - score ကွာခြားမှုတစ်ခုသည် တိုင်းတာမှု setup ပြောင်းလဲခြင်းမဟုတ်ဘဲ နှိုင်းယှဉ်နေသော စနစ်များအကြား ကွာခြားမှုကို အမှန်တကယ် ထင်ဟပ်ကြောင်း စာဖတ်သူများ ယုံကြည်စေနိုင်သည်။

third party evaluation report များသည် ၎င်းတို့၏ evaluation setup က မည်သည့်အဆိုအမျိုးအစားကို ထောက်ခံရန် ရည်ရွယ်ထားသည်ကို ဖော်ပြရန်၊ စမ်းသပ်ထားသောအရာသည် ထိုကျယ်ပြန့်သော အဆိုကို မည်မျှ နီးကပ်စွာ ထင်ဟပ်သည်ကို ရှင်းပြရန်၊ ရလဒ်ကို ပုံဖော်ပေးသော harness ရွေးချယ်မှုများကို ဖော်ပြရန်၊ evaluation များအကြား ထိုရွေးချယ်မှုများ ပြောင်းလဲသည့်အခါ အသေးစိတ်ဖော်ပြရန်နှင့် ရလဒ်ကို မည်သို့ ထုတ်ပေးခဲ့သည်၊ အဆိုအပေါ် မည်မျှ ယေဘုယျအသုံးချနိုင်သည်ကို ပြသရန် အထောက်အထားများ ထည့်သွင်းရန် ကျွန်ုပ်တို့ အကြံပြုသည်။

မော်ဒယ်များ ပိုမိုစွမ်းဆောင်နိုင်လာသည်နှင့်အမျှ evaluation score များကို အဓိပ္ပာယ်လွဲမှားစွာ နားလည်ရန် ပိုမိုလွယ်ကူလာသည်။ အမှန်တကယ် စွမ်းရည်များနှင့် နှိုင်းယှဉ်လျှင် မော်ဒယ်တစ်ခုက မိမိကို evaluation လုပ်နေကြောင်း သိရှိပြီး မဟာဗျူဟာကျကျ စွမ်းဆောင်ရည် လျှော့ချပါက evaluation score များသည် အတုအယောင် လျော့နည်းသွားနိုင်သည်။ မော်ဒယ်က task၊ တုံ့ပြန်ညွှန်ကြားချက်၊ scorer သို့မဟုတ် harness အတွင်းရှိ shortcut တစ်ခုကို အသုံးချပါက score များသည် မြင့်တက်သွားနိုင်သည်။ ၎င်းတို့သည် contamination (မော်ဒယ်က အဖြေကို လုပ်ငန်းမဖြေရှင်းဘဲ ကြိုတင်သိထားခြင်း သို့မဟုတ် ရှာတွေ့နိုင်ခြင်း) သို့မဟုတ် မရှင်းလင်းသော၊ မှားယွင်းစွာ scoring လုပ်ထားသော၊ မဖြေရှင်းနိုင်သော သို့မဟုတ် မရည်ရွယ်ထားသော shortcut များအပေါ် အားနည်းသော “broken” problem များကြောင့်လည်း လွဲမှားသွားနိုင်သည်။ ထို့ကြောင့် evaluation report များသည် headline score များနှင့်အတူ ဤအန္တရာယ်များအကြောင်း ဆွေးနွေးချက်ကို တွဲဖက်ဖော်ပြသင့်ပြီး၊ ထိုသို့မှသာ score များသည် ရည်ရွယ်ထားသော အပြုအမူကို ထင်ဟပ်မထင်ဟပ် စာဖတ်သူများက အကဲဖြတ်နိုင်မည်ဖြစ်သည်။

Harness များ၊ budget များ၊ tools များ၊ scoring rule များ၊ monitor များနှင့် review procedure များအားလုံးသည် အေးဂျင့်တစ်ခုက ရည်ရွယ်ထားသော လုပ်ငန်းကို ဖြေရှင်းနေသလား၊ ရှောင်နေသလား၊ မှတ်မိထားသလား သို့မဟုတ် ၎င်းကို ကျော်လွှားသည့် လမ်းကြောင်းတစ်ခု ရှာနေသလားဆိုသည်ကို သက်ရောက်စေသည်။ ယုံကြည်စိတ်ချရသော report တစ်ခုသည် ထိုစစ်ဆေးမှုများကို မြင်သာစေသည် - assessment တစ်ခု လည်ပတ်တိုင်း evaluators များသည် ဤအပြုအမူများအတွက် sample များကို ပြန်လည်သုံးသပ်သင့်သည်။

Reward hacking

Reward hacking ဆိုသည်မှာ ရည်ရွယ်ထားသော စွမ်းရည်ကို မထင်ဟပ်သော နည်းလမ်းများဖြင့် evaluation score မြင့်များ ရရှိခြင်းကို ဆိုလိုသည်။ ဤနေရာတွင် စိုးရိမ်ရသည့်အချက်မှာ စနစ်သည် evaluation တိုင်းတာလိုသော အလုပ်ကို အမှန်တကယ် မလုပ်ဘဲ task၊ scorer၊ တုံ့ပြန်ညွှန်ကြားချက် သို့မဟုတ် harness ကို အသုံးချခြင်းဖြင့် credit ရရှိသွားခြင်းဖြစ်သည်။ METR ၏ GPT 5.4 evaluation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) သည် ဤအချက်၏ အရေးပါမှုကို ပြသသည် - ပထမကြည့်တွင် မော်ဒယ်သည် ခန့်မှန်းအားဖြင့် 13 နာရီ time horizon အဖြစ် မှတ်တမ်းတင်လောက်သော နှုန်းဖြင့် task များတွင် အောင်မြင်ခဲ့သော်လည်း၊ လူသား review က ထိုအောင်မြင်မှုအချို့သည် reward hacking မှ လာကြောင်း ပြသခဲ့ပြီး၊ reward hacking မပါသော ဖြစ်ရပ်များကိုသာ ထည့်သွင်းစဉ်းစားရန် ရလဒ်များကို ပြင်ဆင်လိုက်သောအခါ estimate သည် 6 နာရီခန့်သို့ လျော့ကျသွားခဲ့သည်။ evaluators များသည် ထိုသို့သော ပြင်ဆင်မှုများ လိုအပ်မလို အကဲဖြတ်သင့်ပြီး၊ လိုအပ်ပါက ရှင်းလင်းစွာ report လုပ်သင့်သည် - စာဖတ်သူများက မည်သည့် ထင်ရှားသော အောင်မြင်မှုများကို ပယ်ချခဲ့သည်၊ အဘယ်ကြောင့် ပယ်ချခဲ့သည်နှင့် ရလဒ်သည် ထိုဆုံးဖြတ်ချက်အပေါ် မည်မျှ မူတည်သည်ကို မြင်နိုင်သောအခါ စွမ်းရည် estimate သည် ပိုမို အသုံးဝင်လာသည်။

Refusals

မော်ဒယ်များသည် safeguards များကြောင့် စွမ်းရည် evaluation များတွင် စွမ်းဆောင်ရည် လျော့နည်းနိုင်သည်။ မော်ဒယ်တစ်ခုသည် evaluation task များကို ပြီးမြောက်စေမည့်အစား ငြင်းဆိုနေခြင်းကြောင့် ၎င်း၏ အမှန်တကယ် စွမ်းရည်ထက် evaluation စွမ်းဆောင်ရည် နိမ့်နေနိုင်သည်။ ထို့ကြောင့် report များသည် refusals များသည် evaluation ရလဒ်၏ အစိတ်အပိုင်းဖြစ်ခဲ့မဖြစ်ခဲ့ကို ရှင်းပြသင့်ပြီး၊ ဖြစ်ခဲ့ပါက ၎င်းတို့ကြောင့် sample မည်မျှ ထိခိုက်ခဲ့သည်ကိုလည်း ဖော်ပြသင့်သည်။

Contamination

Contamination သည် အများပြည်သူသိ သို့မဟုတ် ပြန်လည်အသုံးပြုထားသော benchmark များ⁠ အတွက် အထူးအရေးကြီးသည်။ လုပ်ငန်းများ၊ အဖြေများ သို့မဟုတ် အလွန်ဆင်တူသော ပုံစံများသည် training data တွင် ပါဝင်နေခြင်း သို့မဟုတ် browsing ပါသော အေးဂျင့်တစ်ခုက ရှာတွေ့နိုင်ခြင်းရှိပါက စွမ်းဆောင်ရည်သည် မော်ဒယ်စွမ်းဆောင်ရည်ထက် မှတ်မိထားခြင်း သို့မဟုတ် retrieval ကို ထင်ဟပ်နေနိုင်သည်။ ဖြစ်နိုင်သည့်နေရာများတွင် evaluators များသည် private သို့မဟုတ် အသစ်တည်ဆောက်ထားသော လုပ်ငန်းများကို ဦးစားပေးသင့်ပြီး၊ မော်ဒယ်များသည် မဖြေရှင်းမီ task-specific အသေးစိတ်များကို ပြန်ထုတ်နေမနေ စမ်းသပ်သင့်သည်။

Broken problems

Broken problem များတွင် မတော်တဆ မဖြေရှင်းနိုင်သော problem တစ်ခုကဲ့သို့ အခြေအနေများ ပါဝင်သည်။ Broken problem များသည် လုံလောက်အောင် မကြာခဏ ဖြစ်ပွားသော⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) အရာများဖြစ်သောကြောင့် စံမှန်ကန်မှုအန္တရာယ်တစ်ခုအဖြစ် ဆက်ဆံသင့်သည်။ ၎င်းတို့တွင် မှားယွင်းသော ground truth၊ မရှင်းလင်းသော တုံ့ပြန်ညွှန်ကြားချက်များ၊ ပျောက်ဆုံးနေသော file များ၊ မတည်ငြိမ်သော service များ၊ မမျှတသော scoring စံနှုန်းများနှင့် hidden answer file များ သို့မဟုတ် ground-truth patch ပါဝင်သော repository history ကဲ့သို့ shortcut များကို ဖော်ထုတ်ပေးသော environment များ ပါဝင်သည်။

Sandbagging

မော်ဒယ် သို့မဟုတ် စနစ်တစ်ခု၏ sandbagging ဆိုသည်မှာ စွမ်းဆောင်ရည်ကောင်းကောင်း ပြသခြင်းသည် ရည်မှန်းချက်တစ်ခုနှင့် ဆန့်ကျင်နေသောအခါ မဟာဗျူဟာကျကျ စွမ်းဆောင်ရည် လျှော့ချခြင်းကို ဆိုလိုသည်။ Apollo ၏ GPT‑5.5 evaluation⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) သည် evaluation score မြင့်များက unlearning ကို ဖြစ်စေနိုင်ခြင်း သို့မဟုတ် deployment ကို တားဆီးနိုင်ခြင်းရှိကြောင်း မော်ဒယ်က နားလည်သော context တစ်ခု ဖန်တီးခြင်းဖြင့် ဤအရာကို စမ်းသပ်ခဲ့သည်။ သို့သော် GPT‑5.5 သည် မှန်ကန်စွာ ဖြေကြားနေဆဲဖြစ်ပြီး၊ မဟာဗျူဟာကျကျ စွမ်းဆောင်ရည် လျှော့ချမှု၏ အပြုအမူဆိုင်ရာ အထောက်အထား အနည်းငယ်သာ ရှိကြောင်း ညွှန်ပြသည်³။ သို့သော် reasoning trace များအပေါ် ၎င်းတို့၏ review က အရေးကြီးသော context ကို ထပ်ဖြည့်ပေးခဲ့သည် - Apollo သည် sandbagging-condition sample များ၏ 52% တွင် alignment-evaluation awareness ၏ အလယ်အလတ် သို့မဟုတ် ထို့ထက်မြင့်သော လက္ခဏာများကို တွေ့ရှိခဲ့ပြီး၊ counterfactual များတွင် 0% ဖြစ်ခဲ့သည်။ ထိုအထောက်အထားသည် ရလဒ်၏ အဓိပ္ပာယ်ဖွင့်ဆိုမှုကို ပိုမိုရှုပ်ထွေးစေသော်လည်း နောက်ဆုံးတွင် စာဖတ်သူများအား signal ပိုမိုပေးသည် - စာဖတ်သူများသည် စိတ်ချရစေသော အပြုအမူရလဒ်နှင့် ၎င်းကို အလွန်အကျွံ အဓိပ္ပာယ်ဖွင့်ဆိုရာတွင် သတိထားရမည့် အကြောင်းရင်း နှစ်ခုစလုံးကို မြင်နိုင်သည်။

အားကောင်းသော အဆိုများအတွက် အပြုအမူကို ထုတ်ဖော်စေမည့် မှန်ကန်သော harness နှင့် ရလဒ် မှန်ကန်ကြောင်း ပြသမည့် validity check များ နှစ်မျိုးစလုံး လိုအပ်သည်။ harness များနှင့် validity check များသည် evaluation ရလဒ်၏ အစိတ်အပိုင်းဖြစ်သည်ဟု ကျွန်ုပ်တို့ ယူဆသည့်အမြင်က လက်တွေ့တွင် third party evaluation များကို မည်သို့ ပံ့ပိုးသည်ကို ပုံဖော်ပေးသည် - 

• ကျွန်ုပ်တို့သည် evaluators များနှင့် သီးခြား maximum-elicitation လမ်းညွှန်ချက်များကို မျှဝေနေသည်။
• OpenAI မော်ဒယ်များအတွက် အနည်းဆုံး common floor အဖြစ် Codex ကို အသုံးပြုရန် capability evaluators များအား ကျွန်ုပ်တို့ တောင်းဆိုနေသည် - စမ်းသပ်မှုများသည် stripped-down model interface တစ်ခုတည်းမှသာ မဟုတ်ဘဲ အသုံးပြုသူများ အားထားဖွယ်ရှိသော agentic interface တူညီမှုမှတစ်ဆင့် အနည်းဆုံး baseline တစ်ခုကို လည်ပတ်သင့်သည်။
• လှည့်ဖြားမှု၊ sandbagging သို့မဟုတ် evaluation awareness ကို အကဲဖြတ်ရန် လိုအပ်သည့်နေရာများတွင် reasoning trace များနှင့် အခြား intermediate artifact များကိုလည်း ကျွန်ုပ်တို့ ရရှိနိုင်အောင် ပြုလုပ်နေသည်။ METR နှင့် Apollo တို့သည် GPT‑5 ကတည်းက OpenAI evaluation များတွင် ဤ access ကို အသုံးပြုခဲ့ကြသည်။ 
• နောက်ဆုံးအနေဖြင့် context management နှင့် tool access မှ retry behavior၊ scoring နှင့် resource budget များအထိ harness ရွေးချယ်မှုများက ရလဒ်များကို မည်သည့်အချိန်နှင့် မည်သို့ အရေးပါစွာ ပြောင်းလဲစေသည်ကို ပိုမိုနက်ရှိုင်းစွာ နားလည်ရန် သုတေသနကို ကျွန်ုပ်တို့ ဦးစားပေးနေသည်။

ဤအကြံပြုချက်များသည် တစ်ဦးချင်း evaluation report များကိုသာ တိုးတက်စေရန်မဟုတ်ဘဲ၊ စွမ်းဆောင်ရည်အမြင့်ဆုံး AI evaluation နှင့် reporting အတွက် ပေါ်ပေါက်လာနေသော နိုင်ငံအဆင့် ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)နှင့် အပြည်ပြည်ဆိုင်ရာ ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်)စံနှုန်းများကိုလည်း အထောက်အကူပြုရန် ရည်ရွယ်ထားသည်။ ရှေ့ဆက်၍ third party evaluation စံနှုန်းများသည် ဆုံးဖြတ်ချက်ချသူများက သီးခြား evaluation များက မည်သည့်အဆိုများကို ထောက်ခံသည်၊ မည်သည့်စနစ်ကို စမ်းသပ်ခဲ့သည်၊ ရလဒ်ကို မည်သို့ ထုတ်ဖော်ခဲ့သည်နှင့် evaluators များက ၎င်း၏ မှန်ကန်မှုကို မည်သို့ စစ်ဆေးခဲ့သည်ကို နားလည်နိုင်ရန် လုံလောက်သော အသေးစိတ်အချက်အလက်များကို တောင်းဆိုသင့်သည်။ agentic စွမ်းရည်များ အရေးပါသော လုပ်ငန်းများပေါ်တွင် စမ်းသပ်နေသော စွမ်းဆောင်ရည်အမြင့်ဆုံး စနစ်များအတွက် အသေးစိတ်အချက်အလက်များတွင် (လုံခြုံရေး သို့မဟုတ် လျှို့ဝှက်ရေး စိုးရိမ်ချက်များကို လိုက်နာ၍) အောက်ပါတို့ ပါဝင်သင့်သည် -

• အဆိုပြုချက်- evaluation သည် စနစ်များကို နှိုင်းယှဉ်နေသလား၊ စွမ်းရည်အမြင့်ဆုံးကို ခန့်မှန်းနေသလား၊ သို့မဟုတ် safeguard များကို စမ်းသပ်နေသလား။
• Evaluation content: evaluation က အမှန်တကယ် မည်သည့် ကျွမ်းကျင်မှုများ၊ အပြုအမူများ သို့မဟုတ် failure mode များကို စမ်းသပ်နေသည်ကို စာဖတ်သူများ နားလည်နိုင်ရန် လုပ်ငန်းများ သို့မဟုတ် လုပ်ငန်းဖြန့်ချိမှုအကြောင်း လုံလောက်သော အသေးစိတ်။
• စမ်းသပ်ထားသော စနစ်: မော်ဒယ်၊ reasoning setting၊ tool access၊ harness နှင့် safeguards။
• Budget: turn များ၊ token များ၊ attempts/retries၊ wall-clock time၊ inference cost နှင့် သက်ဆိုင်သည့်နေရာများတွင် အောင်မြင်စွာ ဖြေရှင်းမှုတစ်ခုလျှင် မျှော်မှန်းကုန်ကျစရိတ်။
• Elicitation methods: ရလဒ်ကို ထုတ်ဖော်ရန် အသုံးပြုသော harness ရွေးချယ်မှုများနှင့် စမ်းသပ်ထားသောအရာသည် ပြုလုပ်နေသော ပိုမိုကျယ်ပြန့်သော အဆိုကို မည်မျှ နီးကပ်စွာ ထင်ဟပ်သည်။
• Validity checks: assessors များက reward hacking၊ evaluation awareness၊ contamination၊ refusals၊ sandbagging နှင့် ရလဒ်ကို ထိခိုက်စေနိုင်သော အခြားအပြုအမူများကို မည်သို့ ရှာဖွေခဲ့သည်၊ အတည်ပြုထားသော ဖြစ်ရပ်များက scoring သို့မဟုတ် အဓိပ္ပာယ်ဖွင့်ဆိုမှုအပေါ် မည်သို့ သက်ရောက်ခဲ့သည်တို့ ပါဝင်သည်။

harness ရွေးချယ်မှုများ သို့မဟုတ် validity check များကို ချန်လှပ်ထားသော စံနှုန်းများသည် စနစ်တစ်ခု လုပ်နိုင်သောအရာကို လျော့နည်းဖော်ပြနိုင်သကဲ့သို့ လုံခြုံရေးဆိုင်ရာ အဆိုတစ်ခုအပေါ် ယုံကြည်မှုကိုလည်း ပိုမိုမြင့်မားစွာ ဖော်ပြနိုင်သည်။ အားကောင်းသော harness များနှင့် elicitation method များ တည်ဆောက်ခြင်းသည် ဖွင့်လှစ်ထားဆဲ သုတေသနနယ်ပယ်တစ်ခုဖြစ်ပြီး နောက်ထပ် စုံစမ်းလေ့လာမှုနှင့် ရင်းနှီးမြှုပ်နှံမှုအတွက် အာရုံစိုက်သင့်သော အချက်တစ်ခုဖြစ်သည်။