การรวมกันของ On-premise LLM และการกลั่นกรองโมเดล (Model Distillation) คือวิธีการบีบอัดความรู้จากโมเดลภาษาขนาดใหญ่ (Teacher) ไปยังโมเดลขนาดเล็ก (Student) เพื่อให้สามารถใช้งานได้ภายในเซิร์ฟเวอร์ของบริษัทโดยไม่ต้องพึ่งพาคลาวด์ภายนอก สำหรับเจ้าหน้าที่ระบบสารสนเทศและวิศวกร AI ที่ไม่สามารถส่งข้อมูลไปยัง Cloud API ได้ บทความนี้จะอธิบายตั้งแต่การสร้างสภาพแวดล้อมไปจนถึงการนำโมเดลที่ผ่านการกลั่นกรองไปใช้งานจริง โดยเรียงลำดับตามขั้นตอนดังนี้: การเลือกโมเดล, การสร้างข้อมูล, การฝึกฝน (Training) และการหลีกเลี่ยงข้อผิดพลาด เนื้อหาถูกจัดทำขึ้นเพื่อให้ผู้ที่ไม่ใช่ผู้เชี่ยวชาญด้านการเรียนรู้ของเครื่อง (Machine Learning) สามารถเข้าใจภาพรวมได้ โดยจะมีการอธิบายคำศัพท์เฉพาะทางประกอบในแต่ละส่วน

ข้อจำกัดที่ไม่สามารถนำข้อมูลภายในองค์กรออกไปภายนอกได้ และต้นทุนที่สูงในการรันโมเดลขนาดใหญ่แบบ On-premise คือปัญหาที่การกลั่นโมเดล (Model Distillation) สามารถแก้ไขได้พร้อมกันทั้งสองประการ โมเดลนักเรียน (Student model) ที่มีขนาดเล็กลงจากการกลั่นนั้นสามารถรันบน GPU ของบริษัทได้อย่างสมเหตุสมผล และข้อมูลที่ป้อนเข้าไปจะไม่หลุดออกไปภายนอกองค์กรแม้แต่ก้าวเดียว ในส่วนนี้ เราจะมาสรุปความเสี่ยงของการใช้คลาวด์และปัญหาที่การกลั่นโมเดลเข้ามาช่วยแก้ไขให้ชัดเจนยิ่งขึ้น

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

สำหรับบริษัทที่จัดการกับแบบแปลน ซอร์สโค้ด หรือข้อมูลส่วนบุคคลที่อยู่ภายใต้การกำกับดูแล เช่น ในอุตสาหกรรมการเงิน การแพทย์ และการผลิต แม้ว่าจะมีการทำสัญญาแบบ Enterprise ที่ระบุว่า "จะไม่นำข้อมูลไปใช้ในการเรียนรู้" แต่ข้อเท็จจริงที่ว่า "ข้อมูลถูกส่งออกไปภายนอกองค์กรทางกายภาพ" ก็ยังคงทิ้งภาระความรับผิดชอบในการตรวจสอบและการปฏิบัติตามกฎระเบียบเอาไว้ หากเป็นการใช้งานแบบ On-premises จะสามารถแยกการประมวลผล (Inference) ออกจากเครือข่ายทางกายภาพ และรับประกันเชิงโครงสร้างได้ว่าข้อมูลจะยังคงอยู่ภายในองค์กร นี่คือเหตุผลพื้นฐานที่ทำให้ On-premises เป็นตัวเลือกที่ได้รับความนิยมในพื้นที่ที่มีข้อกำหนดด้านความปลอดภัยที่เข้มงวด

หากคิดว่า "ถ้าอยากเก็บข้อมูลไว้ภายในบริษัท ก็แค่รันโมเดลขนาดใหญ่แบบ On-premise ก็พอ" ก็จะพบกับกำแพงด้านต้นทุน การจะรันโมเดลขนาดใหญ่ระดับแนวหน้าแบบ On-premise โดยตรงนั้น จำเป็นต้องใช้ GPU ราคาแพงที่มี VRAM ขนาดหลายร้อย GB จำนวนหลายตัว ซึ่งไม่สมเหตุสมผลสำหรับบริษัทส่วนใหญ่

