App သို့ AI Features ထည့်နည်း

အက်ပ်သို့ AI features ထည့်ရန် large language model (LLM) API ကို server မှ ခေါ်ပါ- ရှင်းလင်းသော ညွှန်ကြားချက်များနှင့် သက်ဆိုင်သော ဒေတာကို ပို့ပြီး ပြန်လာသည့်အရာကို အသုံးပြုပါ။ အသုံးဝင်သော feature အများစုသည် လေးမျိုးထဲမှ တစ်မျိုး ဖြစ်သည်- အနှစ်ချုပ်ခြင်း၊ chat၊ ဖွဲ့စည်းပုံရှိသော ဒေတာ ထုတ်ယူခြင်းနှင့် အမျိုးအစားခွဲခြင်း- ၎င်းတို့တစ်ခုစီသည် AI builder က ရေးပေးနိုင်သော code စာကြောင်းဆယ်ဂဏန်းခန့် ဖြစ်သည်။ feature ကောင်းမကောင်း ဆုံးဖြတ်သည့်အလုပ်မှာ ခေါ်ဆိုမှု၏ ပတ်ဝန်းကျင်ဖြစ်သည်- API key ကို server တွင် ထားခြင်း၊ အသုံးပြုသူတစ်ယောက်စီ ကုန်ကျစရိတ်ကို ထိန်းခြင်းနှင့် ယုံကြည်မီ output ကို စစ်ဆေးခြင်း ဖြစ်သည်။

AI feature ၏ ပုံစံလေးမျိုး

Extraction နှင့် classification သည် အများအားဖြင့် အဖိုးတန်ဆုံးဖြစ်သော်လည်း အသိအမှတ်ပြုရခက်သည်။ ၎င်းတို့က မှတ်တမ်းတစ်ခုစီအတွက် မိနစ်အနည်းငယ် တိတ်တဆိတ် ချွေတာပေးသည်၊ output ပုံစံ ပုံသေဖြစ်သောကြောင့် အလိုအလျောက် စစ်ဆေးနိုင်သည်။ Chat သည် အမြင်ပိုရှင်းသော်လည်း မှန်ကန်စွာ လုပ်ရန် အခက်ဆုံးဖြစ်ပြီး သီးခြား လမ်းညွှန် ရှိသည်- AI chatbot app တည်ဆောက်ပုံ။

သင့် app ထဲတွင် ဘယ်လို ပေါင်းစပ်သလဲ

ပုံစံတိုင်းတွင် ဖွဲ့စည်းပုံတူတူ ရှိသည်-

1. အသုံးပြုသူက လုပ်ဆောင်သည်- "အနှစ်ချုပ်" ကို နှိပ်သည်၊ ဖိုင် တင်သည်၊ message ပို့သည်။
2. Front end က သင့်ကိုယ်ပိုင် server ကို ခေါ်သည်၊ AI provider ကို တိုက်ရိုက် မခေါ်ပါ။
3. Server က request ကို တည်ဆောက်သည်- system ညွှန်ကြားချက်များ၊ အသုံးပြုသူ၏ input နှင့် database မှ မော်ဒယ် လိုအပ်သော ဒေတာ- ထိုအသုံးပြုသူ မြင်ခွင့်ရှိသော ဒေတာသာ။
4. Server က LLM API ကို ခေါ်သည် environment variable တွင် သိမ်းထားသော key ဖြင့်။
5. Server က တုံ့ပြန်မှုကို စစ်ဆေးသည်- မှန်ကန်သော JSON၊ သိထားသော label၊ သင့်တော်သော အရှည်- ထို့နောက် သိမ်းသည် သို့မဟုတ် ပြန်ပေးသည်။
6. Front end က ပြသသည်၊ ရှည်သော အဖြေများအတွက် ရောက်လာသည်နှင့် စာသားကို တစ်စတစ်စ ပြသည်။

အဆင့် ၄ တွင် key သည် server ပေါ်တွင်သာ ရှိပြီး browser သို့ ဘယ်တော့မှ မရောက်ပါ။ API ဆိုတာ အသစ်ဖြစ်ပါက API ဆိုတာ ဘာလဲ သည် တိုတိုရှင်းရှင်း ရှင်းလင်းချက်ဖြစ်ပြီး LLM API များကို မည်သို့ သုံးမလဲ တွင် token၊ မော်ဒယ်နှင့် key များကို ပိုနက်နက်ရှိုင်းရှိုင်း ဖော်ပြထားသည်။

