RAG ใน production: สิ่งที่เดโมไม่เคยบอก

RAG ทำงานอย่างไรแบบสั้น ๆ

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

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

Chunking: แบ่งเอกสารให้ตรงกับวิธีที่คนถาม

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

ภาษาไทยมีข้อควรระวังเพิ่ม เพราะไม่มีช่องว่างระหว่างคำ ตัวตัดคำหรือ tokenizer ที่ไม่เหมาะจะทำให้การค้นแบบคีย์เวิร์ดพลาดได้ ควรลองค้นด้วยคำถามไทยจริง ๆ หลายแบบ รวมถึงคำสะกดผิดและคำที่ใช้ปนอังกฤษ เช่น "รีเฟรช token" แล้วดูว่าได้ชิ้นที่ต้องการหรือไม่

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

คุณภาพการค้นหา: เริ่มจาก hybrid search

การค้นด้วย embedding เข้าใจความหมายได้ดี แต่บางครั้งพลาดรหัสสินค้า เลขมาตรา หรือชื่อเฉพาะ ส่วนการค้นแบบคีย์เวิร์ดแม่นเรื่องคำตรงตัวแต่ไม่เข้าใจคำพ้องความหมาย การใช้ทั้งสองแบบร่วมกัน หรือ hybrid search มักให้ผลดีกว่าใช้แบบเดียวในงานจริง

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

การอ้างอิงแหล่งที่มา ทำให้ตรวจสอบได้

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

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

คำตอบที่ฟังดูมั่นใจแต่ไม่มีที่มา อันตรายกว่าคำว่า "ยังไม่พบข้อมูล"

วงจรการวัดผล: แยกวัดการค้นหากับการตอบ

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

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

ความล้มเหลวที่พบหลังเดโม

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

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