ai-agents-for-beginners

AI ကို ထုတ်လုပ်မှုတွင် အသုံးချခြင်း: ကြည့်ရှုနိုင်မှုနှင့် အကဲဖြတ်ခြင်း

AI ကို ထုတ်လုပ်မှုတွင် အသုံးချခြင်း

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

သင်ယူရမည့် ရည်မှန်းချက်များ

ဒီသင်ခန်းစာပြီးဆုံးပြီးနောက်၊ သင်သည် အောက်ပါအရာများကို သိရှိနားလည်နိုင်မည်ဖြစ်သည် -

ဤသင်ခန်းစာ၏ ရည်ရွယ်ချက်မှာ သင့် “အမဲရောင်သေတ္တာ” (black box) Agent များကို ပွင့်လင်းမြင်သာပြီး စီမံခန့်ခွဲနိုင်သော ယုံကြည်စိတ်ချရသော စနစ်များအဖြစ် ပြောင်းလဲနိုင်ရန် အသိပညာပေးခြင်းဖြစ်သည်။

မှတ်ချက်: ယုံကြည်စိတ်ချရသော AI Agent များကို ထုတ်လုပ်ရန် အရေးကြီးပါသည်။ Building Trustworthy AI Agents သင်ခန်းစာကိုလည်း ကြည့်ရှုပါ။

Traces နှင့် Spans

Langfuse သို့မဟုတ် Azure AI Foundry ကဲ့သို့သော ကြည့်ရှုနိုင်မှုကိရိယာများသည် Agent များ၏ လုပ်ဆောင်မှုကို trace နှင့် span အဖြစ် ကိုယ်စားပြုလေ့ရှိသည်။

Langfuse တွင် Trace tree

ကြည့်ရှုနိုင်မှုမရှိပါက AI Agent သည် “အမဲရောင်သေတ္တာ” (black box) ကဲ့သို့ ဖြစ်နိုင်ပြီး ၎င်း၏ အတွင်းအခြေအနေနှင့် အကြောင်းပြချက်များကို မမြင်နိုင်သဖြင့် ပြဿနာများကို ရှာဖွေခြင်း သို့မဟုတ် စွမ်းဆောင်ရည်ကို တိုးတက်စေရန် ခက်ခဲနိုင်သည်။ ကြည့်ရှုနိုင်မှုရှိပါက Agent များသည် “ဖန်သားသေတ္တာ” (glass box) ကဲ့သို့ ဖြစ်လာပြီး ယုံကြည်မှုတည်ဆောက်ရန်နှင့် ၎င်းတို့ကို ရည်ရွယ်သည့်အတိုင်း လုပ်ဆောင်စေရန် အရေးကြီးသော ပွင့်လင်းမြင်သာမှုကို ပေးစွမ်းပါသည်။

ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် ကြည့်ရှုနိုင်မှု အရေးကြီးသည့်အကြောင်း

AI Agent များကို ထုတ်လုပ်မှုပတ်ဝန်းကျင်သို့ ပြောင်းလဲအသုံးပြုရာတွင် စိန်ခေါ်မှုအသစ်များနှင့် လိုအပ်ချက်များကို ရင်ဆိုင်ရသည်။ ကြည့်ရှုနိုင်မှုသည် “လိုအပ်လျှင်သာ” သက်သက်မဟုတ်တော့ဘဲ အရေးကြီးသော စွမ်းရည်တစ်ခုဖြစ်လာသည် -

စောင့်ကြည့်ရန် အဓိက Metrics များ

Agent ၏ အပြုအမူကို စောင့်ကြည့်ရန်နှင့် နားလည်ရန်၊ အမျိုးမျိုးသော metrics နှင့် သင်္ကေတများကို စောင့်ကြည့်ရမည်ဖြစ်သည်။ Agent ၏ ရည်ရွယ်ချက်ပေါ်မူတည်၍ အထူး metrics များကွဲပြားနိုင်သော်လည်း အချို့သော metrics များသည် အထွေထွေ အရေးကြီးပါသည်။

အောက်တွင် ကြည့်ရှုနိုင်မှုကိရိယာများက စောင့်ကြည့်လေ့ရှိသော အများဆုံး metrics များကို ဖော်ပြထားသည် -

