วิธีไฟน์จูน LLM [และเมื่อใดควรใช้ RAG หรือการเขียนพรอมต์แทน]

การไฟน์จูน (fine-tuning) โมเดลภาษาขนาดใหญ่ (LLM) คือการปรับปรุง LLM ที่ผ่านการฝึกล่วงหน้าแล้วด้วยชุดข้อมูลขนาดเล็กที่เฉพาะเจาะจงกับงาน เพื่อให้ได้ผลลัพธ์ที่การเขียนพรอมต์เพียงอย่างเดียวทำไม่ได้

การไฟน์จูนประกอบด้วยการรวบรวมตัวอย่างคู่อินพุต/เอาต์พุตที่แสดงพฤติกรรมที่คุณต้องการ การรันรอบการฝึกที่ปรับค่าน้ำหนัก (weights) ของโมเดลให้เข้าใกล้ตัวอย่างเหล่านั้น และการตรวจสอบผลลัพธ์เทียบกับเอาต์พุตของโมเดลต้นฉบับ วิธีการแบบประหยัดพารามิเตอร์อย่าง LoRA ทำให้กระบวนการนี้มีต้นทุนต่ำพอที่จะรันบน GPU เพียงตัวเดียว

หากคุณยังไม่พอใจกับผลลัพธ์ของ LLM ให้ปรับปรุงพรอมต์และการสร้างข้อความเสริมด้วยการดึงข้อมูล (RAG) ก่อน การไฟน์จูนจะเปลี่ยนวิธีที่ LLM ทำงาน แต่เมื่อคุณต้องการให้โมเดลใช้ข้อมูลใหม่ล่าสุดหรือข้อมูลที่เป็นกรรมสิทธิ์ การเขียนพรอมต์และ RAG มักเป็นทางเลือกที่ดีกว่า

ต่อไปนี้คือวิธีไฟน์จูน LLM ทีละขั้นตอน วิธีการไฟน์จูนหลัก (LoRA และ QLoRA) รวมถึงความท้าทายและข้อผิดพลาดที่อาจทำให้กระบวนการล้มเหลว

การไฟน์จูน LLM คืออะไร และแตกต่างจากการฝึกล่วงหน้า (pre-training) LLM อย่างไร

การฝึกล่วงหน้า LLM สร้างความสามารถทางภาษาทั่วไปของโมเดลตั้งแต่เริ่มต้นจากคลังข้อความขนาดมหาศาล ขณะที่การไฟน์จูน LLM จะปรับโมเดลที่ผ่านการฝึกล่วงหน้าแล้วด้วยชุดข้อมูลขนาดเล็กสำหรับงานใดงานหนึ่ง

การฝึกล่วงหน้า LLM เป็นขั้นตอนที่ใช้ทรัพยากรสูงซึ่งให้ผลลัพธ์เป็นโมเดลพื้นฐาน (base model) โมเดลจะเรียนรู้จากคลังข้อความที่ครอบคลุมกว้างขวาง ทำให้มีความรู้ด้านไวยากรณ์ ข้อเท็จจริง และการให้เหตุผลทั่วไป แต่ไม่มีความเชี่ยวชาญเฉพาะสำหรับงานของคุณ

การไฟน์จูน LLM คือการฝึกโมเดลพื้นฐานต่อด้วยชุดข้อมูลขนาดเล็กที่คัดสรรมาแล้ว เพื่อให้โมเดลสร้างผลลัพธ์ที่ต้องการสำหรับงานหรือกรณีการใช้งานเฉพาะ เช่น รูปแบบที่สม่ำเสมอ น้ำเสียงหรือโทนของแบรนด์ รูปแบบเฉพาะโดเมน หรือการเรียกใช้เครื่องมือและฟังก์ชันที่เชื่อถือได้

เมื่อใดควรไฟน์จูน LLM และเมื่อใดควรใช้พรอมต์หรือ RAG แทน

หากต้องการปรับปรุงประสิทธิภาพของ LLM ให้ไล่ระดับขึ้นไปตามลำดับ: การเขียนพรอมต์ -> RAG -> การไฟน์จูน

ปรับปรุงพรอมต์ด้วยคำสั่งที่ละเอียดยิ่งขึ้น และใช้ RAG เพื่อให้ข้อมูลล่าสุดแก่โมเดล ใช้การไฟน์จูนเฉพาะเมื่อการปรับปรุงพรอมต์และการดึงข้อมูลไม่ได้ผลเท่านั้น

เมื่อใดที่พรอมต์ที่ดีขึ้นได้ผลดีกว่าการไฟน์จูน และเมื่อใดที่ยังไม่เพียงพอ

การเขียนพรอมต์เป็นวิธีที่เร็วและประหยัดที่สุด ในหลายกรณี พรอมต์ที่แม่นยำและละเอียดขึ้นก็ช่วยให้โมเดลเปลี่ยนพฤติกรรมได้ตามที่ต้องการแล้ว

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

สัญญาณที่บ่งบอกว่าการเขียนพรอมต์อาจถึงขีดจำกัดแล้ว:

• กรณีพิเศษใหม่ๆ ทำให้ผลลัพธ์ผิดพลาดอยู่เรื่อยๆ: ตัวอย่างเช่น โมเดลส่งคืนข้อความร้อยแก้วเมื่อคุณต้องการ JSON หรือใช้โทนที่ไม่ตรงกับที่ต้องการ และคุณต้องแก้ไขพรอมต์สำหรับกรณีใหม่ทุกครั้ง
• พรอมต์ระบบยาวขึ้นเรื่อยๆ: พรอมต์มีความยาวหลายร้อยหรือหลายพันบรรทัดและจัดการได้ยาก
• คุณต้องจ่ายค่าใช้จ่ายนี้ในการเรียกใช้ทุกครั้ง: พรอมต์จะถูกส่งและประมวลผลซ้ำในทุกคำขอ ทำให้ต้นทุนโทเค็นและเวลาแฝงเพิ่มขึ้น
• การเปลี่ยนแปลงไม่ส่งผลอีกต่อไป: คำสั่งใหม่ไม่ได้ช่วยให้ผลลัพธ์ดีขึ้น

แม้ในกรณีนั้น ให้ลองวิธีแก้ไขระดับพรอมต์ที่ประหยัดกว่าก่อน ใช้ตัวอย่างแบบ few-shot เพื่อแสดงรูปแบบให้โมเดลเห็น (คู่อินพุต/เอาต์พุต) ใช้การเชื่อมพรอมต์ต่อกัน (prompt chaining) เพื่อแบ่งงานที่ยากออกเป็นขั้นตอนย่อย หรือใช้ฮุกการเรียกใช้ฟังก์ชันเพื่อส่งต่องานค้นหาข้อมูลที่ต้องแม่นยำหรืองานคำนวณออกไป

เมื่อใดที่ RAG เหมาะสมกว่าการไฟน์จูนโมเดล

RAG เปลี่ยนสิ่งที่ LLM รู้ ขณะที่การไฟน์จูน LLM เปลี่ยนวิธีที่โมเดลทำงาน หากช่องว่างอยู่ที่ความรู้ โดยเฉพาะความรู้ที่เปลี่ยนแปลงบ่อยหรืออยู่ในเอกสารของคุณเอง RAG คือคำตอบ หากช่องว่างอยู่ที่พฤติกรรม ให้ไฟน์จูน

การไฟน์จูนยังเปลี่ยนสิ่งที่โมเดลรู้ด้วย แต่ข้อเท็จจริงที่โมเดลซึมซับไว้จะหยุดนิ่งอยู่ ณ เวลาที่ฝึก และล้าสมัยอย่างรวดเร็วในสาขาที่เปลี่ยนแปลงเร็ว นอกจากนี้ ข้อมูลยังถูกฝังลงในค่าน้ำหนักของโมเดล จึงไม่มีบันทึกว่ามาจากแหล่งใด

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

