Module 10 Expert

RAG Production 2026

Retrieval-Augmented Generation — จาก Naive RAG สู่ Agentic RAG

🎯 วัตถุประสงค์การเรียนรู้ Module 10

อธิบาย RAG 7 ประเภทและเลือกให้เหมาะกับงานได้
ออกแบบ pipeline ครบ 4 ชั้น: Ingestion, Retrieval, Generation, Evaluation
เขียน RAG Answer Contract ที่มี chunk scoring, conflict detection และ fallback
ใช้ RAGAS metrics วัดคุณภาพ RAG system ด้วย threshold ที่เป็น standard
เลือกเทคนิค Hybrid Search ตาม quantified improvement (Reranking/Contextual/Query Routing)

10.1 RAG คืออะไร?

RAG = ระบบที่ "ค้นหาข้อมูลที่เกี่ยวข้อง" ก่อน แล้วส่งให้ AI ใช้ตอบ — ลด Hallucination, ใช้ข้อมูลองค์กรจริง, อัปเดตได้โดยไม่ต้อง retrain

💡 เข้าใจง่ายๆ ด้วยตัวอย่าง

AI ปกติ: ถามว่า "นโยบายลาพักร้อนบริษัทเราเป็นอย่างไร?" → AI ตอบจากความรู้ทั่วไป (อาจผิด)

AI + RAG: ถามคำถามเดียวกัน → ระบบค้นหาคู่มือพนักงานบริษัท → ส่งข้อมูลที่เกี่ยวข้องให้ AI → AI ตอบจากเอกสารจริง พร้อมอ้างอิงหน้าที่มา

ประโยชน์: ไม่ต้อง train AI ใหม่ทุกครั้งที่นโยบายเปลี่ยน แค่อัปเดตเอกสารก็พอ

10.2 RAG Types 2026

ประเภท	คำอธิบาย	เหมาะกับ
Naive RAG	Embed → Search → Generate	Prototype, ข้อมูลน้อย
Advanced RAG	+ Query rewriting + Reranking + Hybrid search	Production ทั่วไป
Modular RAG	แยก components ปรับแต่งได้	Enterprise customization
Agentic RAG	AI ตัดสินใจเองว่าจะค้นอะไร/เมื่อไหร่	งานซับซ้อน multi-hop
GraphRAG	ใช้ Knowledge Graph + entities	งานเชื่อมโยงข้อมูล, สืบสวน
Self-RAG	AI ประเมินตัวเองว่าต้องค้นเพิ่มไหม	งานที่ต้องการ accuracy สูง
CRAG	Corrective RAG — แก้ไขถ้าค้นผิด	ลด hallucination ในข้อมูลซับซ้อน

10.3 RAG Architecture

🏗️ RAG Pipeline ครบ 4 ชั้น

1. Ingestion

ทำความสะอาดเอกสาร, split เป็น chunks ขนาดเหมาะ, ใส่ metadata (หน้า, วันที่, แหล่งที่มา) ก่อน embed

2. Retrieval

ค้นแบบ hybrid (keyword + vector), re-rank ผลลัพธ์, คืน chunks พร้อม retrieval score

3. Generation

บังคับ AI cite แหล่งข้อมูล, fallback เมื่อ score ต่ำ, ชี้ conflict เมื่อเอกสารขัดแย้งกัน

4. Evaluation

วัด Faithfulness, Answer Relevancy, Context Precision/Recall, latency อย่างต่อเนื่อง

⚠️ Production Rule

ถ้า retrieval score ต่ำกว่า threshold ที่กำหนด — AI ต้องตอบ "ข้อมูลไม่เพียงพอ" แทนการเดาหรือใช้ความรู้ทั่วไป → กำหนด threshold ใน System Prompt เสมอ

┌──────────┐    ┌───────────┐    ┌─────────────┐    ┌──────────┐
│  Query   │───▶│  Retrieve │───▶│  Augment    │───▶│ Generate │
│  (คำถาม) │    │  (ค้นหา)  │    │  (เสริม)    │    │ (ตอบ)    │
└──────────┘    └───────────┘    └─────────────┘    └──────────┘
                      │
               ┌──────┴──────┐
               │  Knowledge  │
               │    Base     │
               │  ┌───────┐  │
               │  │Vector │  │
               │  │  DB   │  │
               │  └───────┘  │
               └─────────────┘