Provider နှင့် မော်ဒယ် ရွေးချယ်ခြင်း

ပင်မ provider များ- OpenAI၊ Anthropic၊ Google နှင့် အခြားသူများသည် ဆင်တူသော ပုံစံရှိသည့် text API များ ပေးသည်။ ရွေးချယ်ရာတွင် အသုံးဝင်သော မေးခွန်းများ-

• သင့်အလုပ်ပေါ်ရှိ အရည်အသွေး။ သင့် app မှ လက်တွေ့ ဥပမာ အချို့ကို မော်ဒယ် နှစ် သို့မဟုတ် သုံးခုတွင် စမ်းပါ။ ယေဘုယျ benchmark ထက် သင့်ဒေတာပေါ်တွင် ကွာခြားချက်များ ပိုရှင်းသည်။
• အရွယ်အစား နှင့် ကုန်ကျစရိတ်။ Provider များသည် ပိုကြီးပြီး စွမ်းဆောင်ရည်မြင့်သော မော်ဒယ်များနှင့် ပိုသေး၊ ပိုစျေးသက်သာ၊ ပိုမြန်သော မော်ဒယ်များ ပေးသည်။ အမျိုးအစားခွဲခြင်းနှင့် ရိုးရှင်းသော extraction သည် သေးငယ်သော မော်ဒယ်တွင် ကောင်းစွာ အလုပ်လုပ်မည်ဖြစ်ပြီး ရှည်လျားသော ဆင်ခြင်ချက် သို့မဟုတ် နူးညံ့သော စာရေးဖွဲ့ခြင်းသည် ပိုကြီးသော မော်ဒယ် လိုအပ်နိုင်သည်။
• ဖွဲ့စည်းပုံရှိသော output။ Extraction နှင့် classification အတွက် စာသား parse လုပ်မည့်အစား schema နှင့်ကိုက်ညီသော JSON ပြန်ပေးစေသည့် API feature ကို ဦးစားပေးပါ။
• ဒေတာ ကိုင်တွယ်ပုံ။ API input များ သိမ်းသလား၊ training အတွက် သုံးသလား ဆိုသည်ကို provider ၏ စည်းမျဉ်းတွင် ဖတ်ပါ၊ ၎င်းသည် အသုံးပြုသူများ ပေးသော ဒေတာနှင့် သင့်တော်ရမည်။
• ကန့်သတ်ချက်များ။ Account အသစ်များတွင် rate limit နိမ့်လေ့ရှိသည်၊ launch မတိုင်မီ စစ်ဆေးပါ။

မော်ဒယ်အမည်နှင့် စျေးနှုန်းများ မကြာခဏ ပြောင်းလဲသောကြောင့် code သည် မော်ဒယ်အမည်ကို နေရာများစွာတွင် hard-code မလုပ်ဘဲ configuration မှ ဖတ်သင့်သည်။

Feature တစ်ခုစီ အဆင့်လိုက် ထည့်ခြင်း

ဥပမာ တစ်ခု- ဆက်သွယ်သူတစ်ယောက်စီတွင် မှတ်စုရှည်ရှည် မှတ်တမ်းရှိသော CRM သေးငယ်တစ်ခု။

၁။ Key ကို သိမ်းပါ။ Provider ၏ dashboard တွင် key ဖန်တီးပြီး OPENAI_API_KEY သို့မဟုတ် ANTHROPIC_API_KEY ကဲ့သို့ server-side secret အဖြစ် သိမ်းပါ။

၂။ Feature ကျဉ်းကျဉ်းတစ်ခု တောင်းဆိုပါ-

ဆက်သွယ်သူ စာမျက်နှာသို့ "အနှစ်ချုပ်" ခလုတ် ထည့်ပါ။ server ပေါ်တွင် ဆက်သွယ်သူ၏ နောက်ဆုံး မှတ်စု ၂၀ ကို [PROVIDER] သို့ secret [ENV_NAME] ကို အသုံးပြု၍ ပို့ပါ၊ အချက်သုံးချက် bullet ရေးရန် ညွှန်ကြားပါ- လက်ရှိအခြေအနေ၊ ဖြေမရသေးသော မေးခွန်းများ၊ နောက်ထပ်အဆင့်။ လက်ရှိ logged-in အသုံးပြုသူ မြင်နိုင်သော မှတ်စုများကိုသာ ထည့်ပါ။ loading state ပြပါ၊ အနှစ်ချုပ်ကို အချိန်တံဆိပ်ဖြင့် သိမ်းပါ၊ ခေါ်ဆိုမှု မအောင်မြင်ပါက "အခု အနှစ်ချုပ်၍ မရပါ" ဟု ပြပါ။ key ကို browser သို့ ဘယ်တော့မှ မပို့ပါနှင့်။

