البحث بالوجه 1:N: الكشف عن جميع الحسابات التي يتحكم بها شخص واحد (AR)

المشغل الذي يدير أربعين حسابًا على منصتك لديه أربعين عنوان بريد إلكتروني، وربما أربعين أداة دفع، وربما أربعين جهازًا. ما ليس لديهم هو أربعين وجهًا.

إذا كان أي جزء من تدفق الوصول الخاص بك يلتقط صورة ذاتية (سيلفي)، فأنت بالفعل تحتفظ بالمعرف الوحيد الذي يصعب تكراره حقًا. البحث بالوجه 1:N هو الاستدعاء الذي يستخدمه — طلب واحد، وجه واحد، ويعود كل حساب في نظامك الخاص الذي قام نفس الشخص بالتحقق منه.

إنه مجاني مع تحقق هوية Didit، ويعود في أقل من ثانيتين، ويعمل تلقائيًا أثناء التحقق من الحيوية ضمن جلسة التحقق.

النقاط الرئيسية

• POST /v3/face-search/ يبحث عن وجه مقابل الوجوه التي قام تطبيقك الخاص بتسجيلها — الجلسات التي تعمل مع save_api_request=true — وليس فهرسًا عالميًا مشتركًا.
• تأتي المطابقات مع بيانات vendor_data الخاصة بك على كل منها، بحيث تتطابق النتائج مباشرة مع معرفات حساباتك.
• وضعان: most_similar لإلغاء التكرار والمستخدمين العائدين، blocklisted_or_approved لفحص قوائم الحظر.
• الحالة status تكون "Declined" فقط عند وجود تطابق في قائمة الحظر. المكررات تعود بـ "Approved" مع تحذير DUPLICATED_FACE — وهي معلومات بطبيعتها، لأن سياسة إلغاء التكرار هي سياسة خاصة بك.
• الاستجابة هي كائن face_search فردي، وليس مصفوفة. هذا يربك البعض.
• مجاني مع تحقق Didit. استجابة في أقل من ثانيتين. يعمل تلقائيًا أثناء التحقق من الحيوية.

ماذا يعني 1:N، ولماذا هو الأداة المناسبة

تطابق الوجه 1:1 يجيب على سؤال "هل هذا هو الشخص في هذه الوثيقة؟" هذا سؤال تحقق، وهو ما يحدث أثناء الإعداد.

البحث 1:N يجيب على سؤال مختلف: "من بين جميع الأشخاص الذين قمت بالتحقق منهم بالفعل، هل هذا أحدهم؟" تدخل صورة واحدة، وتخرج كل تطابق في فهرسك.

بالنسبة لإساءة استخدام الحسابات المنسقة، السؤال الثاني هو المهم. وصف تقرير Anthropic عن حملات التقطير الإسناد المبني على إشارات علائقية — طرق دفع مشتركة، توقيت منسق، بنية تحتية مشتركة. البحث البيومتري 1:N هو نفس الفئة من الإشارات، مصدرها المعرف الأكثر تكلفة الذي يجب على المشغل تكراره.

الفهرس لك وحدك. يعمل البحث بالوجه مقابل الوجوه التي سجلها تطبيقك الخاص من خلال التحققات السابقة — الجلسات التي تحتوي على save_api_request=true، أو التحقق من الحيوية السلبي (Passive Liveness) مع save_api_request=true. إنه ليس بحثًا عبر مستخدمي عملاء Didit الآخرين. إذا لم تكن قد سجلت وجوهًا، فلا يوجد شيء للبحث عنه.

واجهة برمجة التطبيقات (API)

الطلب

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 ميجابايت. لا يتم قبول ملفات PDF. يجب أن تحتوي الصورة على وجه واحد على الأقل قابل للكشف؛ عندما يكون هناك عدة وجوه، يفوز أكبر مربع محيط.

اختياري:

• search_type — most_similar (افتراضي) لإلغاء التكرار واكتشاف المستخدمين العائدين، أو blocklisted_or_approved لفحص قوائم الحظر.
• save_api_request — تسجيل هذه الصورة في فهرسك.
• vendor_data — معرفك الخاص للموضوع.

الاستجابة

تحمل الاستجابة كائن face_search فردي. تعيد معظم ميزات Didit مصفوفات متعددة، لذا هذا هو الشكل الوحيد الذي يستحق القراءة بعناية قبل كتابة المحلل اللغوي.

