สมมติว่าในบริษัทมีเอกสารอยู่เต็มไปหมด ทั้ง policy, คู่มือพนักงาน, ใบเสร็จ และไฟล์ PDF ที่อัปเดตกันคนละเวลา แล้วมีคนถาม AI ว่า “ถ้าไปทำงานต่างจังหวัด เบิกค่าโรงแรมได้คืนละเท่าไร และต้องส่งหลักฐานอะไรบ้าง?”

ถ้าเราโยนคำถามนี้ให้โมเดลอย่างเดียว มันอาจตอบได้ลื่นไหลมาก แต่ยังไม่รู้ว่า policy ล่าสุดของบริษัทเราเขียนไว้อย่างไร คำตอบอาจดูถูกต้องโดยที่เราไม่มีหลักฐานให้ตรวจสอบ

RAG หรือ Retrieval-Augmented Generation เป็นแนวคิดที่เติมขั้นตอน “ค้นข้อมูลก่อนตอบ” เข้าไปใน workflow ของ AI ไม่ได้ทำให้โมเดลฉลาดขึ้นทุกเรื่อง และไม่ได้รับประกันว่าจะไม่มี hallucination แต่ช่วยให้ระบบมีโอกาสอ้างอิงข้อมูลที่เกี่ยวข้อง สดกว่า และตรวจสอบย้อนกลับได้มากขึ้น

บทความนี้เป็นภาพรวมเพื่อปูพื้นก่อนสร้างระบบจริง เราจะเริ่มจากสามคำของ RAG แล้วค่อยแยกให้เห็นว่า retrieval มีหลายวิธีอย่างไร ทำไม RAG ไม่ได้แปลว่า vector database เสมอไป และจุดไหนที่ระบบยังพลาดได้

RAG ในหนึ่งประโยค: ค้นก่อน แล้วค่อยตอบ

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

คำว่า RAG มักอธิบายด้วยสามขั้นตอน:

  • Retrieve — ค้นหา passage หรือเอกสารที่น่าจะเกี่ยวข้องกับคำถาม
  • Augment — นำคำถามและข้อมูลที่ค้นได้มาประกอบเป็น prompt
  • Generate — ให้โมเดลสร้างคำตอบจาก prompt ที่มีบริบทเพิ่มขึ้น

การแยกเป็นสามขั้นนี้ช่วยให้เราถามได้ถูกจุด เมื่อคำตอบไม่ดี ปัญหาอาจอยู่ที่ค้นผิด, ส่งบริบทไม่ครบ, หรือโมเดลตีความบริบทผิด ไม่ใช่โทษ “AI” ก้อนเดียว

Model-only versus RAGBoth paths start with the same question and end with an answer. The RAG path inserts retrieve and augment steps before generation.MODEL ONLYRAGQUESTIONhotel policy?MODELparametric memoryANSWERanswer without a lookupQUESTIONhotel policy?RETRIEVEevidenceAUGMENTprompt + dataGENERATElanguageANSWERevidence path added before the answer
Model-only ข้ามการค้นข้อมูล ส่วน RAG เพิ่มหลักฐานก่อนถึงขั้นสร้างคำตอบ

แล้วทำไมไม่ถามโมเดลตรง ๆ ไปเลย?

โมเดลทั่วไปมีความรู้ที่เรียนรู้มาแล้ว แต่ระบบงานจริงมักมีข้อมูลสามแบบที่คำตอบจากความจำของโมเดลไม่พอ

อย่างแรกคือ ข้อมูลส่วนตัวขององค์กร เช่น policy เบิกค่าใช้จ่าย, runbook ของทีม หรือสัญญากับลูกค้า ข้อมูลเหล่านี้อาจไม่เคยอยู่ในชุดข้อมูลฝึก และเราไม่ควรส่งทุกอย่างไปเทรนโมเดลใหม่เพื่อใช้ตอบคำถามไม่กี่แบบ

อย่างที่สองคือ ข้อมูลที่เปลี่ยนบ่อย เช่น อัตราค่าโรงแรม, รายการสินค้าที่หมด, หรือขั้นตอน incident ล่าสุด การอัปเดต index หรือแหล่งข้อมูลอาจเหมาะกว่า train model ใหม่ทั้งตัว

อย่างที่สามคือ ความต้องการเรื่องที่มา คำตอบสำหรับงานจริงไม่ได้จบที่ “น่าจะใช่” ผู้ใช้ควรรู้ว่าคำตอบมาจากเอกสารไหน เวอร์ชันอะไร และส่วนไหนของเอกสารที่ถูกใช้ การเก็บ metadata เช่น title, URL, document ID และวันที่อัปเดตจึงเป็นส่วนหนึ่งของระบบ ไม่ใช่ของตกแต่งทีหลัง

RAG ทำงานอยู่ 2 ช่วงหลัก

