Fine-Tuning နှင့် RAG နှိုင်းယှဉ်ချက်

နားလည်ထားရမယ့် အချက်

RAG နဲ့ fine-tuning တို့က ပြဿနာကွဲပြားစွာ ဖြေရှင်းပေးပါတယ်၊ ဒါပေမယ့် မှားယွင်းစွာ အပြန်အလှန် အစားထိုးသုံးလေ့ရှိပါတယ်။

RAG က model ကို request time မှာ external knowledge ပေးပါတယ် — weight တွေ ဘယ်တော့မှ မရွေ့ပါဘူး၊ document အသစ်တစ်ခုကို index လုပ်လိုက်တာနဲ့ ချက်ချင်း သုံးလို့ရပါတယ်။

Fine-tuning ကတော့ additional training ကနေတဆင့် model ရဲ့ weight ကိုယ်တိုင်ကို ပြောင်းလဲပေးပါတယ်၊ ဆိုလိုတာက model က learn လုပ်ခဲ့တာကို prompt ထဲ ပြန်ထည့်ပေးစရာမလိုဘဲ 'မှတ်မိ' နေနိုင်ပါတယ် — ဒါပေမယ့် real compute time ကုန်ကျမယ့်၊ small adapter-based method မှလွဲပြီး real GPU memory ကုန်ကျမယ့် training run တစ်ခု ပြီးမှသာပါ။

Practical comparison က ရှင်းလင်းပါတယ်။

Dimension	RAG vs Fine-tuning
Knowledge update	RAG က instant ပါ (document တစ်ခုကို re-index ရုံ)၊ fine-tuning ကတော့ retraining, evaluating, model checkpoint အသစ် redeploy လုပ်ရမှာပါ။
Cost and hardware	RAG မှာ embedding model နဲ့ vector store လိုအပ်ပါတယ်၊ နှစ်ခုစလုံး စျေးသက်သာပြီး CPU ပေါ်မှာတောင် run နိုင်ပါတယ်၊ full fine-tuning ကတော့ inference တစ်ခုတည်းထက် VRAM အများကြီးပိုလိုတဲ့ GPU တစ်ခု နာရီပေါင်းများစွာ လိုအပ်ပါတယ်။
Complexity	RAG က data-pipeline ပြဿနာတစ်ခုပါ၊ fine-tuning ကတော့ overfitting ဒါမှမဟုတ် ရှိပြီးသား capability catastrophic forgetting လို risk ကိုယ်ပိုင်ပါတဲ့ training ပြဿနာတစ်ခုပါ။
ဘယ်ဟာက ဘာမှာ ကောင်းလဲ	RAG က fact ထပ်ထည့် ဒါမှမဟုတ် update လုပ်ရာမှာ သန်မာပြီး model ရဲ့ပြောပုံ ဒါမှမဟုတ် reasoning ပုံစံ ပြောင်းရာမှာ အားနည်းပါတယ်၊ fine-tuning ကတော့ ပြောင်းပြန်ပါ — style, tone, format-following, domain-specific behavior ရဲ့ ခံနိုင်ရည်ရှိတဲ့ ပြောင်းလဲမှုမှာ သန်မာပြီး fact ကို current ထားရာမှာ အားနည်းပါတယ်၊ weight ထဲ ကျစ်ထားတဲ့ fact တိုင်းက reality ထပ်ပြောင်းလိုက်တာနဲ့ stale ဖြစ်သွားလို့ပါ။

သိထားစရာ ပိုပေါ့ပါးတဲ့ middle ground ကတော့ LoRA နဲ့ QLoRA ပါ — full model အစား additional parameter အနည်းငယ်ကိုပဲ train တဲ့ adapter-based fine-tuning ပါ၊ full fine-tuning ရဲ့ compute နဲ့ memory ရဲ့ အစိတ်အပိုင်းတစ်ခုပဲ လိုအပ်ပါတယ်၊ ဒီ lesson ထဲမှာတော့ ၎င်းက ကိုယ်စားပြုတဲ့ tradeoff ကို နားလည်ဖို့ training job တကယ် run ဖို့ မလိုအပ်ပါဘူး။

Fine-tuning: Pretrain ပြီးသား model တစ်ခုပေါ်မှာ task- ဒါမှမဟုတ် domain-specific dataset တစ်ခုသုံးပြီး ထပ်လုပ်တဲ့ training ပါ၊ model ရဲ့ weight ကို update လုပ်ပေးပြီး checkpoint အသစ်တစ်ခု ထုတ်ပေးပါတယ် — base weight ဘယ်တော့မှ မပြောင်းလဲတဲ့ RAG နှင့် ကွဲပြားပါတယ်။

LoRA: Low-Rank Adaptation — full model ကို update လုပ်မယ့်အစား low-rank weight matrix အနည်းငယ်ကိုပဲ train တဲ့ fine-tuning technique တစ်ခုပါ၊ full fine-tuning နှင့်နှိုင်းယှဉ်ရင် compute နှင့် memory ကို သိသိသာသာ လျှော့ချပေးပါတယ်။

