ในการนำ Generative AI มาประยุกต์ใช้ในการทำงาน คำถามที่ว่า "จะนำข้อมูลภายในองค์กรมาผนวกเข้ากับ AI ได้อย่างไร" นั้น มีแนวทางหลัก 2 ประการ คือ Fine-tuning และ RAG (Retrieval-Augmented Generation) โดยวิธีแรกจะเป็นการปรับปรุงค่าน้ำหนัก (Weights) ของ LLM (Large Language Model) โดยตรงเพื่อฝังความรู้เข้าไป ส่วนวิธีหลังจะเป็นการค้นหาเอกสารภายนอกแบบเรียลไทม์เพื่อนำมาสร้างคำตอบ

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

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

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

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

เรามาทำความเข้าใจกลไกพื้นฐานของแต่ละวิธีเพื่อเป็นรากฐานในการตัดสินใจเลือกใช้กันก่อนครับ

การทำ Fine-tuning คือวิธีการปรับโมเดลพื้นฐาน (Foundation Model) ที่ผ่านการฝึกฝนมาแล้วให้เข้ากับงานเฉพาะทาง โดยการนำน้ำหนักพารามิเตอร์ (weight parameters) มาฝึกฝนใหม่ด้วยข้อมูลเพิ่มเติม เนื่องจากตัวโมเดลได้ "สร้างความรู้ไว้ภายใน" (internalize knowledge) จึงไม่จำเป็นต้องอ้างอิงข้อมูลภายนอกในขณะที่ทำการอนุมาน (inference)

ขั้นตอนการเรียนรู้

• เตรียมข้อมูลสอน (คู่ข้อมูลนำเข้าและผลลัพธ์)
• อัปเดตพารามิเตอร์โดยลดฟังก์ชันการสูญเสีย (loss function) ให้เหลือน้อยที่สุด
• นำโมเดลที่อัปเดตแล้วไปปรับใช้ (deploy) เพื่อใช้งานในการอนุมาน

ผลกระทบต่อโมเดลจะปรากฏชัดเจนใน 2 ด้าน ประการแรกคือ การกำหนดรูปแบบผลลัพธ์ให้คงที่ (output style) ทำให้สามารถจำลองรูปแบบภาษาหรือฟอร์แมตเฉพาะทางได้อย่างสม่ำเสมอ เช่น สำนวนที่เป็นมาตรฐานในเอกสารทางกฎหมาย หรือรูปแบบการเขียนบันทึกทางการแพทย์ ประการที่สองคือ การเสริมสร้างคำศัพท์เฉพาะทาง (domain vocabulary) ซึ่งช่วยให้โมเดลสามารถจัดการกับศัพท์เฉพาะในอุตสาหกรรมหรือสำนวนที่ไม่อยู่ในคำศัพท์ของ BPE Tokenizer (Byte-Pair Encoding Tokenizer) ได้ดียิ่งขึ้นผ่านการเรียนรู้

อย่างไรก็ตาม มีข้อจำกัดที่ควรระวังดังนี้:

• ต้นทุนการเรียนรู้สูง: การทำ Full Fine-tuning ใช้ทรัพยากร GPU (Graphics Processing Unit) จำนวนมาก
• ความสดใหม่ของความรู้ลดลงได้ง่าย: ข้อมูลที่เกิดขึ้นหลังจากผ่านการเรียนรู้ไปแล้วจะไม่ถูกสะท้อนอยู่ในโมเดล
• ความเสี่ยงต่อการเกิดอาการหลอน (Hallucination): โมเดลอาจพยายามเติมเต็มข้อเท็จจริงที่ไม่มีอยู่ในข้อมูลที่ใช้เรียนรู้

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

RAG (Retrieval-Augmented Generation) คือเทคนิคที่ LLM จะทำการค้นหาและดึงข้อมูลที่เกี่ยวข้องจากแหล่งความรู้ภายนอกก่อนที่จะสร้างคำตอบ โดยนำเนื้อหานั้นมาประกอบเป็นบริบท (Context) ใน Prompt เนื่องจากไม่ได้มีการปรับเปลี่ยนพารามิเตอร์ของตัวโมเดลโดยตรง การอัปเดตความรู้จึงทำได้เพียงแค่จัดการที่ฝั่งฐานข้อมูลเท่านั้น

ขั้นตอนการทำงานพื้นฐาน

1. แปลงคำถามของผู้ใช้ให้เป็น Embedding
2. ดำเนินการค้นหาความคล้ายคลึง (Similarity Search) ใน Vector Database เพื่อดึง Chunk ที่เกี่ยวข้องออกมา
3. แทรกเอกสารที่ดึงมาได้ลงใน System Prompt หรือ Context Window
4. LLM สร้างคำตอบโดยอ้างอิงจากบริบทที่ได้รับมา

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

กลวิธีหลักในการเพิ่มความแม่นยำในการค้นหา

