gpt-oss-safeguard ကို မိတ်ဆက်ခြင်း

ယနေ့တွင် safety classification လုပ်ငန်းများအတွက် ကျွန်ုပ်တို့၏ open-weight ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသော မော်ဒယ်များဖြစ်သော gpt-oss-safeguard ၏ research preview ကို ထုတ်ပြန်လိုက်ပါသည်။ ၎င်းကို အရွယ်အစားနှစ်မျိုးဖြင့် ရရှိနိုင်ပြီး gpt-oss-safeguard-120b နှင့် gpt-oss-safeguard-20b ဟူ၍ ဖြစ်ပါသည်။ ဤမော်ဒယ်များသည် ကျွန်ုပ်တို့၏ gpt-oss⁠ အများသုံးနိုင်ရန် ပြုလုပ်ပေးထားသော မော်ဒယ်များ၏ fine-tuned version များဖြစ်ပြီး၊ မည်သူမဆို လွတ်လပ်စွာ အသုံးပြု၊ ပြင်ဆင်၊ deploy လုပ်နိုင်စေရန် တူညီသော permissive Apache 2.0 license အောက်တွင် ရရှိနိုင်ပါသည်။ မော်ဒယ်နှစ်မျိုးလုံးကို ယနေ့မှစ၍ Hugging Face⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) မှ ဒေါင်းလုဒ်လုပ်နိုင်ပါသည်။

gpt-oss-safeguard မော်ဒယ်များသည် inference အချိန်တွင် developer ပေးထားသော policy ကို တိုက်ရိုက်အဓိပ္ပာယ်ဖော်ရန် reasoning ကို အသုံးပြုကာ user message များ၊ completion များနှင့် chat အပြည့်အစုံတို့ကို developer ၏ လိုအပ်ချက်များနှင့်အညီ အမျိုးအစားခွဲပေးသည်။ မည်သည့် policy ကို အသုံးပြုမည်ဆိုသည်ကို developer က အမြဲဆုံးဖြတ်သည့်အတွက် response များသည် developer ၏ use case နှင့် ပိုမိုကိုက်ညီပြီး အံဝင်ခွင်ကျဖြစ်လာသည်။ မော်ဒယ်သည် အတွေးကွင်းဆက် ကို အသုံးပြုထားပြီး developer က ၎င်းကို ပြန်လည်စစ်ဆေးကာ မော်ဒယ်က မည်သို့ဆုံးဖြတ်ချက်ချနေသည်ကို နားလည်နိုင်ပါသည်။ ထို့အပြင် policy ကို မော်ဒယ်အတွင်း train လုပ်ထားခြင်းမဟုတ်ဘဲ inference အချိန်တွင် ပေးထားသဖြင့် developer များအနေဖြင့် performance မြှင့်တင်ရန် policy များကို iteration အလိုက် လွယ်ကူစွာ ပြန်လည်ပြင်ဆင်နိုင်ပါသည်။ အစပိုင်းတွင် ကျွန်ုပ်တို့၏ internal use အတွက် တီထွင်ခဲ့သော ဤနည်းလမ်းသည် labeled example အများအပြားမှ decision boundary ကို သွယ်ဝိုက်ကောက်ယူရန် classifier တစ်ခုကို train လုပ်သည့် ရိုးရာနည်းလမ်းထက် သိသိသာသာ ပိုမိုပြောင်းလွယ်ပြင်လွယ်ရှိပါသည်။

gpt-oss-safeguard သည် developer များအား ၎င်းတို့၏ use case နှင့် အကောင်းဆုံးကိုက်ညီသော policy line များကို ကိုယ်တိုင်သတ်မှတ်နိုင်စေပါသည်။ ဥပမာအားဖြင့် video game ဆွေးနွေးရေး forum တစ်ခုသည် ဂိမ်းအတွင်း cheating အကြောင်း ဆွေးနွေးသည့် post များကို အမျိုးအစားခွဲရန် policy တစ်ခု ဖန်တီးချင်နိုင်ပြီး၊ product review site တစ်ခုသည် fake ဖြစ်နိုင်ချေရှိသော review များကို စစ်ဆေးရန် ၎င်း၏ ကိုယ်ပိုင် policy ကို အသုံးပြုချင်နိုင်ပါသည်။

