Adaptive RAG คืออะไร? วิธีสร้างสมดุลระหว่างต้นทุนและความแม่นยำด้วยการค้นหาแบบไดนามิกที่ขับเคลื่อนด้วย Query

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

หัวใจสำคัญของ Adaptive RAG คือการเลิกใช้ "กระบวนการสืบค้นแบบเดียวกันกับทุกคำถาม" และเปลี่ยนมาเป็นการเลือกกลยุทธ์การสืบค้นที่เหมาะสมที่สุดสำหรับแต่ละ Query ก่อนอื่นเราจะมาสรุปประเด็นปัญหาเชิงโครงสร้างของ RAG แบบคงที่ (Static RAG) ในรูปแบบเดิม จากนั้นจะตรวจสอบกลไกของ Dynamic Routing และตำแหน่งของแนวคิดที่เกี่ยวข้องอย่าง Active Retrieval ต่อไป

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

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

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

หัวใจสำคัญของ Adaptive RAG คือ "ตัวจำแนกความซับซ้อนของคำถาม" (Query Complexity Classifier) ซึ่งทำหน้าที่ประเมินความซับซ้อนของคำถามทันทีที่ได้รับ และจัดสรรไปยังกลยุทธ์การสืบค้น 3 รูปแบบ งานวิจัยที่นำเสนอกรอบแนวคิดนี้ (Jeong et al., NAACL 2024, arXiv:2403.14403) ได้ฝึกฝนโมเดลภาษาขนาดเล็ก (Lightweight Language Model) ให้ทำหน้าที่เป็นตัวจำแนกเพื่อส่งคำถามไปยังกลยุทธ์ต่อไปนี้:

จุดสำคัญในการนำไปใช้งานคือ ข้อมูลที่ใช้ฝึกฝนตัวจำแนกไม่ได้มาจากการติดป้ายกำกับโดยมนุษย์ แต่ใช้วิธีสร้างขึ้นโดยอัตโนมัติจากการทดสอบกับชุดข้อมูล QA ที่มีอยู่ว่า "กลยุทธ์ใดที่สามารถให้คำตอบที่ถูกต้องได้" งานวิจัยดังกล่าวยังรายงานว่า การกำหนดเส้นทางแบบปรับเปลี่ยนได้ (Adaptive Routing) นี้ ช่วยปรับปรุงสมดุลระหว่างความแม่นยำและประสิทธิภาพให้ดีขึ้นเมื่อเทียบกับการใช้กลยุทธ์เดียวแบบตายตัว

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

แนวทางที่มักถูกกล่าวถึงควบคู่กับ Adaptive RAG คือแนวทางที่เรียกว่า การสืบค้นเชิงรุก (Active Retrieval) ทั้งสองแนวทางมีแนวคิดร่วมกันคือ "สืบค้นเฉพาะเมื่อจำเป็น" แต่มีช่วงเวลาในการตัดสินใจที่แตกต่างกัน

ตัวอย่างที่เป็นตัวแทนของ Active Retrieval คือ FLARE (arXiv:2305.06983) ซึ่งจะเริ่มการสืบค้นในขณะที่กำลังสร้างคำตอบ เมื่อตัดสินใจได้ว่า "ไม่มั่นใจในประโยคถัดไป" ส่วน Self-RAG (arXiv:2310.11511) จะดำเนินการสร้างคำตอบไปพร้อมกับการที่โมเดลประเมินความจำเป็นในการสืบค้นและความเป็นประโยชน์ของผลลัพธ์ที่ได้ด้วยตนเองผ่านโทเค็นพิเศษ ทั้งสองวิธีถือเป็น "การปรับปรุงประสิทธิภาพระหว่างการทำงาน" (Runtime Optimization) ที่แทรกการสืบค้นแบบไดนามิกระหว่างกระบวนการสร้างคำตอบ

ในทางตรงกันข้าม Adaptive RAG ถือเป็น "การปรับปรุงประสิทธิภาพล่วงหน้า" (Pre-generation Optimization) ที่กำหนดกลยุทธ์ตั้งแต่จุดเริ่มต้นเมื่อได้รับคำถาม ทั้งสองแนวทางนี้ไม่ได้แยกขาดจากกัน แต่สามารถนำมาผสมผสานกันได้ เช่น ในกรณีที่ Adaptive RAG ตัดสินใจที่จุดเริ่มต้นว่าคำถามนั้นต้องการการสืบค้นหลายขั้นตอน ในระหว่างการทำงานก็สามารถใช้ Active Retrieval เพื่อควบคุมจังหวะการสืบค้นได้ ซึ่งหากมองว่า Agentic RAG ที่เอเจนต์วางแผนการสืบค้นด้วยตนเองนั้นเป็นวิวัฒนาการที่ต่อยอดมาจากแนวทางเหล่านี้ ก็จะทำให้เข้าใจได้ง่ายขึ้น

