RAG หรือการปรับแต่งโมเดลเพิ่มเติม? โครงการจริงกับลูกค้าสอนอะไรเราเกี่ยวกับการเลือก

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

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

เริ่มจากดูว่าโมเดลยังขาดอะไร

เมื่อโมเดลให้คำตอบที่ไม่ดีในงานธุรกิจ แสดงว่าขาดสิ่งใดสิ่งหนึ่งจากสองอย่างนี้

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

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

RAG เป็นเครื่องมือสำหรับแก้ปัญหาแรก ส่วนการปรับแต่งโมเดลเพิ่มเติมเป็นเครื่องมือสำหรับปัญหาที่สอง ความสับสนส่วนใหญ่ที่ฉันพบเกิดจากการพยายามใช้การปรับแต่งโมเดลเพิ่มเติมเพื่อสอนข้อเท็จจริง

เหตุใดการปรับแต่งโมเดลเพิ่มเติมจึงไม่ใช่วิธีที่ดีในการเพิ่มความรู้

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

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

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

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

จุดที่การปรับแต่งโมเดลเพิ่มเติมมีประโยชน์

การปรับแต่งโมเดลเพิ่มเติมยังไม่หมดความสำคัญ เพียงแต่มีขอบเขตการใช้งานแคบกว่าที่หลายคนคิด เราเลือกใช้ในสามสถานการณ์นี้:

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

สังเกตว่าไม่มีข้อใดเกี่ยวกับข้อเท็จจริง แต่ทั้งหมดเกี่ยวกับการสอนให้โมเดลทำงานตามที่ต้องการในงานที่คุณเข้าใจดีอยู่แล้ว

ความล้มเหลวของ RAG ส่วนใหญ่เกิดจากการดึงข้อมูล

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

วิธีแก้เหล่านี้อาจไม่หวือหวา แต่ได้ผล:

• แบ่งเนื้อหาตามความหมาย ไม่ใช่ตามจำนวนตัวอักษร การแบ่งสัญญาทุก ๆ 500 ตัวอักษรทำให้ข้อสัญญาถูกตัดขาดครึ่งหนึ่ง แต่การแบ่งตามส่วนและหัวข้อช่วยรักษาบริบทให้ครบถ้วน
• เพิ่มบริบทให้แต่ละส่วน ส่วนข้อความที่ระบุว่า “กำหนดเวลาไว้ที่ 30 วัน” ไม่มีประโยชน์หากไม่รู้ว่าเป็นข้อกำหนดของนโยบายใด Anthropic รายงานว่า การเพิ่มบริบทสั้น ๆ จากเอกสารให้แต่ละส่วนก่อนจัดทำดัชนี ซึ่งเป็นแนวทางที่เรียกว่าการดึงข้อมูลเชิงบริบท ช่วยลดกรณีที่ดึงข้อมูลไม่สำเร็จได้ 49% และลดได้ 67% เมื่อใช้ร่วมกับการจัดอันดับผลลัพธ์ใหม่
• ใช้การค้นหาด้วยคำสำคัญร่วมกับการค้นหาเวกเตอร์ การค้นหาเวกเตอร์ค้นหาตามความหมายได้ดี แต่ไม่เก่งกับคำที่ต้องตรงกันทุกประการ เช่น หมายเลขชิ้นส่วน การค้นหาแบบผสมผสานรองรับทั้งสองแบบ
• ทดสอบการดึงข้อมูลแยกต่างหาก สร้างชุดคำถามจริงที่มีข้อความต้นทางที่ถูกต้องระบุไว้ แล้ววัดว่าข้อความที่เกี่ยวข้องปรากฏอยู่ในผลลัพธ์อันดับต้น ๆ หรือไม่ ก่อนประเมินคำตอบสุดท้าย

เมื่อใดควรใช้ทั้งสองวิธี

ในการใช้งานจริง ระบบที่มีประสิทธิภาพสูงสุดมักใช้ทั้งสองวิธีร่วมกัน RAG ช่วยให้ข้อเท็จจริง ส่วนโมเดลที่ปรับแต่งเพิ่มเติมเพียงเล็กน้อยจะจัดการรูปแบบ น้ำเสียง และภาษาที่ใช้ในสาขานั้น ๆ งานวิจัยก็มุ่งไปในทิศทางเดียวกัน โดย แนวทาง RAFT จาก UC Berkeley จะปรับแต่งโมเดลโดยเฉพาะเพื่อให้ใช้เอกสารที่ดึงมาได้ดีขึ้น และละเว้นเอกสารที่ไม่เกี่ยวข้อง

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

รายการตรวจสอบเพื่อตัดสินใจอย่างง่าย

1. งานนี้ขึ้นอยู่กับข้อเท็จจริงที่เปลี่ยนแปลงมากกว่าหนึ่งครั้งต่อไตรมาสหรือไม่ ใช้ RAG
2. ผู้ใช้หรือผู้ตรวจสอบจำเป็นต้องเห็นที่มาของคำตอบหรือไม่ ใช้ RAG
3. ปัญหาอยู่ที่รูปแบบ น้ำเสียง หรือคำศัพท์ในคำตอบ ไม่ใช่ข้อเท็จจริงใช่หรือไม่ พิจารณาปรับแต่งโมเดล
4. เป็นงานเฉพาะด้านที่ทำซ้ำในปริมาณมาก โดยมีต้นทุนหรือความเร็วเป็นปัจจัยสำคัญหรือไม่ พิจารณาปรับแต่งโมเดลขนาดเล็ก
5. คุณได้วัดคุณภาพการดึงข้อมูลแยกต่างหากแล้วหรือยัง หากยัง ให้ทำสิ่งนี้ก่อนอย่างอื่น

สรุปประเด็นสำคัญ

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