1. ปัญหา (Problem statement)​

ลองนึกภาพว่าคุณเอา Qwen3-0.6B มาถามว่า "ตามระเบียบสำนักนายกรัฐมนตรี การจัดซื้อจัดจ้างโดยวิธีเฉพาะเจาะจงทำได้เมื่อใด" โมเดลจะตอบได้อย่างมั่นใจ และตอบผิด เพราะมันไม่เคยเห็นเอกสารราชการไทยมากพอ

หลายคนพยายามแก้ด้วยการทำ fine-tuning ด้วยคู่ถาม-ตอบไม่กี่พันตัวอย่าง แล้วพบว่าไม่ได้ผล เหตุผลคือ SFT สอน "รูปแบบการตอบ" ไม่ได้สอน "ความรู้" ถ้าโมเดลไม่เคยมีความรู้นั้นอยู่ในน้ำหนัก (weights) การสอนให้มันตอบด้วยน้ำเสียงที่ถูกต้องก็แค่ทำให้มันมั่นใจเวลาโกหกเท่านั้น

ความรู้ใหม่เข้าสู่โมเดลได้ 3 ทาง และเลือกผิดคือสาเหตุที่โปรเจกต์ LLM ส่วนใหญ่ล้มเหลว:

บทความนี้คือทางที่สอง

2. เราจะทำอะไร (Solution)​

เราจะเอาโมเดล base (ยังไม่ผ่าน instruction tuning) มาเทรนต่อด้วย objective เดียวกับตอน pretrain เป๊ะ ๆ คือทายคำถัดไป บนข้อความดิบภาษาไทยในโดเมนที่เราสนใจ ไม่มี label ไม่มีคู่ถาม-ตอบ มีแค่ข้อความล้วน ๆ

แต่หัวใจของบทความนี้ไม่ใช่ "เทรนแล้วเก่งขึ้น" — มันคือสิ่งที่แลกมา:

ปรากฏการณ์ที่โมเดลลืมสิ่งที่เคยทำได้ เรียกว่า catastrophic forgetting เราจะไม่พูดลอย ๆ แต่จะวัดมันออกมาเป็นตัวเลข แล้วหาจุดที่ยอมรับได้

3. สมการ (Equation)​

3.1 Objective ของ CPT​

• $x_t$ = token ตำแหน่งที่ $t$
• $x_{<t}$ = token ทั้งหมดก่อนหน้า
• $p_\theta$ = ความน่าจะเป็นที่โมเดลทำนาย

สมการนี้เหมือนกับตอน pretrain ทุกประการ สิ่งเดียวที่เปลี่ยนคือข้อมูล นี่คือเหตุผลที่ CPT ไม่ต้องการ label — ข้อความเองคือเฉลย

3.2 Perplexity: หน่วยวัดของเรา​

แปลเป็นภาษาคน: "โดยเฉลี่ยแล้ว โมเดลกำลังลังเลอยู่ระหว่างกี่ตัวเลือก" PPL = 20 คือลังเลประมาณ 20 คำ, PPL = 5 คือมั่นใจกว่ามาก ยิ่งต่ำยิ่งดี

3.3 สมการที่สำคัญที่สุดในบทนี้ — Replay Mixing​

$\lambda$ คือสัดส่วนข้อมูลโดเมนในแต่ละ batch

• $\lambda = 1.0$ → ข้อมูลโดเมนล้วน → เก่งโดเมนเร็วที่สุด และลืมเร็วที่สุด
• $\lambda = 0.5$ → ผสมครึ่งต่อครึ่ง → ช้ากว่าแต่ลืมน้อยกว่ามาก

อย่า hardcode ค่านี้ จงกวาดหาค่ามัน แล้วเลือกจุดที่คุณยอมรับได้

4. เห็นภาพสมการ (Visualize)​

Perplexity บอกอะไรเรากันแน่​

กราฟขวาคือสิ่งที่คนมักพลาด: ถ้ามีคนบอกว่า "ลด perplexity ได้ 5 หน่วย" แล้วไม่บอกว่าเริ่มจากเท่าไหร่ ประโยคนั้นแทบไม่มีความหมาย เพราะ 80 → 75 คือดีขึ้น 6% แต่ 10 → 5 คือดีขึ้น 50%

การแลกเปลี่ยนที่ replay ratio ควบคุม​

5. เตรียมสภาพแวดล้อม (Environment)​

เปิด Colab เลือก Runtime → Change runtime type → T4 GPU (ใช้แผนฟรีได้)

torch_dtype=torch.float16      # ไม่ใช่ bfloat16
attn_implementation="sdpa"     # ไม่ใช่ flash_attention_2
fp16=True                      # ใน TrainingArguments (ไม่ใช่ bf16=True)

เซลล์แรกของทุกโน้ตบุ๊กในซีรีส์จะพิมพ์บรรทัดนี้ออกมาให้เห็นกับตา:

cap = torch.cuda.get_device_capability(0)
print("compute capability:", cap)                    # T4 = (7, 5)
print("native bf16:", cap[0] >= 8)                   # T4 -> False
print("torch says   :", torch.cuda.is_bf16_supported())  # T4 -> True (นับ emulation!)

งบ VRAM มีเท่าไหร่ และหมดไปกับอะไร​

สังเกตว่า optimizer state กินที่มากกว่าตัวโมเดลเอง — Adam เก็บ $m$ และ $v$ อย่างละหนึ่งชุดเท่าจำนวนพารามิเตอร์ การเปลี่ยนไปใช้ adamw_bnb_8bit ประหยัดได้ 3.3 GB ซึ่งแปลว่าคุณเพิ่ม batch size หรือความยาว sequence ได้อีกมาก

ลองเล่นกับงบ VRAM ด้วยตัวเอง — ปรับค่าแล้วดูว่าเมื่อไหร่จะ OOM:

6. เตรียมข้อมูล (Data)​

เราใช้ pythainlp/thaigov-v2-corpus-22032023 — คลังข่าวและเอกสารราชการไทย (สาธารณสมบัติ) เป็นตัวแทนของ "ความรู้เฉพาะทางที่โมเดลไม่เคยเห็นมากพอ"

และใช้ข้อความภาษาไทยทั่วไปอีกชุดเป็น replay data เพื่อกันการลืม

from datasets import load_dataset

domain = load_dataset("pythainlp/thaigov-v2-corpus-22032023", split="train")
domain = domain.shuffle(seed=42).select(range(8000))

Packing: อย่าปล่อยให้ padding กินงบ​

ถ้าเอาแต่ละเอกสารมา pad ให้ยาวเท่ากัน คุณจะเสีย compute ไปกับ <pad> มหาศาล วิธีที่ถูกคือ ต่อทุกเอกสารเข้าด้วยกันแล้วหั่นเป็นบล็อกยาว 512 token เท่า ๆ กัน

def pack(examples, block_size=512):
    ids = []
    for text in examples["context"]:
        ids.extend(tokenizer(text + tokenizer.eos_token).input_ids)
    n = (len(ids) // block_size) * block_size
    return {"input_ids": [ids[i:i+block_size] for i in range(0, n, block_size)]}

7. โค้ดหลัก (Main code)​

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer

model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-0.6B-Base",           # base ไม่ใช่ instruct — CPT ต้องเริ่มจาก base
    torch_dtype=torch.float16,        # T4 ไม่มี bf16
    attn_implementation="sdpa",       # T4 ไม่มี FlashAttention-2
).cuda()

model = model.float()                 # ต้อง cast เป็น fp32 ก่อนเทรน — ดูกล่องด้านล่าง

args = TrainingArguments(
    output_dir="cpt-out",
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,    # effective batch = 16
    num_train_epochs=1,
    learning_rate=2e-5,               # ต่ำกว่า SFT 10 เท่า — ดูคำเตือนด้านล่าง
    lr_scheduler_type="cosine",
    warmup_steps=50,
    optim="adamw_bnb_8bit",           # ประหยัด 3.3 GB
    gradient_checkpointing=True,
    max_grad_norm=1.0,                # กัน fp16 ระเบิด
    fp16=True,                        # ไม่ใช่ bf16
    logging_steps=10,
)

ValueError: Attempting to unscale FP16 gradients.

8. ผลลัพธ์ (Results)​

โน้ตบุ๊กจะวัด 3 อย่างก่อนและหลังเทรน แล้วเขียนลง results.json:

1. Domain held-out PPL — ควรลดลงชัดเจน (นี่คือสิ่งที่เราจ่ายเงินซื้อ)
2. General held-out PPL — ควรเพิ่มขึ้นบ้าง (นี่คือราคาที่จ่าย)
3. TH-KNOW accuracy จากชุดวัด KobEval-TH พร้อม Wilson 95% CI

9. เปรียบเทียบ (Comparison)​

โน้ตบุ๊กเทรน 3 แบบบนข้อมูลชุดเดียวกัน เพื่อให้เห็นการแลกเปลี่ยนเป็นตัวเลข:

อ่านตารางนี้ให้ออกคือหัวใจของบทนี้:

• λ = 1.0 ชนะ domain PPL (4.07 ต่ำสุด) แต่ general PPL แย่ลง จาก 5.88 เป็น 6.72 — นี่คือ catastrophic forgetting ที่วัดออกมาเป็นตัวเลขได้จริง ไม่ใช่คำเล่าลือ
• λ = 0.5 ยอมเสีย domain นิดหน่อย (4.29) แต่ general กลับดีขึ้น เป็น 4.98 — replay ไม่ได้แค่กันลืม มันช่วยให้โมเดลอ่านภาษาไทยทั่วไปดีขึ้นด้วย

10. สรุป (Summary)​

• CPT ใส่ความรู้เข้าไปในน้ำหนัก ด้วย objective เดียวกับ pretraining ไม่ต้องมี label
• มันคือการแลกเปลี่ยนเสมอ ความแม่นในโดเมนแลกมาด้วยความสามารถทั่วไปที่หายไป
• replay ratio $\lambda$ คือปุ่มควบคุมอัตราแลกเปลี่ยน — กวาดหาค่า อย่าเดา
• learning rate ต่ำ ๆ คือเส้นแบ่งระหว่าง CPT กับการทำลายโมเดล
• ทุกตัวเลขต้องมาพร้อม confidence interval

บทต่อไป: SFT และ LoRA — เมื่อโมเดลมีความรู้แล้ว เราจะสอนให้มันตอบอย่างไร และทำไมการเทรนแค่ 1.7% ของพารามิเตอร์ถึงเกือบดีเท่าเทรนทั้งหมด

อ้างอิง (References)​

1. Gururangan et al. (2020). Don't Stop Pretraining: Adapt Language Models to Domains and Tasks — ต้นตำรับของ domain-adaptive pretraining ที่บทนี้ทำตาม
2. Ibrahim et al. (2024). Simple and Scalable Strategies to Continually Pre-train Large Language Models — กลยุทธ์ replay และ LR ที่ทำให้ CPT ไม่ทำลายโมเดล
3. Gupta et al. (2023). Continual Pre-Training of Large Language Models: How to (re)warm your model? — ทำไม learning rate warmup ถึงสำคัญมากตอนเทรนต่อ
4. Luo et al. (2023). An Empirical Study of Catastrophic Forgetting in Large Language Models During Continual Fine-tuning — การวัด catastrophic forgetting อย่างเป็นระบบ
5. Kaplan et al. (2020). Scaling Laws for Neural Language Models — scaling laws -- ที่มาของคำว่า "ข้อมูล 8,000 ชิ้นน้อยเกินไป"
6. Hoffmann et al. (2022). Training Compute-Optimal Large Language Models — Chinchilla: สัดส่วนข้อมูลต่อพารามิเตอร์ที่เหมาะสม
7. Yuenyong et al. (2025). OpenThaiGPT 1.6 and R1: Thai-Centric Open Source and Reasoning Large Language Models — CPT ภาษาไทยระดับจริง เทียบกับสเกลของบทนี้
8. Lowphansirikul et al. (2021). WangchanBERTa: Pretraining transformer-based Thai Language Models — โมเดลภาษาไทยรุ่นบุกเบิกและวิธีเตรียมคอร์ปัสไทย