Model Distillation จะช่วยลดขนาดฮาร์ดแวร์ที่จำเป็นลงได้อย่างมาก โดยการบีบอัดความรู้จากโมเดลขนาดใหญ่ (Teacher) ไปสู่โมเดลขนาดเล็กที่มีพารามิเตอร์ระดับพันล้าน (Student) แม้จะมีข้อแลกเปลี่ยนคือประสิทธิภาพทั่วไปจะด้อยกว่าโมเดลที่เป็น Teacher แต่หากจำกัดขอบเขตไว้ที่งานเฉพาะทางที่บริษัทใช้งาน ก็สามารถรักษาความแม่นยำที่ใช้งานได้จริงไว้ได้ แม้จะมีค่าใช้จ่ายคงที่ในการซื้อ GPU แต่เนื่องจากไม่มีค่าใช้จ่ายตามปริมาณการใช้งาน (Token-based) ยิ่งใช้งานบ่อยเท่าไร ต้นทุนรวม (TCO) ก็มักจะคุ้มค่ากว่า จุดคุ้มทุนจะขึ้นอยู่กับโมเดลที่เลือกและปริมาณการใช้งาน ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องคำนวณตามปริมาณการใช้งานจริงของบริษัทตนเอง

โมเดลภาษาขนาดเล็ก (SLM: Small Language Model ขนาดตั้งแต่หลายร้อยล้านไปจนถึงหลักสิบพันล้านพารามิเตอร์) มีความเร็วในการอนุมานที่รวดเร็วและมีความหน่วง (Latency) ในการตอบสนองที่ต่ำกว่าเนื่องจากมีจำนวนพารามิเตอร์น้อยกว่า สามารถจัดการกับการประมวลผลแบบแบตช์หรือการร้องขอพร้อมกันในสภาพแวดล้อมแบบออนพรีมิสได้ง่าย และหากใช้ร่วมกับการทำควอนไทเซชัน (Quantization) ก็จะยิ่งทำให้โมเดลมีขนาดเบาลงไปอีก

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

ก่อนที่จะ "ลองทำ" การกลั่น (Distillation) จำเป็นต้องเตรียมความพร้อมใน 3 ด้าน ได้แก่ ฮาร์ดแวร์ (Hardware), ไลเซนส์ (License) และคุณภาพของข้อมูล (Data Quality) ให้มั่นคงเสียก่อน หากปล่อยให้ส่วนนี้คลุมเครือ อาจนำไปสู่ปัญหาการถูกระงับโดยฝ่ายกฎหมายหลังการฝึกสอน (Training) หรือต้องเริ่มทำใหม่เนื่องจากความแม่นยำไม่เพียงพอ

ในการฝึกฝนแบบ Distillation จะมีการใช้ GPU ทั้งในส่วนของการอนุมานโดยโมเดลครู (การสร้าง Soft label) และการเรียนรู้ของโมเดลนักเรียน ส่วนการใช้งานจริง (เฉพาะการอนุมาน) จะมีภาระงานที่เบากว่าการฝึกฝน และสามารถลดความต้องการทรัพยากรลงได้อีกด้วยการทำ Quantization

เกณฑ์ขั้นต่ำจะขึ้นอยู่กับขนาดของโมเดลนักเรียน หากเป็นระดับหลายพันล้านพารามิเตอร์ มักจะสามารถพิจารณาเริ่มต้นได้จาก GPU ขนาด 24GB จำนวน 1 ใบ ส่วนหน่วยความจำและพื้นที่จัดเก็บข้อมูลจะขึ้นอยู่กับขนาดของชุดข้อมูล เนื่องจากปริมาณ VRAM ที่จำเป็นจริงจะแตกต่างกันอย่างมากตามโมเดลและขนาดของ Batch จึงควรเริ่มจากการทำ PoC (Proof of Concept) ขนาดเล็กเพื่อวัดผลจริง แล้วจึงขยายขนาดตามผลลัพธ์นั้นจะปลอดภัยกว่า ควรหลีกเลี่ยงการซื้ออุปกรณ์ชุดใหญ่ตั้งแต่เริ่มต้น