မော်ဒယ်သည် input နှစ်ခုကို တစ်ပြိုင်နက်လက်ခံသည်—policy တစ်ခုနှင့် ထို policy အောက်တွင် အမျိုးအစားခွဲရမည့် content—ပြီးနောက် ၎င်း content သည် မည်သည့်နေရာတွင် ကျရောက်သည်ဆိုသော အဆုံးသတ်ချက်ကို reasoning နှင့်အတူ ထုတ်ပေးပါသည်။ Developer များက ထိုအဆုံးသတ်ချက်များကို ၎င်းတို့၏ safety pipeline များတွင် မည်သို့ အသုံးပြုမည်၊ သို့မဟုတ် အသုံးမပြုမည်ကို ကိုယ်တိုင်ဆုံးဖြတ်ကြသည်။ ဤ reasoning-based နည်းလမ်းသည် အထူးသဖြင့် အောက်ပါအခြေအနေများတွင် ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်သည်ကို ကျွန်ုပ်တို့ တွေ့ရှိထားပါသည်-

• ဖြစ်ပေါ်လာနိုင်သော အန္တရာယ်သည် အသစ်ပေါ်ထွက်လာခြင်း သို့မဟုတ် ပြောင်းလဲနေခြင်းဖြစ်ပြီး policy များကို လျင်မြန်စွာ လိုက်လျောညီထွေ ပြင်ဆင်ရန် လိုအပ်သောအခါ။
• domain သည် အလွန်နူးညံ့ရှုပ်ထွေးပြီး classifier အသေးများအတွက် ကိုင်တွယ်ရန် ခက်ခဲသောအခါ။
• platform ပေါ်ရှိ risk တစ်ခုချင်းစီအတွက် အရည်အသွေးမြင့် classifier တစ်ခု train လုပ်ရန် developer များတွင် sample အလုံအလောက် မရှိသောအခါ။
• latency ထက် အရည်အသွေးမြင့်ပြီး ရှင်းပြနိုင်သော label များ ထုတ်ပေးခြင်းက ပိုအရေးကြီးသောအခါ။

သုတေသနနှင့် safety community ထံမှ feedback ရယူပြီး မော်ဒယ် performance ကို ထပ်မံ iterate လုပ်နိုင်ရန် gpt-oss-safeguard ၏ ဤ preview ကို ကျွန်ုပ်တို့ ထုတ်ပြန်ခြင်းဖြစ်ပါသည်။ လအတော်ကြာအတွင်း ကျွန်ုပ်တို့သည် developer များ၏ အရေးကြီးလိုအပ်ချက်များကို ဖော်ထုတ်ရန်၊ မော်ဒယ်ကို စမ်းသပ်ရန်နှင့် developer documentation များ ထုတ်လုပ်ရန် ROOST⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) နှင့်အတူ ဤ open weight release ကို ဆောင်ရွက်ခဲ့ပါသည်။ ဤ launch ၏ အစိတ်အပိုင်းတစ်ရပ်အနေဖြင့် ROOST သည် online space များကို ကာကွယ်ရန် open AI မော်ဒယ်များကို စူးစမ်းလေ့လာမည့် model community⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တစ်ခုကို ထူထောင်မည်ဖြစ်ပြီး၊ ၎င်းကိုလည်း ယနေ့ စတင်မိတ်ဆက်ပါသည်။ ဤ release နှင့်အတူ ဤ preview model ၏ safety performance ကို အသေးစိတ်ဖော်ပြထားသော technical report⁠ တိုတစ်စောင်ကိုလည်း ကျွန်ုပ်တို့ ထုတ်ဝေထားပါသည်။