บทความ โค้ด และโน้ตบุ๊กในซีรีส์นี้เผยแพร่ภายใต้สัญญาอนุญาต CC BY-NC-SA 4.0 — นำไปใช้และดัดแปลงต่อได้ โดยอ้างอิงที่มา ไม่ใช้เพื่อการค้า และเผยแพร่ต่อด้วยสัญญาเดียวกัน (โมเดลและชุดข้อมูลของบุคคลที่สามที่อ้างถึง ยังคงใช้สัญญาของเจ้าของเดิม)

1. ปัญหา (Problem statement)​

เอาโมเดล base แท้ ๆ อย่าง Qwen3-0.6B-Base จากบทที่แล้วมาพิมพ์ใส่ว่า "ช่วยแนะนำอาหารไทยให้หน่อยครับ" สิ่งที่ได้กลับมามักไม่ใช่คำตอบ แต่เป็นการเขียนต่อ — มันอาจแต่งคำถามเพิ่มอีกสามข้อ เขียนต่อเป็นบทความท่องเที่ยว หรือเปลี่ยนไปเป็นภาษาอังกฤษกลางทาง เพราะสิ่งเดียวที่มันเคยถูกเทรนคือ "ข้อความแบบนี้บนอินเทอร์เน็ต มักตามด้วยอะไร"

ความสามารถในการตอบ — รับคำสั่ง ตอบตรงประเด็น แล้วหยุด — ไม่ได้มากับ pretraining มันมาจาก SFT: การเทรนต่อด้วยคู่ (คำสั่ง, คำตอบที่ดี) หลายพันถึงหลายล้านคู่ โมเดล instruct ทุกตัวที่คุณเคยใช้ ล้วนผ่านขั้นนี้มาแล้วทั้งนั้น

แต่พอจะลงมือทำเอง จะเจอปัญหาซ้อนอยู่สองชั้น:

ชั้นแรก — ต้นทุนของ full fine-tuning ถ้าเทรนทุกพารามิเตอร์ คุณจะได้โมเดลใหม่ทั้งก้อน (~1.2 GB ต่อหนึ่งงานสำหรับโมเดล 0.6B) องค์กรที่มีสิบงาน — สรุปเอกสาร, ร่างจดหมาย, ตอบลูกค้า, จัดหมวดเรื่องร้องเรียน — ต้องเก็บสิบสำเนา และการขยับน้ำหนักทุกตัวด้วย learning rate สูง ๆ คือสูตรลบความรู้ที่เพิ่งใส่ไปในบทที่ 1 (จำกล่อง learning rate ได้ไหมครับ)

ชั้นที่สอง — ภาษาไทย แม้แต่ตัวที่ผ่านการ post-train มาแล้วอย่าง Qwen3-0.6B ก็ยังมีอาการที่เราเห็นซ้ำ ๆ ทั้งซีรีส์: ถามเป็นไทย แล้วคำตอบไหลไปเป็นภาษาอังกฤษกลางประโยค (นี่คือที่มาของ metric th_ratio ประจำซีรีส์) เพราะข้อมูล SFT ที่มันเคยเห็นเป็นภาษาอังกฤษเป็นหลัก

บทนี้แก้ทั้งสองชั้นพร้อมกัน: SFT ด้วยข้อมูลคำสั่งภาษาไทย และทำผ่าน LoRA แทน full fine-tuning

2. เราจะทำอะไร (Solution)​

เราจะเอา Qwen3-0.6B มาเทรนด้วยคู่คำสั่ง-คำตอบภาษาไทย 4,000 ตัวอย่าง โดยใช้ loss ตัวเดียวกับบทที่ 1 เป๊ะ ๆ บวกของใหม่สองชิ้น:

1. Completion mask — คิด loss เฉพาะ token ฝั่งคำตอบ ไม่คิดฝั่งคำถาม (หัวข้อ 3.1 จะอธิบายว่าทำไมข้ามข้อนี้แล้วพังแบบตลก ๆ)
2. LoRA (Low-Rank Adaptation) — แช่แข็งน้ำหนักเดิมทั้งหมด แล้วเทรนเมทริกซ์เล็ก ๆ สองตัวที่วางทับแต่ละเลเยอร์แทน

3. สมการ (Equation)​

3.1 SFT loss กับ completion mask​

• $(x, y)$ = ตัวอย่างหนึ่งคู่ — $x$ คือส่วนคำสั่ง (รวม chat template) และ $y$ คือลำดับ token ของตัวอย่างที่โมเดลเห็นจริงตอนเทรน
• $y_t$ = token ตำแหน่งที่ $t$ และ $y_{<t}$ = token ทั้งหมดก่อนหน้า
• $p_\theta$ = ความน่าจะเป็นที่โมเดลพารามิเตอร์ $\theta$ ทำนาย
• $m_t \in \{0,1\}$ = completion mask — เป็น 1 เฉพาะ token ฝั่งคำตอบ และเป็น 0 บน token ของ prompt

ลองถอด $m_t$ ออก (คือตั้ง $m_t \equiv 1$ ทุกตำแหน่ง) สมการนี้จะกลายเป็น objective ของ CPT ในบทที่ 1 ทันที SFT คือ CPT บนข้อความที่ถูกจัดฉากเป็นบทสนทนา บวกกับ mask หนึ่งตัว — ไม่มีอะไรมากกว่านั้น

แต่ mask หนึ่งตัวนี้คือครึ่งหนึ่งของความสำเร็จ เพราะ $m_t \equiv 1$ คือ default ที่พลาดกันง่ายที่สุด (หลาย pipeline รวมถึง SFTTrainer ถ้าไม่ใส่ collator ให้ถูก จะเทรนแบบนี้เงียบ ๆ) และในข้อมูลคำสั่งภาษาไทยทั่วไป token ฝั่ง prompt กินราว 60% ของตัวอย่าง แปลว่า gradient ส่วนใหญ่ของคุณกำลังสอนโมเดลให้หัดเขียนคำถามของผู้ใช้ ไม่ใช่หัดตอบ ผลข้างเคียงที่ตามมาจะได้เห็นในหัวข้อ 9

3.2 LoRA: เทรนส่วนแก้ ไม่ใช่น้ำหนัก​

แทนที่จะอัปเดตเมทริกซ์น้ำหนัก $W_0$ ตรง ๆ LoRA ตรึง $W_0$ ไว้ แล้วเรียนรู้ส่วนต่างที่เป็นผลคูณของเมทริกซ์เล็กสองตัว:

• $W_0 \in \mathbb{R}^{d\times k}$ = น้ำหนักเดิมของเลเยอร์ ถูกแช่แข็ง ไม่รับ gradient เลย
• $B \in \mathbb{R}^{d\times r}$ และ $A \in \mathbb{R}^{r\times k}$ = เมทริกซ์ adapter สองตัวที่เราเทรนจริง
• $r \ll \min(d, k)$ = rank ของส่วนแก้ — ปุ่มหลักของ LoRA (บทนี้ใช้ $r = 16$)
• $\alpha$ = ตัวคูณ scale — ผลคูณ $BA$ ถูกคูณด้วย $\alpha/r$ เสมอ (บทนี้ $\alpha = 32$ ดังนั้น $\alpha/r = 2$)

รายละเอียดสองข้อในนิยามนี้สำคัญกว่าที่หน้าตามันบอก:

$B$ ถูก initialize เป็นศูนย์ทั้งเมทริกซ์ ดังนั้น $\Delta W = 0$ ณ step แรก — การเทรนเริ่มจากโมเดล base เป๊ะ ๆ ไม่มีช่วงที่โมเดลถูกรบกวนด้วยน้ำหนักสุ่มเลย (ส่วน $A$ เป็น Gaussian สุ่ม — ถ้าตั้งศูนย์ทั้งคู่ gradient ของทั้งคู่จะเป็นศูนย์ตลอดกาล เพราะต่างฝ่ายต่างคูณกับศูนย์)

ตัวหาร $r$ ใน $\alpha/r$ ทำให้ขนาดของ update ไม่ขึ้นกับ rank — เพิ่ม $r$ เป็นสองเท่า ผลรวม $BA$ มีพจน์มากขึ้นสองเท่า แต่ถูกหารกลับพอดี คุณจึงกวาดหา $r$ ได้โดยไม่ต้องจูน learning rate ใหม่ทุกครั้ง

