Data Lighthouse

ကျွန်တော် အခုလက်ရှိ Chip Huyen ရဲ့ AI Engineering စာအုပ်
ဖတ်ဖြစ်ရင်း အဲဒီထဲက Prompt Engineering Chapter နဲ့
ပတ်သက်ပြီးမျှဝေပေးချင်ပါတယ်။

အမှန်တိုင်းပြောရရင် အဲဒီအခန်းလေးကို ဖတ်ပြီးသွားတဲ့အချိန်မှာ
"Prompt Engineering" နဲ့ ပတ်သက်ပြီး ကျွန်တော့်ရဲ့ အမြင်တွေ
တော်တော်လေး ပြောင်းလဲသွားတယ်။
အရင်တုန်းကဆိုရင် Prompt Engineering ဆိုတာ
ကျွန်တော်တို့ ကိုယ်လိုချင်တဲ့ ပုံစံမျိုး (Format) နဲ့
အဖြေရအောင် Prompt တွေ ရေးတာလောက်ပဲလို့ ထင်ခဲ့မိတာ။
ဒါပေမယ့် တကယ်တမ်းကျတော့ သူ့မှာလည်း စိတ်ဝင်စားစရာတွေနဲ့
Challenges တွေအများကြီး ရှိနေသေးတယ်။

ဒီ Post မှာတော့ ကျွန်တော် ကိုယ်တိုင် ဖတ်ထားပြီး
ရရှိလာတဲ့ သင်ခန်းစာလေးတွေကို ဆွေးနွေးတဲ့ အနေနဲ့
ပြန်လည် မျှဝေပေးချင်ပါတယ်။

LLM Application ရဲ့ အလွှာ ၄ ခု (Four Layers of LLM)
ပထမဆုံးအနေနဲ့ LLM (Large Language Model) အသုံးပြုမှုမှာ
ပါဝင်တဲ့ အလွှာ ၄ ခု အကြောင်းလေး နည်းနည်း ရှင်းပြချင်ပါတယ်။
ကျွန်တော် အပါအဝင် User အများစုက Foundation model တွေကို
စသုံးတဲ့အခါ Prompt ကနေပဲ စကြတာများတယ်။
LLM Application တွေမှာ အဓိက ချဉ်းကပ်ပုံ (၄) မျိုးရှိပြီး၊
ဒါက အချက် (၂) ချက်ပေါ် မူတည်ပါတယ်။
- External Knowledge (ပြင်ပ ဗဟုသုတ) ဘယ်လောက် လိုအပ်လဲ။
- Adaptation (Model ကို ကိုယ့်လုပ်ငန်းစဉ်နဲ့ကိုက်အောင် ဘယ်လောက်အထိ ပြုပြင်ပြောင်းလဲဖို့) လိုအပ်လဲ။

ဒီနှစ်ခုလုံးကို အရမ်းကြီး လိုအပ်မနေဘူးဆိုရင်တော့
ကျွန်တော်တို့ ရိုးရိုး Basic Prompt Engineering လောက်နဲ့ပဲ
အဆင်ပြေပါတယ်။ ဒါပေမယ့် ကျွန်တော်တို့ရဲ့ Task တွေက
ပိုရှုပ်ထွေးလာပြီ၊ ပြင်ပက အချက်အလက် အမှန်တွေ လိုအပ်လာပြီ၊
ဒါမှမဟုတ် Model ကို သီးသန့် အပြုအမူတွေ သင်ပေးဖို့
လိုလာပြီဆိုရင်တော့ RAG (Retrieval-Augmented Generation),
Fine-tuning ဒါမှမဟုတ် အဲဒီနှစ်ခုကို ပေါင်းထားတဲ့ Hybrid တွေဆီကို
ကူးပြောင်းရတော့မှာပါ။ Prompting ဆိုတာ ပိုမိုကြီးမားကျယ်ပြန့်တဲ့
AI Ecosystem ကြီးတစ်ခုရဲ့ ပထမဆုံး ခြေလှမ်းလေးတစ်ခုသာ
ဖြစ်တယ်ဆိုတာပါပဲ။

