ทำไม RAG ที่ทำงานดีตอนทดสอบ ถึงเริ่มตอบผิดเมื่อข้อมูลบริษัทเยอะขึ้น

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

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

บทความนี้จะพาไล่ดูสาเหตุที่แท้จริงของปัญหานี้ และวิธีออกแบบระบบให้ยังแม่นยำแม้ข้อมูลจะโตขึ้นมาก ต่อยอดจากหลักการพื้นฐานเรื่อง Vector Search ที่เคยอธิบายไว้ใน line-oa-ai-chatbot-supabase และเทคนิคการเชื่อมต่อกับ LINE OA ที่พูดถึงใน line-oa-ai-chatbot-cloudflare

ทำไมข้อมูลที่เยอะขึ้นถึงทำให้ความแม่นยำลดลง ทั้งที่ควรจะดีขึ้น

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

ปัญหานี้ชัดเจนมากในธุรกิจที่มีสินค้าหลายรุ่นหรือหลายเวอร์ชัน เช่น ร้านขายอุปกรณ์ที่มีสินค้ารุ่น A รุ่น B และรุ่น C ที่คล้ายกันมาก ถ้าคำอธิบายของแต่ละรุ่นเขียนคล้ายกันเกินไป Embedding ของทั้งสามรุ่นจะอยู่ใกล้กันมากในพื้นที่หลายมิติ ทำให้เมื่อลูกค้าถามถึงรุ่น A ระบบอาจดึงข้อมูลของรุ่น B มาตอบแทนโดยไม่รู้ตัว

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

ตรวจสอบคุณภาพข้อมูลก่อนโทษว่าโมเดลไม่ฉลาด

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

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

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

Reranking ช่วยจัดลำดับผลการค้นหาให้แม่นขึ้นอีกชั้น

Vector Search ทั่วไปจะคืนผลลัพธ์ที่ใกล้เคียงที่สุดตามระยะห่างของ Embedding แต่ระยะห่างทางคณิตศาสตร์ไม่ได้สะท้อนความเกี่ยวข้องที่แท้จริงเสมอไป โดยเฉพาะเมื่อมีผลลัพธ์หลายชิ้นที่ใกล้เคียงกันมาก เทคนิคที่ช่วยแก้ปัญหานี้คือการเพิ่มขั้นตอน Reranking หลังจากค้นหาผลลัพธ์เบื้องต้นมาแล้ว

หลักการของ Reranking คือดึงผลลัพธ์ที่ใกล้เคียงมาจำนวนหนึ่งก่อน เช่น 20 รายการ แล้วใช้โมเดลอีกตัวที่เชี่ยวชาญเฉพาะด้านการจัดอันดับความเกี่ยวข้อง มาประเมินใหม่ว่าแต่ละรายการเกี่ยวข้องกับคำถามจริงแค่ไหน แล้วเลือกเฉพาะรายการที่คะแนนสูงสุดจริงๆ มาใช้ประกอบ Prompt แทนที่จะใช้ผลลัพธ์ดิบจาก Vector Search ตรงๆ

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

ใช้ Metadata กรองผลลัพธ์ก่อนค้นหาแบบ Vector ช่วยลดความสับสน

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

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

การออกแบบ Metadata ที่ดีตั้งแต่ต้นช่วยให้ระบบขยายขนาดข้อมูลได้ง่ายขึ้นในระยะยาว เพราะไม่ต้องพึ่งความแม่นยำของ Vector Search เพียงอย่างเดียวในการแยกแยะข้อมูลที่คล้ายกัน แต่ใช้โครงสร้างข้อมูลที่ชัดเจนช่วยลดภาระของขั้นตอนค้นหาไปด้วย

กำจัดข้อมูลซ้ำซ้อนที่สะสมมาจากการอัปเดตหลายรอบ

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

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

การทำ Deduplication อาจทำได้ด้วยการเปรียบเทียบ Embedding ของ Chunk ต่างๆ ว่ามีคู่ไหนที่ใกล้เคียงกันมากผิดปกติ แล้วให้ทีมมาตรวจสอบว่าควรรวมเป็นชิ้นเดียวหรือลบชิ้นที่ล้าสมัยออก กระบวนการนี้ควรเป็นส่วนหนึ่งของการดูแลระบบตามรอบ ไม่ใช่ทำเฉพาะตอนที่เริ่มสังเกตเห็นปัญหาความแม่นยำลดลงแล้ว

สร้างชุดทดสอบมาตรฐานเพื่อวัดความแม่นยำอย่างต่อเนื่อง

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

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

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

สรุปเทคนิครักษาความแม่นยำเมื่อข้อมูลโตขึ้น

ตารางนี้สรุปเทคนิคหลักที่ช่วยรักษาความแม่นยำของ RAG เมื่อข้อมูลบริษัทเพิ่มขึ้นเรื่อยๆ พร้อมจุดที่แต่ละเทคนิคช่วยแก้:

สรุป

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

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

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

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