AI Chatbot App တစ်ခု တည်ဆောက်နည်း- Key များ၊ Prompt များ၊ ကုန်ကျစရိတ်နှင့် လုံခြုံရေး

AI chatbot app တစ်ခု တည်ဆောက်ရန် အရာလေးခု လိုအပ်ပါတယ်- chat interface၊ provider ၏ API key ကို ကိုင်ထားပြီး message များကို ထိုဆီသို့ ပို့ပေးသော အသေးစား server၊ model ကို ဘယ်သူလဲ၊ ဘာလုပ်ခွင့်ရှိသလဲ ပြောပြသော system prompt၊ နှင့် ကုန်ကျစရိတ်နှင့် အလွဲသုံးစားမှုကို ထိန်းသိမ်းသော ကန့်သတ်ချက်များ။ AI app builder တစ်ခုက ဤအရာအားလုံးကို ဖော်ပြချက်ဖြင့် ရေးပေးနိုင်ပါတယ်။ သင်ကိုယ်တိုင် ဆုံးဖြတ်ရမှာကတော့ provider ရွေးချယ်ခြင်း၊ ညွှန်ကြားချက်များ ရေးခြင်းနှင့် bot က ဘာကို လုံးဝမလုပ်ရကြောင်း ဆုံးဖြတ်ခြင်းတို့ ဖြစ်ပါတယ်။

AI chatbot app ၏ အစိတ်အပိုင်းများ

AI chatbot app အများစု- customer support assistant၊ tutor သို့မဟုတ် "ကျွန်ုပ်တို့ docs ကို မေးပါ" ကိရိယာ ဖြစ်စေ- အစိတ်အပိုင်းတူညီကြပါတယ်-

Server route သည် လူအများစု မှားတတ်သော အပိုင်းဖြစ်ပါတယ်။ Chat page က provider ကို browser မှတိုက်ရိုက်ခေါ်လျှင် မည်သူမဆို developer tools ဖွင့်ပြီး သင့် key ကို ကူးယူကာ ငွေကုန်အောင် သုံးနိုင်ပါတယ်။

မတည်ဆောက်မီ ဆုံးဖြတ်ရမည့်အရာများ

Provider နှင့် model

Main provider များ (OpenAI၊ Anthropic၊ Google နှင့် အခြားသူများ) အားလုံးက အလုပ်လုပ်ပုံတူသော chat-style API ကို ပေးထားပါတယ်- message စာရင်းပို့၍ ပြန်ဖြေချက်ရယူရခြင်း။ လက်တွေ့ရွေးချယ်ရာတွင် brand ထက် model အရွယ်အစားက ပိုအရေးကြီးပါတယ်-

• ငယ်သော၊ မြန်သော model များ က ပိုသက်သာပြီး အမြန်ဖြေပါတယ်။ တိုတောင်းသော အဖြေများ၊ အမျိုးအစားခွဲခြင်းနှင့် ရိုးရှင်းသော FAQ bot များအတွက် သင့်တော်ပါတယ်။
• ကြီးသော model များ က ပိုကောင်းစွာ စဉ်းစားနိုင်ပြီး ရှည်လျားသော ညွှန်ကြားချက်များကို ပိုယုံကြည်ရစွာ လိုက်နာပြီး ရှုပ်ထွေးသော မေးခွန်းများကို ကိုင်တွယ်နိုင်ပါတယ်။ သို့သော် message တစ်ခုစီအတွက် ပိုကုန်ကျပြီး ပိုနှေးပါတယ်။

အလယ်အလတ် model ဖြင့် စတင်ပြီး သင့်တကယ်မေးခွန်းများဖြင့် စမ်းသပ်ကာ ပြောင်းလဲပါ။ API များကို ဘယ်လိုစျေးနှုန်းသတ်မှတ်ပြီး ဘယ်လိုခေါ်ရသလဲ မသိသေးလျှင် LLM API များကို အသုံးပြုနည်း ကို အရင်ဖတ်ပါ။

Bot ၏ အသိပညာ ဘယ်မှလာသလဲ