ข้อเสียของ RAG คืออะไร? RAG เป็นเลเยอร์เพิ่มเติมที่ต้องสร้างและดูแลรักษา และยังเพิ่มเวลาแฝงด้วย

ในทางปฏิบัติ คุณมักต้องใช้ทั้งสองอย่าง ระบบที่ใช้งานจริงจะใช้โมเดลที่ผ่านการไฟน์จูนร่วมกับ RAG โดยใช้อย่างหนึ่งเพื่อให้พฤติกรรมสม่ำเสมอ และอีกอย่างเพื่อให้ได้ข้อเท็จจริงที่เป็นปัจจุบัน

ข้อผิดพลาด ความเสี่ยง และความท้าทายที่พบบ่อยในการไฟน์จูน

แม้การไฟน์จูนจะเป็นเครื่องมือที่เหมาะสม แต่ก็มีต้นทุนและความเสี่ยง:

• ต้นทุนและเวลา: การรวบรวมข้อมูลการฝึกที่สะอาดและเป็นตัวแทนที่ดี รวมถึงทรัพยากรการประมวลผลสำหรับการฝึก ล้วนมีค่าใช้จ่ายสูง
• การลืมแบบหายนะ (Catastrophic forgetting): เมื่อฝึกด้วยชุดข้อมูลที่แคบ โมเดลอาจสูญเสียทักษะทั่วไปและเกิดรูปแบบความล้มเหลวใหม่ๆ ส่งผลให้เกิดข้อผิดพลาดที่โมเดลพื้นฐานไม่เคยทำ
• โอเวอร์ฟิตติ้ง (Overfitting): หากข้อมูลน้อยเกินไปหรือซ้ำกันมากเกินไป โมเดลจะจดจำตัวอย่างการฝึกของคุณแทนที่จะเรียนรู้รูปแบบ จึงทำงานได้ดีกับตัวอย่างที่ใช้ฝึก แต่ทำงานได้ไม่ดีกับอินพุตจริง
• ความล้าสมัยของข้อมูล: ความรู้ที่ฝังอยู่ในค่าน้ำหนักจะล้าสมัยอย่างรวดเร็ว คุณจึงต้องฝึกใหม่ด้วยข้อมูลใหม่
• การตกยุค: เมื่อมีโมเดลที่แข็งแกร่งกว่าเปิดตัว โมเดลนั้นมักทำได้ดีกว่าโมเดลที่คุณไฟน์จูนไว้ได้ทันทีโดยไม่ต้องปรับแต่งใดๆ และคุณต้องทำงานใหม่อีกครั้ง
• ความท้าทายในการประเมินผลและการทำซ้ำ: การพิสูจน์ว่าโมเดลที่ผ่านการไฟน์จูนทำงานได้ดีกว่าโมเดลพื้นฐานนั้นทำได้ยาก นอกจากนี้ การฝึกบน GPU สองครั้งด้วยการตั้งค่าเดียวกันก็อาจได้โมเดลที่แตกต่างกันเล็กน้อย
• ธรรมาภิบาลข้อมูล: การฝึกด้วยข้อมูลที่เป็นกรรมสิทธิ์หรือข้อมูลที่ละเอียดอ่อนทำให้เกิดคำถามด้านความเป็นส่วนตัวและการอนุญาตให้ใช้สิทธิ์ เนื่องจากในภายหลังโมเดลอาจเผยบางส่วนของข้อมูลที่ใช้ฝึกออกมาได้

วิธีการไฟน์จูนหลัก

ประเภทหลักของการไฟน์จูน LLM แตกต่างกันตามสัดส่วนของโมเดลที่ถูกเปลี่ยนแปลง: การไฟน์จูนแบบเต็มรูปแบบจะฝึกโมเดลใหม่ทั้งหมด ขณะที่วิธีการไฟน์จูนแบบประหยัดพารามิเตอร์ (PEFT) อย่าง LoRA และ QLoRA จะอัปเดตค่าน้ำหนักเพียงบางส่วน วิธีการ PEFT ใช้หน่วยความจำเพียงเศษเสี้ยวของการไฟน์จูนแบบเต็มรูปแบบ และหากตั้งค่าอย่างเหมาะสมก็ให้ผลลัพธ์ที่เทียบเท่ากันได้

