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

RAG (Retrieval-Augmented Generation / การสร้างข้อความโดยอาศัยการดึงข้อมูล) คือวิธีการที่ไม่ได้ปรับเปลี่ยนตัวโมเดลโดยตรง แต่ใช้วิธีการดึงข้อมูลความรู้ที่จำเป็นต่อการตอบคำถามจากแหล่งภายนอกมาใส่ไว้ใน Prompt

สำหรับการเตรียมการเบื้องต้น จะต้องแบ่งเอกสารภายในองค์กรหรือ FAQ ออกเป็นส่วนๆ ที่มีความยาวเหมาะสม (Chunking) จากนั้นนำไปแปลงเป็นเวกเตอร์ด้วย Embedding Model และจัดเก็บไว้ใน Vector Database เมื่อมีคำถามจากผู้ใช้ ระบบจะแปลงคำถามนั้นเป็นเวกเตอร์เพื่อค้นหา Chunk ที่มีความหมายใกล้เคียงกันออกมา จากนั้นจะนำ Chunk ที่ดึงมาได้ส่งให้ LLM พร้อมกับคำถามในฐานะ "ข้อมูลอ้างอิง" เพื่อให้โมเดลสร้างคำตอบโดยอาศัยข้อมูลเหล่านั้น

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

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

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

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

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

ในด้านต้นทุน จำเป็นต้องแยกพิจารณาระหว่างการลงทุนเริ่มแรก (Initial Investment) และค่าใช้จ่ายในการดำเนินงานและบำรุงรักษา (Operational Maintenance Cost)

การลงทุนเริ่มแรกสำหรับ RAG จะเน้นไปที่การทำ Document Chunking, การสร้าง Vector Database และการติดตั้งระบบ Search Pipeline เนื่องจากไม่จำเป็นต้องทำการ Re-training โมเดล จึงสามารถเริ่มดำเนินการได้แม้ไม่มีผู้เชี่ยวชาญด้าน Machine Learning สำหรับค่าใช้จ่ายในการดำเนินงานและบำรุงรักษานั้น จะเป็นต้นทุนที่เกิดขึ้นต่อเนื่องจากการเรียกใช้งาน Embedding ทุกครั้งที่ทำการค้นหา และการเพิ่มขึ้นของ Input Token จากการที่ Prompt มีความยาวขึ้น

การลงทุนเริ่มแรกสำหรับ Fine-tuning จะเน้นไปที่การเตรียมข้อมูลสอน (Training Data) และทรัพยากรคำนวณสำหรับการเรียนรู้ ภาระหลักคือค่าแรงในการเตรียมข้อมูลคุณภาพสูงและค่าใช้จ่ายด้านสภาพแวดล้อม GPU สำหรับการประมวลผลการเรียนรู้ ในทางกลับกัน ในช่วงการดำเนินงาน เนื่องจากไม่จำเป็นต้องใส่ความรู้ภายนอกลงใน Prompt ทุกครั้ง จึงสามารถควบคุมปริมาณ Token ในขณะประมวลผล (Inference) ได้ง่ายกว่า อย่างไรก็ตาม ทุกครั้งที่มีการอัปเดตความรู้ ต้นทุนในการ Re-training จะเกิดขึ้นซ้ำอีกครั้ง

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

ในแง่ของความแม่นยำ มักจะมีความแตกต่างในเรื่องความสดใหม่ของข้อมูลและความเสี่ยงต่อการเกิดอาการหลอน (Hallucination)

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

ในขณะที่ Fine-tuning สามารถถ่ายทอดสำนวนหรือรูปแบบในโดเมนที่เรียนรู้มาได้อย่างเสถียร แต่เนื่องจากความรู้ถูกฝังไว้ภายในโมเดล การอัปเดตข้อมูลหลังจากช่วงเวลาที่เรียนรู้จึงไม่สามารถทำได้หากไม่มีการเรียนรู้ใหม่ (Re-training) และมีแนวโน้มที่จะให้คำตอบที่ดูน่าเชื่อถือแต่ผิดพลาด (Hallucination) สำหรับคำถามที่ไม่อยู่ในข้อมูลที่ใช้ฝึกสอน

