Corrective RAG

---

Corrective RAG

Data Mastery Series — Episode 53: RAG ที่ “คิด” ก่อน “ตอบ” และ “แก้ไข” เมื่อผิดพลาด

📌 Connect with me and follow our journey: Linkedin, Facebook

Retrieval-Augmented Generation (RAG) ได้กลายเป็นมาตรฐานที่ได้รับการยอมรับอย่างกว้างขวางสำหรับการแก้ไขปัญหาความเกี่ยวข้องของข้อมูลในการเรียนรู้แบบ In-context ซึ่งเราได้พูดถึงไปแล้วใน 3 Episode:

• EP.50 — LangGraph Introduction: จาก LangChain → LangGraph
• EP.51 — Agentic RAG: เปลี่ยน RAG ให้ “คิด” ได้
• EP.52 — Adaptive RAG: ปรับ RAG ให้ “รู้จักประเมินสถานการณ์” ก่อนลงมือค้นข้อมูล

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

1. Corrective RAG คืออะไร?

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

• ✅ การประเมินคุณภาพเอกสาร (retrieval evaluator)
• 🔄 การเสริมข้อมูลเพิ่มเติมหากจำเป็น (web search / query rewrite)
• 🧠 การกลั่นกรองเนื้อหาให้เหลือเฉพาะ “สาระสำคัญ”

💡 พูดง่าย ๆ:

CRAG คือ RAG ที่ “คิดก่อนตอบ” และ “แก้ก่อนหลอน” เพื่อให้ได้คำตอบที่ถูกต้อง แม่นยำ และเชื่อถือได้

Corrective RAG ทำงานอย่างไร?

CRAG ประกอบด้วย 3 กลไกหลัก:

1. Retrieval Evaluator: ประเมินความเกี่ยวข้องและความน่าเชื่อถือของเอกสารที่ดึงมา โดยให้คะแนนความน่าเชื่อถือและจัดประเภทเอกสารเป็น “ถูกต้อง”, “ไม่ถูกต้อง” หรือ “คลุมเครือ”
2. Knowledge Retrieval Actions: ดำเนินการตามผลการประเมินของ Retrieval Evaluator:
   - Correct → กลั่นกรองด้วย decompose-then-recompose เพื่อใช้เฉพาะเนื้อหาที่สำคัญ
   - Incorrect → ค้นใหม่ผ่าน web search
   - Ambiguous → ปรับคำถามใหม่ (transform query) แล้วดึงข้อมูลเสริมจากหลายแหล่ง
3. Augmented Generation: ใช้ข้อมูลที่ผ่านการประเมินและปรับปรุงแล้ว เพื่อสร้างคำตอบที่ถูกต้อง แม่นยำ และน่าเชื่อถือ

ตัวอย่าง Use Case ที่น่าสนใจ

• 🧑‍⚖️ Legal & Compliance: ตรวจสอบว่าข้อมูลทางกฎหมายหรือข้อกำหนดที่อ้างถึง มีความเกี่ยวข้องกับคำถามและเป็นเวอร์ชันล่าสุดหรือไม่
• 🏥 Healthcare Assistant: เมื่อระบบต้องอ้างอิงแนวทางการรักษา (guideline) หรือข้อมูลผู้ป่วย — CRAG จะช่วยกรองข้อมูลที่ไม่เกี่ยวข้องออก เพื่อป้องกันการวินิจฉัยผิดพลาด
• 🧑‍💼 Enterprise Search & BI Assistant: คำถามเชิงธุรกิจที่ต้องการข้อมูลจากหลายระบบ — เช่น HR, Sales, หรือ CRM — CRAG ช่วยเลือกเฉพาะข้อมูลที่ตรงและน่าเชื่อถือ ก่อนนำไปสร้าง Insight

ข้อจำกัดของ Corrective RAG

แม้จะเพิ่มความแม่นยำได้ดี แต่ CRAG ก็มีความท้าทายที่ควรระวัง:

• ⚖️ ต้องพึ่ง retrieval evaluator ที่มีความแม่นยำสูง → ต้องเทรนหรือ prompt อย่างดี
• ⏱ เพิ่ม latency และ token usage → เพราะต้องประเมิน, กรอง, และบางครั้งต้องค้นใหม่
• ⚙️ โครงสร้างซับซ้อนกว่า RAG ปกติ ต้องออกแบบ workflow ให้รัดกุมและ robust

2. ประเด็นสำคัญๆ ของ Corrective RAG

หลังจากเข้าใจแนวคิดของ Corrective RAG ไปแล้ว ในส่วนนี้เราจะลงลึกถึงโครงสร้างการทำงานจริง โดยอ้างอิงจากตัวอย่างทางการของ LangChain’s official demo ซึ่งนำ LangGraph มาสร้าง Agent ที่มีความสามารถในการ:

• Retrieve ข้อมูลจาก vectorstore ตามคำถามของผู้ใช้
• ตรวจสอบความเกี่ยวข้องของเอกสาร (ผ่าน retrieval evaluator)
• ตัดสินใจเส้นทางถัดไป เช่น ใช้เอกสารเดิม, ปรับคำถามใหม่ + เสริมข้อมูลจาก web search
• สร้างคำตอบที่ผ่านการกลั่นกรองมาแล้วเท่านั้น

🧭 เราจะโฟกัสเฉพาะส่วนที่ เพิ่มเติม หรือ แตกต่าง จาก Basic LangGraph, Agentic RAG,และ Adaptive RAG ซึ่งได้อธิบายไว้ใน 3 ตอนก่อนหน้า

1️⃣ เข้าใจภาพรวมของ Corrective RAG Workflow

Figure: Corrective RAG Concept จาก LangGraph demo

จากภาพ Corrective RAG Concept นี้ เราจะเห็นว่า Workflow ถูกออกแบบให้มี “ขั้นตอนการสะท้อนกลับ (self-reflection)” เพื่อ ตรวจสอบและปรับปรุงข้อมูลที่ Retrieve มา ก่อนนำไปสร้างคำตอบ ซึ่งประกอบด้วย 5 ขั้นตอนหลัก:

🔄 การไหลของคำถาม (Question → Answer)

1. Retrieve (Node): ดึงเอกสารจาก knowledge base ตามคำถามของผู้ใช้
2. Grade (Node): ตรวจสอบความเกี่ยวข้องของแต่ละเอกสารที่ดึงมา
   → ถ้ามีเอกสารใด “ไม่เกี่ยวข้อง” กับคำถามเลย → ไปยังขั้นถัดไป
   → ถ้าทุกเอกสาร “เกี่ยวข้อง” → ไปสร้างคำตอบได้ทันที
3. ตัดสินใจ (Any doc irrelevant?):
   🔸 No: ใช้เอกสารที่ได้เพื่อ Generate คำตอบเลย
   🔹 Yes: เอกสารไม่เพียงพอ → ต้อง Re-write คำถามใหม่
4. Re-write query (Node): ปรับคำถามให้แม่นยำและชัดเจนขึ้น เพื่อเตรียมไปค้นใหม่
5. Web Search (Node): ค้นข้อมูลเพิ่มเติมจากอินเทอร์เน็ตเพื่อเสริมเนื้อหาที่ขาด
   → จากนั้นรวมเอกสารใหม่ทั้งหมดเพื่อไปสร้างคำตอบอีกครั้ง
6. Generate (Node): ใช้ข้อมูลที่ได้รับการ “กรอง” และ “เสริม” มาแล้ว เพื่อสร้างคำตอบสุดท้าย
   → ส่งคำตอบไปยังผู้ใช้

💡 Key Insight:

- RAG ปกติที่ใช้เอกสารที่ได้มาเลย
- CRAG จะ “ไม่รีบตอบ” ทันที แต่ “ตรวจสอบก่อน” ว่าเอกสารที่มี “ดีพอ” หรือไม่
หากไม่ดีพอ → ปรับคำถามใหม่ + ดึงข้อมูลใหม่ก่อนจึงค่อยตอบ

2️⃣ เปรียบเทียบ Workflow Graph ของทั้ง 3 กลยุทธ์ RAG

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

🧠 Agentic RAG

Figure: Agentic RAG Workflow Graph

ในโมเดลนี้ agent node ทำหน้าที่เป็นศูนย์กลางในการตัดสินใจ เช่น:

• หากพบว่าเอกสาร เกี่ยวข้อง → ส่งต่อไปยัง retrieve
• หากไม่มีเอกสารที่เกี่ยวข้อง → ให้ LLM สร้างคำตอบโดยตรง

อีกหนึ่งจุดสำคัญคือการใช้ grade_documents function เพื่อประเมินว่า context ที่ retrieve มานั้นเกี่ยวข้องกับคำถามหรือไม่:

• ถ้า เกี่ยวข้อง → ไปยัง generate
• ถ้า ไม่เกี่ยวข้อง → ส่งไป rewrite เพื่อปรับคำถาม และย้อนกลับเข้า agent loop ใหม่อีกครั้ง

🧭 Adaptive RAG

Figure: Adaptive RAG Workflow Graph

ใน Adaptive RAG การตัดสินใจมอบให้กับ route_question function ซึ่งจะพิจารณาว่า:

• ถ้า คำถามเกี่ยวข้องกับ vectorstore → ไปยัง retrieve
• ถ้า ไม่เกี่ยวข้อง → ทำ web_search