การไฟน์จูนแบบเต็มรูปแบบจะอัปเดตค่าน้ำหนักทุกค่าของโมเดล เป็นวิธีที่มีค่าใช้จ่ายสูงที่สุดและเสี่ยงต่อการลืมแบบหายนะมากที่สุด ควรสงวนไว้สำหรับการเปลี่ยนแปลงพฤติกรรมครั้งใหญ่เมื่อคุณมีข้อมูลและทรัพยากรการประมวลผลเพียงพอ

อีกทางเลือกหนึ่งคือการไฟน์จูนแบบประหยัดพารามิเตอร์ หรือ PEFT ซึ่งเป็นคำเรียกรวมของวิธีการที่ตรึงโมเดลส่วนใหญ่ไว้และฝึกเฉพาะพารามิเตอร์ชุดเล็กๆ วิธีนี้ใช้หน่วยความจำน้อยกว่ามากและมีแนวโน้มที่จะลืมน้อยกว่า เนื่องจากโมเดลพื้นฐานยังคงเดิม

ที่ค่าแรงก์ (rank) ต่ำ PEFT จะเรียนรู้ได้น้อยกว่าการไฟน์จูนแบบเต็มรูปแบบ แต่การเพิ่มค่าแรงก์และปรับอัตราการเรียนรู้จะช่วยลดช่องว่างได้เกือบทั้งหมดในงานการปรับแต่งด้วยคำสั่ง (instruction-tuning)

วิธีการ PEFT ได้แก่:

• LoRA (Low-Rank Adaptation): จุดเริ่มต้นที่นิยมใช้ โดยจะตรึงค่าน้ำหนักเดิมไว้และฝึกพารามิเตอร์อะแดปเตอร์ชุดเล็กๆ ที่เพิ่มเข้ามา ซึ่งมักมีจำนวนไม่ถึง 1% ของทั้งหมด จึงรันบน GPU ระดับผู้บริโภคเพียงตัวเดียวได้
• QLoRA (Quantized Low-Rank Adaptation): บีบอัดโมเดลพื้นฐานให้มีความแม่นยำระดับ 4 บิตก่อนใช้ LoRA ซึ่งช่วยให้คุณไฟน์จูนโมเดลขนาดใหญ่บน GPU ตัวเดียวได้

นอกจากนี้ เรายังใช้วิธีการปรับแต่งด้วยคำสั่ง (instruction-tuning) และการปรับแต่งตามความชอบ (preference-tuning) ตั้งแต่ RLHF (Reinforcement Learning from Human Feedback) ไปจนถึงทางเลือกที่เบากว่า เช่น Direct Preference Optimization (DPO) และ Odds Ratio Preference Optimization (ORPO) เพื่อกำหนดวิธีที่โมเดลทำตามคำสั่งและตอบสนองความชอบของมนุษย์

วิธีไฟน์จูน LLM ทีละขั้นตอน

เมื่อคุณตัดสินใจแล้วว่าการไฟน์จูน LLM เป็นทางเลือกที่ถูกต้อง ต่อไปนี้คือเวิร์กโฟลว์

ขยาย

ขั้นตอนที่ 1: กำหนดงานและวิธีวัดความสำเร็จ

ตัดสินใจว่าคุณต้องการพฤติกรรมแบบใดจาก LLM และคุณจะรู้ได้อย่างไรว่าได้ผลตามนั้นแล้ว

ระบุงานที่เฉพาะเจาะจงที่คุณต้องการให้โมเดลที่ผ่านการไฟน์จูนทำ เช่น การจัดประเภทตั๋วฝ่ายสนับสนุน การสรุปสัญญาในรูปแบบที่กำหนดตายตัว หรือการสร้างโค้ดตามสไตล์ขององค์กรคุณ

จากนั้นกำหนดเกณฑ์ความสำเร็จ ตัวเลือกที่พบบ่อย ได้แก่:

• ความถูกต้องของเอาต์พุต: ตัวอย่างเช่น ผลลัพธ์แยกวิเคราะห์เป็น JSON ที่ถูกต้องได้หรือไม่ หรือตรงกับโครงสร้าง Markdown ที่คุณต้องการหรือไม่
• คะแนนอัตโนมัติ: ใช้ตัวชี้วัดอย่าง BLEU หรือ ROUGE ที่เปรียบเทียบข้อความที่สร้างขึ้นกับคำตอบอ้างอิง หรือใช้ความแม่นยำของงานบนชุดข้อมูลที่ติดป้ายกำกับแล้ว
• การให้คะแนนโดยมนุษย์: เกณฑ์การให้คะแนนแบบมีคะแนนหรือแบบผ่าน/ไม่ผ่าน สำหรับคุณลักษณะที่สคริปต์ประเมินได้ไม่ดี เช่น โทนหรือความเป็นประโยชน์
• ความน่าเชื่อถือกับอินพุตที่ยาก: โมเดลรับมือกับอินพุตที่ผิดปกติซึ่งเคยทำให้โมเดลพื้นฐานผิดพลาดได้หรือไม่

ขั้นตอนที่ 2: เตรียมชุดข้อมูล

คุณภาพของข้อมูลเป็นตัวกำหนดความสำเร็จของการไฟน์จูน ดังนั้นจึงควรทุ่มเทในการรวบรวมชุดข้อมูลสำหรับการไฟน์จูนที่เหมาะสม

จัดรูปแบบข้อมูลเป็นคู่คำสั่ง/คำตอบในรูปแบบ JSONL โดยแต่ละบรรทัดมีอินพุต (รวมถึงบริบทใดๆ) และเอาต์พุตที่ตรงตามที่คุณต้องการ

ตัวอย่างเช่น ลองดูชุดข้อมูลสาธารณะอย่างชุดข้อมูลคำสั่งทั่วไป Alpaca-cleaned หรือ Dolly ของ Databricks หรือชุดข้อมูลเฉพาะงานอย่าง banking77 ซึ่งประกอบด้วยคำถามจริงจากฝ่ายสนับสนุนกว่า 13,000 รายการที่ติดป้ายกำกับไว้ครอบคลุม 77 เจตนา

สำหรับงานที่เจาะจง ตัวอย่างที่สะอาดและหลากหลายเพียงไม่กี่ร้อยถึงไม่กี่พันรายการก็สามารถเปลี่ยนพฤติกรรมได้ ตราบใดที่ตัวอย่างสะท้อนอินพุตจริงในระบบที่ใช้งานจริง รวมถึงกรณีพิเศษ และมีรูปแบบที่สม่ำเสมอ

ยังไม่มีคู่อินพุต/เอาต์พุตใช่ไหม? สร้างชุดข้อมูลจากข้อมูลที่คุณมีอยู่แล้ว เช่น ตั๋วฝ่ายสนับสนุนพร้อมคำตอบที่ดีที่สุด หรือเอกสารพร้อมบทสรุป

หากคุณมีเพียงเอาต์พุต ให้ใช้โมเดลที่แข็งแกร่งกว่าสร้างอินพุตที่สมเหตุสมผลสำหรับแต่ละรายการ หรือเขียนชุดตัวอย่างตั้งต้นขนาดเล็กด้วยตนเองแล้วขยายด้วยโมเดล "ครู" ที่ใหญ่กว่า จากนั้นเก็บคู่ที่ดีที่สุดไว้

ปิดท้ายด้วยการแบ่งข้อมูลเป็นชุดฝึก ชุดตรวจสอบ และชุดทดสอบ เพื่อให้คุณวัดผลกับตัวอย่างที่โมเดลไม่เคยเห็นได้

ขั้นตอนที่ 3: เลือกโมเดลพื้นฐานและวิธีการ

เริ่มต้นด้วยโมเดลโอเพนซอร์สขนาดเล็กที่มีพารามิเตอร์ 3 ถึง 7 พันล้านตัว และวิธีการไฟน์จูนแบบประหยัดพารามิเตอร์อย่าง LoRA หรือ QLoRA