และเมื่อเทรนเสร็จ คุณเลือกได้สองทาง: merge ($W' = W_0 + \frac{\alpha}{r}BA$ แล้วได้โมเดลเดียวที่ไม่มี latency เพิ่ม) หรือเก็บแยก — ทางที่สองคือทางที่ซีรีส์นี้เลือก เพราะ adapter ที่ถอด-ใส่ได้คือสิ่งที่บทที่ 4 ใช้สร้าง reference model ฟรี ๆ

3.3 สัดส่วนพารามิเตอร์ที่เทรน — ตัวเลขที่ต้องเช็ค ไม่ใช่ท่อง​

ต่อเมทริกซ์ขนาด $d \times k$ หนึ่งตัว adapter มีพารามิเตอร์ $rd + rk$ ตัว คิดเป็นสัดส่วน

• $d, k$ = มิติของเมทริกซ์น้ำหนักเดิม
• $r$ = rank ของ adapter

ลองแทนค่าจริงของ Qwen3-0.6B (hidden 1024, intermediate 3072, 28 เลเยอร์ ติด adapter ทั้ง 7 เมทริกซ์: q, k, v, o, gate, up, down) จะได้พารามิเตอร์ที่เทรนได้ 10,092,544 ตัว จากฐาน 596,049,920 ตัว = 1.69%

4. เห็นภาพสมการ (Visualize)​

mask หนึ่งตัว เปลี่ยนทิศของ gradient ทั้งก้อน​

ภาพนี้ไม่มีอะไรลึกไปกว่าการนับ token แต่การนับนี่แหละที่คนข้าม: prompt ภาษาไทย (รวม system message กับ chat template) มักยาวกว่าคำตอบ พอเทรนโดยไม่ mask คุณจึงจ่าย compute ส่วนใหญ่ไปกับการสอนสิ่งที่ไม่ได้อยากได้ โน้ตบุ๊กพิมพ์สัดส่วนจริงของชุดข้อมูลที่สุ่มมาให้ดูด้วย — ตัวเลข 60/40 ในภาพคือค่าแทนตัวอย่างทั่วไป ไม่ใช่ค่าคงที่ศักดิ์สิทธิ์

ทำไม rank 16 ถึง "พอ" — สมมติฐาน low-rank​

สมมติฐานของ LoRA (Hu และคณะ, 2021) คือ: การ fine-tune ขยับน้ำหนักในทิศทางสำคัญเพียงไม่กี่ทิศ เมื่อเทียบกับมิติเต็มของเมทริกซ์ ภาพนี้สร้าง $\Delta W$ ปลอมที่มีโครงสร้างแบบนั้นเป๊ะ ๆ (สัญญาณ rank 16 + noise) แล้วให้ SVD ค้นมันกลับขึ้นมา — ถ้า update จริงหน้าตาแบบนี้ adapter rank 16 ก็เก็บเนื้อหาไว้ได้เกือบหมด สิ่งที่ภาพนี้ไม่ได้พิสูจน์คือ update จริงหน้าตาแบบนี้เสมอ นั่นเป็นข้อค้นพบเชิงประจักษ์ของงานวิจัย และเป็นเหตุผลที่ LoRA "มักจะ" เกือบเท่า full fine-tuning ไม่ใช่ "เสมอ"

เช็คตัวเลข ไม่ใช่ท่องตัวเลข​

เส้นตรงบนแกน log-log ยืนยันสิ่งที่สมการบอก: สัดส่วนโตเชิงเส้นกับ $r$ เป๊ะ ๆ และบนโมเดลตัวนี้ "ต่ำกว่า 1%" จะเป็นจริงก็ต่อเมื่อ $r \le 9$ เท่านั้น ซึ่งไม่ใช่ค่าที่ใครใช้กันจริงกับงานภาษา — จุดที่เราใช้ ($r=16$) คือ 1.69% หรือราว 40 MB เมื่อเก็บเป็น fp32

5. เตรียมสภาพแวดล้อม (Environment)​

เปิด Colab เลือก Runtime → Change runtime type → T4 GPU (แผนฟรีพอ)

torch_dtype=torch.float16      # ไม่ใช่ bfloat16
attn_implementation="sdpa"     # ไม่ใช่ flash_attention_2
fp16=True                      # ใน SFTConfig (ไม่ใช่ bf16=True)

cap = torch.cuda.get_device_capability(0)
print("compute capability:", cap)                    # T4 = (7, 5)
print("native bf16:", cap[0] >= 8)                   # T4 -> False
print("torch says   :", torch.cuda.is_bf16_supported())  # T4 -> True (นับ emulation!)

for p in model.parameters():
    if p.requires_grad:
        p.data = p.data.float()      # cast เฉพาะ adapter — ไม่ใช่ทั้งโมเดล

งบ VRAM ที่เปลี่ยนโฉมไปเลยเมื่อใช้ LoRA​

จำได้ไหมว่าบทที่ 1 optimizer state ของ Adam กินที่มากกว่าตัวโมเดล (ราว 4.4 GB สำหรับ $m$ กับ $v$) พอเทรนแค่ adapter, Adam ก็เก็บ state แค่ 10.1 ล้านพารามิเตอร์ — ประมาณ 0.08 GB จนไม่ต้องพึ่ง adamw_bnb_8bit อีกต่อไป งบก้อนใหญ่ที่เหลือคือน้ำหนัก base (fp16, ~1.2 GB) กับ activations

ลองสลับระหว่าง full fine-tuning กับ LoRA rank ต่าง ๆ ในเครื่องคิดเลขดูว่างบเปลี่ยนตรงไหน:

6. เตรียมข้อมูล (Data)​

เราใช้ airesearch/wangchanx-seed-free-synthetic-instruct-thai-120k — ชุดคำสั่ง-คำตอบภาษาไทยแบบ synthetic 120,000 คู่ จากทีม WangchanX (สุ่มมาใช้ 4,000)

from datasets import load_dataset

ds = load_dataset("airesearch/wangchanx-seed-free-synthetic-instruct-thai-120k", split="train")
ds = ds.shuffle(seed=42).select(range(4000))

def to_text(ex):
    messages = [
        {"role": "user", "content": ex["instruction"]},   # เช็คชื่อคอลัมน์จาก dataset card เสมอ
        {"role": "assistant", "content": ex["output"]},
    ]
    return {"text": tok.apply_chat_template(messages, tokenize=False,
                                            enable_thinking=False)}

train_ds = ds.map(to_text, remove_columns=ds.column_names)

สองบรรทัดที่ควรอ่านช้า ๆ:

• apply_chat_template ประกอบข้อความเป็นรูปแบบที่ Qwen3 ถูกเทรนมา (<|im_start|>user … <|im_end|> …) เราเรียกมันครั้งเดียว ที่นี่ที่เดียว — เหตุผลอยู่ในกับดักข้อ 2 ของหัวข้อ 9
• enable_thinking=False ปิดโหมด thinking ของ Qwen3 เพื่อให้ตัวอย่างในบทนี้เรียบง่ายและ mask ตรงไปตรงมา

แล้วทำพิธีที่ควรเป็นนิสัย: decode ตัวอย่างแรกออกมาดูด้วยตาเสมอ

print(train_ds[0]["text"][:400])
# ต้องเห็น <|im_start|>user ... <|im_end|> ... <|im_start|>assistant ... อย่างละครั้งเดียวต่อ turn

โน้ตบุ๊กยังพิมพ์สถิติความยาว token ของชุดที่สุ่มมา: median ฝั่ง prompt เทียบฝั่งคำตอบ และสัดส่วนตัวอย่างที่ยาวเกิน 768 token — ตัวเลขตัวหลังนี้จะกลับมาทวงบุญคุณในกับดักข้อ 3

7. โค้ดหลัก (Main code)​

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer, SFTConfig, DataCollatorForCompletionOnlyLM

tok = AutoTokenizer.from_pretrained("Qwen/Qwen3-0.6B")

model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-0.6B",                # ตัว post-trained — บทนี้เราแก้พฤติกรรม ไม่ได้สอนความรู้
    torch_dtype=torch.float16,        # T4 ไม่มี bf16
    attn_implementation="sdpa",       # T4 ไม่มี FlashAttention-2
).cuda()

lora = LoraConfig(
    r=16,
    lora_alpha=32,                    # α/r = 2 — ดูสมการ 3.2
    lora_dropout=0.05,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                    "gate_proj", "up_proj", "down_proj"],
    task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora)
model.print_trainable_parameters()    # เชื่อบรรทัดนี้ ไม่ใช่ตัวเลขในบล็อกไหนทั้งนั้น

for p in model.parameters():          # กล่อง fp16 ในหัวข้อ 5
    if p.requires_grad:
        p.data = p.data.float()

ต่อไปคือชิ้นที่แปลงสมการ 3.1 เป็นโค้ด — collator ที่ทำหน้าที่เป็น $m_t$:

collator = DataCollatorForCompletionOnlyLM(
    response_template="<|im_start|>assistant\n",   # ทุกอย่างก่อนหน้านี้ = prompt
    tokenizer=tok,
)

collator ตัวนี้ตั้ง label ของ token ทุกตัวก่อน <|im_start|>assistant เป็น -100 ซึ่งเป็นค่าที่ loss function ของ PyTorch ข้ามให้ — ค่าเดียวกับที่บทที่ 4 ใช้ mask ฝั่ง prompt ในฟังก์ชัน seq_logp นั่นแหละครับ mask ตัวเดียวกัน โผล่มาคนละบท

cfg = SFTConfig(
    output_dir="sft-out",
    dataset_text_field="text",
    max_seq_length=768,               # โน้ตบุ๊กพิมพ์จำนวนตัวอย่างที่โดนตัด — กับดักข้อ 3
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,    # effective batch = 16
    num_train_epochs=1,
    learning_rate=2e-4,               # LoRA รับไหว — full FT ที่ค่านี้คือหายนะ (บทที่ 1)
    lr_scheduler_type="cosine",
    warmup_ratio=0.03,
    packing=False,                    # completion mask ใช้กับ packing ตรง ๆ ไม่ได้
    fp16=True,                        # T4: ไม่ใช่ bf16
    logging_steps=10,
)

trainer = SFTTrainer(
    model=model,
    args=cfg,
    train_dataset=train_ds,
    data_collator=collator,
    processing_class=tok,
)
trainer.train()                       # ~11 นาทีบน T4

เทรนเสร็จ เซฟเฉพาะส่วนแก้:

model.save_pretrained("qwen3-0.6b-th-sft-lora")   # ~40 MB — ไม่ใช่ 1.2 GB

adapter ตัวนี้แหละที่บทที่ 4 โหลดในชื่อ kobkrit/qwen3-0.6b-th-sft-lora เพื่อเป็นทั้ง policy ตั้งต้นและ (เมื่อปิด adapter) reference model — ของขวัญข้ามบทที่ราคา 40 MB

8. ผลลัพธ์ (Results)​

โน้ตบุ๊กวัด 3 อย่างก่อนและหลังเทรน แล้วเขียนลง results.json:

1. TH-INSTR — สัดส่วนคำตอบที่ผ่านเกณฑ์ rubric การทำตามคำสั่ง (ตอบตรงคำถาม จบด้วยตัวเอง อยู่ในบทบาท) จากชุดวัด KobEval-TH พร้อม Wilson 95% CI
2. th_ratio — สัดส่วนอักขระไทยในคำตอบ metric ประจำซีรีส์ Qwen3-0.6B ตั้งต้นขึ้นชื่อเรื่องไหลเป็นอังกฤษบน prompt ไทย การ SFT ด้วยข้อมูลไทยล้วน 4,000 ตัวอย่าง ควรขยับตัวเลขนี้ให้เห็นชัด — และถ้าไม่ขยับ นั่นคือสัญญาณให้ไปไล่ดู mask กับ template ก่อนสิ่งอื่น
3. สัดส่วนคำตอบที่จบด้วย eos ภายในงบ token — ตัวจับอาการ "ไม่ยอมหยุด" จากกับดักข้อ 1 และ 3

9. เปรียบเทียบ (Comparison)​

โน้ตบุ๊กเทรน 3 แบบบนข้อมูลชุดเดียวกัน แล้ววัดเทียบกับโมเดลตั้งต้น:

รูปแบบที่คุณควรจะเห็น: แถว LoRA + mask ตาม full fine-tuning มาติด ๆ ทั้งสอง metric (นี่คือประเด็นทั้งบท — จ่าย 1.69% ได้ของเกือบเท่า 100%) ขณะที่ full FT จ่ายทั้ง VRAM เวลา และพื้นที่เก็บมากกว่ากันมาก

ส่วนแถวสุดท้ายคือดาราของหัวข้อนี้ อาการทั่วไปของมันหน้าตาประมาณนี้:

ผู้ใช้:   สรุปขั้นตอนการต่อภาษีรถยนต์ประจำปีให้หน่อย
โมเดล:  ขั้นตอนมีดังนี้ 1) เตรียม พ.ร.บ. ... 2) ... 3) ... ครับ
        แล้วถ้าภาษีขาดเกิน 3 ปีต้องทำอย่างไร?   ← ตอบเสร็จแล้ว "แต่งคำถามต่อ" เอง

ไม่ใช่ bug ลึกลับอะไรเลย — ย้อนดูรูปที่ 2.1: gradient 60% ของมันถูกใช้หัดเขียนคำถามผู้ใช้ โมเดลจึงเรียน "บทสนทนาทั้งม้วน" แทนที่จะเรียน "บทบาทผู้ตอบ" พอถึงเวลา inference มันตอบจบแล้วก็ทำสิ่งที่ถูกเทรนมาต่อ: เปิดคำถามข้อถัดไป ค่า th_ratio ของแถวนี้อาจดูดีด้วยซ้ำ (มันเขียนไทยทั้งคู่!) — ตัวที่จับอาการนี้ได้คือ TH-INSTR กับการอ่านตัวอย่างจริง

กับดักที่ต้องระวัง​

1. tokenizer.pad_token = tokenizer.eos_token — บรรทัดที่ถูก copy ต่อกันมากที่สุดในวงการ กับ tokenizer ที่ไม่มี pad token (เช่นตระกูล Llama) บรรทัดนี้จำเป็น แต่มันมีราคาแอบแฝง: collator จะ mask ตำแหน่งที่เป็น padding ออกจาก loss โดยดูจาก id พอ pad กับ eos เป็น token เดียวกัน eos จริง ๆ ท้ายคำตอบก็โดน mask ไปด้วย โมเดลจึงไม่เคยถูกสอนให้ "พูดจบ" — อาการคือคำตอบยาวไปเรื่อย ๆ จนชนงบ token Qwen3 มี pad (<|endoftext|>) แยกจาก eos (<|im_end|>) อยู่แล้ว — อย่าเอาบรรทัดนี้จาก tutorial อื่นมาเขียนทับ