ในโดเมนที่ความรู้มีการเปลี่ยนแปลงบ่อยครั้ง RAG จะช่วยรักษาความสดใหม่ของข้อมูลได้ดีกว่า ส่วนในโดเมนที่ข้อมูลมีการเปลี่ยนแปลงน้อยและต้องการความสม่ำเสมอของพฤติกรรม Fine-tuning จะเป็นตัวเลือกที่เหมาะสมกว่า

ในมุมมองของข้อมูล ประเภท ปริมาณ และคุณภาพของข้อมูลที่จำเป็นสำหรับทั้งสองวิธีนั้นมีความแตกต่างกันอย่างมาก

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

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

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

RAG เหมาะสำหรับสาขาที่มีการอัปเดตความรู้บ่อยครั้ง หรือสถานการณ์ที่ยากต่อการเตรียมข้อมูลสำหรับฝึกสอน (Training Data) จำนวนมาก คุณสมบัติของ RAG ที่สามารถรองรับได้เพียงแค่การเปลี่ยนข้อมูลภายนอกนั้นมีประสิทธิภาพในสถานการณ์เหล่านี้ เราจะมาดูตัวอย่างกรณีศึกษาที่สำคัญ 2 กรณีกัน

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

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

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

สำหรับภาษาที่มีทรัพยากรข้อมูลน้อย (low-resource languages) เช่น ภาษาลาวหรือภาษาไทย RAG ถือเป็นทางเลือกที่มีประสิทธิภาพ

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

ในภูมิภาคเอเชียตะวันออกเฉียงใต้ซึ่งเป็นพื้นที่ดำเนินธุรกิจของเรา สถานการณ์ทั่วไปคือมีเอกสารภายในที่เป็นภาษาท้องถิ่นอยู่แล้ว แต่ขาดข้อมูลคู่ขนาน (parallel data) ที่ผ่านการเตรียมไว้สำหรับ Machine Learning ในสภาพแวดล้อมเช่นนี้ แนวทางที่เป็นจริงที่สุดคือการนำเอกสารภาษาท้องถิ่นที่มีอยู่มาใช้เป็นแหล่งความรู้สำหรับ RAG และเลือกใช้ Embedding model ที่มีความเชี่ยวชาญในลักษณะเฉพาะของภาษานั้นๆ ตามความจำเป็น

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

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

ตัวอย่างเช่น ในกรณีที่มีความต้องการให้เอาต์พุตออกมาเป็น JSON schema ที่กำหนดไว้เสมอ, ต้องการให้ใช้คำศัพท์เฉพาะทางในอุตสาหกรรมหรือระดับของคำสุภาพที่สม่ำเสมอ หรือต้องการให้สร้างข้อความที่ตรงตาม Tone & Manner ของบริษัทอย่างคงเส้นคงวา สิ่งเหล่านี้หากใช้เพียงคำสั่งใน Prompt มักจะเกิดความคลาดเคลื่อนได้ง่าย และรูปแบบอาจผิดเพี้ยนไปตามอินพุตที่ได้รับ

การใช้ Fine-tuning เพื่อเรียนรู้ตัวอย่างเอาต์พุตที่ต้องการอย่างเพียงพอ จะช่วยให้ "พฤติกรรม" เหล่านี้ฝังลึกอยู่ในตัวโมเดล ทำให้สามารถสร้างผลลัพธ์ที่เสถียรได้โดยไม่ต้องระบุคำสั่งอย่างละเอียดใน Prompt ทุกครั้ง นอกจากนี้ยังช่วยลดจำนวนโทเค็นในการอนุมาน (Inference) เนื่องจาก Prompt จะสั้นลง สำหรับการใช้งานที่ไม่อนุญาตให้รูปแบบผิดเพี้ยน หรือการใช้งานที่ต้องสร้างข้อมูลในรูปแบบเดิมซ้ำๆ เป็นจำนวนมาก ความสม่ำเสมอนี้ถือเป็นคุณค่าที่สำคัญอย่างยิ่ง