ရိုးရှင်းဆုံး ရွေးချယ်စရာဖြင့် စတင်ပါ။ Retrieval တွင် search index၊ ၎င်းကို အပ်ဒိတ်လုပ်ပေးရန်နှင့် အဖြေမှားနိုင်သော နေရာများ ပိုများလာပါတယ်။ အသုံးဝင်သော bot အများအပြားသည် ၎င်းကို လုံးဝမလိုပါ။

Public သို့မဟုတ် login နောက်ကွယ်တွင်

သင့်ဝဘ်ဆိုဒ်ပေါ်ရှိ public chatbot သည် ရောက်ရှိရလွယ်ပေမယ့် အလွဲသုံးစားလုပ်ရလွယ်ပါတယ်- တစ်စုံတစ်ယောက်က script ဖြင့် message ထောင်ချီ ပို့နိုင်ပါတယ်။ Login ဖြင့် ထားလျှင် အသုံးပြုသူတစ်ဦးချင်းစီ၏ history ကို သိမ်းနိုင်ပြီး အကောင့်တစ်ခုချင်းစီအတွက် နေ့စဉ် ခွင့်ပြုချက် သတ်မှတ်နိုင်ပါတယ်။ Public ဖြစ်လျှင် message အရှည်ကို ကန့်သတ်ပါ၊ ဖော်ပြထားသော ကာလအတွင်း visitor တစ်ဦး ပို့နိုင်သော message အရေအတွက်ကို ကန့်သတ်ပါ၊ provider ၏ dashboard တွင် လစဉ် hard limit သတ်မှတ်ပါ။ အက်ပ်သို့ login ထည့်နည်း တွင် အကောင့်ဘက်ကို ရှင်းပြထားပါတယ်။

စကားဝိုင်းများ သိမ်းမလား

သိမ်းထားသော thread များက အသုံးဝင်ပါတယ်- အသုံးပြုသူများ ရပ်ထားရာမှ ပြန်ဆက်နိုင်ပြီး၊ prompt ကို ပိုကောင်းအောင် ပြင်ရန် အမှန်တကယ် မေးခွန်းများကို ဖတ်နိုင်ပါတယ်။ သို့သော် ၎င်းတို့သည် ကိုယ်ရေးအချက်အလက် (personal data) ဖြစ်ပါတယ်။ ဘယ်လောက်ကြာ သိမ်းမလဲဆိုတာ ဆုံးဖြတ်ပြီး သင့် privacy notice တွင် ပြောပြပါ၊ မလိုအပ်သော အရာကို မသိမ်းပါနှင့်။

System prompt ကို အလုပ်ဖော်ပြချက်လို ရေးပါ

System prompt သည် စကားဝိုင်းတိုင်းမတိုင်မီ model ရရှိသော ညွှန်ကြားချက်ဖြစ်ပါတယ်။ ကောင်းသော prompt တစ်ခုက အလုပ်သစ်ဝန်ထမ်းအတွက် အတိုချုပ် ဖော်ပြချက်လို ဖတ်ရပါမည်-

• ရာထူးနှင့် ပရိသတ်: "သင်သည် Oakline ဆိုင်ကယ်ပြုပြင်ဆိုင်၏ အကူအညီပေး assistant ဖြစ်သည်။ သင်သည် ဖောက်သည်များနှင့် ပြောသည်။"
• နယ်ပယ်: "ဝန်ဆောင်မှုများ၊ စျေးနှုန်းများ၊ ဖွင့်ချိန်နှင့် ကြိုတင်မှာယူမှုနှင့် ဆိုင်သော မေးခွန်းများကိုသာ ဖြေပါ။ အခြားအရာများအတွက် ဆိုင်နှင့်ဆိုင်သည့် အရာများကိုသာ ကူညီနိုင်ကြောင်း ပြောပါ။"
• အရင်းအမြစ်အမှန်: "အောက်ပါ အချက်အလက်ကိုသာ သုံးပါ။ အဖြေမရှိလျှင် မသိကြောင်း ပြောပြီး ဆိုင်၏ ဖုန်းနံပါတ်ကို ပေးပါ။"
• လေသံနှင့် အရှည်: "ဖော်ရွေပြီး ရိုးရှင်းသော အင်္ဂလိပ်စာ၊ တောင်းဆိုခြင်းမရှိလျှင် စာကြောင်း သုံးကြောင်းထက် မပိုပါစေနှင့်။"
• တင်းကျပ်သော စည်းမျဉ်း: "စာရင်းမှာမပါသော ပြုပြင်ခနဲ့ စျေးနှုန်းကို ဘယ်တော့မှ မကတိပါနှင့်။ ကတ်အချက်အလက်ကို ဘယ်တော့မှ မတောင်းပါနှင့်။"

