ရှည်လျားတဲ့ agent turn တွေကို context window အတွင်း ထိန်းထားခြင်း

model တစ်ခုက တစ်ကြိမ်တည်း ဖတ်နိုင်တဲ့ ပမာဏ ကန့်သတ်ထားပါတယ်– ၎င်းရဲ့ context window ပါ။ Mythex ရဲ့ agent က ရှည်ကြာတဲ့ အလုပ်တွေ လုပ်ပါတယ်၊ ဥပမာ ဖိုင်များစွာ ဖတ်ခြင်း၊ command run ခြင်း၊ ကန့်သတ်ထားတဲ့ အလုပ်တွေကို sub-agent တွေဆီ ပေးခြင်း။ ရှည်ကြာတဲ့ အလုပ်တွေ ပျက်စီးတတ်တဲ့ နည်းလမ်း သုံးမျိုး တွေ့ခဲ့ပါတယ်– sub-agent တွေ ကြီးလာလို့ model က request တိုင်းကို ငြင်းပယ်တာ၊ sub-agent တစ်ခုက နေရာကုန်ပြီလို့ ထင်ပြီး စောစော ရပ်သွားတာ၊ နဲ့ ရုရှား၊ တရုတ်၊ ဂျပန်စာသား အတွက် token ရေတွက်မှု မှန်ကန်မှု အလွန်နည်းတာ။ ပြောင်းလဲခဲ့တာတွေကို ဒီမှာ ရေးပါတယ်။

စကားလုံးအချို့ အရင်

• Token ဆိုတာ model ဖတ်တဲ့ အပိုင်းလေးတွေ ဖြစ်ပါတယ်။ ကန့်သတ်ချက်နဲ့ ကုန်ကျစရိတ်တွေကို စာလုံး သို့မဟုတ် စကားလုံးနဲ့ မဟုတ်ဘဲ token နဲ့ တွက်ပါတယ်။
• Context window ဆိုတာ request တစ်ခုတည်းမှာ model ဖတ်နိုင်တဲ့ အများဆုံးပမာဏ ဖြစ်ပါတယ်။ ကျွန်တော်တို့ကလည်း request တိုင်းအတွက် ကိုယ်ပိုင် ပိုနိမ့်တဲ့ budget သတ်မှတ်ထားလို့ ကုန်ကျစရိတ်နဲ့ မြန်နှုန်း သင့်တော်နေပါတယ်။
• Tool results ဆိုတာ agent ရဲ့ tool တွေက ပြန်ပေးတဲ့ အရာတွေ ဖြစ်ပါတယ်– ဖတ်ထားတဲ့ ဖိုင်အကြောင်းအရာ၊ run ထားတဲ့ command ရဲ့ output။ ရှည်ကြာတဲ့ အလုပ်မှာ ပို့နေရတဲ့ အများစုဟာ ဒါတွေပါ။
• sub-agent ဆိုတာ main agent က ကိုယ်ပိုင်အလုပ်တစ်ခုအတွက် စတင်ပေးတဲ့ အကူ ဖြစ်ပါတယ်၊ ဥပမာ "ဒီအခန်းတွေကို မှတ်စုနဲ့ စစ်ဆေးပါ"။ ညွှန်ကြားချက် တစ်ခုရပြီး tool ခေါ်ဆိုမှု အများကြီးကို ကိုယ်တိုင် လုပ်ပါတယ်။

ပြဿနာ ၁– sub-agent တွေ ကြီးလာပြီး model က ငြင်းပယ်တာ

အဆင့်တိုင်းမှာ agent က စကားဝိုင်းကို model ဆီ ပို့ပါတယ်။ အဲဒါ ကြီးလာတဲ့အခါ ကျွန်တော်တို့ code က ဖြတ်ပါတယ်၊ ဒါပေမယ့် user message အစမှာသာ ဖြတ်ပြီး၊ tool call နဲ့ ၎င်းရဲ့ ရလဒ်ကို ဘယ်တော့မှ မခွဲပါဘူး။ ပထမ message ကို ထားပြီး၊ အစောပိုင်း စကားဝိုင်း ဖြတ်ခံရကြောင်း မှတ်စု ထည့်ပြီး၊ အသစ်ဆုံး turn အပြည့်တွေကို ထည့်နိုင်သလောက် ထားပါတယ်။

