โมเดลตอบข้อมูลเก่าทั้งที่เอกสารบริษัทอัปเดตแล้ว แก้ด้วย RAG ยังไง

ทีมพัฒนาแห่งหนึ่งสร้างแชทบอทตอบคำถามพนักงานเรื่องสวัสดิการและนโยบายลา โดยเอาเอกสารนโยบายทั้งหมดไป fine-tune เข้าไปในโมเดลตั้งแต่ต้น ผลลัพธ์ช่วงแรกดูดีมาก โมเดลตอบคล่อง ใช้ภาษาที่เป็นธรรมชาติ แต่พอบริษัทประกาศนโยบายลาแบบใหม่ในเดือนถัดมา แชทบอทกลับยังตอบนโยบายเก่าอยู่ดี เพราะความรู้ที่ฝังไว้ในน้ำหนักของโมเดล (Model Weights) ไม่ได้อัปเดตตามเอกสารที่เปลี่ยนไป จะแก้ทางเดียวคือต้อง fine-tune ใหม่ทั้งรอบ ซึ่งทั้งแพงและใช้เวลา

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

หลายทีมที่เริ่มทำ AI feature ในปี 2026 มักถามคำถามเดียวกันว่า ในเมื่อโมเดลรุ่นใหม่รับ Context Window ได้เป็นล้าน token แล้ว ทำไมยังต้องเสียเวลาทำระบบ RAG ให้ซับซ้อน บทความนี้จะพาไล่ตั้งแต่กลไกพื้นฐาน ไปจนถึงเหตุผลที่ RAG ยังจำเป็น และจุดที่ทีมส่วนใหญ่ตั้งค่าพลาดจนระบบดึงข้อมูลผิดโดยไม่รู้ตัว

RAG คืออะไร กลไกเบื้องหลังคำว่า Retrieval-Augmented Generation

RAG ย่อมาจาก Retrieval-Augmented Generation แปลตรงตัวคือ 'การสร้างคำตอบที่เสริมด้วยการค้นคืนข้อมูล' หัวใจของมันคือการแบ่งกระบวนการตอบคำถามออกเป็นสองขั้นตอนที่แยกจากกันชัดเจน ขั้นแรกคือการค้นหา (Retrieval) ซึ่งระบบจะไปค้นในฐานข้อมูลความรู้ว่ามีเนื้อหาส่วนไหนที่เกี่ยวข้องกับคำถามของผู้ใช้บ้าง ขั้นที่สองคือการสร้างคำตอบ (Generation) ที่โมเดลภาษาจะรับเนื้อหาที่ค้นเจอมาอ่าน แล้วเรียบเรียงเป็นคำตอบที่อ่านง่ายและตรงประเด็น

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

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

Context Window ใหญ่ขึ้นทุกปี แล้วทำไมยังต้องใช้ RAG

คำถามที่พบบ่อยที่สุดในปี 2026 คือโมเดลรุ่นใหม่รับ Context ได้หลักล้าน token แล้ว ทำไมไม่ยัดเอกสารทั้งหมดเข้าไปในพรอมป์ต์เลยตั้งแต่ต้น คำตอบสั้น ๆ คือทำได้ แต่ไม่คุ้ม เพราะทุก token ที่ส่งเข้าไปมีต้นทุนจริง ทั้งค่าใช้จ่ายต่อคำขอและเวลาแฝง (Latency) ที่เพิ่มขึ้นตามปริมาณข้อมูล ถ้าฐานความรู้ของบริษัทมีเอกสารหลายพันหน้า การส่งทั้งหมดในทุกคำถามคือการจ่ายแพงเกินจำเป็นสำหรับคำถามที่จริง ๆ ต้องการแค่ย่อหน้าเดียว

อีกประเด็นที่สำคัญกว่าต้นทุนคือคุณภาพของคำตอบ งานวิจัยหลายชิ้นชี้ว่าเมื่อ Context ยาวมาก โมเดลมักมีปัญหา 'หลงประเด็น' หรือให้น้ำหนักกับข้อมูลตรงกลางของ Context น้อยกว่าข้อมูลตอนต้นและตอนท้าย (ปรากฏการณ์ที่มักเรียกกันว่า Lost in the Middle) การยัดข้อมูลจำนวนมากเข้าไปโดยไม่คัดกรองก่อน จึงไม่ได้แปลว่าโมเดลจะใช้ข้อมูลนั้นได้อย่างมีประสิทธิภาพเสมอไป