Adaptive RAG มีโครงสร้างที่วาง "ตัวจำแนกประเภท" (Classifier) และ "เส้นทางการสืบค้นที่หลากหลาย" (Multiple search paths) ไว้บนพื้นฐานของ RAG เดิมที่มีอยู่ ดังนั้นคุณภาพของรากฐานจึงเป็นตัวกำหนดความสำเร็จ ต่อไปนี้คือการสรุปส่วนประกอบและเกณฑ์การคัดเลือกที่ควรตรวจสอบก่อนการนำไปใช้งาน

องค์ประกอบของ Adaptive RAG มีอยู่ 3 ส่วนหลัก ดังนี้:

1. เวกเตอร์ดาต้าเบส (Vector Database): ทำหน้าที่จัดเก็บ Embedding ของเอกสารและรองรับการค้นหาความคล้ายคลึง (Similarity Search) โดยสามารถใช้ Vector Database ที่ใช้งานอยู่ในระบบ RAG เดิมได้ทันที
2. LLM สำหรับการสร้างคำตอบ: เป็นส่วนหลักที่ใช้สร้างคำตอบ หากต้องการเลือกใช้โมเดลตามกลยุทธ์ที่แตกต่างกัน สามารถเตรียมไว้หลายโมเดลได้ (การประมวลผลแบบแบ่งระดับหรือ Tiered Processing ซึ่งจะกล่าวถึงในภายหลัง)
3. ตัวจำแนกประเภทคำถาม (Query Classifier): เป็นองค์ประกอบที่เพิ่มเข้ามาใหม่ใน Adaptive RAG

วิธีการติดตั้งตัวจำแนกประเภทสามารถแบ่งออกได้เป็น 3 รูปแบบหลัก ได้แก่ ตัวจำแนกขนาดเล็กที่ผ่านการฝึกฝนมาแล้ว (รวดเร็วและต้นทุนต่ำ แต่ต้องใช้ข้อมูลในการฝึกฝน), การจำแนกแบบ Zero-shot โดยใช้ Prompt กับ LLM (ไม่ต้องฝึกฝนและติดตั้งได้ง่าย แต่มีค่าใช้จ่ายในการประมวลผลเพื่อจำแนกประเภทในทุกคำถาม), และแบบใช้กฎเกณฑ์ (Rule-based) ตามความยาวของคำถามหรือคำสำคัญ (รวดเร็วที่สุด แต่รับมือกับความหลากหลายของรูปแบบภาษาได้น้อย)

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

คุณภาพของชั้นการค้นหา (Search Layer) ถือเป็นรากฐานของคุณภาพคำตอบ ไม่ว่าจะถูกส่งไปยังกลยุทธ์ใดก็ตาม สิ่งที่ต้องตรวจสอบเป็นพิเศษมี 2 ประการ คือ วิธีการค้นหา และโมเดลการฝัง (Embedding Model)

สำหรับวิธีการค้นหา ขอแนะนำให้ใช้ Hybrid Search ซึ่งเป็นการผสมผสานระหว่างการจับคู่คำสำคัญ (เช่น BM25) และ Semantic Search เข้าด้วยกัน การค้นหาด้วยคำสำคัญจะมีประสิทธิภาพสูงในการจับคู่หมายเลขรุ่นหรือชื่อเฉพาะที่ตรงกันทุกประการ ในขณะที่การค้นหาด้วยเวกเตอร์จะมีประสิทธิภาพสูงในการจัดการกับคำพ้องความหมายหรือคำถามเชิงแนวคิด ซึ่งสอดคล้องกับจุดประสงค์ของ Adaptive RAG ที่ต้องการรองรับคำค้นหาที่หลากหลาย

เกณฑ์ในการเลือกโมเดลการฝัง (Embedding Model) มี 3 ประการ ดังนี้:

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

นอกจากนี้ ควรตรวจสอบความเป็นไปได้ในการนำการจัดลำดับใหม่ (Reranking) มาใช้เพื่อเรียงลำดับผลลัพธ์การค้นหาในลำดับต้นๆ ไว้ในขั้นตอนนี้ด้วย

