फेस सर्च 1:N: एक व्यक्ति के सभी खातों का पता लगाना

आपके प्लेटफॉर्म पर चालीस खाते चलाने वाला एक ऑपरेटर शायद चालीस ईमेल पते, शायद चालीस भुगतान उपकरण और संभवतः चालीस डिवाइस रखता है। उनके पास चालीस चेहरे नहीं होते हैं।

यदि आपकी एक्सेस फ़्लो का कोई भी हिस्सा सेल्फी लेता है, तो आपके पास पहले से ही वह पहचानकर्ता है जिसे गुणा करना वास्तव में महंगा है। फेस सर्च 1:N वह कॉल है जो इसका उपयोग करती है — एक अनुरोध, एक चेहरा, और आपके अपने सिस्टम में हर वह खाता वापस आता है जिसे उसी व्यक्ति ने सत्यापित किया था।

यह डिडिट पहचान सत्यापन के साथ मुफ्त है, यह दो सेकंड से भी कम समय में परिणाम देता है, और यह सत्यापन सत्र के भीतर जीवंतता के दौरान स्वचालित रूप से चलता है।

मुख्य बातें

• POST /v3/face-search/ आपके अपने एप्लिकेशन द्वारा नामांकित चेहरों के विरुद्ध एक चेहरे की खोज करता है — सत्र save_api_request=true के साथ चलाए जाते हैं — न कि साझा वैश्विक सूचकांक।
• मिलान प्रत्येक पर आपके अपने vendor_data के साथ वापस आते हैं, इसलिए परिणाम सीधे आपकी खाता आईडी पर मैप होते हैं।
• दो मोड: डुप्लीकेशन और लौटने वाले उपयोगकर्ताओं के लिए most_similar, ब्लॉकलिस्ट स्क्रीनिंग के लिए blocklisted_or_approved।
• status "Declined" केवल ब्लॉकलिस्ट मिलान पर होता है। डुप्लिकेट DUPLICATED_FACE चेतावनी के साथ "Approved" वापस करते हैं — डिज़ाइन द्वारा सूचनात्मक, क्योंकि डी-डुप्लीकेशन नीति आपकी है।
• प्रतिक्रिया एक अद्वितीय face_search ऑब्जेक्ट है, न कि एक सरणी। यह लोगों को भ्रमित करता है।
• डिडिट सत्यापन के साथ मुफ्त। दो सेकंड से भी कम समय की प्रतिक्रिया। जीवंतता के दौरान स्वचालित रूप से चलता है।

1:N का क्या अर्थ है, और यह सही उपकरण क्यों है

एक 1:1 चेहरा मिलान यह जवाब देता है कि "क्या यह इस दस्तावेज़ में व्यक्ति है?" यह एक सत्यापन प्रश्न है, और यह ऑनबोर्डिंग के दौरान चलता है।

एक 1:N खोज एक अलग प्रश्न का उत्तर देती है: "मेरे द्वारा पहले ही सत्यापित किए गए सभी लोगों में से, क्या यह उनमें से एक है?" एक छवि अंदर जाती है, और आपके सूचकांक में हर मिलान बाहर आता है।

समन्वित खाता दुरुपयोग के लिए, दूसरा प्रश्न महत्वपूर्ण है। डिस्टिलेशन अभियानों पर एंथ्रोपिक की रिपोर्ट ने संबंधपरक संकेतों से निर्मित एट्रिब्यूशन का वर्णन किया — साझा भुगतान विधियां, समन्वित समय, साझा बुनियादी ढांचा। एक बायोमेट्रिक 1:N खोज संकेतों का वही वर्ग है, जो एक ऑपरेटर को गुणा करने के लिए सबसे महंगे पहचानकर्ता से प्राप्त होता है।

सूचकांक आपका है। फेस सर्च आपके अपने एप्लिकेशन द्वारा पिछले सत्यापन के माध्यम से नामांकित चेहरों के विरुद्ध चलता है — save_api_request=true के साथ सत्र, या save_api_request=true के साथ निष्क्रिय जीवंतता। यह अन्य डिडिट ग्राहकों के उपयोगकर्ताओं के बीच एक खोज नहीं है। यदि आपने चेहरे नामांकित नहीं किए हैं, तो खोजने के लिए कुछ भी नहीं है।

एपीआई

अनुरोध

curl -X POST 'https://verification.didit.me/v3/face-search/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -F 'user_image=@./selfie.jpg' \
  -F 'search_type=most_similar' \
  -F 'save_api_request=true' \
  -F 'vendor_data=acct_8842'

multipart/form-data, x-api-key के साथ प्रमाणित।

