विषय-सूची

आपने RAG तो बना लिया, लेकिन search की क्वालिटी औसत दर्जे की है — ठीक यहीं reranking काम आती है। आप embedding (vector) search से मोटे तौर पर जुटाए गए candidates को लेते हैं और उन्हें relevance के आधार पर फिर से क्रम में लगाकर सिर्फ़ टॉप वाले रखते हैं। यह एक ही कदम किसी RAG सिस्टम के जवाब की क्वालिटी को नाटकीय रूप से बदल सकता है — retrieval की precision के लिए "आख़िरी धक्का"।

यह लेख शुरुआती लोगों के लिए सरल भाषा में बताता है कि reranking क्या है, यह क्यों ज़रूरी है, two-stage retrieval कैसे काम करती है, यह सटीक क्यों होती है (bi-encoder बनाम cross-encoder), और इसके मॉडल व implementation।

RERANKING · GATHER WIDE → REORDER SMART

"सच में relevant" को ऊपर लाने के लिए दो चरण

— तेज़ search से जुटाएँ, सटीक scoring से छाँटें

STEP 1 · RETRIEVE

Embedding search

तेज़ी से और व्यापक रूप से candidates जुटाएँ (जैसे 100)। recall के लिए ऑप्टिमाइज़ करें।

→
STEP 2 · REORDER

Reranker

relevance के आधार पर score दें और टॉप रखें (जैसे 5)। precision के लिए ऑप्टिमाइज़ करें।

1. Reranking क्या है?

Reranking का मतलब है पहले से जुटाए गए search results को query से उनकी relevance के आधार पर फिर से score देना और उन्हें फिर से क्रम में लगाना। RAG में, आप सबसे पहले embedding search का इस्तेमाल करके बहुत-से संभावित-relevant दस्तावेज़ खींच लेते हैं। लेकिन वह क्रम सिर्फ़ "मोटे तौर पर करीब" होता है। फिर आप एक reranker नामक समर्पित मॉडल जोड़ते हैं ताकि सच में relevant दस्तावेज़ों को ऊपर धकेला जा सके।

इसे "पहली छँटाई और आख़िरी इंटरव्यू" की तरह समझें। पहली छँटाई (embedding search) आवेदकों को तेज़ी से छानती है और काफ़ी सारे आगे बढ़ा देती है। आख़िरी इंटरव्यू (reranker) हर एक को ध्यान से देखता है और सबसे बेहतर को ऊपर लगाता है। एक तेज़ पहली छँटाई और एक सटीक आख़िरी इंटरव्यू — यही दो-चरण वाली संरचना असली कुंजी है।

💡 एक पंक्ति में: reranking = "एक दूसरा चरण जो search results को फिर से क्रम में लगाकर precision बढ़ाता है।" embedding search किसी ज़रूरी दस्तावेज़ के छूटने से बचाने के बाद, यह "सबसे बेहतर को ऊपर लाने" का काम संभालता है।

2. यह क्यों ज़रूरी है: embedding search की सीमाएँ

Embedding search तेज़ और सुविधाजनक है, पर इसमें एक कमज़ोरी है। चूँकि यह query और दस्तावेज़ों को अलग-अलग vector में बदलकर फिर तुलना करता है, यह उनके बीच के बारीक रिश्ते को नहीं देख पाता। यह "मोटे तौर पर करीब" खोजने में अच्छा है, पर यह आँकने में कच्चा है कि "क्या यह सच में सवाल का जवाब देता है?"

नतीजतन, टॉप परिणामों में ऐसे दस्तावेज़ भी मिल जाते हैं जो "keyword के लिहाज़ से करीब पर असल में बेमेल" होते हैं। चूँकि RAG टॉप पर मिले दस्तावेज़ सीधे AI को सौंप देता है, इसलिए ख़राब क्रम सीधे जवाब की क्वालिटी घटा देता है। यहीं एक reranker relevance को सही ढंग से दोबारा मापता है और क्रम सुधारता है। शोध बताते हैं कि reranking जोड़ने से RAG की सटीकता काफ़ी बढ़ती है (एक रिपोर्ट में करीब 40% सुधार का ज़िक्र है) — यह एक रिपोर्ट किया गया आँकड़ा है।

इसके अलावा, hybrid search — keyword और vector search का मेल — पर reranking की परत चढ़ाना 2026 में production RAG का मानक सेटअप बन गया है। "व्यापक और विविध रूप से जुटाएँ, फिर अंत में reranker को relevance के आधार पर क्रम लगाने दें" — यह प्रवाह precision बढ़ाता है।

3. यह कैसे काम करता है: two-stage retrieval

आप reranking को "two-stage retrieval" के रूप में बनाते हैं। इसका सिद्धांत है "व्यापक रूप से जुटाएँ, समझदारी से छाँटें।"

① embedding search से व्यापक रूप से जुटाएँ~100
तेज़ी से ढेरों candidates जुटाएँ (recall = कोई न छूटे)
↓ reranker से score दें
② reranker से टॉप तक छाँटेंtop 5
relevance के आधार पर फिर से क्रम लगाएँ (precision = सिर्फ़ वही जो सच में मदद करे)
↓ सिर्फ़ टॉप को आगे भेजें
③ जवाब बनाने के लिए LLM को सौंपें
छँटे हुए context से जवाब बनाएँ

असली बात है काम का बँटवारा। हर दस्तावेज़ को reranker से score देना व्यावहारिक रूप से बहुत धीमा है। इसलिए तेज़ embedding search पहले candidates को छाँट लेती है (जैसे 100), और सिर्फ़ उस छोटे समूह को reranker जाँचता है। इससे गति और precision के बीच संतुलन बनता है। यह context engineering के इस विचार से भी मेल खाता है कि "सबसे ज़्यादा signal वाली जानकारी का सबसे छोटा समूह सौंपें।"