text

RAG (REQUEST-TIME) VS FINE-TUNING (TRAINING-TIME)
-------------------------------------------------
RAG (REQUEST-TIME) VS FINE-TUNING (TRAINING-TIME)
------------------------------------------------------

RAG                                FINE-TUNING
---                                -----------
question                           training examples
   |                                    |
   v                                    v
retrieve context                   gradient descent
   |                                updates model weights
   v                                    |
context + question -> LLM               v
   |                                new model checkpoint
   v                                    |
answer                                  v
                                    question -> LLM(new) -> answer

weights: unchanged                 weights: changed
update speed: instant              update speed: hours+ per run

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Code ဥပမာက 'request-time RAG' ဆိုတဲ့အရာ တကယ်ဆိုလိုတာကို mechanical core အနေနဲ့ ပြသထားပါတယ် — training loop ဘယ်မှာမှ မပါဝင်ပါဘူး။ Retrieve လုပ်ပြီးသား chunk list တစ်ခုနဲ့ question တစ်ခု ပေးရင်၊ context ပေးထားတာကနေပဲ ဖြေဖို့ model ကို ညွှန်ကြားချက်တစ်ခုနဲ့အတူ prompt string တစ်ခုထဲ concatenate လုပ်ပေးပါတယ် — request တစ်ခုနဲ့ တစ်ခုကြား ပြောင်းလဲသွားတာက ဒီ assemble လုပ်ထားတဲ့ string တစ်ခုပဲ ဖြစ်ပါတယ်။

ဒါကို fine-tuning run တစ်ခုမှာ လိုအပ်မယ့်အရာနဲ့ ယှဉ်ကြည့်ပါ —

Example dataset တစ်ခု (ထောင်ပေါင်းများစွာ ရှိနိုင်ပါတယ်)
ဒီ data ကို pass ပေါင်းများစွာ ဖြတ်ကျော် weight update လုပ်တဲ့ training loop တစ်ခု
Fine-tune လုပ်ထားတဲ့ model က ပတ်သက်မှုမရှိတဲ့ task တွေမှာ regress မဖြစ်ကြောင်း စစ်ဆေးဖို့ held-out evaluation set တစ်ခု
ပြီးနောက် deploy လုပ်ပြီး version ခွဲရမယ့် model checkpoint အသစ်တစ်ခု

ဒီ asymmetry ကတော့ တကယ်လိုအပ်တာက 'model က X ကို သိသင့်တယ်' ဆိုတဲ့ X ကို ပြောင်းလဲနေချိန်မှာ default အနေနဲ့ RAG ကို ရွေးချယ်သင့်တဲ့ practical argument ပါ — ဈေးနှုန်း၊ inventory, ယနေ့ schedule, ဒီအပတ် documentation။

လိုအပ်ချက်က behavioral ဖြစ်ပြီး ခံနိုင်ရည်ရှိတဲ့အခါ fine-tuning ကို ရွေးချယ်ပါ — output format တသမတ်တည်း၊ response အားလုံးမှာ tone အတိအကျ၊ system prompt တိုင်းမှာ အပြည့်အစုံ ပြောပြဖို့ ခက်ခဲတဲ့ domain-specific convention တစ်ခု လိုက်နာခြင်းစတာတွေ။

LoRA နဲ့ QLoRA တို့က full model အစား adapter weight သေးသေးလေးတွေကိုပဲ train ပြီး fine-tuning ရဲ့ cost gap ကို ကျဉ်းစေပါတယ်၊ ဒါပေမယ့် RAG နဲ့ မတူဘဲ training run တစ်ခု တကယ် လိုအပ်ဆဲပါ။

RAG က weight မပြောင်းလဲဘဲ request time မှာ knowledge ကို prompt ထဲ inject လုပ်ပေးပါတယ်၊ fine-tuning ကတော့ additional training ကတဆင့် weight ကိုယ်တိုင်ကို ပြောင်းလဲပါတယ်။
ပြောင်းလဲနေတဲ့ fact တွေအတွက် RAG ကို ဦးစားပေးပါ၊ prompt တိုင်းမှာ ပြန်ရေးဖို့ ခက်ခဲတဲ့ style, tone, domain-specific behavior ရဲ့ ခံနိုင်ရည်ရှိတဲ့ ပြောင်းလဲမှုအတွက် fine-tuning ကို စဉ်းစားပါ။
LoRA/QLoRA တို့ဟာ full fine-tuning ထက် compute အများကြီး နည်းတဲ့ adapter-based fine-tuning method တွေပါ၊ ဒါပေမယ့် RAG ရဲ့ instant update နဲ့ မတူဘဲ training run တစ်ခု တကယ် လိုအပ်ဆဲပါ။