sub-agent မှာ user message တစ်ခုသာ ရှိပါတယ်– ညွှန်ကြားချက်။ ဖြတ်စရာ နေရာ မရှိပါဘူး။ ဒါကြောင့် ခေါ်ဆိုတိုင်း သမိုင်းတစ်ခုလုံးကို ပို့ပြီး တိုးလာတာ၊ model လက်ခံတဲ့ အကြီးဆုံးထက် ကြီးသွားတဲ့အထိ– ~ တစ်သန်း token ခန့်။ sub-agent ၈ ခု စမ်းသပ်တဲ့အခါ ၈ ခုလုံး ငြင်းပယ်ခံခဲ့ရပါတယ်။

ပြင်ဆင်ချက်– အဟောင်း tool result တွေကို အရင် ရှင်းပါ

အခု request တွေက အဆင့်သုံးဆင့်နဲ့ budget အတွင်း ထိုက်အောင် လုပ်ပါတယ်။ ယခင်အဆင့် မလုံလောက်မှသာ နောက်တစ်ဆင့် ကြိုးစားပါတယ်–

1. အဟောင်းဆုံး tool result တွေကို ရှင်းပါ။ အကြောင်းအရာကို တိုတိုလေး မှတ်စုနဲ့ အစားထိုးပါတယ်– ရလဒ်ကို model ရဲ့ context အတွင်း ထိန်းဖို့ ရှင်းလင်းခဲ့ပြီး၊ လိုရင် agent က tool ကို ပြန် run နိုင်ပါတယ်။ တစ်နာရီအရင် ဖတ်ထားတဲ့ ဖိုင်က အများအားဖြင့် အကြီးဆုံးနဲ့ အသုံးဝင်ဆုံး မဟုတ်တဲ့ အရာ ဖြစ်ပြီး ဖိုင်ကတော့ ပြန်ဖတ်လို့ ရပါသေးတယ်။ အသစ်ဆုံး ရလဒ်တွေက အပြည့်ကျန်ပါတယ်။
2. user turn အပြည့်တွေ ထားပါ။ ယခင်အတိုင်း– ပထမ message၊ မှတ်စု၊ နဲ့ ထည့်နိုင်သော အသစ်ဆုံး turn အပြည့်တွေ။
3. tool round အပြည့်တွေ ထားပါ။ sub-agent မှာ ရှိတဲ့ ရှည်တဲ့ turn တစ်ခုအတွင်း– ပထမ message၊ မှတ်စု၊ နဲ့ "tool ခေါ်၊ ရလဒ်ယူ" ရဲ့ အသစ်ဆုံး round အပြည့်တွေ။

ဒါက ပို့ရမယ့် အရာကိုသာ ပုံသွင်းတာပါ။ agent ရဲ့ သိမ်းထားတဲ့ သမိုင်းက အားလုံး ဆက်ရှိပါတယ်။ တူညီတဲ့ စမ်းသပ်ချက်မှာ ငြင်းပယ်ခံရတာ ၈ ခုအနက် ၀ ခု၊ ၈ ခုလုံး ပြီးခဲ့ပါတယ်။

cache အလုပ်လုပ်အောင် အုပ်စုလိုက် ရှင်းခြင်း

model ပေးသူတွေက request ရဲ့ အစပိုင်းကို ထပ်သုံးနိုင်တဲ့ prefix cache ရှိပါတယ်၊ အကယ်၍ နောက်ဆုံး request နဲ့ အတူတူ ဖြစ်ရင်ပါ။ ခေါ်တိုင်း ရလဒ်တစ်ခုစီ ရှင်းရင် request ရဲ့ အစက ခေါ်တိုင်း ပြောင်းသွားပြီး cache က ဘယ်တော့မှ မကူညီပါဘူး။

