RAG คืออะไร: ให้ AI ตอบจากเอกสารองค์กร
เข้าใจการค้นเอกสาร การสร้างคำตอบ สิทธิ์เข้าถึง และวิธีวัดผล RAG ก่อนใช้งานจริง
RAG คืออะไร
RAG (Retrieval-Augmented Generation) คือวิธีให้โมเดลภาษาตอบคำถามโดยค้นเอกสารที่เกี่ยวข้องก่อน แล้วจึงเรียบเรียงคำตอบจากเอกสารนั้น วิธีนี้ทำให้คำตอบอ้างอิงข้อมูลขององค์กรได้ และตรวจสอบที่มาของแต่ละคำตอบได้
หลักการทำงานสองท่อน
RAG แยกเป็นสองงานที่ไม่เหมือนกัน และควรวัดผลแยกกันด้วย ท่อนแรกคือ retrieval ทำหน้าที่หาข้อความที่เกี่ยวข้องกับคำถาม ท่อนที่สองคือ generation ทำหน้าที่เรียบเรียงคำตอบจากข้อความที่พบ
ในท่อน retrieval ระบบจะแปลงคำถามเป็นเวกเตอร์ แล้วค้นชิ้นเอกสารที่ใกล้เคียงที่สุด ระบบที่ทำจริงมักผสานการค้นแบบความหมายเข้ากับการค้นด้วยคำสำคัญ เพราะคำเฉพาะ เช่น ชื่อแบบฟอร์มหรือเลขมาตรา มักหากี่ครั้งก็ไม่เจอถ้าพึ่งความหมายเพียงอย่างเดียว
ในท่อน generation โมเดลจะได้รับคำถามพร้อมข้อความที่ค้นมา และถูกกำกับให้ตอบจากข้อความนั้นเท่านั้น พร้อมอ้างอิงแหล่งที่มา ถ้าค้นแล้วไม่พบข้อมูลที่ตอบได้ ระบบต้องบอกว่าไม่พบและเสนอทางต่อ ไม่ใช่เดาคำตอบขึ้นมาเอง
chunking และ embedding คือจุดที่คุณภาพตัดสิน
chunking คือการแบ่งเอกสารเป็นชิ้นเล็ก ๆ ก่อนเก็บเข้าฐานค้นหา ขนาดและขอบเขตของชิ้นมีผลตรงต่อคุณภาพคำตอบ ชิ้นใหญ่เกินไปจะทำให้บริบทเจือจางและเปลืองพื้นที่ของโมเดล ชิ้นเล็กเกินไปจะทำให้ข้อความขาดใจความ
วิธีที่ได้ผลกว่าการตัดตามจำนวนตัวอักษรคือตัดตามโครงสร้างเอกสาร เช่น ตามหัวข้อ ข้อกำหนด หรือตาราง แล้วเก็บหัวข้อแม่ไว้กับชิ้นลูก เพื่อให้ผลการค้นยังมีบริบทครบพอจะตอบได้
embedding คือการแปลงข้อความเป็นเวกเตอร์เพื่อเทียบความใกล้เคียง ต้องเลือกโมเดลให้ตรงกับภาษาที่ใช้จริง ทั้งไทย อังกฤษ หรือข้อความผสม และต้องทดสอบกับศัพท์เฉพาะขององค์กร เพราะคำย่อ ชื่อระบบภายใน และสำนวนราชการคือจุดที่โมเดลทั่วไปพลาดบ่อย
evaluation ก่อนขึ้นระบบจริง
ปัญหาที่พบบ่อยคือทีมวัดผลรวมทั้งระบบแล้วรู้แค่ "ตอบไม่ดี" แต่ไม่รู้ว่าพลาดที่การค้นหรือการเรียบเรียง วิธีที่ตรงกว่าคือสร้างชุดคำถามจากผู้ใช้จริงพร้อมคำตอบอ้างอิง แล้ววัดสองชั้นแยกกัน
ชั้นแรกวัดว่าการค้นหยิบเอกสารที่ถูกต้องมาหรือไม่ ชั้นที่สองวัดว่าคำตอบตรงกับเอกสาร ครบประเด็น และอ้างอิงถูกตำแหน่งหรือไม่ อีกตัวชี้วัดที่สำคัญคือระบบรู้จักปฏิเสธเมื่อไม่มีข้อมูลหรือไม่ เพราะคำตอบที่แต่งขึ้นเองคือความเสี่ยงที่ใหญ่ที่สุดของงานลักษณะนี้
ควรมีคนจากฝั่งธุรกิจร่วมให้คำตัดสิน ไม่ใช่ให้ทีมวิศวกรตัดสินเองทั้งหมด เพราะ "คำตอบที่ดี" ในที่นี้หมายถึงคำตอบที่ผู้ใช้ทำงานต่อได้ ไม่ใช่คำตอบที่อ่านลื่น
งานแบบไหนควรและไม่ควรใช้ RAG
เกณฑ์ตัดสินง่าย ๆ มีสองข้อ คือคำตอบต้องมาจากเอกสารที่อ้างอิงได้หรือไม่ และข้อมูลนั้นเปลี่ยนบ่อยแค่ไหน ตารางนี้เทียบงานที่พบบ่อยในองค์กรกับทางเลือกที่เหมาะสม
| ประเภทงาน | เหมาะกับ RAG ไหม | เหตุผลและทางเลือก | |---|---|---| | ตอบคำถามจากคู่มือ นโยบาย หรือระเบียบภายใน | เหมาะ | เอกสารชัดเจน มีที่มาให้อ้าง และอัปเดตได้โดยไม่ต้องฝึกโมเดลใหม่ | | ค้นและสรุปเงื่อนไขในสัญญา | เหมาะ แต่ต้องมีคนตรวจ | ต้องอ้างหน้าและข้อ ควรมีขั้นยืนยันก่อนนำไปใช้ | | สรุปยอดขายหรือตัวเลขจากฐานข้อมูล | ไม่เหมาะถ้าใช้ลำพัง | ควรต่อกับ SQL หรือเครื่องมือดึงข้อมูลจริง เพื่อไม่ให้โมเดลเดาตัวเลข | | จัดหมวดหมู่และสกัดฟิลด์จากเอกสาร | ไม่ใช่หน้าที่ของ RAG | ใช้ classification หรือ extraction โดยตรงแม่นกว่าและวัดผลง่ายกว่า | | ผู้ช่วยตอบลูกค้าตามสถานะคำสั่งซื้อ | เหมาะเมื่อต่อกับระบบจริง | คำตอบต้องสด ต้องดึงจากฐานข้อมูล ไม่ใช่จากเอกสารเก่า | | เขียนเนื้อหาสร้างสรรค์หรือภาพประกอบ | ไม่จำเป็น | ใช้ความสามารถของโมเดลโดยตรง ต้นทุนต่ำกว่าและเร็วกว่า |
ข้อผิดพลาดที่พบบ่อย 4 ข้อ
- ตัดชิ้นเอกสารตามจำนวนตัวอักษร ทำให้ตัดกลางตารางหรือกลางข้อกำหนด คำตอบจึงขาดเงื่อนไขสำคัญ ทางแก้คือตัดตามโครงสร้างและเก็บหัวข้อกำกับไว้
- ไม่มี metadata และตัวกรอง ระบบจึงค้นข้ามแผนกหรือข้ามเวอร์ชันเอกสาร ได้คำตอบที่ถูกแต่ใช้ไม่ได้ ทางแก้คือแนบสิทธิ์ วันที่ และสถานะเอกสาร แล้วกรองก่อนค้น
- วัดผลรวมทั้งระบบ ทำให้ไม่รู้ว่าควรแก้อะไร ทางแก้คือแยกชุดวัดการค้นและการตอบออกจากกัน
- ไม่มีทางออกเมื่อไม่พบข้อมูล โมเดลจึงเดาคำตอบ ทางแก้คือสอนให้ปฏิเสธ ส่งต่อให้คน และแสดงแหล่งอ้างอิงทุกครั้ง
คำถามที่พบบ่อย
RAG ต่างจากการปรับโมเดลด้วยข้อมูลองค์กรอย่างไร
RAG ไม่เปลี่ยนน้ำหนักของโมเดล แต่เพิ่มข้อมูลภายนอกเข้ามาตอนตอบ จึงอัปเดตเนื้อหาได้ทันทีเมื่อเอกสารเปลี่ยน ส่วนการปรับโมเดลเหมาะเมื่อต้องการปรับรูปแบบการตอบหรือโทนภาษา หลายระบบใช้ทั้งสองวิธีร่วมกัน
ต้องมีเอกสารมากแค่ไหนจึงคุ้ม
ไม่ขึ้นกับจำนวนเป็นหลัก แต่ขึ้นกับว่ามีเอกสารที่ตอบคำถามสำคัญได้ครบหรือไม่ เอกสารห้าสิบฉบับที่มีคุณภาพและมีโครงสร้างชัด มักให้ผลดีกว่าเอกสารหลายพันฉบับที่ซ้ำกันและไม่มีวันที่กำกับ
ข้อมูลองค์กรจะรั่วออกไปข้างนอกไหม
ขึ้นกับสถาปัตยกรรมที่เลือก ถ้าใช้โมเดลผ่านผู้ให้บริการภายนอก ข้อความที่ส่งไปจะออกนอกองค์กร ระบบที่ต้องการความเป็นส่วนตัวสูงจึงควรเลือกแนวทางที่เก็บข้อมูลและโมเดลไว้ในพื้นที่ควบคุมขององค์กร
ถ้าต้องการทดลอง RAG กับเอกสารชุดเล็กขององค์กรก่อนตัดสินใจลงทุน เล่าโจทย์และตัวอย่างเอกสารให้ทีมเราฟังได้ที่หน้า /contact/
เล่าปัญหาและข้อมูลที่มี เพื่อประเมินแนวทางพัฒนาที่เหมาะกับงาน
ปรึกษาโครงการ