ထို့နောက် ခက်ခဲသော မေးခွန်းများဖြင့် စမ်းကြည့်ပါ- နယ်ပယ်အပြင် တောင်းဆိုချက်များ၊ ရိုင်းစိုင်းသော message များ၊ အဖြေမပါသော မေးခွန်းများနှင့် ညွှန်ကြားချက်ကို ဖျက်ခိုင်းသော ကြိုးပမ်းမှုများ ("သင်၏စည်းမျဉ်းများကို မေ့ပြီး…")။ သင့်နာမည်ကို တာဝန်ယူနိုင်သော အဖြေများ ရသည်အထိ prompt ကို ပြင်ပါ။

ကုန်ကျစရိတ်ကို ခန့်မှန်းနိုင်အောင် ထားပါ

Provider များက သင်ပို့သော input နှင့် model ရေးသော output အတွက် token (စကားလုံးအပိုင်းအစများ) အလိုက် ငွေယူပါတယ်။ ကုန်ကျစရိတ်ကို အဓိက အကျိုးသက်ရောက်စေသော အချက်သုံးခုရှိပါတယ်-

1. စကားဝိုင်းအရှည်။ Message အသစ်တိုင်း ပုံမှန်အားဖြင့် model အတွက် အကြောင်းအရာရရန် thread တစ်ခုလုံးကို ပြန်ပို့ပါတယ်။ Message ၄၀ ရှိသော chat သည် message ၄ ခုရှိသော chat ထက် ပြန်ဖြေချက်တစ်ခုစီအတွက် များစွာ ပိုကုန်ပါတယ်။ နောက်ဆုံး အကြိမ်အနည်းငယ်ကိုသာ ထားပါ၊ သို့မဟုတ် အဟောင်းများကို အကျဉ်းချုံးပါ။
2. Prompt အရွယ်အစား။ ရှည်သော system prompt သို့မဟုတ် ကူးထည့်ထားသော အကြောင်းအရာကြီးများကို message တိုင်းနှင့်အတူ ပို့ပါတယ်။
3. Output အရှည်။ API ခေါ်ဆိုမှုတွင် ပြန်ဖြေချက်၏ အမြင့်ဆုံးအရှည်ကို သတ်မှတ်ပါ၊ prompt တွင် တိုတိုရှင်းရှင်း ဖြေရန် တောင်းဆိုပါ။

မထွက်မီ provider ၏ dashboard တွင် လစဉ် spending limit သတ်မှတ်ပါ၊ request တစ်ခုစီ token အသုံးပြုမှုကို မှတ်တမ်းတင်ပါ၊ ဘယ် စကားဝိုင်းက ကုန်ကျများသလဲ သိရန်။ စျေးနှုန်းကို ဤနေရာတွင် မဖော်ပြပါ၊ မော်ဒယ်အလိုက် ကွဲပြားပြီး မကြာခဏ ပြောင်းလဲသောကြောင့်၊ provider ၏ စျေးနှုန်းစာမျက်နှာကို စစ်ပါ။

အဆင့်လိုက် တည်ဆောက်ပါ

အဆင့် ၁: Code မဟုတ်ဘဲ bot ကို ဖော်ပြပါ

ပရိသတ်၊ နယ်ပယ်၊ ဒေတာနှင့် လုံခြုံရေးစည်းမျဉ်းများကို ဖော်ပြသော ပထမ prompt က အများစုကို ရရှိစေပါတယ်-

