Fine-tuning คือวิธีการปรับจูน Weight Parameters ของ Large Language Model (LLM) ที่มีอยู่เดิมด้วยการเรียนรู้เพิ่มเติม เพื่อเพิ่มประสิทธิภาพให้เหมาะสมกับงานหรือโดเมนเฉพาะทาง ในบทความนี้ เราจะมาสรุปเกณฑ์การตัดสินใจว่าบริษัท B2B ควรเริ่มพัฒนาโมเดลของตนเองหรือไม่ โดยพิจารณาจากความสัมพันธ์ระหว่าง Prompt Engineering, RAG และ PEFT

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

หลายบริษัทมักหยุดการพิจารณาเพียงเพราะภาพจำที่ว่า "Fine-tuning = ขั้นสูงและมีต้นทุนสูง" แม้ว่าการมาถึงของ PEFT/LoRA จะช่วยขยายทางเลือกให้สามารถเริ่มต้นได้ด้วยต้นทุนที่ถูกลงถึง 1 หลัก แต่การนำมาใช้โดยขาดการไตร่ตรองอาจนำไปสู่การสิ้นเปลืองงบประมาณในการพัฒนาโดยไม่จำเป็น ในกรณีที่การใช้ RAG เพียงอย่างเดียวก็เพียงพอต่อการแก้ปัญหาแล้ว

การทำ Fine-tuning เป็นเทคนิคหลักในการปรับแต่ง LLM อเนกประสงค์ให้เข้ากับบริบททางธุรกิจเฉพาะขององค์กร โดยเริ่มจากการจัดระเบียบคำจำกัดความและความสัมพันธ์กับเทคโนโลยีที่เกี่ยวข้องอย่าง Prompt Engineering และ RAG จากนั้นจะพิจารณาถึงเหตุผลเชิงโครงสร้างที่ทำให้เทคนิคนี้ได้รับความสนใจในกลุ่มบริษัท B2B

Fine-tuning (การปรับจูนแบบละเอียด) คือเทคนิคการนำโมเดลภาษาที่ผ่านการฝึกฝนล่วงหน้า (Pre-trained Language Model) มาเรียนรู้เพิ่มเติมด้วยข้อมูลของบริษัท เพื่อปรับรูปแบบการตอบโต้และการใช้คำศัพท์เฉพาะทางให้ตรงตามวัตถุประสงค์ หากเปรียบการฝึกฝนล่วงหน้าเป็นขั้นตอนการสร้าง "โมเดลที่มีความรู้ทั่วไป" การ Fine-tuning ก็เปรียบเสมือน "การฝึกอบรมในฐานะผู้เชี่ยวชาญเฉพาะด้าน"

ในเชิงเทคนิค คือการปรับปรุงค่า Weight ของโมเดลให้มีความคลาดเคลื่อนต่อข้อมูลนำเข้าน้อยลง โดยสามารถแบ่งออกเป็น 2 ประเภทหลักตามขอบเขตของพารามิเตอร์ที่ปรับปรุง ได้แก่ Full Fine-tuning ซึ่งครอบคลุมทุกเลเยอร์ และ PEFT (Parameter-Efficient Fine-Tuning) ซึ่งเป็นการเรียนรู้เพียงบางส่วนเท่านั้น

ข้อมูลที่ใช้ในการเรียนรู้ส่วนใหญ่จะเป็นข้อมูลสอน (Teacher Data) ที่จับคู่ระหว่างข้อมูลนำเข้ากับผลลัพธ์ที่ต้องการ ซึ่งเปรียบเสมือนการถ่ายทอดองค์ความรู้เชิงปฏิบัติที่บริษัทสั่งสมมาลงสู่โมเดล เช่น "ต้องตอบกลับคำถามนี้อย่างไร" หรือ "ต้องสรุปสาระสำคัญจากสัญญาฉบับนี้อย่างไร"

ในแวดวง B2B ของไทย มักมีการพิจารณาใช้เทคนิคนี้เพื่อจำลองรูปแบบการเขียนเชิงธุรกิจที่ต้องสื่อสารกับลูกค้าเป็นประจำด้วยสามภาษา ได้แก่ ภาษาญี่ปุ่น ภาษาอังกฤษ และภาษาไทย โดยกำลังได้รับความสนใจในฐานะวิธีการที่จะทำให้โมเดล LLM ทั่วไปสามารถสร้าง "สำนวนภาษาที่ใช้งานได้จริงในพื้นที่" ซึ่งเป็นสิ่งที่โมเดลทั่วไปมักทำได้ยาก

วิธีการทำให้ LLM มีความเชี่ยวชาญเฉพาะด้านสามารถแบ่งออกได้เป็น 3 วิธีหลัก ได้แก่ Prompt Engineering, RAG (Retrieval-Augmented Generation) และ Fine-tuning ทั้งสามวิธีนี้ไม่ใช่คู่แข่งกัน แต่เป็นเทคโนโลยีที่ส่งเสริมซึ่งกันและกันโดยมีจุดประสงค์ที่แตกต่างกัน

Prompt Engineering เป็นวิธีการควบคุมพฤติกรรมของโมเดลโดยการปรับแต่งคำสั่ง (Instruction) เท่านั้น โดยไม่ต้องเปลี่ยนค่าน้ำหนัก (Weight) ของโมเดล มีต้นทุนในการนำไปใช้เกือบเป็นศูนย์และสามารถตรวจสอบผลลัพธ์ได้ทันที แต่เนื่องจากต้องส่งคำสั่งที่ยาวในทุกครั้ง จึงทำให้มีต้นทุนด้าน Token และความหน่วง (Latency) เพิ่มขึ้น

