Reranking

Reranking คือขั้นตอนที่นำผลลัพธ์จากการค้นหารอบแรกมาให้โมเดลอีกตัวหนึ่งที่แม่นยำกว่าตรวจดูใหม่ทีละคู่ระหว่างคำถามกับเอกสาร แล้วจัดอันดับใหม่ตามความเกี่ยวข้องจริง ก่อนเลือกส่งเฉพาะอันดับต้นๆ เข้า context-window ของ llm ในระบบ rag Pinecone อธิบายว่าโมเดลที่ทำหน้าที่นี้เรียกว่า cross-encoder รับคำถามกับเอกสารเข้าไปเป็นคู่ แล้วให้คะแนนความคล้ายออกมาหนึ่งค่าต่อคู่ (Pinecone, Rerankers and Two-Stage Retrieval) ตัวอย่างบริการจริงในตลาดคือ Rerank API ของ Cohere ที่รับคำถามและรายการเอกสาร แล้วส่งกลับลำดับของเอกสารเรียงจากเกี่ยวข้องมากไปน้อยพร้อมคะแนนความเกี่ยวข้องต่อชิ้น เอกสารของ Cohere ณ เดือนสิงหาคม 2026 ระบุว่ามีให้เลือกทั้ง rerank-v4.0-pro, rerank-v4.0-fast, rerank-v3.5, rerank-english-v3.0 และ rerank-multilingual-v3.0 โดยรุ่น 4.0 กับ 3.5 เทรนมาให้ทำงานได้กับภาษามากกว่า 100 ภาษา ส่วนเจน 3.0 แยกเป็นรุ่นภาษาอังกฤษล้วนกับรุ่นหลายภาษา (Cohere) และ Pinecone เองก็มีโมเดล rerank แบบ hosted ให้ใช้ได้สองแบบ คือใส่พารามิเตอร์ rerank ไปกับคำสั่ง search ในคราวเดียว หรือเรียก endpoint rerank แยกต่างหากก็ได้ (Pinecone Docs)

เหตุผลที่ต้องมีขั้นนี้ต่อจากการค้นด้วย embedding เพียงอย่างเดียวคือ embedding บีบอัดความหมายทั้งเอกสารให้เหลือเวกเตอร์เดียวโดยไม่รู้ล่วงหน้าว่าคำถามคืออะไร การเทียบเวกเตอร์แบบนี้จึงเร็วมากแต่ก็สูญเสียรายละเอียดไปด้วย ส่วน cross-encoder ประมวลผลคำถามกับเอกสารพร้อมกันในโมเดลเดียว ทำให้แม่นกว่าแต่ก็หนักกว่ามาก Pinecone ยกตัวอย่างให้เห็นภาพว่าถ้าเอาโมเดลแบบ BERT มา rerank เอกสารทั้งหมด 40 ล้านรายการต่อคำถามหนึ่งข้อบน GPU รุ่น V100 จะต้องรอมากกว่า 50 ชั่วโมงกว่าจะได้ผลลัพธ์ ขณะที่การค้นด้วย encoder model และ vector search แบบเดิมทำเวลาเดียวกันได้ในเวลาต่ำกว่า 100 มิลลิวินาที (Pinecone) นี่คือที่มาของการทำงานสองขั้น: ให้ embedding กวาดเอกสารที่ใกล้เคียงมาก่อนสักหลักสิบถึงหลักร้อยรายการอย่างรวดเร็ว แล้วค่อยให้ reranker มาไล่อ่านทีละคู่เฉพาะกลุ่มที่คัดมาแล้วเท่านั้น งานที่มักถูกอ้างว่าทำให้แนวทางนี้แพร่หลายคือเปเปอร์ปี 2019 ของ Nogueira และ Cho ที่นำ BERT มาใช้จัดอันดับ passage ใหม่ แล้วรายงานว่าขึ้นเป็นอันดับหนึ่งบน leaderboard ของงาน MS MARCO passage retrieval ดีกว่าเจ้าของสถิติเดิมถึง 27% (relative) บนตัวชี้วัด MRR@10 ข้อควรระวังคือตัวเลขนี้เป็นผลของปี 2019 จากเปเปอร์ที่เผยแพร่เป็น preprint บน arXiv และถูกวิธีรุ่นใหม่กว่าแซงไปแล้วหลายรอบ (arXiv 1901.04085)