ถ้ามองภาพรวม RAG มีงานอยู่สองช่วงที่ต่างกันพอสมควร: ช่วงแรกคือการเตรียมข้อมูลให้ค้นหาได้ และอีกช่วงคือการนำข้อมูลนั้นมาใช้ตอนมีคำถามเข้ามา

ด้านแรกคือ indexing pipeline ทำงานก่อนผู้ใช้ถาม ระบบอ่านเอกสาร, แปลงเป็นข้อความ, แบ่งเป็นชิ้นเล็ก ๆ, เก็บ metadata และเตรียม index สำหรับค้นหา ถ้าเอกสารถูก parse ผิดหรือแบ่ง chunk ไม่ดี ปัญหาจะติดไปถึงเวลาตอบ

ด้านที่สองคือ query pipeline เริ่มเมื่อมีคำถาม ระบบอาจปรับ query, ค้น index, filter ตามสิทธิ์, rerank ผลลัพธ์, เลือกบริบทจำนวนพอดี แล้วจึงส่งให้โมเดลสร้างคำตอบ

RAG indexing and querying pipelinesDocuments are prepared, split, enriched with metadata, and indexed. A user query is then searched, filtered, ranked, and passed to the model as context.INDEXING / BEFORE THE QUESTIONDOCUMENTSpolicy / PDFPARSEclean textCHUNKsmall passagesENRICHtitle / accessINDEXkeyword / vectorQUERYING / WHEN THE QUESTION ARRIVESQUESTIONhotel / BangkokSEARCHquery the indexFILTER / RERANKrelevance + accessCONTEXTtop passagesMODELanswer
คุณภาพของคำตอบเป็นผลร่วมของการเตรียมข้อมูลและการค้นตอนมีคำถาม

การมองเป็นสอง pipeline ทำให้การ debug ชัดขึ้น ถ้าหาเอกสารไม่เจอทั้งที่มีอยู่ อาจต้องดู parser, chunking หรือ index ไม่ใช่รีบเพิ่มคำสั่งใน system prompt อย่างเดียว

Retrieve: ค้นให้เจอสิ่งที่ตอบคำถามจริง

กลับมาที่คำถามเรื่องโรงแรม สมมติเอกสารมีข้อความว่า “เบิกได้ไม่เกิน 2,000 บาทต่อคืนในกรุงเทพฯ และ 1,500 บาทต่อคืนในจังหวัดอื่น โดยต้องแนบใบเสร็จฉบับจริง”

ตัวเลขและ policy ในตัวอย่างนี้เป็นข้อมูลสมมติ ใช้เพื่ออธิบายการทำงานของ RAG

ถ้า retrieval หยิบ policy เก่าที่เขียนว่า 1,200 บาทมาแทน หรือหยิบส่วนที่พูดถึง “ค่าเดินทาง” ซึ่งอยู่ใกล้กันแต่ไม่ตอบเรื่องโรงแรม โมเดลก็ได้รับบริบทที่ผิดตั้งแต่ต้น ต่อให้ prompt เขียนดีแค่ไหน คำตอบก็อาจผิดตาม

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

ถ้าเอกสารมีหลายเวอร์ชัน ระบบก็ควรรู้ว่า ฉบับไหนเป็นฉบับที่มีผลใช้งานอยู่ และผู้ใช้คนนี้มีสิทธิ์เห็นข้อมูลใด

Augment: ประกอบคำถามกับหลักฐาน

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

ในเชิงแนวคิด prompt อาจมีหน้าตาประมาณนี้:

คุณเป็นผู้ช่วยตอบคำถามจากเอกสารบริษัท

คำถามของผู้ใช้:
ถ้าไปทำงานต่างจังหวัด เบิกค่าโรงแรมได้เท่าไร และต้องใช้หลักฐานอะไร?

บริบทที่ค้นพบ:
[policy-travel-v3.pdf, section 4.2]
เบิกได้ไม่เกิน 1,500 บาทต่อคืนในจังหวัดอื่น
ต้องแนบใบเสร็จฉบับจริง

กติกา:
- ตอบเฉพาะจากบริบทที่ให้
- ถ้าบริบทไม่พอ ให้บอกว่ายังยืนยันไม่ได้
- ระบุเอกสารที่ใช้เป็นหลักฐาน

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

Generate: ตอบให้เข้าใจง่าย และตรวจสอบย้อนกลับได้

ขั้นสุดท้ายคือให้โมเดลสร้างภาษาที่คนอ่านเข้าใจ แต่ “สร้างจากบริบท” ไม่ได้แปลว่าคำตอบจะจริงโดยอัตโนมัติ โมเดลยังอาจสรุปเกินหลักฐาน, เชื่อเอกสารที่ผิด, หรือผสมข้อมูลจากคนละข้อเข้าด้วยกัน

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