RAG เป็นวิธีการที่ดึงข้อมูลที่เกี่ยวข้องจาก Document DB หรือ Vector Store ภายนอก แล้วนำเนื้อหานั้นมาแทรกใน Prompt เพื่อให้โมเดลสร้างคำตอบ เหมาะสำหรับการให้ "ความรู้" เช่น ข้อมูลล่าสุดหรือองค์ความรู้ภายในองค์กร และเป็นตัวเลือกแรกสำหรับงานที่เกี่ยวข้องกับข้อเท็จจริง (Fact)

Fine-tuning คือการเขียนทับพฤติกรรมของตัวโมเดลเอง มีประสิทธิภาพเมื่อต้องการสร้าง "ทักษะ" ไม่ใช่ความรู้ เช่น การปรับสไตล์การเขียน, รูปแบบ JSON หรือการตีความศัพท์เฉพาะทางในอุตสาหกรรม

จุดเริ่มต้นในการตัดสินใจคือ "หากขาดข้อเท็จจริง (Fact) ให้ใช้ RAG, หากขาดทักษะ (Skill) ให้ใช้ FT, และหากคำสั่งง่ายๆ เพียงพอแล้วให้ใช้ Prompt" สำหรับรายละเอียดในการเลือกใช้งานเพิ่มเติม สามารถดูได้ที่ 『ファインチューニングと RAG の選び方』(slug: fine-tuning-vs-rag-comparison)

เบื้องหลังการที่การทำ Fine-tuning กลายเป็นทางเลือกที่สมเหตุสมผลในแวดวง B2B นั้น เกิดจากการเปลี่ยนแปลงเชิงโครงสร้าง 3 ประการ

ประการแรก คือการมาถึงของ PEFT/LoRA ซึ่งช่วยลดต้นทุนการเรียนรู้ลงอย่างมหาศาล จากเดิมที่การทำ Full Fine-tuning แบบดั้งเดิมต้องใช้งบประมาณระดับหลายสิบล้านเยน แต่เมื่อใช้ LoRA ในหลายกรณีค่าใช้จ่ายสำหรับ GPU บนคลาวด์จะเหลือเพียงหลักหมื่นถึงหลักแสนเยนเท่านั้น ซึ่งอยู่ในขอบเขตที่สามารถทดลองทำ PoC ได้

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

ประการที่สาม คือบริบทของอธิปไตยทางข้อมูล (Data Sovereignty) ภายใต้กฎหมาย PDPA ของไทยและกฎหมายคุ้มครองข้อมูลส่วนบุคคลฉบับแก้ไขของญี่ปุ่น การส่งข้อมูลที่มีความละเอียดอ่อนไปยัง API ภายนอกเริ่มกลายเป็นประเด็นในการตรวจสอบ (Audit) ทำให้ตัวเลือกการใช้ Custom Model ที่รันบน On-premise หรือภายใน VPC เริ่มมีความสำคัญมากขึ้น

อย่างไรก็ตาม การได้รับความสนใจกับ "สิ่งที่บริษัทควรทำในตอนนี้" เป็นคนละประเด็นกัน ในหัวข้อถัดไปเราจะมาพิจารณาปัจจัยในการตัดสินใจกัน

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

Full Fine-tuning คือวิธีการดั้งเดิมที่ปรับจูนพารามิเตอร์ทั้งหมดของโมเดล แม้จะให้ประสิทธิภาพสูงสุด แต่ก็แลกมาด้วยความต้องการหน่วยความจำ GPU, เวลาในการประมวลผล และต้นทุนพลังงานที่มหาศาล

ในทางปฏิบัติ การทำ Full FT สำหรับโมเดลแบบ Open model ขนาด 7B จำเป็นต้องใช้ GPU ระดับไฮเอนด์หลายตัวทำงานต่อเนื่องเป็นเวลาหลายสิบชั่วโมง หากคำนวณเป็นค่าเช่า GPU บนระบบคลาวด์ ต้นทุนต่อการเทรนหนึ่งครั้งจะอยู่ที่หลักแสนถึงหลักล้านเยน

นอกจากนี้ Full FT ยังมีความเสี่ยงเรื่อง "Catastrophic forgetting" (การลืมความรู้เดิม) ซึ่งเป็นปรากฏการณ์ที่โมเดลสูญเสียความสามารถทั่วไปที่เคยเรียนรู้มาจากการ Pre-training ในขณะที่เรียนรู้งานใหม่ การรักษาความสามารถในการใช้งานทั่วไปจึงต้องอาศัยการออกแบบชุดข้อมูลแบบผสมและการควบคุม Learning rate อย่างละเอียด ซึ่งส่งผลให้ต้นทุนด้านวิศวกรรมสูงขึ้นตามไปด้วย

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

PEFT (Parameter-Efficient Fine-Tuning) คือคำเรียกโดยรวมของวิธีการปรับจูนพารามิเตอร์แบบประหยัด ซึ่งจะทำการเรียนรู้พารามิเตอร์เพียงไม่กี่เปอร์เซ็นต์หรือน้อยกว่านั้นของโมเดลทั้งหมด โดยสามารถรักษาความแม่นยำที่เพียงพอต่อการใช้งานจริงในงานธุรกิจส่วนใหญ่ได้ ในขณะที่ลดต้นทุนการเรียนรู้และต้นทุนการดำเนินงานลงได้ 1 ถึง 2 หลักเมื่อเทียบกับ Full FT