2. ใส่ chat template ซ้ำสองรอบ เกิดเมื่อข้อมูลถูก template มาแล้ว แล้วคุณ (หรือ SFTTrainer บางเวอร์ชัน) ไป template ซ้ำอีกชั้น อาการที่เห็นคือ <|im_start|> ซ้อนสองชั้นที่ทุกรอยต่อของ turn โมเดลที่เทรนบนข้อมูลแบบนี้จะเรียนว่าคำตอบต้องขึ้นต้นด้วย token ประหลาด แล้วผลิตมันออกมาตอน inference ด้วย พิธี print(train_ds[0]["text"]) ในหัวข้อ 6 มีไว้จับเรื่องนี้โดยเฉพาะ — สามวินาทีที่คุ้มที่สุดของทั้งโน้ตบุ๊ก

3. truncation กลางคำตอบ สอนโมเดลว่าไม่ต้องหยุด ตัวอย่างที่ยาวเกิน max_seq_length=768 จะถูกตัดท้ายทิ้ง — และท้ายที่ถูกตัดคือ <|im_end|> ของคำตอบ โมเดลจึงได้เห็นตัวอย่างที่ "คำตอบดี ๆ ไม่ต้องจบก็ได้" ปนเข้ามาใน gradient ทางแก้ตรงไปตรงมา: กรองตัวอย่างที่เกินงบทิ้งก่อนเทรน หรือเพิ่ม max_seq_length ถ้า VRAM พอ โน้ตบุ๊กพิมพ์จำนวนตัวอย่างที่โดนตัดให้ดูก่อนเทรนเสมอ — ถ้าเลขนั้นเกินหลักหน่วยเปอร์เซ็นต์ ให้จัดการก่อนกด train

4. fp16 แล้วลืม cast adapter เป็น fp32 อาการ: ValueError: Attempting to unscale FP16 gradients. ตั้งแต่ step แรก วิธีแก้อยู่ในกล่องหัวข้อ 5 — cast เฉพาะพารามิเตอร์ที่ requires_grad ไม่ใช่ model.float() ทั้งก้อนแบบบทที่ 1 (ถ้า cast ทั้งก้อน โค้ดรันได้เหมือนกัน แต่คุณเสีย VRAM ของ base เพิ่มอีกเท่าตัวโดยไม่ได้อะไรกลับมา)

10. สรุป (Summary)​

• SFT คือ CPT บนบทสนทนา + completion mask — loss ตัวเดิมจากบทที่ 1 สิ่งที่เปลี่ยนคือข้อมูลถูกจัดฉาก และ mask เลือกว่า token ไหนนับ
• mask คือครึ่งหนึ่งของความสำเร็จ — $m_t \equiv 1$ ทำให้ 60% ของ gradient ไปหัดเขียนคำถาม และได้โมเดลที่ตอบเสร็จแล้วแต่งคำถามต่อเอง
• LoRA เทรน "ส่วนแก้" ไม่ใช่น้ำหนัก: $W' = W_0 + \frac{\alpha}{r}BA$ โดย $B$ เริ่มจากศูนย์ การเทรนจึงออกตัวจาก base เป๊ะ ๆ และ $\alpha/r$ ทำให้เปลี่ยน rank ได้โดยไม่จูน lr ใหม่
• 1.69% ไม่ใช่ "ต่ำกว่า 1%" — adapter โตเชิงเส้นกับ hidden size แต่ base โตกำลังสอง โมเดลเล็ก adapter จึงเป็นสัดส่วนใหญ่กว่า เช็คจาก print_trainable_parameters() เสมอ
• adapter ~40 MB ต่องาน: base ตัวเดียว + adapter หลายตัว และมันคือเหตุผลที่ reference model ของบทที่ 4 ได้มาฟรี
• lr 2e-4 ปลอดภัยเพราะ base ถูกแช่แข็ง — ค่าเดียวกันนี้ทำลายโมเดลถ้าเทรนเต็มตัว
• pad ≠ eos, template ครั้งเดียว, อย่าปล่อยให้ตัดกลางคำตอบ — สามกับดักที่อาการโผล่ตอน inference แต่ต้นเหตุอยู่ในข้อมูล

บทต่อไป: RLHF และ PPO — โมเดลตอบเป็นแล้ว แต่ "ตอบดี" เขียนเป็น loss function ไม่ได้ เราจะให้มนุษย์เปรียบเทียบคำตอบ เทรน reward model จากความชอบนั้น แล้วใช้ reinforcement learning ดันโมเดลเข้าหามัน — โดยมี adapter 40 MB จากบทนี้เป็นจุดตั้งต้น

อ้างอิง (References)​

1. Hu et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models — สมการ W' = W₀ + (α/r)BA ในหัวข้อ 3 มาจากเปเปอร์นี้
2. Aghajanyan et al. (2020). Intrinsic Dimensionality Explains the Effectiveness of Language Model Fine-Tuning — หลักฐานว่าการปรับโมเดลมี intrinsic dimension ต่ำ -- เหตุผลว่าทำไม LoRA ได้ผล
3. Dettmers et al. (2023). QLoRA: Efficient Finetuning of Quantized LLMs — ต่อยอด LoRA ด้วย 4-bit ให้เทรนโมเดลใหญ่บน GPU ตัวเดียว
4. Biderman et al. (2024). LoRA Learns Less and Forgets Less — LoRA แลกความจำได้น้อยลงกับการลืมน้อยลง -- อ่านคู่กับหัวข้อ 9
5. Ouyang et al. (2022). Training language models to follow instructions with human feedback — InstructGPT: ต้นแบบของ pipeline SFT -> RM -> PPO ทั้งหมด
6. Wang et al. (2022). Self-Instruct: Aligning Language Models with Self-Generated Instructions — วิธีสร้างชุดข้อมูล instruction จากโมเดลเอง
7. Zhou et al. (2023). LIMA: Less Is More for Alignment — ข้อมูลคุณภาพสูงไม่กี่พันตัวอย่างก็พอ -- เหตุผลที่เราใช้แค่ 4,000

บทความ โค้ด และโน้ตบุ๊กในซีรีส์นี้เผยแพร่ภายใต้สัญญาอนุญาต CC BY-NC-SA 4.0 — นำไปใช้และดัดแปลงต่อได้ โดยอ้างอิงที่มา ไม่ใช้เพื่อการค้า และเผยแพร่ต่อด้วยสัญญาเดียวกัน (โมเดลและชุดข้อมูลของบุคคลที่สามที่อ้างถึง ยังคงใช้สัญญาของเจ้าของเดิม)

1. ปัญหา (Problem statement)​

SFT ในบทที่ 2 มีสมมติฐานซ่อนอยู่หนึ่งข้อ: ต้องมีเฉลยให้เลียนแบบ แต่ลองนึกถึงสิ่งที่เราอยากได้จริง ๆ เช่น "ตอบโจทย์เลขให้ถูก และอธิบายเป็นภาษาไทยที่อ่านรู้เรื่อง" ประโยคนี้ไม่มีเฉลยเดียว คำตอบที่ดีมีได้ร้อยแบบ และคำว่า "อ่านรู้เรื่อง" ก็เขียนเป็นสมการไม่ออก

พอพยายามจะ optimize สิ่งเหล่านี้ตรง ๆ เราจะชนกำแพงสองชั้นเสมอ:

กำแพงที่หนึ่ง — คุณภาพเขียนเป็น loss ไม่ได้ "ดีกว่า" นิยามเป็นฟังก์ชันไม่ได้ แต่มนุษย์เปรียบเทียบได้เก่งมาก ให้ดูคำตอบสองอันแล้วชี้ว่าชอบอันไหน ทำได้ทันทีและตรงกันพอสมควร ข้อมูลที่เก็บได้จริงจึงเป็นสามสิ่ง: prompt $x$, คำตอบที่ถูกเลือก $y_w$, คำตอบที่ถูกปัด $y_l$

กำแพงที่สอง — ต่อให้มีคะแนน ก็ backprop ไม่ได้ สมมติมีฟังก์ชันวิเศษ $r(x,y)$ ให้คะแนนทุกคำตอบ คุณก็ยังเทรนแบบ supervised ไม่ได้อยู่ดี เพราะคำตอบ $y$ เกิดจากการสุ่ม token ทีละตัว คะแนนมาถึงหลังการสุ่มจบแล้ว และอนุพันธ์เดินทางย้อนผ่านการสุ่มไม่ได้ — เส้นทางจาก $r$ กลับไปหา weights $\theta$ ขาดตอนตรงนั้นพอดี

นี่คือที่มาของชื่อบท: เรากำลังจะ optimize รางวัลที่หาอนุพันธ์ไม่ได้ เครื่องมือที่ทำแบบนั้นได้ชื่อว่า reinforcement learning

2. เราจะทำอะไร (Solution)​

RLHF แก้กำแพงทั้งสองชั้นด้วยการเดินสองขั้น:

• Stage A — Reward Model: เทรนโมเดล $r_\phi(x,y)$ ให้เลียนแบบการเปรียบเทียบของมนุษย์จากคู่ preference (แก้กำแพงที่หนึ่ง และแทนมนุษย์ที่ให้คะแนนไม่ทัน)
• Stage B — PPO: ใช้ policy-gradient RL ดัน policy ไปหาคะแนนของ $r_\phi$ โดยไม่ต้องหาอนุพันธ์ผ่านการสุ่ม (แก้กำแพงที่สอง) พร้อมสายจูง KL รั้งไม่ให้วิ่งหนีโมเดลตั้งต้น

ราคาที่จ่ายคือความซับซ้อน: ระหว่างเทรนจะมีโมเดลสี่ตัวอยู่ใน VRAM พร้อมกัน — policy $\pi_\theta$ (ตัวที่เทรน), reference $\pi_{\text{ref}}$ (ตัวตั้งต้นที่แช่แข็ง), reward model $r_\phi$ และ value network $V_\psi$ ที่ยังไม่ได้แนะนำตัว (รอหัวข้อ 3.4)

และอีกประโยคที่อยากให้ถือไว้ทั้งซีรีส์: สมการ objective ของบทนี้คือสมการแม่ของครึ่งหลังของซีรีส์ บทที่ 4 (DPO) แก้สมการนี้ในรูปปิดจน reward model และ RL loop ตัดกันหายไป บทที่ 5 (GRPO) เปลี่ยนวิธีประมาณ advantage จน value network หายไป เข้าใจบทนี้บทเดียว อีกสองบทจะกลายเป็น "การลบชิ้นส่วน" ที่อ่านออกทันที

3. สมการ (Equation)​

3.1 Reward model: Bradley–Terry​

Stage A เทรน $r_\phi$ ด้วย loss เดียวสั้น ๆ:

• $r_\phi(x,y)$ = คะแนนสเกลาร์หนึ่งตัวต่อหนึ่งข้อความ — ในทางปฏิบัติคือโมเดลภาษาที่เปลี่ยนหัวเป็น linear ชั้นเดียว (num_labels=1)
• $\sigma$ = sigmoid แปลงผลต่างคะแนนเป็นความน่าจะเป็นที่มนุษย์จะเลือก $y_w$ (โมเดล Bradley–Terry)
• ยิ่งผลต่าง $r_\phi(x,y_w) - r_\phi(x,y_l)$ กว้าง loss ยิ่งต่ำ

