- Fine-tuning กำลังกลับมาเป็นศูนย์กลางของวิธีวิทยาการพัฒนา AI อีกครั้ง โดยถูกจุดกระแสจากการเปิดตัว Tinker ของ Thinking Machines Labs และการเปลี่ยนผ่านกระบวนทัศน์ไปสู่การติดตั้งใช้งาน LLM โอเพนซอร์สแบบดูแลจัดการเอง
- Fine-tuning ซึ่งเคยลดลงจนเหลือ น้อยกว่า 10% ของเวิร์กโหลด AI inference กำลังได้รับความสนใจอีกครั้งจากแพลตฟอร์ม GPU-as-a-service, ระบบนิเวศโมเดลที่มีเสถียรภาพมากขึ้น และการแพร่หลายของโมเดลแบบ open-weight
- เทคโนโลยี LoRA(Low-Rank Adaptation) ช่วยลดต้นทุนอย่างมากโดยเพิ่มเพียงเมทริกซ์ low-rank ขนาดเล็ก แทนการฝึกพารามิเตอร์นับพันล้านตัวใหม่ทั้งหมด พร้อมคงหรือยกระดับประสิทธิภาพไว้ได้
- Tinker นำเสนออาร์กิเทกเจอร์ การเรียนรู้อย่างต่อเนื่องผ่าน online reinforcement learning โดยชี้ให้เห็นอนาคตของ fine-tuning ด้วยแนวทางที่ประเมินและปรับปรุงคำตอบของโมเดลเอง แทนการเลียนแบบคำตอบที่เขียนไว้ล่วงหน้า
- Fine-tuning กำลังพัฒนาไปไกลกว่าขั้นตอนทางเทคนิคธรรมดา สู่การเป็น ชั้นเชิงกลยุทธ์สำหรับความเป็นเจ้าของ การจัดแนว และการปรับปรุงอย่างต่อเนื่อง และคาดว่าจะเป็นแรงขับสำคัญของคอมพิวเตอร์ AI ส่วนบุคคลและการใช้งานเอเจนต์เฉพาะทาง
ภูมิหลังทางประวัติศาสตร์ของ Fine-Tuning
- Thinking Machines Labs เปิดตัว Tinker ทำให้การพูดคุยเรื่อง fine-tuning-as-a-platform กลับมาร้อนแรงอีกครั้ง
- สตาร์ตอัปที่ก่อตั้งโดย Mira Murati อดีต CTO ของ OpenAI แห่งนี้ ได้รับการประเมินมูลค่า 12 พันล้านดอลลาร์ ภายในเวลาเพียง 6 เดือนหลังการก่อตั้ง
- บริษัทวางตำแหน่งแพลตฟอร์ม fine-tuning เป็นฐานสำหรับความร่วมมือด้านการวิจัยกับมหาวิทยาลัย
- Clément Delangue จาก Hugging Face มองเห็น การเปลี่ยนผ่านกระบวนทัศน์ไปสู่การติดตั้งใช้งาน LLM แบบดูแลจัดการเอง โอเพนซอร์ส และเฉพาะทาง
- ฮาร์ดแวร์เฉพาะทางอย่าง NVIDIA DGX Spark เป็นแรงสนับสนุนแนวโน้มนี้
- Personal AI Workstation ของ a16z เป็นตัวอย่างเชิงการตลาดที่สะท้อนเทรนด์ดังกล่าว
- Fine-tuning เคยได้รับความสนใจช่วงสั้น ๆ หลังคลื่นแรกของโมเดลภาษาขนาดใหญ่ แต่ปัจจุบันลดลงอย่างรวดเร็ว จนคิดเป็น น้อยกว่า 10% ของเวิร์กโหลด AI inference
ยุคก่อน Transformer
- ก่อนการปฏิวัติของ Transformer งาน NLP พึ่งพาโมเดลเฉพาะทาง
- สถาปัตยกรรมแบบวนซ้ำ เช่น RNN และ LSTM ได้สร้างความก้าวหน้าในระยะแรก
- เป็นครั้งแรกที่โมเดลสามารถ เรียนรู้จากลำดับคำโดยตรง แทนการใช้คุณลักษณะภาษาที่มนุษย์ออกแบบเอง
- แต่ละแอปพลิเคชันต้องเริ่มต้นใหม่จากศูนย์ด้วยข้อมูลเฉพาะงาน
การมาของ Transformer และการวางรากฐานวิธีวิทยา Fine-Tuning
- ในปี 2017 งานวิจัย Attention Is All You Need ของ Google ได้แนะนำสถาปัตยกรรม Transformer
- แทนที่การวนซ้ำและคอนโวลูชันด้วย self-attention เพียงอย่างเดียว
- เจ็ดเดือนต่อมา ULMFiT ได้พิสูจน์ว่าโมเดลภาษาที่ pretrain ไว้ล่วงหน้า (ซึ่งในเวลานั้นยังอิง LSTM) สามารถนำมา fine-tune สำหรับงานหลากหลายประเภทได้
- สิ่งนี้วาง รากฐานเชิงวิธีวิทยา ที่ทำให้ Transformer ใช้งานได้จริง
- หนึ่งปีต่อมา BERT และ GPT-1 ได้นำแนวทางนี้ไปใช้จริง
- BERT ใช้ด้าน encoder ที่มี bidirectional attention สำหรับงานความเข้าใจ
- GPT ใช้ด้าน decoder ที่มี unidirectional attention สำหรับงานการสร้างข้อความ
- โดยเฉพาะ BERT ได้เปลี่ยนโฉมวัฒนธรรม NLP
- แทนที่จะสร้างทุกโมเดลขึ้นใหม่จากศูนย์ นักวิจัยหันมา fine-tune Transformer ที่ pretrain ไว้แล้ว เพื่อให้ได้ผลลัพธ์ที่ก่อนหน้านี้ต้องใช้เวลาหลายเดือนกับการทำ feature engineering ด้วยมือ
ข้อจำกัดของ Full Fine-Tuning และการมาของ LoRA
- เมื่อจำนวนพารามิเตอร์พุ่งจากระดับหลักล้านสู่ หลักแสนล้าน การทำ fine-tuning ก็ไม่ใช่ทางเลือกที่ชาญฉลาดเสมอไปอีกต่อไป
- Full Fine-Tuning (FFT) หมายถึงการฝึกใหม่ทุกเลเยอร์และทุกค่าน้ำหนัก
- แม้จะให้ความแม่นยำสูง แต่ก็มี ต้นทุนมหาศาล
- สิ่งที่ครั้งหนึ่งเคยเป็นงาน GPU ไม่กี่ชั่วโมง กลายเป็นงานอุตสาหกรรมขนาดใหญ่
- ในปี 2021 Microsoft Research ได้เปิดตัว LoRA(Low-Rank Adaptation of Large Language Models)
- แทนที่จะฝึกพารามิเตอร์นับพันล้านตัวใหม่ LoRA จะตรึงค่าน้ำหนักเดิมไว้ และ เพิ่มเมทริกซ์ low-rank ขนาดเล็ก เข้าไปในเลเยอร์ที่เลือก
- ฝึกเฉพาะส่วนเหล่านี้ จึง ลดต้นทุนลงสู่ระดับเลขหลักเดียว ขณะยังคงหรือแม้แต่ยกระดับประสิทธิภาพเทียบกับ FFT
- LoRA กลายเป็นแนวทางมาตรฐาน
- ภายในปี 2024 สามารถ ใช้งานได้ด้วยคำสั่งเพียงบรรทัดเดียว ผ่านไลบรารี PEFT ของ Hugging Face
ความซับซ้อนของการปรับจูนไฮเปอร์พารามิเตอร์
- Fine-tuning ไม่ได้เป็นเพียงแพ็กเกจสำหรับ deploy และดูแลรักษาเท่านั้น
- ตัวการจูนเองต่างหากคือจุดที่เวทมนตร์จริงเกิดขึ้น และ ไม่มีการตั้งค่าเดียวที่ใช้ได้กับทุกอย่าง
- การปรับจูนไฮเปอร์พารามิเตอร์ เองเป็นตัวชี้ชะตาความสำเร็จหรือล้มเหลวของโมเดล
- การหาสมดุลระหว่าง rank, learning rate และสัดส่วน alpha นั้น ใกล้เคียงการเล่นแร่แปรธาตุมากกว่าวิทยาศาสตร์
- ต้องหลีกเลี่ยงทั้งอะแดปเตอร์ที่ overfit และปรากฏการณ์ที่โมเดลลืมสิ่งที่เคยรู้ไปแล้ว (catastrophic forgetting)
- เมื่อได้สิ่งที่ใช้งานได้จริง การประเมินผลก็ให้ความรู้สึก เหมือนการพยากรณ์มากกว่าการตรวจสอบยืนยัน
- ขณะเดียวกัน LLM ก็ยังพัฒนาดีขึ้นแทบทุกงานอย่างต่อเนื่อง จน เข้าใกล้ความเป็นอเนกประสงค์
- ภายในปี 2023 ทีมส่วนใหญ่ตระหนักว่า ด้วย context window ที่ใหญ่ขึ้น พวกเขาสามารถ ได้ประสิทธิภาพราว 90% ของ fine-tuning ผ่าน prompt engineering
- RAG(Retrieval-Augmented Generation) ก็เปิดทางให้โมเดลเข้าถึงฐานความรู้ภายนอกได้
- ทั้งสองแนวทางไม่ต้องฝึกใหม่ และให้ผลลัพธ์ที่ดีพอพร้อมภาระด้านปฏิบัติการที่ต่ำกว่ามาก
เหตุใด Fine-Tuning จึงกลับมาได้รับความสนใจ
- ปัจจัยที่ครั้งหนึ่งเคยทำให้ fine-tuning ดูไม่สำคัญหรือไม่มีประสิทธิภาพ กำลัง ถูกแก้ไขไปทีละข้อ
- แพลตฟอร์ม GPU-as-a-service อย่าง Together.ai ทำให้เริ่มต้น pipeline สำหรับ LoRA fine-tuning ได้แทบไร้แรงเสียดทาน
- แม้ยังมีโมเดลใหม่ออกมาอย่างรวดเร็ว แต่การเปลี่ยนแปลงในตอนนี้เป็น เชิงวิวัฒนาการ มากกว่าการปฏิวัติ
- ระบบนิเวศ open-weight อย่าง Mistral, Llama, Falcon, Yi และ Gemma มอบทางเลือกมากมายให้องค์กรสามารถเป็นเจ้าของ ตรวจสอบ และดูแลเวอร์ชันที่ fine-tune แล้วได้โดยไม่ติด vendor lock-in
- องค์กรต่าง ๆ อาจมาถึง ขีดจำกัดของสิ่งที่ทำได้ด้วยการ prompt อย่างเดียว แล้ว
- Fine-tuning จึงค่อย ๆ กลับมาอยู่ในสปอตไลต์ ไม่ใช่ในฐานะฟีเจอร์ที่กำลังฮิต แต่เป็น คันโยกเชิงกลยุทธ์สำหรับการควบคุม ความแตกต่าง และการฝังความฉลาดไว้ในตัวระบบ
Tinker ของ Thinking Machines Lab และการปรับปรุง LoRA
- Tinker ของ Thinking Machines Lab มุ่งเน้นที่ การพิสูจน์ทฤษฎีบท การให้เหตุผลทางเคมี การเรียนรู้แบบเสริมกำลังหลายเอเจนต์ และความปลอดภัยของ AI
- ในบล็อกโพสต์ LoRA Without Regret พวกเขาได้แชร์วิธีทำ fine-tuning ให้มีประสิทธิภาพยิ่งขึ้น
- แนะนำให้ใช้ LoRA กับ โมดูลเชิงเส้นทั้งหมด ไม่ใช่เฉพาะ attention layer อย่างในงานต้นฉบับ
- เน้นความสำคัญของ LoRA rank ซึ่งเป็นไฮเปอร์พารามิเตอร์ที่มักถูกมองข้าม
- แนะนำให้ตั้งค่า learning rate ที่สูงกว่าเดิมมาก (อย่างน้อย 10 เท่า) และ batch size ที่เล็กลง (สวนทางกับแนวปฏิบัติทั่วไป)
- แนะนำให้ กำหนด reward function อย่างชัดเจน ผ่านการตรวจสอบเชิงคณิตศาสตร์หรือเชิงตรรกะ
- คำแนะนำทั้งหมดถูกอธิบายไว้อย่างชัดเจนและสามารถทำซ้ำได้ใน TRL ของ Hugging Face
ความเป็นโมดูลาร์ของ Pipeline Fine-Tuning ยุคใหม่
- Pipeline fine-tuning สมัยใหม่แตกต่างจากเมื่อ 5 ปีก่อนโดยสิ้นเชิง
- มันเป็นแบบ โมดูลาร์, serverless และมีการ orchestration
- การติดตั้งใช้งานหนึ่งชุดสามารถรัน LoRA adapter หลายสิบตัว ควบคู่ไปกับโมเดลฐานได้
- แต่ละตัวแทนโทน ฟังก์ชัน หรือโดเมนเฉพาะ
- ระหว่าง inference ระบบจะ route คำขอไปยังชุด adapter ที่เหมาะสม แทนการพึ่งพาไฟล์โมเดลแบบคงที่
- ความเป็นโมดูลาร์นี้ก็ก่อให้เกิดความท้าทายของตัวเอง
- แม้แพลตฟอร์มแบบ all-in-one อย่าง Together.ai จะรับภาระงานหนักส่วนใหญ่ แต่ก็มักขาด การตั้งค่าระดับละเอียดและความสามารถด้าน observability ที่หลายทีมต้องการ
- ต้นทุนในระดับขนาดใหญ่สามารถพุ่งสูงได้อย่างรวดเร็ว
แนวทางอันเป็นเอกลักษณ์ของ Tinker
- Tinker ดูเหมือนจะ มอบข้อดีของทั้งสองฝั่ง
- ผสานความสะดวกสบายของสแตก fine-tuning ยุคใหม่ที่จัดการครบวงจร เข้ากับการควบคุมระดับละเอียดสำหรับนักวิจัย
- เปิดให้ผู้ใช้เข้าถึง API โดยตรงสู่ low-level learning primitives เพื่อ orchestrate เวิร์กโฟลว์การฝึกและอัลกอริทึมแบบกำหนดเองได้ในระดับลึกที่สุด
- และในขณะเดียวกันก็จัดการงานที่ยุ่งยากให้ด้วย
- ปัจจุบัน Tinker ยังสงวนไว้เพื่อวัตถุประสงค์ด้านการวิจัยเท่านั้น แต่คาดว่าจะเป็นแรงบันดาลใจให้แพลตฟอร์มอื่น ๆ
- แม้ปัญหาด้านโครงสร้างพื้นฐานจะค่อย ๆ กลายเป็นเรื่องในอดีต แต่อุปสรรคใหญ่เรื่อง การประเมินผล ยังเหลืออยู่
ความยากของการประเมินโมเดลและ Online Reinforcement Learning
- โมเดลนั้นประเมินได้ยากมาก
- การประเมินโดยมนุษย์ไม่สม่ำเสมอ ช้า และเหนือสิ่งอื่นใดคือมีต้นทุนสูง
- benchmark ล้าสมัยอย่างรวดเร็วและสูญเสียความเกี่ยวข้องจากการปนเปื้อนของข้อมูล
- แม้แต่วิธีอัตโนมัติอย่าง G-Eval หรือ Chatbot Arena ก็ยังก่อปัญหาของตัวเอง โดยมัก ขยายอคติและสร้างคะแนนที่ไม่เสถียร
- Benjamin Anderson เสนอว่า Tinker อาจมีส่วนหนึ่งของคำตอบ
- Tinker เปิดให้ผู้ใช้ ทำ online reinforcement learning ได้
- มันดึงผลลัพธ์การตอบจากค่าน้ำหนักโมเดลปัจจุบัน นำผลลัพธ์นั้นไปให้คะแนน แล้วอัปเดตโมเดลตามว่าคำตอบนั้นดีหรือแย่
- supervised fine-tuning สอนให้โมเดลเลียนแบบคำตอบที่เขียนไว้ล่วงหน้า ขณะที่ online RL ให้โมเดลปรับปรุงตัวเองจากการให้คะแนนคำตอบของตัวเอง
- ด้วยสถาปัตยกรรมแบบนี้ อนาคตของ fine-tuning อาจดูไม่เหมือน fine-tuning แบบเดิมอีกต่อไป
- มันเริ่มมีลักษณะคล้าย การเรียนรู้อย่างต่อเนื่อง
วิวัฒนาการเชิงกลยุทธ์ของ Fine-Tuning
- Robert Hommes จาก Moyai.ai กล่าวว่า
- "ในทางทฤษฎี fine-tuning สมเหตุสมผลมาโดยตลอด แต่ความเร็วที่แล็บปิดซอร์สขยายความฉลาดของโมเดล ทำให้มันกลายเป็น ตัวเลือกที่แย่ในทางปฏิบัติ"
- "ตอนนี้ ด้วย compute, data และ framework ที่ดีขึ้น แนวโน้มกำลัง เอนกลับไปสู่ความเฉพาะทาง อีกครั้ง"
- การเปลี่ยนผ่านไปสู่ self-hosting อาจใกล้กว่าที่คาดไว้
- Constant Razel จาก Exxa กล่าวว่า "คอมพิวเตอร์ AI ส่วนบุคคลไม่ใช่แนวคิดที่ไกลตัวอีกต่อไป"
- เทคโนโลยีกำลังดีขึ้นและเข้าถึงได้ง่ายขึ้น
- ความปลอดภัยและต้นทุนมีแนวโน้มจะเป็นแรงขับของการยอมรับในช่วงแรก
- และ fine-tuning จะทำให้เอเจนต์เฉพาะทางสมรรถนะสูงสามารถทำงานอยู่บนโครงสร้างนี้ได้
- Fine-tuning กำลังเปลี่ยนจาก การไล่ล่าความแม่นยำสูงสุดแบบ brute force ไปสู่กรอบคิดเรื่อง ความเป็นเจ้าของ การจัดแนว และการปรับปรุงอย่างต่อเนื่องที่ยึดโยงกับความใกล้ชิดและการควบคุม
- มันอาจไม่ใช่เพียงขั้นตอนทางเทคนิคอีกต่อไป แต่เป็น ชั้นเชิงกลยุทธ์ของวิธีที่ความฉลาดถูกสร้างและถูกครอบครอง
2 ความคิดเห็น
มนุษย์กลับกลายเป็นตัวถ่วงการพัฒนา AI เองเสียอย่างนั้นนะครับ นี่เป็นภาวะกลืนไม่เข้าคายไม่ออกที่น่าสนใจดีนะ 555
ความคิดเห็นจาก Hacker News
เมื่อราว 1 ปีก่อน ฉันยังมองโลกในแง่ดีอยู่ มีแม้กระทั่งกรณีที่การทำ RL-based fine-tuning ให้ผลที่มีความหมายจริง ๆ แต่พอพยายามนำไปใช้ในงานจริง กลับเจอความขัดแย้งกับเทคโนโลยีเดิมในอุตสาหกรรมอยู่มาก พอมองวิศวกร ML รอบตัวฉัน โดยเฉพาะคนที่เข้ามาทำงานหลังยุค LLM หลายคนกลับขาดความรู้ ML ที่แท้จริง อย่างมากก็เป็นสาย AI developer หรือ AI DevOps เสียมากกว่า ตัวงาน ML เองก็กำลังเปลี่ยนไปเป็นอาชีพที่ใช้ platform tools มากขึ้นเรื่อย ๆ คล้าย data engineering หรือ analytics ด้วยซ้ำ มองผิวเผินแล้ว ผลิตภัณฑ์ AI บนคลาวด์บางเจ้าถึงขั้นไม่มี metric สำหรับ evaluation มาให้ ทำให้พัฒนา ML solution แบบจริงจังแทบไม่ได้ด้วยซ้ำ แต่แทบไม่มีใครมองว่านี่เป็นปัญหาใหญ่ RL fine-tuning ต้องอาศัยรายละเอียดปลีกย่อยจำนวนมาก จุดที่ต้อง monitor และการ refinement ข้อมูล แม้แต่โมเดล ML ธรรมดาตอนนี้ก็แทบไม่มีใครเรียนกันแล้ว ช่องว่างการเรียนรู้ของ RL fine-tuning ยิ่งใหญ่กว่านั้นมาก ในทางปฏิบัติก็แทบไม่มีกรณีตัวอย่างดี ๆ ให้เห็น จึงไม่มีโอกาสเรียนรู้งานจริงผ่านรุ่นพี่ด้วย กระแสตอนนี้ยังพยายามประหยัดทั้งค่าใช้จ่ายในการจัดสรรผู้เชี่ยวชาญและการทำ data labeling ด้วย ฉันก็สงสัยว่าบริษัทจะสนับสนุนเทคนิคแบบนี้ได้นานแค่ไหน และหลังจากฉันออกไปแล้วจะยังมีใครมารับช่วงต่อกันหรือไม่ AutoML ก็ไม่เคยกลายเป็นกระแสหลัก และฉันคิดว่า RL ก็คงไม่ถูกทำให้เป็น platform ได้ง่าย ๆ ความจริงคือบริษัทส่วนใหญ่ไม่ลังเลเลยที่จะจ่ายแพงขึ้นเพื่อผลิตภัณฑ์ที่ด้อยกว่าแต่ขยายสเกลได้มากกว่า ‘ประสบการณ์’ ในวงการสุดท้ายก็คือประสบการณ์กับแพลตฟอร์มผูกขาดนั่นเอง บางครั้งใน tech stack ระบุว่าต้องการ “pytorch” แต่พนักงานที่ใช้เป็นจริง ๆ แทบไม่มี ต่อให้มีก็ใช้ไม่ได้เพราะภาระในการดูแลระบบ
ต่อให้ไม่ได้ฝึกโมเดล การทำ labeling ก็ยังจำเป็นมากสำหรับการตรวจสอบระบบให้รวดเร็วและเป็นกลาง แต่การหา label นั้นยากอยู่ตลอด บางครั้งแม้จะหา SME resource ได้แล้ว การสื่อสารเพื่อให้เขายึดเกณฑ์เดียวกันอย่างเคร่งครัดก็ยาก และ label สุดท้ายที่ได้ก็มักใช้งานลำบาก สุดท้ายฉันเลยมักลงมือทำ labeling เองโดยสมัครใจอยู่บ่อย ๆ แม้จะเข้าใจโดเมนไม่ลึกนัก แต่ก็พอรู้คร่าว ๆ ว่า “neural network ชอบอะไร” จึงช่วยลดเวลา waiting ได้มาก การปรับจูนโมเดลขนาดใหญ่ยังคงเป็นเรื่องที่อธิบายความคุ้มค่าได้ยาก บ่อยครั้งแค่รออีก 6 เดือนก็จะมี base model ที่ดีกว่าออกมา แต่ถ้าช่วงไหนโมเดลใหญ่แพงเกินไปจนไม่มีประสิทธิภาพ การ fine-tune โมเดลเล็กให้ตรงวัตถุประสงค์นั้นมีคุณค่าแน่นอน
ฉันรู้สึกว่างานวิศวกรรมจริง ๆ หรือความสามารถในการแปลงทฤษฎีซับซ้อนให้กลายเป็นระบบที่ใช้งานได้จริง ได้อ่อนแอลงไปมากในความหมายที่แท้จริง ทุกวันนี้คนจำนวนมากมีแนวโน้มจะอาศัยบริการวิศวกรรมที่เตรียมไว้แล้ว มากกว่าจะทุ่มเวลาเพื่อเพิ่มความชำนาญด้านวิศวกรรมของตนเอง ในมุมของจิตวิญญาณแบบแฮ็กเกอร์ การลองฝึกโมเดลเองบน GPU ที่คลุมเครือไม่ได้จำเป็นต้องมี ROI รองรับ เพราะวิศวกรแต่ละคนต่างโหยหาการได้เรียนรู้ความรู้ใหม่
สุดท้ายฉันคิดว่าเมื่อมีใครสักคนสร้างผลลัพธ์ที่ถูกต้องด้วยการวัดผลจริง และ Michael Lewis เขียนหนังสือเกี่ยวกับเรื่องนี้ วงจรรอบใหม่ก็จะเริ่มต้นอีกครั้ง
ฉันเองก็เห็นหลายทีมที่คาดหวังผลลัพธ์ใหญ่จาก fine-tuning แต่ในความเป็นจริงกลับได้เพียงการปรับปรุงแบบค่อยเป็นค่อยไปหรือแทบไม่มีนัยสำคัญ สุดท้ายถึงขั้นทำเป็นผลิตภัณฑ์ออกมาแล้วค่อยมาเสียใจที่ตามอัปเดต SOTA ล่าสุดไม่ทัน ฉันตั้งใจหลีกเลี่ยง fine-tuning อยู่ เพราะตัวโมเดลเองพัฒนาเร็วเกินไป จนความเร็วในการพัฒนาผลิตภัณฑ์ของบริษัทใหญ่ตามไม่ทัน
ไม่นานมานี้ฉันทำแบบสำรวจบน Twitter เกี่ยวกับกรณีที่ LLM fine-tuning สร้างมูลค่าทางเศรษฐกิจได้ ฉันถามคำถามนี้ทุก ๆ ประมาณ 6 เดือน และผลลัพธ์ส่วนใหญ่ก็น่าผิดหวังมาตลอด แต่ครั้งนี้มีคำตอบที่น่าเชื่อถือมากขึ้นกว่าก่อนหน้านี้เล็กน้อย ฉันสรุปกรณีสำคัญไว้ใน เธรด บน Twitter และสำหรับคนที่ไม่ได้ใช้ Twitter ก็แชร์ลิงก์ thread viewer ไว้ด้วย กรณีที่น่าประทับใจ เช่น Datadog ทำเวลา latency ต่ำกว่า 500ms สำหรับฟีเจอร์ค้นหาคำสั่งค้นหาด้วยภาษาธรรมชาติได้ทวีตที่เกี่ยวข้อง, ดู เอกสารทางการ ประกอบ Vercel ก็กำลังรันโมเดล custom fine-tuning สำหรับการสร้าง Next.js อัตโนมัติ และมี บล็อก ด้วย ส่วน Shopify ใช้ Vision LLM ที่ผ่านการ fine-tune สำหรับการวิเคราะห์ภาพสินค้า ดู บทความ ได้
สำหรับงาน regression นั้น fine-tuning แทบจะจำเป็น ส่วนงาน classification ก็มีประโยชน์เพราะสามารถใช้ค่าความน่าจะเป็นโดยตรงเพื่อปรับ threshold แบบ yes/no ได้
ฉันมองว่าสำหรับบริษัทส่วนใหญ่ ผลตอบแทนเทียบความเสี่ยงของ fine-tuning จะแย่กว่าที่คาดไว้ ถ้ายังสามารถยัดข้อมูลเพิ่มเข้าไปใน prompt ได้ การทำแบบนั้นกลับง่ายกว่า
ถ้าคุณมีไอเดียเกี่ยวกับกรณีใช้งานที่ fine-tuning อาจสร้างความเปลี่ยนแปลงใหญ่ได้ แต่ไม่มีเวลาหรือทรัพยากรจะทดลองเอง ฉันยินดีรับการแชร์ไอเดียแบบนี้ ตอนนี้ฉันกำลังรวบรวมกรณีเหล่านี้อยู่ แต่ตอนนี้มีกรณีจริง/ยืนยันแล้วเพียง 3 กรณีเท่านั้น
คนจำนวนมากที่พยายาม fine-tune ความรู้เฉพาะโดเมนให้ LLM มักทำพลาด เช่น ตัดหนังสือจิตวิทยาเป็นชิ้น ๆ แล้วป้อนเข้าไปเป็นข้อความอย่างเดียว วิธีแบบนั้นไม่ได้สอน “การลงมือใช้จิตวิทยา” แต่แค่ทำให้โมเดลเรียนรู้วิธี “เขียนบทนำเกี่ยวกับมัน” เท่านั้น การออกแบบ dataset ที่ผิดพลาดคือสาเหตุของความล้มเหลวในการ fine-tuning จำนวนมาก ในทางกลับกัน ถ้าโครงสร้าง dataset ถูกต้อง โมเดล 7B ก็อาจให้ประสิทธิภาพเหนือโมเดล 180B ได้
จากตัวอย่างที่ได้เห็นไม่นานมานี้ ฉันเห็นด้วยกับ OP PaddleOCR ที่มีพารามิเตอร์ 0.9B ให้ความแม่นยำใกล้ระดับ SOTA ทั้งกับข้อความ ตาราง สมการ แผนภูมิ และลายมืองานวิจัย และโมเดล 3B/8B ก็ทำงานดึง HTML เป็น JSON ได้ด้วยความแม่นยำระดับ GPT-5 โดยมีต้นทุนถูกกว่า 40~80 เท่าและ inference เร็วกว่าReddit ถ้าต้องการเพิ่มประสิทธิภาพสำหรับงานเฉพาะ fine-tuning ก็มีความหมาย
อยากรู้ว่าคุณได้ลองใช้ PaddleOCR ด้วยตัวเองหรือยัง ผมแปลกใจที่มีการอ้างว่าเป็น SOTA โดยไม่เทียบกับ Amazon Textract หรือ Azure Document Intelligence (อิงจาก LayoutLM v3) ตอนที่ผมทดลองงานรู้จำเอกสาร สองตัวนี้ดูจะอยู่ระดับแนวหน้าที่สุด
การถกเถียงนี้กลับไปเชื่อมกับประเด็นเรื่อง SLM และ LLM หรือก็คือเรื่องขนาดโมเดลอีกครั้ง SLM สามารถปรับให้เหมาะกับงานเฉพาะและชนะ LLM ได้ในงานนั้น ๆ อย่างไรก็ดี ถ้า 1. precision ไม่ได้สำคัญมากเป็นพิเศษ หรือ 2. ปริมาณทราฟฟิกไม่ได้สูงมาก คุณค่าที่ได้เมื่อเทียบกับเวลา/แรงที่ลงไปก็จะต่ำ
ในฐานะคนที่เคยก่อตั้งสตาร์ทอัปด้าน LLM fine-tuning ชื่อ Lamini ผมไม่เห็นด้วยกับ OP สมมติฐานของเราคือ fine-tuning จะใช้งานได้ง่ายกว่าการเรียน deep learning ตั้งแต่ต้นมาก เพราะเริ่มจาก LLM ที่ทรงพลังมากอยู่แล้ว เราจึงคาดว่ามันน่าจะง่ายกว่า แต่หลังจากทำโปรเจกต์จริงไปราว 20 เคส เราพบว่า fine-tuning นั้นยากและมีอุปสรรคในการเริ่มต้นพอ ๆ กับ deep learning ในโครงสร้างตลาดตอนนี้ ถ้าเป็น ML engineer ที่เก่งด้าน deep-learning-based fine-tuning ก็มักไปก่อตั้งสตาร์ทอัปเองหรือเข้าร่วม Anthropic, OpenAI ฯลฯ ได้ไม่ยาก แต่กลับกัน ทีมที่กำลังสร้างโซลูชัน LLM กลับไม่ได้ให้คุณค่ากับวิศวกรเก่ง ๆ เท่าที่ควร ผลคือทีมผู้เชี่ยวชาญที่สร้าง Claude, GPT, Qwen ฯลฯ มีความสามารถในการแข่งขันเหนือกว่าความพยายาม fine-tune ของผู้ใช้รายบุคคล ตอนนี้ RAG, prompt engineering, reasoning, AI agent, memory, SLM ล้วนเป็นโซลูชันที่ง่ายกว่าและทรงพลังกว่าอย่างมาก
อยากรู้ว่า Anthropic หรือ OpenAI ถึงขั้นพร้อมรับทุกคนที่ทำ LLM fine-tuning เป็นจริงหรือเปล่า
ผมสงสัยว่าโมเดลที่คุณ fine-tune ตอนนั้นเป็นประเภทไหน และในตอนนั้นโมเดลพัฒนาไปไกลพอที่จะ fine-tune ได้ดีหรือยัง รวมถึงมีปัญหา catastrophic forgetting หรือไม่ ตอนนี้มีโอเพนซอร์สโมเดลที่ดีกว่าเดิมมากแล้ว ถ้าออกแบบสถาปัตยกรรมโดยคำนึงถึง fine-tuning ตั้งแต่แรก ผมคิดว่าก็เอาชนะข้อเสียของรุ่นก่อน ๆ ได้ บริษัทต่าง ๆ อยากถือครองโมเดลของตัวเองมากกว่าจะไปเช่าใช้ของคนอื่น
Fine-tuning เป็นเทคนิคที่ดีและควรมีติดกล่องเครื่องมือไว้ แต่ในความเป็นจริง ขอบเขตการใช้งานที่เหมาะสมกลับแคบกว่าที่คิด ด้านหนึ่ง งาน NLP จำนวนมากมีความแม่นยำสูงอยู่แล้วด้วยความสามารถพื้นฐานของ LLM จึงไม่จำเป็นต้อง fine-tune ขณะที่อีกด้าน งานที่ซับซ้อนจริง ๆ ก็ fine-tune ยากมาก และการเก็บข้อมูลก็มีค่าใช้จ่ายสูงมากเช่นกัน สุดท้าย fine-tuning จึงเป็นโซลูชันที่เหมาะกับงานระดับกลาง ๆ ที่ทั้งความยากพอดีและการเก็บข้อมูลยังพอทำได้จริง
ผมคิดว่าน่าจะมี use case ที่เหมาะอยู่เป็นหลักหลายแสนแบบ
อยากรู้ว่ามีตัวอย่างอะไรบ้างสำหรับ task “ระดับกลาง” แบบนั้น
เว็บไซต์นี้โหลดเร็วมากจริง ๆ แม้จะเข้าใช้งานจากยุโรปก็ตาม มีการโหลดคอนเทนต์แบบไดนามิกตามการเลื่อนหน้าจอ และรูปภาพก็ถูกบีบอัดได้ดีแต่ยังคงคุณภาพไว้ การจัดองค์ประกอบของเว็บน่าประทับใจมาก
ไม่นานมานี้ผมก็เขียนบล็อกโพสต์ในหัวข้อคล้ายกันบล็อก โดยพูดถึง “LoRA Land” งานศึกษาภาคสนามขนาดใหญ่ที่ fine-tune โมเดล 7B จนเหนือกว่า GPT-4 และพูดถึงด้วยว่าในช่วง 6 เดือนที่ผ่านมา เทรนด์ของ fine-tuning เปลี่ยนไปอย่างไร
ผมสงสัยว่า LoRA adapter จะสามารถย้ายองค์ประกอบ context ต่าง ๆ ที่เดิมต้องใส่ใน prompt เสมอ เช่น มาตรฐานงาน รูปแบบการตั้งชื่อที่ชอบ เอกสารอ้างอิง คำจำกัดความ MCP ฯลฯ เข้าไปอยู่ในตัวโมเดลได้หรือไม่ วิธีสร้างข้อมูลก็น่าจะทำได้ง่าย โดยใส่ context เดิมให้มากที่สุด ทดลอง prompt ให้หลากหลาย แล้วดูว่าคำตอบแตกต่างจาก baseline อย่างไร จากนั้นผลลัพธ์นั้นก็อาจนำไปใช้ทำ fine-tuning ในรูปแบบ input=“refactor {base model output}”, output=“{full-context model output}” ได้ด้วย LoRA เดิมก็ถูกออกแบบมาให้ใช้ร่วมกันอยู่แล้ว ดังนั้น MCP ก็น่าจะกระจายเป็น adapter ที่เปิดปิดได้เช่นกัน ผมคิดว่าวิธีนี้อาจช่วยป้องกัน context poisoning ได้ด้วย
ผมเป็นผู้พัฒนา inference.net และ schematron บริษัทต่าง ๆ กำลังนำ LLM ไปใช้ในโปรดักต์จริงและให้ความสำคัญกับประสิทธิภาพมากขึ้นเรื่อย ๆ ในมุมของนักพัฒนา ต่อให้พร้อมจ่ายค่าโมเดลแพงอย่าง GPT-5-Super-AGI-Thinking-Max แต่ธุรกิจจริงก็ยังต้องคำนึงถึงประสิทธิภาพด้วย ถ้าคุณสามารถ fine-tune โมเดล Llama ขนาด 8B จากข้อมูล GPT-5 ภายใน 48 ชั่วโมง แล้วประหยัดเงินได้เดือนละ 100,000 ดอลลาร์ แน่นอนว่าทุกคนก็อยากคว้าโอกาสนั้น
ตอนนี้ดูเหมือนว่าบริษัทส่วนใหญ่ได้มาถึงขีดจำกัดที่ทำได้ด้วย prompt แบบง่าย ๆ แล้ว พวกเขาต้องการโมเดลที่เข้าใจคำศัพท์เฉพาะ น้ำเสียง ระบบการจัดหมวดหมู่ และข้อกำหนดด้าน compliance ของบริษัทนั้นอย่างแม่นยำ เรื่องความเร็วและต้นทุนก็สำคัญจริง และนี่คือเหตุผลหลักของ fine-tuning แต่เทคนิคการจัดการ context ก็ทำให้การทำงานร่วมกันเป็นไปได้เช่นกัน เมื่อ context ใหญ่ขึ้น RAG ก็เข้ามาแทน fine-tuning และช่วงหลังเพียงแค่ออกแบบ prompt ให้ดีขึ้น การใช้งานก็เพิ่มขึ้นมากแล้ว เหมือนการถกเถียงระหว่าง FPGA กับ CPU/GPU เพราะต้นทุนการพัฒนาและความเสี่ยงด้านกำหนดส่งเพื่อให้ได้ประสิทธิภาพสูงสุด ทำให้คนส่วนใหญ่ไม่ได้รับประโยชน์จาก high-end fine-tuning