ทุกคนต่างก็มีความเห็นเกี่ยวกับการทำ fine-tuning เทียบกับ RAG ลองเลื่อนดูในฟอรัม AI ไหนก็ได้ คุณจะพบกระทู้ที่ถกเถียงกันอย่างเผ็ดร้อน เต็มไปด้วยแผนภาพสถาปัตยกรรมและข้อกล่าวอ้างเรื่องผลทดสอบ (benchmark) คนส่วนใหญ่ที่เขียนคอมเมนต์เหล่านั้นไม่เคยฝึกสอน (train) โมเดลด้วยข้อมูลของตัวเอง หรือไม่เคยเห็น RAG pipeline ล้มเหลวเงียบๆ ในขั้นตอนการใช้งานจริง (production)

ผมใช้เวลาหลายเดือนในการทำการทดลอง รวมทั้งหมด 12 ครั้งพอดี ผมทำ fine-tuning ทั้ง LLMs และ embedders รวมถึงสร้างการตั้งค่า RAG ที่แตกต่างกันถึง 6 รูปแบบ ขอบเขตคือการทำนายทางการเงิน โดยเฉพาะการพยายามพยากรณ์ผลลัพธ์ของตลาดที่มีสัญญาณรบกวน (noisy) จากข้อมูลประวัติศาสตร์ที่ยุ่งเหยิง ผมใช้มาตรฐานทางสถิติที่เข้มงวดกับตัวเอง เพราะผมต้องการคำตอบที่แท้จริง ไม่ใช่แค่คำกล่าวอ้างในบล็อก

การทดลองส่วนใหญ่ล้มเหลว แต่ความล้มเหลวเหล่านั้นกลับมีประโยชน์มากกว่าความสำเร็จที่เกิดจากโชคช่วยเสียอีก

ความจริงอันโหดร้ายเกี่ยวกับสัญญาณ (Signal)

ก่อนจะลงรายละเอียด นี่คือบทเรียนที่เชื่อมโยงทุกอย่างเข้าด้วยกัน Fine-tuning และ RAG เป็นเครื่องมือสำหรับเปลี่ยนสิ่งที่โมเดลรู้หรือสิ่งที่โมเดลเห็น พวกมันไม่ใช่ไม้กายสิทธิ์ที่จะเสกสัญญาณขึ้นมาจากความว่างเปล่า หากข้อมูลพื้นฐานของคุณไม่มีรูปแบบ (pattern) ที่แท้จริงและนำไปใช้ประโยชน์ได้ เทคนิคเหล่านี้ก็จะไม่สร้างมันขึ้นมา แต่มันจะแค่ช่วยให้คุณสร้างเรื่องราวที่ดูน่าเชื่อถือขึ้นมาล้อมรอบสัญญาณรบกวน (random noise) เท่านั้น

ในการทำนายทางการเงิน กับดักนี้อันตรายเป็นพิเศษ ตลาดมีความผันผวนและมีสัญญาณรบกวนโดยธรรมชาติ เมื่อคุณนำ LLM ที่ทรงพลังมาเชื่อมกับข้อมูลราคาในอดีต แล้วเพิ่มการทำ retrieval หรือ fine-tuning เข้าไป คุณไม่ได้จะได้ความได้เปรียบ (edge) โดยอัตโนมัติ แต่คุณจะได้วิธีที่ดูมีหลักการมากขึ้นในการหาเหตุผลมารองรับการเดาสุ่มเหมือนการโยนเหรียญ หากไม่มีสัญญาณ (signal) อยู่จริง โมเดลก็จะกลายเป็นเครื่องมือที่โกหกคุณได้อย่างแนบเนียน คุณต้องตรวจสอบเรื่องนี้เป็นอันดับแรก

เมื่อโมเดลที่ใหญ่กว่ากลับเน้นจำมากกว่าเรียนรู้