၃။ အချိန်ကုန်သက်သာစေသည့်နေရာတွင် extraction ထည့်ပါ-

အသုံးပြုသူက "Quick add" အကွက်တွင် အီးမေးလ် signature ကို ကူးထည့်သောအခါ [PROVIDER] ကို server ပေါ်တွင် ခေါ်ပြီး provider ၏ structured output feature ဖြင့် name၊ company၊ job title၊ email နှင့် phone ပါသော JSON ပြန်ပေးပါ။ JSON ကို server ပေါ်တွင် အတည်ပြုပြီး ဆက်သွယ်သူ အသစ်ပုံစံကို ဖြည့်ပေးပါ၊ သိမ်းမီ အသုံးပြုသူ ပြင်ခွင့်ပေးပါ။ ခန့်မှန်းခြင်းအစား ကွက်လပ်ထားပါ။

"သိမ်းမီ အသုံးပြုသူ ပြင်ခွင့်ပေးပါ" သည် အရေးကြီးဆုံး အပိုင်းဖြစ်သည်- မော်ဒယ်က အဆိုပြုပြီး လူက ဆုံးဖြတ်သည်။

၄။ နောက်ကွယ်တွင် အမျိုးအစားခွဲပါ-

Support ticket အသစ် ရောက်လာသောအခါ ၎င်းကို အမျိုးအစား တစ်ခုတည်းသို့ ခွဲပါ- billing၊ bug၊ feature request၊ account access၊ other။ မော်ဒယ် ငယ်ပြီး ကုန်ကျစရိတ်နိမ့်သော မော်ဒယ်ကို သုံးပါ။ တုံ့ပြန်မှု ထို label များထဲမှ မဟုတ်ပါက "other" ဟု သိမ်းပါ။ label ကို ပြင်ဆင်နိုင်သော tag အဖြစ် ပြပါ။

၅။ ရှုပ်ထွေးသော အမှန်တကယ် ဒေတာဖြင့် စမ်းပါ- မှတ်စု ရှည်များ၊ အလွတ် မှတ်စုများ၊ အခြားဘာသာစကားများ၊ ဖုန်းနံပါတ် မပါသော signature- ပြီးမှ output ၂၀ ကို ဘေးချင်းကပ်၍ ကြည့်ပြီးမှ ထုတ်ပါ။

ညွှန်ကြားချက်များ အလုပ်ဖြစ်အောင် ရေးပုံ

တောင်းဆိုမှုတိုင်းနှင့် ပို့သော ညွှန်ကြားချက်များ (system prompt ဟု ခေါ်သည်) တွင် အရည်အသွေး ပေါ်ထွက်သည်-

• ဘယ်သူ့အတွက်လဲ၊ ကောင်းသော output ဘယ်လိုလဲ ပြောပါ။ "အနှစ်ချုပ်ကို ရောင်းချသူက ခေါ်ဆိုမှုမတိုင်မီ ၁၀ စက္ကန့်တွင် ဖတ်သည်" ဟု ပြောခြင်းက မော်ဒယ်ကို ပစ်မှတ်ပေးသည်။
• ပုံစံ သတ်မှတ်ပါ။ bullet အရေအတွက် တိကျစွာ၊ အရှည်ကန့်သတ်ချက်၊ field များ၊ label များ။
• မသေချာသောအခါ ဘာလုပ်ရမလဲ ပြောပါ။ "မှတ်စုတွင် နောက်ထပ်အဆင့် မဖော်ပြထားပါက 'နောက်ထပ်အဆင့် မှတ်တမ်းမတင်ရသေးပါ' ဟု ရေးပါ။" ၎င်းက စိတ်ကူးယဉ်ဖြေဆိုမှုကို လျှော့ချသည်။
• Extraction နှင့် classification အတွက် ဥပမာ နှစ်ခု သို့မဟုတ် သုံးခု ကောင်းသော input နှင့် output ပေးပါ။
• ညွှန်ကြားချက်များနှင့် အသုံးပြုသူ content ကို ခွဲထားပါ၊ အသုံးပြုသူ content ကို ရှင်းရှင်းလင်းလင်း အမှတ်အသားပြုပါ၊ မော်ဒယ်က ခွဲခြားနိုင်စေရန်။