• Hybrid Search: ผสมผสาน Vector Search และ BM25 (Keyword Search) เข้าด้วยกันโดยใช้ RRF เพื่อให้ได้ทั้งค่า Recall และ Precision ที่ดี
• การปรับขนาด Chunk: หากความละเอียดของเอกสารหยาบเกินไป ข้อมูลที่ไม่จำเป็นอาจปะปนเข้ามา แต่หากละเอียดเกินไป บริบทของเนื้อหาก็จะสูญหายไป
• Agentic RAG: ใช้การอนุมานแบบหลายขั้นตอน (Multi-step reasoning) เพื่อทำการค้นหาซ้ำหลายครั้ง ทำให้สามารถตอบคำถามที่ซับซ้อนได้

ในทางกลับกัน RAG มีข้อจำกัดด้านปริมาณข้อมูลที่สามารถบรรจุลงใน Context Window ได้ และความรู้ที่ไม่ถูกค้นพบจากการสืบค้นจะไม่ถูกนำมาใช้ในการตอบคำถาม นอกจากนี้ คุณภาพของ Grounding ยังขึ้นอยู่กับการออกแบบ Search Engine เป็นอย่างมาก ดังนั้นการออกแบบ Index และความแม่นยำในการประมวลผลล่วงหน้า (Preprocessing) จึงเป็นปัจจัยสำคัญที่กำหนดคุณภาพของผลลัพธ์โดยรวม

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

สาเหตุที่ทำให้เกิดความเข้าใจผิดดังกล่าวมีปัจจัยดังนี้:

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

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

กล่าวคือ ทั้งสองวิธีไม่ใช่คู่แข่งกัน แต่เป็นความสัมพันธ์แบบเติมเต็มซึ่งกันและกัน

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

ในส่วนถัดไป เราจะมาสรุปเกณฑ์การประเมินเพื่อตัดสินใจว่าควรให้ความสำคัญกับวิธีใดมากกว่ากัน การระบุให้ชัดเจนว่า "ให้ความสำคัญกับอะไร" คือจุดเริ่มต้นของการเลือกวิธีที่เหมาะสมที่สุด

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

เกณฑ์หลักที่ใช้ในการเปรียบเทียบมี 4 ด้าน ได้แก่ ต้นทุน (Cost), ความแม่นยำ (Accuracy), ความถี่ในการอัปเดต (Update Frequency) และความปลอดภัย (Security) นอกจากนี้ การจำแนกกรณีการใช้งาน (Use Case) ออกเป็น "ประเภทเน้นการเติมเต็มความรู้" (Knowledge Injection) และ "ประเภทเน้นการปรับสไตล์" (Style Adaptation) จะช่วยให้เห็นชัดเจนว่าวิธีใดเหมาะสมกับงานนั้นๆ มากกว่ากัน

ในหัวข้อ H3 ถัดไป จะอธิบายคำจำกัดความและเกณฑ์การตัดสินใจที่ชัดเจนของแต่ละด้านตามลำดับ

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

① ต้นทุน (Cost)

• Fine-tuning ต้องใช้ทรัพยากร GPU ในการเรียนรู้เบื้องต้น และมีต้นทุนการเรียนรู้ใหม่ทุกครั้งที่มีการอัปเดตโมเดล
• RAG มีต้นทุนหลักอยู่ที่การสร้างและดูแลระบบ Vector Database โดยไม่จำเป็นต้องเรียนรู้โมเดลใหม่
• สำหรับการปรับใช้ในระดับเล็ก การใช้ PEFT เช่น LoRA หรือ QLoRA มีแนวโน้มที่จะช่วยลดต้นทุนการเรียนรู้ลงได้อย่างมาก

② ความแม่นยำ (Accuracy)

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

③ ความถี่ในการอัปเดต (Update Frequency)

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

④ ความปลอดภัย (Security)

• หากไม่ต้องการส่งข้อมูลที่เป็นความลับไปยัง Cloud API การใช้โครงสร้าง RAG ที่รวม Local LLM เข้ากับ Vector Database แบบ On-premise จะมีประสิทธิภาพ
• การใช้โมเดลที่ผ่านการ Fine-tuning แล้วในสภาพแวดล้อมแบบ Offline ก็เป็นอีกทางเลือกหนึ่ง แต่จะเพิ่มภาระในการดูแลรักษาเมื่อต้องอัปเดตโมเดล

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

ก่อนที่จะเลือกวิธีการปรับแต่ง LLM สิ่งสำคัญคือต้องจำแนกประเภทของ "สิ่งที่คุณต้องการแก้ไข" ตามลักษณะของ Use Case เสียก่อน โดยสามารถแบ่งออกเป็น 2 ประเภทหลัก ได้แก่ แบบเน้นการเพิ่มพูนความรู้ (Knowledge Injection) และ แบบเน้นการปรับรูปแบบ (Style Adaptation)

แบบเน้นการเพิ่มพูนความรู้ (Knowledge Injection) คือกรณีที่คุณต้องการให้โมเดลสามารถจัดการกับข้อมูลที่เดิมไม่มีอยู่ได้ เช่น:

• ความรู้ที่ต้องนำเข้ามาจากภายนอก เช่น กฎระเบียบภายในบริษัท ข้อมูลจำเพาะของผลิตภัณฑ์ หรือข้อมูลการแก้ไขกฎหมาย
• ข้อมูลล่าสุดที่เกิดขึ้นหลังจากวันตัดยอดข้อมูล (Cut-off date) ของชุดข้อมูลที่ใช้ฝึกสอน
• ข้อมูลเฉพาะของบริษัทหรืออุตสาหกรรม (เช่น ระบบรหัสสินค้าเฉพาะ หรืออภิธานศัพท์ภายในองค์กร)

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

