Model တစ်ခုကို 'ကျွန်တော့်ကုမ္ပဏီရဲ့ HR policy ဘာလဲ' လို့ မေးရင် model က training data ထဲမှာ ဒီ policy မပါဘူးဆိုရင် ခန့်မှန်းဖြေနိုင်ပါတယ် (hallucination)။ RAG (Retrieval-Augmented Generation) ကတော့ 'အဖြေရှာပြီးမှ ဖြေခိုင်း' ဆိုတဲ့ ရိုးရှင်းတဲ့ idea ဖြင့် ဒီပြဿနာကို ဖြေရှင်းပေးပါတယ်။
RAG ရဲ့ အဆင့်များ
RAG pipeline က document ကို chunk (အပိုင်းငယ်) များအဖြစ် ခွဲ၊ chunk တစ်ခုစီကို embedding (vector ဂဏန်းအစုအစည်း) အဖြစ် ပြောင်း၊ database ထဲ သိမ်းထားပါတယ်။ User မေးခွန်းလာတဲ့အခါ မေးခွန်းကိုပါ embedding ပြောင်းပြီး database ထဲက အနီးစပ်ဆုံး chunk များကို ရှာထုတ် (retrieve) ပါတယ်။ နောက်ဆုံးမှာ ရှာတွေ့တဲ့ chunk တွေကို model ဆီ context အဖြစ် ပေးပြီး ဖြေခိုင်းပါတယ်။
| အဆင့် | လုပ်ဆောင်ချက် |
|---|---|
| 1. Chunk | Document ကို အပိုင်းငယ်များအဖြစ် ခွဲခြင်း |
| 2. Embed | Chunk တစ်ခုစီကို vector ဂဏန်းအဖြစ် ပြောင်းခြင်း |
| 3. Retrieve | User မေးခွန်းနဲ့ အနီးစပ်ဆုံး chunk များ ရှာခြင်း |
| 4. Generate | ရှာတွေ့တဲ့ chunk ကို context ပေးပြီး model ဖြေစေခြင်း |
ဘယ်အခါ RAG သုံးသင့်လဲ
Data က ပုံမှန်ပြောင်းနေတာ (documentation, policy, ticket)၊ company-specific ဖြစ်တာ၊ source ညွှန်းပြဖို့ လိုအပ်တာဆိုရင် RAG က fine-tuning ထက် ပိုသင့်တော်ပါတယ် — data အသစ်ကို retrain မလိုဘဲ database ထဲ ပြန်ထည့်ရုံနဲ့ up-to-date ဖြစ်နေလို့ပါ။
Chunk size ရဲ့ trade-off
Chunk ကြီးရင် context ပြည့်စုံပေမယ့် irrelevant data ပါလာနိုင်ပါတယ်။ Chunk သေးရင် precise ဖြစ်ပေမယ့် context ပြတ်တောက်နိုင်ပါတယ် — data အမျိုးအစားအလိုက် စမ်းညှိရပါတယ်။
အနှစ်ချုပ်
RAG က 'model ကို ဖတ်ခိုင်းပြီးမှ ဖြေခိုင်း' ဆိုတဲ့ pattern ပါ — training data ထဲမှာ မပါတဲ့ latest/company-specific data ကို model က တိကျစွာ ကိုးကားနိုင်စေပါတယ်။ Chunking, embedding, retrieval, citation — ဒီလေးချက်ကို သေချာချိန်ညှိထားရင် hallucination ကို သိသိသာသာ လျော့ချနိုင်ပါတယ်။