RAG แก้ปัญหาทั้งสองด้านพร้อมกัน คือคัดเฉพาะข้อมูลที่เกี่ยวข้องจริงมาใส่ใน Context ทำให้ทั้งประหยัดต้นทุนและเพิ่มโอกาสที่โมเดลจะโฟกัสกับข้อมูลที่สำคัญ นอกจากนี้ RAG ยังตอบโจทย์เรื่องข้อมูลที่เปลี่ยนแปลงบ่อยได้ดีกว่า เพราะ Context Window ไม่ว่าจะใหญ่แค่ไหนก็ยังเป็นข้อมูล ณ ตอนที่คุณส่งเข้าไป ถ้าฐานความรู้อัปเดตทุกวัน การมีระบบดึงข้อมูลสดเข้ามาแทนที่จะพึ่งขนาด Context อย่างเดียวจึงยังจำเป็นอยู่ดี

ขั้นตอนทำงานของระบบ RAG ตั้งแต่รับคำถามถึงได้คำตอบ

1. รับคำถามจากผู้ใช้ แล้วแปลงคำถามนั้นให้เป็น Embedding หรือเวกเตอร์ตัวเลขที่แทนความหมายของคำถาม โดยใช้โมเดล Embedding ตัวเดียวกับที่ใช้แปลงเอกสารตอนนำเข้าระบบ
2. นำเวกเตอร์ของคำถามไปค้นหาใน Vector Database เพื่อหาเอกสารหรือย่อหน้าที่มีความหมายใกล้เคียงที่สุด โดยทั่วไปจะดึงมาสัก 3-10 ชิ้นตามค่าที่ตั้งไว้ ไม่ใช่ดึงมาทั้งฐานข้อมูล
3. จัดอันดับผลลัพธ์ที่ได้ใหม่อีกครั้งด้วยเทคนิคที่เรียกว่า Reranking เพื่อคัดเฉพาะชิ้นที่เกี่ยวข้องจริง ๆ ขึ้นมาก่อน เพราะการค้นด้วยเวกเตอร์อย่างเดียวบางครั้งดึงเนื้อหาที่ใกล้เคียงแต่ไม่ตรงประเด็นมาด้วย
4. ประกอบพรอมป์ต์ใหม่ โดยนำเนื้อหาที่คัดกรองแล้วมาแนบไว้ในส่วนบริบท พร้อมคำสั่งที่ชัดเจนว่าให้โมเดลตอบโดยอิงจากเนื้อหาที่ให้มาเท่านั้น และควรระบุแหล่งอ้างอิงถ้าเป็นไปได้
5. ส่งพรอมป์ต์ที่ประกอบแล้วให้โมเดลภาษาสร้างคำตอบ แล้วอาจมีขั้นตอนตรวจสอบเพิ่มเติมก่อนส่งกลับผู้ใช้ เช่น เช็กว่าคำตอบมีการอ้างอิงเอกสารจริงหรือไม่ ก่อนแสดงผลสุดท้าย

คุณภาพของการดึงข้อมูล (Retrieval) สำคัญกว่าที่หลายคนคิด

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

ปัญหาที่พบบ่อยคือการค้นคืนดึงเอกสารมาผิดชิ้น เช่น คำถามเกี่ยวกับนโยบายลาป่วยของพนักงานประจำ แต่ระบบดันดึงนโยบายลาป่วยของพนักงานสัญญาจ้างมาแทน เพราะสองเอกสารนี้มีคำคล้ายกันมากในเชิงความหมาย การแก้ปัญหานี้ต้องอาศัยทั้งการปรับกลยุทธ์การแบ่งเอกสาร (Chunking) และการเพิ่มขั้นตอน Reranking เพื่อคัดกรองซ้ำก่อนส่งให้โมเดล

อีกจุดที่มักถูกมองข้ามคือ Recall กับ Precision ของระบบค้นคืน คือระบบดึงเอกสารที่เกี่ยวข้องมาครบไหม (Recall) และเอกสารที่ดึงมานั้นตรงประเด็นจริงกี่เปอร์เซ็นต์ (Precision) ทีมที่จริงจังกับ RAG ควรมีชุดคำถามทดสอบ (Evaluation Set) ที่รู้คำตอบที่ถูกต้องอยู่แล้ว เพื่อวัดสองค่านี้อย่างสม่ำเสมอ แทนที่จะเดาจากความรู้สึกว่าคำตอบ 'ดูโอเค'

แบ่งเอกสารเป็นชิ้น (Chunking) แบบไหนถึงจะดึงมาใช้ได้จริง

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

แนวทางที่ใช้กันแพร่หลายคือแบ่งตามโครงสร้างของเอกสารจริง เช่น แบ่งตามหัวข้อย่อยหรือย่อหน้าที่มีความหมายสมบูรณ์ในตัวเอง แทนที่จะตัดตามจำนวนตัวอักษรตายตัวโดยไม่สนใจโครงสร้าง และมักเพิ่มส่วนที่ซ้อนทับกัน (Overlap) เล็กน้อยระหว่างชิ้นที่ติดกัน เพื่อลดโอกาสที่ประโยคสำคัญจะถูกตัดขาดกลางคัน

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

