ก่อนอนุมัติงบเทรนโมเดล: ใช้ RAG แยก “ความรู้” ออกจาก “ความสามารถ” ของ AI

เมื่อ AI ตอบเรื่องนโยบาย สินค้า หรือกระบวนการภายในไม่ได้ คำตอบแรกของหลายองค์กรคือ “ต้องเทรนโมเดลเพิ่ม” แต่ปัญหาอาจไม่ได้อยู่ที่ความสามารถของโมเดล หากอยู่ที่โมเดลไม่เคยเข้าถึงข้อมูลธุรกิจฉบับที่ถูกต้อง

การนำข้อมูลใหม่ทั้งหมดไปผูกไว้กับตัวโมเดลทำให้องค์กรต้องเตรียมชุดข้อมูล ใช้ทรัพยากรประมวลผล ทดสอบผลกระทบ และทำซ้ำเมื่อข้อมูลเปลี่ยน สถาปัตยกรรม Retrieval-Augmented Generation หรือ RAG จึงมีคุณค่าในฐานะทางเลือกเชิงโครงสร้าง เพราะแยก “ความรู้ที่เปลี่ยนได้” ออกจาก “ความสามารถพื้นฐานของโมเดล”

งบเทรนเพิ่มอาจกำลังแก้ปัญหาผิดประเภท

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

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

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

RAG เปลี่ยน AI จากผู้จดจำเป็นผู้ค้นข้อมูลก่อนตอบ

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

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

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

คำถามตัดสินใจ: ต้องเพิ่มความรู้หรือเปลี่ยนพฤติกรรม

เกณฑ์ที่ใช้งานง่ายคือพิจารณาว่าสิ่งที่ต้องการเปลี่ยนอยู่ “ภายนอก” หรือ “ภายใน” โมเดล

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

RAG ประหยัดงบตรงไหน และไม่ได้ประหยัดทุกจุด

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

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

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

สถาปัตยกรรมที่ลดงานซ้ำต้องเริ่มจากการจัดการความรู้

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

จากนั้นควรวางองค์ประกอบสำคัญให้ครบ:

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

สถาปัตยกรรมลักษณะนี้ทำให้การเปลี่ยนนโยบายเป็นงานดูแลความรู้ แทนที่จะกลายเป็นโครงการปรับโมเดลทุกครั้ง

เริ่มโครงการด้วยสมมติฐานที่วัดผลได้

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

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

สำหรับองค์กรที่ต้องเชื่อมข้อมูลหลายระบบ แนวทาง Private AI และ AI Knowledge Base ของ MXAI สามารถนำมาใช้เป็นส่วนหนึ่งของการออกแบบ RAG การควบคุมสิทธิ์ และการเชื่อมกระบวนการภายในได้ แต่การเลือกเทคโนโลยีควรเกิดหลังจากกำหนดกรณีใช้งาน เจ้าของข้อมูล และเกณฑ์ประเมินเรียบร้อยแล้ว

Key Takeaway สำหรับผู้อนุมัติงบ AI

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

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

คำถามที่พบบ่อยเกี่ยวกับ RAG และงบเทรนโมเดล

RAG ทำให้ไม่ต้องเทรนโมเดลเลยหรือไม่

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

RAG ต่างจากการส่งเอกสารทั้งหมดให้ AI อ่านอย่างไร

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

ข้อมูลเปลี่ยนบ่อยควรใช้ RAG หรือ Fine-tuning

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

RAG มีค่าใช้จ่ายอะไรที่ผู้บริหารควรรู้

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

ควรเริ่มทดลอง RAG กับงานประเภทใด

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