เวลาใช้ AI ถามเรื่องคู่มือภายในหรือเงื่อนไขที่เพิ่งเปลี่ยน เราอาจต้องให้ข้อมูลเพิ่ม เพราะคำถามเพียงอย่างเดียวไม่ได้ทำให้โมเดลเห็นเอกสารของเรา RAG เป็นวิธีเชื่อมการค้นข้อมูลกับการสร้างคำตอบ เพื่อให้ AI มีเนื้อหาที่เกี่ยวข้องประกอบการตอบ
RAG ย่อมาจากอะไร
RAG ย่อจาก Retrieval-Augmented Generation โดย retrieval หมายถึงการดึงข้อมูลที่เกี่ยวข้อง และ generation คือการสร้างคำตอบ คำอธิบายของ Google Cloud กล่าวถึงการนำข้อมูลจากแหล่งภายนอก เช่น เอกสารหรือฐานข้อมูล มาเป็นบริบทให้โมเดลภาษา
จุดสำคัญคือข้อมูลที่นำมาตอบควรตรงกับคำถามและเป็นรุ่นที่เหมาะกับงาน การเชื่อมระบบค้นหาไม่ได้ทำให้เอกสารทุกชิ้นถูกต้องหรือทันสมัยโดยอัตโนมัติ
ลองนึกถึงคู่มือร้านค้าหนึ่งชุด
สมมติร้านมีคู่มือการรับคืนสินค้า และลูกค้าถามว่า “สินค้าลดราคาคืนได้ไหม” ระบบอาจค้นหัวข้อการรับคืนกับข้อยกเว้นของสินค้าลดราคา แล้วส่งสองส่วนนั้นให้โมเดลเขียนคำตอบที่อ่านง่าย ตัวอย่างร้านนี้สร้างขึ้นเพื่ออธิบายแนวคิด ไม่ใช่นโยบายจริงของธุรกิจใด
ถ้าค้นเจอเฉพาะข้อความว่า “คืนภายใน 7 วัน” แต่ไม่พบข้อยกเว้น คำตอบอาจดูชัดแต่ขาดเงื่อนไข แม้โมเดลจะใช้ข้อมูลที่ส่งมาอย่างตรงไปตรงมาก็ตาม ปัญหาจึงเกิดได้ตั้งแต่ก่อนเริ่มเขียนคำตอบ
เส้นทางจากคำถามถึงคำตอบ
| ขั้นตอน | หน้าที่ | สิ่งที่ควรตรวจ |
|---|---|---|
| รับคำถาม | ระบุสิ่งที่ผู้ใช้ต้องการรู้ | ถามถึงสินค้าและช่วงเวลาใด |
| ค้นข้อมูล | เลือกเอกสารหรือข้อความเกี่ยวข้อง | พบข้อยกเว้นและรุ่นล่าสุดหรือไม่ |
| ให้บริบท | ส่งข้อความที่เลือกให้โมเดล | มีชื่อเอกสารและตำแหน่งอ้างอิงไหม |
| สร้างคำตอบ | เรียบเรียงข้อมูลเพื่อผู้ถาม | เพิ่มข้อสรุปเกินหลักฐานหรือไม่ |
| แสดงผล | ให้ผู้ใช้เปิดตรวจแหล่งที่มา | ลิงก์นำไปยังข้อมูลที่กล่าวถึงจริงไหม |
ตารางนี้เป็นแบบจำลองสำหรับทำความเข้าใจ ระบบจริงอาจมีขั้นตอนเพิ่มเติม เช่น การกรองสิทธิ์ การค้นซ้ำ หรือการตรวจคำตอบก่อนแสดง
มีลิงก์อ้างอิงแล้ว ยังต้องตรวจอะไร
ลิงก์ช่วยให้ตรวจต่อได้ แต่ควรเปิดอ่านส่วนที่รองรับข้อสรุปด้วย เอกสารที่มีชื่อเหมือนคำถามอาจกล่าวถึงคนละเงื่อนไข หรืออ้างข้อมูลเก่าที่ถูกแทนที่แล้ว
Microsoft แยกการประเมิน RAG ระหว่างคุณภาพของข้อมูลที่ค้นมา กับคุณภาพของคำตอบสุดท้าย การแยกสองส่วนนี้ช่วยหาสาเหตุเมื่อคำตอบผิด เช่น ค้นไม่พบเนื้อหาจำเป็น หรือพบแล้วแต่สรุปไม่ครบ
สำหรับผู้ใช้งาน ลองตรวจสามข้อ คือแหล่งนี้ตรงคำถามหรือไม่ คำตอบมีหลักฐานรองรับหรือไม่ และมีข้อสำคัญที่ไม่ได้กล่าวถึงหรือไม่ อย่าใช้เพียงความลื่นไหลของภาษาเป็นเกณฑ์ตัดสิน
RAG ไม่ใช่การฝึกโมเดลใหม่ทุกครั้ง
การส่งเอกสารมาเป็นบริบทระหว่างตอบ กับการปรับโมเดลด้วยการฝึก เป็นคนละขั้นตอนในแนวคิดนี้ จึงไม่ควรสรุปว่าระบบจำเนื้อหาถาวรเพียงเพราะตอบจากเอกสารได้ การเก็บข้อมูลจริงขึ้นอยู่กับการออกแบบระบบและข้อกำหนดของบริการที่ใช้
ถ้าผู้พัฒนาบอกว่าระบบเข้าถึงเอกสารภายในได้ ควรถามต่อว่าค้นจากชุดใด อัปเดตเมื่อไร และผู้ใช้เห็นได้เฉพาะข้อมูลที่มีสิทธิ์หรือไม่ คำตอบเหล่านี้มีประโยชน์กว่าการทราบเพียงชื่อเทคนิค
คำถามเล็ก ๆ ที่ใช้ลองระบบได้
สร้างชุดคำถามจากเอกสารที่ตรวจเองได้ เช่น คำถามที่มีคำตอบตรง ๆ คำถามที่มีข้อยกเว้น และคำถามที่ไม่มีข้อมูลในชุดเอกสาร จดคำตอบที่คาดหวังพร้อมตำแหน่งต้นทาง แล้วดูว่าระบบรู้จักบอกว่าไม่พบข้อมูลหรือยังแต่งรายละเอียดเพิ่ม
แบบฝึกนี้ช่วยให้เห็นพฤติกรรมกับข้อมูลของเราโดยไม่ต้องเริ่มจากโครงการใหญ่ หากเอกสารต้นทางเปลี่ยน ควรตรวจคำถามเดิมอีกครั้ง เพราะคุณภาพของคำตอบผูกกับทั้งข้อมูล ขั้นค้นหา และการเรียบเรียง
ตรวจแหล่งข้อมูลวันที่ 8 ตุลาคม 2569 บทความนี้อธิบายหลักการทั่วไป ไม่ได้รายงานผลทดสอบผลิตภัณฑ์หรือรับรองว่าระบบ RAG ใดจะตอบถูกทุกครั้ง