စာအုပ်ထဲမှာ ပြောထားတဲ့အတိုင်းဆိုရင် Prompt တစ်ခုမှာ အဓိက အပိုင်း (၃) ပိုင်း ပါဝင်ပါတယ် -
- Task Description (လုပ်ဆောင်ရမယ့် အလုပ်ရဲ့ အသေးစိတ် ဖော်ပြချက်)
- Example (ဒီအလုပ်ကို ဘယ်လို ပြီးမြောက်အောင် လုပ်ရမလဲ ဆိုတဲ့ ဥပမာ) - Actual Task (တကယ် လုပ်ရမယ့် အလုပ်)
နောက်ထပ် ကျွန်တော် လေ့လာဖြစ်ခဲ့တာကတော့
In-context learning အကြောင်းပါ။
အရင်ကဆိုရင် Examples (Shots လို့လည်း ခေါ်ကြတယ်) တွေ
ပေးတာက Bias ဖြစ်စေနိုင်တယ်လို့ ထင်ခဲ့တာ။
ဒါပေမယ့် တကယ်တမ်းကျတော့ အဲဒါက Model ကို
အလုပ်တွေ ပိုပြီး ကိုင်တွယ်ဖြေရှင်းနိုင်အောင် ကူညီပေးနိုင်ပါတယ်။

ကျွန်တော်ရဲ့ Workflow အများစုမှာ System Prompt ရော
User Prompt တွေပါ ကိုင်တွယ်ဖြေရှင်းနေရတော့
ဒီနှစ်ခု ဘယ်လို အလုပ်လုပ်လဲဆိုတာကို သိချင်နေခဲ့တာ။
ကျွန်တော် သိလိုက်ရတာကတော့ အဲဒီ Prompt နှစ်ခုလုံးကို
အဆုံးမှာ Prompt တစ်ခုတည်းအနေနဲ့ ပေါင်းလိုက်ပြီး
အတူတူပဲ Process လုပ်သွားတာပါ။
"Task descriptions" တွေကို System Prompts အနေနဲ့
သတ်မှတ်နိုင်ပြီး၊ "Actual tasks" တွေကိုတော့
User Prompts တွေအနေနဲ့ မှတ်ယူနိုင်တယ်လို့
စာအုပ်ထဲမှာ ဆိုထားပါတယ်။

အစိတ်ဝင်စားဆုံး အချက်တစ်ခုကတော့
Model တွေက Prompt ရဲ့ အလယ်ပိုင်းမှာရှိတဲ့
ညွှန်ကြားချက်တွေထက် အစပိုင်းနဲ့ အဆုံးပိုင်းမှာရှိတဲ့
ညွှန်ကြားချက်တွေကို ပိုပြီး နားလည်နိုင်စွမ်း ရှိကြတယ် ဆိုတာပါပဲ။
ဒါကြောင့် Prompt-level defense (ကာကွယ်မှု) ရှုထောင့်ကနေ
ကြည့်မယ်ဆိုရင်လည်း အရေးကြီးတဲ့ ညွှန်ကြားချက်တွေကို
Prompt ရဲ့ အဆုံးမှာ ထပ်ပြီး သတိပေးတဲ့အနေနဲ့
ထည့်သွင်းပေးဖို့ အကြံပြုထားပါသေးတယ်။

ဒီစာအုပ်ထဲမှာ လက်တွေ့အသုံးချနိုင်တဲ့ Best practices တွေကိုလည်း အများကြီး ဖော်ပြပေးထားပါတယ်။
- Clear Instructions: ညွှန်ကြားချက်တွေကို
မရှင်းမလင်းဖြစ်တာမျိုးမရှိဘဲ တိတိကျကျ ရေးဖို့နဲ့
ဥပမာတွေ ပေးဖို့ လိုပါတယ်။
- Persona: Model အနေနဲ့ Task ကို ရှုထောင့်ပေါင်းစုံကနေ
ပိုနားလည်နိုင်အောင် Persona
(ဥပမာ - "မင်းက ကျွမ်းကျင်တဲ့ Data Analyst တစ်ယောက်ပါ" စသဖြင့်)
တစ်ခု သတ်မှတ်ပေးသင့်ပါတယ်။
- Output Format: JSON ဒါမှမဟုတ် Markdown စသဖြင့်
ကိုယ်လိုချင်တဲ့ Output format ကို တိတိကျကျ သတ်မှတ်ပေးပါ။
- Sufficient Context: Hallucination (မရှိတဲ့ အချက်အလက်တွေကို ယောင်ယမ်းဖြေဆိုခြင်း) တွေကို ရှောင်ရှားနိုင်ဖို့ Model ကို လုံလောက်တဲ့ Context (နောက်ခံ အချက်အလက်) တွေ ပေးဖို့က အရမ်း အရေးကြီးပါတယ်။
- Task Breakdown: ရှုပ်ထွေးတဲ့ Task ကြီးတွေကို
Subtasks လေးတွေအဖြစ် ခွဲထုတ်လိုက်တာက
Queries အရေအတွက်တော့ များသွားနိုင်ပေမယ့်
Performance ကိုတော့ သိသိသာသာ တက်လာစေပါတယ်။
ဒါ့အပြင် Monitoring၊ Debugging၊ Parallelism နဲ့ Effort တွေမှာပါ
ပိုပြီး အကျိုးကျေးဇူးတွေ ရနိုင်ပါတယ်။