การเลือกโมเดลครู (Teacher Model) เพียงอย่างเดียวอาจเป็นตัวตัดสินว่าจะมีประเด็นความเสี่ยงทางกฎหมายหรือไม่ ข้อควรระวังประการแรกที่ต้องคำนึงถึงคือ การนำเอาต์พุตจากโมเดลที่ให้บริการผ่าน Commercial API มาใช้เป็นข้อมูลสอน (Teacher Signal) เพื่อฝึกฝนโมเดลของบริษัทตนเองโดยตรง ผู้ให้บริการรายใหญ่ส่วนใหญ่ระบุไว้ในข้อกำหนดการใช้งาน (Terms of Service) อย่างชัดเจนว่าห้ามนำเอาต์พุตไปใช้ในการ "พัฒนาโมเดลที่แข่งขันกัน" ซึ่งหากเข้าข่ายดังกล่าวอาจถือเป็นการละเมิดข้อกำหนดได้ (ทั้ง OpenAI และ Anthropic ต่างห้ามไม่ให้นำเอาต์พุตไปใช้ฝึกฝนโมเดลเพื่อแข่งขันหรือเลียนแบบ) ในความเป็นจริงเคยมีรายงานกรณีที่เป็นปัญหาจากการละเมิดข้อกำหนดในวงกว้างมาแล้ว

วิธีที่เป็นจริงในการหลีกเลี่ยงความเสี่ยงนี้คือ การใช้โมเดล Open Source ที่มีใบอนุญาต (License) อนุญาตให้ทำ Commercial Distillation ได้มาเป็นโมเดลครู อย่างไรก็ตาม แม้จะเป็น Open Source แต่ใบอนุญาตก็มีความแตกต่างกัน โดยใบอนุญาตแบบ MIT หรือ Apache 2.0 (เช่น DeepSeek, Qwen, Mistral, Phi ฯลฯ) ค่อนข้างยืดหยุ่นและนำไปใช้เชิงพาณิชย์ได้ง่าย ในขณะที่ตระกูล Llama จะใช้ Community License เฉพาะของ Meta ซึ่งหากเป็นผู้ให้บริการที่มีจำนวนผู้ใช้งานรายเดือน (Monthly Active Users) สูงมาก อาจจำเป็นต้องขออนุญาตแยกต่างหากและมีข้อจำกัดด้านภูมิภาค ส่วน Gemma นั้นมีเงื่อนไขว่าต้องยอมรับข้อกำหนดการใช้งานของ Google ในการเลือกใช้โมเดล ต้องตรวจสอบหน้าใบอนุญาตของแต่ละโมเดล (จาก Repository หรือแหล่งเผยแพร่อย่างเป็นทางการ) ให้เป็นแหล่งข้อมูลปฐมภูมิเสมอ และต้องผ่านการตรวจสอบจากฝ่ายกฎหมาย เนื่องจากเงื่อนไขใบอนุญาตอาจมีการอัปเดต จึงไม่ควรนำข้อมูลเก่ามาอ้างอิงโดยตรง

ความแม่นยำหลังการกลั่น (Distillation) ขึ้นอยู่กับการออกแบบข้อมูลว่า "จะให้ผู้เรียน (Student) เรียนรู้อะไร" มากกว่าคุณภาพของสัญญาณจากผู้สอน (Teacher) โดยตรง ในขั้นตอนการเตรียมข้อมูล (Preprocessing) จะต้องดำเนินการกำจัดข้อมูลซ้ำ กำจัดสัญญาณรบกวนหรือคำผิดที่ชัดเจน การติดป้ายกำกับระดับความลับ และการทำให้รูปแบบข้อมูลเป็นมาตรฐานเดียวกัน

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

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

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

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

เกณฑ์การคัดเลือกที่แนะนำให้พิจารณาตามลำดับ ได้แก่ ① ไลเซนส์ (สามารถทำ Commercial Distillation ได้หรือไม่) ② ความแม่นยำในงานของบริษัท (ประเมินด้วยข้อมูลของบริษัทเอง) ③ ขนาด (สามารถรันบน GPU ที่ใช้งานจริงได้หรือไม่) ④ การรองรับภาษาญี่ปุ่นและหลายภาษา ⑤ ความคึกคักของชุมชนผู้ใช้งาน (ความง่ายในการเข้าถึงข้อมูลและการอัปเดต) ทั้งนี้ ควรให้ความสำคัญกับความสอดคล้องกับข้อจำกัดของบริษัทมากกว่าค่าคะแนนสัมบูรณ์