Latency: Agent သည် မည်မျှမြန်မြန် တုံ့ပြန်သနည်း။ စောင့်ဆိုင်းချိန်ကြာမြင့်ခြင်းသည် အသုံးပြုသူအတွေ့အကြုံကို ဆိုးရွားစေသည်။ Agent ၏ လုပ်ငန်းဆောင်တာများနှင့် တစ်ခုချင်းစီသော အဆင့်များအတွက် latency ကို trace များဖြင့် တိုင်းတာသင့်သည်။ ဥပမာအားဖြင့် မော်ဒယ်ခေါ်ဆိုမှုအားလုံးအတွက် ၂၀ စက္ကန့်ယူသော Agent တစ်ခုကို ပိုမြန်သော မော်ဒယ် သို့မဟုတ် မော်ဒယ်ခေါ်ဆိုမှုများကို တစ်ပြိုင်တည်း လုပ်ဆောင်ခြင်းဖြင့် မြန်ဆန်စေနိုင်သည်။

Costs: Agent တစ်ခု လုပ်ဆောင်မှုတစ်ခုစီအတွက် ကုန်ကျစရိတ်သည် မည်မျှနည်း။ AI Agent များသည် token အရ သို့မဟုတ် အပြင်ပ API များကို အခေါ်အရ ကုန်ကျစရိတ်ဖြင့် အားထားရသည်။ ကိရိယာများကို မကြာခဏ အသုံးပြုခြင်း သို့မဟုတ် prompt များစွာကို အသုံးပြုခြင်းသည် ကုန်ကျစရိတ်ကို မြန်မြန်တက်စေသည်။ ဥပမာအားဖြင့် Agent တစ်ခုက အရည်အသွေးအနည်းငယ်သာ တိုးတက်စေရန် LLM ကို ၅ ကြိမ်ခေါ်ဆိုပါက၊ ကုန်ကျစရိတ်သည် တန်ဖိုးရှိသလား သို့မဟုတ် ခေါ်ဆိုမှုအရေအတွက်ကို လျှော့ချရန် သို့မဟုတ် စျေးပေါသော မော်ဒယ်ကို အသုံးပြုရန် သုံးသပ်ရမည်။ အချိန်နှင့်တပြေးညီ စောင့်ကြည့်ခြင်းသည် မမျှော်လင့်ထားသော ကုန်ကျစရိတ်တက်ခြင်းများ (ဥပမာ - API loops များကို အလွန်အမင်း ဖြစ်စေသည့် bug များ) ကိုလည်း ဖော်ထုတ်နိုင်သည်။

Request Errors: Agent သည် မအောင်မြင်သော request များ မည်မျှရှိသနည်း။ ၎င်းတွင် API error များ သို့မဟုတ် ကိရိယာခေါ်ဆိုမှု မအောင်မြင်မှုများ ပါဝင်နိုင်သည်။ ထုတ်လုပ်မှုတွင် Agent ကို ပိုမိုခိုင်မာစေရန်၊ fallback သို့မဟုတ် retry များကို ပြုလုပ်နိုင်သည်။ ဥပမာအားဖြင့် LLM ပံ့ပိုးသူ A မရရှိပါက၊ backup အဖြစ် LLM ပံ့ပိုးသူ B သို့ ပြောင်းလဲနိုင်သည်။

User Feedback: အသုံးပြုသူများ၏ တိုက်ရိုက်အကဲဖြတ်ချက်များကို အကောင်းဆုံးအသုံးချပါ။ ၎င်းတွင် 👍thumbs-up/👎down, ⭐1-5 stars ကဲ့သို့သော အဆင့်သတ်မှတ်ချက်များ သို့မဟုတ် စာသားမှတ်ချက်များ ပါဝင်နိုင်သည်။ ဆက်တိုက် အနုတ်လက္ခဏာ အကြောင်းပြန်မှုများသည် Agent သည် မမျှော်လင့်ထားသည့်အတိုင်း မလုပ်ဆောင်နိုင်ကြောင်း သတိပေးချက်ဖြစ်သည်။

Implicit User Feedback: အသုံးပြုသူအပြုအမူများသည် တိုက်ရိုက်မဟုတ်သော အကြောင်းပြန်မှုများကို ပေးသည်။ ၎င်းတွင် မေးခွန်းကို ချက်ချင်း ပြန်လည်ဖော်ပြခြင်း၊ မေးခွန်းများကို ထပ်မံမေးခြင်း သို့မဟုတ် retry ခလုတ်ကို နှိပ်ခြင်းတို့ ပါဝင်နိုင်သည်။ ဥပမာအားဖြင့် အသုံးပြုသူများသည် တစ်ခုတည်းသော မေးခွန်းကို ဆက်တိုက်မေးလျှင်၊ ၎င်းသည် Agent သည် မမျှော်လင့်ထားသည့်အတိုင်း မလုပ်ဆောင်နိုင်ကြောင်း သတိပေးချက်ဖြစ်သည်။

