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 ข้อ

  1. ตัดชิ้นเอกสารตามจำนวนตัวอักษร ทำให้ตัดกลางตารางหรือกลางข้อกำหนด คำตอบจึงขาดเงื่อนไขสำคัญ ทางแก้คือตัดตามโครงสร้างและเก็บหัวข้อกำกับไว้
  2. ไม่มี metadata และตัวกรอง ระบบจึงค้นข้ามแผนกหรือข้ามเวอร์ชันเอกสาร ได้คำตอบที่ถูกแต่ใช้ไม่ได้ ทางแก้คือแนบสิทธิ์ วันที่ และสถานะเอกสาร แล้วกรองก่อนค้น
  3. วัดผลรวมทั้งระบบ ทำให้ไม่รู้ว่าควรแก้อะไร ทางแก้คือแยกชุดวัดการค้นและการตอบออกจากกัน
  4. ไม่มีทางออกเมื่อไม่พบข้อมูล โมเดลจึงเดาคำตอบ ทางแก้คือสอนให้ปฏิเสธ ส่งต่อให้คน และแสดงแหล่งอ้างอิงทุกครั้ง

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

RAG ต่างจากการปรับโมเดลด้วยข้อมูลองค์กรอย่างไร

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

ต้องมีเอกสารมากแค่ไหนจึงคุ้ม

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

ข้อมูลองค์กรจะรั่วออกไปข้างนอกไหม

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

ถ้าต้องการทดลอง RAG กับเอกสารชุดเล็กขององค์กรก่อนตัดสินใจลงทุน เล่าโจทย์และตัวอย่างเอกสารให้ทีมเราฟังได้ที่หน้า /contact/

เล่าปัญหาและข้อมูลที่มี เพื่อประเมินแนวทางพัฒนาที่เหมาะกับงาน

ปรึกษาโครงการ