Advanced RAG เพิ่ม:
- Query Rewriting (ปรับคำถามให้ค้นได้ดีขึ้น)
- Hybrid Search (Semantic + Keyword)
- Reranking (จัดอันดับผลลัพธ์ใหม่)
- Contextual Compression (บีบอัดข้อมูลที่ค้นได้)

10.4 GraphRAG — สำหรับงานสืบสวน

🔍 ทำไม GraphRAG เหมาะกับงานตำรวจ

GraphRAG สร้าง Knowledge Graph จากเอกสาร จับ entities (คน, สถานที่, องค์กร) และ relationships → ตอบคำถามที่ต้อง เชื่อมโยงข้อมูลหลายแหล่ง ได้ดีกว่า vector search ธรรมดา

💡 เข้าใจง่ายๆ:

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

ตัวอย่าง: GraphRAG สำหรับเครือข่ายอาชญากรรม

Entities: 
  - Person: นาย A, นาย B, นาย C
  - Organization: บริษัท X, บริษัท Y
  - Account: บัญชี 001, 002, 003
  - Location: กรุงเทพ, เชียงใหม่, กัมพูชา

Relationships:
  - นาย A → owns → บริษัท X
  - นาย A → transfers_to → นาย B (50 ครั้ง/เดือน)
  - บริษัท X → registered_at → กัมพูชา
  - นาย B → owns → บัญชี 002, 003
  - บัญชี 002 → receives_from → บัญชี 001 (หลายล้านบาท)

Query: "ใครอยู่เบื้องหลังเครือข่ายนี้ และเงินไหลอย่างไร?"
→ GraphRAG ตอบได้โดยเชื่อมโยง relationships ทั้งหมด

10.5 Hybrid Search — เทคนิคเพิ่มประสิทธิภาพ RAG

📊 ผลลัพธ์ที่วัดได้จากแต่ละเทคนิค (อ้างอิงตัวเลขจาก Anthropic — Contextual Retrieval และงานที่เกี่ยวข้อง)

เทคนิค	ผลที่วัดได้	วิธีทำ	ลำดับความสำคัญ
Cross-Encoder Reranking	+15–30% quality	ใช้ cross-encoder model จัดอันดับ retrieved chunks ใหม่ก่อนส่งให้ AI	ทำก่อน — ROI สูงสุด
Contextual Retrieval	-49% failed retrieval	Prepend 50-100 token context ให้แต่ละ chunk ก่อน embed	ทำใน Ingestion stage
Hybrid Search (BM25 + Vector)	+10–30% recall	ผสม keyword search + semantic search, merge ด้วย RRF	เหมาะคำถามที่มีคำเฉพาะ
Query Routing	-20–40% cost	AI ตัดสินใจว่าต้อง retrieve จริงหรือตอบได้เลย	ลดค่าใช้จ่ายระยะยาว

💡 ลำดับ Implementation

เริ่มจาก Reranking ก่อน — ROI สูงที่สุดและ implement ง่ายที่สุด → ต่อด้วย Contextual Retrieval → แล้วค่อย Hybrid Search เมื่อต้องการ precision เพิ่ม

10.6 Prompting สำหรับ RAG

📋 RAG Answer Contract (Template)

# RAG Answer Contract
# Domain: [ชื่อ domain]

คุณเป็นผู้ช่วย RAG สำหรับ [Domain]

คำถามผู้ใช้: {user_query}

เอกสารที่ดึงมา:
[Chunk A | source: ชื่อเอกสาร หน้า X | score: 0.XX]
{content_a}

[Chunk B | source: ชื่อเอกสาร หน้า X | score: 0.XX]
{content_b}

[Chunk C | source: ชื่อเอกสาร หน้า X | score: 0.XX]
{content_c}

กติกา:
1) ตอบเฉพาะสิ่งที่มีใน chunks — ห้ามใช้ความรู้ทั่วไป
2) ทุกข้อสรุปต้องอ้าง [Chunk ID] และ score
3) ถ้า chunks ขัดแย้งกัน → ชี้จุดขัดแย้งและระบุ chunk ที่น่าเชื่อถือกว่า
   (score สูงกว่า / วันที่ใหม่กว่า)
4) ถ้า score ต่ำกว่า {threshold} → ตอบ "ข้อมูลไม่เพียงพอ
   โปรดระบุคำถามเพิ่มเติม"