आवश्यक: user_image — jpg, jpeg, png, tiff या webp, अधिकतम 5 MB। PDF स्वीकार नहीं किए जाते हैं। छवि में कम से कम एक पता लगाने योग्य चेहरा होना चाहिए; जब कई मौजूद हों, तो सबसे बड़ा बाउंडिंग बॉक्स जीतता है।

वैकल्पिक:

• search_type — डी-डुप्लीकेशन और लौटने वाले उपयोगकर्ता पहचान के लिए most_similar (डिफ़ॉल्ट), या ब्लॉकलिस्ट स्क्रीनिंग के लिए blocklisted_or_approved।
• save_api_request — इस छवि को अपने सूचकांक में नामांकित करें।
• vendor_data — विषय के लिए आपका अपना पहचानकर्ता।

प्रतिक्रिया

प्रतिक्रिया में एक अद्वितीय face_search ऑब्जेक्ट होता है। अधिकांश डिडिट सुविधाएँ बहुवचन सरणियाँ लौटाती हैं, इसलिए यह एक ऐसा आकार है जिसे पार्सर लिखने से पहले ध्यान से पढ़ना चाहिए।

{
  "request_id": "...",
  "face_search": {
    "status": "Approved",
    "total_matches": 12,
    "matches": [
      {
        "session_id": "...",
        "session_number": 4471,
        "similarity_percentage": 97.4,
        "vendor_data": "acct_3310",
        "verification_date": "2026-06-02T09:14:00Z",
        "user_details": { },
        "match_image_url": "...",
        "status": "Approved",
        "is_blocklisted": false
      }
    ],
    "user_image": { "entities": [] },
    "warnings": []
  }
}

जांच करने वाले फ़ील्ड:

• total_matches — कितने खातों में यह चेहरा साझा है।
• प्रत्येक मिलान पर vendor_data — आपका पहचानकर्ता, इसलिए एक मिलान सूची तुरंत एक खाता सूची है।
• similarity_percentage — प्रत्येक व्यक्तिगत मिलान की शक्ति।
• verification_date — समयरेखा। ग्यारह महीनों में सत्यापित बारह खाते एक दोपहर में सत्यापित बारह खातों से अलग तरीके से पढ़े जाते हैं।
• is_blocklisted — क्या यह मिलान पहले से ही आपकी ब्लॉकलिस्ट में है।
• session_id — उस सत्र द्वारा कैप्चर की गई हर दूसरी चीज़ में धुरी, जिसमें उसके डिवाइस और नेटवर्क चेतावनियाँ शामिल हैं।

स्थिति सिमेंटिक्स

यह पूरे एंडपॉइंट में सबसे महत्वपूर्ण व्यवहार है:

status "Declined" केवल तब होता है जब कम से कम एक ब्लॉकलिस्ट मिलान पाया जाता है। शुद्ध डुप्लिकेट मिलान "Approved" लौटाते हैं।

एक डुप्लिकेट अस्वीकृति नहीं है। यह जानकारी है। डिडिट जानबूझकर आपके लिए डी-डुप्लीकेशन निर्णय लेने से इनकार करता है, क्योंकि डुप्लिकेट के वैध स्पष्टीकरण होते हैं और केवल आप अपने उत्पाद के नियम जानते हैं।

चेतावनी

चेतावनी	अर्थ
FACE_IN_BLOCKLIST	निश्चित ब्लॉकलिस्ट मिलान — अस्वीकार करें
POSSIBLE_FACE_IN_BLOCKLIST	कठोर सीमा से नीचे की सीमांत मिलान — मैन्युअल समीक्षा पर भेजें
DUPLICATED_FACE	यह चेहरा पहले से ही अलग vendor_data के तहत सत्यापित है
POSSIBLE_DUPLICATED_FACE	सीमांत डुप्लिकेट
MULTIPLE_FACES_DETECTED	सबमिट की गई छवि में एक से अधिक चेहरे पाए गए

विफलता मोड

• HTTP 400 — user_image में कोई चेहरा नहीं मिला। फिर से लेने के लिए कहें।
• HTTP 403 — क्रेडिट समाप्त।
• status: "Declined" with FACE_IN_BLOCKLIST — निश्चित हिट। अस्वीकार करें।
• POSSIBLE_FACE_IN_BLOCKLIST — कठोर सीमा से नीचे। मैन्युअल समीक्षा।
• DUPLICATED_FACE — पहले से ही अलग vendor_data के तहत सत्यापित। अपनी नीति के अनुसार विलय करें, अनुमति दें या उपयोगकर्ता से पूछें।

स्वचालित पथ

आपको अक्सर एंडपॉइंट को बिल्कुल भी कॉल करने की आवश्यकता नहीं होती है। फेस सर्च सत्यापन सत्र के भीतर जीवंतता के दौरान स्वचालित रूप से चलता है:

• चेहरे के बायोमेट्रिक्स की तुलना पहले सत्यापित सभी उपयोगकर्ताओं से की जाती है।
• संभावित डुप्लिकेट खातों की पहचान चेहरे की समानता से की जाती है।
• आपके कॉन्फ़िगर किए गए समानता थ्रेशोल्ड के अनुसार मिलान को फ़्लैग किया जाता है।
• चेहरों की जाँच आपकी ब्लॉकलिस्ट के विरुद्ध की जाती है, और एक ब्लॉकलिस्ट मिलान स्वचालित रूप से सत्यापन को अस्वीकार कर देता है।

तो किसी भी स्तर के लिए जहाँ आप पहले से ही पूर्ण सत्यापन चलाते हैं, डुप्लिकेट पहचान बिना किसी अतिरिक्त लागत और बिना किसी अतिरिक्त कॉल के शामिल है। स्टैंडअलोन एंडपॉइंट उन मामलों के लिए है जिन्हें सत्र प्रवाह कवर नहीं करता है — घटना के बाद एक खाते की जांच करना, आपके द्वारा किसी अन्य तरीके से प्राप्त की गई छवि की स्क्रीनिंग करना, या आपके पास पहले से मौजूद छवि पर ब्लॉकलिस्ट-केंद्रित खोज चलाने के लिए search_type स्विच करना।

मिलानों को एक अभिनेता मानचित्र में बदलना

एक संदिग्ध खाते से शुरू होने वाली व्यावहारिक कार्यप्रणाली:

1. चेहरे की खोज करें। total_matches: 12 — बारह खाते, एक व्यक्ति।
2. vendor_data पढ़ें। आपकी अपनी बारह खाता आईडी, कोई जुड़ने की आवश्यकता नहीं है।
3. समयरेखा पढ़ें। verification_date मानों को क्लस्टर करें। एक साथ बनाए गए खाते वर्षों से बनाए गए खातों से परिचालन रूप से भिन्न होते हैं।
4. session_id पर धुरी। प्रत्येक सत्र के डिवाइस और नेटवर्क चेतावनियों को खींचें। DUPLICATED_DEVICE_FINGERPRINT साझा करने वाले चेहरे क्लस्टर को कसते हैं; असंबंधित उपकरणों पर खाते एक अलग व्यवस्था हो सकते हैं।
5. विस्तार करें। चरण 4 में सामने आए डिवाइस और आईपी रेंज उन खातों को खींच लेंगे जिन्हें चेहरे की खोज ने छोड़ दिया — क्योंकि एक अलग व्यक्ति ने उन जाँचों को पूरा किया।
6. एक बार निर्णय लें, पहचानकर्ताओं पर लागू करें। यदि क्लस्टर को दुरुपयोग की पुष्टि हो जाती है, तो प्रत्येक एंट्री-टाइप ब्लॉकलिस्ट पर पुष्टि की गई reference_session_id पोस्ट करें जिसकी आपको परवाह है — चेहरा, डिवाइस, आईपी, ईमेल, फोन, दस्तावेज़। यह प्रति सूची एक कॉल है, और प्रत्येक कॉल उस सत्र से सही मान को स्वचालित रूप से निकालती है, इसलिए कुछ भी हाथ से दोबारा टाइप नहीं किया जाता है।

छह चरण, एक प्रारंभिक बिंदु, और कहीं भी कोई प्रॉम्प्ट निरीक्षण नहीं। ट्रैफिक लेयर आपको बताती है कि इस खाते में कुछ गड़बड़ है। यह आपको बताता है कि वास्तव में कितने खाते हैं।

स्पष्ट रूप से कहना उचित है: एक 1:N चेहरे की खोज मॉडल निष्कर्षण को नहीं रोकती है और न ही इसका पता लगाती है। फेस सर्च को आपके एपीआई ट्रैफिक की कोई दृश्यता नहीं है। यह खातों को लोगों में बदलता है, जिससे आप एक पूरे क्लस्टर में एक अलर्ट पर कार्य कर सकते हैं, न कि एक पंक्ति पर। मॉडल-स्तरीय आउटपुट नियंत्रण और सिमेंटिक ट्रैफिक पहचान अलग-अलग परतें हैं, और वे मॉडल प्रदाता की जिम्मेदारी बनी हुई हैं।

उपयोग के मामले

एआई एपीआई प्लेटफॉर्म जो एक व्यवहारिक अलर्ट को एक ऑपरेटर द्वारा नियंत्रित पूर्ण खाता सेट में हल करते हैं।

फ्री-टियर और क्रेडिट दुरुपयोग — एक व्यक्ति, कई परीक्षण खाते, कम दांव के साथ वही पहचान समस्या है।

