ကုဒ်အကဲဖြတ်မှုတွင်အရေးကြီးအချက်နှင့်အနှောင့်အယှက်ကို ခွဲခြားခြင်း

ကျွန်ုပ်တို့၏ မော်ဒယ်များ၏ စွမ်းဆောင်ရည်များကို တိကျစွာ တိုင်းတာခြင်းသည် OpenAI ၏ ကြိုတင်ပြင်ဆင်ထားခြင်းဆိုင်ရာ ဖွဲ့စည်းမှု⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) အောက်ရှိ ဆုံးဖြတ်ချက်များအပါအဝင် အသုံးချမှုနှင့် ဘေးကင်းရေးဆိုင်ရာ ဆုံးဖြတ်ချက်များ ခိုင်မာမှန်ကန်ရန် အရေးကြီးသည်။ မော်ဒယ် ထုတ်ဝေမှုတိုင်းတွင် မော်ဒယ်တိုးတက်မှုကို ခြေရာခံရန် ပြင်ပနှင့် အတွင်း benchmark အမျိုးမျိုးအတွက် ရလဒ်များကို ကျွန်ုပ်တို့ အစီရင်ခံသည်။ ရလဒ်များကို သက်ရောက်စေသော အကဲဖြတ်မှုချို့ယွင်းချက်များရှိပါက ၎င်းတို့သည် စွမ်းဆောင်ရည်များကို မှားယွင်းနားလည်စေပြီး ဘေးကင်းရေးဆိုင်ရာ အကြောင်းပြချက်များကို မှားယွင်းတင်ပြကာ သုတေသနဦးစားပေးများကို ထိခိုက်စေနိုင်သည်။

ကျွန်ုပ်တို့သည် အသုံးအများဆုံး ကုဒ်ရေး benchmark များထဲမှတစ်ခုဖြစ်သော SWE-bench Verified တွင် အခြေခံဒီဇိုင်းနှင့် contamination ပြဿနာများရှိကြောင်း မကြာသေးမီက စုံစမ်းလေ့လာခဲ့ပြီး ထို eval သည် ဆော့ဖ်ဝဲဖွံ့ဖြိုးရေးစွမ်းဆောင်ရည်များအပေါ် အဓိပ္ပါယ်ရှိသော အချက်ပြကို မပေးတော့ကြောင်း တွေ့ရှိခဲ့သည်။ ထိုအချိန်တွင် ကျွန်ုပ်တို့သည် ပိုမိုကျယ်ပြန့်သော အသိုင်းအဝိုင်းအား SWE-Bench Pro သို့ ပြောင်းလဲအသုံးပြုရန် တိုက်တွန်းခဲ့သည်။

SWE-Bench Pro⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ကို မော်ဒယ်များအား ပိုရှည်လျားသော အချိန်ပိုင်းများနှင့် ပိုမိုလက်တွေ့ကျသော ကုဒ်ရေးလုပ်ငန်းများပေါ်တွင် စမ်းသပ်၍ agentic coding စွမ်းဆောင်ရည်များကို ပိုကောင်းစွာ ခြေရာခံနိုင်ရန် SWE-bench Verified ထက် ပိုမိုတိုးတက်စေရန် ဒီဇိုင်းဆွဲထားသည်။ SWE-bench Verified ကဲ့သို့ပင် လုပ်ငန်းများကို အများပြည်သူသုံးနှင့် ပုဂ္ဂလိက သိမ်းဆည်းရန်နေရာ အစုတစ်ခုအတွင်း feature ပြောင်းလဲမှုမှတ်တမ်းများမှ ပရိုဂရမ်နည်းဖြင့် ရယူထားသည်။ မော်ဒယ်များသည် ရှိပြီးသား လုပ်ဆောင်ချက်များကို မချိုးဖောက်ဘဲ feature တစ်ခုအတွက် စမ်းသပ်မှုအသစ်များကို အောင်မြင်စေမည့် ဖြေရှင်းချက်တစ်ခုကို အကောင်အထည်ဖော်ရန် လိုအပ်သည်။ လုပ်ငန်း ၇၃၁ ခုပါ အများပြည်သူသုံး split တွင် စွမ်းဆောင်ရည်အမြင့်ဆုံး မော်ဒယ်များသည် ရှစ်လအတွင်း အောင်မြင်နှုန်း ၂၃.၃% မှ ၈၀.၃% အထိ တိုးတက်ခဲ့သည်။