ကျွန်တော်တို့အနေနဲ့ Prompt တွေကို အကြိမ်ကြိမ် စမ်းသပ်မှုတွေ
လုပ်ပြီး Iterative process (အထပ်ထပ် အခါခါ ပြင်ဆင်လေ့ကျင့်ခြင်း)
တစ်ခုလိုမျိုး လုပ်ဆောင်သင့်ပါတယ်။
ဒီအဆင့်မှာဆိုရင် Prompt Engineering Tools တချို့ကို
စမ်းသုံးကြည့်သင့်ပြီး ကျွန်တော်တို့ရဲ့ Prompt တွေကို
Version ခွဲပြီး မှတ်သား (Versioning) ထားသင့်ပါတယ်။
Prompt တွေကို စနစ်တကျ စီစဉ်ထားခြင်းကနေ
အကျိုးကျေးဇူးတွေ ရနိုင်ပါတယ်။ ဥပမာ - Prompt တွေနဲ့ Code တွေကို
သီးသန့်စီ ခွဲထုတ်ထားခြင်းအားဖြင့် ဖတ်ရလွယ်ကူလာစေပြီး
(Readability)၊ Prompt တွေကိုလည်း အကြိမ်ကြိမ် ပြန်လည်
အသုံးပြုနိုင်ပါတယ်။

ကျွန်တော်တို့ရဲ့ System ကို ဘယ်လို ကာကွယ်ရမလဲ ဆိုတာကိုလည်း
မဖြစ်မနေ စဉ်းစားရမှာဖြစ်ပြီး အဓိက Attack (တိုက်ခိုက်မှု) ၃ မျိုးကို
သတိပြုထားသင့်ပါတယ်။
- Prompt Extraction (ရေးထားတဲ့ Prompt တွေကို ခိုးယူခြင်း)
- Jailbreaking & Prompt Injection (Model ရဲ့ စည်းမျဉ်းတွေကို ဖောက်ဖျက်စေခြင်း၊ ညွှန်ကြားချက်အမှားများ ထည့်သွင်းခြင်း)
- Information Extraction (အတွင်းရေး အချက်အလက်များကို ခိုးယူခြင်း)
ဒီလို တိုက်ခိုက်မှုတွေကို ကာကွယ်ဖို့အတွက် Model Level, Prompt Level နဲ့ System Level ဆိုပြီး အဆင့် ၃ ဆင့်နဲ့ လုပ်ဆောင်နိုင်ပါတယ်။ အဓိကကတော့ ကိုယ့်ရဲ့ System က ဘယ်လို တိုက်ခိုက်မှုမျိုးတွေကို ခံရနိုင်ခြေရှိလဲ ဆိုတာကို ကြိုတင် သိထားဖို့ လိုအပ်ပါတယ်။

နိဂုံးချုပ်အနေနဲ့ ပြောရရင် Prompt Engineering ဆိုတာ
စာကြောင်းလေးတွေ ရေးရုံသက်သက် မဟုတ်ပါဘူး။
ကိုယ်လိုချင်တဲ့ ရလဒ်ကို အကောင်းဆုံးနဲ့ အထိရောက်ဆုံး နည်းလမ်းတွေနဲ့
ထွက်လာအောင် ညွှန်ကြားချက်တွေကို ဖန်တီးယူရတဲ့
အနုပညာ တစ်ခုလို့တောင် ခံစားရပါတယ်။
ဒါ့အပြင် အနာဂတ်မှာ ပြန်သုံးဖို့နဲ့ အကဲဖြတ်ဖို့ (Evaluate and Reuse) တွေကိုလည်း
ထည့်သွင်းစဉ်းစားရမှာပါ။ ဒီအပြင် ကျွန်တော်တို့ရဲ့ System ကို
ဘယ်လို တိုက်ခိုက်မှုတွေ လာနိုင်လဲ ဆိုတာကို သတိပြုနေရမယ့်အပြင်
အဲဒီ တိုက်ခိုက်မှုတွေအတွက် ဘယ်လို ကြိုတင်ပြင်ဆင်ထားရမလဲ
ဆိုတာကိုပါ ထည့်သွင်း စဉ်းစားထားဖို့ လိုအပ်ပါတယ်။