แบบเน้นการปรับรูปแบบ (Style Adaptation) คือกรณีที่คุณต้องการให้รูปแบบการตอบกลับ สไตล์การเขียน หรือรูปแบบการตอบสนองของโมเดลเป็นไปตามมาตรฐานที่กำหนด เช่น:

• ต้องการให้แสดงผลในรูปแบบฟอร์มมาตรฐาน เช่น รายงานทางการแพทย์หรือเอกสารทางกฎหมาย
• การสร้างข้อความที่สอดคล้องกับ Tone of Voice ของแบรนด์
• ต้องการเพิ่มความแม่นยำในการแสดงออกที่เป็นธรรมชาติในภาษาเฉพาะ (เช่น ภาษาไทย หรือ ภาษาญี่ปุ่น)

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

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

จากเกณฑ์การประเมินที่กำหนดไว้ในหัวข้อก่อนหน้า เราจะทำการเปรียบเทียบระหว่าง 3 แนวทาง ได้แก่ Fine-tuning, RAG และแนวทางแบบผสมผสาน

โดยมีจุดเปรียบเทียบหลัก 3 ประการ ดังนี้:

• ต้นทุน (Cost): ภาระค่าใช้จ่ายรวม ทั้งค่าใช้จ่ายในการเทรน (Training), ค่าใช้จ่ายในการอนุมาน (Inference) และค่าใช้จ่ายในการดำเนินงาน (Operation)
• ความแม่นยำและอาการหลอน (Accuracy and Hallucination): แนวโน้มของคุณภาพคำตอบและความเสี่ยงต่อข้อมูลที่ผิดพลาด
• ความง่ายในการอัปเดตข้อมูล (Ease of Data Updates): ต้นทุนในการดำเนินงานเพื่อรักษาความสดใหม่ของข้อมูล

รายละเอียดของแต่ละหัวข้อจะถูกเจาะลึกในส่วน H3 ถัดไป โปรดทำความเข้าใจภาพรวมก่อน แล้วจึงนำไปพิจารณาเทียบกับกรณีการใช้งาน (Use Case) ของบริษัทท่าน

ファインチューニングとRAGでは、コスト構造が根本的に異なる。3つのフェーズに分けて整理すると判断しやすい。

学習費（初期投資）

• ファインチューニング：GPU時間が主なコスト。フルファインチューニングは高額になる傾向があるが、LoRAやQLoRAなどPEFT手法を使うと学習パラメータを絞れるため、コストを大幅に抑えられるケースが報告されている
• RAG：モデル自体の学習は不要。ただし、ドキュメントのエンベディング生成とベクトルデータベースの初期構築にコストが発生する

推論費（実行時コスト）

• ファインチューニング済みモデル：コンテキストウィンドウに大量のドキュメントを詰め込む必要がないため、1リクエストあたりのトークン消費が少なくなる傾向がある
• RAG：検索クエリの発行＋取得チャンクのコンテキスト挿入が加わるため、1回の推論でトークン数が増えやすい。特に複数ドキュメントを参照する場合は注意が必要

運用費（継続コスト）

• ファインチューニング：知識が古くなるたびに再学習が必要。更新頻度が高いデータを扱う場合、再学習コストが積み重なりやすい
• RAG：ベクトルデータベースの更新とストレージ費が主な継続コスト。ドキュメントを差し替えるだけで知識を更新できるため、運用コストは比較的予測しやすい

コスト面での大まかな傾向まとめ

初期投資を抑えてすぐに試したい場合はRAGが有利。一方、推論回数が非常に多いプロダクション環境では、ファインチューニングの推論コスト優位性が効いてくる。なお、価格は執筆時点の参考傾向であり、最新の料金は各クラウドプロバイダーの公式ページで確認することを推奨する。

ความแม่นยำและอัตราการเกิดฮัลซิเนชัน (Hallucination rate) เป็นเกณฑ์การประเมินที่สำคัญซึ่งส่งผลโดยตรงต่อการเลือกใช้วิธีการ โดยทั้ง Fine-tuning และ RAG ต่างมีแนวโน้มที่จะเกิดข้อผิดพลาดจากกลไกที่แตกต่างกัน

คุณลักษณะด้านความแม่นยำของ Fine-tuning

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

คุณลักษณะด้านความแม่นยำของ RAG

• เนื่องจากเป็นการสร้างคำตอบโดยอ้างอิงจากเอกสารที่ดึงมาได้จากการค้นหา จึงทำให้ระบุแหล่งที่มาของข้อมูลได้ง่าย
• อย่างไรก็ตาม หากความแม่นยำในการค้นหาต่ำ (เช่น ได้รับ Chunk ที่มีความเกี่ยวข้องน้อย) ก็มีโอกาสสูงที่จะเกิด "Grounding failure" ซึ่งเป็นการสร้างคำตอบโดยอ้างอิงจากบริบทที่ผิดพลาด
• มีรายงานว่าการใช้ Hybrid search ที่ผสมผสานระหว่าง BM25 และ Vector database สามารถช่วยปรับปรุงความแม่นยำในการค้นหาได้