အတူတူ စမ်းရေးကြည့်မယ်

python

def build_rag_prompt(retrieved_chunks, question):
    context = "\n".join(f"- {c}" for c in retrieved_chunks)
    prompt = (
        "Answer the question using only the context below. "
        "If the answer is not in the context, say you don't know.\n\n"
        f"Context:\n{context}\n\n"
        f"Question: {question}\n"
        "Answer:"
    )
    return prompt


retrieved_chunks = [
    "The Basic Plan costs $9/month and includes 5 projects.",
    "The Pro Plan costs $29/month and includes unlimited projects.",
]
question = "How much does the Pro Plan cost?"

final_prompt = build_rag_prompt(retrieved_chunks, question)
print(final_prompt)
print("---")
print(f"prompt length: {len(final_prompt)} chars")

You should see

build_rag_prompt ကို ဈေးနှုန်း chunk နှစ်ခုနှင့် ဈေးနှုန်းမေးခွန်းတို့နှင့် run လိုက်ရာ -

Answer the question using only the context below. If the answer is not in the context, say you don't know.

Context:
- The Basic Plan costs $9/month and includes 5 projects.
- The Pro Plan costs $29/month and includes unlimited projects.

Question: How much does the Pro Plan cost?
Answer:
---
prompt length: 289 chars

'Answer:' အထက်က အားလုံးဟာ LLM ဆီ prompt string တစ်ခုတည်းအဖြစ် တကယ်ပို့ရမည့်အရာပါ — ဒီ process တစ်လျှောက်မှာ 'training' artifact သီးခြားတစ်ခုမှ ဘယ်နေရာမှ ထွက်မလာပါဘူး၊ string concatenation တစ်ခုပါပဲ။

၅ မိနစ် စမ်းကြည့်

retrieved_chunks ကို empty list [] ဖြစ်အောင်ပြောင်းပြီး build_rag_prompt ကို ပြန် run ကြည့်ပါ — ဒီ prompt ကို LLM ဆီပို့ရင် context မရှိတဲ့ အခြေအနေမှာ 'don't know' လို့ ဖြေဖို့ instruction က ဘာကြောင့်ပဲ အရေးကြီးလဲဆိုတာ စဉ်းစားပါ။ ပြီးရင် function ကို source_name လည်း ထည့်စေဖို့ ပြင်ဆင်ပါ၊ context line တစ်ခုစီရဲ့ဘေးမှာ chunk ဘယ် document ကလာလဲ ပြသနိုင်ဖို့ [Source: filename] ပုံစံနဲ့ format လုပ်ပါ။

သတိလေးတစ်ချက်

ပြောင်းလဲနေတဲ့ fact တစ်ခု (ဈေးနှုန်း, stock, ယနေ့ရက်စွဲ) ကို model 'သင်ပေးဖို့' fine-tune လုပ်ခြင်း — reality ထပ်ပြောင်းလိုက်တာနဲ့ fact က stale ဖြစ်သွားပါတယ်၊ RAG က ဒါကို cost အနည်းငယ်နဲ့ ဖြေရှင်းပေးနိုင်ပါတယ်။

Tone ဒါမှမဟုတ် formatting inconsistency ကို RAG တစ်ခုတည်းနဲ့ ပြင်နိုင်လိမ့်မယ်လို့ မျှော်လင့်ခြင်း — retrieval က context ထဲကို fact ထပ်ထည့်ပေးတာပါ၊ response တိုင်းမှာ model ရဲ့ ပြောဆိုပုံကို ယုံကြည်စိတ်ချစွာ ပြောင်းမပေးပါဘူး။

အမြန် စစ်ဆေးမှု

Model ကို ဒီအပတ်ရဲ့ product ဈေးနှုန်းနဲ့ အမြဲ ဖြေစေချင်ပါတယ်၊ ဈေးနှုန်းက ရက်အနည်းငယ်တိုင်း ပြောင်းနေပါတယ်။ ဘယ်ရွေးချယ်မှုက ပထမဆုံး ပိုကောင်းလဲ?

A. ဈေးနှုန်းစာရင်းအသစ်ပေါ်မှာ model ကို အပတ်စဉ် fine-tune လုပ်ပါ။B. RAG ကို သုံးပါ — လက်ရှိ ဈေးနှုန်းစာရင်းကို index လုပ်ပြီး request time မှာ retrieve လုပ်ပါ၊ ဈေးနှုန်းပြောင်းတိုင်း retraining မလိုပါဘူး။C. Historical price တွေပေါ်မှာ တစ်ကြိမ်တည်း fine-tune လုပ်ပြီး model ကို လက်ရှိဈေးနှုန်းကို estimate လုပ်ခိုင်းပါ။D. မဖြစ်နိုင်ပါဘူး — ဒါကို cloud model မပါဘဲ ဖြေရှင်းလို့ မရပါဘူး။

Hugging Face PEFT Documentation — Local AI / Local LLM