Accuracy: Agent သည် မှန်ကန်သော သို့မဟုတ် လိုချင်သော ထွက်ရှိမှုများကို မည်မျှ မကြာခဏ ထုတ်လုပ်သနည်း။ Accuracy သည် အဓိပ္ပါယ်ကွဲပြားနိုင်သည် (ဥပမာ - ပြဿနာဖြေရှင်းမှုမှန်ကန်မှု၊ အချက်အလက်ရယူမှုမှန်ကန်မှု၊ အသုံးပြုသူကျေနပ်မှု)။ ပထမဆုံးအဆင့်မှာ သင့် Agent အတွက် အောင်မြင်မှုသည် မည်သို့ရှိသင့်ကြောင်း သတ်မှတ်ခြင်းဖြစ်သည်။ Accuracy ကို အလိုအလျောက် စစ်ဆေးမှုများ၊ အကဲဖြတ်ချက်အဆင့်များ သို့မဟုတ် တာဝန်ပြီးမြောက်မှုတံဆိပ်များဖြင့် စောင့်ကြည့်နိုင်သည်။ ဥပမာအားဖြင့် trace များကို “အောင်မြင်” သို့မဟုတ် “မအောင်မြင်” ဟု သတ်မှတ်ခြင်း။

Automated Evaluation Metrics: အလိုအလျောက် အကဲဖြတ်ချက်များကိုလည်း သတ်မှတ်နိုင်သည်။ ဥပမာအားဖြင့် Agent ၏ ထွက်ရှိမှုသည် အသုံးဝင်မှု၊ မှန်ကန်မှု သို့မဟုတ် မဟုတ်ကြောင်း LLM ကို အသုံးပြု၍ အဆင့်သတ်မှတ်နိုင်သည်။ Agent ၏ အမျိုးမျိုးသော အချက်အလက်များကို အဆင့်သတ်မှတ်ရန် ကူညီသော အခမဲ့ open source library များလည်း ရှိသည်။ ဥပမာ - RAG Agent များအတွက် RAGAS သို့မဟုတ် အန္တရာယ်ရှိသော ဘာသာစကား သို့မဟုတ် prompt injection ကို ရှာဖွေရန် LLM Guard။

လက်တွေ့တွင်၊ ဤ metrics များကို ပေါင်းစပ်အသုံးပြုခြင်းသည် AI Agent ၏ ကျန်းမာရေးကို အကောင်းဆုံးဖော်ပြနိုင်သည်။ ဤအခန်း၏ ဥပမာ notebook တွင် ဤ metrics များကို လက်တွေ့ဥပမာများတွင် မည်သို့ပုံပေါ်သည်ကို ပြသမည်ဖြစ်သော်လည်း၊ ပထမဦးစွာ အကဲဖြတ်မှု workflow များကို မည်သို့လုပ်ဆောင်ရမည်ကို သင်ယူပါမည်။

သင့် Agent ကို Instrument လုပ်ခြင်း

Tracing ဒေတာကို စုဆောင်းရန်၊ သင့် code ကို instrument လုပ်ရန် လိုအပ်ပါမည်။ ရည်ရွယ်ချက်မှာ Agent code ကို instrument လုပ်ပြီး trace နှင့် metrics များကို ထုတ်လွှင့်နိုင်စေကာ၊ ၎င်းတို့ကို ကြည့်ရှုနိုင်မှု platform မှ ဖမ်းယူ၊ အလုပ်လုပ်စေ၊ visualization ပြုလုပ်နိုင်စေရန်ဖြစ်သည်။

OpenTelemetry (OTel): OpenTelemetry သည် LLM ကြည့်ရှုနိုင်မှုအတွက် စက်မှုလုပ်ငန်းစံဖြစ်လာသည်။ ၎င်းသည် telemetry ဒေတာကို ထုတ်လုပ်ခြင်း၊ စုဆောင်းခြင်းနှင့် တင်ပို့ခြင်းအတွက် API များ၊ SDK များနှင့် ကိရိယာများကို ပေးသည်။

