RAG คืออะไร? อธิบายแบบเห็นภาพ พร้อมสิ่งที่ต้องเตรียมถ้าจะทำเอง

อัปเดต 2026-08-22อ่าน ~10 นาที

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

RAG ย่อมาจาก Retrieval-Augmented Generation แปลตรงตัวคือ "การสร้างคำตอบโดยเสริมด้วยการค้นคืน" ฟังดูซับซ้อน แต่แนวคิดหลักเรียบง่ายมาก และบทความนี้จะอธิบายตั้งแต่ว่ามันคืออะไร ทำงานยังไงทีละขั้น ต่างจาก fine-tuning ตรงไหน มีข้อจำกัดอะไรบ้างที่ต้องรู้ก่อนตัดสินใจลงทุน และถ้าจะรันเองบนเซิร์ฟเวอร์ตัวเองต้องเตรียมอะไร

RAG คืออะไร

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

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

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

💡 สรุปสั้น: RAG = ค้นก่อน แล้วค่อยตอบ ตัวโมเดลไม่ได้ถูกแก้ ข้อมูลของคุณไม่ได้ถูกยัดเข้าไปในโมเดล แต่ถูกส่งให้มันอ่านเป็นครั้ง ๆ ตอนที่มีคนถามเข้ามา

ปัญหาที่ RAG เกิดมาแก้

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

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

ข้อที่สองหนักกว่า คือเมื่อโมเดลไม่รู้ มันมักไม่บอกว่าไม่รู้ แต่จะเรียบเรียงคำตอบที่ฟังดูน่าเชื่อถือออกมาแทน อาการนี้เรียกกันว่า hallucination หรือการมั่ว ปัญหาคือคำตอบที่มั่วมักอ่านลื่นและมั่นใจพอ ๆ กับคำตอบที่ถูก คนอ่านจึงแยกไม่ออกถ้าไม่รู้เรื่องนั้นมาก่อน

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

💡 ข้อดีที่คนมักมองข้าม: RAG ทำให้ระบบ "อ้างอิงแหล่งที่มา" ได้ ซึ่งสำคัญกว่าความลื่นของคำตอบมากในงานที่ตอบผิดแล้วมีต้นทุน เพราะคนอ่านเปิดเอกสารต้นทางตรวจซ้ำเองได้

RAG ทำงานยังไง ทีละขั้น

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

1แบ่งเอกสารเป็นชิ้น (chunking) — เอาไฟล์ทั้งหมดมาตัดเป็นท่อนย่อยขนาดพอเหมาะ เพราะเอกสารทั้งเล่มยาวเกินกว่าจะส่งให้โมเดลอ่านทีเดียว และการค้นทีละท่อนแม่นกว่าค้นทั้งเล่ม
2แปลงแต่ละชิ้นเป็นเวกเตอร์ (embedding) — ส่งข้อความแต่ละท่อนเข้าโมเดล embedding เพื่อแปลงเป็นชุดตัวเลขที่สะท้อนความหมายของท่อนนั้น ท่อนที่พูดเรื่องใกล้กันจะได้ตัวเลขที่ใกล้กัน
3เก็บลง vector database — บันทึกเวกเตอร์พร้อมข้อความต้นฉบับและข้อมูลกำกับ เช่น ชื่อไฟล์ เลขหน้า วันที่ ลงในฐานข้อมูลที่ค้นแบบใกล้เคียงความหมายได้
4ผู้ใช้ถามคำถามเข้ามา — คำถามจะถูกแปลงเป็นเวกเตอร์ด้วยโมเดล embedding ตัวเดียวกับที่ใช้ตอนเตรียมข้อมูล ตรงนี้ต้องเป็นตัวเดียวกันเสมอ ไม่งั้นตัวเลขจะเทียบกันไม่ได้
5ค้นชิ้นที่เกี่ยวข้องที่สุด — ระบบเทียบเวกเตอร์คำถามกับเวกเตอร์ทั้งหมดในฐานข้อมูล แล้วดึงท่อนที่ใกล้เคียงที่สุดออกมาไม่กี่ท่อน โดยทั่วไปประมาณ 3-10 ท่อน แล้วแต่การตั้งค่า
6ส่งให้โมเดลตอบพร้อมอ้างอิง — นำท่อนที่ได้ไปประกอบกับคำถามเป็นคำสั่งเดียว ส่งเข้าโมเดลภาษา พร้อมกำชับให้ตอบจากข้อความที่ให้มาเท่านั้นและระบุแหล่งที่มา จากนั้นส่งคำตอบกลับไปให้ผู้ใช้