คนทำงานมักเจอคำนี้ตอนที่ทีมสร้างแชทบอทหรือระบบค้นหาเอกสารภายในองค์กรด้วย rag แล้วพบว่าคำตอบไม่ตรงคำถามทั้งที่เอกสารที่ถูกต้องมีอยู่ในฐานข้อมูลจริง เพียงแต่ค้นด้วย embedding อย่างเดียวแล้วมันไม่ขึ้นมาอยู่อันดับต้นๆ การเติม reranking เข้าไปช่วยยกเอกสารที่ตอบโจทย์จริงขึ้นมาก่อนส่งเข้า LLM ทำให้คำตอบมี grounding แน่นขึ้น ข้อควรระวังคือ reranking เป็นขั้นตอนที่เพิ่มเวลาและต้นทุนต่อการค้นหาแต่ละครั้ง เพราะต้องเรียกโมเดลอีกตัวหนึ่งเพิ่ม (ไม่ว่าจะรันเองหรือเรียกผ่าน API ของผู้ให้บริการ) จึงต้องคัดจำนวนเอกสารที่ส่งเข้า reranker ให้อยู่ในระดับที่รับไหว ไม่ใช่ส่งทั้งฐานข้อมูลเข้าไปตรงๆ และการันตีผลดีขึ้นเสมอไม่ได้ ต้องวัดผลจริงกับชุดคำถามของงานตัวเองก่อนตัดสินใจใช้ถาวร

ตัวอย่างจากบทสนทนาจริง

ทีมขาย: "ทำไมแชทบอทค้นเอกสารบริษัทแล้วตอบไม่ตรงคำถามเลย ทั้งที่เอกสารที่ถูกอยู่ในระบบจริงๆ"

ทีม IT: "ลองเช็คดูแล้วพบว่าเอกสารที่ถูกอยู่อันดับที่ 20 กว่าของผลค้นหา ไม่ใช่ไม่ถูกค้นเจอ แต่ embedding จัดอันดับมันไว้ต่ำเกินไป เราเลยเพิ่มขั้นตอน reranking เข้าไป คือเอาผลค้นหารอบแรกมาให้โมเดลอีกตัวอ่านคำถามคู่กับเอกสารแต่ละอันจริงๆ อีกที แล้วจัดอันดับใหม่ก่อนส่งเข้า LLM"

ทีมขาย: "แล้วทำไมไม่ใช้โมเดลแม่นๆ ตัวนั้นค้นตั้งแต่ต้นเลยล่ะ จะได้ไม่ต้องมีสองขั้นตอน"

ทีม IT: "เพราะมันช้าเกินไปถ้าเอามาไล่อ่านเอกสารทั้งฐานข้อมูล ต้องให้ embedding คัดมาก่อนสักร้อยอันดับแรกแบบเร็วๆ แล้วค่อยให้ reranker มาช่วยเลือกละเอียดอีกทีเฉพาะกลุ่มที่คัดมาแล้ว"

ระวังสับสนกับ

• embedding : embedding คือขั้นตอนแปลงข้อความเป็นเวกเตอร์เพื่อค้นหาแบบกว้างๆ รอบแรก เร็วแต่หยาบ ส่วน reranking ทำงานทีหลัง ประเมินคู่คำถามกับเอกสารแบบละเอียดทีละคู่ ช้ากว่าแต่แม่นกว่า
• chunking : chunking คือการตัดเอกสารยาวเป็นชิ้นย่อยตั้งแต่ต้นทางก่อนนำไปทำ embedding ส่วน reranking เป็นขั้นตอนที่มาทีหลัง ทำงานกับชิ้นเอกสารที่ถูกค้นเจอแล้วเท่านั้น