---

Adaptive RAG

Data Mastery Series — Episode 52: ปรับ RAG ให้ “รู้จักประเมินสถานการณ์” ก่อนลงมือค้นข้อมูล

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

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

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

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

Adaptive RAG คือการปรับระบบ Retrieval-Augmented Generation (RAG) ให้ “แปรผันตามความยากของคำถาม” โดยใช้ Query Classifier วิเคราะห์ก่อนว่า คำถามนั้นควร:

• ตอบทันที (No Retrieval)
• ดึงข้อมูลรอบเดียว (Single-step RAG)
• หรือ ต้องค้นหลายรอบ (Multi-step RAG)

💡 พูดง่าย ๆ:

RAG ที่ “รู้จักประเมินสถานการณ์” ก่อนลงมือค้นข้อมูล — เพื่อประหยัดเวลา ลดต้นทุน และเพิ่มความแม่นยำ

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

มีองค์ประกอบหลัก 3 ส่วนที่ทำให้มัน “ฉลาด” และ “ปรับตัว” ได้:

• Query Complexity Analysis: ระบบจะใช้ Classifier (เช่น LLM ขนาดเล็ก หรือโมเดล Machine Learning อื่นๆ) เพื่อประเมินความซับซ้อนของคำถามและจัดประเภทคำถามว่าเป็นแบบง่าย, ปานกลาง, หรือซับซ้อน
• Adaptive Retrieval Strategy Selection:
  - No Retrieval: สำหรับคำถามที่ LLM มีความรู้ภายในเพียงพอ และสามารถตอบได้โดยไม่ต้องดึงข้อมูล
  - Single-Step Retrieval: สำหรับคำถามที่ต้องการข้อมูลจากแหล่งภายนอกเพียงครั้งเดียว เช่น การค้นหาเอกสารที่เกี่ยวข้อง
  - Multi-Step Retrieval (Iterative RAG): สำหรับคำถามที่ซับซ้อนและต้องการการดึงข้อมูลหลายครั้ง, การวิเคราะห์ข้อมูลที่ได้, และการปรับปรุงคำค้นเพื่อดึงข้อมูลเพิ่มเติม
• Augmented Generation: LLM จะใช้ข้อมูลที่ดึงมา (ถ้ามี) ร่วมกับความรู้ภายในเพื่อสร้างคำตอบสุดท้าย

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

• Chatbot ทั่วไป: ตอบคำถามง่าย ๆ เช่น “เมืองหลวงของฝรั่งเศสคืออะไร?” โดยไม่ต้องเสียเวลาเรียก vector DB
• Business Intelligence Assistant: ถ้าเจอคำถามว่า “ใครเป็น CEO ของบริษัท A ตอนที่ iPhone เปิดตัวครั้งแรก?” ระบบจะวางแผน multi-hop retrieval (กระบวนการค้นหาข้อมูลหลายขั้น เพื่อหาคำตอบที่ซับซ้อนซึ่งไม่สามารถตอบได้จากแหล่งเดียวในรอบเดียว) อย่างอัตโนมัติ
• Enterprise Assistant: เลือกว่าจะค้นจากฐานข้อมูลภายใน หรือทำ web search จากภายนอก ขึ้นอยู่กับเนื้อหาของคำถาม

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

Adaptive RAG มีข้อดีเรื่อง efficiency และ accuracy — แต่ก็มีความท้าทาย เช่น:

• ⚙️ ต้องเทรน Query Classifier ให้แม่น
• 📈 ต้องออกแบบ logic ให้สามารถ fallback / loop back ได้
• 🧠 ต้องประเมินคุณภาพคำตอบ และวางแผนย้อนกลับแบบอัตโนมัติ

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

หลังจากเข้าใจแนวคิด Adaptive RAG ไปแล้ว ในส่วนนี้เราจะลงลึกถึงโครงสร้างการทำงานจริง โดยอ้างอิงจากตัวอย่างทางการของ LangChain’s official demo ซึ่งแสดงให้เห็นภาพชัดเจนว่าการ “วิเคราะห์คำถามก่อนเลือกวิธีตอบ” สามารถนำมาปรับใช้ใน Workflow ได้อย่างไร

ในตัวอย่างนี้ เราจะใช้ LangGraph สร้าง Agent ที่สามารถ:

• วิเคราะห์คำถามเพื่อเลือกเส้นทางที่เหมาะสม (web search หรือ vector DB)
• ตรวจสอบคุณภาพของเอกสารที่ดึงมา
• ตัดสินใจแบบมีเงื่อนไขว่าจะตอบเลย แก้คำถาม หรือวนกลับไปค้นใหม่
• ประเมินคำตอบว่าตรงคำถามหรือไม่ และมี hallucination หรือเปล่า

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

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