หลังจากนั้นจะใช้ grade_documents เพื่อประเมินความเกี่ยวข้องของเอกสาร:

• ถ้า เกี่ยวข้อง → ไปยัง generate
• ถ้า ไม่เกี่ยวข้อง → ไปที่ transform_query และวนกลับไป retrieve อีกครั้ง

และมี grade_generation_v_documents_and_question เพื่อตรวจสอบว่า:

• คำตอบ ตรงกับคำถาม และ อิงจากข้อมูลจริง (grounded) หรือไม่
• ถ้า ไม่ตรง (not useful) → ปรับคำถามใหม่
• ถ้า hallucinate (not supported) → วนกลับไป generate อีกรอบ

🔍 Corrective RAG (CRAG)

Figure: Corrective RAG Workflow Graph

จุดที่แตกต่างหลักของ CRAG คือการ เลื่อนการประเมิน (grading) มาไว้หลัง retrieve และให้ความสำคัญกับการกรองเอกสารอย่างรัดกุม:

• ถ้าเอกสารที่ retrieve เกี่ยวข้อง → ไปยัง generate
• ถ้าเอกสาร ไม่เกี่ยวข้อง หรือ น้อยเกินไป → ปรับคำถามด้วย transform_query, ทำ web_search เพื่อเสริมข้อมูล แล้วค่อย generate คำตอบ

โดยรวมแล้วฟังก์ชันหลักของ CRAG มีความคล้ายคลึงกับ Adaptive RAG แต่เน้นความสามารถในการ “สะท้อนผล” และ “แก้ไขตัวเอง” เมื่อ retrieval ล้มเหลว

🧪 ตัวอย่างการทำงานจริง

คำถามที่ 1: “What are the types of agent memory?”

• AI Route and Decisions:
  - RETRIEVE → ได้รับเอกสารจาก vectorstore
  - GRADE_DOCUMENTS → ประเมินว่าเอกสารเกี่ยวข้อง และไม่ต้องค้นเพิ่ม
  - GENERATE → LLM สร้างคำตอบจากเอกสารที่ได้
• คำตอบ:
  The types of agent memory are short-term memory and long-term memory. Short-term memory involves in-context learning, while long-term memory allows the agent to retain and recall information over extended periods, often using an external vector store for fast retrieval.
• Route: start → retrieve → grade_documents → generate → end

คำถามที่ 2: “Recommend food from Thailand 3 item”

• AI Route and Decisions:
  - RETRIEVE → ได้รับเอกสารจาก vectorstore
  - GRADE_DOCUMENTS → พบว่าเอกสารไม่เพียงพอ → Yes to web search
  - TRANSFORM_QUERY → ปรับคำถามเป็น: What are three popular Thai dishes you would recommend trying?
  - WEB_SEARCH → ดึงข้อมูลเพิ่มเติมจากอินเทอร์เน็ต
  - GENERATE → สร้างคำตอบจากข้อมูลผสม
• คำตอบ:
  I recommend trying Pad Thai, Massaman Curry, and Tom Yum. These dishes are popular and showcase the diverse flavors of Thai cuisine. Each offers a unique taste experience, from the stir-fried noodles of Pad Thai to the rich curry of Massaman and the spicy-sour soup of Tom Yum.
• Route: start → retrieve → grade_documents → transform_query → web_search → generate → end

3️⃣ การเปรียบเทียบ Vanilla RAG, Agentic RAG, Adaptive RAG, and Corrective RAG

Corrective RAG (CRAG) คือก้าวต่อไปของ RAG ที่ไม่เพียงแค่ “ดึงแล้วตอบ” แต่ “ตรวจ–กรอง–เสริม” ก่อนจะสร้างคำตอบ ช่วยลดความผิดพลาดและเพิ่มความน่าเชื่อถือ เหมาะกับระบบที่ต้องการความแม่นยำสูง

ใน Episode ถัดไป เราจะไปไกลกว่านั้น — รู้จักกับ Self-RAF (Self-Reflective Answer Fixing) กลไกที่ให้ LLM ตรวจสอบคำตอบของตัวเอง และ แก้ไขถ้าผิด เพื่อให้ทุกคำตอบ “ถูกต้อง และมั่นใจได้” กว่าที่เคย

---

Data Science Explore the world of data science with Donato_Story

Dashboard Discover the power of data visualization with Donato_Story

Donato_Journey Join me on my journey (Thai version)

Course_Review Discover the training courses with Donato_Story (Thai version)

Let’s Connect!

Your thoughts and feedback are invaluable. Feel free to share them in the comments or connect with me on

• 🌐 Medium: medium.com/donato-story
• 📘Facebook: web.facebook.com/DonatoStory
• 💼 Linkedin: linkedin.com/in/nattapong-thanngam