Prompt များကို codebase ထဲ ဖိုင်များတွင် ထားပါ၊ ထိုသို့ဆိုလျှင် အခြား code နည်းတူ version ထိန်းနိုင်ပြီး ပြန်လည်သုံးသပ်နိုင်သည်။

ကုန်ကျစရိတ် ထိန်းခြင်း

LLM API များသည် ပို့သည့်အရာနှင့် ပြန်ရသည့်အရာနှစ်ခုလုံးအတွက် token ဖြင့် ကောက်ခံသည်- စာသား အစိတ်အပိုင်းငယ်လေးများ ဖြစ်သည်။ ကုန်ကျစရိတ်သည် request တစ်ခုစီရှိ context ပမာဏကို ခေါ်ဆိုမှု အကြိမ်အရေအတွက်ဖြင့် မြှောက်သည့်အတိုင်း တိုးလာသည်။ လက်တွေ့ ထိန်းချုပ်နည်းများ-

• လိုအပ်သည်များကိုသာ ပို့ပါ။ နောက်ဆုံး မှတ်စု ၂၀၊ သမိုင်းတစ်ခုလုံး မဟုတ်ပါ။ စာရွက်ရှည်များကို ဖြတ်ပါ သို့မဟုတ် ခွဲပါ။
• အလုပ်ပြီးနိုင်သော အသေးဆုံး မော်ဒယ်ကို သုံးပါ။ အကြီးဆုံးကို ပုံသေ မသုံးမီ စမ်းပါ။
• အများဆုံး output အရှည်ကို ကန့်သတ်ပါ API ၏ maximum-tokens setting ဖြင့်။
• Result များကို cache လုပ်ပါ။ အနှစ်ချုပ်ကို သိမ်းပြီး ရင်းမြစ် ပြောင်းသည့်အခါမှသာ ပြန်ထုတ်ပါ၊ စာမျက်နှာကြည့်တိုင်း မထုတ်ပါနှင့်။
• အသုံးပြုသူတစ်ယောက်စီအလိုက် ကန့်သတ်ပါ။ account သို့မဟုတ် plan အလိုက် တစ်ရက် ကန့်သတ်ချက် တစ်ခုသည် အသုံးများသူ တစ်ဦး သို့မဟုတ် script တစ်ခုက ငွေစာရင်းကို တက်စေခြင်းကို တားသည်။
• Endpoint ကို rate-limit လုပ်ပါ ကုန်ကျစရိတ်မြင့်သော route အခြားတစ်ခုကဲ့သို့ပင်။
• Provider ၏ dashboard တွင် budget သို့မဟုတ် alert သတ်မှတ်ပါ၊ launch ပြီးနောက် တစ်ပတ်တစ်ကြိမ် အသုံးပြုမှုကို စစ်ပါ။
• Feature တစ်ခုစီအလိုက် token အသုံးပြုမှု မှတ်ပါ ဘယ် feature က ဘယ်လောက် ကုန်သည်ကို သိရန်။

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

လုံခြုံရေးနှင့် ယုံကြည်မှု

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

