โครงการ Enterprise AI มักมีรูปแบบที่คล้ายกัน ทีมงานสร้างต้นแบบขึ้นมา การสาธิตดูน่าประทับใจ แต่สามเดือนต่อมา ระบบเริ่มพัง คำตอบเริ่มคลาดเคลื่อน ต้นทุนพุ่งสูงขึ้น เมื่อเจ้าหน้าที่ฝ่ายปฏิบัติตามกฎระเบียบ (compliance officer) ถามว่าคำตอบเฉพาะเจาะจงนั้นมาจากไหน กลับไม่มีใครในห้องที่ตอบได้

ความล้มเหลวนี้ไม่ค่อยได้เริ่มจากโค้ดที่แย่ แต่มันเริ่มจากการตัดสินใจทางสถาปัตยกรรมเพียงครั้งเดียวที่ถูกปฏิบัติเหมือนการโหวตความนิยม นั่นคือ การเลือกระหว่าง Retrieval-Augmented Generation กับการทำ fine-tuning

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

กับดักของการสาธิต

แรงกดดันในการปล่อยฟีเจอร์ Generative AI นั้นรุนแรงมาก ทีมงานมักเลือกวิธีการหนึ่งเพราะเห็นจากบทช่วยสอน (tutorial) ที่เขียนไว้ดี หรือเพราะสไลด์นำเสนอของเวนเดอร์ทำให้มันดูเหมือนเป็นเรื่องง่าย นั่นเป็นวิธีที่แย่มากในการตัดสินใจเรื่องโครงสร้างพื้นฐาน (infrastructure)

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

ความหมายที่แท้จริงของ RAG

RAG ย่อมาจาก Retrieval-Augmented Generation แต่ชื่อนี้ทำให้มันฟังดูซับซ้อนกว่าความเป็นจริง หัวใจสำคัญของ RAG คือการตอบคำถามเพียงข้อเดียวว่า: ตอนนี้โมเดลจำเป็นต้องค้นหาข้อมูลอะไร?

ลองจินตนาการถึงพนักงานบริการลูกค้าที่ได้รับอนุญาตให้ค้นหาข้อมูลใน wiki ของบริษัทก่อนที่จะตอบตั๋ว (ticket) งาน RAG ทำสิ่งนั้นทุกประการ แต่ทำโดยอัตโนมัติ เมื่อผู้ใช้ถามคำถาม ระบบจะค้นหาชิ้นส่วนข้อความ (chunks of text) ที่เกี่ยวข้องจาก vector database หรือ document store จากนั้นจึงส่งชิ้นส่วนเหล่านั้นให้กับ language model ในฐานะบริบท (context) พร้อมกับคำถามต้นฉบับ โมเดลจะสร้างคำตอบโดยอิงจากหลักฐานที่ค้นพบ

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

ความหมายที่แท้จริงของ Fine-Tuning

Fine-tuning ตอบคำถามที่ต่างออกไปว่า: โมเดลควรมีพฤติกรรมอย่างไร?

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

ผลลัพธ์ที่ได้คือโมเดลที่ได้ซึมซับรูปแบบ (patterns) เข้าไปเป็นส่วนหนึ่งของตัวเองแล้ว