จุดที่คนมองข้ามแล้วไปเจ็บตัวทีหลัง: loss นี้เห็นแค่ผลต่างของคะแนน ลองแทน $r_\phi$ ด้วย $r_\phi + c$ ด้วยค่าคงที่ $c$ ใดก็ได้ — loss ไม่เปลี่ยนเลย แปลว่าสเกลสัมบูรณ์ของ reward model ไม่มีความหมายและไม่ถูกกำหนดโดยการเทรน รันสองครั้งอาจได้คะแนนเฉลี่ย 3.7 กับ −12.4 ที่จัดอันดับเหมือนกันเป๊ะ นี่คือเหตุผลที่ต้อง standardize reward ก่อนป้อนเข้า PPO เสมอ (ลบ mean หารด้วย std) — จำจุดนี้ไว้ มันจะกลับมาในหัวข้อ 7 และ 9

3.2 สมการแม่: RLHF objective​

ถ้าทั้งซีรีส์นี้จะท่องจำได้สมการเดียว จงจำสมการนี้:

อ่านเป็นภาษาคน: "เก็บคะแนน reward ให้มากที่สุด แต่ทุกก้าวที่เดินห่างจากโมเดลตั้งต้น ต้องจ่ายค่าปรับ"

• $\pi_\theta$ = policy คือโมเดลที่กำลังเทรน — สังเกตว่า $y$ ถูกสุ่มจาก $\pi_\theta$ เอง นี่คือความต่างเชิงโครงสร้างจาก SFT ที่เรียนจากข้อมูลนิ่ง ๆ ในไฟล์
• $\pi_{\text{ref}}$ = reference คือโมเดลตั้งต้น (โมเดลหลัง SFT จากบทที่ 2) แช่แข็งตลอดการเทรน
• $\beta$ = ราคาต่อหนึ่ง nat ของการเดินห่าง — ความตึงของสายจูง
• $\mathbb{D}_{\text{KL}}$ = ระยะห่างเชิงการกระจายระหว่าง policy กับ reference

3.3 PPO clipped surrogate: เครื่องยนต์ของ Stage B​

policy gradient แบบดิบ (REINFORCE) ใช้ rollout หนึ่งชุดอัปเดตได้ครั้งเดียวแล้วต้องทิ้ง ซึ่งแพงมากเพราะการ generate คือคอขวด PPO อยากรีดค่า rollout ชุดเดิมหลาย epoch จึงต้องมีตัวคูณแก้ทาง (importance sampling ratio):

• $s_t$ = สถานะ ณ ตำแหน่ง $t$ คือ prompt บวก token ที่สุ่มมาแล้วทั้งหมด
• $a_t$ = "การกระทำ" คือ token ตัวถัดไปที่ถูกสุ่มไปแล้วตอน rollout
• $\pi_{\theta_{\text{old}}}$ = snapshot ของ policy ณ ตอน rollout — ค่านี้ถูกคำนวณครั้งเดียวแล้วแช่แข็ง

แล้วหนีบ $\rho_t$ ไว้ด้วย clip:

• $\hat A_t$ = advantage คือ "token นี้ดีกว่าที่คาดไว้เท่าไหร่" (นิยามในข้อถัดไป)
• $\epsilon$ = ความกว้างของ trust region (ค่ามาตรฐาน 0.2)

หัวใจอยู่ที่ min + clip ทำงานร่วมกันแบบมองโลกแง่ร้ายอย่างจงใจ: ถ้า $\hat A_t$ เป็นบวก (token ดี) ผลตอบแทนจากการดัน $\rho_t$ ถูกตัดเพดานที่ $1+\epsilon$ — ดันเกินนั้นไม่ได้อะไรเพิ่ม gradient เป็นศูนย์ แต่ถ้า $\hat A_t$ เป็นลบ (token แย่) ตัว min จะเลือกฝั่งที่แย่กว่าเสมอ — ค่าปรับไม่มีเพดาน สรุปหนึ่งประโยค: ได้จำกัด เสียไม่จำกัด นโยบายจึงขยับทีละก้าวเล็ก ๆ ใกล้ ๆ ตัวเดิม

3.4 GAE: คำนวณ advantage อย่างไรไม่ให้จมน้ำเสียง noise​

advantage สร้างจาก TD error ของ value network $V_\psi$:

• $V_\psi(s_t)$ = value network ทำนายว่า "จากจุดนี้ไปจนจบ จะเก็บ reward ได้อีกเท่าไหร่" — นี่คือโมเดลตัวที่สี่
• $r_t$ = reward ต่อ token (ในงานของเรา: ค่าปรับ KL ทุกตำแหน่ง บวกคะแนนงานที่ token สุดท้าย)
• $\gamma$ = discount factor (งาน LLM มักใช้ 1.0)
• $\lambda$ = ปุ่มหมุน bias–variance: $\lambda = 0$ เชื่อ $V_\psi$ สุดใจ (bias สูงถ้า $V_\psi$ ทำนายพลาด), $\lambda = 1$ ไม่เชื่อเลยและรอดูผลจริงจนจบ (variance สูงเพราะแบก noise ทั้งสาย), ค่าที่นิยมใช้คือ 0.95

3.5 Loss เต็มของ PPO: สามพจน์ สองโมเดล​

รวมทุกชิ้นเป็น loss เดียวที่ optimizer เห็นจริง (เขียนในรูป minimize):

• พจน์แรก = clipped surrogate จากข้อ 3.3 (ติดลบเพราะเราต้องการ maximize)
• พจน์ที่สอง = value loss สอน $V_\psi$ ให้ทายเข้าใกล้ return จริง $\hat R_t$, $c_1$ มักเป็น 0.5
• พจน์ที่สาม = entropy bonus $\mathcal{H}$ กันการกระจายยุบเร็วเกินไป, $c_2$ มักเป็น 0.01
• ส่วนสายจูง KL ของสมการ 3.2 ในทางปฏิบัตินิยมยัดเข้าไปใน reward ต่อ token: $r_t \leftarrow r_t - \beta\,(\log\pi_\theta - \log\pi_{\text{ref}})$ ซึ่งเป็นวิธีที่เราใช้ในหัวข้อ 7

นับของเล่นทั้งหมดที่ต้องจูน: โมเดล 4 ตัว บวก $\epsilon, \beta, \gamma, \lambda, c_1, c_2$ และ learning rate อีกสองชุด นี่คือเหตุผลที่ PPO ขึ้นชื่อว่า "รันสองรอบด้วย seed ต่างกัน ได้ผลคนละเรื่อง" และเป็นเหตุผลการมีอยู่ของบทที่ 4 ทั้งบท

4. เห็นภาพสมการ (Visualize)​

Bradley–Terry: gradient ไปกองอยู่ที่คู่ที่ยังเรียงผิด​

เลือกโหมด Bradley-Terry ในเครื่องมือด้านล่าง แล้วลากค่า margin ดู: คู่ที่ reward model จัดอันดับถูกแล้วอย่างมั่นใจ (margin บวกมาก) แทบไม่เหลือ gradient เลย — การเทรน Stage A ใช้งบไปกับคู่ที่มันยังเรียงผิดโดยอัตโนมัติ

ถ้ากราฟนี้ทำให้นึกถึง gradient ของ DPO ในบทที่ 4 — ไม่ใช่เรื่องบังเอิญ DPO ยกโมเดล Bradley–Terry ตัวนี้ไปใช้ทั้งก้อน แค่เปลี่ยนว่าอะไรทำหน้าที่เป็น reward

Trust region ที่มองเห็นได้: min + clip​

สังเกตความไม่สมมาตรให้ดี มันคือบุคลิกทั้งหมดของ PPO: ขยับเข้าหาสิ่งที่ดี ได้ทีละไม่เกิน 20% แต่ถ้าเผลอให้ความน่าจะเป็นกับ token แย่ ๆ มากไป โดนลากกลับเต็มแรงเสมอ "บริเวณแบน" ในภาพคือ trust region ที่ทำให้ PPO ใช้ rollout เก่าซ้ำหลาย epoch ได้โดยไม่ระเบิด

ปุ่มหมุน bias–variance ของ GAE​

อ่านจากเส้นล่างขึ้นบน: ที่ $\lambda = 0$ (เขียว) advantage เกาะศูนย์เกือบตลอด — คะแนนตอนจบไปไม่ถึง token ต้น ๆ เพราะทุกอย่างถูกกรองผ่าน $V_\psi$ ที่ทายพลาด ที่ $\lambda = 1$ (แดง) ทุก token ได้เครดิตเต็มจากตอนจบ แต่แบก noise สะสมของทั้งสายมาด้วย $\lambda = 0.95$ (น้ำเงิน) คือจุดกลางที่คนทั้งวงการเลือกใช้ — สัญญาณเดินทางไกล แต่ noise ถูกหน่วง

ก่อนไปต่อ ลองสร้างสัญชาตญาณของคำว่า advantage — "ดีกว่าที่คาดเท่าไหร่" — ด้วยมือ: เครื่องมือนี้ใช้ ค่าเฉลี่ยของกลุ่ม เป็น baseline แทน $V_\psi$ (สปอยล์บทที่ 5 แบบเต็ม ๆ) กดชุด All correct แล้วดูว่าเกิดอะไรขึ้นเมื่อทุกคำตอบได้ reward เท่ากัน:

advantage เป็นศูนย์ทั้งกลุ่ม = ไม่มีสัญญาณให้เรียน — จำความรู้สึกนี้ไว้ตอนอ่านหัวข้อ 9

สายจูง KL: สมการ 3.2 วาดเป็นภาพ​

จุดหยุดของเส้นเขียวไม่ใช่การเดา — มันคือคณิตศาสตร์ของสมการ 3.2: optimization หยุดตรงที่กำไร reward ต่อ nat เท่ากับ β พอดี เดินต่อจากนั้นขาดทุน เมื่อ $\beta = 0$ เงื่อนไขหยุดนี้ไม่มีอยู่ — ทุก nat ของการเดินห่างที่แลก reward ได้แม้นิดเดียวคือ "กำไร" โมเดลจึงวิ่งออกจากภาษาธรรมชาติไปเรื่อย ๆ ตราบใดที่ตัวเลข reward ยังกระดิกขึ้น

5. เตรียมสภาพแวดล้อม (Environment)​

เปิด Colab เลือก Runtime → Change runtime type → T4 GPU (แผนฟรีพอ)

torch_dtype=torch.float16      # ไม่ใช่ bfloat16
attn_implementation="sdpa"     # ไม่ใช่ flash_attention_2

cap = torch.cuda.get_device_capability(0)
print("compute capability:", cap)                    # T4 = (7, 5)
print("native bf16:", cap[0] >= 8)                   # T4 -> False
print("torch says   :", torch.cuda.is_bf16_supported())  # T4 -> True (นับ emulation!)

ทำไม RLHF ถึงแพง: ภาพเดียวจบ​

ตัวเลขในภาพคือแค่น้ำหนัก — ยังไม่รวม activation, KV cache ตอน generate, gradient และ optimizer state และที่ 0.6B ทุกอย่างยังดูจิ๋ว แต่ตัวคูณ ×4 ไม่หายไปไหนเมื่อสเกลขึ้น: ที่ 7B คือ 56 GB ก่อนเริ่มทำอะไรเลย

6. เตรียมข้อมูล (Data)​

Stage A — คู่ preference สำหรับ reward model​

ใช้ iapp/dpo_thai_tutorial (100 คู่, Apache-2.0) — ชุดข้อมูล preference ภาษาไทยที่ผมทำขึ้นเองสำหรับซีรีส์นี้และปล่อยให้ใช้ต่อได้อิสระ แต่ละแถวมี prompt, chosen, rejected ที่คัดด้วยมือ เน้นความสุภาพและความเป็นธรรมชาติของภาษา