สรุปแนวโน้มของอัตราการเกิดฮัลซิเนชัน

ทั้งสองวิธีไม่สามารถทำให้ฮัลซิเนชันเป็นศูนย์ได้ สิ่งสำคัญคือการทำความเข้าใจสาเหตุที่ทำให้เกิดข้อผิดพลาด และใช้มาตรการรับมือร่วมกับ Guardrails หรือการตรวจสอบโดยมนุษย์ (Human-in-the-Loop: HITL)

ความง่ายในการอัปเดตข้อมูลเป็นหนึ่งในเกณฑ์การประเมินที่แสดงให้เห็นถึงความแตกต่างมากที่สุดระหว่างการทำ Fine-tuning และ RAG

Fine-tuning: ต้นทุนการอัปเดตสูงและขาดความรวดเร็ว

การทำ Fine-tuning จำเป็นต้องมีการเรียนรู้ใหม่ (Re-training) ทุกครั้งที่มีการปรับปรุงความรู้ใหม่ โดยสรุปประเด็นปัญหาหลักได้ดังนี้:

• การเรียนรู้ใหม่ต้องใช้ทรัพยากร GPU และเวลาเพิ่มเติม
• มีระยะเวลา (Lead time) นานในการเตรียมข้อมูลการเรียนรู้ การตรวจสอบ และการนำไปใช้งาน (Deploy)
• ยิ่งมีความถี่ในการอัปเดตสูง ต้นทุนการดำเนินงานก็จะสะสมมากขึ้น

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

RAG: สะท้อนข้อมูลได้ทันทีเพียงแค่เปลี่ยนเอกสาร

เนื่องจาก RAG สร้างคำตอบโดยการค้นหาเอกสารที่จัดเก็บไว้ใน Vector Database การอัปเดตข้อมูลจึงเสร็จสิ้นได้ด้วยการสร้างดัชนี (Index) ใหม่เท่านั้น:

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

RAG เหมาะสำหรับความต้องการที่ว่า "อัปเดตวันนี้และต้องการใช้งานตั้งแต่วันพรุ่งนี้" เช่น การแก้ไขคู่มือภายในบริษัท หรือการตอบสนองต่อการเปลี่ยนแปลงทางกฎหมาย

แนวคิดในการใช้งานร่วมกัน

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

ファインチューニングが真価を発揮するのは、「モデルの振る舞い自体を変えたい」場面です。知識を外部から注入するRAGとは異なり、モデルの重みを直接更新するため、出力スタイルや応答形式の一貫性が求められる用途に適しています。特に専門用語が多い業界や、特定のトーンを維持したい業務での活用が報告されています。以下のH3では、具体的なユースケースと実装手法を掘り下げます。

การทำ Fine-tuning จะแสดงคุณค่าที่แท้จริงออกมาในสถานการณ์ที่ต้องการ "เปลี่ยนพฤติกรรมของตัวแบบ (Model)" โดยตรง ซึ่งแตกต่างจาก RAG ที่เป็นการนำความรู้จากภายนอกมาใส่ เนื่องจากเป็นการอัปเดตน้ำหนัก (Weights) ของตัวแบบโดยตรง จึงเหมาะสำหรับการใช้งานที่ต้องการความสม่ำเสมอของรูปแบบการส่งออก (Output style) และรูปแบบการตอบกลับ (Response format) โดยเฉพาะอย่างยิ่งมีการรายงานถึงการนำไปใช้ในอุตสาหกรรมที่มีศัพท์เฉพาะทางจำนวนมาก หรือในงานที่ต้องการรักษาโทนเสียงเฉพาะเจาะจง ในหัวข้อ H3 ต่อไปนี้ เราจะเจาะลึกถึงกรณีการใช้งานจริงและวิธีการนำไปใช้งาน (Implementation methods)

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

ตัวอย่างเช่น มีการรายงานถึงข้อได้เปรียบของการทำ Fine-tuning ในกรณีดังต่อไปนี้:

• การแพทย์และเภสัชกรรม: การสรุปเวชระเบียนหรือรายงานการทดลองทางคลินิก ซึ่งจำเป็นต้องใช้รูปแบบการแบ่งหัวข้อและกฎการใช้คำศัพท์เฉพาะทาง
• กฎหมาย: การตรวจสอบสัญญาที่ต้องการรูปแบบตายตัว เช่น "รายการความเสี่ยง → ข้อกฎหมายอ้างอิง → ข้อเสนอแนะในการดำเนินการ"
• การเงิน: การหลีกเลี่ยงการใช้คำที่ฟันธงในรายงานการลงทุน หรือการเพิ่มข้อความปฏิเสธความรับผิดชอบ (Disclaimer) โดยอัตโนมัติ
• การผลิต: การบังคับใช้โครงสร้าง 3 ส่วนในรายงานความผิดปกติ ได้แก่ "ปรากฏการณ์-สาเหตุ-มาตรการแก้ไข"

สิ่งเหล่านี้มักจะไม่เสถียรหากใช้เพียงการสั่งงานผ่าน System Prompt เนื่องจากยิ่ง Prompt ยาวขึ้นเท่าใด ก็จะยิ่งสิ้นเปลือง Context Window และเพิ่มต้นทุนในการประมวลผล (Inference cost) มากขึ้นเท่านั้น