ဒါကြောင့် အဟောင်းဆုံး ရလဒ်တွေကို တစ်ခုချင်းမဟုတ်ဘဲ လေးခုစီ ရှင်းပါတယ်။ ရှင်းထားတဲ့အပိုင်းက ခေါ်ဆိုမှုအများအပြားမှာ တည်ငြိမ်နေပါတယ်။ မှတ်စုထက် သိပ်မကြီးတဲ့ ရလဒ်ကို မထိပါဘူး– ရှင်းရင် အကျိုးနည်းပြီး request အစကို ပြောင်းစေမှာပါ။ ဘယ်နှစ်ခုကို အပြည့်ထားမလဲဆိုတာ အရေအတွက်မဟုတ်ဘဲ အရွယ်အစားနဲ့ ဆုံးဖြတ်ပါတယ်– budget ရဲ့ လေးပုံတစ်ပုံထဲ ထိုက်တဲ့ အသစ်ဆုံး ရလဒ်တွေ ကျန်ပြီး အနည်းဆုံး တစ်ခု အမြဲကျန်ပါတယ်။ ယခင် version က ပုံသေ ၆ ခု အပြည့်ထားခဲ့ပြီး၊ တိုတောင်းတဲ့ command output အတွက် မှန်ပေမယ့် ရှည်တဲ့ ဖိုင်ဖတ်မှုတွေမှာ budget အများစုကို အဟောင်းရလဒ်တွေက သုံးထားခဲ့ပါတယ်။

ငြင်းပယ်မှုတွေက ဒါကို ပြောပြပါတယ်

model က မမှန်ကန်ဟု ငြင်းပယ်တဲ့ request ကို ထပ်ပို့တာ မလုပ်တော့ပါဘူး၊ တူညီတဲ့ request ကို ပြန်ပို့ရင် အဖြေအတူတူ ရမှာပါ။ စကားဝိုင်းက model အတွက် ရှည်လွန်းရင် လူက ဒါကို မြင်ပါတယ်– "ဒီစကားဝိုင်းက model တစ်ကြိမ်တည်း ဖတ်ဖို့ ရှည်လွန်းသွားပါပြီ။ နောက်အဆင့်အတွက် စကားဝိုင်းအသစ် စတင်ပါ– ဒီအထိ တည်ဆောက်ထားတာအားလုံး ကျန်ပါမယ်။" ဒါက လူက လုပ်ရမယ့် အရာဖြစ်ပြီး မပျက်စီးမှုမဟုတ်ဘဲ၊ ကျွန်တော်တို့ကို စာမျက်နှာ alert ပေးစရာ မလိုပါဘူး။

ပြဿနာ ၂– agent က "နေရာ ချွေတာဖို့" ရပ်သွားတာ

အခန်း ၄၀ ရှည်ကို ဖတ်ဖို့ တောင်းတဲ့ sub-agent က ၂ ခုသာ ဖတ်ပြီး၊ နေရာ ချွေချင်တယ်လို့ ပြောပြီး ရပ်သွားပါတယ်။ budget ၄၀၀,၀၀၀ token ထဲက ~၁၀၀,၀၀၀ token သာ သုံးထားခဲ့ပါတယ်။

အဟောင်း ရလဒ်တွေ ယခု ရှင်းသွားမယ်ဆိုတာ သူ မသိခဲ့ပါဘူး။ ဒါကြောင့် ကျွန်တော်တို့ ပြောပြခဲ့ပါတယ်။ agent ရဲ့ ညွှန်ကြားချက်တွေမှာ အခု ဒီလို ပါပါတယ်– စကားဝိုင်းက model ယူနိုင်တာထက် ကြီးလာရင် အဟောင်းဆုံး tool result တွေ ရှင်းပြီး အသစ်ဆုံးတွေ အပြည့်ကျန်တယ်။ ဒါကြောင့် "နေရာချွေဖို့" ရှည်တဲ့ အလုပ်ကို မရပ်ပါနဲ့၊ ဆက်လုပ်ပါ၊ ရှင်းသွားတာ လိုရင် ဖိုင်ကို ပြန်ဖတ်ပါ။

model မမြင်နိုင်တဲ့ ပြင်ဆင်ချက်ဟာ model ရဲ့ အမြင်ကနေ ပြင်ဆင်ချက် မဟုတ်ပါဘူး။ ယန္တရားက agent က ယုံကြည်မှသာ အထောက်အကူ ဖြစ်ပါတယ်။

ပြဿနာ ၃– အင်္ဂလိပ်စာ တစ်မျိုးတည်းလို token ရေတွက်တာ

ကျွန်တော်တို့ token ကို tokenizer မသုံးဘဲ ခန့်မှန်းခဲ့ပါတယ်– စာလုံးအရေအတွက်ကို ၄ နဲ့ စားတာ။ အင်္ဂလိပ်အတွက် ဒါက ကောင်းတဲ့ ခန့်မှန်းနည်း ဖြစ်ပါတယ်။ အခြား script တွေအတွက် မဟုတ်ပါဘူး။ ရုရှားက စာလုံး ~၂.၂ လုံးကို token တစ်ခု၊ တရုတ်နဲ့ ဂျပန်က ~၁ ခုခန့် ဖြစ်ပါတယ်။

ဒါကြောင့် ရုရှားအခန်းတွေ ဖတ်တဲ့ sub-agent က token ~၆၄၀,၀၀၀ ခန့် request ပို့ခဲ့ပေမယ့် ကျွန်တော်တို့ ခန့်မှန်းချက်က budget ၄၀၀,၀၀၀ အောက်ဆိုပါတယ်။ ခန့်မှန်းချက်က model ရဲ့ hard limit ကိုလည်း ကျော်စေနိုင်ပါတယ်။

ခန့်မှန်းချက်က အခု script အလိုက် ရေတွက်ပါတယ်– ASCII ကို စာလုံး ၄ လုံး တစ်ခု၊ တရုတ်၊ ဂျပန်၊ ကိုရီးယား ကို ၁ လုံး တစ်ခု၊ အခြားအရာအားလုံး– Cyrillic၊ ဂရိ၊ အာရဗီ၊ အက်ဆင့်ပါသော အက္ခရာ၊ emoji– ကို ၂ လုံး တစ်ခု။ မြင့်ဘက်ကို အမှားလွဲဖို့ ရည်ရွယ်ပါတယ်။ ရုရှားအခန်းတစ်ခုမှာ ယခု ၄၃,၄၂၃ token ခန့်မှန်းပြီး တိုင်းတာတဲ့ ~၄၄,၆၀၀ နဲ့ နီးပါတယ်၊ အရင်က ၂၅,၀၂၃ လို့ ပြောခဲ့ပါတယ်။ message တစ်ခု ရေးပြီးရင် ပြောင်းမသွားတာမို့ ခန့်မှန်းချက်ကို တစ်ကြိမ်တည်း တွက်ပြီး မှတ်ထားပါတယ်၊ အဆင့်တိုင်း မတွက်ပါ။

ဒီကနေ ရလာတာတွေ

• အရွယ်အစား တကယ်ရှိတဲ့နေရာမှာ ဖြတ်ပါ။ agent အလုပ်မှာ အဲဒါက tool result တွေ ဖြစ်ပြီး user message မဟုတ်ပါ။
• agent ကို သူ့ရဲ့ safety net တွေအကြောင်း ပြောပြပါ။ မဟုတ်ရင် မရှိတော့တဲ့ ကန့်သတ်ချက်တွေအတွက် စီစဉ်နေမှာပါ။
• "စာလုံး ÷ ၄" ဆိုတာ အင်္ဂလိပ်အခြေခံ ယူဆချက် ဖြစ်ပါတယ်။ ဘာသာစုံ အသုံးပြုသူတွေအတွက် token ရေတွက်တဲ့ အရာက script အလိုက် ရေတွက်ရမယ်၊ သို့မဟုတ် တကယ့် tokenizer သုံးရမယ်။
• cache ကို ဂရုစိုက်ပါ။ ခေါ်တိုင်း အစပိုင်း ပြောင်းနေတဲ့ request က ပိုကုန်ကျပြီး ပိုနှေးပါတယ်။

AI feature တွေကို သင့်ကိုယ်ပိုင် အက်ပ်ထဲ ထည့်ချင်ရင် LLM ဆိုတာ ဘာလဲ နဲ့ LLM API တွေကို ဘယ်လို သုံးမလဲ က context window နဲ့ token တွေကို အစကတည်းက ရှင်းပြပါတယ်။ Mythex မှာ sub-agent တွေ ဘယ်လို အလုပ်လုပ်လဲဆိုတာ sub-agents docs မှာ ရှိပါတယ်။