ดังนั้น citation หรือ source reference จึงเป็นความสามารถของแอปพลิเคชันที่ต้องออกแบบตั้งแต่ต้น เช่น เก็บ document ID, heading, page number หรือ URL ไว้คู่กับ chunk และส่ง metadata นั้นออกไปพร้อมคำตอบ การมีลิงก์ให้กดตรวจสอบช่วยให้ผู้ใช้แยก “ระบบตอบอะไร” ออกจาก “หลักฐานพูดว่าอะไร” ได้

RAG ไม่เท่ากับ vector database

คำว่า RAG มักถูกเล่าคู่กับ vector search จนเหมือนเป็นสิ่งเดียวกัน แต่ RAG คือ pattern ของระบบ ส่วนวิธีค้นหาเป็น implementation choice

ถ้าคำถามมี error code, เลขใบสั่งซื้อ หรือชื่อ field ที่ต้องตรงกัน การค้นแบบ keyword หรือ lexical search อาจเหมาะกว่า เพราะมันให้ความสำคัญกับคำและ token ที่ตรงกัน

ถ้าคำถามใช้ภาษาคนละแบบกับเอกสาร เช่น “ขอคืนเงินที่พักได้ไหม” แต่ policy เขียนว่า “reimbursement for accommodation” การค้นแบบ semantic หรือ vector search อาจช่วยจับความหมายใกล้กันได้ โดยแปลงข้อความเป็น embedding แล้วหา passage ที่อยู่ใกล้กันในเชิงความหมาย

ส่วน hybrid search ผสมสัญญาณ lexical กับ vector เพื่อไม่ทิ้งทั้งคำเฉพาะและความหมายของประโยค และหลายระบบอาจใช้ filter ตาม metadata หรือ reranker เพื่อจัดลำดับผลลัพธ์อีกครั้ง

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

RAG retrieval pathsA question can use keyword search, semantic or vector search, hybrid search, filtering, and optional reranking before context reaches the model.THE RETRIEVER IS A CHOICEQUESTIONhotel reimbursementKEYWORD / LEXICALexact terms, IDsSEMANTIC / VECTORmeaning, paraphraseHYBRIDlexical + vectorFILTER / RERANKaccess + relevanceCONTEXTto the modelNo single path wins every query: exact codes and natural language often need different signals.

เส้นทาง retrieval เปลี่ยนได้ตามชนิดคำถาม และอาจมี filter หรือ rerank ต่อท้าย

RAG มีกี่ประเภท?

ไม่มีจำนวนประเภทของ RAG ที่เป็นมาตรฐานเดียวกัน ทุกทีมอาจใช้คำเรียกต่างกันตามจุดที่อยากเน้น บางครั้งแบ่งตามวิธีค้น เช่น keyword, vector และ hybrid บางครั้งแบ่งตามสถาปัตยกรรม เช่น classic RAG กับ agentic RAG

Classic RAG มักเป็นลำดับที่ค่อนข้างคงที่: รับคำถาม, ค้นหนึ่งครั้ง, ประกอบ context และเรียกโมเดล เหมาะกับคำถามที่พอ map ไปยัง index เดียวได้ และควบคุม latency กับต้นทุนได้ง่ายกว่า

Agentic RAG ให้โมเดลหรือ agent ช่วยวางแผนว่า query ต้องแตกเป็นคำถามย่อยหรือไม่ ควรเรียก source ไหน และผลลัพธ์พอหรือยัง จึงอาจค้นหลายรอบหรือหลายแหล่ง เหมาะกับคำถามที่ต้องเปรียบเทียบหลายระบบ แต่แลกกับความซับซ้อน, latency, token และจุดที่ต้อง monitor เพิ่มขึ้น

เริ่มจาก classic RAG ที่วัดผลได้ก่อน แล้วค่อยเพิ่ม loop เมื่อปัญหาจริงต้องใช้มัน การมี agent ไม่ได้ทำให้ retrieval ถูกต้องขึ้นเอง

RAG แก้ hallucination ได้ไหม?

คำตอบสั้น ๆ คือ ช่วยลดการเดาโดยไม่มีหลักฐานได้ในบางกรณี แต่ไม่ใช่เครื่องรับประกันความจริง

ถ้าระบบค้นเจอเอกสารที่เกี่ยวข้องและส่งเป็นบริบทที่อ่านได้ โมเดลมีฐานให้ยึดมากขึ้น และอาจตอบพร้อม citation ได้ดีขึ้น แต่ถ้าข้อมูลต้นทางผิด, parse ผิด, chunk ขาดประโยคสำคัญ, retriever หยิบผิด passage หรือโมเดลสรุปเกินหลักฐาน ความผิดก็ยังเดินทางต่อได้