วิธีการที่เป็นตัวแทนของกลุ่มนี้คือ LoRA (Low-Rank Adaptation) และเวอร์ชันที่ผ่านการทำ Quantization อย่าง QLoRA โดย LoRA จะทำการแช่แข็ง (Freeze) โมเดลหลักเอาไว้ แล้วเพิ่มเมทริกซ์อันดับต่ำ (Low-Rank Matrix) ขนาดเล็กเข้าไปในแต่ละเลเยอร์เพื่อเรียนรู้เฉพาะส่วนนั้น ข้อดีคือสามารถปรับจูนโมเดลระดับ 7B ได้ด้วย GPU สำหรับผู้บริโภคเพียงตัวเดียว

ส่วน QLoRA เป็นวิธีการที่นำโมเดลพื้นฐานมาทำ Quantization ให้เหลือ 4-bit เป็นต้น ก่อนที่จะใส่ LoRA เข้าไป ซึ่งช่วยลดการใช้หน่วยความจำลงได้อีกครึ่งหนึ่ง จึงเป็นทางออกที่ใช้งานจริงอย่างแพร่หลายในสภาพแวดล้อมแบบ On-premise ในประเทศไทยที่มีงบประมาณ GPU จำกัด

ผลลัพธ์การเรียนรู้ของ LoRA สามารถบันทึกแยกออกมาเป็นไฟล์ Adapter ขนาดตั้งแต่หลายสิบ MB ถึงหลายร้อย MB และสามารถจัดการเป็น "ชุดไฟล์" ที่สลับใช้งานตามวัตถุประสงค์ได้ (เช่น สำหรับเอกสารงานขาย, สำหรับการแปลเชิงเทคนิค เป็นต้น) ดูรายละเอียดเพิ่มเติมได้ที่ 『PEFT 入門』(slug: peft-introduction)

การทำ Fine-tuning จะมีลักษณะที่เปลี่ยนไปตามวิธีการให้สัญญาณการเรียนรู้ (Learning Signal) โดยการแบ่งประเภทหลักๆ คือ การเรียนรู้แบบมีผู้สอน (Supervised Fine-Tuning: SFT) และระบบการเรียนรู้แบบเสริมกำลัง (Reinforcement Learning) อย่าง RLHF และ DPO

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

RLHF / DPO เป็นการให้มนุษย์เปรียบเทียบและประเมินผลลัพธ์จากหลายๆ ตัวเลือก เพื่อชี้นำโมเดลไปในทิศทางที่ "ส่งเสริมผลลัพธ์ที่พึงประสงค์มากกว่า" วิธีนี้มีประสิทธิภาพสูงในกรณีที่ "ไม่มีคำตอบที่ถูกต้องตายตัว แต่ต้องการปรับโทนหรือความปลอดภัย" อย่างไรก็ตาม เนื่องจากความยากในการรวบรวมข้อมูลประเมินผลและต้นทุนการดำเนินงานที่สูงกว่า SFT อย่างชัดเจน จึงไม่แนะนำให้ใช้ในช่วงเริ่มต้นของการนำไปใช้ในงาน B2B

DPO กำลังได้รับความนิยมในฐานะทางเลือกที่สามารถเรียนรู้ความชอบได้ด้วยข้อมูลคู่ลำดับ "พึงประสงค์/ไม่พึงประสงค์" โดยไม่ต้องสร้างลูปการเรียนรู้แบบเสริมกำลังที่ซับซ้อนเหมือน RLHF ซึ่งสามารถทำความเข้าใจได้ง่ายหากมองว่าเป็นการใช้เพื่อขัดเกลาโมเดลหลังจากทำ SFT แล้ว

สำหรับลำดับการเลือกใช้งาน แผนงานที่สมเหตุสมผลคือการทำ SFT ให้ได้ผลลัพธ์ 80% ก่อน แล้วจึงใช้ DPO หรือ RLHF เพื่อยกระดับคุณภาพของอีก 20% ที่เหลือตามความจำเป็น

ประสิทธิภาพของการทำ Fine-tuning จะแตกต่างกันอย่างมากตามประเภทของงาน การที่จะคุ้มทุนหรือไม่นั้น บ่อยครั้งไม่ได้ขึ้นอยู่กับความเหมาะสมในการเลือกเทคโนโลยี แต่ขึ้นอยู่กับการประเมินว่า "งานนั้นๆ เหมาะกับการทำ FT ตั้งแต่แรกหรือไม่" มากกว่า

การทำ Fine-tuning จะมีประสิทธิภาพสูงสุดในส่วนที่ LLM แบบทั่วไป "รู้จักคำศัพท์แต่ตีความบริบทผิด" ในบริบทของ B2B ในไทย การลงทุนใน 3 โจทย์ต่อไปนี้จะให้ความคุ้มค่าสูงสุด (ROI):

ประการแรก คือการตีความศัพท์เฉพาะทางในอุตสาหกรรมและคำศัพท์เฉพาะภายในองค์กร เช่น เอกสารการขนส่งในธุรกิจโลจิสติกส์, มาตรฐานการตรวจสอบในภาคการผลิต หรือชื่อยาในทางการแพทย์ ซึ่งมีคำศัพท์มากมายที่แม้พจนานุกรมจะรู้จัก แต่ LLM กลับไม่สามารถจัดการได้อย่างถูกต้องตามบริบทของเอกสารทั้งฉบับ การใช้ SFT (Supervised Fine-tuning) เพื่อเรียนรู้ตัวอย่างทั่วไปภายในองค์กรจะช่วยลดอัตราการตีความผิดพลาดลงได้อย่างมาก

