ai-agents-for-beginners
ထုတ်လုပ်မှုရှိ AI အေးဂျင့်များ: Observability & Evaluation
AI အေးဂျင့်များသည် စမ်းသပ်ပုံစံမှ တကယ့်လောက အသုံးချမှုများသို့ ဦးတည်လာသည်နှင့်အမျှ ၎င်းတို့၏အလုပ်ဆောင်မှုကို နက်ရှိုင်းစွာနားလည်နိုင်ခြင်း၊ လုပ်ဆောင်ချက်များကို မျက်မြင်ထိန်းသိမ်းနိုင်ခြင်းနှင့် ထွက်ရှိလာသောရလဒ်များကို စနစ်တကျ သုံးသပ်နိုင်ခြင်းတို့က အရေးကြီးလာသည်။
Learning Goals
ဤသင်ခန်းစာကို ပြီးမြောက်ပြီးပါက သင်သည် အောက်ပါအရာများကို သိရှိ/နားလည်ထားမည်ဖြစ်သည်။
- အေးဂျင့် observable ဖြစ်မှုနှင့် သုံးသပ်ခြင်း၏ အခြေခံအယူအဆများ
- အေးဂျင့်များ၏ လုပ်ဆောင်ရည်၊ ကုန်ကျစရိတ်နှင့် ထိရောက်မှုကို တိုးတက်စေသည့် နည်းလမ်းများ
- သင့် AI အေးဂျင့်များကို စနစ်တကျ ဘာများနှင့် မည်သို့ သတ်မှတ်လေ့လာရမည်ကို
- ထုတ်လုပ်မှုသွင်းရာတွင် ကုန်ကျစရိတ် ထိန်းချုပ်နည်းများ
- Microsoft Agent Framework ဖြင့် တည်ဆောက်ထားသည့် အေးဂျင့်များကို မည်သို့ instrument ထားရမည်ကို
ဤရည်ရွယ်ချက်မှာ သင့် “အနက်သေတ္တာ” အဖြစ်ရှိသော အေးဂျင့်များကို ဖော်ပြနိုင်သော၊ စီမံခန့်ခွဲနိုင်သော၊ ယုံကြည်စိတ်ချရသော စနစ်များအဖြစ် ပြောင်းလဲနိုင်ရန် သိမြင်စေခြင်းဖြစ်သည်။
မှတ်ချက်: လုံခြုံနှင့် ယုံကြည်ရစေရန် AI အေးဂျင့်များကို ထည့်သွင်းအသုံးချရန် အရေးကြီးသည်။ Building Trustworthy AI Agents သင်ခန်းစာကိုလည်း ကြည့်ရှုပါ။
Traces and Spans
Observability ကိရိယာများဖြစ်သည့် Langfuse သို့မဟုတ် Microsoft Foundry ကဲ့သို့သော ကိရိယာများသည် အေးဂျင့် chạy များကို မကြာခဏ trace နှင့် span အဖြစ် ကိုယ်စားပြုကြသည်။
- Trace သည် တစိတ်တပိုင်းအေးဂျင့် တာဝန်တစ်ခုလုံးကို အစမှအဆုံး (ဥပမာ အသုံးပြုသူမေးခွန်းကို xử lý ပြုလုပ်ခြင်း) ကို ကိုယ်စားပြုသည်။
- Spans သည် trace အတွင်းရှိ တစ်ခုချင်းစီအဆင့်များဖြစ်သည် (ဥပမာ language model ကို ခေါ်ယူခြင်း သို့မဟုတ် ဒေတာရယူခြင်း ကဲ့သို့)။
Observability မရှိပါက AI အေးဂျင့်သည် “အနက်သေတ္တာ(black box)” ကဲ့သို့ ခံစားရနိုင်ပြီး ၎င်း၏ အတွင်းအခြေအနေနှင့် ထောက်လှမ်းရေးများဟာ မမြင်နိုင်သဖြင့် ပြဿနာများကို တွေ့ရှိ/အကောင်းဆုံး အမြန်ဖြေရှင်းရန် ခက်ခဲစေသည်။ Observability အပါအဝင်ဖြင့် အေးဂျင့်များကို “ကမ္မရှူးပွင့်ထွက်(glass boxes)” အဖြစ် ပြောင်းလဲစေပြီး ယုံကြည်စိတ်ချမှု တည်ဆောက်ရန်နှင့် ၎င်းတို့ ဆောင်ရွက်သလို အလုပ်လုပ်နေကြောင်း သေချာစေရန် အလွန်အရေးကြီးသည်။
ထုတ်လုပ်မှုပတ်ဝန်းကျင်များတွင် Observability အရေးကြီးသော အကြောင်းရင်း
AI အေးဂျင့်များကို ထုတ်လုပ်မှုပတ်ဝန်းကျင်သို့ ရှေ့ဆက်ရန်အခါ အကွာအဝေးအသစ်များနှင့် လိုအပ်ချက်အသစ်များ ရှိလာမည်။ Observability သည် “ရှိသင့်မရှိသင့်” အရာမဟုတ်တော့ဘဲ အရေးပါသော စွမ်းရည်တစ်ခုဖြစ်လာပါသည်။
- အစွမ်းထုတ်ခြင်းနှင့် အမှား၏ အကြောင်းရင်းရှာဖွေခြင်း(Debugging and Root-Cause Analysis): အေးဂျင့် ဖျက်သိမ်းမိသည် သို့မဟုတ် မမျှော်လင့်ထားသော ထုတ်လွှင့်ချက် ထွက်လာသောအခါ Observability ကိရိယာများသည် အမှား၏ မူရင်းအရင်းအမြစ်ကို ဖော်ထုတ်ရန် လိုအပ်သော trace များကို ပံ့ပိုးပေးသည်။ ၎င်းသည် LLM ခေါ်ဆိုမှုများစွာ၊ ကိရိယာ(tool) နှင့် အခြေအနေအလိုက် တုန့်ပြန်မှုများပါဝင်နိုင်သည့် ဖွဲ့စည်းတည်ဆောက်မှုရှုပ်ထွေးသည့် အေးဂျင့်များအတွက် အထူးအရေးကြီးသည်။
- အသံညှိနှင့် ကုန်ကျစရိတ် စီမံခန့်ခွဲခြင်း(Latency and Cost Management): AI အေးဂျင့်များသည် token များအလိုက် သို့မဟုတ် ခေါ်ဆိုမှုအလိုက် စျေးနှုန်းတွက်ချက်သော LLM များနှင့် အခြား အပြင် APIs များပေါ်တွင် မူတည်ကာ လည်ပတ်လေ့ရှိသည်။ Observability သည် ထိုခေါ်ဆိုမှုများကို တိတိကျကျ မှတ်တမ်းတင်နိုင်စေပြီး၊ နှေးကွေးလျှင် သို့မဟုတ် လွန်စွာ ఖrcေ့သော လုပ်ငန်းစဉ်များကို ဖော်ထုတ်နိုင်သည်။ ၎င်းက အသုံးပြုသူအတွေ့အကြုံကောင်းစေရန် prompt များပြုပြင်ခြင်း၊ ပိုထိရောက်သော မော်ဒယ်ရွေးချယ်ခြင်း သို့မဟုတ် workflow များကို ပြန်လည်ဒီဇိုင်းဆွဲခြင်းတို့ကို ခွင့်ပြုသည်။
- ယုံကြည်စိတ်ချမှု၊ လုံခြုံရေးနှင့် လိုက်နာမှု(Trust, Safety, and Compliance): အများသော လော့ချ်များတွင် အေးဂျင့်များသည် လုံခြုံ၍ ဓေလေရာမရှိစေရန် အရေးကြီးသည်။ Observability သည် အေးဂျင့်၏ လုပ်ဆောင်ချက်များနှင့် ဆုံးဖြတ်ချက်များအတွက် audit trail တစ်ခုကို ပံ့ပိုးပေးသည်။ ၎င်းအား သုံးစွဲ၍ prompt injection, အန္တရာယ်ရှိသော မက်ဆေ့ချ်ဖန်တီးခြင်း သို့မဟုတ် PII (ကိုယ်ရေးလက်ရေးသိမှတ်ချက်များ) မဟုတ်သင့်သော အချက်အလက်များကို မလိမ့်တမ်းကိုင်တွယ်သည့် အကြောင်းအရာများကို ရှာဖွေနိုင်သည်။ ဥပမာအားဖြင့် တစ်ချို့ traces များကို ပြန်လည်သုံးသပ်၍ အေးဂျင့်သည် ဘာကြောင့် တစ်ခုသော တုံ့ပြန်ချက်ကို ပေးလိုက်သလဲ သို့မဟုတ် ဘာကြောင့် တစ်ခုသော ကိရိယာကို အသုံးပြုလိုက်သလဲကို နားလည်နိုင်သည်။
- ဆက်လက်တိုးတက်မှု လည်ပတ်မှုများ(Continuous Improvement Loops): Observability ဒေတာသည် အဆင့်ချင်းတိုးတက်မှုလုပ်ငန်းစဉ်၏ အခြေခံဖြစ်သည်။ အေးဂျင့်များကို တကယ့်လောကတွင် မည်သို့ လုပ်ဆောင်နေသည်ကို ထိန်းယူကြည့်ရှုခြင်းအားဖြင့် အကောင်းမွန်ရေးအတွက် မြှင့်တင်သည့် နေရာများကို ဖော်ထုတ်နိုင်ပြီး မော်ဒယ် fine-tuning အတွက် ဒေတာစုဆောင်းကာ ပြင်ဆင်မှုများ၏ သက်ရောက်မှုကို သက်သေပြသနည်းဖြင့် စစ်ဆေးနိုင်သည်။ ၎င်းက online evaluation မှ ရရှိသော ထုတ်လုပ်မှု အတွင်း အချက်အလက်များအား offline စမ်းသပ်ချက်များနှင့် ပေါင်းစပ်၍ ဆက်လက်လေ့လာExperimentation များကို သောကယ်သည့် လည်ပတ်မှုတစ်ခုကို ဖန်တီးပေးသည်။
ထိန်းသိမ်းရန် အဓိက မီထရစ်များ
အေးဂျင့်လေ့လာမှုနှင့် အလားအလာကို ကြည့်ရန် metrics မျိုးစုံကို အကောက်ခွာထားရမည်။ အေးဂျင့်၏ ရည်ရွယ်ချက်ပေါ်မူတည်၍ အထူး metrics များကွာခြားနိုင်ပေမယ့် အချို့သည် အမြဲတမ်း အရေးပါသည်။
Observability ကိရိယာများက မကြာခဏ ကြည့်မည့် အထင်ကြီး metrics အချို့မှာ အောက်ပါအတိုင်းဖြစ်သည်။
Latency: အေးဂျင့်သည် မည်မျှအမြန်တုံ့ပြန်သနည်း။ များစွာ ခဏချိန်စောင့်ရသည့်အချိန်များသည် အသုံးပြုသူအတွေ့အကြုံကို မကောင်းစေပါ။ အလုပ်အမှုများနှင့် တစ်ဆင့်ချင်းစီအတွက် latency ကို agent run များအား tracing ဖြင့် တိုင်းတာသင့်သည်။ ဥပမာအားဖြင့် model ခေါ်ဆိုမှုများအတွက် စုစုပေါင်း 20 စက္ကန့်ယူသော အေးဂျင့်တစ်ရပ်ရှိပါက ပိုမိုမြန်ဆန်သော မော်ဒယ် သုံးခြင်း သို့မဟုတ် မော်ဒယ်ခေါ်ဆိုမှုများကို 병렬(running in parallel) ဟာ စိတ်ချရသောဖြေရှင်းချက်ဖြစ်နိုင်သည်။
Costs: တစ်ကြိမ်အေးဂျင့် run တစ်ခုလျှင် ကုန်ကျစရိတ် ဘယ်လောက်လဲ။ AI အေးဂျင့်များသည် token အလိုက် သို့မဟုတ် အပြင် API ခေါ်ဆိုမှုအလိုက် စေလွှတ်ခံရသော LLM ခေါ်ဆိုမှုများပေါ် မူတည်သည်။ ကိရိယာများအတွက် အသုံးပြုမှုများ မကြာခဏဖြစ်ခြင်း သို့မဟုတ် prompt များ များစွာ သုံးခြင်းသည် ကုန်ကျစရိတ်ကို အလျင်အမြန် မြင့်တက်စေနိုင်သည်။ ဥပမာ၊ အေးဂျင့်သည် အရည်အသွေးပိုမိုကောင်းလာစေရန်အတွက် LLM ကို ၅ ကြိမ်ခေါ်သုံးလျှင် ကုန်ကျစရိတ် ယုံကြည်ဖို့ သင့်တော်သလား၊ သို့မဟုတ် ခေါ်ဆိုချက်များကို လျော့နည်းစေခြင်း သို့မဟုတ် စျေးသက်သာသော မော်ဒယ်အသုံးပြုခြင်းဖြင့် ဖြေရှင်းနိုင်သလားကို သုံးသပ်ရမည်။ အချိန်နှင့်တပြေးညီ သတိပေးမှုများသည် မမျှော်လင့်သော ပွါးထွက်မှုများ (ဥပမာ အသုံးမလိုအပ်သော API loop များကြောင့် bug များ) ကိုလည်း ဖော်ထုတ်နိုင်သည်။
Request Errors: အေးဂျင့်သည် မည်မျှ ကုဒ်တောင်းဆိုမှုများကို မအောင်မြင်ပါသနည်း။ ၎င်းတွင် API error များ သို့မဟုတ် tool ခေါ်ဆိုမှု မအောင်မြင်မှုများ ပါဝင်နိုင်သည်။ ထုတ်လုပ်မှုတွင် အဆိုပါ အမှားများအပေါ် အတောက်ပဆုံး အားခံနိုင်စေလိုလျှင် fallback များ သို့မဟုတ် retry များကို သတ်မှတ်နိုင်သည်။ ဥပမာ၊ LLM provider A ကို အသုံးမပြုနိုင်သောအခါ LLM provider B သို့ ပြောင်းလဲသူ တစ်ယောက်အဖြစ် သတ်မှတ်နိုင်သည်။
User Feedback: အသုံးပြုသူတိုက်ရိုက် အကဲဖြတ်ချက်(Direct user evaluations) များက အလွန်တန်ဖိုးရှိသော သိကောင်းစရာများ ပေးနိုင်သည်။ ၎င်းတွင် ဖော်ပြချက်(Explicit) အဖြစ် အဆင့်ပေးခြင်း (👍 အကောင်း/👎 အမှား, ⭐1-5 ကြယ်) သို့မဟုတ် စာသားမှတ်ချက်များ ပါဝင်နိုင်သည်။ အမြဲတမ်း အနုတ်လက္ခဏာများ ရှိနေပါက ၎င်းသည် အေးဂျင့်အလုပ်မမှန်သည့် အချက်တစ်ခုဖြစ်သဖြင့် သတိပေးစေပါလိမ့်မည်။
Implicit User Feedback: အသုံးပြုသူပြုသွားသော အပြုအမူများသည် ဖော်ပြချက်မပေးဘဲလည်း အကြောင်းပြချက်ရှာဖွေရန် အကြောင်းအရာများပေးနိုင်သည်။ ၎င်းတွင် မိမိမေးခွန်းကို ချက်ချင်း ပြန်လည်ဖေါ်ပြခြင်း၊ ထပ်မံမေးခြင်း သို့မဟုတ် retry ခလုတ်ကို နှိပ်ခြင်း ကဲ့သို့သော အပြုအမူများ ပါဝင်သည်။ ဥပမာ၊ အသုံးပြုသူများသည် တခါထက်ပို၍ တူညီသော မေးခွန်းကို ထပ်မံမေးနေသည်ကို တွေ့ပါက ၎င်းသည် အေးဂျင့်သည် မမျှော်လင့်သလို လုပ်ဆောင်နေကြောင်းရုပ်သိမ်းဖြစ်နိုင်သည်။
Accuracy: အေးဂျင့်သည် မှန်ကန်သည့် သို့မဟုတ် ဆန္ဒရှိသော ထုတ်လွှင့်ချက်များကို ဘယ်နှစ်ကြိမ်ထပ်ထုတ်သနည်း။ Accuracy သတ်မှတ်ချက်များသည် အမျိုးမျိုးပြောင်းလဲနိုင်သည် (ဥပမာ ဖြေရှင်းမှုမှန်ကန်မှု၊ သတင်းအချက်အလက် ရယူမှု မှန်ကန်မှု၊ အသုံးပြုသူ စိတ်ကျေနပ်မှု)။ ပထမဆင့်ထားရမည့်အရာမှာ သင့်အေးဂျင့်အတွက် အောင်မြင်မှုဆိုတာ ဘယ်လို ရှိမလဲဆိုတာ သတ်မှတ်ခြင်းဖြစ်သည်။ သင်သည် automated checks, evaluation scores, သို့မဟုတ် task completion labels များဖြင့် accuracy ကို ချေနိုင်သည်။ ဥပမာအားဖြင့် traces များကို “succeeded” သို့မဟုတ် “failed” ဟု အမှတ်အသားပေးခြင်း။
Automated Evaluation Metrics: Automated evals များကိုလည်း သတ်မှတ်နိုင်သည်။ ဥပမာအနေဖြင့် LLM တစ်ခုကို သုံး၍ အေးဂျင့်၏ ထုတ်လွှင့်ချက်ကို အကဲဖြတ်စစ်ဆေးနိုင်သည် — ကောင်းမွန်/မှားယွင်း/မထွက်သင့် စသည်ဖြင့် အမှတ်ပေးနိုင်သည်။ ထို့အပြင် အေးဂျင့်၏ အစိတ်အပိုင်းများကို စမ်းသပ်အကဲဖြတ်နိုင်ရန် ကူညီပေးသည့် open source 라이ဘရရီများ များစွာရှိသည်။ ဥပမာ RAGAS သည် RAG အေးဂျင့်များအတွက် သို့မဟုတ် LLM Guard သည် အန္တရာယ်ရှိသော ဘာသာစကား သို့မဟုတ် prompt injection ကို တွေ့ရှိရန် အသုံးပြုနိုင်သည်။
လက်တွေ့တွင် ဤ metrics များကို ပေါင်းစပ်အသုံးပြုခြင်းဖြင့် AI အေးဂျင့်၏ ကျန်းမာရေးကို အကောင်းဆုံး ဖုံးလွှမ်းနိုင်သည်။ ဤအခန်းရှိ example notebook တွင် ဤ metrics များသည် တကယ့်ตัวอย่างများတွင် မည်သို့ ဖော်ပြသည်ကို ပြသမည် ဖြစ်သည်၊ သို့သော် ပထမဦးစွာ သင်သည် တစ်ခုနှင့်သတ်မှတ်ထားသည့် evaluation workflow များမည်သို့ ဖြစ်သည်ကို သင်ယူမည်။
သင့်အေးဂျင့်ကို Instrument တင်ရန်
Tracing ဒေတာကို စုဆောင်းရန် သင်၏ ကုဒ်ကို instrument ပြုလုပ်ရန် လိုအပ်သည်။ ရည်ရွယ်ချက်မှာ အေးဂျင့်ကုဒ်ကို instrument ပြုလုပ်၍ trace နှင့် metrics များ ထုတ်ပေးနိုင်စေခြင်းဖြစ်ပြီး ၎င်းတို့ကို observability ပလက်ဖောင်းက ဖမ်းယူ၊ ဖော်ပြနှင့် မြင်သာစေရန် ဖြစ်သည်။
OpenTelemetry (OTel): OpenTelemetry သည် LLM observability အတွက် ကဏ္ဍစံချိန်တစ်ခုအဖြစ် ထွက်ပေါ်လာသည်။ ၎င်းသည် telemetry data ထုတ်ပေးခြင်း၊ စုဆောင်းခြင်းနှင့် export လုပ်ခြင်းအတွက် API များ၊ SDK များနှင့် ကိရိယာများ စုံစမ်းပေးသည်။
ပစ္စည်းတစ်ချို့မှာ ရှိပြီးသား agent frameworks များကို wrapper သတ်မှတ်ထားသည့် instrumentation 라이ဘရရီများရှိပြီး OpenTelemetry span များကို observability ကိရိယာသို့ အလွယ်တကူ export လုပ်နိုင်စေသည်။ Microsoft Agent Framework သည် OpenTelemetry နှင့် သဘာဝအတိုင်း ပေါင်းစည်းထားသည်။ အောက်တွင် MAF agent ကို 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 လုပ်ဆောင်ချက်များကို အလိုအလျောက် လိုက်လံမှတ်တမ်းတင်သည်
pass
ဤအခန်းရှိ example notebook သည် သင့် MAF agent ကို မည်သို့ instrument ပြုလုပ်ရမည်ကို ပြသပါလိမ့်မည်။
Manual Span Creation: Instrumentation 라이ဘရရီများက အခြေခံအဆင့်ကောင်းတစ်ခု ပေးထားပေမယ့် ပိုမိုအသေးစိတ် သို့မဟုတ် custom အချက်အလက်များလိုအပ်သော ကိစ္စများ မကြာခဏ ဖြစ်ပေါ်နိုင်သည်။ သင်သည် custom application logic ထည့်ရန် span များကို လက်ဖြင့် ဖန်တီးနိုင်သည်။ အရေးကြီးသည်မှာ၊ automated သို့မဟုတ် လက်မှု span များကို custom attributes (tag များ သို့မဟုတ် metadata အဖြစ်လည်း သိကြသည်) ဖြင့် တိုးမြှင့်နိုင်သည်။ ဤ attributes များတွင် စီးပွားရေးအပိုင်းဆိုင်ရာ ဒေတာများ၊ အလယ်ပိုင်းတွက်ချက်ချက်များ သို့မဟုတ် debugging သို့မဟုတ် analysis အတွက် အသုံးဝင်နိုင်သည့် မည်သည့် context မဆို ပါဝင်နိုင်သည်၊ ဥပမာ user_id, session_id, သို့မဟုတ် model_version ကဲ့သို့။
Langfuse Python SDK ကို အသုံးပြု၍ traces နှင့် spans များကို လက်ဖြင့် ဖန်တီးသည့် ဥပမာ:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
အေးဂျင့် အကဲဖြတ်ခြင်း (Agent Evaluation)
Observability က ကျွန်ုပ်တို့အား metrics များပေးသည်၊ သို့ပေမယ့် အကဲဖြတ်ခြင်းသည် အဲဒီဒေတာကို (နှင့် စမ်းသပ်ချက်များကို ဆောင်ရွက်ပြီး) စစ်ဆေးခြင်းဖြင့် AI အေးဂျင့်၏ အလုပ်ဆောင်မှု ဘယ်လိုရှိနေသည်နှင့် မည်သို့တိုးတက်စေမည်ကို သတ်မှတ်သည့် လုပ်ငန်းစဉ်ဖြစ်သည်။ အဓိပ္ပါယ်အားဖြင့် traces နှင့် metrics များ ရရှိလာပါက ၎င်းတို့အား ဘယ်လိုအသုံးချ၍ အေးဂျင့်ကို အကဲဖြတ်၍ ဆုံးဖြတ်ချက်များချမည်နည်း။
တည်ငြိမ်စွာ သုံးသပ်ခြင်းမှာ အရေးကြီးသည်။ အကြောင်းမှာ AI အေးဂျင့်များသည် မသေချာသည့် အဖြစ်အပျက်များ ရှိလေ့ရှိပြီး (အပ်ဒိတ်များ သို့မဟုတ် မော်ဒယ်လုပ်ဆောင်ချက်ရောက်ကျော်မှုကြောင့်) တိုးတက်လာနိုင်သည် — evaluation မရှိဘဲဖြစ်ပါက သင်၏ “သိမြင်ပါသော အေးဂျင့်” သည် တကယ့်အားဖြင့် သူ့လုပ်ငန်းကို အကောင်းဆုံးအတိုင်း ဆောင်ရွက်နေသည်ဟု မသိနိုင်ပါ။
AI အေးဂျင့်များအတွက် အကဲဖြတ်ခြင်းကို နှစ်မျိုးအမျိုးအစား ရှိသည်: online evaluation နှင့် offline evaluation။ နှစ်မျိုးစလုံး တန်ဖိုးရှိပြီး အချင်းချင်း ဖြည့်ဆည်းပေးကြသည်။ ကျွန်ုပ်တို့သည် ထုံးစံအရ ဖန်တီးရာတွင် offline evaluation ဖြင့် စတင်ခြင်း ဖြစ်သည်၊ အာရုံစိုက်မှုနည်းဆုံး ပြဳလုပ်ရမည့် အဆင့်ဖြစ်သည်။
Offline Evaluation
ဤသည်မှာ ထုတ်လုပ်မှုမဟုတ်သော ထိန်းချုပ်ထားသောပတ်ဝန်းကျင်တွင် အေးဂျင့်ကို အကဲဖြတ်ခြင်းဖြစ်သည်၊ ပုံမှန်အားဖြင့် စမ်းသပ် dataset များကို အသုံးပြုသည်။ သင့်တွင် မျှော်လင့်သည့် ထုတ်လွှင့်ချက် သို့မဟုတ် မှန်ကန်သော အပြုအမူကို သိထားသော curated datasets များကို သုံးပြီး အေးဂျင့်ကို ဆောင်ရွက်စေသည်။
ဥပမာအားဖြင့် သင်သည် သင့်ကို သင်ခန်းစာမေးခွန်းဆိုင်ရာ အေးဂျင့်တစ်ခု တည်ဆောက်ထားလျှင် ၊ သင်သည် အဖြေသိရှိပြီး 100 ပြဿနာပါသော test dataset တစ်ခုကို အသုံးပြုနိုင်သည်။ Offline evaluation ကို မကြာခဏ ဖွံ့ဖြိုးရေးအတွင်းတွင် ပြုလုပ်ပြီး (CI/CD pipeline များ၏ အစိတ်အပိုင်းတစ်ခုဖြစ်နိုင်သည်) တိုးတက်မှုများကို စစ်ဆေးရန် သို့မဟုတ် regressions များမှ ကာကွယ်ရန် အသုံးပြုသည်။ ကောင်းကျိုးမှာ ၎င်းသည် ပြန်လည်ထပ်ဆင့်နိုင်ပြီး ground truth ရှိသဖြင့် ရှင်းလင်းသော accuracy metrics ကို ရယူနိုင်သည်။ အသုံးပြုသူမေးခွန်းများကို အတုယူပြီး အကဲဖြတ်နိုင်သည်၊ သို့မဟုတ် အပေါ်တွင်ဖေါ်ပြထားသည့် automated metrics များကို သုံးနိုင်သည်။
Offline evaluation ၏ အဓိက စိန်ခေါ်ချက်မှာ သင်၏ စမ်းသပ် dataset ကို ဖုံးလွှမ်းမှုကောင်းစေပြီး သက်ဆိုင်မှုရှိရန် ထိန်းသိမ်းထားရန် ဖြစ်သည် — အေးဂျင့်သည် တည်ငြိမ်စွာ ပြုလုပ်ထားသော စမ်းသပ်အစုအဝေးပေါ်တွင် သက်သာစွာ လုပ်ဆောင်နိုင်သော်လည်း ထုတ်လုပ်မှုတွင် မတူညီသည့် မေးခွန်းများအား ရင်ဆိုင်ကြုံတွေ့နိုင်သည်။ ထို့ကြောင့် စမ်းသပ်အစုများကို နောက်ထပ် အရိပ်အမြင်များနှင့် လက်တွေ့ကိစ္စများကို ကိုက်ညီအောင် update လုပ်ထားသင့်သည်။ အသေးငယ်သော “smoke test” အမှုများနှင့် ပိုကြီးမားသော evaluation စုံစုများကို ရောထွေးသုံးရန် အကျိုးရှိသည် — အသေးသည့်အစုများသည် အမြန်စစ်ဆေးရန်၊ ပိုကြီးသောထဲမွှန်းများသည် ကျယ်ပြန့်သော လုပ်ဆောင်နိုင်စွမ်း metrics များကိုတွက်ချက်ရန် အသုံးဝင်သည်။
Online Evaluation
ဤသည်မှာ တိုက်ရိုက် အသုံးပြုမှုဖြင့် သို့မဟုတ် ထုတ်လုပ်မှုအခြေအနေတွင် အေးဂျင့်ကို အကဲဖြတ်ခြင်းကို ဆိုလိုသည်။ Online evaluation သည် တကယ့်အသုံးပြုသူ တုံ့ပြန်ချက်များပေါ်တွင် အရေးကြီး metrics များကို မျှော်မီ monitoring လုပ်၍ အစဉ်အမြဲ ချိတ်ဆက်လေ့လာခြင်းကို လုပ်ဆောင်သည်။
ဥပမာ၊ success rates, အသုံးပြုသူကျေနပ်မှု rating များ သို့မဟုတ် အမှုအမျိုးမျိုးကို live traffic ပေါ်တွင် ချိတ်ဆက်စောင့်ကြည့်နိုင်သည်။ Online evaluation ၏ အားသာချက်မှာ ဓမ္မသမိုင်းခန်းတွင် မမျှော်လင့်နိုင်သော အချက်များကို ဖမ်းယူပေးနိုင်သည် — အေးဂျင့်၏ ထိရောက်မှုသည် အချိန်အလိုက် (input အမျိုးအစားပြောင်းလဲမှုကြောင့်) ဆုတ်ကျသွားနိုင်သည်ဟု တွေ့နိုင်သည်၊ မျှော်မင့်ထားသော မေးခွန်းများ သို့မဟုတ် ထူးဆန်းသော အခြေအနေများကို ရှာဖွေနိုင်သည်။ ၎င်းက ထုတ်လုပ်မှုတွင် အေးဂျင့်က ဘယ်လိုအပြုအမူ ပြုလုပ်နေသည်ကို တကယ့်ကို ရိုက်နှိပ်ထားသော ရုပ်ပုံကို ပေးသည်။
Online evaluation သည် implicit နှင့် explicit user feedback များစုဆောင်းခြင်း၊ shadow tests သို့မဟုတ် A/B test များ ပြုလုပ်ခြင်း (နစ်နာသော agent ဗားရှင်းအသစ်ကို ယခင်ဗားရှင်းနှင့် တပြိုင်နက် ပိုင်းခြားစမ်းသပ်ခြင်း) များပါဝင်နိုင်သည်။ စိန်ခေါ်ချက်မှာ live interactions များအတွက် ယုံကြည်စိတ်ချရသော label များ သို့မဟုတ် score များ ရရှိစေဖို့ ခက်ခဲနိုင်သည် — သင်သည် အသုံးပြုသူတုံ့ပြန်ချက်များ သို့မဟုတ် downstream metrics (ဥပမာ အသုံးပြုသူသည် ရလဒ်ကို တစ်ခါတည်း နှိပ်ခဲ့မလား) များပေါ် မူတည်နိုင်သည်။
နှစ်မျိုးကို ပေါင်းစည်းခြင်း
Online နှင့် offline evaluation များသည် အချင်းချင်းမဆန့်ကျင်သဟာသရာဖြစ်ကြပါ။ ၎င်းတို့သည် အချင်းချင်းကို ဖြည့်ဆည်းပေးသည်။ Online monitoring မှ ရရှိသော အရှိန်အဟုန်များ(ဥပမာ agent သည် မပြေပြစ်သော မေးခွန်းအမျိုးအစားအသစ်များ၌ ပျက်ကွက်နေခြင်း) ကို offline စမ်းသပ် dataset များအား ဖွံ့ဖြိုးခြင်းနှင့် တိုးတက်အောင် အသုံးပြုနိုင်သည်။ အနှစ်ချုပ်အားဖြင့် offline စမ်းသပ်တွင် ကောင်းစွာ လုပ်ဆောင်သော အေးဂျင့်များကို ထုတ်လုပ်ရေးတွင် ပို့ချပြီး online တွင် ပိုမိုယုံကြည်စိတ်ချစွာ မျက်နှာဖုံး၍ မော်နီတာလုပ်နိုင်သည်။
အများအားဖြင့် အဖွဲ့များသည် အောက်ပါ ဝင်ရိုးစဉ်ကို လက်နက်တင်လေ့ရှိသည်။
evaluate offline -> deploy -> monitor online -> collect new failure cases -> add to offline dataset -> refine agent -> repeat.
အထင်ကြီးပျက်နှိုးများ (Common Issues)
AI အေးဂျင့်များကို ထုတ်လုပ်မှုသို့ ထည့်သွင်းသည့်အခါ အမျိုးမျိုးသော စိန်ခေါ်မှုများနှင့် ရင်ဆိုင်ရနိုင်သည်။ အောက်တွင် ပုံမှန်ကျော်ကြားသော ပြဿနာများနှင့် ၎င်းတို့၏ဖြေရှင်းနည်းအချို့ကို ဖော်ပြထားသည်။
| ပြဿနာ (Issue) | ဖြေရှင်းနိုင်သည့် နည်းလမ်း (Potential Solution) |
|---|---|
| AI Agent အလုပ်များကို တည်ကြာစွာ မကျေအောင် ဆောင်ရွက်နေခြင်း | - AI Agent ကို ပေးသော prompt ကို အနက်ရှင်းပြေရှင်းစေပါ； ရည်ရွယ်ချက်များကို သေချာဖော်ထုတ်ပါ။ - အလုပ်များကို အပိုင်းခွဲ၍ အေးဂျင့်အများကြီးဖြင့် ကိုင်တွယ်ခြင်းက ကူညီနိုင်သည်ဟု ရှာဖွေပါ။ |
| AI Agent များ ဆက်တိုက် loop အတွင်း ပတ်လည်နေရခြင်း | - Agent သည် ဘယ်အချိန်တွင် ရပ်ရမည်ဆိုသော ကန့်သတ်ချက်များနှင့် ဖျက်ချိန်စာရင်းများကို သေချာထားပါ။ - တွက်ချက်ခြင်းနှင့် အစီအစဉ်လိုအပ်သော စောင့်ကြည့်မှုများအတွက် အကြီးစား မော်ဒယ်တစ်ခု သုံးပါ။ |
| AI Agent ကိရိယာ(tool) ခေါ်ဆိုမှုများ မကောင်းစွာ လုပ်ဆောင်နေခြင်း | - ကိရိယာ၏ ထွက်ပေါက်ကို agent စနစ်သည်မတိုက်ရိုက်သည့်နေရာတွင် စမ်းသပ် နှင့် အတည်ပြုပါ။ - သတ်မှတ်ထားသော ပါရာမီတာများ၊ prompts နှင့် ကိရိယာအမည်များကို ပြုပြင်ပါ။ |
| Multi-Agent စနစ် အလုပ်မမှန်ဆောင်ရွက်ခြင်း | - တစ်ဦးချင်းစီအတွက် ပေးသော prompt များကို ထပ်မံသုံးသပ်၍ ထူးခြားချက်များနှင့် သေချာသည့် ညွှန်ကြားချက်များပေးပါ။ - ဌာနေမှု သို့မဟုတ် controller agent တစ်ခုကို အသုံးပြု၍ ဤ agent မည်သူဖြစ်သင့်ကြောင်း သတ်မှတ်ပေးသည့် hierarchical system တည်ဆောက်ပါ။ |
ဤပြဿနာများအများစုကို observability ရှိပါက ပိုမိုထိရောက်စွာ ရှာဖွေစစ်ဆေးနိုင်သည်။ ဤတွင် ဖော်ပြထားသော traces နှင့် metrics များက အေးဂျင့် workflow ၏ တိတိကျကျ မည်သည့်အဆင့်တွင် ပြဿနာများ ဖြစ်ပေါ်နေကြောင်း ကိုင်တွယ်ဖော်ထုတ်ရာတွင် အထောက်အကူဖြစ်စေ၍ debugging နှင့် optimization ကို ထိုးဖောက် လုပ်ဆောင်ရန် ပိုမိုထိရောက်စေသည်။
ကုန်ကျစရိတ် စီမံခန့်ခွဲမှု
Here are some strategies to manage the costs of deploying AI agents to production:
Using Smaller Models: ကျယ်ပြန့်စွာအသုံးပြုသော agentic use-case အချို့တွင် Small Language Models (SLMs) များကောင်းစွာ လုပ်ဆောင်နိုင်ပြီး ကုန်ကျစရိတ်ကို တဖြည်းဖြည်း လျော့ချနိုင်သည်။ ယခင်တွင် ဖော်ပြထားသကဲ့သို့ performance ကို ကြီးမားသော models များနှင့် ယှဉ်ပြိုင် သတ်မှတ်ရန် နှိုင်းယှဉ်ရန် အကဲဖြတ်စနစ်တစ်ခု တည်ဆောက်ခြင်းက SLM သည် သင့် use case အတွက် ဘယ်လောက်ကောင်းမလဲကို နားလည်ရန် အကောင်းဆုံးနည်းလမ်းဖြစ်သည်။ intent classification သို့မဟုတ် parameter extraction ကဲ့သို့ ရိုးရှင်းသော အလုပ်များအတွက် SLM များကို အသုံးပြုရန် စဉ်းစားပြီး၊ စဉ်းစားရန် ကြုံရာတွင်တော့ ကြီးမားသော models များကို ထိန်းသိမ်းထားပါ။
Using a Router Model: တူညီသော မဟာဗျူဟာတစ်ခုမှာ မတူညီသော model များနှင့် အရွယ်အစားများကို အသုံးချခြင်းဖြစ်သည်။ LLM/SLM သို့မဟုတ် serverless function တစ်ခုကို အသုံးပြု၍ complexity အပေါ်မူတည်ပြီး တောင်းဆိုချက်များကို အကောင်းဆုံးသင့်တော်သည့် model များသို့ လမ်းညွှန်နိုင်သည်။ ၎င်းက ကုန်ကျစရိတ်ကို လျော့ချပေးနိုင်သလို သင့်တာဝန်သတ်မှတ်ထားသော အလုပ်များတွင် စွမ်းဆောင်ရည်ကိုလည်း ထိန်းသိမ်းပေးနိုင်သည်။ ဥပမာ၊ ရိုးရှင်း၍ မြန်ဆန်သော မေးခွန်းများကို ပိုကျဉ်း၍ အရှိန်မြန်သော model များသို့ ပို့လိုက်၍၊ ပြင်းထန်သော အတွေးခေါ်မှုများအတွက်သာ စိတ်ဓာတ်ကြီးသော model များကို အသုံးပြုပါ။
Caching Responses: ပါဝင်သော တောင်းဆိုမှုများနှင့် အလုပ်များကို ဖော်ထွက်ကြောင်း ပြန်ကြည့်ရှု၍ agentic system သို့ မရောက်မီ အဖြေများကို ရှိရှိပေးခြင်းသည် သက်တမ်းတူ တောင်းဆိုမှုများ၏ အရွယ်အစားကို လျော့ချပေးရန် ကောင်းသောနည်းလမ်းတစ်ခုဖြစ်သည်။ ဆက်စပ်သော cached requests များနှင့် တောင်းဆိုချက်တစ်ခုက ဘယ်လောက်ဆင်တူသည်ကို ပိုမိုလွယ်ကူသော AI model များကို အသုံးပြု၍ ဖော်ထုတ်နိုင်သည့် flow တစ်ခုကိုပါ ဆောင်ရွက်နိုင်သည်။ ဤမဟာဗျူဟာသည် မကြာခဏမေးသောမေးခွန်းများ သို့မဟုတ် ပုံမှန် workflow များအတွက် ကုန်ကျစရိတ်ကို ထူးခြားစွာ လျော့ချနိုင်သည်။
Lets see how this works in practice
In the example notebook of this section, we’ll see examples of how we can use observability tools to monitor and evaluate our agent.
Got More Questions about AI Agents in Production?
Join the Microsoft Foundry Discord to meet with other learners, attend office hours and get your AI Agents questions answered.
Previous Lesson
Next Lesson
တာဝန်ပယ်ချချက်: ဤစာတမ်းကို AI ဘာသာပြန်ဝန်ဆောင်မှုဖြစ်သည့် Co-op Translator ဖြင့် ဘာသာပြန်ထားပါသည်။ ကျွန်ုပ်တို့သည် မှန်ကန်စွာ ဘာသာပြန်ရန် ကြိုးစားသော်လည်း အလိုအလျောက် ဘာသာပြန်ချက်များတွင် အမှားများ သို့မဟုတ် မှန်ကန်မှုလျော့နည်းချက်များ ရှိနိုင်ကြောင်း သတိပြုပါ။ မူလစာတမ်းကို မူရင်းဘာသာဖြင့်သာ စံနှုန်းအဖြစ်ယူဆသင့်သည်။ အရေးကြီးသော အချက်အလက်များအတွက် သက်ဆိုင်ရာ ပရော်ဖက်ရှင်နယ် လူ့ဘာသာပြန်ကို အသုံးပြုစေရန် အကြံပြုပါသည်။ ဤဘာသာပြန်ချက်ကို အသုံးပြုခြင်းကြောင့် ဖြစ်ပေါ်လာသည့် နားလည်မှားခြင်းများ သို့မဟုတ် အဓိပ္ပာယ်မှားဖော်ပြခြင်းများအတွက် ကျွန်ုပ်တို့ တာဝန်မယူပါ။