Adaptive RAG ไม่ใช่การสร้างใหม่ตั้งแต่ต้น แต่เป็นการขยายระบบโดยการเพิ่มเลเยอร์การจัดเส้นทาง (Routing Layer) ไว้หน้าไปป์ไลน์เดิม ความง่ายในการติดตั้งขึ้นอยู่กับระดับความเป็นอิสระของการใช้งานที่มีอยู่เดิม

มี 3 ประเด็นที่ควรตรวจสอบ ประการแรก คือกระบวนการสืบค้น (Search process) ถูกแยกออกจากกระบวนการสร้าง (Generation process) ในรูปแบบของฟังก์ชันหรือ API แล้วหรือไม่ หากการใช้งานมีการเชื่อมโยงกันอย่างแน่นหนาระหว่างการสืบค้นและการสร้าง จะทำให้ยากต่อการนำไปประยุกต์ใช้เป็นเส้นทางการสืบค้นแบบขั้นตอนเดียว ประการที่สอง คือจุดรับคำถาม (Query entry point) ถูกรวมไว้เป็นจุดเดียวหรือไม่ หากมีการเรียกใช้การสืบค้นจากหลายจุดอย่างกระจัดกระจาย จำเป็นต้องรวมจุดเข้าใช้งานให้เป็นหนึ่งเดียวก่อน ประการที่สาม คือมีการจัดเก็บล็อกของคุณภาพคำถามและคำตอบหรือไม่ ล็อกเหล่านี้คือข้อมูลสำหรับใช้ฝึกฝนตัวจำแนก (Classifier) ที่จะกล่าวถึงในภายหลัง หากดำเนินการเปลี่ยนไปใช้ Adaptive RAG โดยไม่มีโครงสร้างพื้นฐานของล็อก จะทำให้วงจรการปรับปรุงตัวจำแนกไม่สามารถทำงานได้

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

การสร้างระบบจะดำเนินการตาม 3 ขั้นตอน ได้แก่ "ตัวจำแนกประเภท (Classifier) → ไปป์ไลน์แยกตามกลยุทธ์ (Strategy-specific Pipeline) → การรวมเส้นทาง (Routing Integration)" เนื่องจากแต่ละขั้นตอนสามารถตรวจสอบแยกกันได้อย่างอิสระ จึงสามารถทยอยปล่อยฟีเจอร์เพื่อลดความเสี่ยงได้

ขั้นตอนแรกคือการออกแบบตัวจำแนกความซับซ้อนของคิวรี (Query Complexity Classifier) โดยใช้การแบ่ง 3 ประเภทตามที่กล่าวไปข้างต้น (ไม่ต้องค้นหา / ขั้นตอนเดียว / หลายขั้นตอน) เป็นพื้นฐาน

สำหรับการสร้างข้อมูลการเรียนรู้ สามารถใช้วิธีการติดป้ายกำกับอัตโนมัติ (Automatic Labeling) ที่นำเสนอในงานวิจัย Adaptive RAG (arXiv:2403.14403) ได้ โดยใช้วิธีรันกลยุทธ์ทั้ง 3 รูปแบบกับคู่ QA ที่มีอยู่ แล้วกำหนดให้ "กลยุทธ์ที่เบาที่สุดที่สามารถตอบได้ถูกต้อง" เป็นป้ายกำกับของคิวรีนั้นๆ เนื่องจากไม่จำเป็นต้องใช้คนทำ Annotation ข้อมูลการเรียนรู้จึงเพิ่มขึ้นตามบันทึกการใช้งานที่สะสมมากขึ้น

แล้วในช่วงเริ่มต้นที่ยังไม่มีข้อมูลการเรียนรู้ควรทำอย่างไร? หลายทีมมักจะหยุดชะงักเพราะต้องการสร้างตัวจำแนกที่สมบูรณ์แบบ แต่คำตอบนั้นเรียบง่าย คือในช่วงแรกให้ใช้ Zero-shot Classification Prompt ของ LLM แทนไปก่อน เพียงแค่ถามว่า "คิวรีต่อไปนี้จัดอยู่ในประเภทใด: A: ไม่ต้องค้นหา / B: ตอบได้ด้วยการค้นหา 1 ครั้ง / C: ต้องใช้การผสมผสานแหล่งข้อมูลหลายแห่ง" ก็ถือเป็นการจัดสรรที่สมเหตุสมผลมากกว่าการใช้ Pipeline แบบตายตัว