5) ห้ามแต่งเรื่อง สมมติ หรือเดาข้อมูลที่ไม่มีใน chunks

รูปแบบผลลัพธ์:
- คำตอบสั้น (ไม่เกิน 150 คำ)
- หลักฐานอ้างอิง: ตาราง [ข้อสรุป | Chunk ID | Score]
- ระดับความเชื่อมั่นรวม (สูง/กลาง/ต่ำ) + เหตุผล
- คำถามต่อยอดที่ควรถาม (1-2 ข้อ)

💡 RAG Answer Contract vs System Prompt ธรรมดา

ความต่าง: RAG Answer Contract บังคับให้ AI แสดง chunk ID และ score ทุกครั้ง — ทำให้ตรวจสอบ hallucination ได้ง่ายมาก

ตัวอย่าง: RAG สำหรับฐานข้อมูลกฎหมาย (งานตำรวจ)

คุณเป็นผู้ช่วย RAG สำหรับฐานระเบียบ สตช.

คำถาม: "การขอหมายจับผู้ต้องหาคดีออนไลน์ต้องมีหลักฐานอะไรบ้าง?"

[Chunk A | source: ระเบียบ ตร. ว่าด้วยการสอบสวน 2566 หมวด 4 ข้อ 23 | score: 0.92]
"การขอหมายจับต้องมีพยานหลักฐานเพียงพอที่จะเชื่อได้ว่าผู้ต้องหากระทำผิด..."

[Chunk B | source: คู่มือปฏิบัติ บก.ปอท. 2567 บทที่ 5 | score: 0.88]
"หลักฐานดิจิทัลที่ใช้ประกอบคำร้อง: IP log, transaction record, device fingerprint..."

[Chunk C | source: ระเบียบ ตร. ฉบับเก่า 2561 หมวด 3 | score: 0.61]
"ต้องมีพยานบุคคลอย่างน้อย 2 ปาก..." (⚠️ score ต่ำ + เวอร์ชันเก่า)

กติกา: (เหมือน template ด้านบน threshold = 0.75)

รูปแบบผลลัพธ์:
- คำตอบสั้น: [สรุปจาก Chunk A + B]
- หลักฐานอ้างอิง: ตาราง [ข้อสรุป | Chunk | Score]
- หมายเหตุ: Chunk C score ต่ำ (0.61) และเป็นระเบียบเก่า 2561
  — แนะนำ verify กับ Chunk A ที่ใหม่กว่า
- คำถามต่อยอด: "ต้องการทราบขั้นตอนการยื่นคำร้องต่อศาล
  หลังรวบรวมหลักฐานแล้วหรือไม่?"

💡 สังเกต Score Threshold

Chunk C score 0.61 < threshold 0.75 — RAG ต้องแจ้งว่าข้อมูลนี้ความเชื่อมั่นต่ำและเป็นเวอร์ชันเก่า ไม่ใช่ตอบโดยไม่เตือน

10.7 RAGAS — วัดคุณภาพ RAG อย่างเป็นระบบ

🎯 RAGAS Production Targets

Metric	ความหมาย	เป้าหมาย	ถ้าต่ำกว่า → แก้ที่ไหน
Faithfulness	AI ตอบตาม context จริงไม่เดา	> 0.90	แก้ Generation prompt — เพิ่ม constraint + citation
Answer Relevancy	คำตอบตรงกับคำถาม	> 0.85	แก้ Retrieval — ปรับ query rewriting หรือ embedding model
Context Precision	chunks ที่ดึงมาเกี่ยวข้องจริง	> 0.80	แก้ Retrieval — ลด top-k, เพิ่ม reranking
Context Recall	ดึง chunks ครบหรือไม่	> 0.80	แก้ Ingestion — chunk size, metadata, embedding

⚠️ Production Rule

RAG systems จำนวนมากล้มเหลวเพราะทำ Naive RAG โดยไม่ eval (ตัวเลข "70%+" ที่อ้างถึงในอุตสาหกรรมเป็นค่าประมาณการ) — กำหนด RAGAS baseline ก่อน deploy เสมอ

📌 วิธีทดสอบง่ายๆ

ถาม AI ตรงๆ ว่า: "คำตอบนี้มาจาก context ส่วนไหน? cite chunk ให้ด้วย" — ถ้า AI ทำไม่ได้ แสดงว่า System Prompt ยังไม่ strict พอ

10.8 ข้อผิดพลาดที่พบบ่อย