• Output ကို ယုံကြည်မှုမရှိသော input အဖြစ် ဆက်ဆံပါ။ ဖွဲ့စည်းပုံကို အတည်ပြုပါ၊ HTML အဖြစ် မပြသမီ escape လုပ်ပါ၊ code သို့မဟုတ် database query အဖြစ် ဘယ်တော့မှ မ run ပါနှင့်။
• အကျိုးဆက်ရှိသော မည်သည့်အရာအတွက်မဆို လူကို ဝင်ပါစေပါ- အီးမေးလ် ပို့ခြင်း၊ record ပြင်ခြင်း၊ ငွေပြန်အမ်းခြင်း။ မော်ဒယ်က မူကြမ်းရေးသည်၊ လူက အတည်ပြုသည်။
• Prompt injection မှ ကာကွယ်ပါ။ စာရွက်စာတမ်း သို့မဟုတ် message တွင် "သင့်ညွှန်ကြားချက်များကို လျစ်လျူရှုပါ" ကဲ့သို့ စာသား ပါနိုင်သည်။ မော်ဒယ်မြင်နိုင်သည့်အရာကို လက်ရှိ အသုံးပြုသူ မြင်ခွင့်ရှိသည့်အရာသို့ ကန့်သတ်ပြီး၊ သင့် code က ခွင့်ပြုချက် အရင်စစ်ပြီးမှသာ ခွဲခြားမှု ရှိသော လုပ်ဆောင်ချက်များ လုပ်နိုင်သည့် tool များကိုသာ ပေးပါ။
• AI content ကို အမှတ်အသားပြုပါ အနှစ်ချုပ်သို့မဟုတ် အကြံပြုချက်သည် AI က ထုတ်ထားကြောင်း အသုံးပြုသူ သိပြီး စစ်ဆေးနိုင်စေရန်။
• ပျက်ကွက်မှုကို ကျေးဇူးရှိစွာ ကိုင်တွယ်ပါ။ Provider များတွင် outage နှင့် rate limit ရှိတတ်သည်။ timeout သတ်မှတ်၊ ရှင်းလင်းသော message ပြပြီး app ၏ အခြားအပိုင်းများ ဆက်လည်ပတ်စေပါ။
• အသုံးပြုသူများ ပို့သည့်အရာကို စောင့်ကြည့်ပါ။ ဖွင့်ထားသော စာသား input များအတွက် moderation အဆင့် ထည့်ရန် စဉ်းစားပြီး privacy policy တွင် content ကို တတိယပါတီ AI provider က လုပ်ဆောင်သည်ဟု ရှင်းရှင်းပြောပါ။

စစ်ဆေးမှုများ၏ ပိုကျယ်သော စာရင်းကို AI ဖြင့် တည်ဆောက်သော app များအတွက် လုံခြုံရေး checklist တွင် တွေ့နိုင်သည်။

အဖြစ်များသော အမှားများ

• ယေဘုယျ chatbot မှ စတင်ခြင်း တစ်ခုတည်းသော "အနှစ်ချုပ်" သို့မဟုတ် "အမျိုးအစားခွဲ" ခလုတ်က လူပိုများစွာကို ပိုကူညီနိုင်သည့်အခါ။
• Key ကို front-end code သို့မဟုတ် public repository တွင် ထည့်ခြင်း။
• Database တစ်ခုလုံးကို context အဖြစ် ပို့ခြင်း ဖြေးပြီး ကုန်ကျစရိတ်မြင့်ပြီး အခြား အသုံးပြုသူများ၏ ဒေတာ ယိုစိမ့်နိုင်သည်။
• ဖွဲ့စည်းပုံ သို့မဟုတ် label အစုသတ်မှတ်ချက် မရှိသော free-text output ကို ယုံခြင်း ၎င်းကို စစ်ဆေးနိုင်ရန်။
• အသုံးပြုသူ ကန့်သတ်ချက် မရှိခြင်း ပထမ ငွေတောင်းခံလွှာ ရောက်လာမှသာ သိရခြင်း။

Mythex ဖြင့် AI features ထည့်ခြင်း

Mythex တွင် သင့်ကိုယ်ပိုင် app ထဲ AI ကို chat တွင် တောင်းဆိုခြင်းဖြင့် ထည့်သည်၊ သင့်ကိုယ်ပိုင် provider key ကို အသုံးပြုသည်။ Key ကို project secret အဖြစ် သိမ်းပါ- agent ကို လိုအပ်သောအခါ Mythex က chat ထဲ secrets card ပြပေးသဖြင့် key ကို စကားဝိုင်းထဲ ကူးမထည့်ရပါ- agent က server route၊ prompt များနှင့် interface ကို ရေးပေးမည်။ သင့် app ၏ AI အသုံးပြုမှုကို သင့် provider က ကောက်ခံသည်၊ သင် တည်ဆောက်ရာတွင် သုံးသော Mythex credit နှင့် သီးခြားဖြစ်သည်။ Docs ၏ starter prompt ကို သင့်ကိုယ်ပိုင် API key များဖြင့် AI features ထည့်ခြင်း တွင် တွေ့နိုင်သည်။

မေးခွန်းများ