ထို့နောက် ကျွန်ုပ်တို့သည် SWE-Bench Pro ပေါ်တွင်လည်း အလားတူ စစ်ဆေးမှုတစ်ခု ပြုလုပ်ကာ datapoint ခွဲခြမ်းစိတ်ဖြာရေး ပိုက်လိုင်းဖြင့် dataset ကို သုံးသပ်ခဲ့ပါသည်။ ထိုပိုက်လိုင်းသည် ဖြစ်နိုင်ချေရှိသော အကဲဖြတ်မှုချို့ယွင်းချက်များကို အမှတ်အသားပြုရန် လုပ်ငန်းပေါ်ရှိ မော်ဒယ်ကြိုးပမ်းချက်များ၊ လုပ်ငန်း metadata နှင့် မအောင်မြင်မှု traces များကို သုံးသပ်ခဲ့ပါသည်။ အမှတ်အသားပြုထားသော လုပ်ငန်းတစ်ခုစီကို စုံစမ်းစစ်ဆေးသူ-အေးဂျင့် အကြိမ်များစွာဖြင့် အကဲဖြတ်ပြီး အတွေ့အကြုံရှိ ဆော့ဖ်ဝဲအင်ဂျင်နီယာ ငါးဦးက သီးခြားသုံးသပ်ခဲ့ကာ သဘောထားကွဲလွဲမှုများကို ထပ်မံစုံစမ်းရန် တင်ပြခဲ့ပါသည်။

ပြဿနာများသည် အဓိကအားဖြင့် အမျိုးအစားလေးမျိုးသို့ ကျရောက်သည်။

• အလွန်တင်းကျပ်သော စမ်းသပ်မှုများ¹ သည် တုံ့ပြန်ညွှန်ကြားချက်တွင် မသတ်မှတ်ထားသော သီးခြားအကောင်အထည်ဖော်မှုအသေးစိတ်များကို အတင်းလိုက်နာစေပြီး လုပ်ဆောင်ချက်အရ မှန်ကန်သော တင်သွင်းမှုများစွာကို မမှန်ကန်တော့စေသည်။
• အသေးစိတ်မပြည့်စုံသော တုံ့ပြန်ညွှန်ကြားချက်များ² သည် ဝှက်ထားသော စမ်းသပ်မှုများက အတင်းလိုက်နာစေပြီး ကျိုးကြောင်းဆီလျော်စွာ ခန့်မှန်း၍မရနိုင်သော လိုအပ်ချက်များကို ချန်လှပ်ထားသည်။
• လွှမ်းခြုံမှုနည်းသော စမ်းသပ်မှုများ သည် တောင်းဆိုထားသော feature ကို လုံလောက်စွာ မစစ်ဆေးသောကြောင့် မပြည့်စုံသော ပြင်ဆင်မှုများ အောင်မြင်နိုင်သည်။
• လမ်းမှားညွှန်သော တုံ့ပြန်ညွှန်ကြားချက် သည် မော်ဒယ်များကို မှားယွင်းသော အပြုအမူဆီ ဦးတည်စေသည် သို့မဟုတ် စမ်းသပ်မှုများလိုအပ်သည့်အရာနှင့် ဆန့်ကျင်နေသည်။

ကျွန်ုပ်တို့၏ တွေ့ရှိချက်များသည် ခက်ခဲသော်လည်း တရားမျှတသော benchmark များကို စုစည်းပြင်ဆင်ရန် ခက်ခဲမှုနှင့် အတိုင်းအတာချဲ့နိုင်သော ဒေတာအရည်အသွေးစစ်ဆေးမှုများအတွက် အေးဂျင့်များ၏ အသုံးဝင်မှု တိုးလာခြင်းကို ထောက်ပြသည်။ ဤရလဒ်များအရ SWE-bench Pro လုပ်ငန်းများ၏ ~30% ခန့်သည် ချို့ယွင်းနေသည်ဟု ကျွန်ုပ်တို့ ခန့်မှန်းပြီး မော်ဒယ်ဖွံ့ဖြိုးသူများအနေဖြင့် ရလဒ်များကို ဂရုတစိုက် စစ်ဆေးရန် အကြံပြုသည်။

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