💡 ขั้นที่ 1 ถึง 3 คือช่วงเตรียมข้อมูล ทำล่วงหน้าและทำซ้ำเมื่อเอกสารเปลี่ยน ส่วนขั้นที่ 4 ถึง 6 เกิดขึ้นสด ๆ ทุกครั้งที่มีคำถาม ดังนั้นความเร็วที่ผู้ใช้รู้สึกได้จะขึ้นกับขั้นที่ 5 และ 6 เป็นหลัก

ส่วนประกอบที่ต้องมี

ระบบ RAG หนึ่งชุดไม่ได้มีแค่โมเดลตัวเดียว แต่ประกอบด้วยชิ้นส่วนหลายอย่างที่ต้องต่อกัน ตารางด้านล่างสรุปว่าแต่ละชิ้นทำหน้าที่อะไรและคนนิยมใช้อะไรกัน โดยเฉพาะชิ้นที่สาม คือ vector database ซึ่งเป็นหัวใจของฝั่งค้นหาและมีรายละเอียดเยอะพอจะแยกอ่านต่างหาก

ส่วนประกอบ	หน้าที่	ตัวเลือกที่พบบ่อย
ตัวโหลดและตัดเอกสาร	อ่านไฟล์ PDF, Word, เว็บเพจ หรือฐานข้อมูล แล้วแปลงเป็นข้อความและตัดเป็นท่อน	ไลบรารีสำเร็จรูปฝั่ง Python หรือ JavaScript ที่ทำ ETL เอกสารโดยเฉพาะ
โมเดล embedding	แปลงข้อความเป็นเวกเตอร์ที่สะท้อนความหมาย ใช้ทั้งตอนเตรียมข้อมูลและตอนรับคำถาม	เรียกผ่าน API ของผู้ให้บริการ หรือรันโมเดลโอเพนซอร์สเองบนเครื่อง
Vector database	เก็บเวกเตอร์และค้นหาท่อนที่ใกล้เคียงความหมายกับคำถามได้เร็ว	pgvector บน PostgreSQL, Qdrant, Milvus, Weaviate, Chroma
โมเดลภาษา (LLM)	อ่านท่อนที่ค้นมาได้แล้วเรียบเรียงเป็นคำตอบภาษามนุษย์	เรียกผ่าน API ของผู้ให้บริการ หรือรันโมเดลเองผ่านเครื่องมืออย่าง Ollama
ตัวประสานงาน (orchestration)	ร้อยทุกขั้นเข้าด้วยกัน จัดการคำสั่ง จัดการประวัติแชต และจัดการข้อผิดพลาด	เขียนโค้ดเอง ใช้เฟรมเวิร์กสำเร็จรูป หรือใช้เครื่องมือ workflow แบบ n8n
ส่วนติดต่อผู้ใช้	หน้าเว็บแชต ปุ่มในระบบหลังบ้าน หรือบอตในแอปแชตที่ทีมใช้อยู่	เว็บแอปของตัวเอง หรือเชื่อมเข้าแอปแชตที่ใช้อยู่แล้ว

