คู่มือปฏิบัติการ Agentic RAG: การวิเคราะห์หกโหมดและการประยุกต์ใช้ระดับการผลิต

อธิบาย 6 รูปแบบ Agentic RAG ด้วยการแลกเปลี่ยนในการผลิตจริง

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

แต่กลับอยู่ที่การที่ RAG แบบดั้งเดิมใช้วิธีการประมวลผลแบบเดิมๆ ซ้ำๆ สำหรับทุกคำถาม

Agentic RAG เปลี่ยนกระบวนทัศน์นี้ ระบบไม่ใช่แค่ทำการค้นหาแบบกลไกอีกต่อไป แต่สามารถตัดสินใจได้ด้วยตัวเองว่าเมื่อใดควรค้นหา ค้นหาอะไร และเมื่อใดควรหยุด

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

หลักการทำงานของ RAG แบบดั้งเดิม (จากหลักการแรก)

ก่อนอื่น ให้เราย้อนดูวิธีการทำงานของ RAG แบบดั้งเดิม การสร้างเสริมด้วยการค้นหา (Retrieval-Augmented Generation หรือ RAG) โดยทั่วไปประกอบด้วยขั้นตอนต่อไปนี้:

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

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

ขั้นตอนพื้นฐานเข้าใจง่ายมาก:

1. แปลงคำถามผู้ใช้เป็นการแสดงแทนเชิงตัวเลข (เวกเตอร์ฝังหรือ embedding)
2. ค้นหาเอกสารที่มีเวกเตอร์คล้ายกันในฐานข้อมูลเวกเตอร์
3. เพิ่มผลการค้นหาที่อยู่ในอันดับต้นๆ ลงในพรอมต์
4. สร้างคำตอบสุดท้าย

ขั้นตอนนี้ได้ผล แต่ก็มีข้อบกพร่องโดยธรรมชาติ

ทำไม RAG แบบดั้งเดิมถึงล้มเหลวในสภาพแวดล้อมการผลิต

วิธีการประมวลผลแบบไปป์ไลน์ตายตัวจะล้มเหลวในรูปแบบที่คาดเดาได้

• การค้นหาที่ไม่เกี่ยวข้องเกิดขึ้นบ่อย: ผู้ใช้ถาม: “นโยบายการคืนเงินของคุณคืออะไร?” ระบบอาจค้นหาเอกสารเกี่ยวกับการประมวลผลการชำระเงิน การจัดการการสมัครสมาชิก การตั้งค่าบัญชี เพียงเพราะพวกมันพูดถึง “เงิน” นโยบายการคืนเงินจริงอาจถูกฝังอยู่ในผลการค้นหาลำดับที่ห้า โมเดลต้องค้นหาสัญญาณที่มีประสิทธิภาพท่ามกลางสัญญาณรบกวนจำนวนมาก
• การค้นหามากเกินไปทำให้สิ้นเปลืองทรัพยากร: ปัญหาง่ายและปัญหาซับซ้อนได้รับการปฏิบัติเหมือนกัน ผู้ใช้ถาม: “อีเมลของคุณคืออะไร?” ระบบยังคงค้นหาเอกสาร 5 ฉบับและส่งให้โมเดล สำหรับคำถามที่โมเดลสามารถตอบได้โดยตรง คุณเสียค่าใช้จ่าย tokens มากกว่า 10 เท่าโดยเปล่าประโยชน์
• ความล่าช้าสะสมเป็นชั้นๆ: การฝังเวกเตอร์สำหรับคำถาม (50ms), การค้นหาฐานข้อมูลเวกเตอร์ (100ms), การจัดลำดับผลลัพธ์ใหม่ (150ms), การสร้างคำตอบ (800ms) คำถามง่ายๆ ก็อาจต้องใช้เวลาตอบสนองเกิน 1 วินาที ผู้ใช้จะรับรู้ถึงความล่าช้าได้ชัดเจน
• ข้อจำกัดของหน้าต่างบริบทนำไปสู่การแลกเปลี่ยนที่ยาก: แม้จะค้นหาเอกสารที่เกี่ยวข้อง 10 ฉบับ ก็อาจไม่สามารถใส่ทั้งหมดลงในหน้าต่างบริบทที่มีจำกัดได้ ควรตัดเนื้อหาบางส่วนออก หรือสรุปย่อก่อน? ทุกทางเลือกนำความเสี่ยงใหม่ๆ มาสู่ความล้มเหลว
• ปัญหาการหลอน (hallucination) ยังคงมีอยู่: แม้ผลการค้นหาจะดี โมเดลก็ยังอาจสร้างข้อมูลหลอนได้ มันอาจจับประโยคหนึ่งจากบริบทที่ค้นพบ มองข้ามข้อมูลที่ขัดแย้งในเอกสารอื่นๆ และสร้างคำตอบทั้งหมดรอบๆ มัน หรืออาจผสมข้อมูลที่ค้นพบกับข้อมูลการฝึกฝน สร้างคำตอบที่ดูมั่นใจแต่ผิดพลาด

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

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

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

สามารถเข้าใจได้ดังนี้: หาก RAG แบบดั้งเดิมเป็นไปป์ไลน์เส้นตรง Agentic RAG ก็คือต้นไม้ตัดสินใจ

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

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

ตัวอย่างง่ายๆ สามารถอธิบายจุดนี้ได้:

• ผู้ใช้ถาม: “15% ของ 240 คือเท่าไร?” RAG แบบดั้งเดิมอาจค้นหาเอกสารเกี่ยวกับการคำนวณเปอร์เซ็นต์ แต่ Agentic RAG สามารถระบุได้ว่านี่เป็นปัญหาคณิตศาสตร์ที่โมเดลสามารถแก้ได้โดยตรง จึงข้ามขั้นตอนการค้นหาไปทั้งหมด
• ผู้ใช้อีกคนถาม: “ราคาของเราเปลี่ยนแปลงอย่างไรในช่วงสองปีที่ผ่านมา?” RAG แบบดั้งเดิมอาจค้นหาหน้าราคาปัจจุบัน แต่ Agentic RAG สามารถระบุได้ว่าต้องการข้อมูลประวัติศาสตร์ จึงไปค้นหาเอกสารที่เก็บถาวร เปรียบเทียบเวอร์ชันต่างๆ และสรุปประเด็นการเปลี่ยนแปลง

ส่วนที่เป็น “Agentic” หมายถึงวงจรการตัดสินใจแบบไดนามิกนี้ ระบบสังเกตคำถาม ตัดสินใจว่าจะดำเนินการใด (ค้นหา, คำนวณ, สร้าง) ประเมินผลการดำเนินการ แล้วตัดสินใจว่าจะดำเนินการต่อไปหรือส่งคืนคำตอบสุดท้าย

เวิร์กโฟลว์หลักของ Agentic RAG

ลองดูตัวอย่างผู้ช่วยเอกสารว่า Agentic RAG จะจัดการกับคำถามจริงอย่างไร

คำถาม: “เปรียบเทียบวิธีการรับรองความถูกต้องในเวอร์ชัน 2.x และ 3.x”

ระบบจะผ่านขั้นตอนการตัดสินใจหลายขั้นตอน:

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

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

3. เลือกแหล่งที่มาสำหรับการค้นหา
   ระบบไม่ทำการค้นหาแบบกว้างๆ ทุกแหล่งในครั้งเดียว แต่เลือกอย่างตรงเป้าหมาย:

   • เอกสารที่เก็บถาวรของเวอร์ชัน 2.x
   • เอกสารปัจจุบันของเวอร์ชัน 3.x

4. ค้นหาและประเมิน
   ระบบค้นหาเอกสารทั้งสองเวอร์ชัน และประเมินความสมบูรณ์ของข้อมูล:

   • เนื้อหาของเวอร์ชัน 2.x เพียงพอ
   • เนื้อหาของเวอร์ชัน 3.x ไม่สมบูรณ์ และอ้างอิงถึงคู่มืออีกฉบับหนึ่ง
     ดังนั้น ระบบตัดสินใจเริ่มการค้นหารอบที่สอง

5. ปรับปรุงการค้นหา
   สำหรับรายละเอียดการรับรองความถูกต้องของ v3.x ที่ขาดหายไป ระบบเริ่มการค้นหาแบบเจาะจง และค้นพบข้อมูลที่ต้องการสำเร็จ

6. ตรวจสอบและสร้าง
   เมื่อข้อมูลของทั้งสองเวอร์ชันเพียงพอแล้ว ระบบสร้างผลการเปรียบเทียบที่มีโครงสร้าง เช่น:

   • OAuth 2.0 และ API keys (มีทั้งสองเวอร์ชัน)
   • JWT (รองรับเฉพาะ v3.x)
   • อ้างอิงถึงส่วนเอกสารเฉพาะ

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

ประเภทของระบบ Agentic RAG 6 แบบ

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

1. Agentic RAG แบบมีเงื่อนไข (ขั้นตอนเดียว)

พฤติกรรม Agentic ที่ง่ายที่สุดคือการตัดสินใจว่าจะทำการค้นหาหรือไม่ ก่อนที่จะมีการค้นหาใดๆ โมเดลจะประเมินคำถามก่อน

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

จากการประเมินดังกล่าว ระบบอาจข้ามการค้นหาและสร้างคำตอบโดยตรง หรือค้นหาครั้งหนึ่งแล้วจึงสร้าง

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

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

ข้อดี:
* ในแอปพลิเคชันแบบผสม สามารถลดต้นทุนการค้นหาได้ 30–40% สำหรับคำถาม
* ตอบสนองต่อคำถามที่ไม่ต้องการการค้นหาได้เร็วขึ้น
* การนำไปใช้และดีบักค่อนข้างง่าย
* โดยทั่วไปสามารถลดต้นทุนได้อย่างมีนัยสำคัญ ในขณะที่รักษาความล่าช้ารวมไว้ใกล้เคียงกัน

ข้อเสีย:

Agentic RAG แบบวนซ้ำ/หลายขั้นตอน

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

วิธีการทำงาน:
1. ดำเนินการค้นหาแรกตามคำถามเริ่มต้นของผู้ใช้
2. โมเดลภาษาขนาดใหญ่ประเมินความเพียงพอและความเกี่ยวข้องของผลการค้นหา
3. หากการประเมินพบว่าข้อมูลไม่เพียงพอ ให้สร้างคำถามที่ปรับปรุงแล้ว และทำการค้นหาใหม่
4. ทำซ้ำกระบวนการนี้ จนกว่าจะถึงจำนวนการวนซ้ำสูงสุดที่กำหนด (ปกติ 2-3 ครั้ง)
5. สร้างคำตอบสุดท้ายจากข้อมูลบริบทที่สะสม

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

ข้อดี:
* ปรับปรุงคุณภาพการตอบคำถามที่ซับซ้อนหรือคลุมเครือได้อย่างมีนัยสำคัญ
* มีความสามารถในการกู้คืนจากการค้นหาแรกที่แย่

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

Agentic RAG แบบกำหนดเส้นทางเครื่องมือ

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

วิธีการทำงาน:
1. วิเคราะห์คำถามผู้ใช้ เพื่อทำความเข้าใจความต้องการข้อมูล
2. โมเดลภาษาขนาดใหญ่ตัดสินใจว่าแหล่ง

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง