สรุปหัวใจ RAG: เมื่อ AI ต้องเปิดหนังสือสอบก่อนตอบคำถาม

ช่วงหลังผมเริ่มศึกษาเรื่อง AI tools มากขึ้น ไม่ว่าจะเป็น Claude Code, ChatGPT, Agent, MCP หรือ RAG เพราะอยากเข้าใจว่าเราจะเอา AI มาช่วยงาน software development ได้ยังไงแบบที่ใช้งานได้จริง ไม่ใช่แค่ให้มันตอบคำถามทั่วไป

หนึ่งใน concept ที่ผมคิดว่า Backend Developer ควรรู้คือ RAG หรือ Retrieval-Augmented Generation

พูดแบบง่าย ๆ RAG คือการทำให้ AI “ไปค้นข้อมูลก่อนตอบ” แทนที่จะให้มันตอบจากความจำของตัวเองอย่างเดียว

RAG คืออะไร

RAG ย่อมาจาก 3 คำหลัก ๆ คือ

1. Retrieve — ดึงข้อมูลที่เกี่ยวข้องจากแหล่งข้อมูลภายนอก
2. Augment — เอาข้อมูลที่ดึงมาได้ไปเติมเข้าไปใน prompt
3. Generation — ให้ LLM สร้างคำตอบโดยอิงจากข้อมูลที่เราใส่เข้าไป

ถ้าเปรียบเทียบง่าย ๆ การถาม LLM ปกติเหมือนถามคนจากความจำ แต่ RAG เหมือนให้คนนั้นเปิดหนังสือสอบก่อนตอบ

จุดสำคัญคือ RAG ช่วยให้ AI ตอบจากข้อมูลที่เราเตรียมไว้ เช่น เอกสารบริษัท, PDF, database, wiki, knowledge base หรือข้อมูลที่อัปเดตใหม่กว่าข้อมูลที่โมเดลเคยถูก train มา

ทำไมต้องใช้ RAG

ปัญหาของ LLM คือบางครั้งมันตอบมั่ว หรือที่เรียกว่า Hallucination

โดยเฉพาะเวลาถามเรื่องที่ต้องการข้อมูลเฉพาะ เช่น

• นโยบายบริษัทล่าสุด
• เอกสารภายในองค์กร
• ข้อมูลการเงิน
• คู่มือระบบ
• requirement ของ project
• เอกสาร technical ที่ไม่ได้อยู่ใน training data

ถ้าเราให้ AI ตอบจากความจำอย่างเดียว มันอาจเดาได้ แต่ถ้าใช้ RAG เราสามารถบังคับให้มันตอบจากข้อมูลที่เราดึงมาให้ก่อน ตอนที่ผมลองใช้ NotebookLM ผมเริ่มเห็นภาพว่า RAG ไม่ได้ไกลตัวเลย เพราะการอัปโหลดวิดีโอหรือเอกสารเข้าไป แล้วถามเฉพาะจาก source นั้น จริง ๆ ก็คือประสบการณ์แบบ RAG ในระดับ product ที่ใช้งานง่ายมาก

RAG ต่างจาก Context Window ยังไง

บางคนอาจคิดว่า ถ้า model มี context window ใหญ่มาก เช่น ใส่ข้อมูลได้หลายแสนหรือเป็นล้าน token ก็ไม่ต้องใช้ RAG แล้วหรือเปล่า

คำตอบคือ ไม่เสมอไป

Context Window ใหญ่เหมาะกับข้อมูลที่ไม่ได้ใหญ่มาก และไม่ได้เปลี่ยนบ่อย แต่ถ้าข้อมูลมีจำนวนมาก หรือมีการอัปเดตตลอดเวลา การยัดข้อมูลทั้งหมดเข้า prompt อาจไม่ practical

ปัญหาคือ

• ใช้ token เยอะ
• latency สูง
• ค่าใช้จ่ายเพิ่ม
• model อาจหยิบข้อมูลผิดจุด
• ข้อมูลบางอย่างไม่จำเป็นต้องถูกส่งเข้าไปทุกครั้ง

RAG จึงช่วยให้เราเลือกเฉพาะข้อมูลที่เกี่ยวข้องที่สุดก่อน แล้วค่อยส่งให้ LLM ตอบ

RAG ต่างจาก Fine-tuning ยังไง

Fine-tuning คือการปรับ model ให้เรียนรู้ pattern หรือ style เพิ่มเติม เหมือนส่งคนไปเรียนคอร์สเฉพาะทาง

แต่ RAG เหมือนการให้คนเปิดเอกสารก่อนตอบ

ถ้าเป็นข้อมูลที่เปลี่ยนบ่อย เช่น ราคา นโยบาย เอกสารล่าสุด หรือข้อมูลลูกค้า RAG จะเหมาะกว่า เพราะเราแค่อัปเดตแหล่งข้อมูล ไม่ต้อง train model ใหม่

มุมมองที่ผมเข้าใจคือ

• Fine-tuning เหมาะกับการปรับพฤติกรรมหรือ style ของ model
• RAG เหมาะกับการให้ model ใช้ข้อมูลจริงที่อัปเดตได้

ส่วนประกอบสำคัญของ RAG

ระบบ RAG ทั่วไปมักมีส่วนประกอบประมาณนี้

1. Data Source

แหล่งข้อมูลที่เราต้องการให้ AI ใช้ เช่น PDF, website, database, Notion, Google Docs, internal wiki หรือ log บางประเภท

2. Chunking