RAG เทียบกับแนวทางอื่นที่แก้ปัญหาคล้ายกัน

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

จุดที่ระบบ RAG พังบ่อยในโปรเจกต์จริง

• ทำแบบนี้แล้วพัง เพราะใช้โมเดล Embedding คนละตัวกันระหว่างตอนนำเข้าเอกสารกับตอนค้นคืนคำถาม ทำให้เวกเตอร์ทั้งสองฝั่งอยู่คนละพื้นที่ทางคณิตศาสตร์ การค้นคืนจึงแทบไม่เจออะไรที่เกี่ยวข้องเลย
• ทำแบบนี้แล้วพัง เพราะไม่มีกลไกอัปเดตเอกสารเก่าที่ถูกยกเลิกไปแล้วออกจากฐานข้อมูล ระบบยังดึงนโยบายเวอร์ชันเก่ามาปนกับเวอร์ชันใหม่ ทำให้คำตอบขัดแย้งกันเอง
• ทำแบบนี้แล้วพัง เพราะตั้งจำนวนเอกสารที่ดึงมา (Top-K) น้อยเกินไปสำหรับคำถามที่ต้องอาศัยข้อมูลจากหลายส่วนประกอบกัน ทำให้คำตอบไม่ครบถ้วน
• ทำแบบนี้แล้วพัง เพราะไม่ตรวจสอบว่าโมเดลตอบตรงกับเอกสารที่ดึงมาจริงหรือไม่ ปล่อยให้โมเดลผสมความรู้เดิมของมันเข้ากับเอกสารที่ให้มา จนคำตอบมีทั้งส่วนที่ถูกและมโนปนกัน
• ทำแบบนี้แล้วพัง เพราะไม่มีชุดคำถามทดสอบเพื่อวัดคุณภาพก่อนขึ้นระบบจริง เห็นว่าตอบคำถามตัวอย่างไม่กี่ข้อได้ดีก็ปล่อยใช้งาน แล้วมาเจอปัญหาทีหลังตอนผู้ใช้ถามคำถามที่หลากหลายกว่านั้นมาก

เมื่อไรควรใช้ RAG และเมื่อไรยังไม่จำเป็น

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

ในทางกลับกัน ถ้าข้อมูลของคุณนิ่ง ไม่ค่อยเปลี่ยน และปริมาณไม่ใหญ่มาก การยัด Context ตรง ๆ หรือแม้แต่การ fine-tune อาจง่ายและคุ้มกว่าการลงทุนสร้างระบบ RAG ทั้งชุด ก่อนตัดสินใจทำ RAG จึงควรถามตัวเองก่อนว่าปัญหาที่แท้จริงคืออะไร ถ้าเป็นแค่ต้องการให้โมเดลตอบสั้นลงหรือมีสไตล์เฉพาะ นั่นเป็นปัญหาคนละแบบที่ RAG แก้ไม่ได้

สำหรับทีมที่ตัดสินใจแล้วว่าจะลงมือทำ ขั้นถัดไปคือการเลือก Vector Database ที่จะใช้เก็บข้อมูล และทำความเข้าใจ Embeddings ว่าทำงานอย่างไร เพราะสองส่วนนี้คือฐานรากที่กำหนดว่าระบบค้นคืนของคุณจะแม่นแค่ไหน ถ้าต้องการอ่านตัวอย่างการต่อระบบ RAG จริงบนโครงสร้างพื้นฐานที่ใช้กันแพร่หลาย ลองดูเพิ่มเติมที่ RAG บน Supabase ซึ่งอธิบายการเชื่อม pgvector เข้ากับ Edge Function แบบเป็นขั้นตอน

สรุป

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

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

• RAG แยกความรู้ออกจากตัวโมเดล ทำให้อัปเดตข้อมูลได้โดยไม่ต้องเทรนโมเดลใหม่
• Context Window ใหญ่ขึ้นไม่ได้แทนที่ RAG เพราะปัญหาคือต้นทุน ความสด และการอ้างอิงแหล่งที่มา
• คุณภาพการค้นคืนข้อมูลสำคัญกว่าการเลือกโมเดลภาษา ต้องดูแล Chunking และ Reranking ให้ดี
• ก่อนทำ RAG ควรถามก่อนว่าปัญหาจริงคืออะไร บางกรณี Fine-tuning หรือ Context ยาวอาจคุ้มกว่า

คำถามที่พบบ่อย