💡 ไม่จำเป็นต้องรันเองทุกชิ้น หลายทีมเริ่มด้วยการเรียก embedding และ LLM ผ่าน API ของผู้ให้บริการ แล้วรันเฉพาะ vector database กับตัวประสานงานไว้บนเซิร์ฟเวอร์ของตัวเอง ซึ่งเป็นสูตรที่เริ่มง่ายและควบคุมค่าใช้จ่ายได้

RAG กับ fine-tuning ต่างกันยังไง เลือกอะไร

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

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

หัวข้อ	RAG	Fine-tuning
แก้ปัญหาอะไร	โมเดลไม่รู้ข้อมูลเฉพาะของเรา	โมเดลตอบไม่ตรงรูปแบบหรือน้ำเสียงที่ต้องการ
ตัวโมเดลถูกแก้ไหม	ไม่ ข้อมูลถูกส่งให้อ่านตอนถาม	ใช่ น้ำหนักในโมเดลถูกปรับ
อัปเดตข้อมูลใหม่	เพิ่มเอกสารเข้าฐานข้อมูล มีผลทันที	ต้องเตรียมชุดข้อมูลและฝึกรอบใหม่
อ้างอิงแหล่งที่มาได้ไหม	ได้ เพราะรู้ว่าดึงท่อนไหนมาตอบ	ไม่ได้โดยตรง
ทรัพยากรที่ต้องใช้	เน้นแรมและพื้นที่เก็บดัชนี	ต้องใช้ GPU ในการฝึก
เหมาะกับ	ฐานความรู้ คู่มือ เอกสารที่เปลี่ยนบ่อย	รูปแบบคำตอบเฉพาะทาง สำนวนเฉพาะแบรนด์

💡 ข้อผิดพลาดที่พบบ่อยคือลงทุน fine-tuning เพื่อ "สอนข้อมูลบริษัทให้โมเดลจำ" ซึ่งเป็นวิธีที่แพงกว่า อัปเดตยากกว่า และตรวจสอบย้อนกลับไม่ได้ เทียบกับการทำ RAG ที่แก้ข้อมูลได้ด้วยการแก้เอกสารต้นทาง

ข้อจำกัดที่ต้องรู้ก่อนตัดสินใจ

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

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

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

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

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

จะรันเองบน VPS ต้องเตรียมอะไร

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

ถ้าคุณเรียกโมเดล embedding และโมเดลภาษาผ่าน API ของผู้ให้บริการ งานหนักทั้งหมดเกิดขึ้นที่ฝั่งเขา เซิร์ฟเวอร์ของคุณทำแค่ตัดเอกสาร เก็บดัชนีเวกเตอร์ ค้นหา และประสานงาน ซึ่งไม่ต้องแรงมาก แรมส่วนใหญ่จะหมดไปกับดัชนีของ vector database ตามจำนวนเอกสารที่คุณมี

แต่ถ้าคุณจะรันโมเดลเองบนเครื่องเพื่อไม่ให้ข้อความออกนอกองค์กร ต้องเข้าใจตรงกันก่อนว่าแพ็กเกจ VPS ของ Plusweb ทุกตัวไม่มี GPU การประมวลผลจะเกิดบน CPU ล้วน ซึ่งช้ากว่าเครื่องที่มีการ์ดจอสำหรับงาน AI อย่างมีนัยสำคัญ ในทางปฏิบัติ การรันโมเดล embedding ขนาดเล็กบน CPU ยังพอไหวสำหรับงานเป็นชุดที่ไม่รีบ แต่การรันโมเดลภาษาไว้ตอบแชตสด ๆ ให้ผู้ใช้หลายคนพร้อมกันบนเครื่องที่ไม่มี GPU จะช้าจนไม่เหมาะกับงานหน้าบ้าน ตารางด้านล่างคือแพ็กเกจ VPS ของ Plusweb ทุกตัวมีสิทธิ์ root เต็มและ 1 Public IPv4 ในตัว โดยตัวเลขในวงเล็บคือราคาต่อเดือนเมื่อชำระรายปี