นี่คือเหตุผลที่การประเมินต้องแยกอย่างน้อยสองส่วน: retrieval ได้ข้อมูลที่เกี่ยวข้องหรือไม่ และ generation ตอบสอดคล้องกับข้อมูลนั้นหรือไม่ คำตอบที่ดูดีแต่ไม่มีหลักฐานที่เกี่ยวข้องไม่ควรถูกนับเป็น success

RAG failure propagationData and parsing begin aligned. A small vertical offset begins at chunking and continues through indexing, retrieval, context, and generation until the answer is wrong.ONE SMALL OFFSET CAN TRAVELDATAsourcePARSEcleanCHUNKwrong spanINDEXstoredRETRIEVEtop resultCONTEXTin promptGENERATIONwrong answerSMALL OFFSET BEGINSA retrieval system can ground an answer in text; it cannot repair evidence that was never retrieved correctly.

ระบบอาจสร้างคำตอบที่ผิดจากหลักฐานที่ผิดหรือไม่ครบ แม้ขั้น generation จะทำงานตามปกติ

RAG กับ fine-tuning ต่างกันอย่างไร?

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

ถ้าโจทย์คือ “อยากเปลี่ยนพฤติกรรม, รูปแบบ, น้ำเสียง หรือความสามารถเฉพาะงานของโมเดล” fine-tuning อาจเหมาะกว่า ทั้งสองวิธีใช้ร่วมกันได้ แต่ไม่ได้แทนกันทั้งหมด และการเลือกควรเริ่มจากปัญหาที่ต้องแก้ ไม่ใช่จากชื่อเทคโนโลยีที่กำลังเป็นกระแส

RAG ใช้กับงานอะไรได้บ้าง?

งานที่มี knowledge base และคำถามเปลี่ยนไปเรื่อย ๆ มักเป็นจุดเริ่มต้นที่ดี เช่น ผู้ช่วยค้น policy ในองค์กร, support ที่ต้องอ้างคู่มือสินค้า, ค้นเอกสารวิจัย, สรุป incident จาก runbook หรือถามข้อมูลจาก catalog ที่มีการเปลี่ยนแปลง

แต่ทุกกรณีต้องคิดเรื่อง access control ด้วย การค้นเจอไม่ได้แปลว่าผู้ถามควรเห็นข้อมูลนั้น ระบบควร filter ตามสิทธิ์ตั้งแต่ retrieval boundary และถือว่าเนื้อหาในเอกสารเป็น input ที่อาจไม่น่าเชื่อถือหรือมี prompt injection ได้

RAG ไม่ได้จบตอนตอบได้หนึ่งครั้ง

prototype ที่ตอบคำถามตัวอย่างได้อาจเป็นเพียงจุดเริ่มต้น ปัญหาที่ต้องค่อย ๆ วัดยังมีตั้งแต่การแบ่ง chunk, จำนวน top-k, การทำ metadata filter, reranking, ความขัดแย้งระหว่างเอกสาร, ความสดของ index, token budget, latency และต้นทุน

ก่อนปรับระบบ ควรมีชุดคำถามจริงที่เป็นตัวแทนของงาน พร้อมคำตอบหรือหลักฐานอ้างอิงที่คนตรวจแล้ว จากนั้นวัดทั้งคุณภาพการค้น, groundedness ของคำตอบ, citation ที่ตามได้ และกรณีที่ระบบควรยอมรับว่า “ยังตอบไม่ได้” การมี demo ที่สวยไม่เท่ากับการมีระบบที่เชื่อถือได้

สรุป: RAG คือการออกแบบเส้นทางจากข้อมูลสู่คำตอบ

RAG ไม่ใช่ปุ่มเปิดความรู้ใหม่ให้ AI แต่เป็นการออกแบบ workflow ที่ทำให้ระบบค้นข้อมูลที่เกี่ยวข้อง, ประกอบบริบท, แล้วให้โมเดลสร้างคำตอบบนฐานนั้น

สิ่งที่ควรจำมีสามข้อ:

  1. Retrieve → Augment → Generate เป็นกรอบคิดที่ช่วยแยกปัญหาเป็นช่วง ๆ
  2. RAG ใช้ keyword, vector, hybrid, filter หรือ rerank ได้ตามลักษณะข้อมูลและคำถาม ไม่ได้บังคับให้ใช้ vector database อย่างเดียว
  3. การค้นผิดหรือข้อมูลต้นทางผิดยังทำให้คำตอบผิดได้ จึงต้องมี citation, access control และการประเมินทั้ง retrieval กับ generation

บทความถัดไปจะลงลึกกับคำถามที่มักเกิดขึ้นทันทีหลังเข้าใจภาพรวมนี้: Chunking คืออะไร และทำไมการหั่นเอกสารจึงเปลี่ยนคุณภาพของคำตอบได้มากกว่าที่คิด

References