RAG ทำงานอย่างไร: อธิบายแบบเห็นภาพ

ลองนึกภาพ tech lead เดินเข้ามาวางคู่มือพนักงานหนา 500 หน้าลงบนโต๊ะ แล้วบอกว่า “อยากได้ chatbot ที่ตอบคำถามจากคู่มือเล่มนี้ ภายในสองสัปดาห์ ทำได้ไหม” คำตอบแรกที่หลายคนนึกถึงคือ “ก็ fine-tune โมเดลเอาสิ” — ฟังดูสมเหตุสมผล แต่พอคิดจริงๆ จะเจอปัญหาเพียบ ใครจะ label คู่ถาม-ตอบจาก 500 หน้า? ถ้าเดือนหน้านโยบายเปลี่ยน ต้อง fine-tune ใหม่ทั้งรอบไหม? และเมื่อพนักงานถามว่า “ดูได้ที่หน้าไหน” โมเดลที่จำข้อมูลไว้ใน weights จะอ้างอิงหน้าไม่ได้เลย

อีกทางคือยัดคู่มือทั้งเล่มเข้า prompt แต่ 500 หน้าคือราว 350,000 tokens ซึ่งเกิน context window ของโมเดลส่วนใหญ่ และต่อให้ใส่ได้ ค่า token ต่อคำถามก็แพงมหาศาล ทางที่สามคือสิ่งที่กลายเป็น default ของ AI Engineer ยุคนี้ นั่นคือ RAG (Retrieval-Augmented Generation)

RAG คือการบังคับให้โมเดล “เปิดหนังสือก่อนตอบ”

แทนที่จะให้โมเดลจำทุกอย่าง หรือยัดทุกอย่างเข้า prompt RAG ให้ระบบ “ค้นเฉพาะหน้าที่เกี่ยวข้อง” มาให้โมเดลอ่านก่อนตอบ

เปรียบเทียบกับการสอบแบบเปิดหนังสือได้ คุณไม่ต้องท่องทุกอย่างให้แม่น แต่ต้องรู้ว่าคำตอบ “อยู่หน้าไหน” และเปิดได้เร็วพอ นักศึกษาที่เตรียมตัวดีจะเปิดถูกหน้าและตอบถูก นักศึกษาที่เปิดผิดหน้า ต่อให้หนังสือมีคำตอบก็ตอบไม่ได้ ส่วนคนที่ไม่เปิดเลยแล้วตอบจากความจำที่อาจคลาดเคลื่อน — นั่นคือสิ่งที่ LLM ปกติเป็นโดย default

ถ้า retrieval ดึงผิด ไม่มี LLM ตัวไหนแก้ได้ — garbage in, garbage out ยังใช้ได้ในยุค AI

Pipeline 7 ขั้น แยกเป็นสองช่วงเวลา

RAG ไม่ใช่ของชิ้นเดียว มันคือ pipeline ที่แบ่งเป็นสองช่วงชัดเจน เข้าใจสองช่วงนี้แล้วเข้าใจ RAG ทั้งหมด

ช่วงแรกคือ Offline (ทำครั้งเดียวตอน setup, ทำใหม่เมื่อเอกสารเปลี่ยน):

• Load — อ่านไฟล์เข้าระบบ (PDF, Word, Markdown, HTML, แถวใน database)
• Chunk — แบ่งเอกสารใหญ่เป็นชิ้นย่อยที่ embed ได้
• Embed — แปลงแต่ละ chunk เป็น vector ตัวเลข
• Store — บันทึก vector พร้อม text และ metadata ลง vector store

ช่วงสองคือ Online (ทำทุกครั้งที่ผู้ใช้ถาม):

• Retrieve — embed คำถามด้วยโมเดลเดียวกัน หา chunk ที่ใกล้ที่สุด top-k
• Augment — เอา chunk ที่ดึงมา รวมกับคำถามเดิม ประกอบเป็น prompt
• Generate — ส่ง prompt ที่ประกอบแล้วให้ LLM ตอบพร้อม citation

แก่นของทุก framework ไม่ว่าจะ LlamaIndex หรือ Pinecone ก็ตามนี้ จุดที่ต้องเข้าใจคือขั้น 1–4 เป็นงาน batch ที่ทำครั้งเดียว ส่วนขั้น 5–7 รันทุก request — cost, latency และจุดที่พังของสองช่วงนี้ไม่เหมือนกันเลย การออกแบบที่ดีจึงต้องแยกสองช่วงนี้ออกจากกันให้ชัด