ความผิดพลาดครั้งใหญ่ครั้งแรกของผมคือการทึกทักเอาเองว่าขนาด (scale) จะแก้ปัญหาได้ทุกอย่าง ผมทดสอบโมเดลขนาด 14 พันล้านพารามิเตอร์ เทียบกับโมเดลขนาด 7 พันล้านพารามิเตอร์ โดยใช้ตัวอย่างการฝึกสอนเพียง 777 ตัวอย่างพอดี โมเดลที่ใหญ่กว่ามีค่า eval_loss ที่ดีกว่าอย่างเห็นได้ชัด ค่า perplexity ลดลง หากดูจากในกระดาษ มันกำลังเรียนรู้

แต่แล้วผมก็ไปดู win rate หรืออัตราการทำนายที่ถูกต้องจริงๆ ของโมเดล ปรากฏว่าโมเดล 14B ทำผลงานได้แย่กว่าโมเดล 7B อย่างมีนัยสำคัญ มันจดจำสัญญาณรบกวน (noise) ในข้อมูลฝึกสอนไปเสียหมด ด้วยตัวอย่างที่น้อยกว่า 3,000 รายการ โมเดลที่ใหญ่กว่ามีขีดความสามารถมากพอที่จะเกิดการ overfitting กับความสัมพันธ์ที่ผิดพลาด (spurious correlations) และความผันผวนแบบสุ่มในข้อมูล มันแทบจะกลายเป็นตารางค้นหา (lookup table) ของสัญญาณรบกวนไปแล้ว

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

อย่าเชื่อใจ Loss Curve

ผมเรียนรู้ที่จะเลิกจ้องมองแต่ loss curves โมเดลสามารถปรับปรุงค่า token-level cross-entropy ให้ดีขึ้นได้ ในขณะที่ความสามารถในการตัดสินใจทางธุรกิจที่คุณสนใจกลับแย่ลง สิ่งนี้เกิดขึ้นเพราะ loss ของการทำ language modeling จะให้รางวัลกับการทำนาย token ถัดไปได้อย่างแม่นยำ ในหลายๆ โดเมน โดยเฉพาะการเงิน การตัดสินใจที่ถูกต้องกับ token ถัดไปที่มีความน่าจะเป็นสูงสุดนั้นไม่ใช่เรื่องเดียวกัน

ผมเคยเห็นโมเดลที่สามารถเลียนแบบสำนวนภาษาในข้อมูลฝึกสอนได้อย่างสวยงาม แต่กลับเลือกทิศทางการเดิมพันที่ผิดพลาดทุกครั้ง ค่า loss ลดลง แต่เงินทุน (bankroll) ก็ลดลงตามไปด้วย จงเลือกตัวชี้วัดการประเมิน (evaluation metric) ตามงานที่ต้องทำในโลกจริง หากคุณกำลังจัดลำดับเอกสาร ให้วัดคุณภาพการจัดลำดับ หากคุณกำลังทำนายผลลัพธ์ ให้วัดความแม่นยำในการตัดสินใจ อย่าปล่อยให้ eval_loss เป็นตัวเลือกโมเดลให้คุณ

Fine-Tuning จะโดดเด่นก็ต่อเมื่อใช้กับคำศัพท์ที่ไม่คุ้นเคย

ผมทำการทดลอง fine-tuning embedder กับข้อความสองประเภท ประเภทแรกคือข่าวการเงินมาตรฐานและเอกสารที่ยื่นต่อสาธารณะ ผลปรากฏว่า embedder ที่ผ่านการ fine-tuning กับเวอร์ชันสำเร็จรูป (off-the-shelf) ให้ผลลัพธ์ไม่ต่างกัน เพราะโมเดลพื้นฐานรู้จักภาษาเหล่านี้อยู่แล้ว ผมกำลังปรับจูนบนสิ่งที่มันคุ้นเคย

ชุดข้อมูลที่สองเต็มไปด้วยศัพท์เฉพาะภายใน (jargon), รหัสเรียกภายใน และคำย่อเฉพาะทางที่ไม่เคยปรากฏบนอินเทอร์เน็ต ในกรณีนี้ การ fine-tuning ช่วยเพิ่มความแม่นยำในการทำ retrieval ได้ถึง 79 เปอร์เซ็นต์ โมเดลพื้นฐานไม่รู้เลยว่าคำเหล่านี้หมายถึงอะไร การ fine-tuning จึงช่วยสอนคำศัพท์เฉพาะถิ่นให้แก่โมเดล

