RAG (Retrieval-Augmented Generation) คือเทคนิคที่ทำให้ AI ตอบคำถามจากเอกสารของบริษัทคุณเอง ไม่ใช่ตอบจากความรู้ทั่วไปที่โมเดลเคยเรียนมาเท่านั้น ก่อนตอบทุกครั้ง ระบบจะค้นหาเนื้อหาที่เกี่ยวข้องจากคลังเอกสารแล้วส่งให้โมเดลอ่านประกอบ คำตอบจึงอิงกับนโยบาย คู่มือ และข้อมูลสินค้าจริงของคุณ และบอกได้ว่ามาจากเอกสารไหน
ทำไมเจ้าของธุรกิจถึงควรรู้จัก RAG
LLM อย่าง GPT หรือ Claude เขียนตอบได้ลื่นไหลเหมือนคน แต่ไม่มีทางรู้ว่าใบราคาล่าสุด ระเบียบการลา หรือ SOP ที่เพิ่งแก้เมื่อเดือนที่แล้วของบริษัทคุณเขียนไว้ว่าอะไร ถ้าถามไปตรงๆ ก็อาจได้คำตอบที่ฟังดูน่าเชื่อแต่ผิด ซึ่งในวงการเรียกกันว่า hallucination
RAG แก้ปัญหานี้ได้โดยไม่ต้องเทรนโมเดลใหม่ แค่นำเอกสารที่มีอยู่มาทำดัชนี แล้วให้โมเดลหยิบเฉพาะส่วนที่เกี่ยวข้องมาอ่านตอนที่มีคนถาม สำหรับ SME ไทยที่ความรู้ในองค์กรกระจายอยู่ตามไฟล์ PDF ไดรฟ์กลาง แชท LINE และในหัวของพนักงานรุ่นพี่ไม่กี่คน RAG ช่วยให้ทั้งพนักงานและลูกค้าถามข้อมูลเหล่านี้ได้ด้วยภาษาพูดธรรมดา จะถามเป็นภาษาไทยหรืออังกฤษก็ได้
RAG ทำงานอย่างไร อธิบายทีละขั้น
1. รวบรวมและคัดกรองเอกสาร
แหล่งข้อมูลอาจเป็น PDF ไฟล์ Word, Excel หน้าเว็บ ประวัติเคสลูกค้า หรือข้อมูลในฐานข้อมูล ส่วนเอกสารกระดาษที่สแกนเก็บไว้ต้องผ่าน OCR ก่อน ขั้นนี้สำคัญที่สุด เพราะถ้าเอกสารเก่าหรือขัดแย้งกันเอง AI ก็จะตอบแบบเก่าหรือขัดแย้งตามไปด้วย
2. หั่นเอกสารเป็นท่อน (Chunking)
เอกสารยาวๆ จะถูกแบ่งเป็นท่อนเล็กที่เรียกว่า chunk ท่อนละประมาณไม่กี่ร้อยคำ บางระบบให้แต่ละท่อนซ้อนทับกันเล็กน้อยเพื่อไม่ให้ประโยคขาดกลางทาง การแบ่งที่ดีควรยึดโครงสร้างของเอกสาร เช่น หัวข้อ ข้อกำหนด หรือแถวในตาราง มากกว่าตัดตามจำนวนตัวอักษรแบบตายตัว
3. แปลงความหมายเป็นตัวเลข (Embeddings)
แต่ละ chunk จะถูกแปลงด้วย embedding model ให้เป็นเวกเตอร์ หรือชุดตัวเลขที่แทน "ความหมาย" ของข้อความ ข้อความเรื่อง "สิทธิ์ลาพักร้อน" กับ "วันหยุดประจำปี" จึงอยู่ใกล้กัน แม้จะไม่มีคำไหนซ้ำกันเลย ถ้าเอกสารส่วนใหญ่เป็นภาษาไทย ควรเลือกโมเดลแบบ multilingual ที่รองรับภาษาไทยได้ดี และลองทดสอบกับเอกสารจริงของคุณก่อนตัดสินใจ
4. เก็บในฐานข้อมูลเวกเตอร์ (Vector Database)
เวกเตอร์ทั้งหมดจะถูกเก็บในฐานข้อมูลที่ค้นหาตามความคล้ายได้ เช่น PostgreSQL ที่ติดตั้งส่วนขยาย pgvector หรือระบบเฉพาะทางอย่าง Weaviate, Pinecone และ Chroma โดยเก็บ metadata อย่างแผนก วันที่ของเอกสาร และระดับสิทธิ์การเข้าถึงไว้คู่กัน เพื่อใช้กรองผลลัพธ์
5. ค้นหาเนื้อหาที่เกี่ยวข้อง (Retrieval)
เมื่อผู้ใช้พิมพ์คำถาม ระบบจะแปลงคำถามเป็นเวกเตอร์ด้วยวิธีเดียวกัน แล้วดึง chunk ที่ใกล้เคียงที่สุดออกมา ระบบที่ใช้งานจริงมักผสมการค้นหาเชิงความหมายเข้ากับการค้นหาด้วยคีย์เวิร์ด (hybrid search) และจัดอันดับผลลัพธ์ซ้ำอีกรอบ การค้นด้วยคีย์เวิร์ดช่วยได้มากกับรหัสสินค้า เลขที่ใบแจ้งหนี้ และภาษาไทยที่ไม่มีการเว้นวรรคระหว่างคำ
6. ให้ LLM เรียบเรียงคำตอบ (Generation)
chunk ที่ค้นเจอจะถูกส่งให้ LLM พร้อมคำถามและคำสั่ง เช่น "ตอบจากเอกสารที่ให้มาเท่านั้น ถ้าไม่พบคำตอบให้บอกตรงๆ" จากนั้นโมเดลจะเรียบเรียงคำตอบ และควรแนบลิงก์เอกสารต้นทางให้ผู้ใช้กดตรวจสอบได้
ตัวอย่างการใช้ RAG ในธุรกิจ
| การใช้งาน | ผู้ใช้หลัก | แหล่งข้อมูลที่มักใช้ |
|---|---|---|
| คลังความรู้ภายในองค์กร | พนักงาน พนักงานใหม่ | ระเบียบ HR, SOP, คู่มือไอที |
| ผู้ช่วยตอบคำถามลูกค้า | ลูกค้าบนเว็บไซต์หรือ LINE | FAQ คู่มือสินค้า นโยบายจัดส่งและคืนสินค้า |
| ถาม-ตอบจากเอกสาร | ฝ่ายขาย กฎหมาย จัดซื้อ | สัญญา TOR สเปกทางเทคนิค |
| ตัวช่วยฝ่ายขาย | ทีมขาย | ใบราคา ตารางเปรียบเทียบสินค้า เทมเพลตใบเสนอราคา |
| ข้อมูลหน้างาน | คลังสินค้า ช่างเทคนิค | คู่มือเครื่องจักร วิธีแก้ปัญหาเบื้องต้น |
ถ้าอยากให้ลูกค้าถามผ่านช่องทางที่ใช้อยู่ทุกวัน แนะนำให้อ่านต่อที่บทความ แชทบอท LINE สำหรับธุรกิจ
ข้อจำกัดของ RAG ที่ควรรู้ก่อนลงทุน
RAG มีประโยชน์มาก แต่ไม่ใช่เวทมนตร์ ควรวางแผนรับมือกับข้อจำกัดเหล่านี้
- ข้อมูลเข้าไม่ดี คำตอบก็ไม่ดี ถ้าเอกสารสองฉบับเขียนไม่ตรงกัน AI อาจหยิบฉบับไหนมาตอบก็ได้ ต้องมีคนรับผิดชอบดูแลเนื้อหา
- การค้นหาพลาดได้ ถ้าระบบดึง chunk ที่ถูกต้องมาไม่ได้ โมเดลก็ตอบไม่ได้ จึงต้องทดสอบด้วยคำถามจริงเสมอ
- ลด hallucination ได้ แต่ไม่หายขาด การสั่งให้ปฏิเสธเมื่อไม่มีข้อมูลและการแสดงแหล่งอ้างอิงช่วยได้มาก แต่คำตอบที่มีผลทางกฎหมาย การแพทย์ หรือการเงิน ยังควรมีคนตรวจ
- ไม่เก่งคำถามเชิงสรุปตัวเลข คำถามอย่าง "ยอดขายไตรมาสที่แล้วแยกตามภาคเป็นเท่าไร" เป็นงานของฐานข้อมูล ไม่ใช่การค้นเอกสาร ควรเชื่อม AI เข้ากับข้อมูลเชิงโครงสร้างหรือรายงานแทน
- มีค่าใช้จ่ายต่อเนื่อง ทุกคำถามใช้ token ของ LLM และทรัพยากรประมวลผล และต้องอัปเดตดัชนีทุกครั้งที่เอกสารเปลี่ยน
RAG ต่างจาก Fine-tuning อย่างไร
Fine-tuning คือการนำโมเดลที่มีอยู่มาเทรนต่อด้วยตัวอย่างของเราเอง เพื่อเปลี่ยนพฤติกรรมของโมเดล ทั้งสองวิธีแก้ปัญหาคนละแบบ
| RAG | Fine-tuning | |
|---|---|---|
| เหมาะกับ | ตอบจากข้อมูลที่เปลี่ยนบ่อย | สไตล์ รูปแบบ หรืองานเฉพาะทางที่ต้องสม่ำเสมอ |
| อัปเดตความรู้ | ทำดัชนีเอกสารใหม่ | ต้องเทรนโมเดลใหม่ |
| อ้างอิงแหล่งที่มา | ทำได้ตรงไปตรงมา | ทำได้ยาก |
| งานตั้งต้น | ปานกลาง | ต้องเตรียมชุดตัวอย่างสำหรับเทรนอย่างดี |
| ควบคุมสิทธิ์การเข้าถึง | กรองตามสิทธิ์ผู้ใช้ตอนค้นหาได้ | ยาก เพราะความรู้ฝังอยู่ในโมเดล |
สำหรับโจทย์ด้านความรู้ในองค์กรส่วนใหญ่ แนะนำให้เริ่มจาก RAG ก่อน ส่วน fine-tuning จะคุ้มค่าเมื่อต้องการรูปแบบคำตอบหรือโทนภาษาที่เฉพาะมากในปริมาณสูง และสามารถใช้ร่วมกับ RAG ภายหลังได้
ความปลอดภัยของข้อมูล และทางเลือกแบบ On-premise
คำถามแรกที่เจ้าของธุรกิจมักถามคือ "เอกสารของเราจะถูกส่งไปไหน" หลักการสำคัญมีดังนี้
- รู้ว่าข้อมูลไหลไปที่ใด ถ้าใช้ LLM ผ่าน API บนคลาวด์ chunk ที่ค้นเจอจะถูกส่งไปยังผู้ให้บริการทุกครั้งที่มีคำถาม ควรอ่านนโยบายการเก็บข้อมูลและการนำไปเทรน และเลือกเงื่อนไขแบบธุรกิจที่ไม่นำข้อมูลของเราไปเทรนโมเดล
- บังคับใช้สิทธิ์การเข้าถึง เก็บสิทธิ์ไว้กับทุก chunk และกรองตั้งแต่ขั้นค้นหา พนักงานขายจะได้ไม่เห็นเอกสารเงินเดือนเพียงเพราะตั้งคำถามถูกจุด
- ปฏิบัติตาม PDPA พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคลครอบคลุมข้อมูลส่วนบุคคลที่อยู่ในเอกสารด้วย ควรทำดัชนีเฉพาะที่จำเป็น ปิดบังข้อมูลส่วนบุคคลที่ไม่เกี่ยวข้อง และเก็บ log คำถาม-คำตอบไว้ตรวจสอบ
- ติดตั้งในองค์กรเองได้ ฐานข้อมูลเวกเตอร์ คลังเอกสาร และตัวแอปพลิเคชันรันบนเซิร์ฟเวอร์ของบริษัทหรือ private cloud ได้ ส่วนตัวโมเดลเลือกใช้ LLM แบบ open-weight ได้ รวมถึงโมเดลที่พัฒนาเพื่อภาษาไทยอย่าง Typhoon โดยรันบน GPU ของเราเอง แลกกับค่าโครงสร้างพื้นฐานและภาระดูแลที่สูงขึ้น และคุณภาพคำตอบที่มักด้อยกว่าโมเดลใหญ่บนคลาวด์อยู่บ้าง
ทางสายกลางที่นิยมคือ เก็บเอกสาร embeddings และ log ไว้ในโครงสร้างพื้นฐานของเราเอง แล้วส่งให้ LLM บนคลาวด์เฉพาะ chunk ไม่กี่ท่อนที่จำเป็นต่อการตอบแต่ละครั้ง
เริ่มโปรเจกต์ RAG อย่างไรให้คุ้ม
- เลือกโจทย์แคบๆ หนึ่งเรื่องที่มีเจ้าของชัดเจน เช่น คำถามเรื่องระเบียบ HR
- รวบรวมคำถามจริงที่คนถามบ่อยประมาณ 50–100 ข้อ พร้อมคำตอบที่ถูกต้อง ใช้เป็นชุดทดสอบ
- ทำความสะอาดเอกสารต้นทาง และเอาเวอร์ชันเก่าออก
- สร้างระบบต้นแบบ วัดความแม่นยำเทียบกับชุดทดสอบ แล้วปรับวิธี chunking และการค้นหา
- เปิดให้กลุ่มเล็กใช้ก่อน เก็บ feedback แล้วค่อยขยาย
Vectorkub พัฒนาระบบค้นหาแบบ RAG, ระบบ OCR และแชทบอท LINE ภายใต้บริการโซลูชัน AI โดยเริ่มต้นที่ 44,999 บาท ราคาจริงขึ้นอยู่กับความต้องการของแต่ละโปรเจกต์
คำถามที่พบบ่อย (FAQ)
ต้องมีข้อมูลเยอะแค่ไหนถึงจะใช้ RAG ได้?
ไม่ต้องเยอะ RAG ใช้ได้แม้มีเอกสารไม่กี่สิบหน้า ขอแค่เขียนชัดเจนและเป็นปัจจุบัน คุณภาพสำคัญกว่าปริมาณมาก
RAG ตอบเป็นภาษาไทยได้ไหม?
ได้ ถ้า embedding model และ LLM ที่เลือกรองรับภาษาไทยได้ดี ควรทดสอบด้วยคำถามภาษาไทยจริงจากทีมงาน และพิจารณาใช้ hybrid search เพราะภาษาไทยไม่เว้นวรรคระหว่างคำ
RAG กับ ChatGPT เหมือนกันไหม?
ไม่เหมือน ChatGPT เป็นผู้ช่วยอเนกประสงค์ ส่วน RAG เป็นสถาปัตยกรรมที่สร้างรอบ LLM ให้ตอบจากแหล่งข้อมูลของคุณ และทำตามกฎสิทธิ์การเข้าถึงขององค์กร
ทำระบบต้นแบบ RAG ใช้เวลานานแค่ไหน?
ขึ้นอยู่กับความพร้อมของเอกสารเป็นหลัก ระบบต้นแบบสำหรับความรู้เรื่องเดียวมักใช้เวลาเป็นหลักสัปดาห์มากกว่าหลักเดือน แต่ถ้าสิทธิ์การเข้าถึงซับซ้อนหรือมีเอกสารสแกนจำนวนมากก็จะใช้เวลานานขึ้น
ก้าวต่อไป
ถ้าทีมของคุณต้องตอบคำถามเดิมๆ จากกองเอกสารเดิมๆ ทุกวัน นั่นมักเป็นจุดเริ่มต้นที่ดีสำหรับ RAG เล่าโจทย์ของคุณให้เราฟัง แล้วเราจะช่วยวางขอบเขตระบบต้นแบบและรูปแบบการดูแลข้อมูลที่เหมาะกับธุรกิจของคุณ