การใช้ Fine-tuning เพื่อฝัง "กฎการเขียนของอุตสาหกรรม" ลงในน้ำหนัก (Weights) ของโมเดล จะช่วยให้รักษาฟอร์แมตที่สอดคล้องกันได้แม้ใช้ Prompt สั้นๆ การที่ผลลัพธ์มีความแปรปรวนน้อยลง ยังช่วยให้การตรวจสอบคุณภาพในขั้นตอนถัดไปและการเชื่อมต่อกับระบบ RPA มีความเสถียรมากขึ้นอีกด้วย

อย่างไรก็ตาม มีข้อควรระวังดังนี้:

• หากข้อมูลที่ใช้สอน (Training data) มีคุณภาพต่ำ อาจมีความเสี่ยงที่จะทำให้รูปแบบการเขียนที่ผิดพลาดกลายเป็นสิ่งที่ฝังแน่น
• มีต้นทุนในการเรียนรู้ใหม่ (Re-training) ทุกครั้งที่มีการเปลี่ยนแปลงข้อกำหนดของรูปแบบผลลัพธ์
• ความสดใหม่ของข้อมูล (Knowledge freshness) ไม่สามารถรับประกันได้ดีเท่ากับ RAG

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

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

กลไกและข้อดีของ LoRA

LoRA เป็นเทคนิคที่คงพารามิเตอร์เดิมของโมเดลไว้ แล้วเพิ่มเมทริกซ์อันดับต่ำ (Low-Rank Matrix) เข้าไปเพื่อเรียนรู้เฉพาะส่วนต่างเท่านั้น เนื่องจากเป้าหมายในการอัปเดตถูกจำกัดไว้เพียงประมาณ 1-5% ของทั้งหมด จึงทำให้เกิดข้อดีดังนี้:

• ลดหน่วยความจำ GPU ที่จำเป็นสำหรับการเรียนรู้ลงได้อย่างมาก
• ลดเวลาในการเรียนรู้ ทำให้ควบคุมค่าใช้จ่ายบนคลาวด์ได้ง่ายขึ้น
• สามารถสลับเปลี่ยน LoRA Adapter หลายตัวได้โดยที่ยังคงโมเดลพื้นฐาน (Base Model) เดิมไว้

การทำให้เบาลงยิ่งขึ้นด้วย QLoRA

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

ข้อควรระวังในการปฏิบัติ

• ปริมาณข้อมูลที่แนะนำ: มักจะเห็นผลลัพธ์ที่ดีจากตัวอย่างการเรียนรู้คุณภาพสูงจำนวนหลายร้อยถึงหลายพันรายการ
• การตั้งค่า Rank (r): ยิ่งค่า r น้อย โมเดลยิ่งเบาแต่ความสามารถในการแสดงออก (Expressiveness) จะลดลง จึงจำเป็นต้องปรับตามความซับซ้อนของงาน
• ความเสี่ยงต่อการเกิด Overfitting: หากมีข้อมูลน้อย ต้องไม่ลืมทำการประเมินด้วย Validation Set

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

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

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

เหตุผลหลักที่ RAG มีความเหมาะสม

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

รูปแบบการใช้งานจริง

ตัวอย่างเช่น ในหน้างานอุตสาหกรรมการผลิต คู่มือผลิตภัณฑ์มักมีการอัปเดตเวอร์ชันอยู่บ่อยครั้ง เพียงแค่แบ่งไฟล์ PDF เวอร์ชันใหม่เป็น Chunk แล้วลงทะเบียนใน Vector Database ใหม่ AI Chatbot ก็จะสามารถให้คำแนะนำตามขั้นตอนล่าสุดได้ทันที หรือในการบริหารจัดการกฎระเบียบภายในของแผนกทรัพยากรบุคคล หากมีการเพิ่มเนื้อหาการแก้ไขข้อบังคับเกี่ยวกับการทำงานลงใน Index ก็จะสามารถอัปเดตการตอบคำถามของพนักงานให้เป็นข้อมูลล่าสุดได้ทันทีเช่นกัน

ข้อควรระวัง

อย่างไรก็ตาม ความแม่นยำในการค้นหาจะขึ้นอยู่กับขนาดของ Chunk และคุณภาพของ Embedding Model ในกรณีที่เอกสารมีโครงสร้างซับซ้อน มีรายงานว่าการใช้ Hybrid Search (BM25 + Dense Model) ร่วมกันจะช่วยเพิ่มความแม่นยำได้ สำหรับการใช้งานด้านกฎหมายและ Compliance ที่จะกล่าวถึงในส่วนถัดไป คุณสมบัติการระบุแหล่งที่มานี้จะมีบทบาทสำคัญยิ่งขึ้นไปอีก

ในด้านกฎหมาย การแพทย์ และการปฏิบัติตามกฎระเบียบ (Compliance) ความโปร่งใสของหลักฐานที่แสดงว่า "เหตุใดคำตอบนั้นจึงถูกต้อง" ถือเป็นสิ่งจำเป็นอย่างยิ่ง ซึ่ง RAG มีจุดแข็งเชิงโครงสร้างที่ตอบโจทย์ความต้องการนี้