ကနဦး အလိုအလျောက် filter သည် မော်ဒယ်အား ပေးထားသော ညွှန်ကြားချက်များ၊ လုပ်ငန်းကို ဖြေရှင်းရန် မော်ဒယ်၏ ကြိုးပမ်းချက်များနှင့် ထိုကြိုးပမ်းချက်များကို အမှတ်ပေးရာတွင် အသုံးပြုသော စမ်းသပ်မှုများကို သုံးသပ်ပြီး ချို့ယွင်းနိုင်ခြေ သို့မဟုတ် ပြဿနာရှိနိုင်ခြေရှိသော ဥပမာများကို အမှတ်အသားပြုသည်။ ဤ filter သည် ချို့ယွင်းနိုင်ခြေရှိသော လုပ်ငန်း ၂၈၆ ခုကို အမှတ်အသားပြုခဲ့သည်။ ထို့နောက် ထို subset ကို နည်းလမ်းနှစ်မျိုးဖြင့် ပိုမိုနက်ရှိုင်းစွာ သုံးသပ်ခဲ့သည်။ စုံစမ်းစစ်ဆေးသူ အေးဂျင့်များဖြင့် ကျယ်ကျယ်ပြန့်ပြန့် စစ်ဆေးပြီး နောက်ဆုံး လူသားဆုံးဖြတ်ချက်ပါဝင်သော လူသားကြီးကြပ်သည့် အေးဂျင့်သုံးသပ်မှု၊ နှင့် အတွေ့အကြုံရှိ ဆော့ဖ်ဝဲဖွံ့ဖြိုးသူများနှင့် လုပ်ဆောင်သည့် လူသားအမှတ်အသားပြု ကမ်ပိန်းတို့ဖြစ်သည်။

အမှတ်အသားပြုထားသော ပြဿနာတစ်ခုစီကို လုပ်ငန်း သိမ်းဆည်းရန်နေရာနှင့် ပတ်ဝန်းကျင်သို့ ဝင်ရောက်ခွင့်ပေးထားသည့် Codex အခြေပြု စုံစမ်းစစ်ဆေးသူ အေးဂျင့်များဖြင့် စစ်ဆေးသည်။ ၎င်းက ၎င်းတို့အား အနီးအနားရှိ code နှင့် သိမ်းဆည်းရန်နေရာ ထုံးတမ်းစဉ်လာများကို လေ့လာခြင်းဖြင့် မကြာခဏ ဖြေရှင်းနိုင်သော ကျိုးကြောင်းဆီလျော်သည့် လုပ်ငန်းမရှင်းလင်းမှုနှင့် အမှန်တကယ် အသေးစိတ်မပြည့်စုံမှုကို ခွဲခြားနိုင်စေသည်။ အေးဂျင့်သည် စမ်းသပ်မှုများကို လည်ပတ်စေနိုင်သည်၊ repo အတွင်းရှိ ဖိုင်များကို စစ်ဆေးနိုင်သည်၊ မော်ဒယ်ကြိုးပမ်းချက်များနှင့် လုပ်ငန်းပေါ်ရှိ ၎င်းတို့၏ အဖြစ်များသော မအောင်မြင်မှုပုံစံများကို စုံစမ်းနိုင်သည်။ ဤပိုမိုနက်ရှိုင်းသော စစ်ဆေးမှုများကို သီးခြားအကြိမ်များစွာ ထပ်လုပ်ပြီးနောက် သုတေသီတစ်ဦးက အနှစ်ချုပ်များကို သုံးသပ်ကာ နောက်ဆုံးဆုံးဖြတ်ချက် ချမှတ်ပြီး ဖြစ်နိုင်ချေရှိသော ပြဿနာများကို label တပ်ခဲ့သည်။

တစ်ပြိုင်နက်တည်းတွင် ကျွန်ုပ်တို့သည် အမှတ်အသားပြုထားသော subset ပေါ်တွင် လူသားအမှတ်အသားပြု ကမ်ပိန်းတစ်ခုကို လုပ်ဆောင်ခဲ့သည်။ လုပ်ငန်းများကို မသုံးသပ်မီ benchmark ရည်မှန်းချက်များ၊ ပြဿနာ taxonomy နှင့် အနားစွန်းကိစ္စများအကြောင်း လေ့ကျင့်ပေးထားသော အတွေ့အကြုံရှိ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများနှင့် ကျွန်ုပ်တို့ လုပ်ဆောင်ခဲ့သည်။ လုပ်ငန်းတစ်ခုစီကို အင်ဂျင်နီယာ ငါးဦးက သုံးသပ်ခဲ့သည်။

