टूल्स

Reranking

इसे भी कहा जाता है: Re-ranking, Cross-Encoder Reranking

Retrieval pipeline का दूसरा scoring pass जो अधिक accurate — और अधिक expensive — relevance model से initial candidate documents को फिर order करता है। Vector search या keyword search जैसा fast first stage top कुछ dozen candidates लौटाता है, और reranker हर candidate को query के विरुद्ध score करके बेहतर final ordering बनाता है।

यह क्यों मायने रखता है

First-stage retrieval precision नहीं speed के लिए optimize होता है, इसलिए best chunk अक्सर position 1 के बजाय position 12 पर आता है — और top पर आने वाली चीज़ ही LLM वास्तव में अपने prompt में देखता है। Reranking modest latency cost में बड़ा relevance improvement खरीदता है, इसीलिए production RAG systems में standard stage बन गया है।

गहन अध्ययन

Reranking इसलिए मौजूद है क्योंकि fast retrieval तथा accurate retrieval अलग problems हैं। RAG या semantic search pipeline के first stage को milliseconds में millions of chunks छाँटने पड़ते हैं, इसलिए वह approximate methods पर निर्भर करता है: bi-encoder एम्बेडिंग model query तथा हर document को independently vectors में बदलता है, या BM25 meaning की समझ के बिना keyword overlap score करता है। ये methods आम तौर पर सही document को top 50 में कहीं ले आते हैं, लेकिन उन 50 के भीतर ordering noisy होती है। Reranker वह candidate set लेकर ऐसा model लगाता है जो पूरे corpus पर चलने के लिए बहुत slow होगा — आम तौर पर cross-encoder जो query और एक document साथ पढ़ता है — और list को फिर sort करता है ताकि वास्तव में relevant chunks ऊपर आएँ। Final top-k, अक्सर केवल 3–10 chunks, prompt में assemble होता है।

Bi-Encoders बनाम Cross-Encoders

दो stages के बीच performance gap architecture से आता है। Bi-encoder हर text के लिए एक vector बनाता है: query एक बार embedded होती है, हर document एक बार, आम तौर पर offline और पहले से, तथा relevance केवल दो points के बीच Cosine Similarity होती है। Approximate nearest-neighbor indexes के साथ यह बेहद fast है, लेकिन model query तथा document को साथ कभी नहीं देखता, इसलिए एक के specific words का दूसरे के specific words के साथ interaction model नहीं कर सकता। Cross-encoder उलटा करता है: query और single candidate document concatenate होकर एक input के रूप में Transformer से गुजरते हैं और model सीधे relevance score output करता है। दोनों texts में हर token दूसरे हर token पर attend कर सकता है, इसलिए यह nuance — negation, exact constraints तथा multi-hop phrasing — पकड़ता है जिसे embedding similarity नियमित रूप से miss करती है।

Catch cost है। 50 candidates score करने का अर्थ 50 separate forward passes है और pairs pre-compute नहीं हो सकते क्योंकि query केवल request time पर पता चलती है। इसीलिए cross-encoders कभी millions of documents वाले full corpus पर नहीं चलते और two-stage split पहली जगह मौजूद है: bi-encoder का काम recall है, सही documents candidate set में लाना, और cross-encoder का काम precision है, उन्हें सही order में रखना।

व्यवहार में Rerankers

Reranker जोड़ने के दो common तरीके हैं। Cohere Rerank तथा Voyage AI के rerank endpoint जैसी hosted APIs single request में query plus documents की list लेकर scores लौटाती हैं — चलाने के लिए infrastructure नहीं, लेकिन extra network call और per-request pricing। BAAI की bge-reranker family तथा Jina AI के rerankers के नेतृत्व वाले open-weight models Hugging Face पर उपलब्ध हैं और small candidate sets के लिए single GPU या CPU पर भी चल सकते हैं, जिससे data in-house और costs predictable रहती हैं।

Integration pattern दोनों में same है: generous candidate set, top 20–100, अक्सर वेक्टर डेटाबेस plus BM25 के hybrid search से, retrieve करें, rerank करें, top 3–10 रखें और बाकी discard करें। कुछ teams dedicated model पूरी तरह छोड़कर बड़ा भाषा मॉडल को candidates zero-shot rank करने का prompt देती हैं; यह काम करता है और listwise LLM rerankers strong हो सकते हैं, लेकिन purpose-built cross-encoder आम तौर पर per query one से two orders of magnitude सस्ता होता है।

यह Bad Retrieval ठीक नहीं कर सकता

एक आम गलतफ़हमी है कि reranker जोड़ना weak search pipeline को बचा लेगा। ऐसा नहीं हो सकता, क्योंकि reranking केवल first stage से पहले ही लौटे items का order बदलता है: relevant chunk candidate set में आया ही नहीं तो reranker उसे देखता नहीं और accurate scoring की कोई मात्रा उसे वापस नहीं ला सकती। First stage downstream हर चीज़ पर hard recall ceiling तय करता है। Debugging के लिए इसका practical consequence है: end-to-end retrieval quality खराब हो तो stages अलग measure करें। जाँचें कि सही chunk top 50 में कहीं दिखता है या नहीं, retrieval problem में embeddings अथवा chunking ठीक करें या hybrid search जोड़ें, बनाम वह दिखता है लेकिन बहुत नीचे rank है, जो reranking problem है। यह distinction छोड़ने वाली teams अक्सर ऐसे gains के लिए reranker tune करने में weeks बिताती हैं जिन्हें stage one ने शुरू से cap किया था।

Latency Budget

Reranking एक trade है: extra लेटेंसी तथा cost के बदले बेहतर ordering। 50 query–document pairs score करने वाला self-hosted cross-encoder model size तथा document length के अनुसार आम तौर पर tens से few hundred milliseconds जोड़ता है; hosted API उसके ऊपर network round trip जोड़ती है। Knobs सीधे हैं: कम candidates rerank करें, top 100 के बजाय top 20, scoring से पहले documents truncate करें, smaller model इस्तेमाल करें या repeated queries के scores cache करें।

Trade worthwhile है या नहीं, application पर निर्भर है। User-facing assistant में जहाँ answers generate होने में पहले ही seconds लगते हैं, extra 100–300 ms आम तौर पर invisible है और relevance gain off-topic context से होने वाला हैलूसिनेशन सीधे घटाता है। Autocomplete-style search या high-QPS internal services में teams अक्सर उन queries के लिए reranking reserve करती हैं जो कठिन लगती हैं — long, ambiguous या stage one से low-confidence — और easy queries सीधे pass करती हैं। Production retrieval systems में pragmatic default है: हमेशा rerank करें, जब तक साबित न कर सकें कि आप afford नहीं कर सकते।