เหตุผลที่ RAG โดดเด่นด้านการจัดการการอ้างอิงและแหล่งที่มา

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

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

ในด้านการแพทย์ การให้ AI อ้างอิงจากแนวทางการรักษา (Clinical Practice Guidelines) หรือเอกสารกำกับยา จะช่วยให้สามารถให้ข้อมูลที่มีหลักฐานรองรับพร้อมทั้งลดความเสี่ยงของอาการประสาทหลอน (Hallucination) ของ AI อย่างไรก็ตาม การนำไปใช้ตัดสินใจทางการแพทย์โดยตรงจำเป็นต้องมีการพิจารณาอย่างเชี่ยวชาญแยกต่างหาก และแนะนำให้ออกแบบโดยให้ AI ทำหน้าที่เป็นเพียงตัวช่วยในการสืบค้นข้อมูลเท่านั้น

สำหรับการใช้งานด้านการปฏิบัติตามกฎระเบียบ (Compliance) มีรายงานว่าการอัปเดตดัชนีของเอกสารกฎระเบียบต่างๆ เช่น EU AI Act หรือ PDPA อย่างสม่ำเสมอ ช่วยลดต้นทุนในการรับมือกับการแก้ไขกฎหมายได้

การแบ่งบทบาทกับ Fine-tuning

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

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

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

โครงสร้างพื้นฐานของสถาปัตยกรรม

• ชั้น Fine-tuning: ฝึกฝนโมเดลให้เข้าใจโทนเสียงเฉพาะของอุตสาหกรรม รูปแบบการส่งออก (Output format) และการใช้คำศัพท์เฉพาะทาง
• ชั้น RAG: ดึงข้อมูลกฎระเบียบภายในบริษัทหรือข้อมูลผลิตภัณฑ์ล่าสุดจาก Vector Database แบบไดนามิก และนำเข้าสู่ Context Window
• ชั้น System Prompt: ทำหน้าที่เป็นตัวเชื่อมระหว่างทั้งสองส่วน โดยระบุคำสั่งว่าจะใช้ผลลัพธ์จากการค้นหาอย่างไร

ในโครงสร้างนี้ Fine-tuning จะรับผิดชอบเรื่อง "วิธีการตอบ" ส่วน RAG จะรับผิดชอบเรื่อง "เนื้อหาที่จะตอบ" ทำให้การแบ่งแยกหน้าที่ชัดเจน

ข้อควรระวังในการออกแบบ

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

นอกจากนี้ การออกแบบ Chunk size ก็มีความสำคัญ มีรายงานว่าหากส่ง Chunk ที่สั้นเกินไปให้กับโมเดลที่ถูกฝึกมาให้เขียนข้อความยาวๆ อาจทำให้บริบทขาดตอนและส่งผลให้ความแม่นยำลดลง จึงแนะนำให้ปรับ Chunk size ให้เหมาะสมกับสไตล์การส่งออกของโมเดล

ในขั้นตอน PoC การเริ่มต้นด้วย Base model + RAG เพื่อตรวจสอบความแม่นยำก่อน และค่อยเพิ่มการทำ Fine-tuning ด้วย PEFT หรือ LoRA ในกรณีที่คุณภาพของผลลัพธ์ยังไม่เพียงพอ ถือเป็นลำดับขั้นตอนที่สมเหตุสมผลในแง่ของการบริหารจัดการต้นทุน

Agentic RAG คือสถาปัตยกรรมที่ AI Agent ควบคุมขั้นตอนการสืบค้นของ RAG ได้อย่างอิสระ ในขณะที่ Static RAG แบบเดิมมีขั้นตอนการทำงานที่ตายตัวคือ "สืบค้น 1 ครั้ง → สร้างคำตอบ" แต่ใน Agentic RAG นั้น ตัว Agent จะทำการ สืบค้น ตัดสินใจ และสืบค้นซ้ำหลายครั้ง ได้อย่างยืดหยุ่น

เมื่อนำโมเดลที่ผ่านการ Fine-tuning มาใช้งานร่วมกับ Agentic RAG จะเกิดการแบ่งหน้าที่ดังนี้:

• โมเดลที่ผ่านการ Fine-tuning: รับผิดชอบด้านรูปแบบภาษาเฉพาะอุตสาหกรรม รูปแบบการแสดงผล และคำศัพท์เฉพาะทาง
• Agent Layer: รับผิดชอบด้านการแยกย่อยคำถาม (Query Decomposition) การกำหนดลำดับการเรียกใช้เครื่องมือสืบค้น และการประเมินผลลัพธ์
• Vector Database: รับผิดชอบด้านการจัดเก็บเอกสารล่าสุดและการสืบค้นข้อมูลที่มีความคล้ายคลึง (Similarity Search)

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

ข้อดีหลักของการออกแบบนี้มีดังนี้:

• รองรับ Multi-step Reasoning ทำให้ความแม่นยำในการตอบคำถามที่ซับซ้อนมีแนวโน้มสูงขึ้น
• สามารถสั่งสืบค้นซ้ำโดยอัตโนมัติหากผลลัพธ์การสืบค้นไม่เพียงพอ จึงช่วยลดการเกิด Hallucination ได้ง่ายขึ้น
• เมื่อมีการอัปเดตเอกสาร ไม่จำเป็นต้องออกแบบ Agent Layer ใหม่ เพียงแค่อัปเดต Vector Database ก็เพียงพอ