သုံးသပ်သူများသည် ပိုက်လိုင်းခွဲခြမ်းစိတ်ဖြာချက် သို့မဟုတ် transcript ကို အထောက်အကူပြုအခြေအနေအဖြစ် မသုံးမီ မြင်နိုင်သော ပြဿနာဖော်ပြချက်၊ စမ်းသပ်ကိစ္စများနှင့် ground-truth reference solution (gold patch ဟု သိကြသည်) တို့မှ သီးခြားဆုံးဖြတ်ချက်တစ်ခု ချမှတ်ခဲ့ကြသည်။ ထို့နောက် သုံးသပ်သူများသည် ခိုင်မာသော အထောက်အထားအပေါ် မူတည်၍ label နှင့် ပြင်းထန်မှုအဆင့်ကို သတ်မှတ်ပြီး သဘောထားကွဲလွဲမှုများ သို့မဟုတ် ယုံကြည်မှုနည်းသော ကိစ္စများကို ထပ်မံသုံးသပ်ရန် တင်ပြခဲ့သည်။

လူသားသုံးသပ်သူများသည် စုံစမ်းစစ်ဆေးသူ အေးဂျင့်များထက် လုပ်ငန်းများကို ချို့ယွင်းနေသည်ဟု အမှတ်အသားပြုနိုင်ခြေ ပိုများခဲ့သည်။ သုံးသပ်လမ်းကြောင်းနှစ်ခုကြားတွင် အမျိုးအစားများနှင့် ပတ်သက်၍ သဘောထားကွဲလွဲမှုအချို့လည်း ရှိခဲ့သော်လည်း အမှတ်အသားပြုထားသော လုပ်ငန်းတစ်ခုမျှတွင် “မချို့ယွင်း” သည် လူသား label အများဆုံးမဟုတ်ခဲ့ပါ။ အေးဂျင့် ပိုက်လိုင်းက အမှတ်အသားပြုခဲ့သော အမျိုးအစားများတွင် သုံးသပ်သူများ၏ ဆုံးဖြတ်ချက်များသည် ကိစ္စများ၏ ၇၄% တွင် ထပ်တူကျခဲ့သည်။

အေးဂျင့် ပိုက်လိုင်းနှင့် နှိုင်းယှဉ်ပါက လူသားသုံးသပ်သူများသည် လုပ်ငန်းတစ်ခုအတွက် label များစွာ ရွေးချယ်နိုင်ခြေ ပိုများခဲ့ပြီး ၎င်းတို့က လုပ်ငန်းများကို နည်းလမ်းများစွာဖြင့် ချို့ယွင်းနေသည်ဟု တွေ့ရှိခြင်း သို့မဟုတ် အမျိုးအစားတစ်ခုတည်းအတွင်း သန့်ရှင်းစွာ မကိုက်ညီခြင်းကို ပြသသည်။ ဤအချက်က အေးဂျင့်-သုံးသပ်သူ ပိုက်လိုင်းသည် သတိထားပြီး label တပ်သည့် ရလဒ်ကို ပေးခဲ့ကြောင်း ညွှန်ပြသည်။ ၎င်းသည် လူသားများ ဖော်ထုတ်ခဲ့သော ကျယ်ပြန့်သည့် မအောင်မြင်မှုပုံစံများကို ဖမ်းယူနိုင်ခဲ့သော်လည်း သုံးသပ်သူများက ထပ်ဆောင်း သို့မဟုတ် ထပ်နေသော ပြဿနာများကို မြင်ခဲ့သည့် ကိစ္စများကို လျော့တွက်ခဲ့သည်။ အကြီးမားဆုံး ကွာခြားချက်မှာ လွှမ်းခြုံမှုနည်းသော စမ်းသပ်မှုများတွင် ဖြစ်ပြီး လူသားများက ၎င်းကို benchmark ၏ ၉.၄% အတွက် အဖြစ်များဆုံး ပြဿနာအဖြစ် ရွေးချယ်ခဲ့ကြကာ အေးဂျင့် ပိုက်လိုင်းမှ ၄.၁% နှင့် နှိုင်းယှဉ်နိုင်သည်။