ประการที่สอง คือการกำหนดรูปแบบการตอบกลับให้คงที่ เช่น การเขียนข้อเสนอตามเทมเพลตของบริษัท, การทำรายงานประจำตามรูปแบบที่กำหนด หรือการตอบกลับลูกค้าโดยรักษาโทนเสียงของแบรนด์ หากการเขียนคำสั่ง (Prompt) อย่างละเอียดถี่ถ้วนแล้วยังไม่สามารถลดความคลาดเคลื่อนได้ การใช้ FT เพื่อฝัง "รูปแบบ (Template)" ลงไปจะเป็นวิธีที่มีประสิทธิภาพที่สุด

ประการที่สาม คือการทำให้การส่งออกข้อมูลแบบมีโครงสร้าง (Structured Output) มีความเสถียร หากต้องการให้ส่งกลับข้อมูลในรูปแบบ JSON หรือ YAML ตาม Schema ที่กำหนดไว้อย่างถูกต้องทุกครั้ง การใช้เพียง Prompt มักจะเกิดข้อผิดพลาดหรือข้อมูลหลุดประเด็นเป็นระยะ แต่การใช้ SFT เรียนรู้ตัวอย่างที่ถูกต้องหลายร้อยถึงหลายพันรายการ จะช่วยเพิ่มอัตราการปฏิบัติตามรูปแบบได้อย่างมหาศาล

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

ตัวอย่างสำคัญที่การทำ Fine-tuning ไม่เหมาะสม คือในส่วนของโดเมนที่ความรู้มีการเปลี่ยนแปลงบ่อยครั้ง เนื่องจากความรู้ที่เรียนรู้ผ่าน FT จะถูกฝังลงในน้ำหนัก (weights) ของโมเดล การอัปเดตข้อมูลจึงจำเป็นต้องทำการเรียนรู้ใหม่ (re-training) ซึ่งการที่ระยะเวลาในการรออัปเดต (lead time) ไม่สอดคล้องกับความเร็วในการทำงานถือเป็นปัญหาสำคัญ

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

นอกจากนี้ การใช้ FT ยังไม่เหมาะสำหรับกรณีที่มีจุดประสงค์เพื่อโหลดข้อมูลข้อเท็จจริงจำนวนมหาศาล เนื่องจากหัวใจสำคัญของ FT คือ "การเรียนรู้พฤติกรรม" จึงไม่เหมาะกับการนำมาใช้เพื่อท่องจำพจนานุกรมทั้งเล่ม การใช้ RAG เพื่ออ้างอิงข้อมูลจะมีข้อได้เปรียบทั้งในด้านความแม่นยำและต้นทุนมากกว่าการให้โมเดลจำ FAQ จำนวน 100,000 บรรทัด

ยิ่งไปกว่านั้น ควรหลีกเลี่ยงการทำ FT ในสถานการณ์ที่ข้อมูลมีไม่เพียงพอ ในขั้นตอนที่มีคู่ข้อมูลสอน (training pairs) เพียงประมาณ 100 รายการ การทำ FT มีความเสี่ยงสูงที่จะเกิด Overfitting จนทำลายความสามารถเดิมของโมเดล โดยทั่วไปแล้วควรมีข้อมูลอย่างน้อยหลายร้อยถึงหลายพันรายการเพื่อให้ได้ผลลัพธ์ที่เสถียร

RAG และ FT ไม่ใช่เทคโนโลยีที่ขัดแย้งกัน แต่แนวทางที่ทันสมัยคือการออกแบบ Roadmap โดยตั้งสมมติฐานว่าจะนำมาใช้ร่วมกัน ซึ่งสามารถสรุปเกณฑ์การตัดสินใจได้จาก 3 แกนหลัก ดังนี้:

แกนที่ 1 คือ ความรู้ (Knowledge) หรือ พฤติกรรม (Behavior) หากจำเป็นต้องดึงข้อมูลที่เป็นข้อเท็จจริง ให้ใช้ RAG หากต้องการทำให้รูปแบบการเขียน สไตล์ หรือการใช้คำศัพท์เฉพาะทางมีความเสถียร ให้ใช้ FT หากต้องการทั้งสองอย่าง แนวทางมาตรฐานคือการใช้ FT เพื่อปรับจูนให้เข้ากับสไตล์ของอุตสาหกรรมนั้นๆ แล้วใช้ RAG เพื่อป้อนข้อมูลล่าสุดให้

แกนที่ 2 คือ ความถี่ในการอัปเดต หากเนื้อหามีการเปลี่ยนแปลงแบบรายวันหรือรายสัปดาห์ ให้ใช้ RAG หากการอัปเดตทุกครึ่งปีหรือรายปีเพียงพอ ก็สามารถเลือกใช้ FT ได้ สำหรับการออกแบบโครงสร้างพื้นฐานที่ใช้ RAG เป็นหลัก โปรดดูที่ 『ベクトルデータベース入門』 (slug: vector-database-guide)

แกนที่ 3 คือ ความรู้สึกด้าน Latency และต้นทุน เนื่องจาก RAG จะมีการค้นหาข้อมูลในขณะที่ทำการ Inference จึงทำให้ Response ช้าลงและมีต้นทุน Token ที่สูงขึ้น หากใช้งานบ่อยครั้ง การใช้โมเดลที่ผ่านการ FT มาแล้วเพื่อทำ Lightweight Inference จะคุ้มค่ากว่าในแง่ของ TCO แต่หากเป็นงานที่ความถี่ต่ำแต่ต้องการความแม่นยำสูง ความยืดหยุ่นของ RAG จะมีประสิทธิภาพมากกว่า