สิ่งนี้เปลี่ยนมุมมองต่อการทดลองทั้งหมดของผม การ fine-tuning ไม่ใช่การทำให้โมเดลฉลาดขึ้นในความหมายทั่วไป แต่มันคือการสอนคำศัพท์ใหม่ รูปแบบใหม่ หรือสไตล์การเขียนเฉพาะตัว (house style) หากข้อมูลของคุณดูเหมือนข้อมูลบนอินเทอร์เน็ต ก็ข้ามการ fine-tune ไปได้เลย แต่ถ้าข้อมูลของคุณใช้ภาษาที่โมเดลพื้นฐานไม่เคยเห็น การ fine-tuning จะกลายเป็นสิ่งจำเป็น

RAG ให้ความมั่นใจ แต่ไม่ใช่ความจริง

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

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

บทเรียนที่เจ็บปวดที่สุดมาจากการทำ backtesting กับ RAG รูปแบบหนึ่ง ซึ่งแสดงให้เห็นกำไรต่อปีที่ 11 เปอร์เซ็นต์ หากมองเพียงผิวเผิน มันดูเหมือนเป็นกลยุทธ์ที่ชนะ แต่ค่า AUC (พื้นที่ใต้เส้นโค้ง ROC ซึ่งเป็นตัววัดทักษะการจำแนกประเภท) กลับอยู่ที่ 0.486 ซึ่งแย่กว่าการโยนเหรียญเสี่ยงทาย (ซึ่งอยู่ที่ 0.500) เสียอีก กำไรที่เห็นนั้นเป็นเพียงความโชคดีในช่วงเวลาเฉพาะของตลาด ไม่ใช่ความได้เปรียบที่ทำซ้ำได้ การใช้เพียง P&L เป็นตัวชี้วัดนั้นอันตราย เพราะตลาดมักจะมอบช่วงเวลาแห่งความโชคดีให้เราเสมอ คุณจึงจำเป็นต้องมีตัวชี้วัดทักษะทางสถิติเพื่อแยกแยะระหว่างความฟลุ๊คกับความสามารถที่แท้จริง

รู้ว่าเครื่องมือแต่ละอย่างทำหน้าที่อะไรกันแน่

แล้วเรื่องนี้บอกอะไรเรา? จงใช้ fine-tuning เมื่อโมเดลจำเป็นต้องเรียนรู้คำศัพท์ใหม่ รูปแบบเฉพาะ หรือสไตล์ที่โดดเด่น จงใช้ RAG เมื่อโมเดลต้องการเข้าถึงข้อเท็จจริง คลังโค้ด (code repositories) หรือความจำขององค์กร (institutional memory) ที่อยู่นอกเหนือจากน้ำหนัก (weights) ของโมเดล อย่าใช้เครื่องมือใดก็ตามเพื่อพยายามค้นหาสัญญาณ (signal) ในข้อมูลที่ไม่มีสัญญาณอยู่เลย หากรูปแบบพื้นฐานไม่มีอยู่จริง การทำ retrieval และ fine-tuning ก็เป็นเพียงการช่วยแต่งแต้มสัญญาณรบกวน (noise) ให้ดูดีขึ้นเท่านั้น

คอขวดที่แท้จริง

โครงสร้างพื้นฐานสำหรับการทำ fine-tuning และ RAG นั้นติดตั้งได้ง่ายกว่าที่เคย คุณสามารถสร้าง pipeline ขึ้นมาได้ภายในบ่ายวันเดียว เทคนิคไม่ใช่คอขวดอีกต่อไป แต่การประเมินผล (evaluation) ต่างหากที่เป็นคอขวด ทีมส่วนใหญ่มักข้ามขั้นตอนการทำงานทางสถิติที่ยากลำบาก และไปเฉลิมฉลองให้กับ vanity metrics แทน พวกเขาปล่อยระบบที่ฟังดูฉลาดแต่กลับล้มเหลวอย่างเงียบเชียบ

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