เมื่อ RAG ตอบผิด ให้ถามว่า “มันพังที่ขั้นไหน”

เสน่ห์ของการมองเป็น pipeline คือเวลามันตอบผิด คุณ debug เป็นจุดได้ ไม่ใช่นั่งลองมั่วไปเรื่อย จุดที่พังบ่อยมีรูปแบบซ้ำๆ เช่น

• Chunk boundary ผิด — ตัดกลางประโยคหรือ chunk หนึ่งครอบหลายหัวข้อ ทำให้ความหมายเพี้ยน นี่คือจุดที่เจอบ่อยที่สุด
• Semantic mismatch — ผู้ใช้พิมพ์ “WFH ได้กี่วัน” แต่เอกสารเขียน “Remote work policy” คำผิวต่างกัน vector เลยดึงผิด แก้ด้วย hybrid search (semantic + keyword)
• Lost-in-the-middle — งานวิจัยพบว่าโมเดลใส่ใจข้อมูลที่ต้นและท้าย context มากกว่าตรงกลาง ประสิทธิภาพตกได้เกิน 30% เมื่อข้อมูลสำคัญอยู่กลาง แก้ด้วยการลด top-k และ rerank เอา chunk ที่ดีที่สุดไว้ต้น
• Generation ละเลย context — ดึง chunk ถูกแล้วแต่โมเดลดันตอบจากความรู้เดิม หรืออ้างอิงผิดอัน แก้ด้วย system prompt ที่บังคับว่า “ตอบจาก context เท่านั้น”

วิธีคิดคือไล่ถามทีละขั้น: chunk ที่ดึงมาถูกต้องไหม? ถ้าไม่ถูก คือ retrieval failure (ไปแก้ chunking / embedding / hybrid search) ถ้าถูกแต่ยังตอบผิด คือ generation failure (ไปลด top-k / เสริม system prompt) ถ้าเอกสารไม่มีคำตอบเลย นั่นไม่ใช่ปัญหาของ RAG แต่คือ knowledge base ต้องเพิ่มแหล่งข้อมูล

Chunking: การตัดสินใจเล็กๆ ที่ส่งผลแรงที่สุด

Chunk คือ “หน่วยที่เล็กที่สุดที่ระบบจะค้นให้คุณได้” ถ้าเล็กไปความหมายหาย ถ้าใหญ่ไป noise เยอะ ไม่มีขนาดที่ “ถูกต้อง” มีแต่ขนาดที่ดีพอสำหรับเอกสารและงานนั้นๆ แนวที่ใช้ได้จริงคือ ถ้าเอกสารมีโครงสร้างชัด (หัวข้อ section) ลอง structure-aware ก่อน ถ้าเป็นบทสนทนาหรือ Q&A ใช้ sentence-aware ถ้ายังไม่แน่ใจให้เริ่มที่ recursive character ราว 400–512 tokens ซึ่งเป็นจุดเริ่มที่ดีสำหรับงานส่วนใหญ่ และอย่ารีบกระโดดไป semantic chunking เพราะ cost สูงและไม่ได้ดีกว่าทุกกรณี

ใครก็ตามที่บอกว่า “ใช้ 512 tokens สิ ดีที่สุด” โดยไม่ถามว่าเอกสารของคุณคืออะไร — ฟังหูไว้หู

คุณภาพคำตอบของ RAG ขึ้นกับสองอย่างพอๆ กัน: (1) หนังสือมีคำตอบนั้นไหม และ (2) เราเปิดถูกหน้าหรือเปล่า

เมื่อมองภาพรวม RAG ไม่ใช่เวทมนตร์ แต่เป็น pipeline engineering ที่ประกอบของสำเร็จรูปเข้าด้วยกันอย่างมีเหตุผล พลังของมันอยู่ที่การแยกงาน offline ออกจาก online และความสามารถในการ debug เป็นจุดเมื่อมันพลาด เข้าใจ 7 ขั้นนี้แล้ว คุณจะเห็นว่าใต้ framework สวยๆ มีอะไรเกิดขึ้นจริง และจะออกแบบระบบที่ตอบได้ทั้งแม่นและตรวจสอบที่มาได้