ในการทำงานจริง มักจะลงเอยด้วยการออกแบบแบบไฮบริดที่ว่า "ใช้ FT เพื่อกำหนดพฤติกรรม และใช้ RAG เพื่อป้อนข้อเท็จจริง" สำหรับการทำ Routing ที่เป็นรูปธรรม โปรดดูที่ 『ハイブリッド LLM × SLM 設計ガイド』 (slug: hybrid-llm-slm-routing-design-guide)

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

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

สิ่งแรกที่ต้องกำหนดคือรูปแบบของข้อมูล สำหรับการเรียนรู้แบบมีผู้สอน (Supervised Learning) รูปแบบ JSON Lines ที่จับคู่ระหว่างอินพุตและเอาต์พุตที่ต้องการนั้นเป็นที่นิยม โดยควรทำการสุ่มแบบแบ่งชั้น (Stratified Sampling) เพื่อไม่ให้ความหลากหลายของโจทย์ (ประเภทลูกค้า, หมวดหมู่การสอบถาม, ภาษา) ในแต่ละคู่เกิดความเอนเอียง

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

ปริมาณข้อมูลที่แนะนำคือ 500–1,000 รายการสำหรับการกำหนดรูปแบบ (Style) ให้คงที่ และ 3,000 รายการขึ้นไปสำหรับการเรียนรู้พฤติกรรมที่ซับซ้อน ทั้งนี้ กลยุทธ์ที่เน้นการรับประกันคุณภาพจะส่งผลต่อความสำเร็จโดยตรงมากกว่าการเพิ่มปริมาณข้อมูล

นอกจากนี้ ต้องไม่ลืมการจัดการข้อมูลที่มีความละเอียดอ่อน ข้อมูล PII เช่น ชื่อลูกค้า ชื่อคู่ค้า หรือเงื่อนไขสัญญา จะต้องถูกทำ Masking ก่อนเริ่มการเรียนรู้ หากละเลยอาจมีความเสี่ยงที่โมเดลจะแสดงข้อมูลบางส่วนจากชุดข้อมูลฝึกสอนออกมาในระหว่างการอนุมาน (Inference) ซึ่งจะกลายเป็นปัญหาในการปฏิบัติตาม PDPA อีกด้วย

การเลือกโมเดลพื้นฐาน (Base Model) ให้พิจารณาจาก 3 ปัจจัยร่วมกัน ได้แก่ ใบอนุญาต (License), ขนาด (Size) และสภาพแวดล้อมการใช้งาน (Deployment)

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

ในด้าน ขนาด ให้ใช้ "ขีดความสามารถขั้นต่ำที่จำเป็นสำหรับงาน" เป็นเกณฑ์ หากเป็นงานที่ค่อนข้างง่าย เช่น การสรุปความหรือการจัดหมวดหมู่ โมเดลระดับ 3B ถึง 7B ก็เพียงพอแล้วและยังช่วยลดต้นทุนในการประมวลผล (Inference cost) แต่หากต้องการการสนทนาหลายภาษาขั้นสูงหรือการใช้เหตุผลที่ซับซ้อน จึงค่อยพิจารณาระดับ 13B ถึง 70B แม้โมเดลขนาดใหญ่จะให้ความแม่นยำสูงกว่า แต่ก็จะทำให้ค่าความหน่วง (Latency) ในการประมวลผลและปริมาณการใช้หน่วยความจำ GPU เพิ่มขึ้นอย่างรวดเร็ว

การตัดสินใจเรื่อง สภาพแวดล้อมการใช้งาน (Cloud API vs On-premise Self-hosting) ตั้งแต่ต้นจะช่วยจำกัดตัวเลือกให้แคบลง ในภาคการผลิตของไทยมีกรณีการเลือกใช้ Open Model สำหรับติดตั้งแบบ On-premise เพิ่มมากขึ้น เนื่องจากข้อกำหนดเรื่องการไม่นำข้อมูลที่มีความละเอียดอ่อนออกไปภายนอก

สำหรับ ตัวชี้วัดการประเมินผล ให้เน้นไปที่ KPI ของธุรกิจตนเองเป็นหลักมากกว่าการใช้เกณฑ์มาตรฐานทั่วไป (เช่น MMLU) หากเป็นการสร้างข้อเสนอโครงการอัตโนมัติ ควรวัดผลอย่างต่อเนื่องในด้าน "อัตราการปฏิบัติตามเทมเพลต" "อัตราความถูกต้องของคำศัพท์เฉพาะทางในอุตสาหกรรม" และ "จำนวนครั้งที่ต้องส่งกลับไปแก้ไขจากการตรวจสอบโดยมนุษย์"

การเรียนรู้ไม่ใช่สิ่งที่ทำเพียงครั้งเดียวแล้วจบ แต่ต้องออกแบบให้เป็นวงจรที่รวมการประเมินผลและคำติชม (Feedback) เข้าไว้ด้วยกัน โดยให้หมุนเวียนลูป: การเตรียมข้อมูล → การเรียนรู้ → การประเมินผลอัตโนมัติ → การตรวจสอบโดยมนุษย์ → การเพิ่มข้อมูลในส่วนที่ขาด → การเรียนรู้ซ้ำ หลายๆ รอบ