4. reranker ज़्यादा सटीक क्यों होता है

Embeddings और rerankers अंदर से अलग ढंग से बने होते हैं। यही सटीकता के अंतर की वजह है।

BI-ENCODER (embedding)

अलग-अलग देखो, बाद में तुलना करो

query और दस्तावेज़ को अलग-अलग vector में बदलता है, फिर दूरी मापता है। पहले से गणना करने योग्य और तेज़, पर यह उनकी आपसी क्रिया कभी नहीं देखता (अनुमानित)।

CROSS-ENCODER (reranker)

साथ में देखो, सीधे score दो

query और दस्तावेज़ को एक साथ feed करता है और सीधे एक relevance score (0–1) देता है। यह उनकी आपसी क्रिया देखता है, इसलिए सटीक है — पर भारी।

उपमा के तौर पर, एक bi-encoder "दो निबंधों का अलग-अलग सारांश बनाकर फिर सारांशों की तुलना करता है," जबकि एक cross-encoder "दोनों को साथ-साथ पढ़कर रिश्ते का आकलन करता है।" बाद वाला स्वाभाविक रूप से ज़्यादा सटीक है, पर आप इसे हर दस्तावेज़ पर नहीं चला सकते। इसीलिए दो-चरण वाला सेटअप — तेज़ bi-encoder से जुटाओ, सटीक cross-encoder से छाँटो — समझदारी भरा है।

5. मॉडल और implementation

आपको reranker शुरू से बनाने की ज़रूरत नहीं — समर्पित मॉडल और API तैयार हैं।

API प्रकार (आसान)

Cohere Rerank, Voyage, Jina Reranker। बस अपने मौजूदा search के ऊपर बैठा दें — सिर्फ़ एक API कॉल।

Open-source प्रकार

BGE reranker, mixedbread, FlashRank (हल्का)। मुफ़्त में self-host करें — लागत और privacy के लिए अच्छा।

LLM से score (RankLLM आदि)

LLM से ख़ुद ही score दिलवाएँ कि "कौन-सा relevant है।" लचीला, पर ज़्यादा महँगा।

Implementation हैरान करने वाली हद तक सरल है। अपने मौजूदा RAG (vector search) में, बस "ज़्यादा संख्या में retrieve करें (जैसे 50–100), उन्हें reranker से गुज़ारें, और टॉप 5 तक छाँट लें" — यही एक कदम जोड़ें। असर को AI evals से मापें और तय करें कि कितने retrieve करने हैं और कितने रखने हैं।

※ मॉडल के नाम और आँकड़े विभिन्न गाइड व शोध से लिए गए हैं (जून 2026 तक)। असर data और settings के साथ बदलता है, इसलिए मापना और ट्यून करना ही पक्का तरीका है।

सारांश

Reranking पर तीन मुख्य बातें।

  • यह क्या है: एक दूसरा चरण जो search results को relevance के आधार पर फिर से score करके सबसे बेहतर को ऊपर ले आता है। RAG की precision के लिए "आख़िरी धक्का।"
  • यह कैसे काम करता है: two-stage retrieval — तेज़ embedding search से व्यापक रूप से जुटाएँ, फिर सटीक reranker से छाँटें। "व्यापक रूप से जुटाएँ, समझदारी से छाँटें।"
  • फ़र्क़: embeddings (bi-encoder) अलग-अलग देखते हैं और तेज़ हैं; rerankers (cross-encoder) साथ में देखते हैं और सटीक हैं। दोनों फ़ायदे पाने के लिए भूमिकाएँ बाँट दें।

अगर आपके RAG की precision में कमी है, तो एक reranker जोड़ने से शुरुआत करें। अक्सर, बस इसे अपने मौजूदा search के ऊपर रख देने भर से ही फ़र्क़ साफ़ महसूस होता है। पूरी retrieval तस्वीर समझने के लिए इसके साथ embeddings और RAG implement करना भी पढ़ें।

FAQ

Q. क्या अकेले embedding search काफ़ी नहीं है?

A. कुछ इस्तेमालों के लिए, हाँ — पर जब precision कम पड़े तब reranking मदद करती है। Embeddings तेज़ी से और व्यापक रूप से जुटाने में अच्छे हैं, पर relevance आँकने में कच्चे। एक reranker जोड़ने से सच में relevant दस्तावेज़ों के टॉप पर पहुँचने की संभावना बढ़ जाती है।

Q. क्या यह धीमा नहीं होगा?

A. reranker भारी होता है, पर आप इसे सिर्फ़ उस छोटे समूह पर चलाते हैं जिसे embedding search ने छाँटा है (जैसे 50–100), हर दस्तावेज़ पर नहीं, इसलिए यह व्यावहारिक गति पर बना रहता है। तरकीब यह है कि बहुत ज़्यादा retrieve न करें।

Q. क्या rerankers और embedding models अलग-अलग चीज़ें हैं?

A. हाँ। एक embedding model (bi-encoder) search के लिए vectors बनाता है; एक reranker (cross-encoder) दोनों को साथ में देखकर relevance को score देता है। भूमिकाएँ अलग हैं, इसलिए आप दोनों को मिलाकर इस्तेमाल करते हैं।

Q. कितने retrieve करूँ, और कितने रखूँ?

A. एक मोटा अंदाज़ा है "50–100 retrieve करें → टॉप 3–10 रखें," पर सबसे बेहतर संख्या आपके data पर निर्भर करती है। precision को AI evals से मापें और संख्याएँ समायोजित करें। बहुत ज़्यादा धीमा करता है; बहुत कम चीज़ें छुड़ा देता है।