อย่างไรก็ตาม ควรระวังเรื่องต้นทุนในการออกแบบและทดสอบ Agent Orchestration ที่เพิ่มขึ้น ในช่วงขั้นตอน PoC จึงแนะนำให้เริ่มจาก Static RAG ก่อน แล้วค่อยขยับขยายไปสู่ Agentic RAG เมื่อมีความจำเป็นต้องรองรับคำถามที่มีความซับซ้อนมากขึ้น

จากผลการเปรียบเทียบข้างต้น เราจะมาสรุปเกณฑ์การตัดสินใจเพื่อช่วยให้คุณคัดเลือกวิธีการที่เหมาะสมกับสถานการณ์ของบริษัทได้อย่างรวดเร็ว

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

เมื่อไม่แน่ใจว่าจะเลือกใช้วิธีใด ให้ลองตัดสินใจตาม 3 ขั้นตอนต่อไปนี้เพื่อให้เห็นภาพชัดเจนขึ้น

ขั้นตอนที่ 1: ตรวจสอบงบประมาณ

ให้แยกประเมินระหว่างการลงทุนเริ่มต้นและค่าใช้จ่ายในการดำเนินงาน เช่น ค่า GPU Cloud และค่าบริการ API

• การทำ Fine-tuning จะมีค่าใช้จ่าย GPU เกิดขึ้นในช่วงการเรียนรู้ (Training) แต่ค่าใช้จ่ายในการอนุมาน (Inference) จะเท่ากับ LLM ทั่วไป
• RAG มีค่าใช้จ่ายหลักคือค่าบำรุงรักษา Vector Database และค่าบริการ Search API
• หากงบประมาณมีจำกัด สามารถพิจารณาทางเลือกในการลดต้นทุนการเรียนรู้ด้วย PEFT โดยใช้ LoRA หรือ QLoRA ได้

ขั้นตอนที่ 2: ตรวจสอบปริมาณข้อมูลที่มีอยู่

ให้ประเมินทั้งในแง่ของ "ปริมาณ" และ "คุณภาพ" ของข้อมูลที่มีอยู่ในมือ

• หากมีข้อมูลสำหรับสอน (Supervised Data) คุณภาพสูงตั้งแต่หลายร้อยถึงหลายพันรายการขึ้นไป มักจะเห็นผลลัพธ์จากการทำ Fine-tuning ได้ง่าย
• หากข้อมูลหลักเป็นเอกสารที่มีอยู่เดิมและจัดโครงสร้างได้ยาก การใช้ RAG มักจะสามารถนำมาใช้งานได้รวดเร็วกว่า
• ในกรณีที่ข้อมูลยังมีน้อย การทำ PoC (Proof of Concept) ด้วย RAG เพื่อตรวจสอบประสิทธิภาพก่อน แล้วค่อยพิจารณาทำ Fine-tuning ในภายหลังถือเป็นลำดับขั้นตอนที่สมเหตุสมผล

ขั้นตอนที่ 3: ตรวจสอบความถี่ในการอัปเดต

ความต้องการด้านความสดใหม่ของข้อมูลส่งผลโดยตรงต่อการเลือกวิธี

• งานที่ต้องมีการอัปเดตเอกสารเป็นรายสัปดาห์หรือรายเดือน (เช่น กฎระเบียบภายในบริษัท หรือข้อมูลจำเพาะของผลิตภัณฑ์) จะเหมาะกับ RAG มากกว่า เนื่องจากสามารถรองรับได้เพียงแค่การสร้าง Index ใหม่
• ในทางกลับกัน รูปแบบการตอบ (Output Style) หรือรูปแบบการใช้ภาษาเฉพาะทางในอุตสาหกรรมมักมีความถี่ในการอัปเดตต่ำ ดังนั้นการทำ Fine-tuning เพื่อกำหนดรูปแบบให้คงที่ตั้งแต่แรกจะช่วยรักษาคุณภาพให้เสถียรได้ง่ายกว่า
• หากมีความถี่ในการอัปเดต "สูง" และ "จำเป็นต้องมีการอ้างอิงแหล่งที่มา" การใช้แนวทางแบบผสมผสานจะเป็นทางเลือกที่ใช้งานได้จริงที่สุด

หากผ่านทั้ง 3 ขั้นตอนแล้วยังตัดสินใจได้ยาก โปรดตรวจสอบปัจจัยเพิ่มเติมสำหรับสภาพแวดล้อมแบบหลายภาษา (Multilingual) ซึ่งจะอธิบายในส่วนถัดไป

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

ปัญหาเรื่อง Tokenizer

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

ข้อควรระวังในการทำ Fine-tuning

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

ข้อควรระวังในการออกแบบ RAG

• คุณภาพการรองรับหลายภาษาของ Embedding model แตกต่างกันไปตามแต่ละโมเดล เพื่อรับประกันความแม่นยำในการค้นหาความหมายของภาษาไทย ควรเลือกโมเดลที่รองรับ Multilingual NLP และตรวจสอบความแม่นยำด้วยการทดสอบจริง
• หากเลือกใช้ Hybrid search (BM25 + Vector search) ต้องตรวจสอบให้แน่ใจว่า Morphological analyzer ของ BM25 รองรับภาษาไทยและภาษาญี่ปุ่น