ในการประเมินผล สิ่งที่ควรให้ความสำคัญไม่ใช่แค่ความแม่นยำในการจำแนก แต่คือความไม่สมมาตรของต้นทุนจากความผิดพลาดในการจำแนก (Asymmetry of misclassification cost) ความผิดพลาดที่นำคิวรีง่ายๆ ไปผ่านการค้นหาหลายขั้นตอนเป็นเพียง "การสิ้นเปลืองต้นทุน" แต่ความผิดพลาดที่นำคิวรีซับซ้อนไปตอบโดยไม่ค้นหาจะนำไปสู่ "คำตอบที่ผิด" โดยตรง ดังนั้นควรออกแบบการประเมินที่ลงโทษกรณีหลังอย่างหนัก และกำหนดเกณฑ์ (Threshold) ให้เอนเอียงไปทางฝั่งที่มีการค้นหาหากเกิดความไม่แน่ใจ

ถัดไป ให้สร้างไปป์ไลน์ปลายทางสำหรับการทำ Routing ทั้ง 3 รูปแบบแยกจากกันโดยอิสระ

• เส้นทางแบบไม่ใช้การค้นหา (Search-less path): ให้ LLM ตอบคำถามด้วยตัวเอง ข้อควรระวังคือต้องระบุเงื่อนไขใน System Prompt ให้ชัดเจนว่า "ข้อมูลเฉพาะของบริษัทให้เป็นหน้าที่ของเส้นทางการค้นหา" และจำกัดไม่ให้โมเดลคาดเดาคำตอบในสิ่งที่ตนไม่รู้
• เส้นทางแบบค้นหาขั้นตอนเดียว (Single-step search path): สามารถนำไปป์ไลน์ RAG ที่มีอยู่มาปรับใช้ได้เกือบทั้งหมด โดยเป็นโครงสร้างมาตรฐานคือ การค้นหา (Search) → การใส่ข้อมูลจาก Chunk ลำดับต้นๆ (Injection) → การสร้างคำตอบ (Generation)
• เส้นทางแบบค้นหาหลายขั้นตอน (Multi-step search path): ทำการแยกย่อยคำถามออกเป็นคำถามย่อยๆ แล้วสลับการค้นหาและการอนุมานเพื่อสร้างคำตอบ เนื่องจากต้องมีการควบคุมลูป (จำนวนรอบสูงสุดและเงื่อนไขการสิ้นสุด) จึงเป็นเส้นทางที่ซับซ้อนที่สุดในการติดตั้งใช้งานจากทั้ง 3 รูปแบบ

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

สุดท้ายคือการเชื่อมต่อตัวจำแนก (Classifier) เข้ากับ 3 เส้นทาง (Paths) เพื่อให้ทำงานแบบ End-to-End แม้ตัวการใช้งานจริงจะเป็นเพียง "การแยกสาขาตามผลลัพธ์การจำแนก" แต่สิ่งที่กำหนดคุณภาพในการดำเนินงานมี 3 ประการดังนี้:

1. การออกแบบ Fallback: กำหนดค่าเริ่มต้นให้เควอรีที่ตัวจำแนกมีความมั่นใจต่ำหันไปใช้การค้นหาแบบขั้นตอนเดียว (Single-step retrieval) และเตรียมทางออกสำหรับกรณีที่การค้นหาแบบหลายขั้นตอน (Multi-step retrieval) ถึงจำนวนรอบสูงสุดแล้วแต่ยังหาหลักฐานไม่ครบ โดยให้เปลี่ยนไปใช้ "การตอบเท่าที่ทราบ + การระบุข้อมูลที่ขาดหาย" แทน
2. การติดตามผลแยกตามกลยุทธ์: บันทึกการกระจายตัวของ Routing (ว่าแต่ละกลยุทธ์รับงานไปกี่เปอร์เซ็นต์) รวมถึงแยกบันทึกค่า Latency, การใช้ Token และคุณภาพของคำตอบในแต่ละกลยุทธ์ หากไม่มีรายละเอียดส่วนนี้ จะไม่สามารถตัดสินได้ว่าสิ่งที่ควรปรับปรุงคือตัวจำแนกหรือเส้นทางเฉพาะจุด
3. การทยอยปล่อยใช้งาน (Gradual Release): อย่าเพิ่งเปลี่ยนผ่านทราฟฟิกทั้งหมดในทันที แต่ให้เริ่มจากโหมด Shadow เพื่อตรวจสอบการกระจายตัวโดยบันทึกเฉพาะการตัดสินใจของ Routing ควบคู่ไปกับระบบ RAG เดิม จากนั้นจึงค่อยๆ เปลี่ยนผ่านทราฟฟิกบางส่วน

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