ถ้าเอกสารยาวมาก เราต้องหั่นข้อมูลออกเป็นชิ้นเล็ก ๆ เพื่อให้ค้นหาและส่งเข้า prompt ได้ง่ายขึ้น

จุดที่ต้องระวังคือ ถ้าหั่นเล็กเกินไป context อาจหาย แต่ถ้าหั่นใหญ่เกินไป retrieval อาจไม่แม่น

3. Embedding

Embedding คือการแปลงข้อความให้กลายเป็นตัวเลข เพื่อให้ระบบสามารถคำนวณความใกล้เคียงทางความหมายได้

เช่น คำว่า “วันลา” กับ “leave policy” อาจไม่ได้ใช้คำเหมือนกัน แต่มีความหมายใกล้กัน ระบบ vector search จะช่วยหาเนื้อหาที่เกี่ยวข้องได้ดีกว่าการ search แบบ keyword ตรง ๆ

4. Vector Database

Vector Database ใช้เก็บ embedding และช่วยค้นหาข้อมูลแบบ semantic search

ตัวอย่าง concept คือ แทนที่จะค้นหาว่ามี keyword ตรงไหม ระบบจะค้นหาว่าเนื้อหาไหน “มีความหมายใกล้เคียง” กับคำถามมากที่สุด

5. Prompt Template

หลังจากดึงข้อมูลที่เกี่ยวข้องมาได้แล้ว Backend จะเอาข้อมูลนั้นไปประกอบกับคำถามของ user แล้วสร้าง prompt ใหม่ส่งให้ LLM

ตัวอย่าง flow ง่าย ๆ คือ

User question
↓
Retrieve related documents
↓
Insert documents into prompt template
↓
Send to LLM
↓
Generate answer based on retrieved context

Backend Developer ควรมอง RAG ยังไง

สำหรับผม RAG ไม่ใช่แค่เรื่องของ AI อย่างเดียว แต่มันคือ backend architecture แบบหนึ่ง

Backend ต้องรับผิดชอบหลายอย่าง เช่น

• รับคำถามจาก user
• เตรียม query สำหรับค้นหา
• ดึงข้อมูลจาก database หรือ vector database
• จัดอันดับข้อมูลที่เกี่ยวข้อง
• สร้าง prompt template
• ส่ง request ไปหา LLM
• จัดการ response
• handle error, timeout, logging, cost และ security

สิ่งสำคัญคือ Retrieval ต้องแม่น ถ้าดึงข้อมูลผิด ต่อให้ LLM เก่งแค่ไหนก็อาจตอบผิดได้

ไม่จำเป็นต้องใช้ Vector DB เสมอไป

จุดหนึ่งที่ผมคิดว่าน่าสนใจคือ RAG ไม่ได้แปลว่าต้องใช้ Vector Database เสมอไป

ถ้าข้อมูลของเรามีโครงสร้างชัดเจน เช่น transaction, order, user profile หรือ policy ที่อยู่ใน SQL อยู่แล้ว เราอาจใช้ SQL query ดึงข้อมูลมาก่อนก็ได้

บางระบบอาจใช้ Hybrid Search เช่น

1. ใช้ SQL กรองข้อมูลตาม user, date, category หรือ permission
2. ใช้ Vector Search หาเนื้อหาที่เกี่ยวข้องภายในชุดข้อมูลนั้น
3. เอาผลลัพธ์ไปประกอบ prompt ให้ LLM ตอบ

แบบนี้จะช่วยให้ระบบแม่นขึ้น และควบคุม data access ได้ดีกว่า

ข้อควรระวังของ RAG

RAG ไม่ใช่ magic bullet ที่ใส่เข้าไปแล้วทุกอย่างจะดีขึ้นทันที ยังมีหลายอย่างที่ต้องออกแบบดี ๆ

Chunking ผิด อาจทำให้ข้อมูลหาย

ถ้าแบ่งข้อมูลไม่ดี ข้อมูลที่ควรอยู่ด้วยกันอาจถูกแยกออกจากกัน ทำให้ตอน retrieval ดึงข้อมูลมาไม่ครบ

Context เยอะเกินไปก็มีปัญหา

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

Latency และ Cost

RAG มีหลาย step มากกว่าการเรียก LLM ตรง ๆ เช่น search, ranking, prompt building และ generation ดังนั้นต้องคิดเรื่อง performance และ cost ด้วย

Security และ Permission

ถ้าใช้กับข้อมูลภายในองค์กร ต้องระวังเรื่องสิทธิ์การเข้าถึงข้อมูล เช่น user คนหนึ่งไม่ควรได้คำตอบจากเอกสารที่ตัวเองไม่มีสิทธิ์อ่าน

สรุปสิ่งที่ผมเข้าใจ

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

สำหรับ Backend Developer สิ่งที่ควรโฟกัสไม่ใช่แค่ “ใช้ Vector DB ตัวไหนดี” แต่คือการออกแบบ retrieval pipeline ให้ดี

สิ่งที่ควรคิดคือ

• ข้อมูลอยู่ที่ไหน
• จะหั่นข้อมูลยังไง
• จะค้นหายังไงให้แม่น
• จะควบคุม permission ยังไง
• จะจัด prompt ยังไง
• จะลด hallucination ยังไง
• จะวัดคุณภาพคำตอบยังไง

มุมมองที่ผมชอบคือ RAG ไม่ใช่แค่ AI feature แต่มันคือ architecture ที่เชื่อม LLM เข้ากับข้อมูลจริงของระบบ

และนั่นทำให้ Backend Developer ยังมีบทบาทสำคัญมากในการทำให้ AI ใช้งานได้จริงใน production