Oakline ဆိုင်ကယ်ပြုပြင်ဆိုင်အတွက် ဖောက်သည် အကူအညီ chatbot တစ်ခု တည်ဆောက်ပါ။ Message စာရင်းနှင့် input ပါသော chat page၊ ရေးနေစဉ် streaming ဖြင့် ပြန်ဖြေချက်များ။ Server route မှ Anthropic API ကို ခေါ်ပါ၊ လျို့ဝှက် ANTHROPIC_API_KEY ကို သုံးပါ- browser သို့ ဘယ်တော့မှ မပေါ်စေနှင့်။ shop-info.md ဖိုင်ထဲမှ စာသားဖြင့်သာ ဝန်ဆောင်မှု၊ စျေးနှုန်းနှင့် ဖွင့်ချိန်ကို ဖြေသော system prompt သုံးပါ၊ အခြားအခါများတွင် "သေချာမသိပါ — အောက်ပါနံပါတ်သို့ ခေါ်ပါ" ဟု ပြောပါ။ Message ကို စာလုံး ၅၀၀ အထိ၊ visitor တစ်ဦးလျှင် တစ်နာရီ message ၂၀ အထိ ကန့်သတ်ပါ။ ဖုန်းပေါ်တွင် အဆင်ပြေသော ရှင်းလင်းပြီး ဖော်ရွေသော ဒီဇိုင်း။

အဆင့် ၂: Key ကို secret အဖြစ် ထည့်ပါ

Provider console တွင် key ဖန်တီးပြီး project ၏ environment variables သို့မဟုတ် secrets တွင် သိမ်းပါ၊ chat ထဲ သို့မဟုတ် code ထဲ မထည့်ပါနှင့်။ Key တစ်ခုခု နေရာအများသူငှာတွင် ပေါ်သွားလျှင် provider တွင် ရုပ်သိမ်းပြီး အသစ်ဖန်တီးပါ။ Environment variables နှင့် secrets ဆိုတာ ဘာလဲ တွင် အဘယ်ကြောင့် အရေးကြီးသည် ရှင်းပြထားပါတယ်။

အဆင့် ၃: Interface သာမက အဖြေများကို စမ်းပါ

Chat အလုပ်လုပ်ပြီးနောက် အချိန်အများစုကို အဖြေအရည်အသွေးအတွက် ပေးပါ။ တကယ့်မေးခွန်း ၂၀ ခန့် စာရင်းကို ထားပါ၊ ငြင်းသင့်သော အချို့ပါဝင်ပါစေ၊ prompt ပြောင်းတိုင်း ပြန်စမ်းပါ။ စစ်ဆေးရန်-

• နယ်ပယ်အတွင်းတွင်သာ ရှိနေသလား?
• မသိသည့်အခါ မသိကြောင်း ဝန်ခံသလား၊ သို့မဟုတ် အဖြေကို ပြုစုထားသလား?
• ညွှန်ကြားချက်ကို ဖျက်ခိုင်းသော ကြိုးပမ်းမှုကို ခံနိုင်ရည်ရှိသလား?
• Browser က ဒေါင်းလုဒ်လုပ်သော ဘယ်အရာတွင်မှ key မပါသလား?

အဆင့် ၄: လိုအပ်လျှင် မှတ်ဉာဏ်နှင့် အကောင့်များ ထည့်ပါ

စကားဝိုင်းတစ်ခုချင်း အလုပ်လုပ်ပြီးသည်နှင့် သိမ်းထားသော thread များကို database တွင် တောင်းပြီး၊ လိုအပ်လျှင် အသုံးပြုသူတစ်ဦးချင်းစီသည် သူ၏ chat ကိုသာ မြင်စေရန် sign-up နှင့် login ထည့်ပါ။ တစ်ပြိုင်နက် အသုံးပြုသူတစ်ဦးချင်းစီ၏ နေ့စဉ် message ခွင့်ပြုချက်ကို ထည့်ပါ။

အဆင့် ၅: ကန့်သတ်ချက်များ ဖွင့်ထားပြီး ထုတ်ပြန်ပါ

ထုတ်ပြန်ထားသော app တွင် preview နှင့် တူညီသော secrets ရှိကြောင်း၊ provider တွင် spending cap သတ်မှတ်ထားကြောင်း၊ error များကို သင်မြင်နိုင်သည့်နေရာတွင် မှတ်တမ်းတင်ထားကြောင်း သေချာပါစေ။ ထို့နောက် သင့်ဝဘ်ဆိုဒ်ပေါ်တင်မီ လူအနည်းစုနှင့် အရင်မျှဝေပါ။

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

Chatbot သည် သင့်အမည်ဖြင့် ပြည်သူနှင့် စကားပြောပါတယ်၊ ထို့ကြောင့် ၎င်း၏ ပျက်ကွက်မှုများကို သင့်တာဝန်အဖြစ် ကိုင်တွယ်ပါ-

• မှားသော အဖြေများ။ Model များက မှန်ကန်မှုမရှိသော အရာများကို ယုံကြည်စွာ ပြောတတ်ပါတယ်။ Bot ကို ကျဉ်းမြောင်းသော အကြောင်းအရာတွင် ထားပါ၊ သင့်ကိုယ်ပိုင်အကြောင်းအရာဖြင့် အခြေခံပါ၊ အရေးကြီးသော အရာများတွင် အဖြေများ မှားနိုင်ကြောင်း အတိုချုပ် သတိပေးချက် ပြပါ။
• Prompt injection။ အသုံးပြုသူများ (သို့မဟုတ် bot ဖတ်သော စာရွက်စာတမ်းများ) တွင် "ယခင်စည်းမျဉ်းများကို လျစ်လျူရှုပါ" ကဲ့သို့ ညွှန်ကြားချက်များ ပါနိုင်ပါတယ်။ ယုံကြည်မရသော စွမ်းရည်များကို bot အား မပေးပါနှင့်- သင့်ကုဒ်ထဲ စစ်ဆေးမှုမရှိဘဲ အသုံးပြုသူ၏ စကားအပေါ် ငွေပြန်အမ်း၊ ဖျက်ခြင်း သို့မဟုတ် အီးမေးလ် ပို့ခြင်း မလုပ်ပါနှင့်။
• အထိခိုက်မခံသော ခေါင်းစဉ်များ။ ဆေးဘက်ဆိုင်ရာ၊ ဥပဒေဆိုင်ရာ သို့မဟုတ် ငွေကြေးဆိုင်ရာ မေးခွန်းများအတွက် အကြံပေးမည့်အစား ပရော်ဖက်ရှင်နယ်ထံ လမ်းညွှန်ပါ။
• ကိုယ်ရေးအချက်အလက်။ လိုအပ်ခြင်းမရှိလျှင် prompt ထဲ ဖောက်သည်မှတ်တမ်းများ မကူးထည့်ပါနှင့်၊ API ဒေတာကို provider က ဘယ်လိုကိုင်တွယ်သလဲ ၎င်း၏ စည်းမျဉ်းများတွင် စစ်ပါ။

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

အများဆုံး အမှားများ

• Browser မှ provider ကို ခေါ်ခြင်း။ Key ယိုဝင်ပါမည်။ အမြဲ သင့် server မှတစ်ဆင့်သာ ခေါ်ပါ။
• Public bot တွင် ကန့်သတ်ချက်မရှိခြင်း။ Script တစ်ခုတည်းက နေ့တစ်ဝက်အတွင်း လစဉ် budget ကို ကုန်စေနိုင်ပါတယ်။
• RAG၊ tool များနှင့် model များစွာကို တစ်ပြိုင်နက် စတင်ခြင်း။ အရင်ဆုံး စကားဝိုင်းကောင်းတစ်ခု အလုပ်လုပ်အောင် လုပ်ပါ၊ တကယ့်မေးခွန်းများက လိုအပ်ကြောင်း ပြသသည့်အခါ နောက်ထပ်ထည့်ပါ။
• ရွှင်ပျော်သော မေးခွန်းများသာ စမ်းခြင်း။ အသုံးပြုသူများက ပထမနေ့တွင် ထူးဆန်း၊ ရန်လိုသော၊ နယ်ပယ်ပြင်ပ အရာများကို မေးမြန်းမည်ဖြစ်ပါတယ်။
• Thread ကို အဆုံးမဲ့ ကြီးလာခွင့်ပေးခြင်း။ Message တိုင်းနှင့်အတူ ကုန်ကျစရိတ်နှင့် တုံ့ပြန်ချိန် တက်လာပါမည်။

Ready-made product သည် ပိုကောင်းသည့်အချိန်