ประสิทธิภาพในการลดต้นทุนของ Adaptive RAG ไม่ได้ขึ้นอยู่กับการทำ Routing เพียงอย่างเดียว แต่ยังขึ้นอยู่กับการออกแบบ Token ภายใน Pipeline ด้วย ในที่นี้จะอธิบายถึง 3 กลไกการปรับแต่งที่สามารถเลือกใช้ได้ตามกลยุทธ์

ปริมาณโทเค็นขาเข้าจะถูกกำหนดโดย "ขนาดของส่วนข้อมูล (chunk size) × จำนวนรายการที่ดึงข้อมูล (top-k)" เป็นหลัก ซึ่งความสามารถในการปรับเปลี่ยนค่าเหล่านี้ตามกลยุทธ์ที่แตกต่างกันคือข้อได้เปรียบด้านต้นทุนของ Adaptive RAG

ในไปป์ไลน์แบบคงที่ (Fixed Pipeline) มักจะมีการกำหนดขนาดส่วนข้อมูลที่ใหญ่และค่า k ที่สูงเพื่อรองรับคำถามที่ซับซ้อนสำหรับทุกคำถาม ทำให้ต้องเสียค่าใช้จ่ายด้านโทเค็นเท่ากันแม้จะเป็นคำถามที่ง่ายก็ตาม แต่สำหรับ Adaptive RAG เราสามารถแยกส่วนได้ เช่น เส้นทางการค้นหาแบบขั้นตอนเดียวใช้ค่า k ที่น้อยกว่า ส่วนเส้นทางการค้นหาแบบหลายขั้นตอนจะดึงข้อมูลทีละน้อยในแต่ละรอบการทำซ้ำ

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

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

ไม่จำเป็นต้องใช้ LLM ระดับสูงสุดในทุกขั้นตอนของกระบวนการ การแบ่ง "ระดับ (Tier)" ของโมเดลตามบทบาทหน้าที่ช่วยให้สามารถลดต้นทุนได้โดยยังคงคุณภาพไว้

โดยสรุปแล้ว รูปแบบพื้นฐานคือการมอบหมายงานที่มีน้ำหนักเบาอย่างการจำแนกประเภท (Classification) ให้กับ SLM ส่วนงานที่ต้องอาศัยการสังเคราะห์เอกสารหลายฉบับหรือการใช้เหตุผลในการสร้างเนื้อหา ให้มอบหมายให้กับ LLM

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

คันโยกที่สามคือการลดจำนวนการเรียกใช้ LLM ตั้งแต่ต้น

• Semantic Cache: ตรวจจับคำถามที่มีความหมายเดียวกัน เช่น "วิธีลาพักร้อนทำอย่างไร?" กับ "จะขอลาพักร้อนต้องทำยังไง?" โดยใช้ความคล้ายคลึงของ Embedding เพื่อนำคำตอบเดิมกลับมาใช้ใหม่ ซึ่งมีประสิทธิภาพสูงสำหรับเวิร์กโหลดที่มีลักษณะเป็น FAQ
• Embedding Cache: หลีกเลี่ยงการคำนวณ Embedding ซ้ำสำหรับข้อความเดิม โดยใช้ร่วมกับการทำ Differential Embedding เมื่อมีการอัปเดตเอกสาร
• Prompt Cache: ใช้ฟังก์ชัน Prompt Cache ที่มีให้ใน API ของ LLM หลัก เพื่อลดต้นทุนการประมวลผลซ้ำสำหรับ System Prompt หรือบริบทที่เป็นรูปแบบมาตรฐาน
• Throttling: การควบคุมอัตราการใช้งาน (Rate Control) ต่อผู้ใช้หรือต่อ Tenant เพื่อป้องกันค่าใช้จ่ายที่พุ่งสูงขึ้นจากไคลเอนต์ที่ทำงานผิดพลาดหรือการส่งคำถามรัวๆ อย่างมีเจตนาร้าย

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

การลดต้นทุนจะไม่มีความหมายเลยหากยังให้คำตอบที่ผิดพลาด หัวใจสำคัญด้านความแม่นยำของ Adaptive RAG คือการตรวจสอบความถูกต้องของข้อมูล (Grounding Check) ซึ่งเป็นการประเมินคุณภาพของผลลัพธ์การค้นหาโดยอัตโนมัติ และการรองรับคำถามที่ซับซ้อนด้วยกระบวนการหลายขั้นตอน (Multi-step reasoning)