Safety နှင့်ပတ်သက်လာလျှင် ကျွန်ုပ်တို့သည် defense in depth⁠ ကို ယုံကြည်ပါသည်။ ကျွန်ုပ်တို့၏ မော်ဒယ်များကို လုံခြုံစွာ တုံ့ပြန်နိုင်အောင် train လုပ်သကဲ့သို့၊ policy များအရ အန္တရာယ်ရှိနိုင်သော input နှင့် output များကို ရှာဖွေဖော်ထုတ်ပြီး ကိုင်တွယ်ရန် နောက်ထပ် ကာကွယ်ရေးအလွှာများကိုလည်း အကောင်အထည်ဖော်ထားပါသည်။ Risk area တစ်ခုအတွင်း safe content နှင့် unsafe content ကို ခွဲခြားပေးသော safety classifier များသည် ကျွန်ုပ်တို့၏ မော်ဒယ်ကြီးများနှင့် အခြား large language model များအတွက် အဓိကကာကွယ်ရေးအလွှာတစ်ခုအဖြစ် ကြာမြင့်စွာ ရှိလာခဲ့ပါသည်။

ကျွန်ုပ်တို့၏ Moderation API⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) မှတစ်ဆင့် ရရှိနိုင်သည့် traditional safety classifier များကို ကြိုတင်သတ်မှတ်ထားသော safety policy များအောက်တွင် safe content နှင့် unsafe content ၏ example ထောင်ပေါင်းများစွာကို လက်ဖြင့်ရွေးချယ်စုစည်းကာ တီထွင်ထားပါသည်။ ဤ training data မှ classifier သည် safe output နှင့် unsafe output ကို ခွဲခြားနားလည်လာသည်။ ဤရိုးရာနည်းလမ်းတွင် classifier သည် safety policy ကို တကယ်မမြင်ရပါ။ ၎င်းအစား unsafe ဟု label တပ်ထားသော content များအတွင်း ဆင်တူမှုများနှင့် unsafe content နှင့် safe content အကြား ကွာခြားချက်များကို ရှာဖွေခြင်းဖြင့် example များကို label တပ်ရာတွင် အသုံးပြုခဲ့သော အခြေခံ policy ကို ခန့်မှန်းရန် ကြိုးစားပါသည်။

Traditional classifier များသည် latency နည်းပြီး operating cost နည်းသဖြင့် performance မြင့်မားနိုင်ပါသည်။ သို့သော် training example အရေအတွက် လုံလောက်စွာ စုဆောင်းခြင်းသည် အချိန်ကုန်ပြီး ကုန်ကျစရိတ်များနိုင်ကာ policy ကို update လုပ်ခြင်း သို့မဟုတ် ပြောင်းလဲခြင်းအတွက် classifier ကို ပြန်လည် train လုပ်ရပါသည်။

gpt-oss-safeguard သည် မတူကွဲပြားသည်။ အကြောင်းမှာ ၎င်း၏ reasoning capability များကြောင့် developer များသည် မည်သည့် policy ကိုမဆို—၎င်းတို့ကိုယ်တိုင် ရေးသားထားသော policy များ သို့မဟုတ် အခြားရင်းမြစ်များမှ ယူလာသော policy များအပါအဝင်—အသုံးချနိုင်ပြီး reasoning က မော်ဒယ်များကို အသစ်ရေးသားထားသော policy များပေါ်တွင်လည်း generalize လုပ်နိုင်ရန် ကူညီပေးသောကြောင့်ဖြစ်ပါသည်။ Safety policy များအပြင် gpt-oss-safeguard ကို ထုတ်ကုန်များနှင့် platform များအတွက် အရေးကြီးသော အခြားနည်းလမ်းများဖြင့် content ကို label တပ်ရန်လည်း အသုံးပြုနိုင်ပါသည်။