ในการเรียนรู้รอบแรก ให้เริ่มจากไฮเปอร์พารามิเตอร์ที่เป็นค่าแบบอนุรักษ์นิยม (อัตราการเรียนรู้ต่ำ, จำนวน Epoch น้อย) เนื่องจากหากเกิดภาวะ Overfitting แล้วต้องมาแก้ไข จะทำให้เสียเวลาและค่าใช้จ่าย GPU โดยเปล่าประโยชน์ การค่อยๆ ปรับจูนจากจุดที่ปลอดภัยจึงให้ผลลัพธ์ที่รวดเร็วกว่าในระยะยาว

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

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

สำหรับวิธีการลดต้นทุน โปรดดูที่ 『LLM Cost Optimization Guide』 (slug: llm-cost-optimization-guide)

ต้นทุนของการทำ Fine-tuning ไม่ได้มีเพียงแค่ค่าใช้จ่ายในการเรียนรู้เบื้องต้นเท่านั้น การประเมินจากมุมมองของ TCO ซึ่งรวมถึงการดำเนินงาน การอัปเดต และการจัดการความเสี่ยงหลังการนำไปใช้งานจริง ถือเป็นสิ่งสำคัญในการขออนุมัติภายในองค์กร

จุดเริ่มต้นของการประเมินต้นทุนประกอบด้วย 3 ปัจจัย ได้แก่ ขนาดของ Base model, วิธีการเรียนรู้ (Training method) และปริมาณข้อมูลที่ใช้เรียนรู้ หากเป็นการเรียนรู้ด้วย LoRA สำหรับโมเดลระดับ 7B โดยใช้ข้อมูล 5,000 คู่ การประเมินมาตรฐานจะอยู่ที่ประมาณ 6–12 ชั่วโมง โดยใช้ GPU ระดับไฮเอนด์ 1–2 ตัว ซึ่งการเรียนรู้หนึ่งครั้งมักจะมีค่าใช้จ่ายอยู่ในช่วงหลักหมื่นปลายๆ ถึงหลักแสนเยน

ในทางกลับกัน หากใช้ Full Fine-tuning กับโมเดลขนาด 13B ขึ้นไป จำนวน GPU ที่จำเป็นและระยะเวลาในการเรียนรู้จะเพิ่มขึ้น ส่งผลให้ต้นทุนสูงขึ้นอีก 1 ถึง 2 หลัก เนื่องจากความแตกต่างของต้นทุนนั้นมีมากกว่าความแตกต่างของความแม่นยำ กฎเหล็กคือต้องตรวจสอบก่อนว่า PEFT สามารถตอบโจทย์ความต้องการได้หรือไม่

สิ่งที่มักถูกมองข้ามมากกว่าต้นทุนการเรียนรู้คือต้นทุนการอนุมาน (Inference cost) ค่าใช้จ่ายรายเดือนจะแตกต่างกันอย่างมากระหว่างการจอง GPU ไว้ใช้งานตลอด 24 ชั่วโมง กับการเรียกใช้งานแบบ Serverless เป็นครั้งคราว หากเป็นการประมวลผลแบบ Batch ที่มีความถี่ต่ำ การใช้ Serverless จะเหมาะสมกว่า แต่หากมีความถี่สูง การใช้ Container แบบเปิดใช้งานตลอดเวลาจะเป็นทางเลือกที่สมเหตุสมผลกว่า

หากออกแบบการเลือกใช้โมเดลที่หลากหลายและการทำ Inference routing จะสามารถลดเวลาการทำงานของโมเดล FT ให้เหลือน้อยที่สุดได้ แนวคิดในการผสมผสานโมเดลต่างๆ ได้กล่าวไว้ใน 『ハイブリッド LLM × SLM 設計ガイド』 (slug: hybrid-llm-slm-routing-design-guide)

FT (Fine-tuning) ไม่ใช่สิ่งที่ทำครั้งเดียวแล้วจบ แต่จะมีการเรียนรู้ใหม่ (re-training) เกิดขึ้นเป็นระยะตามการเปลี่ยนแปลงของเนื้องาน การอัปเดตข้อบังคับ และการเพิ่มบริการใหม่ หากไม่รวมวงจรการอัปเดตนี้ไว้ในการประเมินราคา จะทำให้เกิดงบบานปลายในช่วงการดำเนินงานจริง

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

ไม่จำเป็นต้องเรียนรู้ใหม่ทั้งชุด (full set) ทุกครั้ง การนำ "การเรียนรู้ต่อเนื่อง" (continual learning) มาใช้ด้วยการเพิ่มเฉพาะข้อมูลส่วนต่าง (incremental data) จะช่วยลดต้นทุนการคำนวณลงได้ถึงประมาณ 1 ใน 3 อย่างไรก็ตาม การเรียนรู้ต่อเนื่องมีความเสี่ยงสูงที่จะเกิด "การลืมแบบหายนะ" (catastrophic forgetting) จึงจำเป็นต้องมีเทคนิคการผสมข้อมูลเก่าบางส่วนเข้าไปในระหว่างการเรียนรู้ด้วย

กลไกการประเมินและการย้อนกลับ (rollback) ก็มีความสำคัญเช่นกัน ก่อนนำไปใช้งานจริงจะต้องมีการเปรียบเทียบกับเวอร์ชันก่อนหน้าโดยใช้ชุดข้อมูลประเมิน (evaluation set) ที่คงที่ เพื่อยืนยันว่าไม่มีการถดถอยของประสิทธิภาพ (regression) และควรเตรียมระบบจัดการเวอร์ชัน (version control) รวมถึงการสลับอะแดปเตอร์ (adapter switching) แบบอัตโนมัติไว้ เพื่อให้สามารถย้อนกลับไปใช้เวอร์ชันเก่าได้ทันทีหากตรวจพบความเสื่อมถอยของประสิทธิภาพ

