BGE-Reranker ตัดทอนข้อความที่ 512 โทเค็น: 31% ของชังค์ข้อมูลถูกตัดหาย
นักพัฒนาพบปัญหา BGE-Reranker ตัดข้อความทิ้งหลัง 512 โทเค็น ทำชังค์ข้อมูลที่มีวิธีแก้ปัญหาสำคัญหลุดรอดจากระบบ RAG พร้อมแนวทางแก้ไข
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- BGE-Reranker ตัดข้อความที่ 512 โทเค็น ทำให้ 31% ของชังค์ข้อมูลถูกตัดส่วนท้ายออก
- คำสั่งแก้ปัญหาที่อยู่ท้ายเอกสาร Runbook หายไป ส่งผลให้ระบบ RAG ตอบคำถามผิดพลาด
- โครงสร้าง Cross-Encoder นำ Query และ Passage มาต่อกัน ทำให้ความยาวเกินขีดจำกัด
- แนวทางแก้ทำได้โดยปรับขนาดชังค์ตามตัวตัดคำของ Reranker หรือใช้ระบบ MaxP Scoring
ท่อส่งข้อมูล RAG ของนักพัฒนาท่านหนึ่งเกิดความผิดพลาดในการตอบคำถามเกี่ยวกับการแก้ไขปัญหาการแจ้งเตือน Replication Lag บนฐานข้อมูลคำสั่งซื้อ โดยคำตอบที่ถูกต้องอยู่ในคู่มือการดำเนินงาน (Runbooks) ซึ่งระบบค้นหาข้อมูล (Retrieval) สามารถดึงชังค์ที่ถูกต้องมาได้ในอันดับที่ 3 แต่เมื่อผ่านกระบวนการจัดอันดับใหม่ (Reranker) กลับถูกดันลงไปอยู่อันดับที่ 14 จนถูกคัดออกเนื่องจากตั้งค่าตัดที่ 5 อันดับแรก ทำให้โมเดลภาษาขนาดใหญ่ (LLM) ตอบคำถามผิดพลาดจากฐานข้อมูลอื่นแทน
สาเหตุไม่ได้มาจากความไร้ประสิทธิภาพของ Reranker แต่เป็นเพราะข้อจำกัดทางสถาปัตยกรรม โดย BGE-Reranker จะทำการตัดข้อความทิ้งที่ 512 โทเค็น เมื่อทำการตรวจสอบพบว่ามีชังค์ข้อมูลถึง 31% ที่มีความยาวเกินกว่าที่ Reranker จะสามารถมองเห็นได้ เนื่องจากคู่มือมักจะเขียนเรียงตามลำดับจากชื่อ อาการ บริบท และส่วนการแก้ไขปัญหา (Resolution) ที่อยู่บริเวณท้ายสุดของข้อความ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในแง่ของการทดสอบจากชุดคำถามที่ติดป้ายกำกับด้วยมือ 60 ข้อ ระบบ Retrieval สามารถค้นหาชังค์ที่ถูกต้องให้อยู่ใน 20 อันดับแรกได้ถึง 54 ข้อ แต่หลังผ่านขั้นตอน Reranker จำนวนชังค์ที่ติด 5 อันดับแรกลดลงเหลือเพียง 41 ข้อเท่านั้น สะท้อนให้เห็นว่ากระบวนการ Reranking ซึ่งควรทำหน้าที่เป็นด่านคัดกรองที่ชาญฉลาดและละเอียดกว่า กลับทำข้อมูลที่ค้นพบแล้วสูญหายไป
เมื่อตรวจสอบ 13 กรณีที่หลุดรอดไป พบว่าใน 9 กรณี ประโยคที่เป็นคำตอบจริงอยู่ 3 ส่วนท้ายของชังค์ ซึ่งเป็นธรรมชาติของการเขียนเอกสารคู่มือระบบที่จะวางคำสั่งหรือโค้ดแก้ไขปัญหาไว้ที่บรรทัดสุดท้ายเสมอ
"The reranker wasn't dumb. It was blind. My bge-reranker truncates at 512 tokens, and the fix commands lived at the bottom of a chunk it never finished reading."
นักพัฒนาผู้ประสบปัญหา
เบื้องหลังข้อจำกัดนี้มาจากการที่ Cross-Encoder Reranker ทำงานโดยอิงสถาปัตยกรรมแบบ BERT ที่มีจำนวน Position Embeddings คงที่ โดยนำ Query และ Passage มาต่อเข้าด้วยกันเป็นอินพุตชุดเดียว ซึ่งแตกต่างจากโมเดล Embedding แบบ Bi-Encoder ที่ทำการฝังเวกเตอร์แยกออกจากกันอย่างอิสระ
การทำความเข้าใจความแตกต่างระหว่าง Bi-Encoder และ Cross-Encoder ช่วยให้เห็นภาพว่าทำไม Reranker จึงให้ผลลัพธ์ที่แม่นยำกว่าด้วยการทำ Joint Attention ระหว่างคำถามและเนื้อหา แต่ก็แลกมาด้วยข้อจำกัดด้านขนาดอินพุตที่เข้มงวด เมื่อตัวตัดคำ (Tokenizer) ใช้กลยุทธ์ Longest First จึงทำให้ส่วนท้ายของเนื้อหาที่มีความยาวเกินถูกตัดทิ้งไปอย่างเงียบๆ โดยไม่มีการแจ้งเตือนในระบบบันทึก (Logs)
แนวทางแก้ไขปัญหานี้สามารถทำได้ 3 วิธีหลัก โดยผู้พัฒนาเลือกใช้สองวิธีแรกคารวมกัน ได้แก่ การกำหนดขนาดชังค์ให้สอดคล้องกับงบประมาณโทเค็นของ Reranker โดยใช้ length_function เป็นตัวตัดคำ และการใช้เทคนิค MaxP Scoring ด้วยการแบ่งหน้าต่างข้อความซ้อนทับกัน (Sliding Window) เพื่อคำนวณคะแนนและเลือกค่าสูงสุดในแต่ละส่วน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น