ယခုအခါ ကျွန်ုပ်တို့၏ အဓိက reasoning မော်ဒယ်များသည် ကျွန်ုပ်တို့၏ safety policy များကို တိုက်ရိုက် သင်ယူထားပြီး၊ ဘာသည် safe ဖြစ်သည်ကို ၎င်းတို့၏ reasoning capability များဖြင့် ဆင်ခြင်သုံးသပ်ပါသည်။ ကျွန်ုပ်တို့က စဉ်းစားဆုံးဖြတ်ပြီး ကိုက်ညီစေမှု⁠ ဟု ခေါ်သော ဤနည်းလမ်းသည် ယခင် safety training နည်းလမ်းများထက် သိသိသာသာ ပိုမိုကောင်းမွန်ပြီး၊ capability များ မြင့်တက်လာသည့်အချိန်တွင်ပင် reasoning မရှိသော ၎င်းတို့၏ ရှေ့မျိုးဆက်များထက် safety အချက်အချာများစွာတွင် ပိုမိုလုံခြုံစေပါသည်။ သို့သော် reasoning သည် မော်ဒယ်များကိုယ်တိုင် train လုပ်ရာတွင်သာ အသုံးဝင်သည်မဟုတ်ပါ။ ၎င်းသည် defense in depth အတွက် အလားအလာသစ်များကိုလည်း ဖန်တီးပေးပါသည်။ Reasoning-based နည်းလမ်းများသည် ပိုမိုပြောင်းလွယ်ပြင်လွယ်ရှိပြီး ယခင် training ၏ အသေးစိတ်အချက်များကြောင့် ကန့်သတ်ခံရမှု နည်းပါးကာ၊ တစ်ခါတစ်ရံတွင် ၎င်းတို့ပါဝင်သည့် ထပ်တိုး compute cost နှင့် latency ကို ကျော်လွန်အောင်တောင် အကျိုးရှိစေပါသည်။

gpt-oss-safeguard သည် ကျွန်ုပ်တို့က Safety Reasoner ဟု ခေါ်သော tool တစ်ခုအတွင်း internal အနေဖြင့် တီထွင်ခဲ့သော နည်းလမ်း၏ open-weight implementation ဖြစ်ပါသည်။ ကျွန်ုပ်တို့သည် policy labelling task များအပေါ် အားဖြည့် မွမ်းမံပြင်ဆင်ခြင်း ဖြင့် စတင်ခဲ့ပြီး၊ လူ့ကျွမ်းကျင်သူများ၏ မှန်ကန်သော ဆုံးဖြတ်ချက်များကို တိတိကျကျ ထင်ဟပ်ပေးသောအခါ မော်ဒယ်ကို reward ပေးခဲ့ပါသည်။ ထိုနည်းလမ်းက policy သည် ၎င်း၏ judgement သို့ မည်သို့ ဦးတည်စေသည်ကို မော်ဒယ်က reasoning လုပ်နိုင်အောင် သင်ကြားပေးခဲ့သည်။ ယနေ့တွင် Safety Reasoner သည် classifier တစ်ခုကို ပြန်လည် train လုပ်ရန် လိုမည့်အချိန်ထက် နည်းသောအချိန်အတွင်း production တွင် ကျွန်ုပ်တို့၏ safety policy များကို dynamic အနေဖြင့် update လုပ်နိုင်စေပါသည်။ ထို့ကြောင့် Safety Reasoner သည် iterative deployment⁠ အတွက် အဓိက tool တစ်ခုဖြစ်လာပါသည်။ ကျွန်ုပ်တို့သည် မော်ဒယ်အသစ်များကို production သို့ deploy လုပ်သည့်အခါ မကြာခဏ ပိုမိုတင်းကျပ်သော policy များဖြင့် စတင်ပြီး၊ လိုအပ်သည့်နေရာများတွင် compute အရင်းအမြစ် အတော်အတန်များစွာကို အသုံးပြုကာ Safety Reasoner သည် ထို policy များကို သေချာစွာ လိုက်နာအသုံးပြုနိုင်စေရန် ဆောင်ရွက်ပါသည်။ ထို့နောက် production အတွင်းရှိ risk များကို ကျွန်ုပ်တို့ ပိုမိုနားလည်လာသည်နှင့်အမျှ policy များကို ပြင်ဆင်ညှိနှိုင်းပါသည်။ မကြာသေးမီက launch အချို့တွင် safety reasoning အတွက် အသုံးပြုသော total compute အချိုးအစားသည် 16% အထိ မြင့်တက်ခဲ့ပါသည်။