Figure: Adaptive RAG Concept จาก LangChain’s official demo

จากภาพ Adaptive RAG Concept ของ LangChain จะเห็นได้ชัดว่า Workflow นี้แบ่งออกเป็น 2 ส่วนหลัก:

• Query Analysis (ด้านซ้าย): เป็น Node ที่วิเคราะห์คำถามและตัดสินใจว่า:
  - ถ้าเกี่ยวข้องกับข้อมูลใน vectorstore → วิ่งเข้ากระบวนการ RAG
  - ถ้าไม่เกี่ยวข้อง → ไปทำ web search แทน
• RAG + Self-Reflection (ด้านขวา): ภายในกรอบนี้จะมีการ:
  - ตรวจสอบความเกี่ยวข้องของเอกสารที่ Retrieve มา
  - วนกลับไปแก้คำถาม (Transform) หากเอกสารไม่เกี่ยวข้อง
  - ตรวจสอบว่าคำตอบสุดท้าย “มี Hallucination หรือไม่” และ “ตอบตรงคำถามหรือเปล่า”
  - ตัดสินใจว่าสามารถส่งคำตอบได้เลย หรือจะวนไปปรับคำถามและค้นใหม่อีกครั้ง

2️⃣ อธิบาย Workflow Graph และ Function ที่เกี่ยวข้อง

ในโค้ด LangGraph จะมี Node หลัก ๆ ที่สร้างผ่าน workflow.add_node(...) พร้อมกับ Conditional Routing ผ่าน add_conditional_edges(...) ดังนี้:

• route_question(state) : วิเคราะห์คำถาม → เลือกเส้นทาง
• web_search(state): ค้นข้อมูลจากอินเทอร์เน็ต
• retrieve(state): ดึงข้อมูลจาก vectorstore
• grade_documents(state): ตรวจสอบความเกี่ยวข้องของเอกสาร
• decide_to_generate(state): ตัดสินใจว่า generate หรือ transform query
• generate(state): สร้างคำตอบสุดท้าย
• transform_query(state): ปรับคำถามใหม่ให้แม่นยำขึ้น
• grade_generation_v_documents_and_question(state): ตรวจสอบคำตอบว่าตรงคำถามและมี hallucination หรือไม่

Figure: Graph ของ Adaptive RAG

3️⃣ อธิบาย Adaptive RAG ในมุม Workflow

Figure: แปลง Diagram ให้ง่ายต่อการเข้าใจ และ Map code เข้าไปดูว่าอยู่ส่วนไหน

จากภาพ workflow ข้างต้น ระบบจะเริ่มต้นจาก __start__ และวิเคราะห์คำถามด้วย Node route_question เพื่อเลือกเส้นทางที่เหมาะสมที่สุด — จะเป็น Web Search หรือการ Retrieve จาก Vectorstore ภายใน

🟢 กรณีเลือก Web Search:

• ระบบจะดึงข้อมูลจากภายนอกอินเทอร์เน็ต
• ส่งข้อมูลไปยัง Node generate เพื่อให้ LLM สร้างคำตอบ
• ถ้าคำตอบใช้ได้ (useful) → จบที่ __end__
• หากไม่ผ่านเงื่อนไข → วนกลับมาตรวจสอบหรือปรับคำถามใหม่

🔵 กรณีเลือก Vectorstore:

• ไปยัง Node retrieve เพื่อค้นเอกสาร
• ส่งต่อไปยัง grade_documents เพื่อตรวจสอบว่าเกี่ยวข้องหรือไม่
• ถ้าไม่มีเอกสารที่เกี่ยวข้อง → ปรับคำถามใหม่ผ่าน transform_query และวนกลับไป retrieve
• ถ้าเอกสารเกี่ยวข้อง → ส่งต่อไปยัง generate เพื่อสร้างคำตอบ
• จากนั้นใช้ Node ตรวจสอบ (grading) เพื่อพิจารณาว่าคำตอบ:
  - มีคุณภาพและ grounded หรือไม่ (useful)
  - ไม่ตรงคำถาม (not useful) → วนไป transform_query - หรือ hallucinate (not supported) → วนกลับมา generate อีกครั้ง

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

คำถามที่ 1: “What player at the Bears expected to draft first in the 2024 NFL draft?”

• ระบบเลือกใช้ Web Search → พบข้อมูล Caleb Williams
• LLM สร้างคำตอบ grounded และตรงคำถาม
• คำตอบ: Caleb Williams
• Route: start → web_search → generate → end

