နားလည်ထားရမယ့် အချက်
local model ဆီ ပို့တဲ့ request တိုင်းဟာ တကယ်တော့ အရာနှစ်ခု ပေါင်းစပ်ထားတာပါ — conversation ကိုယ်တိုင် (message list အနေနဲ့ ဖွဲ့စည်းထားတယ်) နဲ့ model က နောက်စကားလုံးကို ဘယ်လို ရွေးမလဲ ထိန်းချုပ်တဲ့ generation setting တွေပါ။ message list မှာ ပုံမှန် role သုံးမျိုး ရှိပါတယ်။
- System message — conversation မစခင် model ရဲ့ persona နဲ့ rule ကို သတ်မှတ်ပေးတာဖြစ်ပြီး ဥပမာ “You are a patient programming tutor who explains ideas in Burmese and English” လိုမျိုးပါ။
- User message — လူတစ်ယောက် တကယ်ရိုက်ထည့်တာတွေပါ။
- Assistant message — model ရဲ့ ယခင် reply တွေဖြစ်ပြီး conversation history ကို model မှတ်မိအောင် list ထဲ ထားထားတာပါ။
ဒီ structure အပေါ်မှာ layer ထပ်ထားတာက generation setting တွေ (sampling parameter လို့လည်း ခေါ်ကြသည်) ဖြစ်ပြီး model က internal probability တွေကို စကားလုံးအစစ်တစ်ခုအဖြစ် ဘယ်လို ပြောင်းလဲမလဲ ပုံဖော်ပေးပါတယ်။
- Temperature — model က confidence အများဆုံး ရှိတဲ့ စကားလုံးတစ်ခုတည်းကို ဦးစားပေးမလား probability ကို confidence နည်းတဲ့ စကားလုံးတွေဆီ ပျံ့နှံ့ခွင့်ပေးမလား scale ချပေးပါတယ် — 0 နီးနီးဆိုရင် greedy နီးပါးဖြစ်ပြီး ပိုလုံခြုံတဲ့ စကားလုံးကို ရွေးတတ်ပြီး, value မြင့်ရင် ရှားပါးတဲ့ စကားလုံးတွေ ယှဉ်ပြိုင်ဝင်လာလို့ output ပိုမတူညီစွာ ဖြစ်စေပါတယ်။
- Top-p (nucleus sampling) — probability ပေါင်း 0.9 လို threshold ကို ကျော်တဲ့ candidate စကားလုံး အနည်းဆုံး set ကိုပဲ ကန့်သတ်ပေးလို့ ဖြစ်နိုင်ခြေ အလွန်နည်းတဲ့ စကားလုံးတွေကို ဖြတ်ချပေးပါတယ်။
- Top-k — step တစ်ခုစီမှာ probability အမြင့်ဆုံး k ခုကိုပဲ ထည့်တွက်တဲ့ ပိုရိုးရှင်းတဲ့ setting။
- Max tokens — reply တစ်ခု ဘယ်လောက်ရှည်နိုင်လဲ ကန့်သတ်ချက်။
Temperature 0 မှာတောင် output အတိအကျ ထပ်တူ မဖြစ်နိုင်
temperature 0 မှာတောင် output ဟာ အချိန်တိုင်း bit-for-bit အတိအကျ ထပ်တူ ဖြစ်ချေမည်ဟု အာမမခံနိုင်ကြောင်း ရိုးသားစွာ ဖော်ပြရပါမည် — floating-point math, batching, hardware ကွာခြားချက်တွေက runtime အလိုက် အနည်းငယ် ကွဲလွဲစေနိုင်ပါတယ်။
- Temperature
- model က နောက်စကားလုံးအတွက် confidence အများဆုံး ရွေးချယ်မှုကို ဘယ်လောက်ဦးစားပေးမလဲ scale ချပေးတဲ့ generation setting တစ်ခု — value နိမ့်ရင် focused ဖြစ်ပြီး ခန့်မှန်းနိုင်တဲ့ output ထွက်ပြီး, value မြင့်ရင် ပိုမတူညီတဲ့ output ထွက်ပါတယ်။
- Top-p
- Nucleus sampling ပါ — probability ပေါင်း threshold တစ်ခု (ဥပမာ 0.9) ကို ကျော်တဲ့ candidate စကားလုံး အနည်းဆုံး set ကိုပဲ model ကို ကန့်သတ်ပေးပြီး ဖြစ်နိုင်ခြေ အလွန်နည်းတဲ့ စကားလုံးတွေကို ဖြတ်ချပေးပါတယ်။
- System Prompt
- conversation မစခင် ထားပေးတဲ့ message တစ်ခုဖြစ်ပြီး model ရဲ့ persona, rule, (သို့) ကျန်တဲ့ conversation တစ်လျှောက်လုံးအတွက် behavior ကို သတ်မှတ်ပေးပါတယ်၊ end user က ရိုက်ထည့်ဖို့ (သို့) မြင်ဖို့ မလိုပါဘူး။
PROMPT STRUCTURE AND GENERATION DIALS
-------------------------------------
------------------------------------------------------------
SYSTEM PROMPT ---+
"You are a |
tutor..." |
v
USER PROMPT --> [ MODEL ] --> ASSISTANT RESPONSE
"Explain ^
for loops" |
dials turned before generating:
-----------------------------
temperature (focused <-> varied)
top-p (nucleus cutoff)
top-k (candidate pool size)
max tokens (reply length cap)လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
ဒီသင်ခန်းစာအစောပိုင်းက Burmese programming tutor ကို တည်ဆောက်နေတယ်လို့ ယူဆကြည့်ပါ။ system message က “You are a patient programming tutor who explains ideas in simple Burmese and English, and always includes a short code example.” လိုမျိုး ဖြစ်ပါလိမ့်မယ်။ ဒီစာကြောင်းတစ်ခုတည်းက user ဘယ်တော့မှ မမြင်ဘဲ conversation ကျန်တဲ့ အပိုင်းအားလုံးရဲ့ reply ကို ပုံဖော်ပေးပါတယ်။
- နေ့စဉ် Q&A — temperature ကို 0.2 လို နိမ့်နိမ့်နဲ့ top-p ကို 0.9 လို အလယ်အလတ် ထားပါလိမ့်မယ်၊ ဒါမှ model က creative ပေမယ့် လွဲမှားနိုင်တဲ့ ရှင်းပြချက်ဆီ လွှဲမသွားဘဲ confidence အများဆုံးရှိတဲ့, textbook စတိုင် phrasing ကို တသမတ်တည်း ရွေးနိုင်ပါလိမ့်မယ်။
- Practice-exercise generation — learner တွေ scenario တစ်ခုတည်းကို ထပ်ခါထပ်ခါ မမြင်ရအောင် ဒီ specific request တစ်ခုအတွက်ပဲ temperature ကို 0.9 လို မြင့်မြင့် တင်မယ်, tutoring conversation ကိုယ်တိုင်ကို temperature နိမ့်နိမ့်မှာ ဆက်ထားမယ်။
ဒါက ဒီသင်ခန်းစာရဲ့ practical အနှစ်ချုပ်ပါ — temperature ဆိုတာ app တစ်ခုလုံးအတွက် global setting တစ်ခုတည်းမဟုတ်ဘဲ, request တစ်ခုစီအတွက် reliability လိုချင်လား variety လိုချင်လား ပေါ်မူတည်ပြီး ရွေးရတဲ့ per-request dial တစ်ခု ဖြစ်ပါတယ်၊ အောက်ပါ code exercise က ဒီလို request structure ကို ကိုယ်တိုင် တည်ဆောက်ခိုင်းထားပါတယ်။
အတူတူ စမ်းရေးကြည့်မယ်
import json
def build_chat_messages(system_prompt, conversation_history, user_message):
messages = [{"role": "system", "content": system_prompt}]
for turn in conversation_history:
messages.append({"role": "user", "content": turn["user"]})
messages.append({"role": "assistant", "content": turn["assistant"]})
messages.append({"role": "user", "content": user_message})
return messages
if __name__ == "__main__":
system_prompt = (
"You are a patient programming tutor who explains ideas in "
"simple Burmese and English, with short code examples."
)
history = [
{
"user": "Python list ဆိုတာ ဘာလဲ?",
"assistant": "List ဆိုတာ item အများကြီးကို စဉ်လိုက် သိမ်းထားနိုင်တဲ့ container တစ်ခုပါ.",
}
]
new_message = "for loop နဲ့ list ထဲက item တွေကို ဘယ်လို ထုတ်ကြည့်လဲ?"
messages = build_chat_messages(system_prompt, history, new_message)
print(json.dumps(messages, ensure_ascii=False, indent=2))
script ကို run လိုက်ရင် message object လေးခု ပါဝင်တဲ့ JSON array တစ်ခု print ထုတ်ပါတယ် — tutor persona ကို သတ်မှတ်တဲ့ system message, Python list ဆိုတာ ဘာလဲ မေးတဲ့ ပထမ user message, list အကြောင်း သိမ်းထားတဲ့ assistant reply, ပြီးတော့ list ကို for loop နဲ့ ဘယ်လို ထုတ်ကြည့်လဲ မေးတဲ့ user message အသစ် — key 'role' နဲ့ 'content' နှစ်ခုစီနဲ့ 2-space indent ဖြင့် format လုပ်ထားပါတယ်။၅ မိနစ် စမ်းကြည့်
`build_chat_messages` ကို `temperature` argument ထပ်ယူအောင် တိုးချဲ့ပါ၊ JSON မထုတ်ခင် 'Sending N messages at temperature X' လိုမျိုး one-line summary ကို function ထဲက print ထုတ်ခိုင်းပါ၊ ပြီးရင် conversation တူတူကို temperature 0.2 နဲ့ 0.9 နှစ်ခုနဲ့ ခေါ်ကြည့်ပြီး summary line နှစ်ကြောင်းကို compare ကြည့်ပါ။
သတိလေးတစ်ချက်
model ရဲ့ behavior အတွက် ရည်ရွယ်တဲ့ instruction ကို system message အစား user message ထဲ ထည့်ခြင်း — နောက် user turn တစ်ခုက override (သို့) လျစ်လျူရှုလို့ လွယ်သွားစေပါတယ်။
temperature 0 ထားရင် run တိုင်း output အတိအကျ ထပ်တူ ရမယ်လို့ ယုံကြည်ခြင်း — output ကို ပိုတည်ငြိမ်စေတာသာဖြစ်ပြီး runtime အားလုံးမှာ bit-for-bit deterministic မဟုတ်ပါဘူး။
Temperature — ခန့်မှန်းနိုင်လား ဖန်တီးနိုင်လား?
Ollama API documentation (chat request options) — Local AI / Local LLM