ตระกูลโมเดลแบบเปิดอย่าง Llama, Mistral และ Qwen มอบโมเดลพื้นฐานที่แข็งแกร่งซึ่งคุณโฮสต์เองได้ และวิธีการ PEFT ช่วยให้ความต้องการด้านฮาร์ดแวร์อยู่ในระดับต่ำ: QLoRA จะควอนไทซ์โมเดลพื้นฐานเป็น 4 บิต การไฟน์จูนโมเดล 7B จึงใช้เพียงการ์ดระดับผู้บริโภคขนาด 16-24GB เท่านั้น ส่วนการไฟน์จูนแบบเต็มรูปแบบกับโมเดลเดียวกันต้องใช้หน่วยความจำมากกว่านั้นหลายเท่า

ขั้นตอนที่ 4: ตั้งค่าไฮเปอร์พารามิเตอร์สำหรับการฝึก

ต่อไปนี้คือพารามิเตอร์สำคัญในการไฟน์จูน LLM และช่วงค่าเริ่มต้นที่แนะนำ:

• อัตราการเรียนรู้ (Learning rate) ควบคุมขนาดของการอัปเดตค่าน้ำหนักแต่ละครั้ง งานวิจัยปี 2024 โดย Biderman และคณะ พบว่าอัตราที่ดีที่สุดของ LoRA สูงกว่าของการไฟน์จูนแบบเต็มรูปแบบประมาณสิบเท่า โดยทั่วไปอยู่ที่ 5e-5 ถึง 5e-4 เทียบกับ 1e-5 ถึง 5e-5 งานวิจัยนี้แนะนำให้ทดลองไล่ค่าตั้งแต่ 1e-5 ถึง 5e-4 และใช้ค่าสูงสุดที่ยังฝึกได้อย่างเสถียร
• ขนาดแบตช์ (Batch size) คือจำนวนตัวอย่างที่โมเดลเรียนรู้ก่อนการอัปเดตน้ำหนักแต่ละครั้ง บน GPU ตัวเดียว ให้ใช้แบตช์ต่ออุปกรณ์ขนาดเล็ก 1 ถึง 8 ร่วมกับการสะสมเกรเดียนต์ (gradient accumulation) เพื่อให้ได้ขนาดแบตช์ที่มีผลจริงประมาณ 16 ถึง 64
• จำนวนอีพ็อก (Number of epochs) คือจำนวนครั้งที่โมเดลได้เห็นชุดข้อมูลทั้งหมด เมื่อฝึกโมเดลให้ทำงานเฉพาะด้าน การใช้ 1-3 อีพ็อกถือเป็นหลักทั่วไปที่ดี แต่การรัน LoRA มักต้องใช้มากกว่านั้น
• LoRA rank (r) กำหนดความจุของอะแดปเตอร์ หรือปริมาณที่อะแดปเตอร์สามารถเรียนรู้ได้ ให้เริ่มที่ 8 ถึง 32 สำหรับงานที่ง่ายกว่า และเพิ่มขึ้นสำหรับงานที่ยากกว่า: ในงานศึกษา LoRA ของ Biderman et al. ที่อ้างถึงข้างต้น การทำ instruction tuning โมเดล 7B สำหรับงานโค้ดต้องใช้ rank 256 จึงจะเทียบเท่าการไฟน์จูนแบบเต็มรูปแบบ ขณะที่ rank 64 ให้ผลใกล้เคียงสำหรับงานคณิตศาสตร์
• ความยาวลำดับสูงสุด (Maximum sequence length) คืออินพุตที่ยาวที่สุดที่การรันจะประมวลผล ให้ตั้งค่าให้ครอบคลุมตัวอย่างที่ยาวที่สุดของคุณ โดยไม่เกินหน้าต่างบริบท (context window) ของโมเดล เพราะส่วนที่ยาวเกินจะถูกตัดทิ้ง
• Warmup และ schedule ควบคุมวิธีที่อัตราการเรียนรู้ค่อยๆ เพิ่มขึ้นและเปลี่ยนแปลงตลอดการรัน ค่าเริ่มต้นที่ใช้กันทั่วไปคือ warmup ระยะสั้นและ cosine decay อย่างไรก็ตาม งานศึกษาโมเดลขนาดเล็กของ Pareja et al. พบว่าการตัด warmup ออกไม่ได้ทำให้คะแนนสุดท้ายแย่ลง