Grounding คือการทำให้คำตอบของ LLM ยึดโยงอยู่กับเอกสารอ้างอิงที่ได้จากการสืบค้น ใน Adaptive RAG เราสามารถแทรกจุดตรวจสอบได้ 2 ตำแหน่ง คือหลังการสืบค้นและหลังการสร้างคำตอบ

สำหรับการตรวจสอบหลังการสืบค้น สิ่งที่ใช้เป็นแนวทางได้คือตัวประเมินผลการสืบค้นที่เสนอโดย CRAG (Corrective RAG, arXiv:2401.15884) โดยใช้ตัวประเมินที่มีน้ำหนักเบาตัดสินว่าเอกสารที่ได้มานั้นเกี่ยวข้องกับคำถามจริงหรือไม่ หากคุณภาพต่ำ จะไม่ดำเนินการสร้างคำตอบต่อทันที แต่จะใช้มาตรการแก้ไข เช่น การเขียนคำถามใหม่เพื่อสืบค้นซ้ำ หรือการเปลี่ยนไปใช้แหล่งข้อมูลอื่น ซึ่งเป็นแนวคิดในการจัดการที่ต้นเหตุของปัญหาที่ว่า "หากสร้างคำตอบโดยที่ผลการสืบค้นไม่ดี จะนำไปสู่ Hallucination"

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

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

คำถามประเภท "มีข้อขัดแย้งระหว่างเงื่อนไขในสัญญาของบริษัท X กับระเบียบภายในปัจจุบันหรือไม่" จำเป็นต้องดึงเอกสารหลายฉบับมาเปรียบเทียบกัน ซึ่งไม่สามารถตอบได้ด้วยการค้นหาเพียงครั้งเดียว รูปแบบการออกแบบเส้นทางการค้นหาแบบหลายขั้นตอน (Multi-step search path) มี 3 รูปแบบ ดังนี้:

1. การแยกย่อยคำถาม (Query Decomposition): แยกคำถามหลักออกเป็นคำถามย่อยๆ แล้วทำการค้นหาแยกกันก่อนจะนำมารวมกัน เนื่องจากสามารถรันคำถามย่อยแบบขนานได้ จึงช่วยลดค่า Latency ได้ง่าย
2. การค้นหาแบบสลับ (Iterative Search): ระบุ "ข้อมูลที่จำเป็นในลำดับถัดไป" ในขณะที่ดำเนินการอนุมาน (Reasoning) แล้วทำการค้นหาซ้ำ แม้จะเป็นกระบวนการแบบลำดับเนื่องจากผลลัพธ์การค้นหาก่อนหน้าจะกำหนดคำค้นหาถัดไป แต่ก็มีประสิทธิภาพสูงสำหรับการอนุมานที่มีความสัมพันธ์เชิงพึ่งพากัน
3. การสร้างพร้อมการประเมินตนเอง (Self-reflective Generation): เช่นเดียวกับ Self-RAG (arXiv:2310.11511) คือการให้โมเดลประเมินความจำเป็นในการค้นหาและความเป็นประโยชน์ของผลลัพธ์ที่ได้ด้วยตนเองในระหว่างการสร้างคำตอบ

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

นอกจากนี้ หากมีคำถามที่ต้องติดตามความสัมพันธ์ระหว่างเอนทิตี (เช่น ผังองค์กร หรือความสัมพันธ์เชิงพึ่งพา) จำนวนมาก การใช้ GraphRAG ร่วมด้วยจะเหมาะสมกว่า

ปัญหาของ Adaptive RAG มักไม่ได้ปรากฏในรูปแบบของข้อผิดพลาดที่ชัดเจน แต่จะแสดงออกมาในรูปแบบของ "คุณภาพที่ค่อยๆ เสื่อมถอยลงอย่างเงียบๆ" ต่อไปนี้คือ 2 รูปแบบความล้มเหลวที่พบบ่อยและแนวทางการแก้ไข