Agent framework များကို wrap

AI Agent များကို ထုတ်လုပ်မှုတွင် အသုံးပြုရာတွင် ကြုံတွေ့နိုင်သော ပြဿနာများ

AI Agent များကို ထုတ်လုပ်မှုတွင် အသုံးပြုရာတွင် အောက်ပါ ပြဿနာများနှင့် ရင်ဆိုင်နိုင်ပါသည်။

ပြဿနာ ဖြေရှင်းနည်းများ
Agent များ၏ အဖြေများ မမှန်ကန်ခြင်း - Prompt များကို ပြန်လည်စစ်ဆေးပြီး တိကျမှုရှိစေရန် ပြင်ဆင်ပါ။
- Agent များ၏ output ကို စစ်ဆေးရန် evaluation system တစ်ခု တည်ဆောက်ပါ။
အလွန်ရှုပ်ထွေးသော တာဝန်များအတွက် AI Agent များ မကောင်းမွန်ခြင်း - Reasoning အတွက် အထူးပြုထားသော ပိုမိုကြီးမားသော မော်ဒယ်များကို အသုံးပြုပါ။
AI Agent tool များ output မကောင်းမွန်ခြင်း - Agent system အပြင်တွင် tool output ကို စမ်းသပ်ပြီး အတည်ပြုပါ။
- Parameter, prompt, tool name များကို ပြန်လည်တိကျစွာ သတ်မှတ်ပါ။
Multi-Agent system များ မတည်ငြိမ်မှုရှိခြင်း - Agent တစ်ခုချင်းစီအတွက် prompt များကို တိကျပြီး သီးခြားစွာ ပြင်ဆင်ပါ။
- “Routing” သို့မဟုတ် controller agent တစ်ခုကို အသုံးပြု၍ အချင်းချင်း သင့်တော်သော agent ကို သတ်မှတ်ပါ။

ပြဿနာများကို ပိုမိုထိရောက်စွာ ရှာဖွေဖော်ထုတ်ရန် observability ရှိခြင်းက အရေးကြီးပါသည်။ ယခင်တွင် ပြောခဲ့သည့် trace များနှင့် metric များက Agent workflow ၏ ပြဿနာဖြစ်ပေါ်နေသည့်နေရာကို တိတိကျကျ ဖော်ထုတ်ပေးနိုင်ပြီး debugging နှင့် optimization ကို ပိုမိုထိရောက်စေပါသည်။

ကုန်ကျစရိတ်များကို စီမံခန့်ခွဲခြင်း

AI Agent များကို ထုတ်လုပ်မှုတွင် အသုံးပြုရာတွင် ကုန်ကျစရိတ်များကို စီမံခန့်ခွဲရန် အောက်ပါ များကို အသုံးပြုနိုင်ပါသည်-

မော်ဒယ်အသေးများကို အသုံးပြုခြင်း: Small Language Models (SLMs) သည် တချို့သော agentic use-case များတွင် ကောင်းစွာ လုပ်ဆောင်နိုင်ပြီး ကုန်ကျစရိတ်များကို အလွန်လျှော့ချနိုင်ပါသည်။ ယခင်တွင် ပြောခဲ့သည့်အတိုင်း SLM ၏ စွမ်းဆောင်ရည်ကို ကြီးမားသော မော်ဒယ်များနှင့် နှိုင်းယှဉ်၍ သင့် use-case အတွက် ဘယ်လောက်ထိရောက်မည်ကို သတ်မှတ်ရန် evaluation system တစ်ခု တည်ဆောက်ပါ။ SLM များကို intent classification သို့မဟုတ် parameter extraction ကဲ့သို့သော ရိုးရှင်းသော တာဝန်များအတွက် အသုံးပြုပြီး ရှုပ်ထွေးသော reasoning အတွက် ကြီးမားသော မော်ဒယ်များကို ထားပါ။