ให้ถือว่าค่าเหล่านี้เป็นจุดเริ่มต้นสำหรับการสวีป (sweep) ไม่ใช่ค่าที่ตายตัว

ขั้นตอนที่ 5: ฝึกโมเดลและติดตามค่า loss

ระหว่างการฝึก ให้สังเกตกราฟ training loss และ validation loss เพื่อดูว่าการฝึกได้ผลหรือไม่

Loss วัดว่าเอาต์พุตของโมเดลห่างจากตัวอย่างของคุณมากเพียงใด และควรลดลงอย่างราบรื่นเมื่อการรันดำเนินไป Training loss คำนวณจากข้อมูลที่โมเดลใช้เรียนรู้ ส่วน validation loss คำนวณจากตัวอย่างที่กันไว้ (held-out)

หาก training loss และ validation loss ลดลงไปพร้อมกัน แสดงว่าโมเดลกำลังเรียนรู้ที่จะนำไปใช้กับข้อมูลทั่วไปได้ (generalize) หาก training loss ยังคงลดลงแต่ validation loss ทรงตัวหรือเพิ่มขึ้น แสดงว่าโมเดลกำลังจดจำชุดข้อมูลฝึกแทนที่จะเรียนรู้รูปแบบ (overfitting)

ขยาย

ขั้นตอนที่ 6: ประเมินผล แล้วจึงนำไปใช้งาน

Training loss ที่ต่ำไม่ได้รับประกันว่าเอาต์พุตจะถูกต้อง ดังนั้นให้ประเมินโมเดลที่ไฟน์จูนแล้วตามเกณฑ์ที่คุณกำหนดไว้ในขั้นตอนที่ 1

เมื่อโมเดลผ่านการประเมินแล้ว คุณมีสองวิธีในการนำไปใช้งาน:

• เสิร์ฟอะแดปเตอร์ควบคู่ไปกับโมเดลพื้นฐาน และโหลดทั้งสองส่วนขณะรันไทม์ วิธีนี้ทำให้ยังสลับเปลี่ยนอะแดปเตอร์ได้
• ผสานอะแดปเตอร์เข้ากับน้ำหนักของโมเดลพื้นฐาน เพื่อให้ได้โมเดลเดี่ยวแบบสแตนด์อโลนที่โฮสต์ได้ง่ายกว่า

ใช้ Perplexity เพื่อให้ LLM ของคุณเข้าถึงข้อมูลล่าสุดได้

การไฟน์จูนเป็นทางเลือกที่เหมาะสมเมื่อคุณต้องการปรับพฤติกรรมของโมเดลให้ตรงกับความต้องการของคุณ

หากโมเดลของคุณต้องใช้ข้อมูลปัจจุบัน โดยเฉพาะข้อมูลที่เปลี่ยนแปลงอย่างรวดเร็ว คุณจำเป็นต้องใช้ระบบ RAG หรือเครื่องมือค้นหาของบุคคลที่สามที่เชื่อถือได้

สแตกการดึงข้อมูล (retrieval) แบบกำหนดเองเหมาะที่สุดสำหรับชุดข้อมูลที่เป็นกรรมสิทธิ์เฉพาะ เช่น วิกิภายใน ประวัติการสนับสนุนลูกค้า สัญญา หรือเอกสารผลิตภัณฑ์ของคุณ