मार्केटप्लेस और गिग प्लेटफॉर्म प्रतिबंधित विक्रेताओं, ड्राइवरों या कूरियर को फिर से पंजीकरण करते हुए पकड़ते हैं।

आई-गेमिंग एकल-खाता नियमों और आत्म-बहिष्कार को लागू करता है, जहाँ एक लौटने वाला बहिष्कृत खिलाड़ी केवल एक दुरुपयोग का मामला नहीं, बल्कि एक नियामक विफलता है।

वित्तीय सेवाएं सिंथेटिक-पहचान रिंगों की पहचान करती हैं जहाँ एक वास्तविक चेहरा कई मनगढ़ंत पहचानों में फैला होता है।

अक्सर पूछे जाने वाले प्रश्न

क्या मेरा चेहरा सूचकांक अन्य डिडिट ग्राहकों के साथ साझा किया जाता है?

नहीं। फेस सर्च आपके अपने एप्लिकेशन द्वारा आपके अपने सत्यापन के माध्यम से बनाए गए सूचकांक के विरुद्ध चलता है। यह एक क्रॉस-ग्राहक खोज नहीं है।

कौन नियंत्रित करता है कि एक चेहरा सूचकांक में प्रवेश करता है?

एक सत्यापन सत्र या एक निष्क्रिय जीवंतता कॉल पर save_api_request=true। आप तय करते हैं कि क्या नामांकित किया गया है और आप प्रतिधारण को नियंत्रित करते हैं, आपकी अपनी गोपनीयता सूचना और बायोमेट्रिक डेटा को संसाधित करने के कानूनी आधार के अनुरूप।

मुझे किस समानता थ्रेशोल्ड का उपयोग करना चाहिए?

इस बात से अवगत रहें कि ट्यूनिंग कहाँ लागू होती है। स्टैंडअलोन एंडपॉइंट पर, निश्चित हिट (FACE_IN_BLOCKLIST, DUPLICATED_FACE) को संभावित हिट (POSSIBLE_FACE_IN_BLOCKLIST, POSSIBLE_DUPLICATED_FACE) से अलग करने वाले समानता बैंड आंतरिक रूप से निश्चित होते हैं — प्रति-एप्लिकेशन थ्रेशोल्ड ट्यूनिंग वर्कफ़्लो जीवंतता जांच पर लागू होती है, न कि POST /v3/face-search/ पर। तो स्टैंडअलोन पथ पर, प्रति मिलान similarity_percentage पढ़ें और एप्लिकेशन लॉजिक में अपनी खुद की बार लागू करें, और POSSIBLE_* चेतावनियों को अपनी समीक्षा कतार के रूप में मानें, न कि अपनी अस्वीकृति कतार के रूप में।

यह बड़े पैमाने पर कितनी तेजी से काम करता है?

दो सेकंड से भी कम समय की प्रतिक्रिया।

क्या मैं ऐसे चेहरे की खोज कर सकता हूँ जो कभी डिडिट सत्यापन से नहीं गुजरा?

हाँ। किसी भी स्वीकृत प्रारूप में कोई भी user_image काम करता है। यदि कोई चेहरा नहीं पाया जाता है तो कॉल HTTP 400 लौटाता है।

क्या यह वास्तव में मुफ्त है?

हाँ — फेस सर्च 1:N डिडिट पहचान सत्यापन के साथ मुफ्त है। कोई प्रति-खोज शुल्क नहीं है। आप सत्यापन के लिए भुगतान कर रहे हैं जो सूचकांक बनाता है, पूर्ण बंडल के लिए $0.33 पर, जिसमें प्रत्येक महीने के पहले 500 मुफ्त हैं।

क्या होगा यदि एक ही व्यक्ति के वैध रूप से दो खाते हैं?

तो DUPLICATED_FACE बिल्कुल वही सूचनात्मक संकेत है जिसे इसे डिज़ाइन किया गया है — यही कारण है कि यह अस्वीकार नहीं करता है। अपनी उत्पाद के नियमों के अनुसार उन्हें मर्ज करें, अनुमति दें, या उपयोगकर्ता से पूछें।

शुरू करने के लिए तैयार हैं?

फेस सर्च प्रत्येक डिडिट खाते पर उपलब्ध है, बिना किसी अलग उत्पाद को खरीदने के।

• दस्तावेज पढ़ें — फेस सर्च 1:N अवलोकन और फेस ब्लॉकलिस्ट के लिए सूचियाँ एपीआई।
• उत्पाद देखें — उपयोगकर्ता सत्यापन।
• मूल्य निर्धारण की जाँच करें — फेस सर्च 1:N मुफ्त है; सूचकांक बनाने वाला सत्यापन बंडल $0.33 है।
• मुफ्त में शुरू करें — business.didit.me, प्रति माह 500 केवाईसी सत्यापन बिना किसी लागत के।