หากต้องการถ่ายโอนพฤติกรรมของโมเดลขนาดใหญ่ไปยังโมเดลขนาดเล็กเพื่อลดต้นทุนการอนุมาน (Inference cost) การทำ Fine-tuning ก็เป็นทางเลือกหนึ่งที่น่าสนใจ

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

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

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

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

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

RAG และ Fine-tuning ไม่ใช่ทางเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง แต่สามารถออกแบบให้ใช้งานร่วมกันเพื่อดึงจุดแข็งของทั้งสองวิธีมาใช้ได้

รูปแบบทั่วไปคือการใช้ Fine-tuning เพื่อปรับ "พฤติกรรม" (Behavior) และใช้ RAG เพื่อจัดหา "ความรู้" (Knowledge) ตัวอย่างเช่น การใช้ Fine-tuning เพื่อให้โมเดลจดจำโทนเสียง รูปแบบการแสดงผล หรือสำนวนเฉพาะทางของบริษัท ในขณะที่ใช้ RAG เพื่อสืบค้นและส่งมอบความรู้เฉพาะเจาะจงที่มีการอัปเดตอยู่บ่อยครั้ง วิธีนี้จะช่วยให้ได้ทั้งความสม่ำเสมอของรูปแบบและความสดใหม่ของข้อมูลไปพร้อมกัน

อย่างไรก็ตาม การใช้งานร่วมกันจะเพิ่มความซับซ้อนในการดำเนินงานและต้นทุน เนื่องจากต้องดูแลทั้งไปป์ไลน์การสืบค้น (Search pipeline) และการดำเนินการฝึกฝนใหม่ (Re-training) จึงไม่ควรเริ่มด้วยความต้องการที่มากเกินไปตั้งแต่ต้น ควรเริ่มต้นด้วยวิธีใดวิธีหนึ่งก่อน (ส่วนใหญ่มักเป็น RAG) แล้วค่อยเพิ่ม Fine-tuning เข้าไปเมื่อพบว่าความไม่สม่ำเสมอของรูปแบบหรือความแม่นยำในงานเฉพาะทางกลายเป็นคอขวด การค่อยๆ ขยายไปสู่การใช้งานร่วมกันหลังจากที่ปัญหาเริ่มชัดเจนขึ้น เป็นแนวทางที่จะช่วยให้การลงทุนไม่สูญเปล่า

การเลือกใช้วิธีการควรดำเนินการผ่าน 3 ขั้นตอน ได้แก่ การสำรวจ Use Case (Step 1), การทดสอบด้วย PoC (Step 2) และการตรวจสอบ Governance ก่อนการย้ายเข้าสู่ระบบงานจริง (Step 3) เพื่อลดโอกาสความล้มเหลว สิ่งสำคัญคือการสร้างกระบวนการทดสอบในสเกลเล็กและตัดสินใจโดยใช้ตัวเลขจริงของบริษัท แทนการตัดสินใจเพียงแค่การเปรียบเทียบทางทฤษฎี ต่อไปนี้คือรายละเอียดสิ่งที่ต้องทำในแต่ละขั้นตอน

ขั้นตอนแรกคือการสำรวจ use case ที่ต้องการและความถี่ในการอัปเดตความรู้นั้น

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

ในขณะเดียวกัน ให้ตรวจสอบทรัพยากรที่มีอยู่ในมือด้วย ไม่ว่าจะเป็นเอกสารความรู้ที่จัดระเบียบไว้แล้ว หรือมีกำลังคนและเวลาเพียงพอในการสร้าง training data หรือไม่ องค์กรส่วนใหญ่มักอยู่ในสถานะที่ "มีเอกสารความรู้แต่ไม่มีแรงพอจะสร้าง training data" ในกรณีนั้นการเริ่มต้นด้วย RAG ก็เป็นทางเลือกที่สมเหตุสมผล การระบุข้อสมมติฐานเหล่านี้ให้ชัดเจนตั้งแต่ต้น จะทำให้เห็นว่าควรตรวจสอบอะไรใน PoC ถัดไป

ถัดมา คือการวัดต้นทุนและความแม่นยำจริงในระดับ PoC (Proof of Concept) โดยมีจุดประสงค์เพื่อเก็บตัวเลขจากข้อมูลและคำถาม (Query) ของบริษัทเอง แทนที่จะใช้เพียงตารางเปรียบเทียบเชิงทฤษฎี

ในการตรวจสอบ เราจะเตรียมชุดคำถามที่เป็นตัวแทนของงานจริง เพื่อวัดคุณภาพของคำตอบ (อัตราความถูกต้อง, ความสมเหตุสมผลของแหล่งอ้างอิง, การปฏิบัติตามรูปแบบที่กำหนด) รวมถึงต้นทุนและค่า Latency ต่อครั้ง หากเป็น RAG จะเน้นดูว่าการค้นหาสามารถดึง Chunk ที่เหมาะสมออกมาได้หรือไม่ หากเป็น Fine-tuning จะเน้นดูว่าคำตอบจะผิดเพี้ยนไปมากน้อยเพียงใดเมื่ออยู่นอกเหนือขอบเขตการเรียนรู้

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

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

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

นอกจากนี้ ให้ตรวจสอบข้อกำหนดด้านอธิปไตยของข้อมูล (Data Sovereignty) เช่น สามารถส่งข้อมูลไปยัง Cloud API ภายนอกได้หรือไม่ หรือขัดต่อกฎระเบียบเรื่องสถานที่จัดเก็บและระยะเวลาในการเก็บรักษาข้อมูลหรือไม่ โดยให้รวบรวมสิ่งเหล่านี้ไว้เป็นรายการตรวจสอบ (Checklist) สำหรับการใช้งานจริง และดำเนินการย้ายระบบหลังจากได้รับอนุมัติจากแผนกที่เกี่ยวข้องแล้วเท่านั้น

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

ปัญหาที่พบบ่อยที่สุดใน RAG คือการที่ความแม่นยำในการค้นหาลดลงเนื่องจากความผิดพลาดในการออกแบบ Chunk

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

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

สิ่งที่มักถูกมองข้ามในการทำ Fine-tuning คือ Catastrophic Forgetting (การลืมแบบหายนะ) ซึ่งหมายถึงปรากฏการณ์ที่โมเดลสูญเสียความสามารถทั่วไปที่เคยมีอยู่เดิมไป อันเป็นผลมาจากการเรียนรู้เพิ่มเติมในงานใหม่

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

วิธีหลีกเลี่ยงปัญหานี้คือการใช้เทคนิคอย่าง LoRA ซึ่งเป็นการปรับจูนเพียงบางพารามิเตอร์แทนการเขียนทับพารามิเตอร์ทั้งหมด เพื่อลดผลกระทบต่อโมเดลต้นฉบับ นอกจากนี้ การปรับจูนค่า Learning rate ไม่ให้สูงเกินไป, การไม่ฝึกฝนมากจนเกินไป (ป้องกัน Overfitting) และการผสมข้อมูลทั่วไปเข้าไปในสัดส่วนที่เหมาะสมระหว่างการฝึกฝนก็เป็นวิธีที่มีประสิทธิภาพเช่นกัน และที่สำคัญที่สุดคือ หลังจากทำการเรียนรู้เพิ่มเติมแล้ว ต้องตรวจสอบกับข้อมูลทดสอบ (Validation data) เสมอว่า นอกจากความแม่นยำในงานเป้าหมายจะเพิ่มขึ้นแล้ว งานทั่วไปที่เคยทำได้ต้องไม่เสื่อมถอยลง การไม่ด่วนสรุปว่า "ความแม่นยำเพิ่มขึ้น" โดยดูเพียงตัวชี้วัดแคบๆ คือหัวใจสำคัญที่จะช่วยให้ไม่มองข้าม Catastrophic Forgetting ไป