Safety Reasoner သည် ကျွန်ုပ်တို့၏ safety stack ၏ အဓိကအစိတ်အပိုင်းတစ်ခု ဖြစ်လာပါသည်။ image generation နှင့် Sora 2 အတွက် ၎င်းသည် unsafe generation များကို အချိန်နှင့်တပြေးညီ ဖော်ထုတ်ပြီး တားဆီးရန် output များကို dynamic, step-wise evaluation များ ပြုလုပ်ပေးပါသည်။ Biology နှင့် self-harm ကဲ့သို့သော domain များတွင် ကျွန်ုပ်တို့သည် Moderation API တွင် အသုံးပြုသော မော်ဒယ်များကဲ့သို့ သေးငယ်၊ မြန်ဆန်ပြီး recall မြင့်သော classifier များကို content တစ်ခုသည် စိတ်ဝင်စားရမည့် domain အတွင်း ပါဝင်ခြင်းရှိမရှိ ဆုံးဖြတ်ရန် အသုံးပြုပြီး၊ ထို့နောက် ထို content ကို ပြန်လည်သုံးသပ်ရန် Safety Reasoner ကို အသုံးပြုပါသည်။ Safety Reasoner သည် မည်သို့ တုံ့ပြန်ရမည်ကို ဆုံးဖြတ်ရန် မော်ဒယ် output များကို အသေးစိတ် taxonomy နှင့် နှိုင်းယှဉ်၍ အမျိုးအစားခွဲပေးပြီး GPT‑5 နှင့် ChatGPT Agent ကဲ့သို့သော system များတစ်လျှောက် ကျွန်ုပ်တို့၏ multi-layered safeguard များ၏ အစိတ်အပိုင်းတစ်ခုအဖြစ် လုပ်ဆောင်ပါသည်။ ယခုတော့ gpt-oss-safeguard မော်ဒယ်များက ဤနည်းလမ်းတူကို မည်သူမဆို အသုံးပြုနိုင်အောင် လုပ်ပေးထားပါသည်။

ကျွန်ုပ်တို့သည် gpt-oss-safeguard မော်ဒယ်များကို internal evaluation set များနှင့် external evaluation set များ နှစ်မျိုးလုံးအပေါ် အကဲဖြတ်ခဲ့ပါသည်။

Internal evaluation တွင် inference အချိန်၌ policy အများအပြားကို gpt-oss-safeguard သို့ တစ်ပြိုင်နက် ပေးခဲ့ပါသည်။ Test input တစ်ခုချင်းစီအတွက် gpt-oss-safeguard သည် ပါဝင်သည့် policy အားလုံးအောက်တွင် စာသားကို မှန်ကန်စွာ အမျိုးအစားခွဲနိုင်ခြင်းရှိမရှိကို ကျွန်ုပ်တို့ အကဲဖြတ်ပါသည်။ ၎င်းသည် ခက်ခဲသော task တစ်ခုဖြစ်ပြီး—မော်ဒယ်သည် ပါဝင်သော policy အားလုံးအတွက် golden set label များနှင့် တိတိကျကျ ကိုက်ညီမှသာ accurate ဟု သတ်မှတ်ပါသည်။

ကျွန်ုပ်တို့၏ gpt-oss-safeguard မော်ဒယ်များနှင့် internal Safety Reasoner သည် multi-policy accuracy တွင် gpt-5-thinking နှင့် gpt-oss အများသုံးနိုင်ရန် ပြုလုပ်ပေးထားသော မော်ဒယ်များထက် ပိုမိုကောင်းမွန်ပါသည်။ ယခင်မော်ဒယ်များ၏ အရွယ်အစား သေးငယ်နေသော်လည်း gpt-oss-safeguard မော်ဒယ်များက gpt-5-thinking ထက် ပိုကောင်းခြင်းသည် အထူးသဖြင့် အံ့အားသင့်ဖွယ် ဖြစ်ပါသည်။