Figure: Question 1 _ What player at the Bears expected to draft first in the 2024 NFL draft?

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

• ระบบเลือกใช้ Vectorstore → Retrieve แล้ว Grade เอกสาร
• LLM อธิบายประเภท memory ของ agent ได้อย่างแม่นยำ
• คำตอบ: Short-term & Long-term Memory
• Route: start → retrieve → grade_documents → generate → end

Figure: Question 2 _ What are the types of agent memory?

4️⃣ ทำความเข้าใจสัญลักษณ์ใน Graph Diagram

• 🟪 กล่องสีม่วง (Node): คือ function ที่เราสร้างขึ้นและเพิ่มเข้าไปใน Workflow ด้วย add_node(...) เช่น generate, web_search

ตัวอย่างกล่องสีม่วง

workflow.add_node("web_search", web_search)
workflow.add_node("generate", generate)

• 🩶 กล่องสีเทา (Text Highlight): ไม่ใช่ Node แต่คือ ค่าผลลัพธ์ที่ return จากฟังก์ชัน routing/decision → add_conditional_edges(..., {label: node})

ตัวอย่างกล่องสีเทา

workflow.add_conditional_edges(START, route_question, {
"web_search": "web_search", #เนื่องจาก start --> web_search นั้นมี node อยู่แล้ว จึงไม่มี Text สีเทาขึ้นมา
"vectorstore": "retrieve", #เนื่องจาก start --> vectorstore นั้นไม่มี node อยู่ จึงทำการสร้าง Text สีเทาขึ้นมา
})

• อธิบายโครงสร้างของ add_conditional_edges()

ตัวอย่าง Code

workflow.add_conditional_edges("generate", grade_generation_v_documents_and_question, {
"not supported": "generate",
"useful": END,
"not useful": "transform_query"
})

ความหมาย

workflow.add_conditional_edges("จากไหน", ฟังก์ชันตัดสินใจ, {
"ผลลัพธ์ที่ 1": "ไปที่ไหน" หรือ END,
"ผลลัพธ์ที่ 2": "ไปที่ไหน" หรือ END,
"ผลลัพธ์ที่ 3": "ไปที่ไหน" หรือ END,
})

• เส้นทึบ: deterministic edge — เดินจาก Node A → B แน่นอน
• เส้นประ: หมายถึง conditional edge — ต้องมีการประเมินค่าจากฟังก์ชันก่อนจึงจะเลือกทิศทาง

5️⃣ จุดเด่นของ Adaptive RAG Router Node

Router นี้ถูกออกแบบด้วยแนวคิด structured output ซึ่ง LLM จะต้องตอบกลับในรูปแบบที่เรากำหนดไว้อย่างชัดเจน ผ่าน Pydantic BaseModel (class พื้นฐานจาก library [Pydantic] ที่ใช้สำหรับ: กำหนด schema ของข้อมูล และ ตรวจสอบ type และ validate input/output ซึ่งสามารถใช้ร่วมกับ LLM structured output เพื่อให้ LLM ตอบตาม format ที่เรากำหนดได้เป๊ะ) เช่นตัวอย่างด้านล่าง:

ROUTER (LLM จะต้องตอบกลับในรูปแบบที่เรากำหนดไว้อย่างชัดเจน ผ่าน Pydantic BaseModel)

class RouteQuery(BaseModel):
"""Route a user query to the most relevant datasource."""
datasource: Literal["vectorstore", "web_search"] = Field(
...,
description="Given a user question choose to route it to web search or a vectorstore.",
)

จากนั้นเรานำ schema นี้ไปใช้ร่วมกับ LLM ผ่าน with_structured_output:

จากนั้นเรานำ schema นี้ไปใช้ร่วมกับ LLM ผ่าน with_structured_output

structured_llm_router = llm.with_structured_output(RouteQuery)

และผูกกับ system prompt เพื่อให้ LLM ตัดสินใจ:

และผูกกับ system prompt เพื่อให้ LLM ตัดสินใจ:

system = """You are an expert at routing a user question to a vectorstore or web search.
The vectorstore contains documents related to agents, prompt engineering, and adversarial attacks.
Use the vectorstore for questions on these topics. Otherwise, use web-search."""
route_prompt = ChatPromptTemplate.from_messages(
[
("system", system),
("human", "{question}"),
]
)

ประกอบเป็น Router chain:

ประกอบเป็น Router chain:

question_router = route_prompt | structured_llm_router

แล้วนำมาใช้ใน workflow ดังนี้:

แล้วนำมาใช้ใน workflow ดังนี้:

def route_question(state):
question = state["question"]
source = question_router.invoke({"question": question})
if source.datasource == "web_search":
return "web_search"
elif source.datasource == "vectorstore":
return "vectorstore"

🧠 ทำไมถึงต้องใช้ Structured Output?

การเขียน class BaseModel แยกต่างหากช่วยให้เราควบคุมรูปแบบคำตอบจาก LLM ได้อย่างแม่นยำ เช่น การตอบ “web_search” หรือ “vectorstore” เท่านั้น ไม่หลุดนอก scope (กำหนด structured output ของ LLM ได้ดี)
เหมาะอย่างยิ่งสำหรับงานที่ต้องการ การตัดสินใจแบบชัดเจน (decision) เช่น:

• Routing
• Validation
• Grading (Yes/No)
• Triggering function calls

หากเป็นแค่การ generate คำตอบทั่วไป หรือใช้ retriever → ไม่จำเป็นต้องใช้ BaseModel

6️⃣ การเปรียบเทียบ Vanilla RAG vs Agentic RAG vs Adaptive RAG

1. 🔁 Vanilla RAG: Simple Retrieval, Direct Generation

• แนวคิด: ดึงข้อมูลจาก vectorstore และให้ LLM ตอบคำถามจาก context
• โครงสร้าง: ตรงไปตรงมา ไม่มี branching หรือ decision logic
• ลักษณะการทำงาน:
  User → Retrieve → Generate
• จุดเด่น:
  - ทำงานเร็ว
  - โค้ดเรียบง่าย
  - เหมาะกับคำถามที่อิงเอกสารตรง ๆ
• ข้อจำกัด:
  - ขาดกลไกตัดสินใจหรือ fallback
  - หาก retrieve ไม่แม่น → LLM อาจ hallucinate
• เหมาะสำหรับ:
  - งานที่ใช้เอกสารเฉพาะทาง
  - Q&A ที่ไม่ซับซ้อน

2. 🧠 Agentic RAG: Reasoning-Driven Retrieval

• แนวคิด: เพิ่ม “ความสามารถในการตัดสินใจ” ให้กับระบบ RAG ผ่านการใส่ agent behavior เช่น การ loop, การประเมินคำตอบ หรือการเรียกเครื่องมือเสริม
• โครงสร้าง: มีหลาย state, รองรับการ branching และ feedback loop
• State Management:
  ใช้ AgentState ที่เก็บทั้งข้อความสนทนา (messages), tool calls และ memory

class AgentState(TypedDict):
messages: Annotated[Sequence[BaseMessage], add_messages]

• ลักษณะการทำงาน:
  User → Router → Tool/Retrieve → Generate → Evaluate → Improve
• จุดเด่น:
  - ยืดหยุ่นสูง
  - รองรับ workflow ที่ซับซ้อน
• ข้อจำกัด:
  - โครงสร้างซับซ้อน
  - มี latency เพิ่มขึ้น
  ต้องออกแบบ logic อย่างรอบคอบ
• เหมาะสำหรับ:
  - Agent ที่ต้องใช้ reasoning และการวางแผนหลายขั้นตอน

3. 🔀 Adaptive RAG: Smart Strategy for Every Question

• แนวคิด: ปรับวิธีการดึงข้อมูลให้เหมาะสมกับประเภทของคำถาม โดยเลือกว่าจะใช้ vectorstore, web search หรือไม่ retrieve เลย
• โครงสร้าง: ใช้ conditional routing และ state ที่เบาและตรงไปตรงมา
• State Management:
  - มี state แน่นอน เบา และตรงไปตรงมา)
  - ใช้ GraphState (TypedDict) ที่เก็บ question, documents, generation
  - ไม่มี message history → โฟกัสที่ข้อมูลและการตัดสินใจเชิงกลยุทธ์

class GraphState(TypedDict):
question: str
generation: str
documents: List[str]

• ลักษณะการทำงาน:
  User → Route → Retrieve (if needed) → Grade → Generate → Evaluate
• จุดเด่น:
  - ประหยัดทรัพยากรโดยไม่ต้อง retrieve ทุกคำถาม
  - ปรับแผนตามสถานการณ์แบบเรียลไทม์
• ข้อจำกัด:
  - ต้องเทรน query classifier หรือ prompt ให้แม่น
  - โค้ดและ logic เริ่มมีความซับซ้อน
• เหมาะสำหรับ:
  - ระบบที่ต้องรับมือกับคำถามหลากหลายประเภท และไม่แน่นอนล่วงหน้า

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

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

---

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