AI Agent မတင်ခင်မှာ သင်မဖြစ်မနေလုပ်ရမယ့် စစ်ဆေးခြင်းနဲ့ လုံခြုံရေး အကာအကွယ်များ
Agent မှာ အအਭಯရဆုံးက စက်ရပ်သွားတာ မဟုတ်ဘဲ, မှားနေတာကို တိတ်တဆိတ်နဲ့ လုပ်နေတာပါပဲ—ကြည့်ကောင်းပြီး သဘာဝကျတဲ့ အဖြေတစ်ခုကို ပြန်ပေးလိုက်ပေမယ့် အကုန်မှားနေတာကို ဘယ်သူမှ မသိလိုက်ကြပါဘူး။ ဒီဆောင်းပါးမှာ Agent တွေ ဘာကြောင့် တိတ်တဆိတ် ပျက်ကွက်တတ်လဲ, Promptfoo ကိုသုံးပြီး ဘယ်လိုစစ်မလဲ, AgentOps နဲ့ အဆင့်များစွာကို ဘယ်လို debug လုပ်မလဲ, Langfuse ကိုသုံးပြီး အွန်လိုင်းမှာ ဘယ်လို စောင့်ကြည့်မလဲဆိုတာတွေကို ရှင်းပြထားပြီး, နောက်ဆုံးမှာ တင်ဆက်မှုမတိုင်ခင် လုပ်ဆောင်ရမယ့် စာရင်းကို ပူးတွဲဖော်ပြထားပါတယ်။
Customer service Agent တစ်ခုကို တည်ထောင်ထားတဲ့ startup ကုမ္ပဏီတစ်ခုဟာ အွန်လိုင်းစတင်လွှင့်တင်ပြီး တတိယပတ်မှာတော့ ဖောက်သည်တွေရဲ့ တိုင်ကြားချက်တွေက လျော့မသွားဘဲ ပိုတောင် တိုးလာခဲ့ပါတယ်။ သူတို့လည်း အံ့သြနေကြပါတယ် - စမ်းသပ်စစ်ဆေးတုန်းက အားလုံး မှန်ကန်နေခဲ့တာကိုး။ နောက်ပိုင်းမှာ မှတ်တမ်းတွေကို ပြန်ထုတ်ကြည့်မှ သတိထားမိလိုက်တာက: ပြဿနာ တစ်မျိုးမျိုးကြုံတိုင်း Agent က "ကုမ္ပဏီရဲ့ ငွေပြန်အမ်းပေးခြင်းဆိုင်ရာ မူဝါဒ အပိုဒ် (၇)" ဆိုတာကို ယုံကြည်ချက်အပြည့်နဲ့ အမြဲတမ်း ကိုးကားဖော်ပြနေခဲ့တာပါပဲ။ တကယ်တမ်းမှာတော့ အဲဒီမူဝါဒမှာ အပိုဒ် (၇) ဆိုတာ မရှိပါဘူး။ သူက မလုပ်တတ်တာ မဟုတ်ပါဘူး၊ မရှိတာကို တကယ့်အစစ်လိုဖြစ်အောင် ပြောတတ်နေတာပါပဲ။ ပြီးတော့ အွန်လိုင်းမတင်ခင်က စမ်းသပ်ခဲ့တဲ့ ဇာတ်လမ်းပုံစံတွေထဲမှာ ဒီလိုမျိုးကိစ္စမျိုး မပါသွားခဲ့တာ ဖြစ်ပါတယ်။
ဒါဟာ Agent တွေရဲ့ အအန္တရာယ်အရှိဆုံး ကျရှုံးပုံပါပဲ - သူက အနီရောင်စာသားနဲ့ ပြဿနာထုတ်မပြဘူး၊ exception လည်း မပစ်ဘူး။ သူက တိတ်ဆိတ်စွာ၊ ယဉ်ကျေးစွာ၊ ရှင်းလင်းပြတ်သားစွာနဲ့ အမှားလုပ်လိုက်တယ်၊ ပြီးတော့ သင်ရဲ့အသုံးပြုသူကလည်း ယုံသွားတယ်။
ဘာကြောင့် Agent တွေ "တိတ်တဆိတ် ကျရှုံး" ရတာလဲ
ရိုးရာဆော့ဖ်ဝဲလ်တွေ အမှားလုပ်တဲ့အခါ သင့်ကို သိသာစေလေ့ရှိပါတယ် - အမှားအယွင်းပြတာ၊ 500 ပြန်ပေးတာ၊ stack trace က ဘယ်လိုင်းမှာလဲ ဆိုတာကို ညွှန်ပြတာမျိုး လုပ်ပါတယ်။ Agent ကတော့ မတူပါဘူး။ သူ့ရဲ့ အخرထွက်လာတဲ့ အဖြေက "ထုတ်လုပ်ဖန်တီး" ထားတာဖြစ်ပြီး ဘာသာစကားကလည်း အမြဲတမ်း ရှင်းလင်းပြတ်သားနေတာကြောင့် အမှားကို မှန်ကန်တဲ့အဖြေနဲ့ လုံးဝတူနေအောင် ဖုံးကွယ်ထားနိုင်ပါတယ်။
ပိုပြီးခက်ခဲတာက အဆင့်ပေါင်းများစွာ လုပ်ဆောင်ရတဲ့အခါ ဖြစ်ပါတယ်။ Agent တစ်ခုက အလုပ်လုပ်တဲ့အခါ ကိရိယာတွေကို ငါးကြိမ်၊ ခြောက်ကြိမ်လောက် ခေါ်သုံးနိုင်ပြီး အလယ်မှာ ဘယ်အဆင့်က လွဲချော်သွားတာပဲဖြစ်ဖြစ် - မှားယွင်းတဲ့ အချက်အလက်ကို ရှာမိတာ၊ မှားယွင်းတဲ့ ပါရာမီတာ ပေးပို့မိတာ၊ အခြေအနေ တစ်ခုခုကို လွတ်သွားတာမျိုး - နောက်ပိုင်း အဆင့်တွေက ဒီအမှားပေါ်မှာ အခြေခံပြီး ဆက်လက်တွေးခေါ်သွားကာ နောက်ဆုံးမှာ "ကိုယ့်ကိုယ်ကိုယ် ကိုက်ညီမှုရှိပေမယ့် မှားယွင်းနေတဲ့" ရလဒ်ကို ပေးအပ်လာပါလိမ့်မယ်။ နောက်ဆုံးအဖြေကို ကြည့်လိုက်ရင် ဘယ်နေရာမှာ လွဲနေမှန်း လုံးဝ မသိနိုင်ပါဘူး။
ဒါကြောင့် Agent ရဲ့ အရည်အသွေး အာမခံချက်ဟာ လူကိုယ်တိုင် ကျပန်းစစ်ဆေးတာမျိုး ဒါမှမဟုတ် "ငါ အကြိမ်အနည်းငယ် စမ်းကြည့်တာ အတော်လေး အဆင်ပြေပါတယ်" ဆိုတဲ့ ပုံစံမျိုးနဲ့ လုပ်လို့မရပါဘူး။ သင့်အနေနဲ့ အရည်အသွေးကို တိုင်းတာနိုင်တဲ့၊ ပြန်လည်ဖွင့်ကြည့်နိုင်တဲ့ (re-play)၊ အွန်လိုင်းမှာ ဆက်လက်စောင့်ကြည့်နိုင်တဲ့ စနစ်တစ်ခု လိုအပ်ပါတယ်။ ဒါဟာ Slogan ဖြစ်တဲ့ 〈ကိုယ့်ဘာသာေကာင်း AI Agent တခုကို ဖန်တီးချင်ရင် ဘယ်လိုကိရိယာတွေကို ပြင်ဆင်သင့်လဲ〉 မှာ ဖော်ပြထားတဲ့ စစ်ဆေးအကဲဖြတ်ခြင်း၊ လုံခြုံရေးနဲ့ မြင်သာမြင်သာရှိမှု (observability) ဆိုတဲ့ အလွှာသုံးခုကို အွန်လိုင်းတင်တဲ့ အဆင့်မှာ တကယ်တမ်း အသုံးချရမယ့် နေရာပဲ ဖြစ်ပါတယ်။
အဓိကအချက်- အွန်လိုင်းမတင်ခင် သေချာစစ်ဆေးရမယ့် အရာ (၄) ခု
- အော့ဖ်လိုင်း စစ်ဆေးအကဲဖြတ်ခြင်း: ပုံသေမေးခွန်းဘဏ်တစ်ခုကို အသုံးပြုပြီး ပြောင်းလဲမှုတိုင်းပြီးနောက် အရည်အသွေး ကျဆင်းသွားခြင်း ရှိမရှိကို တိုင်းတာပါ။
- Red Team Testing (ရန်သူ့ဘက်မှနေ၍ စမ်းသပ်ခြင်း): သူ့ရဲ့ အားနည်းချက်တွေကို တက်ကြွစွာ ရှာဖွေပါ - ဘယ်လို အချက်အလက်မျိုးတွေ ထည့်သွင်းလိုက်ရင် သူက စည်းကျော်သွားမလဲ၊ ပေါက်ကရတွေ ပြောမလဲ၊ ပေါက်ကြားသွားမလဲ ဆိုတာကို စစ်ဆေးပါ။
- အဆင့်ပေါင်းများစွာ Debug လုပ်ခြင်း: အမှားဖြစ်တဲ့အခါ လုပ်ဆောင်ချက်လမ်းကြောင်း တစ်ခုလုံးကို ပြန်လည်ဖွင့်ကြည့်နိုင်ပြီး ဘယ်အဆင့်မှာ လွဲသွားလဲဆိုတာကို တိကျစွာ ရှာဖွေပါ။
- အွန်လိုင်း စောင့်ကြည့်ခြင်းနှင့် ကာကွယ်ရေး ကန့်သတ်ချက်များ (Guardrails): အွန်လိုင်းတင်ပြီးနောက် အရည်အသွေးနဲ့ ကုန်ကျစရိတ်ကို ဆက်လက်စောင့်ကြည့်ပြီး အန္တရာယ်ရှိတဲ့ လုပ်ဆောင်ချက်တွေ မလုပ်ခင်မှာ ကြားဖြတ် တားဆီးပေးပါ။
ဒီလေးခုထဲက တစ်ခုခု လျော့နည်းနေမယ်ဆိုရင် သင် အွန်လိုင်းတင်တာဟာ လောင်းကစားလုပ်နေတာနဲ့ အတူတူပါပဲ။
ဘယ်လိုစစ်ဆေးမလဲ: Promptfoo
အော့ဖ်လိုင်း စစ်ဆေးအကဲဖြတ်ခြင်းရဲ့ အဓိက သဘောတရားကတော့ "ငါထင်တယ် ပိုကောင်းလာပြီ" ဆိုတာကို "နံပါတ်တွေက ပိုကောင်းလာပြီလို့ ပြောနေတယ်" ဆိုတာနဲ့ အစားထိုးလိုက်တာပါပဲ။ Promptfoo က သင်တို့ကို စမ်းသပ်မှု ဖြစ်ရပ်အစုအဝေးတစ်ခု တည်ဆောက်နိုင်စေပါတယ် - ထည့်သွင်းမှု၊ မျှော်လင့်ထားတဲ့ အပြုအမူ၊ ဆုံးဖြတ်ချက် စံနှုန်းတွေ - ပြီးရင် prompt ပြောင်းတိုင်း၊ မော်ဒယ်လဲတိုင်း၊ parameter တွေ ချိန်ညှိတိုင်းမှာ တစ်ခုလုံးကို ပြန်လည်ပြေးဆွဲပြီး ရမှတ်တွေ ဘယ်လိုပြောင်းလဲသွားလဲဆိုတာကို ကြည့်ရှုနိုင်ပါတယ်။
ဆုံးဖြတ်ချက် စံနှုန်းတွေက စာသားကို နှိုင်းယှဉ်တာ၊ ပုံမှန် ဖော်ပြချက် (regular expression) တွေ ဖြစ်နိုင်သလို အခြား မော်ဒယ်တစ်ခုကို ዳိုင်လူကြီးအဖြစ် အသုံးပြုပြီး (LLM-as-judge) "ဒီအဖြေမှာ ကိုးကားချက်ကို မှန်ကန်စွာ ကိုးကားထားရဲ့လား" ဆိုတာကို အကဲဖြတ်ခိုင်းတာမျိုးလည်း ဖြစ်နိုင်ပါတယ်။ အစက ပြောခဲ့တဲ့ startup ကုမ္ပဏီမှာသာ "အဖြေထဲမှာ ဖော်ပြထားတဲ့ မူဝါဒ အပိုဒ်နံပါတ်ဟာ အစစ်အမှန် ရှိနေရမယ်" ဆိုတဲ့ အတည်ပြုချက် (assertion) တစ်ခု ရှိခဲ့မယ်ဆိုရင် အဲဒီအပိုဒ် (၇) ဆိုတာ အွန်လိုင်းပေါ် လုံးဝ တက်လာစရာ အကြောင်းမရှိပါဘူး။
Red Team Testing ကိုလည်း ဒီအလွှာမှာပဲ လုပ်ဆောင်ပါတယ်။ Promptfoo က တိုက်ခိုက်လိုတဲ့ ထည့်သွင်းချက် အစုအဝေးတွေကို လုပ်ဆောင်နိုင်ပြီး Agent က system prompt ပေါက်ကြားအောင်၊ ကန့်သတ်ချက်တွေကို ကျော်လွှားအောင်၊ မလုပ်သင့်တဲ့ လုပ်ဆောင်ချက်တွေကို လုပ်ဆောင်အောင် လုပ်ဖို့ ကြိုးစားပါတယ်။ သင်ကိုယ်တိုင် မတိုက်ခိုက်ဘူးဆိုရင် အသုံးပြုသူတွေ (သို့မဟုတ် မသမာသူတွေ) က သင့်အတွက် တိုက်ခိုက်ပေးပါလိမ့်မယ်။ ကိုယ်တိုင် အရင်ဆုံး တစ်ကြိမ် တိုက်ခိုက်ကြည့်တာက ပိုကောင်းပါတယ်။
ဘယ်လို Debug လုပ်မလဲ: AgentOps
စစ်ဆေးအကဲဖြတ်မှုက "အဖြေမှားနေတယ်" လို့ ပြောပြပေးပေမယ့် "ဘယ်အဆင့်မှာ မှားနေလဲ" ဆိုတာကိုတော့ မပြောပြပါဘူး။ အဆင့်ပေါင်းများစွာ Debug လုပ်ဖို့အတွက် AgentOps ကို အသုံးပြုရပါမယ်။
သူက Agent ရဲ့ လုပ်ဆောင်ချက် တစ်ပတ်လည်ကို ပြန်လည်ဖွင့်ကြည့်လို့ရတဲ့ အချိန်မျဉ်း (timeline) တစ်ခုအဖြစ် ချိတ်ဆက်ပေးပါတယ်: ပထမအဆင့်မှာ ဘယ်ကိရိယာကို ခေါ်သုံးခဲ့လဲ၊ ဘယ်လို parameter တွေ ပို့ခဲ့လဲ၊ ဘာတွေ ပြန်ရခဲ့လဲ၊ token ဘလောက် ဘလောက် သုံးခဲ့လဲ၊ ဒုတိယအဆင့်မှာ ဘာကို အခြေခံပြီး နောက်တစ်ဆင့်ကို ဆုံးဖြတ်ခဲ့လဲ…… အားလုံးကို ဖြန့်ခင်းပြီး ပြသပေးပါတယ်။ ငွေပြန်အမ်းပေးခြင်း မူဝါဒ ဥပမာမှာဆိုရင် AgentOps ထဲမှာ ရှင်းရှင်းလင်းလင်း မြင်ရမှာပါ - တစ်ဆင့်ချင်း ပြန်ရှာယူလာတဲ့ စာရွက်စာတမ်း အပိုင်းအစကတည်းက မှားယွင်းနေပြီးသား ဖြစ်နေပြီး နောက်ပိုင်းတွေက အားလုံးဟာ မှားယွင်းတဲ့ အချက်အလက်အပေါ် အခြေခံထားတဲ့ ကျိုးကြောင်းဆီလျော်မှုတွေ ဖြစ်နေပါပြီ။ ဒီလိုလမ်းကြောင်းမျိုး မရှိဘူးဆိုရင် နောက်ဆုံးအဖြေကိုပဲ ကြည့်ပြီး မျက်စိစုံမှိတ် ငေးနေရုံပဲ ရှိပါလိမ့်မယ်။
ဘယ်လို စောင့်ကြည့်မလဲ: Langfuse
အွန်လိုင်းတင်တာဟာ အဆုံးသတ်မဟုတ်ပါဘူး၊ နောက်ထပ် စတင်ခြင်းတစ်ခုသာ ဖြစ်ပါတယ်။ ထုတ်လုပ်မှု ပတ်ဝန်းကျင် (production environment) ထဲက ထည့်သွင်းချက်တွေဟာ ထူးဆန်းပြီး အမျိုးစုံနေတတ်ပြီး အသုံးပြုသူတွေဟာ သင် စမ်းသပ်တုန်းက လုံးဝ မတွေးမိခဲ့တဲ့ မေးခွန်းမျိုးတွေကို မေးမြန်းလာကြပါလိမ့်မယ်။ Langfuse ကတော့ အွန်လိုင်းပေါ်က ဆွေးနွေးမှုတိုင်း၊ token ကုန်ကျစရိတ်တိုင်းနဲ့ နှောင့်နှေးကြန့်ကြာမှု (latency) တိုင်းကို ရေရှည်မှတ်တမ်းတင်ပေးဖို့ တာဝန်ယူထားပြီး အချိန်ကြာလာတာနဲ့အမျှ အရည်အသွေးတွေ ပြောင်းလဲသွားခြင်း (drift) ရှိမလား၊ ဘယ်လိုပြဿနာမျိုးတွေက အဆိုးဆုံး ဖြေဆိုခဲ့ရလဲ၊ ကုန်ကျစရိတ်တွေ ထိန်းမနိုင်သိမ်းမရ ဖြစ်သွားလားဆိုတာတွေကို ခြေရာခံနိုင်အောင် ကူညီပေးပါတယ်။
သူနဲ့ AgentOps ရဲ့ အလုပ်ခွဲဝေမှုကတော့: AgentOps က ထုတ်လုပ်ရေးကာလအတွင်း တစ်ကြိမ်ချင်း နက်နက်ရှိုင်းရှိုင်း Debug လုပ်ဖို့အတွက် ဖြစ်ပြီး Langfuse ကတော့ အွန်လိုင်းမှာ ရေရှည် လူအများရဲ့ အခြေအနေကို စောင့်ကြည့်ဖို့အတွက် ဖြစ်ပါတယ်။ လက်တွေ့မှာတော့ အဖွဲ့အစည်း အများစုဟာ ဒီနှစ်ခုစလုံးကို အသုံးပြုကြပါတယ်။ အဓိကအချက်ကတော့ - သင့်မှာ အချိန်မရွေး "ကျွန်တော့်ရဲ့ Agent က ဒီတစ်ပတ်မှာ ဘယ်လို စွမ်းဆောင်ရည်ပြခဲ့လဲ" ဆိုတဲ့ မေးခွန်းကို ဖြေဆိုနိုင်မယ့် နေရာတစ်ခု ရှိရပါမယ်။ မဖြေနိုင်ဘူးဆိုရင်တော့ အကာအကွယ်မပါဘဲ ဗလာကျင်း ပြေးလွှားနေတာပါပဲ။
ကာကွယ်ရေး ကန့်သတ်ချက်များ (Guardrails): နောက်ဆုံး ကာကွယ်တားဆီးချက်
စစ်ဆေးအကဲဖြတ်ခြင်း၊ debug လုပ်ခြင်း၊ စောင့်ကြည့်ခြင်းတွေဟာ "ဖြစ်ပျက်ပြီးမှ သို့မဟုတ် ဖြစ်ပျက်ခါနီးမှ သိရှိခြင်း" ဖြစ်ပြီး ကာကွယ်ရေး ကန့်သတ်ချက်တွေကတော့ "လက်ရှိအချိန်မှာ တားဆီးပေးခြင်း" ဖြစ်ပါတယ်။ Agent က အန္တရာယ်ရှိတဲ့ လုပ်ဆောင်ချက်တွေကို မလုပ်ဆောင်ခင်မှာ - ငွေပေးချေခြင်း၊ အချက်အလက်ဖျက်ဆီးခြင်း၊ အပြင်ဘက်ကို ပို့ဆောင်ခြင်း၊ စနစ် အမိန့်ပေးချက်များ လုပ်ဆောင်ခြင်း - စည်းကမ်းချက် စစ်ဆေးမှု ဒါမှမဟုတ် လူကိုယ်တိုင် အတည်ပြုချက် အလွှာတစ်ခုကို ထည့်သွင်းပေးရပါမယ်။
ကာကွယ်ရေး ကန့်သတ်ချက်တွေက ဘာတွေကို တားဆီးသင့်လဲ: အထွက်ရလဒ်မှာ ကိုယ်ရေးကိုယ်တာ အချက်အလက် သို့မဟုတ် လျို့ဝှက်ချက်တွေ ပါဝင်နေရင် ဖုံးကွယ်ပေးတာ၊ ငွေပမာဏက သတ်မှတ်ချက်ထက် ကျော်လွန်နေရင် လူကိုယ်တိုင်ဆီ လွှဲပြောင်းပေးတာ၊ prompt injection ကို တွေ့ရှိရရင် ရပ်တန့်ပစ်တာမျိုး ဖြစ်ပါတယ်။ ဒီအလွှာက ကိရိယာ ကွင်းဆက်ထဲက လုပ်ဆောင်ချက် sandbox (ဥပမာ Blaxel) နဲ့ တွဲဖက်အသုံးပြုရတာ ဖြစ်ပါတယ် - sandbox က သူ "ဘာတွေ လုပ်ဆောင်နိုင်လဲ" ဆိုတာကို ကန့်သတ်ပေးပြီး ကာကွယ်ရေး ကန့်သတ်ချက်ကတော့ သူ "ဘာတွေ လုပ်ခွင့်ရှိလဲ" ဆိုတာကို ကန့်သတ်ပေးပါတယ်။
အဖွဲ့အစည်း (၃) မျိုးအတွက် အဓိက စစ်ဆေးရမည့် အချက်များ
ထိုင်ဝန်မှ တစ်ဦးချင်း ဆော့ဖ်ဝဲရေးသားသူများ (Individual Developers): Promptfoo ကို အနည်းဆုံးတော့ ချိတ်ဆက်ပါ။ စမ်းသပ်မှု ဖြစ်ရပ်အစုအဝေး အခု နှစ်ဆယ်လောက်ပဲ ရှိရင်တောင်မှ ပြောင်းလဲမှုတိုင်းပြီးတိုင်း ခံစားချက်နဲ့ တိုင်းတာတာထက် ပိုကောင်းပါတယ်။ Red Team Testing ကို အန္တရာယ်အရှိဆုံး တိုက်ခိုက်မှု မျက်နှာပြင် အချို့ကို ရွေးချယ်ပြီး လုပ်ဆောင်ပါ၊ အပြည့်အစုံ ဖြစ်ဖို့တော့ မလိုပါဘူး။
Startup အဖွဲ့များ: AgentOps နဲ့ Langfuse ကို စောစောစီးစီး အသုံးပြုပါ။ သင့်ရဲ့ ထုတ်ကုန်က လျင်မြန်စွာ တိုးတက်ပြောင်းလဲနေဆဲ ဖြစ်ပြီး မြင်သာမြင်သာရှိမှု မရှိဘူးဆိုရင် ပြဿနာဖြစ်တိုင်း အဖွဲ့လိုက် log ပင်လယ်ထဲမှာ လိုက်ရှာနေရပါလိမ့်မယ်။ ရှာရတဲ့ အချိန်နဲ့တင် လုပ်ဆောင်ချက် အသစ်နှစ်ခုလောက် ပိုလုပ်နိုင်ပါလိမ့်မယ်။ ကာကွယ်ရေး ကန့်သတ်ချက်တွေအနေနဲ့ "ငွေကုန်ကြေးကျများမယ့်" နဲ့ "နောက်ပြန်လှည့်လို့မရမယ့်" လုပ်ဆောင်ချက်တွေကို ဦးစားပေး ကာကွယ်ပါ။
လုပ်ငန်းကြီးများ (Enterprise): Red Team Testing နဲ့ ကာကွယ်ရေး ကန့်သတ်ချက်တွေဟာ စည်းကမ်းလိုက်နာမှု (compliance) ရဲ့ အခြေခံစည်း ဖြစ်ပါတယ်။ သတင်းအချက်အလက် လုံခြုံရေးနဲ့ ဥပဒေရေးရာဌာနက မေးမြန်းမယ့် "အချက်အလက်တွေ ပေါက်ကြားသွားမှာလား"၊ "ဆုံးဖြတ်ချက် တစ်ခုချင်းစီကို စစ်ဆေးနိုင်သလား (audit)" ဆိုတဲ့ မေးခွန်းတွေအတွက် အဖြေဟာ Promptfoo ရဲ့ ဆန့်ကျင်ဘက် စမ်းသပ်မှု မှတ်တမ်းနဲ့ AgentOps ရဲ့ လုပ်ဆောင်ချက် လမ်းကြောင်းတွေထဲမှာ ပုန်းအောင်းနေပါတယ်။ ဒီမှတ်တမ်းတွေကို သိမ်းဆည်းထားခြင်းဟာ စစ်ဆေးမည့် အထောက်အထားတွေကို ကြိုတင် ပြင်ဆင်ထားတာနဲ့ အတူတူပါပဲ။
အွန်လိုင်းမတင်မီ စစ်ဆေးရမည့် စာရင်း (Checklist)
ဒီအတိုင်း တိုက်ရိုက် လိုက်လုပ်ပါ:
- အဖြစ်များတဲ့ အခြေအနေနဲ့ အစွန်းရောက် အခြေအနေတွေကို အနည်းဆုံး ဖုံးလွှမ်းနိုင်တဲ့ စမ်းသပ်မေးခွန်းဘဏ်တစ်ခု ရှိပြီး Promptfoo ပေါ်မှာ အလုပ်လုပ်နေပါပြီ။
- prompt ပြောင်းတိုင်း သို့မဟုတ် မော်ဒယ်လဲတိုင်း ပြည့်စုံတဲ့ စစ်ဆေးအကဲဖြတ်မှုကို ဖြတ်သန်းပြီး ရမှတ်မကျဆင်းမှသာ အွန်လိုင်းတင်ပါတယ်။
- prompt injection၊ စည်းကျော်ခြင်းနဲ့ ပေါက်ကရပြောခြင်းတွေကို အနည်းဆုံး တစ်ကြိမ် Red Team Testing လုပ်ထားပါတယ်။
- "အချက်အလက် ကိုးကားဖော်ပြခြင်း" အမျိုးအစား အဖြေတွေအတွက် ကိုးကားချက် အစစ်အမှန် ရှိနေကြောင်း စစ်ဆေးပေးမယ့် assertion တွေ ထည့်သွင်းထားပါတယ်။
- အဆင့်ပေါင်းများစွာ လုပ်ဆောင်တဲ့ လုပ်ငန်းစဉ်မှာ AgentOps ကို ချိတ်ဆက်ထားပြီး အမှားဖြစ်တဲ့အခါ ဘယ်အဆင့်မှာ မှားနေလဲဆိုတာကို ပြန်လည်ဖွင့်ကြည့် (re-play) နိုင်ပါတယ်။
- အွန်လိုင်းမှာ Langfuse ကို ချိတ်ဆက်ထားပြီး အရည်အသွေး ပြောင်းလဲမှုနဲ့ ကုန်ကျစရိတ်တွေကို ကြည့်ရှုနိုင်ပါတယ်။
- အန္တရာယ်ရှိတဲ့ လုပ်ဆောင်ချက်တွေ (ငွေပေးချေခြင်း၊ ဖျက်ဆီးခြင်း၊ အပြင်ဘက် ပို့ဆောင်ခြင်း) မလုပ်ခင်မှာ ကာကွယ်ရေး ကန့်သတ်ချက် ဒါမှမဟုတ် လူကိုယ်တိုင် အတည်ပြုချက် ရှိပါတယ်။
- နောက်ခံ Agent တွေ ငွေကုန်ကြေးကျ မများစေရန် token နဲ့ ကုန်ကျစရိတ် အများဆုံး ပမာဏကို သတ်မှတ်ထားပါတယ်။
- အန္တရာယ်ရှိတဲ့ ကုဒ် လုပ်ဆောင်ချက်တွေကို sandbox ထဲမှာ run ပါတယ်။
- ပြဿနာဖြစ်တဲ့အခါ ပထမဦးဆုံး ဘယ်နေရာကို
မေးလေ့ရှိသောမေးခွန်းများ
ဘာကြောင့် AI Agent ရဲ့ အမှားတွေက သမားရိုးကျ ဆော့ဖ်ဝဲလ်တွေထက် ရှာရ ပိုခက်တာလဲ?
ဘာလို့လဲဆိုတော့ Agent ရဲ့ ထွက်လာတဲ့ အချက်အလက်တွေက ဖန်တီးထားတာဖြစ်ပြီး ဘာသာစကားက ဘယ်တော့မဆို ချောမွေ့နေတာကြောင့် မှားယွင်းတဲ့ အဖြေဟာ မှန်ကန်တဲ့အဖြေလိုပဲ စနစ်တကျ ရှိနေပါတယ်။ သမားရိုးကျ ဆော့ဖ်ဝဲလ်တွေလို error ဒါမှမဟုတ် stack trace ထွက်လာတာမျိုး မရှိပါဘူး။ အဆင့်များစွာပါတဲ့ လုပ်ငန်းစဉ်မှာ တစ်ခုခုလွဲသွားရင် နောက်ပိုင်းမှာ အမှားပေါ်အခြေခံပြီး ဆက်လက် ကောက်ချက်ချသွားတဲ့အတွက် နောက်ဆုံးမှာ 'ကိုက်ညီမှုရှိပေမယ့် မှားယွင်းနေတဲ့' ရလဒ်ကို ပေးစွမ်းပြီး အဖြေကို သက်သက်ကြည့်ရုံနဲ့ ပြဿနာကို မတွေ့နိုင်ပါဘူး။
Promptfoo က ဘယ်လိုပြဿနာတွေကို အဓိက ဖြေရှင်းပေးလဲ?
သူက Agent ရဲ့ အရည်အသွေးကို 'ငါထင်တယ် ပိုကောင်းလာပြီ' ဆိုတာကနေ အရေအတွက်နဲ့ တိုင်းတာလို့ရတဲ့ ကိန်းဂဏန်းတွေအဖြစ် ပြောင်းလဲပေးပါတယ်။ သင်ဟာ စမ်းသပ်မှု ဖြစ်ရပ်မှန်တွေနဲ့ ဆုံးဖြတ်ချက် စံနှုန်းတွေကို သတ်မှတ်ထားပြီး prompt ပြောင်းတိုင်း, မော်ဒယ်လဲတိုင်း တစ်ခေါက်စီ Run ကြည့်ပြီး ရမှတ်တွေ ကျဆင်းသွားလားဆိုတာကို ကြည့်ရှုနိုင်ပါတယ်။ တစ်ပြိုင်နက်တည်းမှာပဲ Red Teaming ကို လုပ်ဆောင်နိုင်ပြီး ရှောင်ကွင်းခံရမယ့် ဒါမှမဟုတ် Agent ကို လိမ်လည်ပြောဆိုစေမယ့် အားနည်းချက်တွေကို အဓိက ရှာဖွေပေးပါတယ်။
AgentOps နဲ့ Langfuse က ဘာတွေ ကွာခြားလဲ, နှစ်ခုစလုံး သုံးဖို့ လိုအပ်လား?
AgentOps က ဖွံ့ဖြိုးတိုးတက်ရေးကာလမှာ တစ်ကြိမ်ချင်း နက်နက်ရှိုင်းရှိုင်း debug လုပ်ဖို့အတွက် ဖြစ်ပြီး တစ်ကြိမ် Run မှုကို ပြန်ကြည့်လို့ရတဲ့ ခြေရာခံလမ်းကြောင်းအဖြစ် ပြောင်းလဲပေးကာ ဘယ်အဆင့်မှာ အမှားရှိလဲဆိုတာကို ရှာဖွေဖို့ လွယ်ကူစေပါတယ်။ Langfuse ကတော့ အွန်လိုင်းမှာ ရေရှည် စုပေါင်းစောင့်ကြည့်ဖို့ဖြစ်ပြီး စကားပြောဆိုမှုတိုင်း, ကုန်ကျစရိတ်, နှောင့်နှေးမှုတွေကို မှတ်တမ်းတင်ပေးကာ အရည်အသွေး ယိုယွင်းလာမှုကို ခြေရာခံပေးပါတယ်။ နှစ်ခုစလုံးရဲ့ အဓိကထားချက်တွေ မတူညီကြပါဘူး။ လက်တွေ့မှာ အသင်းအများစုက တွဲဖက်ပြီး အသုံးပြုကြပါတယ်။
Guardrails (ကာရံများ) နဲ့ စစ်ဆေးခြင်း (Evaluation) က ဘာတွေ ကွာခြားလဲ?
စစ်ဆေးခြင်းဆိုတာက အရည်အသွေး ဘယ်လိုရှိတယ်ဆိုတာကို ကြိုတင်သိရှိတာဖြစ်ပြီး, စောင့်ကြည့်ခြင်းဆိုတာက ဖြစ်ပွားပြီးမှ ပြဿနာကို ရှာဖွေနိုင်တာဖြစ်ကာ, Guardrails ဆိုတာကတော့ 'လက်ငင်း တားဆီးခြင်း' ဖြစ်ပါတယ်—Agent က ငွေပေးချေခြင်း, ဖျက်ဆီးခြင်း, အပြင်ဘက်ကို ပို့ဆောင်ခြင်း စတဲ့ အန္တရာယ်ရှိတဲ့ လုပ်ရပ်တွေကို မလုပ်ခင်မှာ စည်းမျဉ်း စစ်ဆေးမှု ဒါမှမဟုတ် လူကိုယ်တိုင် အတည်ပြုမှုကို ထည့်သွင်းပေးပါတယ်။ ဥပမာ- ပမာဏက သတ်မှတ်ချက်ထက် ကျော်လွန်ရင် လူကိုယ်တိုင် ဖြေရှင်းဖို့ လွှဲပြောင်းပေးတာ, prompt injection ကို တွေ့ရှိရင် ရပ်တန့်လိုက်တာမျိုး ဖြစ်ပါတယ်။