เกณฑ์การตัดสินใจในทางปฏิบัติ

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

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

หลายคนมักถอดใจว่า "ข้อมูลน้อยเกินไปจนทำ Fine-tuning ไม่ได้" แต่ในความเป็นจริง ปริมาณข้อมูลที่จำเป็นจะแตกต่างกันอย่างมากตามวิธีการและขนาดของโมเดล

ในกรณีของ Full Fine-tuning

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

ในกรณีที่ใช้ PEFT / LoRA

• มีรายงานว่าสามารถเห็นผลลัพธ์ที่ดีได้แม้ใช้ข้อมูลเพียงหลักร้อยถึงหลักพันรายการ
• เนื่องจาก LoRA อัปเดตเพียงบางส่วนของน้ำหนักโมเดล (Weights) จึงช่วยลดโอกาสเกิด Overfitting ได้ง่ายแม้มีข้อมูลน้อย
• หากใช้ QLoRA จะช่วยลดการใช้หน่วยความจำลงได้อีก ทำให้สามารถทดลองบน GPU ที่มีอยู่ได้ง่ายขึ้น

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

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

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

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

ตัวอย่างโครงสร้างหลักสำหรับการใช้งานในสภาพแวดล้อมแบบ Local

• Base Model: ทำ Fine-tuning โมเดล Open-weights เช่น Llama หรือ Mistral ด้วย QLoRA
• Vector Database: สร้าง Chroma หรือ Weaviate แบบ On-premise
• Embedding Model: ใช้โมเดลที่ทำงานแบบ Local เช่น BGE หรือ E5 ในการแปลงเอกสารเป็นเวกเตอร์
• Inference Server: สร้าง API Endpoint ด้วย Ollama หรือ vLLM

โครงสร้างนี้ช่วยให้สามารถสร้าง RAG Pipeline ที่ทำงานเสร็จสมบูรณ์ภายในเครือข่ายของบริษัทได้

จุดที่ควรระวัง

• ข้อจำกัดด้าน GPU Memory มีผลมาก ทำให้โมเดลขนาดประมาณ 7B Parameters มักเป็นตัวเลือกที่ใช้งานได้จริงมากที่สุด
• หากภาษาของโมเดลที่ผ่านการ Fine-tuning และ Embedding Model ไม่ตรงกัน จะส่งผลให้ความแม่นยำในการค้นหาภาษาไทยหรือภาษาญี่ปุ่นลดลง
• การทำ Quantization สามารถลดขนาดโมเดลได้ แต่จำเป็นต้องตรวจสอบ Trade-off ระหว่างขนาดกับความแม่นยำ

ความเป็นจริงในด้านต้นทุน

แม้จะไม่มีค่าใช้จ่าย API เหมือนการใช้ Cloud แต่จะมีต้นทุนคงที่ในการจัดหา GPU, ค่าไฟฟ้า และการบำรุงรักษา หากเป็นงานที่มีความถี่ในการใช้งานสูง จะเห็นความคุ้มค่าในระยะยาวได้ง่ายกว่า แต่ในทางกลับกัน หากใช้งานน้อย การใช้ Cloud อาจมีราคาถูกกว่า

การใช้ Local LLM ร่วมกับเทคนิคต่างๆ มีความท้าทายทางเทคนิคค่อนข้างสูง แต่เป็นทางเลือกที่มีศักยภาพสำหรับสภาพแวดล้อมที่มีข้อกำหนดด้านอธิปไตยของข้อมูล (Data Sovereignty) และความปลอดภัยที่เข้มงวด แนะนำให้เริ่มจากการทดสอบในระดับ PoC เพื่อตรวจสอบความสมดุลระหว่างต้นทุนการดำเนินงานและความแม่นยำก่อนเริ่มใช้งานจริง

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

กรณีที่ Fine-tuning เหมาะสม:

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

กรณีที่ RAG เหมาะสม:

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

กรณีที่การใช้งานร่วมกันมีประสิทธิภาพ:

• ต้องการทั้งความสามารถในการแสดงออกเฉพาะทาง (Domain-specific) และการสืบค้นข้อมูลแบบเรียลไทม์
• ต้องการขั้นตอนการทำงานที่ต้องมีการอนุมานแบบหลายขั้นตอน (Multi-step reasoning) ผ่าน Agentic RAG

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

ทั้งสองวิธีไม่สามารถขจัดความเสี่ยงของอาการประสาทหลอน (Hallucination) ให้เป็นศูนย์ได้ การออกแบบ Guardrails และ HITL (Human-in-the-loop) ควบคู่กันไปจะเป็นตัวกำหนดคุณภาพของการใช้งานจริง แนวทางที่สมเหตุสมผลที่สุดในการลดความเสี่ยงและสร้างผลลัพธ์ที่จับต้องได้ คือการเริ่มจาก PoC ขนาดเล็กเพื่อตรวจสอบสมมติฐาน แล้วจึงตัดสินใจขยายผลโดยอ้างอิงจากค่าที่วัดได้จริง