ความล้มเหลวที่พบบ่อยที่สุดคือกรณีที่เควอรี (Query) ที่ซับซ้อนถูกจัดสรรไปยังเส้นทาง "ไม่ใช้การค้นหา" (No-search path) อย่างผิดพลาด ในกรณีนี้ระบบจะไม่แสดงข้อผิดพลาด แต่ LLM จะตอบกลับด้วยความมั่นใจโดยใช้เพียงความรู้ที่มีอยู่ ซึ่งอาจนำไปสู่คำตอบที่ผิดพลาดแต่ดูน่าเชื่อถือ ปัญหานี้มักถูกตรวจพบเมื่อผู้ใช้รายงานว่า "คำตอบไม่ละเอียด" หรือ "ข้อมูลไม่ถูกต้อง" ซึ่งยากที่จะระบุว่าสาเหตุมาจากระบบการจัดเส้นทาง (Routing)

แนวทางแก้ไขมี 4 ประการ:

• เกณฑ์แบบไม่สมมาตร (Asymmetric threshold): หากความมั่นใจในการจัดประเภทต่ำ ให้เลือกเส้นทางที่ใช้การค้นหา ต้นทุนที่เสียไปจากการค้นหาโดยไม่จำเป็นนั้นถูกกว่าความเสียหายจากคำตอบที่ผิดพลาดเพราะไม่ได้ค้นหา
• การใช้งานแบบ Shadow mode: ก่อนที่จะเปลี่ยนไปใช้ระบบจริง ให้บันทึกเฉพาะผลการตัดสินใจของ Routing แล้วนำไปเปรียบเทียบกับคำตอบของ RAG ที่มีอยู่เพื่อทำความเข้าใจแนวโน้มของการจัดประเภทที่ผิดพลาด
• การตรวจสอบคุณภาพแยกตามกลยุทธ์: แยกตัวชี้วัดคุณภาพตามเส้นทาง เช่น "อัตราการให้คะแนนต่ำต่อคำตอบในเส้นทางไม่ใช้การค้นหา" เพราะค่าเฉลี่ยโดยรวมอาจทำให้การเสื่อมถอยของเส้นทางใดเส้นทางหนึ่งถูกกลบไป
• การเรียนรู้ใหม่เป็นระยะ (Periodic retraining): รวบรวมกรณีการจัดประเภทผิดพลาดจากบันทึกการใช้งาน (Operation logs) เพื่ออัปเดตตัวจำแนกประเภท (Classifier) อย่างต่อเนื่อง เนื่องจากแนวโน้มของเควอรีจะเปลี่ยนแปลงไปตามการใช้งานจริง

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

อีกหนึ่งความล้มเหลวคือความเสื่อมถอยของชั้นการค้นหา (search layer) เอง ซึ่งมีสาเหตุมาจาก 2 ปัจจัยหลัก

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

ประการที่สองคือความเสี่ยงจากปัจจัยภายนอกที่เรียกว่า RAG poisoning หากมีข้อความที่เป็นอันตรายปะปนอยู่ในแหล่งที่มาของฐานความรู้ (เช่น ไดรฟ์ที่แชร์, หน้าเว็บ, หรือเอกสารที่ได้รับจากภายนอก) เมื่อข้อความเหล่านั้นถูกค้นพบ จะทำหน้าที่เป็น Prompt Injection ทางอ้อมต่อ LLM ซึ่งอาจนำไปสู่การชี้นำคำตอบหรือการรั่วไหลของข้อมูลได้

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

Q. ควรเลือกใช้ Adaptive RAG หรือ RAG แบบปกติ? ให้ตัดสินจากความหลากหลายของคำถาม (Query) หากคำถามของผู้ใช้เป็นรูปแบบตายตัวและมีความยากง่ายเท่ากัน การใช้ RAG แบบปกติที่มีไปป์ไลน์คงที่ก็เพียงพอแล้ว แต่สำหรับระบบที่มีความหลากหลายของคำถามสูง ตั้งแต่การทักทายทั่วไปไปจนถึงการใช้เหตุผลแบบหลายขั้นตอน (Multi-hop reasoning) และมีปริมาณคำถามจำนวนมาก Adaptive RAG จะให้ผลลัพธ์ที่คุ้มค่ากว่าทั้งในด้านการลดต้นทุนและการปรับปรุงความแม่นยำ

Q. Adaptive RAG กับ Agentic RAG ต่างกันอย่างไร? ต่างกันที่ตัวตัดสินใจและขอบเขตครับ Adaptive RAG เป็นกลไกที่ตัดสินใจเพียงครั้งเดียวที่จุดเริ่มต้นว่า "ควรใช้กลยุทธ์การค้นหาแบบใด" ในขณะที่ Agentic RAG หมายถึงกรอบการทำงานที่กว้างกว่า ซึ่งตัวแทน (Agent) จะทำการค้นหา ดำเนินการผ่านเครื่องมือ และวางแผนใหม่ซ้ำๆ อย่างอิสระ หากนำการควบคุมแบบ Agent มาใช้ในเส้นทางการค้นหาหลายขั้นตอนของ Adaptive RAG ทั้งสองแนวทางก็จะทับซ้อนกันโดยธรรมชาติ