ကျွန်ုပ်တို့ ဖော်ထုတ်ထားသော ပြဿနာများသည် SWE-bench Verified ရှိ အလားတူကိစ္စများနှင့် ပေါင်းစပ်ပြီး benchmark များကို တင်းကျပ်စွာ စစ်ဆေးရန် အရေးကြီးကြောင်း မီးမောင်းထိုးပြသည်။ open-source သိမ်းဆည်းရန်နေရာ များမှ issue နှင့် pull request များကို မူလက လူသားများ ပူးပေါင်းဆောင်ရွက်ရန် ဖန်တီးထားခြင်းဖြစ်ပြီး မကြာခဏ maintainer များနှင့် contributor များအကြား ရှည်လျားသော အပြန်အလှန်ဆွေးနွေးမှုများမှတစ်ဆင့် ဖြစ်ပေါ်သည်။ ထို့ကြောင့် ပြဿနာဖော်ပြချက်များ၊ ပေါင်းထည့်ထားသော code နှင့် unit test များသည် မော်ဒယ်များကို ယုံကြည်စိတ်ချစွာ အကဲဖြတ်ရန် သန့်ရှင်းပြီး သီးခြားဖြစ်သော လုပ်ငန်းများအဖြစ် အမြဲတမ်း မကိုက်ညီနိုင်ပါ။ အထူးသဖြင့် pull request များတွင် ပါဝင်သော စမ်းသပ်မှုများသည် လုပ်ငန်းကို ဖြေရှင်းရန် အကောင်အထည်ဖော်နည်းမမှီခိုသော စံတစ်ခုကို သတ်မှတ်ရန် မဟုတ်ဘဲ သီးခြားပြောင်းလဲမှုတစ်ခုကို အတည်ပြုရန် ရေးသားထားသောကြောင့် အလွန်တင်းကျပ်နိုင်သည်။

တစ်ချိန်တည်းတွင် အကဲဖြတ်မှုချို့ယွင်းချက်များကို ယခင် မကြာသေးမီကာလနှင့်ပင် နှိုင်းယှဉ်လျှင် ယခုအခါ ပိုမိုလွယ်ကူစွာ ဖော်ထုတ်နိုင်လာသည်။ မော်ဒယ်စွမ်းဆောင်ရည်များ တိုးတက်လာသည်နှင့်အမျှ ကျွန်ုပ်တို့သည် ထိုမော်ဒယ်များကို အသုံးပြု၍ တုံ့ပြန်ညွှန်ကြားချက်များ၊ စမ်းသပ်မှုများ၊ patch များ၊ trace များနှင့် အနားစွန်းကိစ္စများကို ပိုမိုနက်ရှိုင်း၍ တသမတ်တည်း စစ်ဆေးနိုင်ကာ ယခင်က အတိုင်းအတာချဲ့၍ ရှာဖွေရန် ကုန်ကျစရိတ်များသော သို့မဟုတ် လက်တွေ့မကျသော benchmark ပြဿနာများကို ဖော်ထုတ်နိုင်ရန် ကူညီပေးသည်။

ပိုမိုကျယ်ပြန့်သော အကဲဖြတ်မှုအသိုင်းအဝိုင်းသည် မော်ဒယ်စွမ်းဆောင်ရည်များကို စမ်းသပ်ရန် အထူးရည်ရွယ်၍ အတွေ့အကြုံရှိ ဆော့ဖ်ဝဲဖွံ့ဖြိုးသူများက တည်ဆောက်သော benchmark အသစ်များကို ဖန်တီးမည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်သည်။ ထိုနည်းလမ်းသည် မော်ဒယ်စွမ်းဆောင်ရည်များကို တိုင်းတာရာတွင် ကျွန်ုပ်တို့ လိုလားသော မြင့်မားသည့် စံနှုန်းနှင့် လက်တွေ့ကျမှုကို ထိန်းသိမ်းနိုင်ပြီး လုပ်ငန်းစဉ်တစ်လျှောက် လူသားကြီးကြပ်မှု ပိုကောင်းစေသည်။ ဤခွဲခြမ်းစိတ်ဖြာမှုတွင် တွေ့ရှိထားသော ပြဿနာများကြောင့် SWE-Bench Pro ကို အသုံးပြုရန် ကျွန်ုပ်တို့၏ ယခင်အကြံပြုချက်ကို ပြန်လည်ရုပ်သိမ်းသည်။

နောက်ဆုံးတွင် eval တစ်ခုသည် လွယ်ကူစွာ game လုပ်၍မရ၊ ယုံကြည်ရန် လွယ်ကူပြီး မော်ဒယ်စွမ်းဆောင်ရည် သို့မဟုတ် alignment ကို အမှန်တကယ် ထင်ဟပ်သော benchmark များမှတစ်ဆင့် အဓိပ္ပါယ်ရှိသော အချက်ပြကို ပေးသင့်သည်။ ဤရလဒ်များသည် OpenAI ၏ အသုံးချမှုနှင့် ဘေးကင်းရေးဆုံးဖြတ်ချက်များကို အထောက်အကူပြုသောကြောင့် ကျွန်ုပ်တို့ ခြေရာခံသော eval များသည် မှန်ကန်ပြီး အသိပေးနိုင်စွမ်းရှိရန် လိုအပ်သည်။