ထို့အပြင် ကျွန်ုပ်တို့သည် ဤမော်ဒယ်များကို ကျွန်ုပ်တို့၏ moderation dataset⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ပေါ်တွင်လည်းကောင်း၊ ကျွန်ုပ်တို့၏ 2022 research paper⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) နှင့်အတူ ထုတ်ပြန်ခဲ့သော dataset နှင့် open-source chatbot သို့ user query များအပေါ် အခြေခံထားသော public benchmark ဖြစ်သည့် ToxicChat⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ပေါ်တွင်လည်း အကဲဖြတ်ခဲ့ပါသည်။

2022 moderation evaluation set တွင် ကျွန်ုပ်တို့၏ internal safety policy များကို အသုံးပြု၍ အကဲဖြတ်ခဲ့ပါသည် (နောက်ပိုင်းပြောင်းလဲမှုများကို ထည့်သွင်းတွက်ချက်ရန် policy တစ်ခုကို လိုက်လျောညီထွေ ပြင်ဆင်ထားသည်)။ gpt-oss-safeguard သည် internal Safety Reasoner နှင့် gpt-5-thinking အပါအဝင် စမ်းသပ်ထားသော အခြားမော်ဒယ်များအားလုံးထက် အနည်းငယ် ပိုကောင်းခဲ့သော်လည်း Safety Reasoner နှင့် gpt-oss-safeguard အကြားရှိ ဤကွာခြားချက်မှာ စာရင်းအင်းအရ အဓိပ္ပာယ်ရှိသော ကွာခြားချက် မဟုတ်ပါ။

ToxicChat အတွက် ကျွန်ုပ်တို့၏ internal policy အချို့မှ လိုက်လျောညီထွေ ပြင်ဆင်ထားသော လက်ရေး prompt အတိုတစ်ခုကို အသုံးပြု၍ အကဲဖြတ်ခဲ့ပါသည်။ ကျွန်ုပ်တို့၏ internal Safety Reasoner သည် ထပ်မံ၍ gpt-5-thinking ထက် ပိုမိုကောင်းမွန်ခဲ့ပြီး၊ gpt-5-thinking နှင့် Safety Reasoner နှစ်ခုလုံးသည် gpt-oss-safeguard-120b နှင့် gpt-oss-safeguard-20b ထက် အနည်းငယ်သာ ပိုမိုကောင်းမွန်ပါသည်။ သို့သော် gpt-oss-safeguard ၏ အရွယ်အစား သေးငယ်မှုကြောင့် ဤအမျိုးအစား task များအတွက် ၎င်းကို ပိုမိုရွေးချယ်သင့်သည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။

gpt-oss-safeguard တွင် သီးခြားကန့်သတ်ချက် နှစ်ခုရှိပါသည်။ ပထမအချက်မှာ အရည်အသွေးမြင့် label တပ်ထားသော sample သောင်းပေါင်းများစွာဖြင့် train လုပ်ထားသော classifier များသည် policy မှ တိုက်ရိုက် reasoning လုပ်သော gpt-oss-safeguard ထက် content classification တွင် ပိုမိုကောင်းမွန်နိုင်ကြောင်း ကျွန်ုပ်တို့ တွေ့ရှိထားခြင်းဖြစ်ပါသည်။ ပိုမိုရှုပ်ထွေးသော risk များတွင် performance မြင့်မားစေရန် dedicated classifier တစ်ခုကို train လုပ်ရန် အချိန်ပေးခြင်းကို ဦးစားပေးနိုင်ပါသည်။