สำหรับโมเดลนักเรียน (Student model) การสร้างเป็นโมเดลขนาดเล็กที่เน้นเฉพาะทางจะเหมาะสมกว่าการย่อส่วนโมเดลขนาดใหญ่แบบอเนกประสงค์ลงมาทั้งชุด โดยความสัมพันธ์ระหว่างการใช้งานทั่วไปกับขนาดของโมเดลมีดังนี้: สำหรับการจำแนกประเภทเอกสารหรือการสกัดข้อมูลสำคัญ ขนาดระดับหลายร้อยล้านถึงหลักพันล้านพารามิเตอร์ (B) มักจะเพียงพอแล้ว สำหรับการทำ QA เอกสารภายในองค์กร โครงสร้างที่ใช้งานได้จริงคือการใช้ร่วมกับ RAG (Retrieval-Augmented Generation) โดยให้โมเดลนักเรียนขนาดกลางเป็นผู้รับผิดชอบส่วนการสร้างข้อความ สำหรับการสรุปความควรใช้ขนาดกลาง และสำหรับการเติมเต็มโค้ดควรใช้โมเดลที่ผ่านการเรียนรู้ล่วงหน้า (Pre-trained model) ที่เน้นด้านโค้ดโดยเฉพาะเป็นพื้นฐาน

คำว่า "เฉพาะทาง" ในที่นี้หมายถึงการนำโมเดลขนาดเล็กที่มีอยู่มากลั่นกรอง (Distillation) และปรับจูน (Fine-tuning) ด้วยงานของบริษัทตนเอง การไม่พยายามจำลองความสามารถของแชทบอทอเนกประสงค์ทั้งหมด แต่เลือกโฟกัสเพียง 1-2 งานที่ใช้จริงในการปฏิบัติงาน จะช่วยให้โมเดลขนาดเล็กสามารถบรรลุมาตรฐานที่ใช้งานได้จริงง่ายขึ้น การออกแบบที่ไม่โลภจนเกินไปจะนำไปสู่ความสมดุลระหว่างต้นทุนการดำเนินงานและความแม่นยำในท้ายที่สุด

สรุปคือ การเลือกขนาดที่เล็กที่สุดที่ตอบโจทย์ความต้องการ โดยพิจารณาจาก 2 แกนหลัก คือ "ค่าความหน่วง (Latency) ที่ยอมรับได้" และ "ความแม่นยำ (Accuracy) ที่จำเป็น" ถือเป็นแนวทางปฏิบัติมาตรฐาน

ขั้นตอนการจัดทำแผนงานคือ 1) ระบุรายการงานที่จะใช้ในองค์กร 2) กำหนดค่าความแม่นยำและค่าความหน่วงที่ต้องการสำหรับแต่ละงานให้เป็นตัวเลขมากที่สุดเท่าที่จะทำได้ และ 3) เริ่มต้นจากขนาดเล็กที่สุดแล้วค่อยๆ ปรับเพิ่มขึ้นในการทำ PoC การเลือกใช้โมเดลขนาดใหญ่ตั้งแต่เริ่มต้นจะทำให้ต้องแบกรับทั้งต้นทุนและค่าความหน่วงโดยไม่จำเป็น การหยุดขนาดของโมเดลทันทีที่ตอบโจทย์ความต้องการได้ จะส่งผลดีต่อการใช้งานจริงอย่างมาก

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

Soft Label คือการกระจายความน่าจะเป็นที่โมเดลครู (Teacher Model) มอบให้กับแต่ละคลาสหรือโทเค็น ซึ่งต่างจาก Hard Label ที่ตัดสินว่า "คำตอบมีเพียงหนึ่งเดียว" โดย Soft Label จะมีข้อมูลรวมอยู่ด้วยว่าครูมองแต่ละตัวเลือกด้วยระดับความมั่นใจเท่าใด

ขั้นตอนการสร้างมีดังนี้: 1. เตรียมข้อมูลนำเข้าที่เป็นตัวแทน 2. ทำการอนุมาน (Inference) ด้วยโมเดลครู และบันทึกค่า Logits หรือการกระจายความน่าจะเป็นของผลลัพธ์ (ในขั้นตอนนี้ให้เพิ่ม Temperature parameter ที่จะกล่าวถึงในภายหลังเพื่อทำให้การกระจายตัวราบเรียบขึ้น) 3. นำข้อมูลนี้ไปใช้เป็นเป้าหมายในการเรียนรู้ของนักเรียน (Student Model) เนื่องจาก Soft Label มีข้อมูลที่ใกล้เคียงกับ "เหตุผลที่ครูตัดสินใจเช่นนั้น" จึงช่วยให้โมเดลนักเรียนมีประสิทธิภาพในการสรุปผล (Generalization) ได้ดีกว่าการเรียนรู้ด้วย Hard Label เพียงอย่างเดียว อย่างไรก็ตาม การสร้าง Soft Label มีต้นทุนในการอนุมานของครูเข้ามาเกี่ยวข้อง จึงควรพิจารณาความสมดุลระหว่างปริมาณข้อมูลที่จำเป็นและทรัพยากรการคำนวณที่มีอยู่

การแปลงเอกสารที่กระจัดกระจายอยู่ภายในองค์กร (เช่น PDF, Office, Wiki ภายในองค์กร, ตั๋วสอบถามข้อมูล ฯลฯ) ให้เป็นข้อมูลสำหรับเรียนรู้ (Training Data) จำเป็นต้องสร้างไปป์ไลน์แบบเป็นขั้นตอน ดังนี้: ① การสกัด (Extraction): แปลงเป็นข้อความด้วย Parser หรือ OCR (สำหรับ PDF ที่บันทึกเป็นรูปภาพ การใช้ LLM แปลงเป็นข้อความถือเป็นวิธีที่มีประสิทธิภาพ) ② การทำความสะอาด (Cleansing): ลบส่วนหัว (Header) ส่วนท้าย (Footer) และข้อมูลที่ซ้ำซ้อนออก ③ การจัดโครงสร้าง (Structuring): จัดรูปแบบให้อยู่ในรูปแบบ QA หรือรูปแบบ "คำสั่ง—การตอบกลับ" (Instruction-Response) ④ การติดป้ายกำกับระดับความลับ (Sensitivity Labeling): กำหนดประเภทของข้อมูล ⑤ การแบ่งส่วน (Splitting): แบ่งข้อมูลสำหรับใช้ในการเรียนรู้ (Training) และการตรวจสอบ (Validation)

หากใช้สำหรับ RAG หัวใจสำคัญคือการแบ่ง Chunk และการสร้าง Embedding แต่หากใช้สำหรับการกลั่นกรอง (Distillation) หัวใจสำคัญคือการจัดรูปแบบให้เป็นคู่คำสั่งและคำตอบ แม้กระบวนการจะถูกทำให้เป็นอัตโนมัติ แต่ตัวอย่างข้อมูลที่ได้มานั้นจำเป็นต้องได้รับการตรวจสอบด้วยสายตาจากมนุษย์เสมอ เพราะจากประสบการณ์ สาเหตุที่ทำให้ความแม่นยำลดลงมากที่สุดมักไม่ใช่ข้อบกพร่องของอัลกอริทึมขั้นสูง แต่เกิดจากการปนเปื้อนของข้อมูลขยะ (Garbage Data) เป็นส่วนใหญ่

แม้จะดำเนินการแบบ On-premise ทั้งหมด แต่หากข้อมูลที่ใช้ในการเรียนรู้มีข้อมูลส่วนบุคคลหรือข้อมูลที่เป็นความลับรวมอยู่ด้วย ก็ยังคงมีความเสี่ยงที่โมเดลจะจดจำข้อมูลเหล่านั้นและนำออกมาแสดงผลในภายหลัง การรับมือควรพิจารณาเป็น 3 ขั้นตอน ดังนี้: ① ตรวจจับ PII (เช่น ชื่อ-นามสกุล, ข้อมูลติดต่อ, เลขที่บัญชี) เพื่อทำการปกปิด (Masking) หรือทำให้เป็นนามแฝง (Pseudonymization) ② คัดเลือกข้อมูลที่จะนำมาใช้เรียนรู้โดยพิจารณาตามระดับความลับของข้อมูลนั้นๆ และ ③ หลังจากเรียนรู้แล้ว ให้ทำการทดสอบแบบ Red Teaming เพื่อตรวจสอบว่าโมเดลจะเปิดเผยข้อมูลที่เป็นความลับออกมาหรือไม่

