प्रकाशित 19 October 2026
भर्ती और स्टाफ़िंग फ़र्में संस्थागत ज्ञान की बहुत बड़ी मात्रा तैयार करती हैं, जिसका ज़्यादातर हिस्सा कहीं भी खोजने योग्य रूप में मौजूद नहीं होता। स्क्रीनिंग कॉल पर एक रिक्रूटर के नोट्स, किसी उम्मीदवार के आगे न बढ़ने के कारण पर हायरिंग मैनेजर की प्रतिक्रिया, स्थानांतरण या वेतन को लेकर उम्मीदवार की अपनी प्राथमिकताएँ — यह सब आमतौर पर एक applicant tracking system के मुक्त-पाठ फ़ील्ड, ईमेल थ्रेड्स, और अलग-अलग रिक्रूटर्स की स्मृति में बिखरा रह जाता है। जब महीनों बाद कोई समान भूमिका खुलती है, तो फ़र्म लगभग फिर से शून्य से शुरू करती है, जबकि टीम में किसी ने संभवतः पहले ही लगभग उसी पद के लिए एक मज़बूत उम्मीदवार की स्क्रीनिंग कर ली होती है।
यह retrieval-augmented generation के लिए काफ़ी साफ़-सुथरा उपयुक्त मामला है, क्योंकि मूल समस्या यह नहीं है कि फ़र्म के पास डेटा नहीं है — समस्या यह है कि डेटा असंरचित रूप में मौजूद है, सिस्टमों में फैला हुआ है, और रिक्रूटर की इस याद से ज़्यादा सटीक किसी चीज़ के ज़रिए खोजा नहीं जा सकता कि उन्होंने किससे कब बात की थी।
ATS खोज क्यों पर्याप्त नहीं है
ज़्यादातर applicant tracking systems रिज़्यूमे और उम्मीदवार रिकॉर्ड पर कीवर्ड खोज का समर्थन करते हैं, जो skills tags, अनुभव के वर्षों, और स्थान जैसे संरचित फ़ील्ड्स के लिए काफ़ी ठीक काम करता है, लेकिन उस तरह की सूक्ष्म जानकारी के सामने लड़खड़ा जाता है जो वास्तव में यह बताती है कि कोई फिर से शुरू हुई बातचीत करने लायक है या नहीं। कीवर्ड खोज यह तथ्य सामने नहीं ला पाएगी कि किसी विशेष उम्मीदवार ने अतीत में इसी तरह की भूमिका के लिए अच्छा इंटरव्यू दिया था, लेकिन वेतन के अंतर के कारण ऑफ़र ठुकरा दिया था जो अब शायद लागू न हो, या कि हायरिंग मैनेजर ने जॉब डिस्क्रिप्शन में दी गई आवश्यकताओं से आगे वे वास्तव में क्या तलाश रहे थे, इस बारे में स्पष्ट, गैर-जनरल प्रतिक्रिया दी थी।
वह जानकारी कॉल नोट्स, इंटरव्यू फ़ीडबैक, और ईमेल सारांशों में मौजूद होती है, लेकिन वह प्राकृतिक भाषा में, असंगत प्रारूप में लिखी होती है, और प्रभावी रूप से किसी भी चीज़ के लिए अदृश्य रहती है सिवाय इसके कि कोई इंसान उसे पढ़े। लंबे अनुभव और अच्छी स्मृति वाला रिक्रूटर कभी-कभी इसे मैन्युअल रूप से दोबारा जोड़ सकता है। किसी नई भूमिका में आया रिक्रूटर, या कोई फ़र्म जो इस ज्ञान को सिर्फ़ अलग-अलग व्यक्तियों की स्मृति में बंद रखने के बजाय अपनी पूरी टीम में उपलब्ध कराना चाहती है, ऐसा नहीं कर सकती।
यहाँ RAG सिस्टम क्या करता है
उपयोगी आर्किटेक्चर फ़र्म के अपने ऐतिहासिक उम्मीदवार संवादों के ऊपर एक retrieval layer है, जिसके साथ एक language model जुड़ा होता है जो सामान्य ज्ञान से उत्तर गढ़ने के बजाय उस प्राप्त सामग्री पर आधारित विशिष्ट सवालों के जवाब दे सके। जब कोई रिक्रूटर नई requisition खोलता है, तो वह शून्य से खोज शुरू करने के बजाय एक वास्तविक सवाल जैसा कुछ पूछ सकता है: पिछले साल समान backend engineering भूमिका के लिए मज़बूत रहे उम्मीदवार, जिन्होंने वेतन के कारण ऑफ़र ठुकराया था, या वे उम्मीदवार जिन्होंने clinical operations भूमिका के लिए अच्छा इंटरव्यू दिया लेकिन skill से असंबंधित कारणों से चुने नहीं गए।
सिस्टम उन विशिष्ट संवादों को वापस लाता है जो वास्तव में उस सवाल से संबंधित हैं — सिर्फ़ कीवर्ड मिलान नहीं, बल्कि अर्थगत रूप से समान पिछले संवाद — और language model अपनी मिली हुई जानकारी को स्रोत रिकॉर्ड्स के संदर्भों के साथ संक्षेपित करता है, ताकि रिक्रूटर सारांश को वास्तविक नोट्स से मिलाकर सत्यापित कर सके, न कि उस पर आँख मूँदकर भरोसा करे। यह grounding चरण महत्वपूर्ण है: ऐसा सिस्टम जो वास्तविक रिकॉर्ड्स से जोड़े बिना विश्वसनीय लगने वाले सारांश बनाता है, भर्ती में एक जोखिम है, जहाँ उम्मीदवार के इतिहास को गलत समझना उम्मीदवार संबंध और हायरिंग मैनेजर के सामने फ़र्म की विश्वसनीयता — दोनों के लिए वास्तविक परिणाम ला सकता है।
डेटा स्रोत और उन्हें उपयोगी बनाने का काम
ऐसे प्रोजेक्ट का कठिन हिस्सा शायद ही कभी retrieval architecture स्वयं होता है — असली चुनौती अंतर्निहित डेटा को उपयोगी स्थिति में लाना है। कॉल नोट्स अक्सर उन्हें लिखने वाले रिक्रूटर के आधार पर प्रारूप और गुणवत्ता में असंगत होते हैं। इंटरव्यू फ़ीडबैक ATS से अलग सिस्टम में हो सकता है। ईमेल थ्रेड्स को प्रासंगिक सामग्री के लिए पार्स करना पड़ता है और उन्हें शेड्यूलिंग लॉजिस्टिक्स तथा दूसरे शोर से अलग करना पड़ता है। किसी भी retrieval system के उपयोगी होने से पहले, आमतौर पर डेटा समेकन और सफ़ाई का एक महत्वपूर्ण चरण होता है: ATS, ईमेल, और उन सभी अन्य सिस्टमों से डेटा खींचना जहाँ उम्मीदवार संवाद दर्ज होते हैं, प्रारूपों को मानकीकृत करना, और कुछ मामलों में retrieval के लिए इंडेक्स किए जाने से पहले एक language model का उपयोग करके गंदे ऐतिहासिक नोट्स को अधिक सुसंगत संरचना में संक्षेपित करना।
यही वह जगह भी है जहाँ access controls सामान्य internal knowledge base से अधिक महत्वपूर्ण हो जाते हैं। उम्मीदवार डेटा संवेदनशील होता है, और कई ग्राहकों के साथ काम करने वाली भर्ती फ़र्म को यह सुनिश्चित करना होता है कि retrieval विभिन्न client accounts के बीच मौजूद किसी भी confidentiality सीमा का सम्मान करे। किसी एक client के लिए गोपनीय रूप से स्क्रीन किया गया उम्मीदवार किसी अन्य टीम द्वारा की गई असंबंधित खोज के परिणाम में नहीं आना चाहिए, और सिस्टम को उस सीमा को data layer पर लागू करना चाहिए, न कि इस भरोसे पर छोड़ना चाहिए कि रिक्रूटर देखना याद रखेंगे या नहीं।
सिस्टम को अपडेटेड रखना
ऐसा ज्ञान-आधार एक बार बन जाने वाली चीज़ नहीं है — इसमें लगातार नई उम्मीदवार बातचीत का प्रवाह बना रहना चाहिए, वरना यह धीरे-धीरे पुराना पड़ने लगता है और जिस काम के लिए इसे बनाया गया था, वही मूल्य खो देता है। इसका मतलब आम तौर पर एक ऐसा इनजेशन पाइपलाइन होता है जो निरंतर नए कॉल नोट्स, फीडबैक फ़ॉर्म और ईमेल सारांश उठाता रहे, उन्हें प्रोसेस और इंडेक्स करे, और उन्हें बिना अतिरिक्त मैनुअल मेहनत के रिट्रीवल के लिए उपलब्ध करा दे — रिक्रूटर्स की ओर से सिर्फ़ वही नोट-लेखन काफी हो जो वे अपनी सामान्य वर्कफ़्लो का हिस्सा बनाकर पहले से कर रहे हैं। लक्ष्य यह है कि सिस्टम मौजूदा काम का उप-उत्पाद बने, उस पर चढ़ाया गया एक अतिरिक्त काम नहीं।
सामान्य गलतियाँ जिनका पहले से ध्यान रखना चाहिए
ऐसे सिस्टम में सबसे आम विफलता यह है कि रिट्रीवल आउटपुट को मानव निर्णय की शुरुआती दिशा के बजाय एक तैयार जवाब मान लिया जाए। पुराने उम्मीदवार इंटरैक्शनों का सारांश इसलिए उपयोगी है क्योंकि वह रिक्रूटर को तुरंत मूल नोट्स तक वापस ले जाता है; जैसे ही रिक्रूटर्स स्रोत जाँचें बिना तैयार किए गए सारांश को अंतिम और भरोसेमंद मान लेते हैं, वह उपयोगी होना बंद कर देता है और जोखिम पैदा करने लगता है। उद्धरणों को स्पष्ट और आसानी से खोला जा सकने वाला रखना, उन्हें किसी सामान्य “sources” लिंक के पीछे छिपाने के बजाय, इस बात में बड़ा फर्क डालता है कि रिक्रूटर्स वास्तव में जो पढ़ रहे हैं उसकी पुष्टि करते हैं या नहीं।
दूसरी गलती है डेटा रिटेंशन और सहमति को नज़रअंदाज़ करना। उम्मीदवार डेटा की एक तय उम्र होती है, और कई क्षेत्रों तथा क्लाइंट समझौतों में इस पर सीमाएँ होती हैं कि कुछ उम्मीदवार जानकारी कितने समय तक रखी या दोबारा इस्तेमाल की जा सकती है, खासकर उन उम्मीदवारों के लिए जिन्हें हायर नहीं किया गया। ऐतिहासिक इंटरैक्शनों पर बना रिट्रीवल सिस्टम उन सभी रिटेंशन और डिलीशन नीतियों का सम्मान करे जो पहले से उस डेटा पर लागू हैं; इसका मतलब है कि रिट्रीवल इंडेक्स को सोर्स सिस्टम में होने वाले डिलीट के साथ सिंक में रखना होगा, न कि उस डेटा की एक दूसरी, भुला दी गई प्रति बनने देना जिसे वास्तव में हटाया जाना था।
तीसरी गलती है हालिया घटनाओं की पक्षपातपूर्ण प्राथमिकता। क्योंकि हाल की इंटरैक्शन स्वाभाविक रूप से पुरानी बातचीतों की तुलना में अधिक और ज्यादा विस्तार वाली होती हैं, रिट्रीवल सिस्टम अनजाने में आगे की तारीख में स्क्रीन किए गए उम्मीदवारों को उतनी ही मजबूत लेकिन पहले के उम्मीदवारों पर तरजीह दे सकता है, सिर्फ़ इसलिए क्योंकि वापस लाने के लिए वहाँ ज्यादा टेक्स्ट होता है। प्रासंगिकता को हालियापन से ऊपर रखने के लिए रिट्रीवल को ट्यून करना, बजाय इसके कि वह अपने-आप सबसे ताज़ा रिकॉर्ड्स को ही प्राथमिकता दे, आम तौर पर जानबूझकर किए गए ध्यान की माँग करता है — यह अपने-आप नहीं हो जाता।
यह सबसे अधिक मूल्य कहाँ देता है
ऐसे सिस्टम से सबसे साफ़ फ़ायदा तब दिखता है जब पहले से भरे जा चुके समान पदों के लिए समय-से-भराव कम हो जाता है, और उन मज़बूत उम्मीदवारों से दोबारा जुड़ने के अवसर कम छूटते हैं जो किसी पुराने रोल के लिए सही नहीं थे लेकिन मौजूदा रोल के लिए उपयुक्त हैं। इसका एक कम स्पष्ट लेकिन महत्वपूर्ण लाभ भी है: यह संस्थागत ज्ञान के नुकसान को कम करता है, जो तब होता है जब कोई अनुभवी रिक्रूटर फ़र्म छोड़ देता है, क्योंकि उनकी प्रभावशीलता का एक बड़ा हिस्सा वही खोजी जा सकने वाली इतिहास-जानकारी थी जो उनके जाने के साथ बाहर चली जाती थी।
अगर आपकी टीम के पास वर्षों का उम्मीदवार इंटरैक्शन इतिहास है जो व्यवहार में खोजा ही नहीं जा सकता, तो बड़े निर्माण में कूदने से पहले यह समझना उपयोगी होगा कि उस डेटा पर आधारित एक रिट्रीवल सिस्टम असल में कैसा दिखेगा। व्यापक आर्किटेक्चर से जुड़ी बातों को हम अपने RAG और enterprise knowledge systems पेज पर कवर करते हैं, और रिक्रूटमेंट-विशिष्ट संदर्भ हमारे recruitment and staffing AI software पेज पर मिलता है। अगर आप अपनी फ़र्म के विशिष्ट सिस्टम्स के लिए यह क्या माँगेगा, इस पर बात करना चाहते हैं, तो हमारे साथ project conversation शुरू करें।
संबंधित