{
  "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".

التكرار ليس رفضًا. إنه معلومات. ترفض Didit عمدًا اتخاذ قرار إلغاء التكرار نيابة عنك، لأن التكرارات لها تفسيرات مشروعة وأنت وحدك من يعرف قواعد منتجك.

التحذيرات

التحذير	المعنى
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" مع 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. التوسع. ستجلب الأجهزة ونطاقات IP التي تم اكتشافها في الخطوة 4 حسابات فاتها البحث عن الوجه — لأن شخصًا مختلفًا أكمل تلك الفحوصات.
6. القرار مرة واحدة، والتطبيق عبر المعرفات. إذا تم تأكيد إساءة الاستخدام في التجمع، انشر reference_session_id المؤكد لكل نوع إدخال في قائمة الحظر التي تهتم بها — الوجه، الجهاز، IP، البريد الإلكتروني، الهاتف، المستند. إنه استدعاء واحد لكل قائمة، ويقوم كل استدعاء باستخراج القيمة الصحيحة تلقائيًا من تلك الجلسة، لذلك لا يتم إعادة كتابة أي شيء يدويًا.

ست خطوات، نقطة بداية واحدة، ولا يوجد فحص فوري في أي مكان. تخبرك طبقة حركة المرور أن هناك شيئًا خاطئًا في هذا الحساب. هذا يخبرك عدد الحسابات التي هو عليها بالفعل.

جدير بالذكر بوضوح: بحث الوجه 1:N لا يمنع استخراج النموذج ولا يكشف عنه. لا يمتلك البحث بالوجه رؤية لحركة مرور API الخاصة بك. إنه يحل الحسابات إلى أشخاص، وهذا ما يسمح لك بالعمل على تنبيه عبر مجموعة كاملة بدلاً من صف واحد. ضوابط إخراج مستوى النموذج واكتشاف حركة المرور الدلالية هي طبقات منفصلة، وتبقى مسؤولية مزود النموذج.

حالات الاستخدام

منصات AI API تحل تنبيهًا سلوكيًا في مجموعة الحسابات الكاملة التي يتحكم فيها المشغل.

إساءة استخدام الطبقة المجانية والائتمان — شخص واحد، العديد من الحسابات التجريبية، هي نفس مشكلة الكشف بمخاطر أقل.

الأسواق ومنصات العمل الحر تكتشف البائعين أو السائقين أو عمال التوصيل المحظورين الذين يعيدون التسجيل.

الألعاب الإلكترونية (iGaming) تفرض قواعد الحساب الفردي والاستبعاد الذاتي، حيث يعتبر اللاعب المستبعد العائد فشلًا تنظيميًا، وليس مجرد حالة إساءة استخدام.

الخدمات المالية تحدد حلقات الهوية الاصطناعية حيث ينتشر وجه حقيقي واحد عبر العديد من الهويات المزيفة.

الأسئلة المتداولة

هل يتم مشاركة فهرس وجهي مع عملاء Didit الآخرين؟

لا. يعمل البحث بالوجه مقابل الفهرس الذي أنشأه تطبيقك الخاص من خلال تحققاتك الخاصة. إنه ليس بحثًا عبر العملاء.

ما الذي يتحكم في دخول الوجه إلى الفهرس؟

save_api_request=true في جلسة تحقق أو استدعاء التحقق من الحيوية السلبي. أنت تحدد ما يتم تسجيله وتتحكم في الاحتفاظ به، بما يتوافق مع إشعار الخصوصية الخاص بك والأساس القانوني لمعالجة البيانات البيومترية.

ما هو عتبة التشابه التي يجب أن أستخدمها؟

كن على دراية بالمكان الذي ينطبق فيه الضبط. في نقطة النهاية المستقلة، نطاقات التشابه التي تفصل بين التطابقات المؤكدة (FACE_IN_BLOCKLIST، DUPLICATED_FACE) عن التطابقات المحتملة (POSSIBLE_FACE_IN_BLOCKLIST، POSSIBLE_DUPLICATED_FACE) ثابتة داخليًا — ينطبق ضبط العتبة لكل تطبيق على فحص حيوية سير العمل، وليس على POST /v3/face-search/. لذا في المسار المستقل، اقرأ similarity_percentage لكل تطابق وطبق معيارك الخاص في منطق التطبيق، وتعامل مع تحذيرات POSSIBLE_* كقائمة مراجعة بدلاً من قائمة الرفض.

ما مدى سرعته على نطاق واسع؟

استجابة في أقل من ثانيتين.

هل يمكنني البحث عن وجه لم يمر أبدًا بتحقق Didit؟

نعم. أي user_image بتنسيق مقبول يعمل. إذا لم يتم اكتشاف وجه، يعيد الاستدعاء HTTP 400.

هل هو مجاني حقًا؟

نعم — البحث بالوجه 1:N مجاني مع تحقق هوية Didit. لا توجد رسوم لكل بحث. أنت تدفع مقابل التحققات التي تبني الفهرس، بسعر 0.33 دولار للحزمة الكاملة، مع أول 500 فحص مجاني كل شهر.

ماذا لو كان نفس الشخص لديه حسابين بشكل مشروع؟

إذن DUPLICATED_FACE هي بالضبط الإشارة المعلوماتية التي صممت لتكونها — ولهذا السبب لا ترفض. ادمجها، اسمح بها، أو اسأل المستخدم، وفقًا لقواعد منتجك.

هل أنت مستعد للبدء؟

البحث بالوجه متاح في كل حساب Didit، بدون منتج منفصل للشراء.

• اقرأ الوثائق — نظرة عامة على البحث بالوجه 1:N وواجهة برمجة تطبيقات القوائم (Lists API) لقوائم حظر الوجه.
• شاهد المنتج — التحقق من المستخدم.
• تحقق من الأسعار — البحث بالوجه 1:N مجاني؛ حزمة التحقق التي تبني الفهرس تبلغ 0.33 دولار.
• ابدأ مجانًا — business.didit.me، 500 تحقق KYC شهريًا بدون تكلفة.