Q. ควรใช้โมเดลแบบไหนสำหรับตัวจำแนกคำถาม (Query Classifier)? แนวทางที่เป็นจริงที่สุดคือการค่อยๆ พัฒนาไปทีละขั้น ในช่วงเริ่มต้นให้ใช้ Zero-shot classification prompt กับ LLM ไปก่อน และเมื่อมีบันทึกการใช้งาน (Operation log) สะสมมากขึ้น จึงค่อยฝึกฝน SLM หรือตัวจำแนกขนาดเล็กมาแทนที่ เนื่องจากเป็นกระบวนการที่ต้องทำงานกับทุกคำถาม การใช้โมเดลที่มีความหน่วงต่ำและต้นทุนต่ำในท้ายที่สุดจึงเป็นวิธีปฏิบัติที่เป็นมาตรฐาน

Q. การนำ Adaptive RAG มาใช้จะช่วยลดต้นทุนได้มากน้อยเพียงใด? ไม่สามารถระบุตัวเลขที่แน่นอนได้เนื่องจากขึ้นอยู่กับการกระจายตัวของคำถาม ยิ่งเวิร์กโหลดมีสัดส่วนของคำถามง่ายๆ ที่ไม่จำเป็นต้องค้นหาข้อมูลมากเท่าใด การลดต้นทุนก็จะยิ่งเห็นผลชัดเจนมากขึ้นเท่านั้น ก่อนการนำไปใช้จริง คุณสามารถประมาณการผลลัพธ์ที่จะเกิดขึ้นกับองค์กรได้โดยการสุ่มตัวอย่างจากบันทึกที่มีอยู่ เพื่อประเมิน "สัดส่วนของคำถามที่สามารถตอบได้โดยไม่ต้องค้นหาข้อมูล" ทั้งนี้ งานวิจัยที่นำเสนอ (arXiv:2403.14403) ได้รายงานว่าผลลัพธ์ที่ได้คือการปรับปรุงสมดุลระหว่างความแม่นยำและประสิทธิภาพ โดยอัตราการลดต้นทุนที่แท้จริงนั้นขึ้นอยู่กับเวิร์กโหลดของแต่ละที่ครับ

Adaptive RAG คือเทคนิคการขยายขีดความสามารถของ RAG โดยการประเมินความซับซ้อนของ Query ตั้งแต่ต้นทาง และเลือกใช้กลยุทธ์การทำงาน 3 รูปแบบอย่างไดนามิก ได้แก่ การไม่ใช้การค้นหา (No-search), การค้นหาแบบขั้นตอนเดียว (Single-step search) และการค้นหาแบบหลายขั้นตอน (Multi-step search) คุณค่าที่สำคัญที่สุดคือการแก้ปัญหาของโครงสร้างแบบเดิมที่ใช้ Pipeline เดียวกันกับทุก Query ซึ่งมักเกิดปัญหา "ต้นทุนเกินความจำเป็นสำหรับ Query ง่าย" และ "ความแม่นยำไม่เพียงพอสำหรับ Query ที่ซับซ้อน" ได้ในกลไกเดียว

แนวทางการนำไปใช้งานที่เหมาะสมคือการเริ่มแบบค่อยเป็นค่อยไป โดยเริ่มจากการทำ Routing ขนาดเล็กด้วย Zero-shot classification จากนั้นจึงพัฒนา Classifier ด้วย Log การใช้งานจริง และรักษาคุณภาพด้วยการทำ Grounding check และการตรวจสอบ (Monitoring) ไม่จำเป็นต้องเตรียม Classifier ที่สมบูรณ์แบบตั้งแต่เริ่มต้น แต่สามารถขยายขีดความสามารถโดยยังคงใช้ RAG Pipeline เดิมที่มีอยู่ได้

บริษัทของเราให้บริการสนับสนุนการใช้งาน AI รวมถึงการออกแบบและปรับปรุงการทำงานของ RAG Pipeline หากคุณกำลังพิจารณาการนำ Adaptive RAG มาใช้ให้เหมาะสมกับรูปแบบ Query ขององค์กร เราขอแนะนำให้เริ่มจากการวิเคราะห์ Log การใช้งานจริงเป็นอันดับแรก