แบ่ง 80/20: เทรน 80 คู่ กัน 20 คู่ไว้เป็น held-out ห้ามแตะระหว่างเทรน เกณฑ์ผ่านของ Stage A คือ pairwise ranking accuracy บน 20 คู่ที่กันไว้ พร้อม Wilson 95% CI ที่ไม่คร่อม 0.5 — แค่ "ดีกว่าโยนเหรียญอย่างมีนัยสำคัญ" ก็ถือว่าพิสูจน์กลไกได้แล้ว เพราะ 20 คู่ทำ CI แคบกว่านั้นไม่ได้จริง ๆ

Stage B — โจทย์ที่ตรวจได้ด้วยกติกา​

สำหรับลูป PPO เราใช้โจทย์เลข 64 ข้อจาก VISAI-AI/gsm8k-thai (GSM8K ฉบับแปลไทย) และให้คะแนนด้วยกติกาที่ตรวจสอบได้ แทนที่จะใช้ reward model จาก Stage A:

import re

def rule_reward(response: str, gold: int) -> float:
    """+1.0 ถ้าเลขจำนวนเต็มตัวสุดท้ายในคำตอบถูก, +0.2 ถ้าตอบเป็นภาษาไทยจริง"""
    nums = re.findall(r"-?\d+", response.replace(",", ""))
    correct = 1.0 if nums and int(nums[-1]) == gold else 0.0
    thai = sum("ก" <= ch <= "๛" for ch in response)
    thai_bonus = 0.2 if thai / max(len(response), 1) >= 0.5 else 0.0
    return correct + thai_bonus

7. โค้ดหลัก (Main code)​

7.1 Stage A — เทรน reward model จริง (~6 นาที)​

เปลี่ยนโมเดลภาษาให้เป็นเครื่องให้คะแนน: หัว LM ถูกแทนด้วย linear ชั้นเดียวที่คืนสเกลาร์หนึ่งตัว

import torch, torch.nn.functional as F
from transformers import AutoModelForSequenceClassification, AutoTokenizer
from peft import LoraConfig, get_peft_model

tok = AutoTokenizer.from_pretrained("Qwen/Qwen3-0.6B")
rm = AutoModelForSequenceClassification.from_pretrained(
    "Qwen/Qwen3-0.6B",
    num_labels=1,                          # หัวสเกลาร์: หนึ่งคะแนนต่อหนึ่งข้อความ
    torch_dtype=torch.float16,             # T4 ไม่มี bf16
    attn_implementation="sdpa",
).cuda()
rm.config.pad_token_id = tok.pad_token_id

rm = get_peft_model(rm, LoraConfig(
    task_type="SEQ_CLS", r=8, lora_alpha=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
    modules_to_save=["score"],             # หัวคะแนนตั้งต้นแบบสุ่ม ต้องเทรนเต็ม
))
for p in rm.parameters():
    if p.requires_grad:
        p.data = p.data.float()            # บทเรียน fp16 จากบทที่ 1: เทรนใน fp32

def rm_loss(chosen, rejected):
    s_w = rm(**chosen).logits.squeeze(-1)     # r_φ(x, y_w)
    s_l = rm(**rejected).logits.squeeze(-1)   # r_φ(x, y_l)
    return -F.logsigmoid(s_w - s_l).mean()    # สมการ 3.1 ตรงตัว

เทรน 3 epoch บน 80 คู่ แล้ววัด pairwise accuracy บน 20 คู่ที่กันไว้ พร้อม Wilson CI ถ้า CI ไม่คร่อม 0.5 — คุณเพิ่งเทรน reward model ตัวแรกในชีวิตสำเร็จ ด้วยข้อมูล 80 แถว

7.2 Stage B — PPO เขียนเองจากศูนย์ ~120 บรรทัด (~10 นาที)​

เราจะไม่ใช้ PPOTrainer ของ TRL และนี่คือการตัดสินใจที่ตั้งใจ ไม่ใช่ความดื้อ: TRL ย้าย PPOTrainer ไปอยู่ trl.experimental แล้ว และประกาศแผนถอดออกใน 0.29.0 — โค้ดที่สอนด้วยไลบรารีตัวนี้จะรันไม่ได้ในอีกไม่กี่เดือน ส่วนลูป PPO ที่เขียนเองราว 120 บรรทัดจะรันได้ตราบเท่าที่ PyTorch ยังอยู่ และสำคัญกว่านั้น: เขียนเองแล้วคุณจะรู้ว่าทุกบรรทัดทำอะไร แบบเดียวกับ DPO loss 25 บรรทัดในบทที่ 4

ชิ้นส่วนบนกระดาน: policy = base + LoRA adapter (จากบทที่ 2, is_trainable=True), reference = base ตัวเดิมปิด adapter, และ value head เป็น MLP สองชั้นเสียบบน hidden state สุดท้าย:

value_head = torch.nn.Sequential(
    torch.nn.Linear(1024, 1024), torch.nn.Tanh(),
    torch.nn.Linear(1024, 1),
).float().cuda()                           # ~1M พารามิเตอร์ — จิ๋วเดียวเทียบกับอีกสามตัว

rollout: สุ่มคำตอบครั้งละ 8 prompt (max_new_tokens=200, do_sample=True) ให้คะแนนด้วย rule_reward, standardize คะแนนภายใน batch, และเก็บ log-prob ณ ตอน rollout แบบ detach ไว้ทันที แล้วเข้าลูป update นี้ — 40 บรรทัดที่เป็นหัวใจของทั้งบท (ลูปเต็มอยู่ในโน้ตบุ๊ก):

def compute_gae(rewards, values, gamma=1.0, lam=0.95):
    """rewards: [T] ของหนึ่ง response, values: [T+1] (ช่องสุดท้าย = 0 หลังจบ)"""
    adv, acc = torch.zeros_like(rewards), 0.0
    for t in reversed(range(rewards.shape[0])):
        delta = rewards[t] + gamma * values[t + 1] - values[t]   # สมการ 3.4
        acc = delta + gamma * lam * acc                          # Â_t = δ_t + γλ Â_{t+1}
        adv[t] = acc
    return adv

def ppo_update(rollout, eps=0.2, beta=0.05):
    out = policy(rollout.ids, output_hidden_states=True)         # forward เดียวได้สองอย่าง
    logp = gather_logprobs(out.logits, rollout.ids)              # [B, T] มี gradient
    with torch.no_grad(), policy.disable_adapter():
        logp_ref = gather_logprobs(policy(rollout.ids).logits, rollout.ids)

    # reward ต่อ token = ค่าปรับ KL ทุกตำแหน่ง + คะแนนงานที่ token สุดท้าย (สมการ 3.2)
    rew = -beta * (logp.detach() - logp_ref)
    rew[:, -1] += rollout.scores_std                 # คะแนน rule ที่ standardize แล้ว

    hidden = out.hidden_states[-1].detach().float()  # detach = ตัด gradient เข้าลำต้น
    values = value_head(hidden).squeeze(-1)
    adv = torch.stack([compute_gae(r, F.pad(v, (0, 1))) for r, v in zip(rew, values)])
    adv = (adv - adv.mean()) / (adv.std() + 1e-8)    # standardize advantage อีกชั้น

    log_ratio = (logp - rollout.logp_old).clamp(-10, 10)   # กัน fp16 overflow!
    ratio = log_ratio.exp()                                # ρ_t (สมการ 3.3)
    surr = torch.min(ratio * adv.detach(),
                     ratio.clamp(1 - eps, 1 + eps) * adv.detach())

    returns = (adv + values).detach()                # เป้าหมายของ value head
    m = rollout.resp_mask                            # นับเฉพาะ token ของ response
    loss = (-(surr * m).sum() + 0.5 * ((values - returns).pow(2) * m).sum()) / m.sum()
    return loss                                      # (พจน์ entropy อยู่ในโน้ตบุ๊ก)

ตั้งค่า: $\epsilon = 0.2$, $\beta = 0.05$, $\gamma = 1.0$, $\lambda = 0.95$, 4 epoch ต่อ rollout เดียวกัน บน 64 prompt, LR ของ adapter 1e-5 ของ value head 1e-4 รวมประมาณ 10 นาทีต่อหนึ่งรันบน T4 (โน้ตบุ๊กรันสองครั้ง: $\beta = 0.05$ และ $\beta = 0$)

8. ผลลัพธ์ (Results)​

โน้ตบุ๊กวัดสามเส้นโค้งพร้อมกันทุก update แล้วเขียนลง results.json:

1. Reward เฉลี่ยต่อ rollout — ควรไต่ขึ้น (นี่คือสิ่งที่เราซื้อ)
2. KL ต่อ token เทียบ $\pi_{\text{ref}}$ — ควรโตแล้วอิ่มตัวใต้เพดานที่ $\beta$ กำหนด (นี่คือราคาที่จ่าย)
3. ความยาวคำตอบเฉลี่ย — ตัวจับโรค: ความยาวที่พุ่งหรือดิ่งผิดปกติคือสัญญาณแรกของ policy ที่กำลังเพี้ยน

จับ reward hacking คาหนังคาเขา​

รันที่สองของโน้ตบุ๊กตั้ง $\beta = 0$ โดยแตะอย่างอื่นเลยแม้แต่ตัวเดียว — ไม่มีสายจูง รูปแบบที่คาดว่าจะเห็น: reward ไต่เท่าเดิมหรือเร็วกว่า แต่ KL ทะยานไม่มีเพดาน และคำตอบเริ่มเสื่อมสภาพ — วนซ้ำ สั้นผิดปกติ หรือกลายเป็นสูตรสำเร็จที่ยัดตัวเลขไว้ท้ายประโยค เพราะ rule_reward มองเห็นแค่เลขท้ายกับสัดส่วนอักขระไทย ทุกอย่างที่มันมองไม่เห็นคือของฟรีที่โมเดลทิ้งได้

ตัวอย่างคำตอบเสื่อมสภาพจากรัน $\beta = 0$ จะถูกพิมพ์โดยเซลล์สุดท้ายของโน้ตบุ๊ก:

[ช่องนี้เติมจากผลรันจริงของโน้ตบุ๊กเท่านั้น — ผมจะไม่แต่งตัวอย่าง degenerate ขึ้นเอง
 เพราะทั้งซีรีส์นี้ยืนอยู่บนกติกาว่าไม่มีตัวเลขหรือ output ที่ invent ขึ้นมา
 รันโน้ตบุ๊กแล้วเซลล์ "hacking exhibits" จะโชว์คำตอบจริง 2-3 อันพร้อม KL ของมัน]

9. เปรียบเทียบ (Comparison)​

โน้ตบุ๊กวัดชุดเดียวกันสามระบบบนโจทย์เลขไทย held-out (TH-MATH):

รูปแบบที่ควรจะเห็น: แถว $\beta = 0.05$ ขยับ accuracy ขึ้นเล็กน้อยหรือเสมอตัวโดย KL นิ่ง ส่วนแถว $\beta = 0$ ได้ rule reward ตอนเทรนสูงที่สุด แต่ accuracy บน held-out ไม่ควรดีกว่า และภาษาพัง — คะแนนที่โกงมาไม่โอนย้ายไปยังโจทย์ใหม่

ถ้าเห็นอย่างอื่น ให้ตีความแบบนี้:

• ทั้งสามแถวแทบไม่ต่างกัน → advantage เป็นศูนย์เกือบตลอด เช็คว่า reward ในแต่ละ batch มีความหลากหลายไหม (ถ้าโมเดลตอบผิดหมดทุกข้อ advantage หลัง standardize คือ noise ล้วน — ความรู้สึกเดียวกับชุด All wrong ในเครื่องมือหัวข้อ 4)
• β = 0 แล้ว KL ไม่ทะยาน → 4 epoch คูณ 64 prompt สั้นเกินกว่าที่การ hack จะสุกงอม — เพิ่มรอบแล้วดูใหม่ อย่าเพิ่งสรุปว่า "ไม่มี hacking"
• β = 0.05 แต่ KL ก็ยังทะยาน → เกือบแน่นอนว่าลืม standardize คะแนน ทำให้สเกล reward ท่วม β หรือไม่ก็ LR สูงเกิน

