जेंडर API कैसे चुनें
इस श्रेणी का हर प्रदाता तुमसे कहेगा कि वह सटीक है, और उनमें से किसी ने भी इसे तुम्हारी सूची पर नहीं मापा। यहाँ वह है जो उन्हें असल में अलग करता है — और हर बिंदु के नीचे हमारा अपना उत्तर भी, ताकि तुम वही सवाल हमसे भी पूछ सको।
छोटा जवाब
- इस आधार पर तुलना करो कि एक परिणाम तुम्हें क्या देता है — सिर्फ़ लेबल पर सीमा नहीं लगाई जा सकती, संभावना और नमूनों की संख्या पर लगाई जा सकती है। इससे तय होता है कि तुम फ़ाइल का एक हिस्सा स्वचालित करोगे या पूरी फ़ाइल हाथ से करोगे।
- विज्ञापन में लिखे सटीकता के प्रतिशत को छोड़ दो, हमारे भी — हम कोई प्रकाशित नहीं करते, क्योंकि हमने इसे किसी प्रकाशित बेंचमार्क पर नहीं मापा। उसके बजाय अपनी ही कुछ सौ पंक्तियों पर खुद मापो।
- नामों का बड़ा डेटाबेस अपने आप बेहतर नहीं होता: कोई नाम एक ही तरह गिना जाता है, चाहे उसके पीछे तीन रिकॉर्ड हों या पचास हज़ार।
- फिर वे चार चीज़ें जाँचो जो लोग भूल जाते हैं — देश के हिसाब से स्थानीयकरण, सालों में उत्तर की स्थिरता, अज्ञात नाम पर क्या लौटता है, और डेटा कहाँ प्रोसेस होता है।
शुरुआत इससे करो कि एक अकेला परिणाम क्या देता है
यही वह मापदंड है जो तुम्हारे बचे हुए काम की मात्रा बदल देता है, और कुछ भी हस्ताक्षर करने से पहले प्रदाता के उदाहरण उत्तर में दिख जाता है।
अकेला जेंडर लेबल बिना हिसाब दिखाया गया फ़ैसला है। तुम उसे हर जगह लागू कर सकते हो या हर जगह जाँच सकते हो; बीच का रास्ता नहीं है। संभावना तुम्हें एक सीमा देती है। जिसके पीछे रिकॉर्ड की संख्या भी हो, वह संभावना बताती है कि वह सीमा तुम्हारे सामने वाली पंक्ति के लिए कुछ मायने रखती है या नहीं — क्योंकि तीन रिकॉर्ड पर टिका भरोसेमंद दिखने वाला उत्तर और हज़ारों पर टिका उत्तर, जब तक कोई गिनती न दिखाए, बिल्कुल एक जैसे लगते हैं।
हमारा उत्तर: हर परिणाम के साथ एक संभावना और नमूनों की संख्या आती है, और CSV/Excel आउटपुट उन्हें तुम्हारी फ़ाइल में स्तंभों के रूप में लिख देता है, इसलिए वही सीमा काम करती है — चाहे तुम API बुला रहे हो या स्प्रेडशीट खोल रहे हो।
जाँचने लायक छह पहलू
इस श्रेणी के प्रदाता आम तौर पर छह जगहों पर अलग होते हैं, और हर एक के साथ यह भी कि हम क्या करते हैं। बाईं ओर का स्तंभ बताता है कि क्या देखना है — हमने किसी और की जाँच नहीं की है, इसलिए इसमें कुछ भी किसी ख़ास प्रदाता के बारे में दावा नहीं है। इसे अपनी सूची में जो भी हैं, उन सबसे पूछो, हमसे भी।
आख़िरी दो के बारे में: एक बार के पैकेज के रूप में खरीदे गए credits की समय-सीमा खत्म नहीं होती, और मासिक प्लान हर महीने नवीनीकृत होता है और कभी भी रद्द किया जा सकता है (पैकेज बदलने का मतलब है रद्द करना और दूसरा चुनना)। दोनों कीमत वाले पन्ने पर पूरे विस्तार से हैं, बिना कोई कोटेशन मांगे।
कवरेज का आँकड़ा फ़ैसला क्यों नहीं करता
हमारे पास 9,124,598 नाम हैं, जो 192 देशों से आते हैं, और हम ये आँकड़े भी सबकी तरह मुख्य पन्ने पर लगाते हैं। उनकी कीमत बस इतनी है: वे बताते हैं कि उत्तर कितनी बार मिलता ही है, और यह कुछ नहीं बताते कि कोई ख़ास उत्तर इस्तेमाल करने लायक है या नहीं। इनके आधार पर मत चुनो — न हमारे, न किसी और के।
जो परीक्षण फ़ैसला करता है उसमें एक दोपहर लगती है: अपने डेटा से कुछ सौ पंक्तियाँ लो जिनका सही उत्तर तुम पहले से जानते हो, उन्हें भी शामिल करो जिनके मुश्किल होने की उम्मीद है, और उन्हें अपनी सूची के हर प्रदाता से गुज़ारो। जिन नामों को सब सही बताते हैं, वे तुम्हें कुछ नहीं बताते।
जाँच-सूची
नौ सवाल, उसी क्रम में जिसमें वे आम तौर पर मायने रखते हैं। हमारा उत्तर दाईं ओर के स्तंभ में है — जिसे भी देख रहे हो उससे यही पूछो, और उत्तर किसी फ़ीचर तालिका से नहीं, लिखित में मांगो।
| पूछो | यह क्यों मायने रखता है | हमारा उत्तर |
|---|---|---|
| एक परिणाम में क्या होता है? | तय करता है कि तुम भरोसेमंद पंक्तियाँ स्वचालित करके बाकी की ही जाँच कर सकते हो या नहीं | जेंडर, एक संभावना, और उसके पीछे रिकॉर्ड की संख्या |
| क्या वही नाम देश के हिसाब से अलग उत्तर दे सकता है? | Andrea इटली में पुरुष नाम है और जर्मनी में स्त्री नाम; एक ही वैश्विक उत्तर इनमें से एक जगह गलत होगा | हाँ — देश कोड, ब्राउज़र locale या IP पते से |
| क्या वही अनुरोध अगले साल भी वैसा ही उत्तर देगा? | ऑडिट पूछता है कि रिकॉर्ड को वर्गीकृत कैसे किया गया, और बदलते रहने वाले उत्तर की व्याख्या नहीं हो सकती | हाँ — यह संग्रहित रिकॉर्ड पर की गई गणित है, कोई उत्पन्न किया गया अनुमान नहीं |
| जिस नाम को वह नहीं जानता, उसके लिए क्या लौटता है? | खाली खाने को छाना जा सकता है; भरोसेमंद दिखने वाले अनुमान को पकड़ा नहीं जा सकता | साफ़-साफ़ “नहीं मिला” और नमूनों की संख्या जो कारण बताती है — कोई गढ़ा हुआ उत्तर कभी नहीं |
| कोई ऐसा रास्ता है जिसमें डेवलपर की ज़रूरत न हो? | जिसके पास सूची होती है, वह आम तौर पर वह व्यक्ति नहीं होता जो API बुला सके | CSV और Excel अपलोड, जिसमें मूल वर्कबुक सुरक्षित रहती है |
| डेटा कहाँ प्रोसेस होता है, और डेटा-प्रोसेसिंग अनुबंध है? | ग्राहकों के नामों की सूची निजी डेटा है, और खरीद विभाग शुरू करने से पहले यह पूछेगा | जर्मन कंपनी, सर्वर जर्मनी में, प्रोसेसिंग EU में, मांगने पर डेटा-प्रोसेसिंग अनुबंध |
| क्या बची हुई क्षमता की समय-सीमा खत्म हो जाती है? | एक बार की सफ़ाई के लिए ऐसी सदस्यता की ज़रूरत नहीं होनी चाहिए जो उससे ज़्यादा चले | प्रीपेड credits, और उनकी समय-सीमा खत्म नहीं होती |
| क्या मैं किसी से बात करने से पहले इसे परख सकता हूँ? | अगर मूल्यांकन के लिए सेल्स कॉल चाहिए, तो तुम एक दोपहर में सूची की तुलना नहीं कर सकते | महीने में 100 मुफ़्त लुकअप, कोई कार्ड नहीं, कोई कॉल नहीं |
| प्रकाशित सटीकता कितनी है? | एक अकेला प्रतिशत उस नाम-सेट का वर्णन करता है जिस पर वह मापा गया, और वह तुम्हारा नहीं है | हम कोई प्रकाशित नहीं करते — नीचे देखो |
सटीकता का वह आँकड़ा जो हम तुम्हें नहीं देंगे
इस बाज़ार में तुम्हें कई प्रतिशत बताए जाएँगे। हमारे पास बताने के लिए कोई मापा हुआ आँकड़ा नहीं है: लेबल लगे नाम-सेट पर हमारा कोई प्रकाशित बेंचमार्क नहीं है, इसलिए हम जो भी आँकड़ा छापें वह सफ़ेद कोट पहना हुआ विज्ञापन का आँकड़ा होगा। किसी आँकड़े को सजाने से बेहतर हमें यही कहना लगता है।
वह जितना लगता है, उससे कम काम का भी है। नाम-जेंडर लुकअप की सटीकता लगभग पूरी तरह इस पर निर्भर करती है कि तुम किन नामों के बारे में पूछते हो — आम जर्मन पहले नामों की सूची और एक दर्जन लिपियों से लिप्यंतरित उपनामों की सूची, दुनिया के किसी भी प्रदाता से एक ही आँकड़ा नहीं देंगी। इसलिए एक अकेला प्रतिशत उस सेट के बारे में बताता है जिस पर वह मापा गया, और तुम्हारी सूची वह सेट नहीं है।
जब तुम्हें कोई आँकड़ा बताया जाए, तो उसे सार्थक बनाने वाला सवाल यह है: किन नामों पर मापा गया, कितने, लेबल किसने लगाए, और “अज्ञात” को किस रूप में गिना गया? अगर ये उत्तर उपलब्ध नहीं हैं, तो वह प्रतिशत सजावट है।
एक दोपहर में मूल्यांकन कैसे कर लें
यह पन्ना तुमसे बार-बार कह रहा है कि अपने डेटा पर मापो, तो तरीका यहाँ है। इसमें एक दोपहर लगती है, यह तुम्हारी सूची के हर प्रदाता पर एक ही तरह काम करता है, और परियोजना का फ़ैसला पाँचवाँ कदम करता है।
- 1. 200–300 पंक्तियाँ निकालो जिनका उत्तर तुम पहले से जानते हो। अपने असली डेटा से, मशहूर नामों की सूची से नहीं। मुश्किल वालों को जानबूझकर शामिल करो: दुर्लभ नाम, गैर-पश्चिमी नाम, वे प्रविष्टियाँ जिनमें उपनाम पहले है, एक शब्द के नाम, हाइफ़न वाले नाम और शादी के बाद बदले नाम।
- 2. उन्हें पहले साफ़ मत करो। आख़िर में लगी खाली जगह, पदवियाँ, “Dr.” और सारे बड़े अक्षर — ये सब उसी का हिस्सा हैं जिसे तुम परख रहे हो। जो प्रदाता सिर्फ़ सुथरे इनपुट पर चलता है, उसने तुम्हारी समस्या हल नहीं की।
- 3. पूरा उत्तर रखो, सिर्फ़ लेबल नहीं। पाँचवें कदम में तुम्हें संभावना और नमूनों की संख्या चाहिए होगी, और अगर कोई प्रदाता उन्हें नहीं लौटाता, तो यह अपने आप में परीक्षण का नतीजा है।
- 4. तीन नतीजे अलग-अलग गिनो — सही, गलत, और कोई उत्तर नहीं। यहीं ज़्यादातर मूल्यांकन बिगड़ते हैं: “गलत” और “अज्ञात” को एक ही आँकड़े में मिला देना उसी अंतर को छिपा देता है जो मायने रखता है। जिसे तुम छान सको, वह अज्ञात तुम्हें एक तटस्थ अभिवादन की कीमत देता है। भरोसे के साथ दिया गया गलत उत्तर तुम्हें ग्राहक की कीमत देता है।
- 5. अब एक सीमा लगाओ और फिर से गिनो। सिर्फ़ अपनी सीमा से ऊपर की पंक्तियाँ स्वीकार करो — मान लो 0.9 संभावना जिसके पीछे कम से कम 50 नमूने हों — और दो चीज़ें मापो: यह फ़ाइल का कितना हिस्सा ढकती है, और उसके भीतर गलती की दर। यही जोड़ी असली उत्तर है, क्योंकि यह बताती है कि कितना काम गायब हो जाता है और उसके साथ कितना जोखिम आता है।
- 6. इसी दौरान संचालन से जुड़ी बातें भी जाँच लो। 300 पंक्तियों में कितना समय लगता है। बेकार इनपुट भेजने पर त्रुटि उत्तर कैसा दिखता है। वही अनुरोध दो बार भेजने पर वही उत्तर आता है या नहीं। परीक्षण के लिए फ़ोन कॉल की ज़रूरत पड़ी या नहीं।
पाँचवाँ कदम ही वह कारण है कि उत्तर का ढाँचा विज्ञापन के किसी भी आँकड़े से ज़्यादा मायने रखता है: संभावना और नमूनों की संख्या के बिना लगाने के लिए कोई सीमा ही नहीं होती, इसलिए “इस फ़ाइल का कितना हिस्सा स्वचालित कर सकता हूँ?” का ईमानदार उत्तर बन जाता है “पूरा या कुछ भी नहीं”। महीने में 100 मुफ़्त लुकअप में 300 पंक्तियों का परीक्षण तीन बार हो जाता है।
अगर तुम किसी भाषा मॉडल पर भी विचार कर रहे हो
अब चुनाव अक्सर दो API के बीच नहीं, बल्कि एक API और एक prompt के बीच होता है। वह तुलना दूसरी बातों पर टिकती है — दस लाख पंक्तियों की लागत, वही इनपुट दो बार वही आउटपुट देता है या नहीं, और तुम किसी ऑडिटर को क्या दिखा सकते हो — इसलिए उसका अपना पन्ना है।
जोड़ना असल में कैसा दिखता है
इसे मूल्यांकन के बाद नहीं, उसी दौरान देखना ठीक है, क्योंकि यहीं एक दोपहर दो हफ़्तों में बदल जाती है। हर लुकअप पर एक credit, हर बैच अनुरोध में 100 नाम, और तुम कितने अनुरोध करो इसकी कोई ऊपरी सीमा नहीं।
- PHP, Python, Node, Java, Go, Ruby, Rust, Perl और .NET के लिए आधिकारिक क्लाइंट।
- OpenAPI विवरण के साथ पूरा v2 संदर्भ, और RFC 7807 problem उत्तर, ताकि त्रुटियाँ मशीन पढ़ सके।
- एक नेटिव Excel ऐड-इन और एक Shopify ऐप, Google Sheets, HubSpot, Salesforce, Zapier और अन्य के लिए तैयार इंटीग्रेशन, और AI उपकरणों के लिए होस्टेड MCP सर्वर — पूरी सूची।
- एक बार की फ़ाइल के लिए थोक जेंडर लुकअप, और अगर मूल भी तुम्हारी ज़रूरत का हिस्सा है तो नाम से राष्ट्रीयता।
कीमत 1,000 लुकअप के लिए €0.35 से शुरू होती है और कीमत वाले पन्ने पर पूरी दी हुई है — देखने के लिए कोई कोटेशन नहीं चाहिए।
अक्सर पूछे जाने वाले सवाल
जेंडर API की तुलना किस आधार पर करनी चाहिए?
इस आधार पर कि एक अकेला परिणाम तुम्हें क्या देता है, न कि विज्ञापन में लिखे सटीकता के आँकड़े पर। जो प्रदाता सिर्फ़ एक लेबल लौटाता है, वह तुम्हें हर पंक्ति पर भरोसा करने या हर पंक्ति की जाँच करने पर मजबूर कर देता है; जो प्रदाता संभावना और उसके पीछे के रिकॉर्ड की संख्या लौटाता है, वह तुम्हें भरोसेमंद पंक्तियाँ स्वचालित करने और बाकी को ही देखने देता है। उसके बाद: क्या वही नाम देश के हिसाब से अलग नतीजा दे सकता है, क्या उत्तर समय के साथ स्थिर रहता है, नाम अज्ञात होने पर क्या होता है, और डेटा कहाँ प्रोसेस होता है।
इसे ठीक से कैसे परखें?
अपनी ही सूची पर, मशहूर नामों के नमूने पर नहीं। कुछ सौ पंक्तियाँ लो जिनका उत्तर तुम पहले से जानते हो — मुश्किल वाली भी शामिल करके — और उन्हें चला दो। इसके लिए महीने में 100 मुफ़्त लुकअप काफ़ी हैं, और परखने लायक कोई भी प्रदाता तुम्हें बिना किसी कॉल के यही करने देगा।
क्या नामों का बड़ा डेटाबेस बेहतर होता है?
अपने आप में नहीं। कोई नाम कुल गिनती में एक ही तरह जुड़ता है, चाहे डेटाबेस में उसके लिए तीन रिकॉर्ड हों या पचास हज़ार — इसलिए कुल गिनती यह नहीं बता सकती कि तुम्हारी कौन-सी पंक्तियों पर भरोसा किया जा सकता है। प्रति-परिणाम प्रमाण बता सकता है। आकार से यह तय होता है कि उत्तर कितनी बार मिलता ही है; नमूनों की संख्या से यह तय होता है कि उसे इस्तेमाल करना चाहिए या नहीं।
आप कितनी सटीकता प्रकाशित करते हैं?
जानबूझकर कोई मापा हुआ आँकड़ा नहीं। हमने लेबल लगे नामों के किसी सेट पर प्रकाशित बेंचमार्क नहीं चलाया है, इसलिए कोई प्रतिशत बताना प्रमाण नहीं, विज्ञापन होगा। उसके बजाय हम तुम्हें हर उत्तर का प्रमाण देते हैं — हर परिणाम पर एक संभावना और नमूनों की संख्या — ताकि तुम सटीकता अपने डेटा पर माप सको; तुम्हारी स्थिति बताने वाला यही एक आँकड़ा है। अगर कोई प्रदाता तुम्हें सटीकता का एक आँकड़ा बताता है, तो पूछो कि वह किन नामों पर मापा गया था।
डेटा कहाँ प्रोसेस होता है, इससे फ़र्क पड़ता है?
अगर तुम्हारी सूची ग्राहकों के नामों की है तो पड़ता है, क्योंकि वह निजी डेटा है। हम एक जर्मन कंपनी हैं, सभी सर्वर जर्मनी में हैं, प्रोसेसिंग EU के भीतर होती है, और डेटा-प्रोसेसिंग अनुबंध तुम अपने खाते में मंगा सकते हो। जिसे भी परख रहे हो, यह पायलट के बाद नहीं, उससे पहले लिखित में मांगो।
लोग कौन-से सवाल पूछना भूल जाते हैं?
तीन। उस नाम का क्या होता है जिसे डेटाबेस नहीं जानता — जिसे छान सको ऐसा खाली खाना, उस भरोसेमंद दिखने वाले अनुमान से ज़्यादा कीमती है जिसे तुम पकड़ ही नहीं सकते। क्या वही अनुरोध अगले साल भी वही उत्तर देगा, जो उस पल मायने रखता है जब कोई ऑडिट पूछता है कि रिकॉर्ड को वर्गीकृत कैसे किया गया। और क्या बची हुई क्षमता की समय-सीमा खत्म हो जाती है।
अपनी ही सूची पर परीक्षण करो
महीने में 100 मुफ़्त लुकअप, कोई क्रेडिट कार्ड नहीं और कोई कॉल नहीं। वे पंक्तियाँ लाओ जिनका उत्तर तुम पहले से जानते हो — मुश्किल वाली भी — और देखो हर एक के आगे क्या लौटता है।
API दस्तावेज़ · CSV या Excel फ़ाइल अपलोड करो · हमसे कुछ ठोस पूछो