แพ็กเกจ	CPU	RAM	SSD	ราคา/เดือน (รายปี)
VPS-01	1 vCore	3 GB	30 GB	250฿ (200฿)
VPS-02	2 vCores	4 GB	60 GB	350฿ (280฿)
VPS-03	4 vCores	8 GB	100 GB	600฿ (480฿)
VPS-04	5 vCores	10 GB	140 GB	1,000฿ (800฿)
VPS-06	8 vCores	16 GB	220 GB	1,600฿ (1,280฿)

💡 แนวทางเลือกคร่าว ๆ: ถ้าเรียกโมเดลผ่าน API และมีเอกสารไม่มาก VPS-01 หรือ VPS-02 พอเริ่มได้ ถ้าเอกสารเยอะขึ้นจนดัชนีกินแรม ให้ขยับไป VPS-03 ขึ้นไป และถ้าจะรันโมเดล embedding เองบนเครื่องด้วย ควรเริ่มที่ VPS-03 เป็นอย่างน้อย ทุกแพ็กเกจมี 1 Public IPv4 และสิทธิ์ root เต็ม

สรุป

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

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

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

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

อยากลองทำ RAG บนเซิร์ฟเวอร์ของตัวเอง?

VPS ของ Plusweb มีสิทธิ์ root เต็มและ Public IPv4 ในตัว ลง Docker แล้วรัน vector database ได้ทันที (หมายเหตุ: ทุกแพ็กเกจไม่มี GPU)

ดูแพ็กเกจ VPS สั่งซื้อทันที

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

RAG คืออะไรแบบสั้นที่สุด?

RAG ย่อจาก Retrieval-Augmented Generation คือวิธีทำให้โมเดลภาษาไปค้นข้อมูลของเราก่อนแล้วค่อยตอบ แทนที่จะตอบจากความจำที่เรียนรู้มาตอนฝึกอย่างเดียว ระบบจะดึงข้อความส่วนที่เกี่ยวข้องจากเอกสารของเราขึ้นมาส่งไปพร้อมคำถาม ให้โมเดลอ่านแล้วเรียบเรียงคำตอบพร้อมระบุแหล่งที่มาได้

RAG ทำให้ AI ไม่มั่วเลยใช่ไหม?

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

RAG กับ fine-tuning ควรเลือกอันไหน?

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

ทำ RAG ต้องมี vector database เสมอไหม?

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

รัน RAG บน VPS ที่ไม่มี GPU ได้ไหม?

ได้ ถ้าคุณเรียกโมเดล embedding และโมเดลภาษาผ่าน API ของผู้ให้บริการ เพราะงานหนักเกิดที่ฝั่งผู้ให้บริการ เซิร์ฟเวอร์ของคุณทำแค่เก็บดัชนี ค้นหา และประสานงาน แต่ถ้าจะรันโมเดลเองบนเครื่อง แพ็กเกจ VPS ของ Plusweb ทุกตัวไม่มี GPU การประมวลผลจะอยู่บน CPU ล้วนซึ่งช้ากว่ามาก เหมาะกับงานเบื้องหลังมากกว่าแชตสดที่มีผู้ใช้พร้อมกันหลายคน

ควรเริ่มที่แพ็กเกจไหน?

ถ้าเรียกโมเดลผ่าน API และมีเอกสารไม่มาก เริ่มที่ VPS-01 (1 vCore / 3 GB / 30 GB) 250฿ ต่อเดือน หรือ VPS-02 (2 vCores / 4 GB / 60 GB) 350฿ ต่อเดือนก็พอ เมื่อเอกสารเยอะขึ้นจนดัชนีเวกเตอร์กินแรมมากขึ้น ค่อยขยับไป VPS-03 (4 vCores / 8 GB / 100 GB) 600฿ ต่อเดือน ซึ่งเป็นจุดเริ่มที่ควรเลือกถ้าจะรันโมเดล embedding เองด้วย

GUIDES