❌ ข้อผิดพลาดที่พบบ่อยใน RAG Production

#	❌ ข้อผิดพลาด	✅ วิธีที่ถูกต้อง
1	ทำ Naive RAG (embed → search → generate) โดยไม่ eval → production fail	ทำ Advanced RAG: Query rewriting + Reranking + Hybrid search + RAGAS eval
2	ไม่มี RAG Answer Contract → AI แต่งเรื่อง ไม่อ้างอิง chunk	บังคับให้อ้างอิง chunk ID + score ทุกครั้ง พร้อม fallback rule
3	ไม่ระบุ score threshold → AI ตอบจาก chunk ที่ไม่เกี่ยวข้อง	กำหนด threshold (เช่น 0.75) และบังคับว่า score ต่ำกว่า → "ข้อมูลไม่เพียงพอ"
4	Chunk size ใหญ่เกินไป (2000+ tokens) → ข้อมูลไม่ relevant	Chunk size 300-500 tokens พร้อม 50-100 tokens overlap + prepend context
5	ไม่มี metadata ใน chunks → ไม่รู้ว่ามาจากไหน วันไหน	ใส่ metadata: source, page, date, author ก่อน embed
6	Faithfulness สูง แต่ Answer Relevancy ต่ำ → ปัญหาอยู่ที่ Retrieval	แก้ที่ Retrieval: ปรับ query rewriting, embedding model, เพิ่ม reranking
7	Deploy โดยไม่กำหนด RAGAS baseline → ไม่รู้ว่าเสื่อมลงหรือไม่	กำหนด targets ก่อน deploy: Faithfulness > 0.90, Answer Relevancy > 0.85, Precision/Recall > 0.80

10.9 Key Takeaways

📝 Key Takeaways Module 10

RAG = ค้นหาข้อมูลก่อน → ส่งให้ AI → ตอบจากข้อมูลจริง
Naive RAG ไม่เพียงพอใน 2026 — ต้อง Advanced/Agentic RAG
GraphRAG เหมาะกับงานที่ต้องเชื่อมโยงข้อมูล (สืบสวน, วิจัย)
Hybrid Search (Semantic + Keyword) ให้ผลดีกว่า semantic อย่างเดียว
System Prompt ต้องบังคับให้ AI ตอบจาก context เท่านั้น + อ้างอิง
RAG systems จำนวนมากล้มเหลวเพราะ "ทำแบบ naive" (ประมาณการอุตสาหกรรม ~70%+) → ต้อง evaluate อย่างจริงจัง
RAG pipeline ครบ 4 ชั้น: Ingestion (clean/chunk) → Retrieval (hybrid+rerank) → Generation (cite+fallback) → Evaluation (RAGAS)
RAGAS targets: Faithfulness > 0.90 · Answer Relevancy > 0.85 · Context Precision/Recall > 0.80
หลีกเลี่ยงข้อผิดพลาด 7 ข้อ: ทำ Advanced RAG, Answer Contract, threshold ชัด, chunk size เหมาะ, metadata ครบ, แก้ stage ที่ถูก, กำหนด RAGAS baseline

✅ หลังเรียน Module 10 — สิ่งที่ควรทำได้

เลือก RAG type ที่เหมาะ (Naive/Advanced/GraphRAG/Agentic) ตาม use case ได้
เขียน RAG Answer Contract ที่มี chunk ID, scoring, conflict detection และ fallback rule
ระบุ RAGAS target สำหรับ production system และรู้ว่าถ้า metric ต่ำต้องแก้ที่ stage ไหน
ใช้ GraphRAG สำหรับงานที่ต้องเชื่อมโยง entities (สืบสวน, วิจัย)

🤔 คำถามทบทวน

โจทย์: ระบบ RAG มี faithfulness สูง (0.92) แต่ answer relevancy ต่ำ (0.71) — ปัญหาอยู่ที่ stage ไหน? ควรแก้อะไรก่อน?

ดูเฉลย

Faithfulness สูง = Generation ดี (AI ตอบตาม context ไม่แต่งเรื่อง)
Answer Relevancy ต่ำ = Retrieval ไม่ดี (ดึง chunks ที่ไม่ตรงคำถามมา)
แก้ที่ Retrieval: ปรับ query rewriting, embedding model, หรือเพิ่ม reranking ก่อน

M9: MCP & Agentic M11: Prompt Operations