การทำ Fine-tuning, retrieval-augmented generation (RAG) และการใช้ prompting แบบปกติ ต่างก็ช่วยแก้ปัญหาคนละประเภทสำหรับโมเดลภาษาขนาดใหญ่ (LLMs) การเลือกวิธีที่ผิดจะทำให้เสียรอบการทำงานของ GPU (GPU cycles) สิ้นเปลืองค่าใช้จ่ายคลาวด์ และยังทำให้ผู้ใช้ได้รับคำตอบที่ไม่ถูกต้องอีกด้วย ด้านล่างนี้คือเฟรมเวิร์กแบบทีละขั้นตอนที่จะช่วยให้นักพัฒนาตัดสินใจได้ว่าเครื่องมือใดเหมาะกับกรณีการใช้งานของตน และจะนำมาผสมผสานกันอย่างไรเมื่อมีความจำเป็น
กลไกทั้งสามรูปแบบ
| สิ่งที่เปลี่ยนแปลง | หลักการทำงาน | การใช้งานทั่วไป |
|---|---|---|
| RAG | เพิ่มข้อเท็จจริงจากภายนอกเข้าไปในบริบทของโมเดลในขณะที่ทำการ inference | อัปเดตราคา, ดึงเอกสารนโยบายล่าสุด, การอ้างอิงข้อมูลส่วนตัว |
| Fine-tuning | ปรับเปลี่ยนค่าน้ำหนัก (weights) ภายในของโมเดลเพื่อเปลี่ยนสไตล์ รูปแบบ หรือพฤติกรรมที่ทำซ้ำได้ | โทนเสียงที่สม่ำเสมอ, โครงสร้างผลลัพธ์ที่ซับซ้อน, การจำแนกประเภทข้อมูลที่มีปริมาณสูง (high-throughput classification) |
| Prompting | กำหนดการตอบสนองในทันทีของโมเดลด้วยคำสั่งและตัวอย่างที่ชัดเจน | การใช้เหตุผลทั่วไป, การสร้างต้นแบบอย่างรวดเร็ว, การส่งมอบฟีเจอร์ภายในไม่กี่วัน |
คำถามสำคัญที่ต้องถามเมื่อเริ่มโครงการใดๆ คือ: ปัญหาที่เกิดขึ้นคือช่องว่างด้านความรู้ (knowledge gap) หรือช่องว่างด้านพฤติกรรม (behavior gap)? ช่องว่างด้านความรู้หมายถึงโมเดลไม่มีข้อเท็จจริงที่ถูกต้อง ส่วนช่องว่างด้านพฤติกรรมหมายถึงโมเดลรู้ข้อเท็จจริงนั้นแล้ว แต่ไม่สามารถแสดงออกมาในรูปแบบที่คุณต้องการได้
เมื่อปัญหาคือช่องว่างด้านความรู้ – ให้ใช้ RAG
หากโมเดลเกิดอาการหลอน (hallucinates), ให้ตัวเลขที่ล้าสมัย หรือไม่สามารถระบุแหล่งที่มาได้ แสดงว่าปัญหาคือข้อมูลที่ขาดหายไปหรือข้อมูลที่เก่าเกินไป RAG จะช่วยแก้ปัญหานี้โดยการดึงเอกสารหรือจุดข้อมูลที่ถูกต้องเข้าไปใน prompt ในขณะที่ทำงาน (runtime)
- ใช้ RAG เมื่อข้อเท็จจริงมีการเปลี่ยนแปลงบ่อยครั้ง เช่น ระดับสินค้าคงคลัง, ราคาตลาด หรือตารางข้อกำหนดทางกฎหมาย
- ใช้เมื่อคุณต้องมีการอ้างอิงหรือความสามารถในการตรวจสอบย้อนกลับเพื่อวัตถุประสงค์ด้านการปฏิบัติตามกฎระเบียบหรือการตรวจสอบ (audit)
- ใช้สำหรับชุดข้อมูลส่วนตัว (private corpora) ที่ไม่สามารถเปิดเผยต่อโมเดลสาธารณะได้ โดยชั้นการดึงข้อมูล (retrieval layer) จะช่วยรักษาข้อมูลไว้ภายใต้ไฟร์วอลล์ของคุณ
การอัปเดตเอกสารนั้นง่าย แต่การฝึกฝนโมเดลใหม่ (re-training) นั้นยาก
เมื่อปัญหาคือช่องว่างด้านพฤติกรรม – ให้ทำ fine-tune
หากโมเดลทราบข้อเท็จจริงที่ถูกต้องอยู่แล้ว แต่แสดงผลในรูปแบบ โทนเสียง หรือโครงสร้างที่ไม่สม่ำเสมอ คุณจำเป็นต้องปรับแต่งพฤติกรรมภายในของมัน การทำ fine-tuning จะเป็นการเขียนค่าน้ำหนัก (weights) ของโมเดลใหม่ เพื่อให้สไตล์ที่ต้องการกลายเป็นค่าเริ่มต้น
- เหมาะสำหรับน้ำเสียงเฉพาะของแบรนด์, ภาษาทางกฎหมาย หรือผลลัพธ์ใดๆ ที่ต้องเป็นไปตามเทมเพลตที่เข้มงวด
- ทำงานได้ดีสำหรับงานที่มีปริมาณมากและทำซ้ำๆ เช่น การจำแนกประเภทข้อมูลจำนวนมาก (bulk classification) ซึ่งค่าใช้จ่ายในการใช้ prompt ต่อครั้งแม้จะน้อยแต่เมื่อรวมกันแล้วอาจสูงขึ้น
- สามารถทำให้ prompt สั้นลง ช่วยลดการใช้ token และลดค่าใช้จ่ายในการ inference ลงได้
ข้อผิดพลาดที่พบบ่อยคือการทำ fine-tune โมเดลเพียงเพื่อสอนข้อเท็จจริง ซึ่งเป็นการสิ้นเปลืองทรัพยากรการประมวลผล (compute) และยังทำให้โมเดลเสี่ยงต่อปัญหาข้อมูลเปลี่ยนแปลง (data drift) ในอนาคต ข้อเท็จจริงควรอยู่ในชั้นการดึงข้อมูล (retrieval layer) ส่วนการ fine-tuning ควรอยู่ในชั้นพฤติกรรม (behavior layer)
เมื่อปัญหาคือช่องว่างด้านคำสั่ง – ให้เริ่มจากการใช้ prompting
Prompt engineering เป็นวิธีที่ถูกและเร็วที่สุดในการทดสอบว่าโมเดลสามารถแก้ปัญหาได้หรือไม่ คำสั่งที่ชัดเจน, ตัวอย่างแบบ few-shot และการใช้ chain-of-thought prompting มักจะช่วยปิดช่องว่างได้โดยไม่ต้องเปลี่ยนแปลงโมเดลเลย
- ใช้เพื่อสำรวจว่าคำตอบที่ "ดี" มีลักษณะอย่างไร ก่อนที่จะตัดสินใจเลือกโซลูชันที่มีราคาแพงกว่า
- ใช้กับงานที่ต้องใช้การใช้เหตุผลสูง, การระดมสมอง หรือสถานการณ์ใดก็ตามที่คุณต้องการผลลัพธ์ที่รวดเร็ว
- หากคุณสามารถได้รับผลลัพธ์ที่น่าพอใจด้วย prompt ที่เขียนมาอย่างดี คุณก็จะหลีกเลี่ยงภาระในการเก็บรวบรวมข้อมูล, การฝึกฝนโมเดล หรือการสร้าง pipeline สำหรับการดึงข้อมูล
หากคุณยังไม่ได้ลองใช้การเขียน prompt ที่ชัดเจนและตัวอย่างประกอบอย่างเต็มที่ คุณก็ยังไม่พร้อมที่จะลงทุนในโครงสร้างพื้นฐานสำหรับการทำ fine-tuning หรือ RAG
ขั้นตอนการตัดสินใจ
นำกรณีการใช้งานของคุณมาตรวจสอบตามรายการด้านล่างนี้ หากเจอคำตอบว่า "ใช่" ข้อแรก ให้หยุดและใช้วิธีนั้นทันที หากมีเงื่อนไขมากกว่าหนึ่งข้อที่ตรง ให้ใช้หลายวิธีร่วมกัน
- คุณได้ลองใช้ prompting ด้วยคำสั่งที่ชัดเจนและตัวอย่างแบบ few-shot หรือยัง? ยัง → เริ่มต้นด้วยการใช้ prompting
- ความล้มเหลวเกิดจากข้อเท็จจริงที่ขาดหายไปหรือล้าสมัย หรือคุณจำเป็นต้องมีการอ้างอิงแหล่งที่มาใช่หรือไม่? ใช่ → เพิ่มชั้น RAG
- ความล้มเหลวเกิดจากสไตล์หรือรูปแบบที่ไม่สม่ำเสมอ หรือความต้องการผลลัพธ์ที่ทำซ้ำได้และมีปริมาณสูงใช่หรือไม่? ใช่ → ทำ fine-tune โมเดล
เมื่อมีทั้งช่องว่างด้านความรู้และช่องว่างด้านพฤติกรรม ให้ใช้ RAG และ fine-tuning ร่วมกัน: ดึงข้อเท็จจริงที่ถูกต้องออกมาก่อน จากนั้นจึงให้โมเดลที่ผ่านการ fine-tune แล้วนำข้อมูลเหล่านั้นมาแสดงผลในสไตล์ที่ต้องการ
การวัดความสำเร็จ
อย่าพึ่งพาแค่ “ความรู้สึก” (vibes) เพียงอย่างเดียว จงสร้างชุดข้อมูลสำหรับประเมินผล (evaluation set) ขนาดเล็กที่เป็นตัวแทนของข้อมูลจริง ซึ่งครอบคลุมทั้งอินพุตหลักและเอาต์พุตที่คาดหวัง นำชุดข้อมูลเดียวกันนี้ไปทดสอบกับทุกโซลูชันที่เป็นไปได้—ไม่ว่าจะเป็น prompt เพียงอย่างเดียว, prompt + RAG, prompt + fine-tune หรือแบบ full stack—แล้วเปรียบเทียบความแม่นยำ, คุณภาพของการอ้างอิง (citation), ค่าใช้จ่ายด้าน token และความหน่วง (latency) ข้อมูลจะบอกคุณเองว่าเลเยอร์ไหนที่สร้างมูลค่าได้จริง และเลเยอร์ไหนที่เป็นภาระส่วนเกินที่ไม่จำเป็น
การเลือกเครื่องมือที่เหมาะสมตั้งแต่เนิ่นๆ จะช่วยประหยัดทั้งเวลา เงิน และลดความหงุดหงิด เริ่มต้นด้วย prompt ก่อน แล้วค่อยเพิ่มการดึงข้อมูล (retrieval) เมื่อพบว่าข้อเท็จจริงเป็นคอขวด และค่อยทำ fine-tune เมื่อพฤติกรรมเป็นคอขวด วัดผล ทำซ้ำ และคุณจะหลีกเลี่ยงหลุมพรางที่พบบ่อย นั่นคือการทุ่มพลัง GPU ไปกับปัญหาที่ไม่ใช่จุดสำคัญ