ဒုတိယအချက်မှာ gpt-oss-safeguard သည် အချိန်နှင့် compute အရင်းအမြစ် များစွာ လိုအပ်နိုင်ပြီး၊ ထို့ကြောင့် platform content အားလုံးတွင် scale လုပ်ရန် စိန်ခေါ်မှုရှိစေပါသည်။ Internal အနေဖြင့် Safety Reasoner ဖြင့် ဤပြဿနာကို နည်းလမ်းအမျိုးမျိုးဖြင့် ကိုင်တွယ်ပါသည်- (1) မည်သည့် content များကို အကဲဖြတ်ရမည်ကို ဆုံးဖြတ်ရန် ပိုမိုသေးငယ်ပြီး ပိုမြန်သော classifier များကို အသုံးပြုသည်၊ (2) အချို့အခြေအနေများတွင် unsafe content ကို တွေ့ရှိပါက ဝင်ရောက်ဆောင်ရွက်နိုင်စွမ်းကို ထိန်းသိမ်းထားစဉ် latency နည်းသော user experience ပေးနိုင်ရန် Safety Reasoner ကို asynchronous အနေဖြင့် အသုံးပြုသည်။

gpt-oss-safeguard သည် community နှင့်အတူ တည်ဆောက်ထားသော OpenAI ၏ ပထမဆုံး open safety မော်ဒယ်အစုဖြစ်ပါသည်။ ကျွန်ုပ်တို့သည် စောစီးစွာ စမ်းသပ်မှုအဖြစ် SafetyKit၊ ROOST၊ Tomoro၊ နှင့် Discord မှ trust and safety specialist များနှင့်အတူ gpt-oss-safeguard ကို iterate လုပ်ခဲ့ပါသည်။ ROOST CTO Vinay Rao က “gpt-oss-safeguard သည် ‘bring your own policies and definitions of harm’ ဒီဇိုင်းပါရှိသော ပထမဆုံး open source ကျိုးကြောင်းသင့်လျော်စွာ စဉ််းစားပေးသော မော်ဒယ် ဖြစ်ပါသည်။ အဖွဲ့အစည်းများသည် အရေးကြီးသော safety technology များကို လွတ်လပ်စွာ လေ့လာ၊ ပြင်ဆင်၊ အသုံးပြုနိုင်သင့်ပြီး ဆန်းသစ်တီထွင်နိုင်ရပါမည်။ ကျွန်ုပ်တို့၏ စမ်းသပ်မှုများတွင် ၎င်းသည် မတူညီသော policy များကို နားလည်ခြင်း၊ ၎င်း၏ reasoning ကို ရှင်းပြခြင်းနှင့် policy များကို အသုံးချရာတွင် nuance ကို ပြသခြင်းတို့တွင် ကျွမ်းကျင်ခဲ့ပြီး၊ ၎င်းက builder များနှင့် safety team များအတွက် အကျိုးရှိမည်ဟု ကျွန်ုပ်တို့ ယုံကြည်ပါသည်” ဟု ဆိုသည်။

ROOST Model Community (RMC) အပါအဝင် community နှင့်အတူ open safety tooling ကို တိုးတက်ကောင်းမွန်အောင် ဆက်လက် iterate လုပ်သွားမည်ဖြစ်ပါသည်။ RMC သည် open source AI မော်ဒယ်များကို safety workflow များအတွင်း အကောင်အထည်ဖော်ရာတွင် အကောင်းဆုံးနည်းလမ်းများကို မျှဝေရန် safety practitioner များနှင့် researcher များကို စုစည်းပေးထားပြီး evaluation result များနှင့် model feedback များလည်း ပါဝင်ပါသည်။ ဤပူးပေါင်းဆောင်ရွက်မှုအကြောင်းနှင့် မည်သို့ ပါဝင်နိုင်မည်ကို ပိုမိုလေ့လာရန် RMC GitHub repo⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) သို့ ဝင်ရောက်ကြည့်ရှုပါ။

ဤမော်ဒယ်များဖြင့် စတင်တည်ဆောက်လိုပါက ၎င်းတို့ကို Hugging Face⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) မှ ဒေါင်းလုဒ်လုပ်ပါ။