ความเสี่ยงเฉพาะของ FT คือ "ปรากฏการณ์การจดจำ (memorization)" ซึ่งเป็นกรณีที่ข้อมูลการเรียนรู้บางส่วนถูกโมเดลจดจำและแสดงผลออกมาโดยไม่ตั้งใจในระหว่างการอนุมาน (inference) โดยมีการชี้ให้เห็นถึงความเสี่ยงที่ข้อมูลลูกค้าซึ่งประกอบด้วยชื่อเฉพาะหรือตัวเลขเฉพาะอาจถูกนำกลับมาสร้างใหม่เป็นส่วนๆ ในระหว่างการสร้างข้อความต่อเนื่องที่ยาว

มาตรการรับมือมี 3 ประการหลัก ประการแรก คือการทำ Masking ข้อมูล PII ในข้อมูลการเรียนรู้ล่วงหน้า โดยการเปลี่ยนชื่อลูกค้า ยอดธุรกรรม เงื่อนไขสัญญา ฯลฯ ให้เป็นโทเค็นหรือ ID นิรนามก่อนนำไปใช้เรียนรู้ ประการที่สอง คือการทำ Red Teaming กับโมเดลหลังการเรียนรู้ เพื่อพยายามดึงข้อมูลที่ละเอียดอ่อนออกมาผ่านทาง Prompt โดยเจตนา ประการที่สาม หากยังมีความเสี่ยงที่ข้อมูลจะรั่วไหล ให้ดำเนินการคัดข้อมูลดังกล่าวออกแล้วทำการเรียนรู้ใหม่ (Retraining)

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

ภายใต้กฎหมายคุ้มครองข้อมูลส่วนบุคคลรวมถึง PDPA ของไทย การแจ้งให้เจ้าของข้อมูลทราบและการขอความยินยอมเมื่อต้องใช้ข้อมูลที่ละเอียดอ่อนในการเรียนรู้ถือเป็นประเด็นสำคัญ การดึงทีมกฎหมายและทีมกำกับดูแลการปฏิบัติงาน (Compliance) เข้ามามีส่วนร่วมตั้งแต่เนิ่นๆ และการจัดทำเอกสารนโยบายการใช้ข้อมูลให้เป็นลายลักษณ์อักษร จะช่วยป้องกันการต้องย้อนกลับไปแก้ไขงานในขั้นตอนหลังได้เป็นอย่างดี

การตัดสินใจว่าจะก้าวเข้าสู่การทำ Fine-tuning หรือไม่นั้น มีแง่มุมของการตัดสินใจเชิงบริหารมากกว่าการตัดสินใจเชิงเทคนิค ต่อไปนี้คือรายการหัวข้อที่ควรตรวจสอบในที่ประชุมพิจารณาภายใน หากยังไม่สามารถตอบ "Yes" ได้ในทุกหัวข้อ การคงไว้เพียงเฟสของการทำ RAG และ Prompt Engineering เพื่อสร้างผลลัพธ์ก่อนถือเป็นทางเลือกที่มั่นคงกว่า

ประการแรก ลักษณะของโจทย์ สิ่งที่ต้องการคือ "ความเสถียรของพฤติกรรมและสไตล์" หรือ "ความรู้ที่เป็นข้อเท็จจริงล่าสุด" หากเป็นอย่างหลัง RAG จะเป็นตัวเลือกแรก และมักไม่จำเป็นต้องทำ FT

ประการที่สอง ข้อกำหนดด้านข้อมูล สามารถเตรียมคู่ข้อมูลสอน (Teacher pairs) คุณภาพสูงได้อย่างน้อยหลายร้อยรายการ หรือถ้าเป็นไปได้ควรเป็นหลายพันรายการหรือไม่ และอยู่ในสถานะที่สามารถสกัดออกมาจากบันทึกการดำเนินงาน (Operation logs) ที่สะสมไว้ภายในบริษัทได้หรือไม่

ประการที่สาม งบประมาณสำหรับ PoC สามารถวางแผนงบประมาณสำหรับการทำ PoC โดยอิงตาม LoRA ไว้ที่หลักแสนต้นๆ ถึงหลักแสนกลางๆ ได้หรือไม่ และสำหรับการขยายผล (Scale out) ไปสู่ Full FT สามารถคาดการณ์งบประมาณที่สูงขึ้นอีก 1 หลักได้หรือไม่

ประการที่สี่ โครงสร้างการดำเนินงาน สามารถจัดหาทรัพยากรวิศวกรภายในหรือพันธมิตรภายนอกที่สามารถดำเนินการฝึกฝนใหม่ (Re-training), การประเมินผล และการย้อนกลับ (Rollback) ได้อย่างสม่ำเสมอหรือไม่

ประการที่ห้า ข้อกำหนดด้านการปกป้องข้อมูลและการปฏิบัติตามกฎระเบียบ (Compliance) สามารถสร้างความสอดคล้องกับ PDPA และกฎระเบียบภายในบริษัท รวมถึงได้ตกลงแนวทางการจัดการข้อมูลที่ละเอียดอ่อนกับฝ่ายกฎหมายเรียบร้อยแล้วหรือไม่

โครงการที่สามารถตอบ Yes ได้ครบทั้ง 5 หัวข้อนั้นถือว่าคุ้มค่าที่จะลงทุนทำ FT หากมีข้อใดข้อหนึ่งที่เป็น No ให้จัดลำดับความสำคัญไปที่การเตรียมการเพื่อเติมเต็มในหัวข้อนั้นก่อน