กับดักที่ต้องระวัง​

1. ไม่ standardize reward สเกลของ reward ไม่ถูกนิยามตามสมการ 3.1 — RM สองตัวที่จัดอันดับเหมือนกันเป๊ะอาจให้สเกลต่างกันสิบเท่า สเกลนั้นคูณตรงเข้าไปใน advantage และ gradient: รันเดิมที่เคยนิ่งจะระเบิดทันทีเมื่อเปลี่ยน RM

2. คำนวณ logp_old ใหม่ในลูป update บั๊กที่เงียบที่สุดของบทนี้: ไม่มี error, loss ดูปกติ แต่ $\rho_t = 1$ ตลอดกาล clip ไม่เคยทำงาน trust region ไม่มีจริง — คุณกำลังรัน REINFORCE โดยเข้าใจว่าตัวเองรัน PPO

3. ใช้ลำต้นร่วมระหว่าง policy กับ value โดยไม่ stop-gradient value loss มีสเกลใหญ่และไหลย้อนเข้า backbone ไปเขียนทับความสามารถทางภาษา โน้ตบุ๊กนี้กันด้วย .detach() ตรง hidden state (เห็นในโค้ดหัวข้อ 7.2) — ราคาหนึ่งบรรทัด

4. fp16 ratio overflow exp(log_ratio) ระเบิดเกินเพดาน fp16 ได้ตั้งแต่ log-ratio ประมาณ 11.1 ต้อง .clamp(-10, 10) ก่อน .exp() เสมอ — และถ้าเห็น log-ratio โตถึงระดับนั้นบ่อย ๆ นั่นเป็นสัญญาณว่า policy กำลังวิ่งหนี rollout เก่าเร็วเกินไป (ลด LR หรือลดจำนวน epoch ต่อ rollout)

10. สรุป (Summary)​

• RLHF = เดินอ้อมสองขั้น เพื่อ optimize สิ่งที่หาอนุพันธ์ไม่ได้: เทรนกรรมการ ($r_\phi$) แล้วใช้ RL วิ่งเข้าหาคะแนนของกรรมการ
• Bradley–Terry เห็นแค่ผลต่าง — สเกลสัมบูรณ์ของ reward ไม่ถูกนิยาม จึงต้อง standardize ก่อนใช้เสมอ
• สมการแม่ $\max\ \mathbb{E}[r] - \beta\,\mathbb{D}_{\text{KL}}$ คือสมการเดียวที่ต้องท่องจำ — บทที่ 4 และ 5 คือการแก้สมการนี้ด้วยวิธีอื่น
• KL ไม่ใช่ regularizer — มันคือเงื่อนไขหยุดเพียงอย่างเดียวของระบบ ถอดออกเมื่อไหร่ Goodhart ทำงานเมื่อนั้น
• min + clip = มองโลกแง่ร้ายโดยดีไซน์: ได้จำกัด เสียไม่จำกัด — trust region ที่ทำให้ rollout เก่าใช้ซ้ำได้
• GAE คือปุ่ม bias–variance และ $V_\psi$ ที่มันพึ่งพาคือโมเดลตัวที่สี่ ที่ GRPO จะลบทิ้งในบทที่ 5
• PPO แพงเพราะโครงสร้าง ไม่ใช่เพราะเขียนโค้ดห่วย: โมเดล 4 ตัว + hyperparameter ร่วมสิบตัวคือราคาหน้าตั๋ว

บทต่อไป: DPO — DPO ลบทั้ง reward model และ RL loop ทิ้งด้วยพีชคณิตล้วน ๆ จากสมการแม่ 3.2 ที่คุณเพิ่งท่องจำไป

อ้างอิง (References)​

1. Schulman et al. (2017). Proximal Policy Optimization Algorithms — PPO ต้นฉบับ: สมการ clipped surrogate ในหัวข้อ 3
2. Schulman et al. (2015). High-Dimensional Continuous Control Using Generalized Advantage Estimation — GAE: สมการ advantage ที่ใช้ใน PPO
3. Christiano et al. (2017). Deep reinforcement learning from human preferences — งานที่เริ่มต้นแนวคิด RL จาก preference ของมนุษย์
4. Stiennon et al. (2020). Learning to summarize from human feedback — RLHF ที่ใช้งานได้จริงเป็นครั้งแรกในงาน summarization
5. Ouyang et al. (2022). Training language models to follow instructions with human feedback — InstructGPT: ต้นแบบของ pipeline SFT -> RM -> PPO ทั้งหมด
6. Bai et al. (2022). Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback — ชุดข้อมูล helpful/harmless และบทเรียนเรื่อง KL
7. Zheng et al. (2023). Secrets of RLHF in Large Language Models Part I: PPO — รายละเอียดภาคปฏิบัติของ PPO ที่เปเปอร์อื่นไม่เขียน
8. Bradley & Terry (1952). Rank Analysis of Incomplete Block Designs: I. The Method of Paired Comparisons — โมเดล Bradley-Terry ที่ reward model ทั้งหมดตั้งอยู่บนนั้น

บทความ โค้ด และโน้ตบุ๊กในซีรีส์นี้เผยแพร่ภายใต้สัญญาอนุญาต CC BY-NC-SA 4.0 — นำไปใช้และดัดแปลงต่อได้ โดยอ้างอิงที่มา ไม่ใช้เพื่อการค้า และเผยแพร่ต่อด้วยสัญญาเดียวกัน (โมเดลและชุดข้อมูลของบุคคลที่สามที่อ้างถึง ยังคงใช้สัญญาของเจ้าของเดิม)

1. ปัญหา (Problem statement)​

สมมติคุณอยากให้ผู้ช่วย AI ของคุณ "ตอบเป็นภาษาไทยเสมอ" — ฟังดูง่าย แต่ลองเขียนเป็น loss function ดูสิครับ คุณจะเขียนไม่ออก

นี่คือปัญหาแกนกลางของ alignment: คุณภาพของคำตอบ เขียนเป็นสมการไม่ได้ "สุภาพกว่า" "เป็นธรรมชาติกว่า" "ไม่หลุดไปเป็นภาษาอังกฤษ" — ไม่มีเฉลยเดียวที่ถูกต้อง มีแต่การเปรียบเทียบ ให้คนดูคำตอบสองอันแล้วบอกว่าชอบอันไหนมากกว่า ข้อมูลที่ได้จึงมีหน้าตาเป็นสามสิ่ง: prompt $x$, คำตอบที่ชอบ $y_w$ (chosen), คำตอบที่ไม่ชอบ $y_l$ (rejected)

RLHF แบบ PPO แก้ปัญหานี้ด้วยการเดินอ้อมสองขั้น:

1. เทรน reward model $r_\phi(x,y)$ ให้เลียนแบบความชอบของมนุษย์
2. ใช้ RL ดัน policy ไปหาคะแนนสูง ๆ ของ reward model นั้น

การเดินอ้อมนี้มีราคา:

คำถามของบทนี้จึงเป็นคำถามเดียวสั้น ๆ: เราข้ามขั้นที่ 1 กับ 2 ไปเลยได้ไหม

2. เราจะทำอะไร (Solution)​

คำตอบคือได้ และเหตุผลสวยมาก

จุดเริ่มคือข้อสังเกตว่า objective ของ RLHF ที่มี KL constraint นั้น มีคำตอบในรูปปิด (closed form) เรารู้อยู่แล้วว่า policy ที่ดีที่สุดหน้าตาเป็นอย่างไร โดยไม่ต้องรัน RL เลยแม้แต่ step เดียว เมื่อรู้แบบนั้น เราก็พลิกสมการกลับด้าน — แทนที่จะถามว่า "reward นี้ให้ policy อะไร" เราถามว่า "policy นี้แปลว่า reward เท่าไหร่"

นี่คือ DPO (Direct Preference Optimization) ซึ่งเสนอโดย Rafailov และคณะ (2023) ชื่อ "Direct" มาจากการที่เรา optimize บนข้อมูล preference โดยตรง ไม่ผ่านตัวกลาง

3. สมการ (Equation)​

3.1 ตั้งโจทย์: RLHF objective​

อ่านเป็นภาษาคน: "ทำคะแนน reward ให้สูงที่สุด แต่ห้ามเดินห่างจากโมเดลตั้งต้นมากเกินไป"

• $\pi$ = policy คือโมเดลที่เรากำลังเทรน
• $\pi_{\text{ref}}$ = reference policy คือโมเดลตั้งต้น (ในบทนี้คือโมเดลหลัง SFT จากบทที่ 2)
• $r(x,y)$ = reward ของคำตอบ $y$ ต่อ prompt $x$
• $\beta$ = ความเข้มของสายจูง ยิ่งมากยิ่งดึงกลับหา $\pi_{\text{ref}}$ แรง

พจน์ KL ไม่ใช่ของประดับ ถ้าไม่มีมันโมเดลจะวิ่งหนีไปหาจุดที่ reward สูงแต่ภาษาพัง

3.2 ขั้นที่ 1 — คำตอบในรูปปิด​

โจทย์ข้างบนนี้แก้ได้ด้วยมือ (เป็นการหา distribution ที่ minimize KL ต่อ distribution เป้าหมาย) ได้ผลว่า

• $Z(x) = \sum_{y}\pi_{\text{ref}}(y|x)\exp\!\big(r(x,y)/\beta\big)$ คือ partition function ตัวหารที่ทำให้ผลรวมเป็น 1
• สังเกตว่า $Z(x)$ ขึ้นกับ $x$ เท่านั้น ไม่ขึ้นกับ $y$ — จำประโยคนี้ไว้ให้ดี เดี๋ยวมันจะกลายเป็นพระเอก

ความหมายเชิงสัญชาตญาณ: policy ที่ดีที่สุดคือ โมเดลเดิม ถ่วงน้ำหนักใหม่ด้วย $\exp(r/\beta)$ คำตอบที่ reward สูงถูกขยายความน่าจะเป็น คำตอบที่ reward ต่ำถูกกด แต่ตั้งต้นจากรูปร่างเดิมของ $\pi_{\text{ref}}$ เสมอ

ในทางปฏิบัติเราคำนวณ $Z(x)$ ไม่ได้ เพราะต้องรวมทุกคำตอบที่เป็นไปได้ทั้งจักรวาล นี่คือเหตุผลที่คนใช้ RL — และเป็นเหตุผลที่ DPO ไม่ต้องใช้

3.3 ขั้นที่ 2 — พลิกสมการหา reward​

ใส่ log ทั้งสองข้างแล้วย้ายข้าง จะได้

บรรทัดนี้คือหัวใจ reward ทุกฟังก์ชันเขียนใหม่ได้ในรูปของ policy ที่ optimal กับ policy ตั้งต้น แปลว่าถ้าเรามีโมเดลสองตัว เราคำนวณ reward โดยปริยายของมันได้ทันที โดยไม่ต้องเทรน reward model ใด ๆ

3.4 ขั้นที่ 3 — แทนใน Bradley-Terry แล้ว $Z(x)$ ตัดหาย​

โมเดลมาตรฐานของความชอบคือ Bradley-Terry: โอกาสที่คนจะเลือก $y_w$ เหนือ $y_l$ คือ

โดย $\sigma$ คือ sigmoid สังเกตว่าในสมการนี้ reward ปรากฏในรูป ผลต่าง เท่านั้น แทนสมการ 3.3 ลงไป — $\beta\log Z(x)$ อยู่ทั้งสองฝั่งเท่ากันเป๊ะเพราะ $x$ ตัวเดียวกัน — มันจึงตัดกันหายไป