เมื่อความรู้ที่คุณต้องการใช้เป็นข้อมูลสาธารณะ ก็ไม่จำเป็นต้องสร้างเลเยอร์การดึงข้อมูลขึ้นมาเอง Perplexity คือเอนจินคำตอบที่ให้คำตอบพร้อมการอ้างอิงแบบอินไลน์ที่คลิกได้จากดัชนีเว็บแบบเรียลไทม์ Agent API ของ Perplexity มอบคำตอบที่อิงข้อมูลจากเว็บพร้อมการอ้างอิงเหล่านั้นได้ในการเรียกใช้เพียงครั้งเดียว เพื่อให้แอปของคุณใช้ข้อมูลจากแหล่งที่มาที่เป็นปัจจุบันได้

คำถามที่พบบ่อยเกี่ยวกับการไฟน์จูน LLM

ไฟน์จูน LLM ได้ฟรีหรือไม่

ได้ คุณสามารถไฟน์จูน LLM แบบเปิดขนาดเล็กได้ฟรี ตัวอย่างเช่น แพ็กเกจฟรีของ Google Colab ให้ GPU เพียงพอสำหรับรัน QLoRA บนโมเดลขนาด 3B ถึง 8B ซึ่งมากพอสำหรับงานที่เจาะจง คุณจะเริ่มต้องจ่ายเงินเมื่อต้องการหน่วยความจำมากขึ้น การรันที่นานขึ้น หรือโมเดลพื้นฐานที่ใหญ่เกินกว่าที่แพ็กเกจฟรีรองรับได้

คุณต้องมี GPU ของตัวเอง หรือสามารถไฟน์จูนบนคลาวด์ได้

คุณไม่จำเป็นต้องมี GPU ของตัวเองเพื่อไฟน์จูน LLM บริการแบบมีการจัดการ (managed service) และผู้ให้บริการคลาวด์ GPU ให้เช่าฮาร์ดแวร์เป็นรายชั่วโมง ดังนั้นการเช่า GPU เพียงตัวเดียวก็เพียงพอสำหรับการรัน QLoRA บนโมเดลขนาดเล็ก การซื้อ GPU จะคุ้มค่าก็ต่อเมื่อคุณไฟน์จูนบ่อยครั้ง หรือจำเป็นต้องเก็บข้อมูลทั้งหมดไว้บนเครื่องของคุณเอง

การไฟน์จูน LLM ใช้เวลานานเท่าใด

สำหรับ LLM ขนาดเล็ก การรันหนึ่งครั้งอาจเสร็จได้ภายในไม่กี่นาทีจนถึงไม่กี่ชั่วโมง ขึ้นอยู่กับขนาดชุดข้อมูลและฮาร์ดแวร์ ตัวอย่างเช่น Oumi ไฟน์จูนโมเดลขนาด 0.8B แบบเต็มรูปแบบโดยใช้เวลาเพียงหนึ่งชั่วโมงเศษ บนแพลตฟอร์มแบบโฮสต์ของตน

โมเดลที่ใหญ่ขึ้นหรือตัวอย่างหลายหมื่นรายการจะทำให้ใช้เวลานานขึ้นถึงหนึ่งวันหรือมากกว่านั้น: การรัน LoRA ของ Emburse บนโมเดล 7B ใช้เวลา 8 ชั่วโมงสำหรับตัวอย่าง 5,000 รายการ และประมาณ 30 ชั่วโมงสำหรับ 50,000 รายการบน GPU ขนาด 40GB เพียงตัวเดียว

คุณสามารถอัปเดตโมเดลที่ไฟน์จูนแล้วไปเรื่อยๆ เมื่อข้อมูลของคุณเปลี่ยนแปลงได้หรือไม่

คุณสามารถไฟน์จูนซ้ำด้วยข้อมูลใหม่ได้ แต่แต่ละรอบจะสิ้นเปลืองทรัพยากรการประมวลผลและเสี่ยงต่อการลืมแบบหายนะ (catastrophic forgetting) สำหรับความรู้ที่เปลี่ยนแปลงบ่อย RAG มักเป็นทางแก้ที่ดีกว่า เนื่องจากคุณเพียงอัปเดตเอกสารต้นทางแทนการฝึกโมเดลใหม่