သင့် chatbot သည် သင့် product ၏ အစိတ်အပိုင်းဖြစ်ပြီး သင့်ကိုယ်ပိုင် ဒေတာ သို့မဟုတ် workflow လိုအပ်ပါက၊ ဒါမှမဟုတ် သီးခြား ပုံစံနှင့် အပြုအမူလိုအပ်ပါက ကိုယ်ပိုင်တည်ဆောက်ခြင်းသည် သင့်တော်ပါတယ်။ အောက်ပါအခြေအနေများတွင် ပိုသင့်တော်သော ရွေးချယ်မှု မဟုတ်ပါ-

• ရှိပြီးသား ဝဘ်ဆိုဒ်ပေါ်တွင် support widget တစ်ခုသာ လိုချင်သည်။ Helpdesk နှင့် live-chat ထုတ်ကုန်အများစုတွင် သင့် help centre ကို ဖတ်ပြီး ဖြေသော AI bot၊ လူသို့ လွှဲပေးခြင်း၊ inbox နှင့် အစီရင်ခံစာတို့ ပါဝင်လာပြီးပါပြီ။
• သင် သို့မဟုတ် သင့်အဖွဲ့သာ အသုံးပြုမည်။ ChatGPT သို့မဟုတ် Claude ကဲ့သို့ ယေဘုယျ assistant ကို စာရွက်စာတမ်းများ upload လုပ်ပြီး သုံးခြင်းဖြင့် လုံလောက်နိုင်ပါတယ်။
• တင်းကျပ်သော ကိုက်ညီမှု အာမခံချက် လိုအပ်သည်။ ဥပမာ ဆေးဘက်ဆိုင်ရာ သို့မဟုတ် ငွေကြေးဆိုင်ရာ ဥပဒေထိန်းချုပ်ထားသော ဒေတာ။ လက်မှတ်များ ရှိပြီးသား vendor သည် custom build ထက် ပိုလုံခြုံနိုင်ပါတယ်။

Mythex ဖြင့် တည်ဆောက်ခြင်း

Mythex သည် AI app builder တစ်ခုဖြစ်ပြီး chat ထဲတွင် chatbot ကို ဖော်ပြလိုက်ရုံဖြင့် interface နှင့် server-side ခေါ်ဆိုမှုကို ရေးပေးကာ live preview တွင် run ပြီး public URL သို့ ထုတ်ပြန်ပေးပါတယ်။ App အတွင်း AI သည် သင့်ကိုယ်ပိုင် provider key ကို သုံးပါတယ်။ Project secrets တွင် ထည့်ပါ၊ သို့မဟုတ် Mythex က လိုအပ်သောအခါ chat တွင် ပြသသော secrets card မှတစ်ဆင့် ထည့်ပါ။ Provider အသုံးပြုမှုကို သင့် provider အကောင့်သို့ ငွေယူပြီး Mythex build credits သို့ မဟုတ်ပါ။ Mythex သည် သင့် app ၏ အသုံးပြုသူများအတွက် token များ၊ built-in knowledge-base ထုတ်ကုန် သို့မဟုတ် အဆင်သင့် rate limit များကို မပေးပါ၊ ၎င်းတို့သည် သင်တောင်းဆိုပြီး စမ်းသပ်ရသော အပိုင်းများ ဖြစ်ပါတယ်။ App အတွင်း AI ထည့်ခြင်း docs စာမျက်နှာတွင် အဆင့်လိုက် ရှင်းပြထားပြီး၊ သင့်ကိုယ်ပိုင် API key များဖြင့် AI ထည့်ခြင်း တွင် starter prompt ရှိပါတယ်။

Bot သည် သိမ်းထားသော thread များ လိုအပ်လျှင် သင်တောင်းသည့်အခါ Mythex က project သို့ Postgres database ကို ထည့်ပေးပါတယ်။ App အတွင်း model အသုံးပြုရန် နည်းလမ်းအများအပြား၊ အနှစ်ချုပ်မှ အမျိုးအစားခွဲခြင်းအထိ၊ သင့် app သို့ AI feature များ ထည့်နည်း ကို ကြည့်ပါ၊ သို့မဟုတ် စတင်ရန် app template များ ကို လေ့လာပါ။

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