Router Model ကို အသုံးပြုခြင်း: မော်ဒယ်အမျိုးမျိုးနှင့် အရွယ်အစားအမျိုးမျိုးကို အသုံးပြုခြင်းသည် တူညီသော မဟာဗျူဟာတစ်ခုဖြစ်သည်။ LLM/SLM သို့မဟုတ် serverless function တစ်ခုကို အသုံးပြု၍ တောင်းဆိုမှုများကို ရှုပ်ထွေးမှုအလိုက် သင့်တော်သော မော်ဒယ်များသို့ လမ်းညွှန်ပါ။ ဤနည်းလမ်းသည် ကုန်ကျစရိတ်များကို လျှော့ချနိုင်သလို တာဝန်များအတွက် စွမ်းဆောင်ရည်ကိုလည်း သေချာစေပါသည်။ ဥပမာအားဖြင့် ရိုးရှင်းသော မေးခွန်းများကို သေးငယ်ပြီး မြန်ဆန်သော မော်ဒယ်များသို့ လမ်းညွှန်ပြီး ရှုပ်ထွေးသော reasoning အတွက်သာ ကြီးမားသော မော်ဒယ်များကို အသုံးပြုပါ။

Caching Responses: ရိုးရှင်းသော တောင်းဆိုမှုများနှင့် တာဝန်များကို သတ်မှတ်ပြီး Agentic system မှတဆင့် မဖြတ်ဘဲ အဖြေများကို ပေးခြင်းသည် တူညီသော တောင်းဆိုမှုများ၏ ပမာဏကို လျှော့ချရန် ကောင်းမွန်သော နည်းလမ်းတစ်ခုဖြစ်သည်။ AI မော်ဒယ်များကို အသုံးပြု၍ တောင်းဆိုမှုတစ်ခုသည် သင့် cache ထဲရှိသော တောင်းဆိုမှုများနှင့် ဘယ်လောက်တူညီသည်ကို သတ်မှတ်နိုင်သော flow တစ်ခုကိုတောင် တည်ဆောက်နိုင်ပါသည်။ ဤနည်းလမ်းသည် မကြာခဏ မေးလေ့ရှိသော မေးခွန်းများ သို့မဟုတ် ရိုးရှင်းသော workflow များအတွက် ကုန်ကျစရိတ်များကို အလွန်လျှော့ချနိုင်ပါသည်။

ဤနည်းလမ်းများကို လက်တွေ့အသုံးပြုကြည့်ရအောင်

ဤအပိုင်း၏ ဥပမာ notebook တွင် Agent များကို စောင့်ကြည့်ခြင်းနှင့် အကဲဖြတ်ခြင်းအတွက် observability tools များကို ဘယ်လို အသုံးပြုနိုင်သည်ကို ဥပမာများဖြင့် ကြည့်ရှုနိုင်ပါသည်။

AI Agent များနှင့် ပတ်သက်၍ မေးစရာများ ရှိပါသလား?

အခြားသော သင်ယူသူများနှင့် တွေ့ဆုံရန်၊ office hours များတက်ရောက်ရန်နှင့် AI Agent များနှင့် ပတ်သက်သော မေးခွန်းများကို ဖြေရှင်းရန် Azure AI Foundry Discord ကို ဝင်ရောက်ပါ။

ယခင် သင်ခန်းစာ

Metacognition Design Pattern

နောက်သင်ခန်းစာ

Agentic Protocols

အကြောင်းကြားချက်:
ဤစာရွက်စာတမ်းကို AI ဘာသာပြန်ဝန်ဆောင်မှု Co-op Translator ကို အသုံးပြု၍ ဘာသာပြန်ထားပါသည်။ ကျွန်ုပ်တို့သည် တိကျမှုအတွက် ကြိုးစားနေသော်လည်း၊ အလိုအလျောက် ဘာသာပြန်မှုများတွင် အမှားများ သို့မဟုတ် မတိကျမှုများ ပါဝင်နိုင်သည်ကို သတိပြုပါ။ မူရင်းဘာသာစကားဖြင့် ရေးသားထားသော စာရွက်စာတမ်းကို အာဏာတရ အရင်းအမြစ်အဖြစ် ရှုလေ့လာသင့်ပါသည်။ အရေးကြီးသော အချက်အလက်များအတွက် လူ့ဘာသာပြန်ပညာရှင်များမှ ပရော်ဖက်ရှင်နယ် ဘာသာပြန်မှုကို အကြံပြုပါသည်။ ဤဘာသာပြန်မှုကို အသုံးပြုခြင်းမှ ဖြစ်ပေါ်လာသော အလွဲအလွတ်များ သို့မဟုတ် အနားယူမှုများအတွက် ကျွန်ုပ်တို့သည် တာဝန်မယူပါ။

This site is open source. Improve this page.