teach-me-ai / sources / HO-5
⟵ กลับหน้าแทร็กเสริม
HO-5 · Hands-On AI Engineering

Fine-tuning — เมื่อไหร่ควรเทรนเอง เทียบกับ RAG / prompt

⏱️ ~18 นาที 🎯 ได้เฟรมตัดสินใจ prompt → RAG → fine-tune และเห็นเคส text-to-SQL ที่ fine-tune ชนะ 📦 ต้นทาง: fine_tuning/text_to_sql_inventory

หมวดนี้มีโปรเจกต์เดียว แต่สอนการตัดสินใจที่สำคัญมาก: เมื่อไหร่ควร fine-tune (เทรนโมเดลต่อ) แทนที่จะแค่ prompt ดี ๆ หรือทำ RAG เพราะ fine-tune มักเป็นสิ่งแรกที่คนนึกถึงเวลาโมเดล "ยังไม่เก่งพอ" ทั้งที่จริง ๆ มันควรเป็น ทางเลือกท้าย ๆ บทนี้จะให้เฟรมคิดที่ใช้ได้จริง

fine-tuning คืออะไร (สั้น ๆ)

fine-tuning = เอาโมเดลที่มีอยู่แล้วมา เทรนต่อด้วยตัวอย่างเฉพาะงานของเรา ให้มันจำ "รูปแบบ" ที่เราต้องการ ต่างจาก prompt (บอกวิธีทำใน prompt) และ RAG (แปะความรู้เข้าไปใน context) ตรงที่ fine-tune เปลี่ยนตัวโมเดลเอง — จำได้ถาวรโดยไม่ต้องบอกซ้ำทุกครั้ง

เฟรมตัดสินใจ: prompt → RAG → fine-tune

ลำดับที่ควรลอง (จากถูก/เร็ว ไปแพง/ช้า) — ไต่ลงมาเมื่อขั้นก่อนหน้าไม่พอเท่านั้น:

1. Prompt engineering เร็ว/ถูกสุด · ลองก่อนเสมอ · system prompt + few-shot ดี ๆ ↓ ยังไม่พอ เพราะ "ขาดความรู้เฉพาะ" 2. RAG แปะความรู้จริงเข้า context · อัปเดตข้อมูลง่าย · (ทั้งบท HO-2) ↓ ยังไม่พอ เพราะ "ต้องการรูปแบบเฉพาะ/โมเดลเล็กเร็ว" 3. Fine-tune เทรนโมเดลจำรูปแบบ · แพง/ช้าสุด · ข้อมูลเปลี่ยน = เทรนใหม่
ไต่จากบนลงล่าง — อย่าเริ่มที่ fine-tune ถ้ายังไม่ได้พิสูจน์ว่า prompt/RAG ไม่พอ

เคสจริง: text-to-SQL ที่ fine-tune "คุ้ม"

text_to_sql_inventory แปลงคำถามภาษาคนเป็น SQL สำหรับฐานข้อมูลสต็อกสินค้า ทำไมเคสนี้ fine-tune ถึงเข้าท่า? เพราะมันเข้าเงื่อนไข "งานที่ fine-tune ชนะ" พอดี:

  • รูปแบบแคบและซ้ำ ๆ: input คือคำถาม → output คือ SQL เสมอ (โครงตายตัว เหมาะให้โมเดลจำ)
  • โมเดลเล็กก็พอ: ใช้ Qwen3.5-2B (เล็กมาก) fine-tune ด้วยตัวอย่างแค่ 200 คู่ (คำถาม → SQL) ก็ทำงานได้ — รันในเครื่องผ่าน HF Transformers
  • เทรนถูก: ใช้ QLoRA (Unsloth + TRL) บน Google Colab GPU T4 ตัวเดียว
  • ปลอดภัย: จำกัดให้รันแค่ query แบบ SELECT อย่างเดียว (read-only)
💡

สัญญาณว่า fine-tune คุ้ม: (1) งานมีรูปแบบตายตัวและทำซ้ำเยอะมาก · (2) อยากได้โมเดลเล็ก+เร็ว+ถูกที่รันเองได้ แทนโมเดลใหญ่ราคาแพง · (3) prompt ยาวเกินจนเปลืองทุก request — ยัดตัวอย่างเข้าโมเดลทีเดียวจบ

ข้อควรระวังก่อนกระโดดไป fine-tune

เข้าใจผิดว่า…ความจริง
"โมเดลไม่รู้ข้อมูลบริษัทเรา ต้อง fine-tune"นั่นคือปัญหา "ความรู้" → ใช้ RAG ดีกว่า (อัปเดตง่าย ไม่ต้องเทรนใหม่)
"fine-tune แล้วจะแม่นขึ้นทุกเรื่อง"มันเก่งเฉพาะรูปแบบที่เทรน อาจลืม/แย่ลงเรื่องอื่น
"ทำครั้งเดียวจบ"ข้อมูล/สคีมาเปลี่ยน = ต้องเตรียม dataset + เทรนใหม่ + ประเมินใหม่

map ลงงาน NestJS/Go ของคุณ

  • ส่วนใหญ่เริ่มที่ prompt + RAG: 90% ของงาน backend ที่ต่อ LLM ไม่ต้อง fine-tune เลย
  • text-to-SQL เป็นเคสคลาสสิกที่คุ้ม: ถ้าคุณมี query ซ้ำ ๆ บน PostgreSQL/Mongo เยอะ โมเดลเล็ก fine-tuned อาจถูกและเร็วกว่า — แต่ต้อง sandbox + read-only เสมอ (กัน SQL อันตราย)
  • มองเป็น artifact ที่ต้อง version: โมเดล fine-tuned = ไฟล์ที่ต้องเก็บ/เวอร์ชัน/deploy เหมือน service หนึ่งตัว (ขึ้น registry, มี rollback)
  • ต้องมี eval: เตรียมชุดทดสอบวัดก่อน/หลัง ไม่งั้นไม่รู้ว่าเทรนแล้วดีขึ้นจริงไหม
⚠️

ระวัง: fine-tune มีต้นทุนแฝงเยอะ — เตรียม dataset คุณภาพ (ยากสุด), ค่าเทรน, การ deploy/serve โมเดลเอง, และวินัย eval ถ้ายังไม่ลอง prompt/RAG ให้เต็มที่ก่อน การกระโดดมา fine-tune มักเสียเวลาโดยไม่จำเป็น เก็บไว้ใช้ตอนมีหลักฐานชัดว่าคุ้มจริง

🎯 แบบฝึกหัด
  1. เปิด README ของ fine_tuning/text_to_sql_inventory/ แล้วหาว่า dataset ที่ใช้เทรนมีกี่ตัวอย่าง และโมเดลฐานคือตัวไหน (ขนาดเท่าไหร่)
  2. มีเพื่อนบอกว่า "โมเดลไม่รู้เรื่องสินค้าของเรา ต้อง fine-tune" — อธิบายว่าทำไม RAG อาจเป็นคำตอบที่ดีกว่าในกรณีนี้
  3. นึกงานในบริษัทคุณที่ อาจ คุ้มกับ fine-tune (งานรูปแบบตายตัว ทำซ้ำเยอะ) แล้วเขียนว่าคุณจะพิสูจน์ยังไงว่ามันคุ้มกว่า prompt/RAG ก่อนลงมือเทรน

เมื่อทำเสร็จ พิมพ์ /quiz HO-5 เพื่อทดสอบความเข้าใจ