นี่คือคำตอบโดยสรุปสำหรับคำถามที่พบบ่อยจากลูกค้าเมื่อพิจารณาเรื่องการทำ Fine-tuning ในหน้างาน B2B

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

Q2: ต้องใช้ข้อมูลจำนวนเท่าใดจึงจะเห็นผล? เกณฑ์มาตรฐานคือ 500–1,000 รายการสำหรับการกำหนดสไตล์ที่เสถียร และ 3,000 รายการขึ้นไปสำหรับการเรียนรู้พฤติกรรมที่ซับซ้อน ทั้งนี้ การรับประกันคุณภาพของข้อมูลคู่ (Pair) ส่งผลโดยตรงต่อผลลัพธ์มากกว่าการเพิ่มจำนวนข้อมูล

Q3: หากบริษัทไม่มีวิศวกร จะสามารถทำได้หรือไม่? ปัจจุบัน LoRA/QLoRA มีบริการแบบ Managed Service มากขึ้น หากเตรียมข้อมูลได้ การเทรนก็สามารถจ้างทำภายนอกได้ง่าย อย่างไรก็ตาม การออกแบบการประเมินผล การควบคุมคุณภาพข้อมูล และการดำเนินงานอย่างต่อเนื่อง จำเป็นต้องอาศัยความรู้ความเข้าใจภายในองค์กร

Q4: มีความเสี่ยงที่ความสามารถทั่วไปจะลดลงหลังจากทำ FT หรือไม่? ในการทำ Full FT มีความเสี่ยงสูงที่จะเกิด Catastrophic Forgetting แต่หากใช้ LoRA จะไม่มีการปรับเปลี่ยนน้ำหนัก (Weights) ของ Base Model ทำให้ผลกระทบมีจำกัด การนำการประเมินด้วย General Benchmark มาใช้เป็น Regression Test จะช่วยให้ปลอดภัยยิ่งขึ้น

Q5: ควรเริ่มจาก RAG หรือ FT ก่อน? ในเกือบทุกกรณี ควรเริ่มจาก RAG ก่อน การขาดความรู้ที่เป็นข้อเท็จจริงสามารถแก้ไขได้ด้วย RAG และเมื่อพบปัญหาเรื่อง "พฤติกรรมหรือรูปแบบ" ที่ยังคงเหลืออยู่ จึงค่อยพิจารณาทำ FT ตามลำดับ ซึ่งเป็นวิธีที่ปลอดภัยทั้งในด้านความคุ้มค่าของการลงทุนและความต่อเนื่องในการดำเนินงาน

การทำ Fine-tuning จะแสดงประสิทธิภาพได้ดีที่สุดในกรณีที่ข้อจำกัดของ LLM แบบทั่วไปกระจุกตัวอยู่ที่ "พฤติกรรม สไตล์ และการใช้ศัพท์เฉพาะทาง" ในทางกลับกัน หากโจทย์คือการดึงข้อมูลล่าสุดหรือการอัปเดตความรู้ที่เป็นข้อเท็จจริง ควรพิจารณาการใช้ RAG และ Prompt Engineering ก่อน

การตัดสินใจสำหรับองค์กร B2B จะกลายเป็นเรื่องง่ายหากแบ่งออกเป็น 3 ขั้นตอน ขั้นตอนแรกคือการใช้ RAG + Prompt Engineering อย่างเต็มรูปแบบเพื่อจัดการในส่วนของความรู้ที่เป็นข้อเท็จจริง ขั้นตอนที่สอง หากปัญหาที่เหลือยังคงกระจุกตัวอยู่ที่ "ความไม่เสถียรของพฤติกรรม" "ความไม่สม่ำเสมอของรูปแบบ" และ "การจัดการศัพท์เฉพาะทางในอุตสาหกรรม" จึงค่อยเริ่มทำ PoC ขนาดเล็กโดยใช้ PEFT/LoRA และขั้นตอนที่สาม เมื่อ PoC ในขั้นตอนที่สองประสบความสำเร็จและมีเงื่อนไขครบทั้ง 3 ประการ ได้แก่ ข้อมูล ระบบการดำเนินงาน และงบประมาณ จึงค่อยพิจารณาลงทุนใน Full FT หรือการพัฒนาโมเดลเฉพาะของตนเองอย่างเต็มรูปแบบ

จากประสบการณ์หน้างานของบริษัทเราที่ให้การสนับสนุนการนำ AI มาใช้ในองค์กร B2B ในประเทศไทย พบว่าโครงการส่วนใหญ่สามารถบรรลุผลลัพธ์ที่เพียงพอได้ตั้งแต่ขั้นตอนที่สอง การขยายผลไปสู่ Full FT นั้นจำกัดอยู่เพียงบางกรณีที่ความเป็นเอกลักษณ์ส่งผลโดยตรงต่อความสามารถในการแข่งขันทางธุรกิจ และมีข้อกำหนดด้านอธิปไตยของข้อมูล (Data Sovereignty) ที่เข้มงวดเท่านั้น

การทำ Fine-tuning ไม่ควรถูกมองว่าเป็นทางเลือกว่า "ทำหรือไม่ทำ" แต่ควรถูกมองว่าเป็นหนึ่งในเครื่องมือที่ช่วยให้คุณเลือกแนวทางที่แก้ปัญหาของบริษัทได้ด้วยต้นทุนที่ต่ำที่สุด