ai-agents-for-beginners
ထုတ်လုပ်မှုရှိ AI ကိုယ်စားလှယ်များ - ကြည့်ရှုမှုနှင့် သုံးသပ်ခြင်း
AI ကိုယ်စားလှယ်များကို စမ်းသပ်ရေးနမူနာများမှ ပျော်ရွှင်ရေသာ ပတ်ဝန်းကျင်များသို့ ရွေ့ပြောင်းလာသောအခါ၊ ၎င်းတို့၏အပြုအမူကို နားလည်ရန်၊ လုပ်ဆောင်မှုကို မျှော်မှန်းစစ်ဆေးရန်နှင့် ရလဒ်များကို စနစ်တကျ သုံးသပ်နိုင်ရန် အရေးကြီးလာသည်။
သင်ယူရမည့် ရည်မှန်းချက်များ
ဒီသင်ခန်းစာပြီးဆုံးသည်နှင့် သင်သည် သိရှိနားလည်လာမည့် အချက်များမှာ-
- ကိုယ်စားလှယ် ကြည့်ရှုမှုနှင့် သုံးသပ်မှု၏ အခြေခံအယူအဆများ
- ကိုယ်စားလှယ်များ၏ လုပ်ဆောင်မှု၊ ကုန်ကျစရိတ်နှင့် ထိရောက်မှု တိုးတက်စေရန် နည်းလမ်းများ
- သင်၏ AI ကိုယ်စားလှယ်များကို စနစ်တကျ ဘယ်လို သုံးသပ်ရမည်ကို
- AI ကိုယ်စားလှယ်များကို ထုတ်လုပ်မှုထဲ သွင်းသောအခါ ကုန်ကျစရိတ်ကို ဘယ်လို ထိန်းချုပ်ကြမည်ကို
- Microsoft Agent Framework ဖြင့် တည်ဆောက်ထားသော ကိုယ်စားလှယ်များအတွက် ဘယ်လို ကိရိယာထည့်သွင်းမယ်ကို
ရည်မှန်းချက်မှာ သင်၏ “အမှောင်ခွဲ” ကိုယ်စားလှယ်များကို တွင်းရှင်းပြီး၊ စီမံခန့်ခွဲနိုင်ပြီး ယုံကြည်စိတ်ချရသော စနစ်များအဖြစ် ပြောင်းလဲနိုင်ရန် သိမြင်ပေးခြင်း ဖြစ်သည်။
မှတ်ချက်။ ဘေးကင်းလုံခြုံပြီး ယုံကြည်စိတ်ချရသော AI ကိုယ်စားလှယ်များကို ထုတ်လုပ်မှုတွင် ထည့်သွင်းသည်မှာ အရေးကြီးသည်။ ယုံကြည်စိတ်ချရသော AI ကိုယ်စားလှယ်များ တည်ဆောက်ခြင်း သင်ခန်းစာကိုလည်း ကြည့်ရှုပါ။
လမ်းကြောင်းများနှင့် ချဲ့ထွင်မှုများ (Traces and Spans)
ကြည့်ရှုမှုကိရိယာများဖြစ်သည့် Langfuse သို့မဟုတ် Microsoft Foundry များသည် ပုံမှန်အားဖြင့် ကိုယ်စားလှယ်လည်ပတ်မှုများကို လမ်းကြောင်းများ (traces) နှင့် ချဲ့ထွင်မှုများ (spans) အဖြစ် ကိုယ်စားပြုသည်။
- လမ်းကြောင်း (Trace) သည် ကိုယ်စားလှယ်လုပ်ငန်းတစ်ခုလုံးကို အစမှ အဆုံးအထိ ကိုယ်စားပြုသည် (ဥပမာ - အသုံးပြုသူမေးခွန်းတစ်ခုကို ကိုင်တွယ်ခြင်း)။
- ချဲ့ထွင်မှုများ (Spans) သည် လမ်းကြောင်းအတွင်းရှိ တစ်ဆင့်ချင်းစီ ဖြစ်ပြီး (ဥပမာ - ဘာသာစကားမော်ဒယ်ခေါ်ဆိုခြင်း သို့မဟုတ် ဒေတာ ရယူခြင်း) ဖြစ်သည်။
ကြည့်ရှုမှုမရှိပါက AI ကိုယ်စားလှယ်သည် “အမှောင်ခွဲ”ကဲ့သို့ ဖြစ်နေရသောကြောင့် ၎င်း၏ အတွင်းအစိတ်အပိုင်းနှင့် မှတ်ယူချက်များသည် မမြင်သာဘဲ ကြာရှည်စွာ ခွဲခြား၍ ပြင်ဆင်ရန် အခက်အခဲရှိသည်။ ကြည့်ရှုမှုဖြင့် ရထားသောကြောင့် ကိုယ်စားလှယ်များသည် “မွန်မှန်ကိရိယာ” ကဲ့သို့ ရှင်းလင်းမှတ်သားနိုင်သောကြောင့် ယုံကြည်မှုတည်ဆောက်ခြင်းနှင့် ဝိညာဥ်ကျသော လုပ်ဆောင်ပုံစံများ အတွက် အရေးကြီးသည်။
ထုတ်လုပ်မှု ပတ်ဝန်းကျင်များတွင် ကြည့်ရှုမှု အရေးပါခြင်း
AI ကိုယ်စားလှယ်များကို ထုတ်လုပ်မှု ပတ်ဝန်းကျင်များသို့ ရွေ့ပြောင်းပြောင်းလဲခြင်းသည် စိန်ခေါ်မှုနှင့် လိုအပ်ချက်အသစ်များကို တင်သွင်းသည်။ ကြည့်ရှုမှုသည် “လိုအပ်ချက်တစ်ခု” သက္ကရာဇ်ကထက် လိုအပ်ချက် အထူးပြု အင်အားဖြစ်လာသည်။
- အမှားရှာဖွေပုံနှင့် အကြောင်းအရင်းစုံစမ်းခြင်း - ကိုယ်စားလှယ် လုပ်ဆောင်မှု မအောင်မြင်ခြင်း သို့မဟုတ် မမျှော်လင့်သော ရလဒ် ထုတ်ပေးသောအခါ၊ ကြည့်ရှုမှုကိရိယာများသည် အမှားမှ ပြဿနာဟာ ဘယ်မှာလဲဆိုတာ ရှာဖွေရန် လမ်းကြောင်းများကို ပူဇော်ပေးသည်။ ၎င်းသည် များပြားသော LLM ခေါ်ဆိုချက်များ ၊ ကိရိယာများနှင့် စည်းမျဉ်းချက်များပါသည့် ရိုးရှင်းမှုမရှိသော ကိုယ်စားလှယ်များအတွက် အထူးအရေးကြီးသည်။
- ကြာသပတေးနှင့် ကုန်ကျစရိတ် ထိန်းချုပ်မှု - AI ကိုယ်စားလှယ်များသည် ကောက်ယူသည့် token လိုက်တာ နှင့် ခေါ်ဆိုချက်အလိုက် ကုန်ကျစရိတ်များမ ဖြစ်စေရန် ကြည့်ရှုမှုဖြင့် ခေါ်ဆိုချက်ခြားနားမှုများကို တိတိကျကျ ထိန်းသိမ်းနိုင်သည်။ ၎င်းသည် ရာထူးရှမ်ပေားများအား ကျွမ်းကျင်စွာ ပြန်လည်တည်ဆောက်ခြင်း သို့မဟုတ် ပိုမိုထိရောက်သော မော်ဒယ်များကို ရွေးချယ်ခြင်း၊ လုပ်ငန်းစဉ်ကို ပြန်လည် ဒီဇိုင်းဆွဲခြင်းတို့ဖြင့် ကုန်သက်သာစေရန် အကျိုးရှိသည်။
- ယုံကြည်မှု၊ လုံခြုံမှုနှင့် စည်းကမ်းရှိမှု - အများအပြားတစ်ခုတည်းသော လျှောက်လွှာများတွင် ကိုယ်စားလှယ်များသည် လုံခြုံပြီး ဝါဒနှင့်ကျင့်သုံးရမည့်အတိုင်း ဆောင်ရွက်ရန် အရေးကြီးသည်။ ကြည့်ရှုမှုသည် ကိုယ်စားလှယ် လုပ်ဆောင်ချက်နှင့် ဆုံးဖြတ်ချက်များ၏ စစ်ဆေးမှုလမ်းကြောင်းကို ပေးသည်။ ၎င်းက လိမ်လည်ထည့်သွင်းမှု (prompt injection), ထိခိုက်မှုရှိသော အကြောင်းအရာများ ထုတ်ပေးမှု သို့မဟုတ် လူပုဂ္ဂိုလ်သတင်းအချက်အလက် မသင့်တော်စွာ ကိုင်တွယ်မှု(s) ကဲ့သို့သော ပြဿနာများကို ရှာဖွေရန်နှင့် ဖြေရှင်းရန် အသုံးပြုနိုင်သည်။ ဥပမာအားဖြင့်, ကိုယ်စားလှယ် တစ်ခုက တိကျသော တုံ့ပြန်ချက်တစ်ခု ပေးမှုအကြောင်းအရင်း သို့မဟုတ် သတ်မှတ်ထားသော ကိရိယာအသုံးပြုမှု ကိုယ်စားလှယ်ကြိုတင်သိရှိရန် လမ်းကြောင်းများကို ပြန်လည်သုံးသပ်နိုင်သည်။
- ဆက်လက်တိုးတက်မှု လုပ်ငန်းစဉ်များ - ကြည့်ရှုမှုဒေတာသည် ပုံမှန်တိုးတက်တတ်သော ဖွံ့ဖြိုးတိုးတက်မှု လုပ်ငန်းစဉ်အတွက် အခြေခံတည်ဆောက်မှုဖြစ်သည်။ ကိုယ်စားလှယ်အလုပ်လုပ်ပုံကို အွန်လိုင်းတွင် ကြည့်ရှုခြင်းဖြင့် အကောင်းမြင်မှုရာများ ရှာဖွေပြီး မော်ဒယ်များကို ပိုမို ထိရောက်အောင် ပြုပြင်နှိမ်နင်းရန် ဒေတာစုဆောင်းကာ ပြင်ဆင်မှုများ၏ အကျိုးသက်ရောက်မှုများကို သက်သေပြနိုင်သည်။ ထို့ကြောင့် ထုတ်လုပ်မှုမှ ရရှိသည့် အကြံပြုချက်များသည် အွန်လိုင်းသုံးသပ်မှုမှ အော့ဖ်လိုင်း စမ်းသပ်မှုနှင့် ပြုပြင်မှုများကို တိုးတက်အောင် ညှိနှိုင်းပေးသည်။
လိုအပ်သည့် ပမာဏကျော်များကို ထိန်းသိမ်းမည့်အချက်များ
ကိုယ်စားလှယ်၏ အပြုအမူကို ကြည့်ရှု၍ နားလည်ရန် အမျိုးမျိုးသော ပမာဏများနှင့် သင်္ကေတများကို လိုက်လံကြည့်ရမည်။ ကိုယ်စားလှယ်၏ ရည်ရွယ်ချက်အပေါ်မူတည်၍ ပမာဏများကွဲပြားနိုင်သော်လည်း၊ အချို့ကို ချုပ်ဆို၍ အရေးကြီးသော စံနှုန်းများလည်း ရှိသည်။
သာမန်အားဖြင့် ကြည့်ရှုမှု ကိရိယာများက စောင့်ကြည့်သော အခြားစံနှုန်းများမှာသည်-
ကြာသပတေး (Latency): ကိုယ်စားလှယ်သည် မည်သည့်အမြန်နှုန်းဖြင့် တုံ့ပြန်သနည်း? ကြာရှည်စောင့်ဆိုင်းမှုများသည် အသုံးပြုသူအတွေ့အကြုံကို နည်းတယ်စေသည်။ လုပ်ငန်းများနှင့် တစ်ဆင့်ချင်းစီ သက်ဆိုင်သည့် ကြာသပတေးကို ကိုယ်စားလှယ် လည်ပတ်မှုအား လမ်းကြောင်းအားဖြင့် တိုင်းတာသင့်သည်။ ဥပမာ- မော်ဒယ်ခေါ်ဆိုချက်အားလုံး ၂၀ စက္ကန့် ဆင်းပြီးဆိုပါက ပိုမိုလျင်မြန်သော မော်ဒယ် သို့မဟုတ် အလားတူ မော်ဒယ်ခေါ်ဆိုချက်များကို 병렬ခေါ်ဆိုခြင်းကြောင့် မြန်ဆန်အောင်ပြုလုပ်နိုင်သည်။
ကုန်ကျစရိတ်များ: ကိုယ်စားလှယ် လည်ပတ်မှုနှုန်းတိုင်းအတွက် ကုန်ကျစရိတ် မည်မျှနည်း? AI ကိုယ်စားလှယ်များသည် token နှုန်းလိုက် လိုက်ကြေးယူသည့် LLM ခေါ်ဆိုမှုများနှင့် ပြင်ပ API များမှ ခေါ်ဆိုမှုများအား မှီငြမ်းသည်။ ကိရိယာများနှင့်ပုံစံအမျိုးမျိုးတို့ကို မကြာခဏ သုံးစွဲခြင်းသည် ကိုယ်စားလှယ် လည်ပတ်မှုအတွက် ကုန်ကျစရိတ်များ ကြီးမားစေနိုင်သည်။ ဥပမာ- တစ်ကိုယ်စား AI ကိုယ်စားလှယ်သည် အရည်အသွေးမြင့်မားမှုအတွက် LLM ကို ၅ ကြိမ်ခေါ်ဆိုပါက၊ ဤကုန်ကျစရိတ်သည် သင့်တော်ကြောင်းသတ်မှတ်ရန် သို့မဟုတ် ခေါ်ဆိုချက်အရေအတွက် လျော့ချရန် သို့မဟုတ် ပိုမိုသက်သာသော မော်ဒယ်များ အသုံးပြုရန် စဉ်းစားရမည်ဖြစ်သည်။ အချိန်နဲ့တပြေးညီ ကြည့်ရှုမှုသည် မမျှော်လင့်သော အတက်အကျများကို ရှာဖွေသူတွင်အထောက်အကူဖြစ်သည် (ဥပမာ - အမှားကြောင့် API loop များ စွံဆဲလုပ်ဆောင်မှု)။
တောင်းဆိုမှု အမှားများ: ကိုယ်စားလှယ်သည် မည်မျှသောတောင်းဆိုမှုများကို မအောင်မြင်နည်း? အဲဒါတွင် API အမှားများ သို့မဟုတ် ကိရိယာခေါ်ဆိုမှု မအောင်မြင်မှုများ ပါဝင်သည်။ ထုတ်လုပ်မှုတွင် ကိုယ်စားလှယ်ကို ပိုမိုခိုင်ခံ့အောင် လုပ်၍ ရှေ့ဆက်ဖော်ရွေမှုများ သို့မဟုတ် ပြန်လည်ကြိုးစားမှုများ ပြုလုပ်နိုင်သည်။ ဥပမာ - LLM ပံ့ပိုးသူ A ပိတ်သွားပါက LLM ပံ့ပိုးသူ B ကို backup အဖြစ် သုံးနိုင်သည်။
အသုံးပြုသူ တုံ့ပြန်ချက်: အသုံးပြုသူမှ တိုက်ရိုက် သုံးသပ်ချက်များပေးခြင်းသည် တန်ဖိုးရှိသော အချက်အလက်များ ရရှိစေသည်။ ၎င်းက thumbs-up / thumbs-down (👍/👎) ၊ တစ်စကြယ်မှ ငါးစကြယ် သုံးသပ်ချက်များ (⭐1-5 stars) သို့မဟုတ် စာပိုဒ်ဖြင့်မှတ်ချက်များ ပါဝင်နိုင်သည်။ မကြာခဏ ပျက်ကွက်သော တုံ့ပြန်မှုများက ၎င်းဟာ ကိုယ်စားလှယ် မဟုတ်သင့်သလို လုပ်ဆောင်နေသည်ဟု သတိပေးသည်။
ဖျားပြင့်သាប់တုံ့ပြန်ချက် (Implicit User Feedback): တိုက်ရိုက် မသတ်မှတ်ခဲ့ပေမယ့် အသုံးပြုသူ အပြုအမူများက ထောက်ပြချက် ဖြစ်ပေးသည်။ ဥပမာ - မေးခွန်းကို သိမ်းပြီးပြန်မေးခြင်း၊ မေးခွန်းများကို ထပ်မံမေးခြင်း သို့မဟုတ် ထပ်မံကြိုးစားရန် ခလုတ်နှိပ်ခြင်း။ တခြားကဲ့သို့မဟုတ် မကြာခဏ တူညီသော မေးခွန်းများကို မေးရခြင်းသည် ကိုယ်စားလှယ်ဟာ မထင်မှတ်ဘူးသလို လုပ်နေခြင်း၏ အချက်အလက်ဖြစ်သည်။
တိကျမှန်ကန်မှု (Accuracy): ကိုယ်စားလှယ်သည် မည်မျှ အကြိမ်အရေအတွက် မှန်ကန်သော ရလဒ်များ ထုတ်ပေးသနည်း? တိကျမှုကို သတ်မှတ်မှုများကွဲပြားနိုင်သည် (ဥပမာ - ပြproblemမ်းများ ဖြေရှင်းမှန်ကန်မှု, သတင်းအချက်အလက် ရယူမှန်ကန်မှု, အသုံးပြုသူ စိတ်ကျေနပ်မှု)။ ပထမဆုံးအဆင့်မှာ သင့်ကိုယ်စားလှယ်အတွက် အောင်မြင်မှု ဘာဖြစ်သည်ဆိုတာ သတ်မှတ်ရန်ဖြစ်သည်။ အလိုအလျောက်စစ်ဆေးမှုများ၊ အကဲဖြတ်မှတ်တမ်းများ သို့မဟုတ် လုပ်ငန်းပြီးမြောက်မှု အမှတ်အသားများ အသုံးပြု၍ တိကျမှန်ကန်မှုကို လိုက်လံနိုင်သည်။ ဥပမာ - လမ်းကြောင်းကို “အောင်မြင်” သို့မဟုတ် “မအောင်မြင်” ဟူ၍ သတ်မှတ်ခြင်း။
အလိုအလျော့ သုံးသပ်ချက်များ: သင့်ကိုယ်စားလှယ် output ကို အလိုအလျော့ သုံးသပ်ချက်လုပ်ရနိုင်သည်။ ဥပမာ - LLM ကိုသုံး၍ အကဲဖြတ်ခြင်း - အကူအညီဖြစ်/ တိကျ/ မကိုက်ညီဘူးဖြစ်ခြင်းကို အမှတ်ပေးနိုင်သည်။ အများအပြား အစုလိုက်အပြုံလိုက် open source စာကြည့်တိုက်များလည်း ရှိ၍ ကိုယ်စားလှယ်၏ အပိုင်းအစများအား သုံးသပ်ရန် ကူညီပေးသည်။ ဥပမာ - RAGAS ရှိသည်။ RAG ကိုယ်စားလှယ်များအတွက်၊ LLM Guard ကတော့ ထိခိုက်မှုရှိသော ဘာသာစကား သို့မဟုတ် prompt injection ကို ဖော်ထုတ်ရန် အသုံးပြုသည်။
လက်တွေ့တွင် ဒီအချက်အလက်များ အပေါင်းအစုံကို ပေါင်းစပ်သုံးစွဲခြင်းသည် AI ကိုယ်စားလှယ်၏ ကျန်းမာရေးအခြေအနေကို အကောင်းဆုံး မျှတစွာ ဖော်ပြနိုင်သည်။ ဒီအခန်းတွင် ဥပမာ notebook မှာ ဒီမျိုး Metrics များ ဂဏန်းနမူနာများအဖြစ် ပြသမည်ဖြစ်သော်လည်း ပထမဦးဆုံး သင်ယူမည့် အချက်မှာ သုံးသပ်မှုလုပ်ငန်းစဉ် သွားရမည့် နည်းလမ်းဖြစ်သည်။
ကိုယ်စားလှယ်အား Instrument လုပ်ခြင်း
လမ်းကြောင်းဒေတာစုဆောင်းရန် သင့်ကုဒ်ကို Instrument လုပ်ရမည်။ ရည်မှန်းချက်မှာ ကိုယ်စားလှယ်ကုဒ်ကို instrument လုပ်ပြီး လမ်းကြောင်းနှင့် Metrics များ ထွက်ရှိစေရန်ဖြစ်ပြီး၊ အဲဒီဒေတာများကို ကြည့်ရှုမှု ပလက်ဖောင်းတွင် စုဆောင်း၊ စနစ်တကျလုပ်ဆောင်နှင့် ဖော်ပြနိုင်အောင် ကူညီပေးသည်။
OpenTelemetry (OTel): OpenTelemetry သည် LLM ကြည့်ရှုမှုအတွက် စက်မှုလုပ်ငန်းစံချိန်တစ်ခုအဖြစ် မကြာသေးမီကပေါ်ပေါက်လာသည်။ ၎င်းသည် Telemetry ဒေတာများထွက်ရှိ၊ စုဆောင်း၊ ပို့နိုင်ရန် API များ၊ SDK များနှင့် ကိရိယာများကို ပေးဆောင်သည်။
ရှိပြီးသား ကိုယ်စားလှယ် ဖွဲ့စည်းမှုများကို လွယ်ကူစွာ ဖြည့်သွင်းပေးနိုင်သည့် Instrumentation စာကြည့်တိုက် များစွာ ရှိပြီး၊ OpenTelemetry spans များကို ကြည့်ရှုမှု ကိရိယာသို့ ပို့တင်ပေးနိုင်သည်။ Microsoft Agent Framework သည် OpenTelemetry နှင့် ပေါင်းစပ်မှုကို မူရင်းအတိုင်း ထည့်သွင်းထားသည်။ အောက်တွင် MAF ကိုယ်စားလှယ် တစ်ခု Instrument လုပ်ခြင်း နမူနာပါရှိသည်။
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# Agent execution is traced automatically
pass
ဒီအခန်းရှိ ဥပမာ notebook ကို အသုံးပြု၍ သင်၏ MAF ကိုယ်စားလှယ်ဘယ်လို Instrument လုပ်ရမလဲ ပြသမည်ဖြစ်သည်။
Manual Span Creation: Instrumentation စာကြည့်တိုက်များက အခြေခံအဆင့်ကောင်းတစ်ခု ဖန်တီးပေးသော်လည်း မကြာခဏ ပိုပြီး အသေးစိတ် သို့မဟုတ် အသုံးအနှုန်း အထူးလုပ်ငန်းဆိုင်ရာ သိရှိချက်လိုအပ်သည်။ အဲဒီအတွက် ကျွန်ုပ်တို့သည် ကျွမ်းကျင်စွာ span များကို ကိုယ်တိုင် ဖန်တီးကာ custom application logic ထည့်သွင်းနိုင်သည်။ အရေးကြီးသည်မှာ၊ အလိုအလျော့ သို့မဟုတ် မီနူးဖြစ်စွာ ဖန်တီးထားသော span များကို custom attribute များ (tag များ သို့မဟုတ် metadata ဆောင်) ဖြင့် ထောက်ပံ့တိုးမြှင့်နိုင်သည်။ ၎င်းတို့မှာ လုပ်ငန်းအသီးသီးရေးရာ ဒေတာ၊ အလယ်အလတ်တွက်ချက်ချက်များ သို့မဟုတ် debugging သို့မှ စစ်ဆေးမှုအတွက် အသုံးဝင်နိုင်သော အခြား context များ အပါအဝင်ဖြစ်နိုင်သည်၊ ဥပမာ user_id, session_id, သို့မဟုတ် model_version တို့ကဲ့သို့။
Langfuse Python SDK ဖြင့် လမ်းကြောင်းနှင့် ချဲ့ထွင်မှုများ ကိုယ်တိုင်ဖန်တီးသည့် နမူနာ-
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
ကိုယ်စားလှယ် သုံးသပ်ခြင်း
ကြည့်ရှုမှုက ပမာဏများ ပေးသည်၊ သို့သော် သုံးသပ်မှုသည် ဤဒေတာကို သုံးသပ်ခြင်း (နှင့် စမ်းသပ်ခြင်းမှု) ဖြစ်ပြီး AI ကိုယ်စားလှယ်၏ လုပ်ဆောင်မှုကောင်းကောင်းနှင့် ဘယ်လိုတိုးတက်စေမည်ကို ဆုံးဖြတ်ရန် ဖြစ်သည်။ အဓိပ္ပါယ်မှာ ချိတ်ဆက်ပြီး ရလာဒ်များကို အသုံးပြု၍ ကိုယ်စားလှယ်အား တိုင်းတာ၍ ဆုံးဖြတ်ချက်လွှဲပေးတာဖြစ်သည်။
AI ကိုယ်စားလှယ်များမှာ မကြာခဏ မညီမျှမှုရှိပြီး (စနစ်ပြောင်းလဲမှု သို့မဟုတ် မော်ဒယ်သဘောထားပြောင်းလဲမှုကြောင့်) ရှိနိုင်သည်။ သို့မဟုတ် သုံးသပ်မှုမရှိပါက၊ သင့် 「smart agent」သည် အလုပ်ကောင်းစွာလုပ်နေသလား၊ ပြောင်းလဲမှုဟာ စိုးရိမ်ဖွယ်ဖြစ်နေသလားဆိုတာ မသိနိုင်မှာဖြစ်သည်။
AI ကိုယ်စားလှယ်များအတွက် သုံးသပ်မှုကို နှစ်မျိုး ခွဲခြားသည်- online evaluation နှင့် offline evaluation ဖြစ်သည်။ နှစ်မျိုးလုံးအရေးကြီးပြီး အချင်းချင်း ဖြည့်ဆည်းပေးသည်။ သာမန်အားဖြင့် offline evaluation ဖြင့် စတင်မည်ဖြစ်ပြီး၊ ပြီးနောက် မှ ကိုယ်စားလှယ်ကို ထုတ်လုပ်မှုသို့ ထည့်သွင်းသည်။
Offline Evaluation
၎င်းသည် ကိုယ်စားလှယ်ကို ထိန်းချုပ်ထားသော ပတ်ဝန်းကျင်တွင် သုံးသပ်ခြင်း ဖြစ်ပြီး၊ အသုံးပြုသူလွှတ်ပေးသည့် မေးခွန်းများကို မသုံးပါ။ သင်ကလည်း ရွေးချယ်ထားသော စမ်းသပ်မှုဒေတာများကို အသုံးပြု၍ မျှော်လင့်ချက်ရှိသည့် ရလဒ်၊ သို့မဟုတ် မှန်ကန်သော ပြုမူမှုရှိသည်ကို သိပြီး ချိန်ညှိသည်။
ဥပမာ - သင်က သင်္ချာ စကားလုံးပြproblemများဖြေရှင်းရာ AI ကိုယ်စားလှယ်တစ်ခု ဖန်တီးထားကာ စမ်းသပ်မှု ဒေတာစု ၁၀၀ ပြproblem ကို အသုံးပြု၍ စမ်းသပ်နိုင်သည်။ Offline သုံးသပ်မှုသည် ဖွံ့ဖြိုးတိုးတက်စဉ်တွင် (CI/CD လမ်းကြောင်းအတွင်း ပါဝင်နိုင်) တိုးတက်မှုများ စစ်ဆေးရန် သို့မဟုတ် နောက်ပြန်ကြည့်ခြင်းတို့အတွက် ဖြစ်သည်။ ၎င်း၏အားသာချက်မှာ ပြန်လည်လုပ်ဆောင်နိုင်ပြီး မူလအချက်အလက်ရှိရာတွင် တိကျမှန်ကန်မှု မြှင့်တင်နိုင်ခြင်း ဖြစ်သည်။ သင်သည် အသုံးပြုသူ မေးခွန်းများကို မရဘဲ မော်ဒယ် အနီးကပ် တုံ့ပြန်မှုများကို စမ်းသပ်ပြီး အခြား အလိုအလျောက် metrics များပါ အသုံးပြုနိုင်သည်။
Offline သုံးသပ်မှု၏ အဓိက စိန်ခေါ်မှုမှာ သင်၏ စမ်းသပ်မှုဒေတာ စုစုပေါင်းကို ပြည့်စုံစွာ ထိန်းသိမ်းထားရမည်နှင့် မျှော်မှန်းချက်နှင့် အညီ ဟန်ချက်ညီမှုရှိစေရန်ဖြစ်သည်။ ကိုယ်စားလှယ်သည် စမ်းသပ်မှုအတွင်း စမ်းသပ်မှုများတွင် အလွန်ကောင်းစွာ လုပ်ဆောင်ပေမယ့် ထုတ်လုပ်မှုတွင် တစ်ပြိုင်နက်နဲ့ မတူညီသော မေးခွန်းများကို တွေ့မြင်ရနိုင်သည်။ ထို့ကြောင့် လုပ်ငန်းအတွက် အသစ်ဖြစ်သော Edge case များ နှင့် နမူနာများဖြင့် စမ်းသပ်မှုစုများကို အသစ်ထည့်သွင်းရန်လိုအပ်သည်။ ဇာတိပေးရန် - Smoke test အဖြစ် အသေးစားဒေတာ အစုများနှင့် ကျယ်ပြန့်သော သုံးသပ်မှုစုများလိုက်ဖက်စွာ ပေါင်းစပ်အသုံးပြုခြင်းကောင်းသည်။
Online Evaluation
ဤသည်မှာ ကိုယ်စားလှယ်ကို အသက်ဝင်သည့် အစစ်အမှန် ပတ်ဝန်းကျင်တွင် သုံးသပ်ခြင်းဖြစ်ပြီး၊ ထိုသုံးစွဲမှုအတွင်း အလုပ်လုပ်ပုံကို ကြည့်ရှုခြင်းနှင့် ရလဒ်များကို ဆက်လက်စစ်တမ်းတင်ခြင်း ရည်ရွယ်သည်။
ဥပမာအားဖြင့်, သင်သည် အောင်မြင်မှုနှုန်းများ, အသုံးပြုသူ စိတ်ကျေနပ်မှုအကဲဖြတ်မှတ်များ သို့မဟုတ် real-time ကျရှိသော အခြား metrics များကို စောင့်ကြည့်နိုင်သည်။ Online သုံးသပ်မှု၏အားသာချက်မှာ လေ့လာသုံးသပ်ရခက်သော အရာများကို ဖော်ထုတ်ပေးခြင်း ဖြစ်သည်။ ဥပမာ - ကိုယ်စားလှယ်၏ ထိရောက်မှုသည် အချိန်အလျောက် ပြောင်းလဲခြင်း (Model drift), ကြိုတင်ထောက်ထားမထားသော မေးခွန်းများ သို့မဟုတ်ကိစ္စများ ကို ကြည့်နိုင်သည်။ ထို့ကြောင့် online သုံးသပ်မှုသည် တကယ့်ဘဝအရ ကိုယ်စားလှယ်၏ လုပ်ဆောင်မှုကို ပြသသည်။
Online သုံးသပ်မှုအားဖြင့် implicit နှင့် explicit user feedback များစုဆောင်းခြင်းအပြင် shadow tests သို့မဟုတ် A/B test များ လုပ်ဆောင်နိုင်သည် (နောက်ဆုံး version အသစ်ကို ဟောင်းသော version နှင့် နှိုင်းယှဉ်ရန် parallel run)။ စိန်ခေါ်ချက်မှာ နောက်သို့ဖြည့်တင်းရမည့် Label သို့မဟုတ် အမှတ်အသားများကို ပြန်လည်ရရန် သိသိသာသာ ခက်ခဲသည်။ ထို့ကြောင့် အသုံးပြုသူတုံ့ပြန်ချက် သို့မဟုတ် downstream metrics (ဥပမာ - အသုံးပြုသူက ရလဒ်ကို နှိပ်ဖူးသလား) များကို အားထားရမည်ဖြစ်သည်။
နှစ်ခု ပေါင်းစပ်ခြင်း
Online နှင့် offline သုံးသပ်မှု သည် မတတ်ကွဲဘဲ အားဖြည့်သည့် အဆက်ဖွဲ့ပါဝင်မှုများဖြစ်သည်။ Online ကြည့်ရှုမှုမှရရှိသည့် အချက်အလက်များ (ဥပမာ- အသုံးပြုသူ မေးခွန်း မျိုးစုံဖြစ်သည့် နေရာများတွင် သက်သာမှုနည်းပါးမှု) ကို offline စမ်းသပ်မှု ဒေတာစနစ်တွင် ထည့်သွင်း အသုံးပြု၍ တိုးတက်ပြောင်းလဲနိုင်သည်။ အနောက်ဘက်တွင် offline စမ်းသပ်မှု အကျိုးရှိမှသာ online တွင် အားထားမည်။
စနစ်တကျ လုပ်ကိုင်သောအဖွဲ့များသည် ဆက်တိုက် လုပ်ဆောင်စဉ်( loop )ကို လက်ခံထားသည်-
offline သုံးသပ်ပြီး -> ထုတ်လုပ်မှုသို့ ထည့်သွင်း -> online တွင် စောင့်ကြည့် -> အသစ်ဆိုးရွားမှု များစုဆောင်း -> offline ဒေတာစနစ်သို့ ထည့်သွင်း -> ကိုယ်စားလှယ် သက်သာအောင် ပြုပြင် -> ထပ်မံလုပ်ဆောင်။
ရှိနိုင်သော ပြဿနာများ
AI ကိုယ်စားလှယ်များကို ထုတ်လုပ်သည့်အခါ မတူညီသော စိန်ခေါ်မှုများ တွေ့ရနိုင်သည်။ အောက်တွင် ကွဲပြားသော ပြဿနာများနှင့် အဖြေများကို ဖော်ပြထားသည်-
| ပြဿနာ | ဖြေရှင်းနည်း |
|---|---|
| AI ကိုယ်စား လုပ်ငန်းများကို လက်မတက်နိုင်ခြင်း | - AI Agent ကို ပေးလိုက်သော prompt ကို ပြုပြင်ပြောင်းလဲပါ၊ ရည်ရွယ်ချက်များ ကြောင်းပြစေရန်။ - လုပ်ငန်းများကို အပိုင်းအလိုက်ခွဲခြားကာ အမျိုးမျိုးသော ကိုယ်စားလှယ်များဖြင့် ကိုင်တွယ်စေခြင်းအား စုံစမ်းပါ။ |
| AI ကိုယ်စား လည်ပတ်မှု ကိုယ့်ကိုယ် loops များဝင်ပတ်နေခြင်း | - ကိုယ်စားလှယ် သည် လုပ်ငန်းစဉ်ကို ဘယ်အချိန်မှ သွန်သတ်ရမည်ဆိုတာ သေချာသိရှိအောင် စည်းမျဉ်းတွေနှင့် အတိအကျ ထုတ်ဖော်ပါ။ - စဉ်းစားချက်များအတွက် ပက်လက်ရှင်နည်း စားပွဲပုံ မော်ဒယ် ဖြစ်သောကြောင့် အကြီးမားသောမော်ဒယ်အသုံးပြုပါ။ |
| AI ကိုယ်စား လည်ပတ်သည့် ကိရိယာများ ဆောင်ရွက်မှု မကောင်းခြင်း | - ကိုယ်စားလှယ်စနစ်အပြင်က ကိရိယာထွက်လက်လွင့်မှုများ စမ်းသပ် အတည်ပြုပါ။ - သတ်မှတ်ထားသော parameter များ၊ prompt များနှင့် ကိရိယာအမည်များကို ပြင်ဆင်ပါ။ |
| Multi-Agent စနစ်မှာ နည်းရိုးမရှိ၊ ခိုင်မာမှုနည်းခြင်း | - ကိုယ်စားလှယ် တစ်ဦးချင်းစီအတွက် prompts များကို အထူးပြု၍ပိုမိုသက်သေပြ သေချာခြင်း။ - “routing” သို့မဟုတ် controller ကိုယ်စားလှယ်တစ်ခု တည်ဆောက်ကာ ဘယ် Agent မှန်သည်ကို ဆုံးဖြတ်စေနိုင်အောင် ချိတ်ဆက်ပါ။ |
ဤပြဿနာများ အများစုကို ကြည့်ရှုမှုရှိ၍ ပိုမို ထိရောက်စွာ ရှာဖွေမှုကို ပြုလုပ်နိုင်ပါသည်။ အရင်က ပြောခဲ့သည့် လမ်းကြောင်းနှင့် ပမာဏများက ကိုယ်စားလှယ် လုပ်ငန်းစဉ်တွင် ကွဲပြားခြားနားသော ပြဿနာများကို တိတိကျကျ ဖော်ထုတ်ပေး၍ အမှားရှာခြင်းနှင့် ပိုမိုထိရောက်သော ပြုပြင်ဆန်းသစ်မှုပေးသည်။
ကုန်ကျစရိတ် ထိန်းချုပ်ခြင်း
AI ကိုယ်စားလှယ်များကို ထုတ်လုပ်မှုသို့ ထည့်သွင်းရာတွင် ကုန်ကျစရိတ်ကို ထိန်းချုပ်ရမည့် လုပ်ထုံးလုပ်နည်းများမှာ-
သေးငယ်သောမော်ဒယ်များအသုံးပြုခြင်း: သေးငယ်သောဘာသာစကားမော်ဒယ်များ (SLMs) သည် agentic အသုံးပြုမှုတချို့တွင် ကောင်းစွာလည်ပတ်နိုင်ပြီး ကုန်ကျစရိတ်ကို တသက်တာလျှော့ချနိုင်သည်။ ယခင်တွင် ဖော်ပြခဲ့သည့်အတိုင်း၊ ကြီးမားသောမော်ဒယ်များနှင့် တိုင်းဆိုင်၍ စွမ်းဆောင်မှုအား ရှာဖွေသည့်အတွက် အကဲဖြတ်မှုစနစ်တစ်ခုကို တည်ဆောက်ခြင်းမှာ သင့်အသုံးပြုမှုတွင် SLM ခုလျှောက်ကောင်းမွန်မှုကို နားလည်ရန်အကောင်းဆုံးနည်းလမ်းဖြစ်သည်။ ရည်ရွယ်ချက်ခွဲခြားခြင်း သို့မဟုတ် ပါရာမီတာထုတ်ယူခြင်းကဲ့သို့ ရိုးရှင်းသောတာဝန်များအတွက် SLM များကို အသုံးပြုရန်စဉ်းစားပါ၊ ထိုကြောင့် စိတ်ရှုပ်မှုများရှိသော နောင်ကျသောဒေါ်များကို ကြီးမားသောမော်ဒယ်များအတွက်သီးသန့်ထားပါ။
Router မော်ဒယ်အသုံးပြုခြင်း: ဒီနည်းလမ်းနှင့်คลလိုက်တူသည် မော်ဒယ်အမျိုးမျိုးနှင့် အရွယ်အစား များစွာကို အသုံးပြုခြင်းဖြစ်သည်။ LLM/SLM သို့မဟုတ် Serverless Function တစ်ခုကို အသုံးပြုပြီး၊ အတားအဆီးအရ ကောင်းမွန်သည့်မော်ဒယ်များသို့ တောင်းဆိုချက်များကို ကမ်းလှမ်းပေးနိုင်သည်။ ဤနည်းလမ်းသည် ကျသင့်ငွေကိုလျော့ချခြင်းကိရိယာဖြစ်ပြီး တာ၀န်သင့်တော်သော မော်ဒယ်တွင်စွမ်းဆောင်ရည်ကိုသေချာစေပါသည်။ ဥပမာ၊ ရိုးရှင်းသော မေးခွန်းများကို သေးငယ်၍ အမြန်လှုပ်ရှားနိုင်သော မော်ဒယ်များသို့လမ်းညွှန်ပြီး တာဝန်ရှုပ်ထွေးသော ဒေါ်များအတွက်သာ အကြီးစားမော်ဒယ်များကိုအသုံးပြုပါ။
တုံ့ပြန်ချက်အစီရင်ခံခြင်း: သာမန်တောင်းဆိုမှုများနှင့် အလုပ်အမှုများကို သတ်မှတ်၍၊ agentic စနစ်မှတဆင့် မဖြတ်ဆီးမီပင် တုံ့ပြန်ချက်များ ပေးစွမ်းခြင်းသည် တူညီသော တောင်းဆိုမှုများ၏အလေးချိန်ကို လျော့ချနိုင်သည်။ မူလတန်း AI မော်ဒယ်များကို အသုံးပြုပြီး၊ တောင်းဆိုမှုတစ်ခုနှင့် သင့်ရဲ့ ဦးစားပေးထားသော တုံ့ပြန်ချက်များရဲ့ဆက်စပ်မှုကို ရှာဖွေရန်လည်း flow တစ်ခုတည်ဆောက်နိုင်ပါတယ်။ ဤနည်းဗျူဟာသည် မကြာခဏမေးမြန်းသော မေးခွန်းများ သို့မဟုတ် သာမန် workflow များအတွက် ကုန်ကျစရိတ်များကို သိသိသာသာလျော့ချပေးနိုင်သည်။
ဤနည်းလမ်းကို လက်တွေ့တွင် မည်သို့အလုပ်လုပ်သည်ကို ကြည့်ကြမယ်
ဤအပိုဒ်၏ နမူနာမှတ်တမ်းစာမျက်နှာ တွင် ကျွန်ုပ်တို့၏ agent ကို ကြည့်ရှုထိန်းသိမ်းရန်နှင့် အကဲဖြတ်ရန် observability ကိရိယာများကို မည်သို့ အသုံးပြုနိုင်သည်ကို ဥပမာများဖြင့်ထုတ်ဖော်ပြသထားသည်။
ထုတ်ကုန်ထဲရှိ AI Agent များနှင့်ပတ်သက်၍ မေးခွန်းများပိုမိုရှိပါသလား?
Microsoft Foundry Discord တွင် အခြားသင်ကြားသူများနှင့်တွေ့ဆုံ၊ office hours ကိုတက်ရောက်ပြီး သင့်၏ AI Agent မေးခွန်းများကို ဖြေရှင်းနိုင်ပါသည်။
ယခင်ခန်းစာ
နောက်တစ်ခန်းစာ
ပြောကြားချက် ဤစာတမ်းကို AI ဘာသာပြန်ဝန်ဆောင်မှု Co-op Translator အသုံးပြု၍ ဘာသာပြန်ထားပါသည်။ ကျွန်ုပ်တို့သည် တိကျမှန်ကန်မှုအတွက် ကြိုးပမ်းနေသော်လည်း၊ စက်ကိရိယာဘာသာပြန်ခြင်းများတွင် အမှားများ သို့မဟုတ် မှားယွင်းချက်များ ပါဝင်နိုင်ကြောင်း သတိပြုပါရန် လိုအပ်ပါသည်။ မူလစာတမ်းကို မူရင်းဘာသာဖြင့်သာ ယုံကြည်စိတ်ချရသော အချက်အလက်အဖြစ် သတ်မှတ်သင့်သည်။ အရေးကြီးသည့် သတင်းအချက်အလက်များအတွက် ပရော်ဖက်ရှင်နယ် လူသားဘာသာပြန်သူဝန်ဆောင်မှုကို အကြံပြုပါသည်။ ဤဘာသာပြန်ချက်ကို အသုံးပြုခြင်းမှ ဖြစ်ပေါ်လာသော နားလည်မှုကွာခြားမှုများ သို့မဟုတ် မမှန်ကန်သော အသုံးပြုမှုများအတွက် ကျွန်ုပ်တို့ တာဝန်မခံပါ။