3.5 Gradient — ที่ซึ่งสัญชาตญาณอยู่​

โดย $\hat r = \beta\log\big(\pi_\theta/\pi_{\text{ref}}\big)$ เรียกว่า implicit reward (reward โดยปริยาย)

อ่านทีละชิ้น:

• วงเล็บขวา = ทิศทาง ดัน log-prob ของ $y_w$ ขึ้น และกด log-prob ของ $y_l$ ลง พร้อมกัน
• $\sigma(\hat r_l - \hat r_w)$ = น้ำหนัก คือ "โมเดลจัดอันดับคู่นี้ผิดแค่ไหน"

น้ำหนักตัวนี้คือจุดสอนที่สำคัญที่สุด ถ้าโมเดลจัดอันดับคู่นี้ถูกอยู่แล้ว ($\hat r_w$ มากกว่า $\hat r_l$ ชัดเจน) ค่า $\sigma(\hat r_l - \hat r_w)$ จะเข้าใกล้ศูนย์ และคู่นั้นแทบไม่ส่ง gradient เลย DPO จึงโฟกัสไปที่ความผิดพลาดของตัวเองโดยอัตโนมัติ ไม่ต้องมีใครมาคัดข้อมูลให้

4. เห็นภาพสมการ (Visualize)​

Bradley-Terry: จากผลต่าง reward เป็นความน่าจะเป็น​

จุดที่ผลต่างเป็นศูนย์ให้ความน่าจะเป็น 0.5 พอดี คือ "โมเดลไม่มีความเห็น" และเพราะกราฟสนใจแค่ผลต่าง การบวกค่าคงที่เข้าไปใน reward ทั้งสองฝั่งจึงไม่เปลี่ยนอะไรเลย นั่นแหละคือเหตุผลเชิงเรขาคณิตที่ $Z(x)$ ตัดหายได้

Loss และน้ำหนักของ gradient​

ให้ $\Delta = \log\frac{\pi_\theta(y_w|x)}{\pi_{\text{ref}}(y_w|x)} - \log\frac{\pi_\theta(y_l|x)}{\pi_{\text{ref}}(y_l|x)}$ แล้ว loss คือ $-\log\sigma(\beta\Delta)$ และน้ำหนัก gradient คือ $\sigma(-\beta\Delta)$

แผงขวาคือสิ่งที่ต้องดูให้ดี เมื่อ margin เป็นบวกมาก ๆ น้ำหนักจะลู่เข้าศูนย์ — คู่นั้น "เรียนจบแล้ว" และยิ่ง $\beta$ สูง เส้นยิ่งชัน คือทั้งเรียนเร็วและ "เลิกเรียน" เร็ว ที่ $\beta = 1.0$ คู่ที่ margin เกิน 4 แทบไม่มี gradient เหลือเลย ส่วนที่ $\beta = 0.1$ เส้นแบนกว่ามาก โมเดลยังเก็บ gradient จากทุกคู่อยู่เรื่อย ๆ — ช้ากว่า แต่นิ่งกว่า

$\beta$ ควบคุมว่าโมเดลจะเดินห่างจากตั้งต้นได้แค่ไหน​

อ่านภาพนี้จากขวาไปซ้าย: ที่ $\beta = 0.1$ ความน่าจะเป็นเกือบทั้งหมดยุบไปกองที่ $y_5$ ซึ่ง reward สูงสุด นั่นคือ mode collapse — ได้คะแนนดีแต่ความหลากหลายหายเกลี้ยง ที่ $\beta = 10$ แท่งเกือบทับเส้นประ คือแทบไม่ได้เรียนอะไรเลย $\beta$ ไม่ใช่ hyperparameter ที่ "ปรับให้ loss ต่ำสุด" แต่มันคือ การเลือกจุดแลกเปลี่ยน ระหว่างการทำตามความชอบกับการรักษาตัวตนเดิม

ลองเลื่อนค่าเองแล้วดูว่า loss กับ gradient เปลี่ยนรูปอย่างไร:

5. เตรียมสภาพแวดล้อม (Environment)​

เปิด Colab เลือก Runtime → Change runtime type → T4 GPU (แผนฟรีพอ)

torch_dtype=torch.float16      # ไม่ใช่ bfloat16
attn_implementation="sdpa"     # ไม่ใช่ flash_attention_2
fp16=True                      # ใน DPOConfig (ไม่ใช่ bf16=True)

cap = torch.cuda.get_device_capability(0)
print("compute capability:", cap)                    # T4 = (7, 5)
print("native bf16:", cap[0] >= 8)                   # T4 -> False
print("torch says   :", torch.cuda.is_bf16_supported())  # T4 -> True (นับ emulation!)

reference model ที่ไม่กิน VRAM เพิ่มเลย​

DPO ต้องใช้ทั้ง $\pi_\theta$ และ $\pi_{\text{ref}}$ ฟังดูเหมือนต้องโหลดสองโมเดล แต่เราต่อยอดจาก LoRA adapter ของบทที่ 2 ซึ่งทำให้ทั้งสองตัวใช้น้ำหนักฐานร่วมกัน

from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-0.6B",
    torch_dtype=torch.float16,
    attn_implementation="sdpa",
).cuda()

policy = PeftModel.from_pretrained(base, "kobkrit/qwen3-0.6b-th-sft-lora", is_trainable=True)

policy คือ base + adapter ส่วน $\pi_{\text{ref}}$ คือ base ตัวเดิม ที่ปิด adapter ไว้ เรียกผ่าน context manager policy.disable_adapter() ได้เลย ไม่ต้องโหลดอะไรเพิ่ม

6. เตรียมข้อมูล (Data)​

ข้อมูล DPO ต้องมี 3 คอลัมน์: prompt, chosen, rejected เท่านั้น

ชุดที่ 1 — iapp/dpo_thai_tutorial (100 คู่, Apache-2.0) เป็นชุดข้อมูลที่ผมทำขึ้นเองสำหรับซีรีส์นี้ ปล่อยเป็น Apache-2.0 ให้เอาไปใช้ต่อได้ เป็นคู่ preference ภาษาไทยที่คัดด้วยมือ เน้นความสุภาพและความเป็นธรรมชาติของภาษา

ชุดที่ 2 — สร้างเองราว 400 คู่ จาก airesearch/wangchanx-seed-free-synthetic-instruct-thai-120k วิธีสร้างตรงไปตรงมามาก:

• chosen = คำตอบอ้างอิงภาษาไทยที่มากับชุดข้อมูล
• rejected = คำตอบที่โมเดลฐานสร้างเองด้วย greedy decoding

def build_rejected(prompt):
    with torch.no_grad(), policy.disable_adapter():
        out = policy.generate(**tok(prompt, return_tensors="pt").to("cuda"),
                              max_new_tokens=192, do_sample=False)
    return tok.decode(out[0], skip_special_tokens=True)[len(prompt):]

รวมได้ราว 500 คู่ แบ่ง held-out ไว้ 15% สำหรับวัดผล ไม่แตะระหว่างเทรน

7. โค้ดหลัก (Main code)​

หัวใจของหัวข้อนี้ไม่ใช่การเรียกใช้ไลบรารี แต่คือการเขียน DPO loss เองด้วยมือ แล้วพิสูจน์ว่ามันตรงกับของจริง ถ้าอ่านสมการในหัวข้อ 3 มาแล้วยังไม่เชื่อ โค้ดนี้จะทำให้เชื่อ

7.1 เขียนเอง 25 บรรทัด​

import torch, torch.nn.functional as F

def seq_logp(model, input_ids, attention_mask, labels):
    """ผลรวม log-prob ของ 'เฉพาะส่วนคำตอบ' (token ของ prompt ถูก mask เป็น -100)"""
    logits = model(input_ids=input_ids, attention_mask=attention_mask).logits
    logits = logits[:, :-1, :]                   # ตำแหน่ง t ทำนาย token ที่ t+1
    target = labels[:, 1:]                       # จึงต้องเลื่อนเป้าหมายไป 1
    mask = target.ne(-100)                       # นับเฉพาะ token คำตอบ
    target = target.masked_fill(~mask, 0)        # กัน gather พังที่ตำแหน่ง -100
    logp = torch.log_softmax(logits.float(), dim=-1)
    tokp = logp.gather(-1, target.unsqueeze(-1)).squeeze(-1)
    return (tokp * mask).sum(-1)                 # [B] — ผลรวม ไม่ใช่ค่าเฉลี่ย

def dpo_loss(policy, batch, beta=0.1):
    pi_w = seq_logp(policy, batch["chosen_ids"],   batch["chosen_mask"],   batch["chosen_labels"])
    pi_l = seq_logp(policy, batch["rejected_ids"], batch["rejected_mask"], batch["rejected_labels"])

    with torch.no_grad(), policy.disable_adapter():        # reference: ปิด adapter + ไม่เอา gradient
        ref_w = seq_logp(policy, batch["chosen_ids"],   batch["chosen_mask"],   batch["chosen_labels"])
        ref_l = seq_logp(policy, batch["rejected_ids"], batch["rejected_mask"], batch["rejected_labels"])

    delta = (pi_w - ref_w) - (pi_l - ref_l)                # Δ ในหัวข้อ 4
    loss = -F.logsigmoid(beta * delta).mean()              # สมการ 3.4 ตรงตัว

    r_w = beta * (pi_w - ref_w).detach()                   # implicit reward ของ chosen
    r_l = beta * (pi_l - ref_l).detach()                   # implicit reward ของ rejected
    return loss, r_w, r_l

ทั้ง DPO อยู่ในนี้หมดแล้วครับ ไม่มีอะไรซ่อนอยู่อีก บรรทัด delta คือสมการ 3.4 แปลงเป็นโค้ดแบบหนึ่งต่อหนึ่ง และ -F.logsigmoid(beta * delta) คือ loss ทั้งก้อน

7.2 พิสูจน์ว่ามันตรงกับ TRL​

from trl import DPOTrainer, DPOConfig

cfg = DPOConfig(
    output_dir="dpo-out",
    beta=0.1,
    loss_type="sigmoid",              # ต้องตรงกับสูตรที่เราเขียนเอง
    label_smoothing=0.0,              # ถ้าไม่ศูนย์ สูตรจะไม่ใช่สมการ 3.4 อีกต่อไป
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,    # effective batch = 16
    num_train_epochs=2,
    learning_rate=5e-6,               # ต่ำกว่า SFT มาก — ดูคำเตือนด้านล่าง
    lr_scheduler_type="cosine",
    warmup_ratio=0.1,
    max_length=768,
    max_prompt_length=256,
    fp16=True,                        # T4 ไม่มี bf16
    logging_steps=5,
)

trainer = DPOTrainer(model=policy, args=cfg, train_dataset=train_ds, processing_class=tok)

# สำคัญ: LoRA ที่เพิ่งสร้างมี lora_B = 0 ทำให้ policy เท่ากับ reference พอดี
# ผลต่างจึงเป็นศูนย์ และทั้งสองสูตรคืนค่า ln 2 เท่ากันเสมอ "แม้สูตรจะผิด"
# ต้องรบกวนน้ำหนักก่อน assert ถึงจะเป็นการทดสอบจริง
with torch.no_grad():
    for name, p in policy.named_parameters():
        if "lora_B" in name:
            p.add_(torch.randn_like(p) * 0.01)

loss_manual, _, _ = dpo_loss(policy, batch, beta=0.1)
loss_trl = trainer.compute_loss(policy, trl_batch)

assert torch.allclose(loss_manual, loss_trl, atol=1e-4)
print("ตรงกัน:", loss_manual.item(), loss_trl.item())