กฎหมายคุ้มครองข้อมูลส่วนบุคคลในภูมิภาคต่างๆ รวมถึง PDPA ของไทย มีข้อจำกัดเกี่ยวกับการนำข้อมูลส่วนบุคคลไปใช้หรือจัดเก็บนอกเหนือจากวัตถุประสงค์ที่กำหนดไว้ ดังนั้น จึงจำเป็นต้องจัดเตรียมความพร้อมว่า "สามารถนำข้อมูลไปใช้ในการเรียนรู้ AI ภายในขอบเขตวัตถุประสงค์ที่เก็บรวบรวมมาได้หรือไม่" โดยอ้างอิงตามหลักกฎหมายที่เกี่ยวข้อง ทั้งนี้ แม้จะตั้งใจทำให้เป็นข้อมูลนิรนาม (Anonymized) แล้ว แต่ในบางกรณีอาจสามารถระบุตัวตนบุคคลกลับได้จากการนำข้อมูลส่วนย่อยมาประกอบกัน จึงควรพิจารณาครอบคลุมไปถึงการประเมินความเสี่ยงในการระบุตัวตนซ้ำ (Re-identification risk) ด้วย

หัวใจสำคัญของการเทรน (Training) อยู่ที่ 2 ส่วน คือ การออกแบบ Distillation Loss (Loss ที่ทำให้โมเดลเลียนแบบครู) และการมอนิเตอร์เพื่อหยุดภาวะ Overfitting การออกแบบในส่วนนี้เป็นตัวกำหนดความแม่นยำสุดท้าย มากกว่าการรันคำสั่งเพียงอย่างเดียว

โดยทั่วไปแล้ว ฟังก์ชันการสูญเสีย (Loss function) ของการกลั่นความรู้ (Distillation) จะถูกออกแบบโดยการรวมสองส่วนเข้าด้วยกัน ส่วนแรกคือส่วนที่ทำให้เอาต์พุตของนักเรียน (Student) เข้าใกล้ซอฟต์เลเบล (Soft label) ของครู (Teacher) ซึ่งมักจะใช้ KL Divergence ในการวัดระยะห่างระหว่างการแจกแจงความน่าจะเป็น ส่วนที่สองคือ Cross-entropy แบบปกติที่ทำให้เอาต์พุตของนักเรียนเข้าใกล้คำตอบที่ถูกต้อง (Hard label)

จุดสำคัญอยู่ที่พารามิเตอร์อุณหภูมิ (Temperature parameter) หรือ T ซึ่ง T จะทำหน้าที่ปรับความราบเรียบของ Softmax ยิ่งค่า T สูงขึ้น การแจกแจงความน่าจะเป็นของครูจะยิ่งราบเรียบขึ้น ทำให้ "ความรู้โดยนัย" (Implicit knowledge) ซึ่งก็คือความสัมพันธ์ระหว่างคลาสต่างๆ ส่งต่อไปยังนักเรียนได้ง่ายขึ้น ในทางปฏิบัติ เราจะปรับค่า T นี้และสัมประสิทธิ์น้ำหนักของทั้งสองส่วน (เช่น α) ผ่านการค้นหาไฮเปอร์พารามิเตอร์ (Hyperparameter tuning) หาก T สูงเกินไป ข้อมูลจะเจือจางลง และหากต่ำเกินไป ผลลัพธ์จะเข้าใกล้ Hard label ดังนั้นจึงต้องคอยสังเกตความแม่นยำบนชุดข้อมูลตรวจสอบ (Validation set) เพื่อหาจุดที่เหมาะสมที่สุด แม้ว่าจะยังไม่เข้าใจทฤษฎีอย่างถ่องแท้ แต่หากจำไว้ว่า "T และค่าน้ำหนักเป็นสิ่งที่ต้องปรับจูน" ก็สามารถเริ่มลงมือเขียนโค้ดได้ทันที

การฝึกฝนโมเดลแบบ On-premise มักจะสร้างขึ้นบนพื้นฐานของไลบรารี PyTorch และ Hugging Face เป็นหลัก สำหรับการเรียนรู้แบบกระจายศูนย์ (Distributed Training) จะใช้เครื่องมืออย่าง accelerate หรือ DeepSpeed ควบคู่ไปด้วย โดยมีขั้นตอนหลักดังนี้:

1. โหลด Teacher Model และ Student Model
2. สร้าง Soft Label ล่วงหน้า (หรือทำ Distillation แบบ On-the-fly)
3. กำหนด Custom Distillation Loss ด้วย KL Divergence + Cross Entropy
4. รันลูปการเรียนรู้และบันทึก Checkpoint ตามตัวชี้วัดการตรวจสอบ (Validation Metrics)

แนวคิดในการตั้งค่าคือ เริ่มต้นด้วย Learning Rate ที่ต่ำ, ปรับ Batch Size ให้เหมาะสมกับ VRAM โดยใช้ Gradient Accumulation เพื่อให้ได้ Effective Batch ที่ต้องการ และใช้ Mixed Precision (fp16/bf16) เพื่อประหยัดหน่วยความจำ หากต้องการลดต้นทุนในการ Fine-tuning ของ Student Model ให้ใช้เทคนิค PEFT เช่น LoRA ควบคู่ไปด้วย ในสภาพแวดล้อมแบบ Offline โดยสมบูรณ์ จำเป็นต้องดาวน์โหลดโมเดลและแพ็กเกจที่จำเป็นไว้ใน Internal Mirror ขององค์กรล่วงหน้า ทั้งนี้ คำสั่งและอาร์กิวเมนต์ที่เฉพาะเจาะจงอาจเปลี่ยนแปลงไปตามเวอร์ชันของเฟรมเวิร์ก ดังนั้นเมื่อทำการ Implement ควรตรวจสอบเอกสารอย่างเป็นทางการของเวอร์ชันที่ใช้งานอยู่เสมอ

ระหว่างการฝึก (training) ให้ติดตามตัวชี้วัดหลายตัวควบคู่กันไป ได้แก่ ค่า Loss ของทั้งฝั่งการเรียนรู้ (training) และการตรวจสอบ (validation), รายละเอียดของ Distillation Loss และ Task Loss รวมถึงความแม่นยำของงาน (เช่น accuracy หรือ F1) บนข้อมูลประเมินผลของบริษัท

การตัดสินใจทำ Early stopping โดยพื้นฐานแล้วควรหยุดก่อนที่ค่า Validation loss จะหยุดลดลงและเริ่มกลับตัวสูงขึ้น เนื่องจากค่าที่สูงขึ้นเป็นสัญญาณของการเกิด Overfitting อย่างไรก็ตาม การดูเพียงค่า Loss อย่างเดียวนั้นมีความเสี่ยง เพราะแม้ค่า Loss จะลดลง แต่คุณภาพของผลลัพธ์จริงอาจเสื่อมถอยลงได้ จึงควรสร้างนิสัยในการตรวจสอบตัวชี้วัดของงานจริงและตัวอย่างผลลัพธ์ด้วยสายตาในทุกๆ Epoch ทั้งนี้ ควรเก็บ Checkpoint ไว้หลายจุดและเลือกใช้ตัวที่ให้ค่าตัวชี้วัดการตรวจสอบดีที่สุดในท้ายที่สุด ประเด็นที่ว่า "Epoch สุดท้ายไม่ได้หมายความว่าดีที่สุดเสมอไป" เป็นเรื่องเล็กน้อยแต่เป็นจุดที่เข้าใจผิดกันได้ง่าย

ปัญหาทั่วไปที่มักพบในการทำ Distillation สรุปได้เป็น 2 ประเด็นหลัก คือ "ความแม่นยำไม่ถึงเป้าหมาย (Gap กับ Teacher Model)" และ "ยึดติดกับข้อมูลภายในบริษัทมากเกินไป (Overfitting)" หากทราบล่วงหน้า ปัญหาเหล่านี้ส่วนใหญ่สามารถหลีกเลี่ยงได้ตั้งแต่ขั้นตอนการออกแบบ

