คู่มือเริ่มต้นการทำ Fine-tuning: พื้นฐานและเกณฑ์การตัดสินใจสำหรับองค์กร B2B ก่อนสร้าง LLM ของตนเอง

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 คือวิธีการค้นหาข้อมูลที่เกี่ยวข้องจากฐานข้อมูลเอกสารภายนอกหรือ Vector Store แล้วนำเนื้อหานั้นไปแทรกใน Prompt เพื่อให้โมเดลสร้างคำตอบ เหมาะสำหรับการให้ข้อมูลล่าสุดหรือความรู้ภายในองค์กร และเป็นตัวเลือกแรกสำหรับงานที่เกี่ยวข้องกับข้อเท็จจริง

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

จุดเริ่มต้นในการตัดสินใจคือ "หากขาดข้อเท็จจริง (Fact) ให้ใช้ RAG, หากขาดทักษะ (Skill) ในการแสดงออกให้ใช้ Fine-tuning และหากคำสั่งง่ายๆ เพียงพอแล้วให้ใช้ Prompt" สำหรับรายละเอียดในการเลือกใช้งานเพิ่มเติม สามารถดูได้ที่ "วิธีการเลือกใช้ Fine-tuning และ 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 สามารถบันทึกแยกออกมาเป็นไฟล์อะแดปเตอร์ขนาดหลายสิบ 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 ไม่ใช่เทคโนโลยีที่ขัดแย้งกัน แต่แนวทางสมัยใหม่คือการออกแบบแผนงานโดยตั้งสมมติฐานว่าจะนำมาใช้ร่วมกัน ซึ่งสามารถสรุปเกณฑ์การตัดสินใจได้จาก 3 แกนหลัก ดังนี้:

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

แกนที่ 2 คือ ความถี่ในการอัปเดต หากเนื้อหามีการเปลี่ยนแปลงแบบรายวันหรือรายสัปดาห์ให้เลือก RAG แต่หากการอัปเดตทุกครึ่งปีหรือรายปีเพียงพอต่อความต้องการ FT ก็เป็นตัวเลือกที่ใช้ได้ สำหรับการออกแบบโครงสร้างพื้นฐานที่ใช้ RAG เป็นหลัก โปรดดูที่ "คู่มือเบื้องต้นเกี่ยวกับฐานข้อมูลเวกเตอร์" (slug: vector-database-guide)

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

ในการปฏิบัติงานจริง มักจะลงเอยด้วยการออกแบบแบบไฮบริดที่ "ใช้ FT เพื่อกำหนดพฤติกรรม และใช้ RAG เพื่อส่งข้อมูลที่เป็นข้อเท็จจริง" สำหรับการกำหนดเส้นทาง (Routing) ที่เป็นรูปธรรม โปรดดูที่ "คู่มือการออกแบบ Hybrid 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), วิธีการเรียนรู้ และปริมาณข้อมูลที่ใช้ฝึกสอน ในกรณีของการฝึกสอนโมเดลระดับ 7B ด้วย LoRA โดยใช้ข้อมูล 5,000 คู่ การประมาณการมาตรฐานจะอยู่ที่ 6 ถึง 12 ชั่วโมงโดยใช้ GPU ระดับไฮเอนด์ 1 ถึง 2 ตัว ซึ่งโดยส่วนใหญ่จะมีค่าใช้จ่ายต่อการฝึกสอนหนึ่งครั้งอยู่ในช่วงหลักแสนเยนต้นๆ ถึงหลักแสนเยนปลายๆ

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

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

หากมีการออกแบบการเลือกใช้โมเดลที่หลากหลายและการกำหนดเส้นทางการอนุมาน (Inference Routing) จะสามารถลดเวลาการทำงานของโมเดล FT ให้เหลือน้อยที่สุดได้ แนวคิดในการผสมผสานโมเดลได้กล่าวถึงไว้ใน "คู่มือการออกแบบ Hybrid 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 ไม่ควรถูกมองว่าเป็นทางเลือกว่า "ทำหรือไม่ทำ" แต่ควรถูกมองว่าเป็นหนึ่งในเครื่องมือที่ช่วยให้คุณเลือกแนวทางที่แก้ปัญหาของบริษัทได้ด้วยต้นทุนที่ต่ำที่สุด