หากนักเรียน (Student) มีขนาดเล็กเกินไป หรือครู (Teacher) มีขนาดใหญ่เกินไป อาจทำให้ผู้เรียนไม่สามารถรับความรู้ได้ทั้งหมดและส่งผลให้ความแม่นยำลดลงอย่างมาก ปรากฏการณ์นี้เรียกว่า "Capacity Gap" ซึ่งมีทางเลือกในการแก้ไขหลายวิธี ดังนี้: ① เพิ่มขนาดของ Student ขึ้นอีกหนึ่งระดับ ② จำกัดขอบเขตของงาน (Task) โดยยอมลดความสามารถในการใช้งานทั่วไป (Generalization) เพื่อเน้นความเชี่ยวชาญเฉพาะด้าน ③ ใช้การกลั่นกรองความรู้แบบเป็นลำดับขั้น (Stepwise Distillation) โดยใช้โมเดลขนาดกลางเป็นผู้ช่วยสอน (Teacher Assistant) ④ เพิ่มปริมาณหรือยกระดับคุณภาพของข้อมูลที่ใช้ในการกลั่นกรอง (Distillation Data) ⑤ นำเทคนิคที่ใช้ปรับจูนคุณลักษณะ (Feature) ของชั้นกลาง (Intermediate Layer) นอกเหนือไปจากผลลัพธ์ที่ได้ (Output) มาใช้

สิ่งสำคัญคือ ก่อนที่จะลงมือแก้ไขโดยไร้ทิศทาง ควรแยกแยะให้ชัดเจนด้วยข้อมูลประเมินผล (Evaluation Data) ว่าความแม่นยำที่ลดลงนั้นเกิดขึ้นใน "Task ใด" เพราะแนวทางแก้ไขที่มีประสิทธิภาพจะแตกต่างกันอย่างสิ้นเชิง ขึ้นอยู่กับว่าประสิทธิภาพลดลงในทุก Task หรือลดลงเพียงแค่บาง Task เท่านั้น

หากพึ่งพาข้อมูลภายในองค์กรที่มีอยู่อย่างจำกัดมากเกินไป จะทำให้ได้โมเดลที่เก่งเฉพาะกับข้อมูลที่ใช้ฝึกสอน แต่จะล้มเหลวเมื่อเจอข้อมูลนำเข้าที่แตกต่างออกไปเพียงเล็กน้อย ซึ่งนี่คือภาวะ "การเรียนรู้เกินพอดี" (Overfitting) โดยสัญญาณบ่งชี้ ได้แก่ ค่าความสูญเสียในการตรวจสอบ (Validation loss) ที่เพิ่มสูงขึ้น หรือความแม่นยำที่ลดลงเมื่อเจอสำนวนภาษาที่ไม่อยู่ในข้อมูลฝึกสอน

แนวทางแก้ไข ได้แก่ ① การสร้างความหลากหลายของข้อมูล (ครอบคลุมการกระจายตัวของข้อมูลจากการใช้งานจริงให้กว้างขวาง) ② การใช้การปรับให้เหมาะสม (Regularization) เช่น dropout, weight decay และ early stopping ③ การผสมผสานข้อมูลทั่วไปเข้ากับข้อมูลภายในองค์กรเพื่อฝึกสอน เพื่อรักษาทักษะทางภาษาพื้นฐานไว้ และ ④ การประเมินผลใหม่อย่างสม่ำเสมอและฝึกสอนใหม่หากจำเป็น นอกจากนี้ หลังจากนำไปใช้งานจริงแล้ว ต้องคอยเฝ้าระวัง "การเบี่ยงเบน" (Drift) ซึ่งเป็นกรณีที่ความแม่นยำลดลงเนื่องจากการเปลี่ยนแปลงของแนวโน้มข้อมูลนำเข้า สุดท้ายนี้คือประเด็นสำคัญด้านการดำเนินงาน การสร้างโมเดลกลั่นกรอง (Distillation model) ไม่ใช่แค่ทำเสร็จแล้วจบไป แต่การจัดตั้งระบบโดยมีเงื่อนไขว่าต้องมีการอัปเดตข้อมูลประเมินผลและทำการกลั่นกรองซ้ำอย่างต่อเนื่อง คือหัวใจสำคัญที่จะทำให้ AI แบบ On-premise สามารถใช้งานได้ในระยะยาว