الانتقال إلى المحتوى الرئيسي

نظرة عامة

البحث بالوجه هو بحث بيومتري بنسبة 1:N: تأخذ Didit أكبر وجه تم اكتشافه في user_image وتبحث عنه في فهرس البحث بالوجه الخاص بتطبيقك — الوجوه المسجلة من جلسات التحقق، واستدعاءات API المستقلة المحفوظة، وعمليات رفع الوجوه المباشرة في الملف الشخصي للمستخدم، وقوائم الحظر/السماح الخاصة بك. وهو يختلف عن مطابقة الوجه، التي تكون بنسبة 1:1 — تقارن مطابقة الوجه صورة سيلفي بالصورة الشخصية على مستند محدد، بينما يبحث البحث بالوجه عمّا إذا كنا قد رأينا هذا الشخص في أي مكان من قبل. يجدر بك فهم سلوكين قبل تحليل التقرير:
  • تطابقات قائمة الحظر وحدها هي التي تؤدي إلى الرفض. تكون قيمة face_search.status هي Declined فقط عند إطلاق تحذير FACE_IN_BLOCKLIST أو POSSIBLE_FACE_IN_BLOCKLIST. أما التطابقات المكررة وحدها فترجع Approved — افحص matches وwarnings، وليس مجرد status.
  • الحفظ والتسجيل الاختياريان. عندما تكون قيمة save_api_request=true (الافتراضية)، يتم حفظ الاستدعاء كجلسة من نوع API ويتم تسجيل الوجه الذي تم البحث عنه في فهرس البحث بالوجه الخاص بك. الوجوه المسجلة بواسطة استدعاءات البحث بالوجه تُستثنى من نتائج البحث بالوجه المستقبلية، لذا لن تتطابق عمليات البحث المتكررة مع بعضها البعض أبدًا. مرّر save_api_request=false لإجراء استعلام لمرة واحدة: لن يتم تخزين أي شيء ولن يتم تسجيل الوجه.

أين تظهر النتائج

البحث بالوجه هو API مستقل. وتُعاد نتائج البحث بشكل متزامن، في استجابة POST /v3/face-search/ فقط، ككائن face_search فردي في المستوى الأعلى:
لا توجد مصفوفة بصيغة الجمع face_searches[] في أي مكان — فإن اصطلاح المصفوفات بصيغة الجمع المستخدم في id_verifications[] وaml_screenings[] وliveness_checks[] على endpoint الخاص بقرار الجلسة لا ينطبق هنا. عندما تكون قيمة save_api_request=true (الافتراضية)، يتم حفظ الاستدعاء أيضًا كجلسة من نوع API:
  • Business Console — تظهر الجلسة في قائمة الجلسات مع صورة البحث والتطابقات والتحذيرات.
  • GET /v3/session/{sessionId}/decision/ — يمكن استرجاعها باستخدام request_id المُعاد كمعرّف للجلسة. تظهر البيانات المحفوظة كمدخل FACE_SEARCH في features[] وكعنصر في liveness_checks[] يحمل matches المخزنة (مع قيم match_image_url موقعة حديثًا) وwarnings — وليس ككائن face_search.
عندما تكون قيمة save_api_request=false، يكون request_id معرّف ارتباط UUID مؤقتًا: لا يتم تخزين الجلسة مطلقًا، لذا لا يمكن جلبها من وحدة التحكم أو من endpoint القرار.

المخطط

راجع البحث بالوجه في مرجع نماذج البيانات للاطلاع على جداول الحقول القياسية. يعكس الشكل أدناه ما يعيده الـ endpoint فعليًا في وقت التشغيل.
ملاحظات الحقول:
  • الحد الأقصى لمصفوفة matches[] هو 5 مدخلات أعلى من الحد الأدنى للتشابه، مرتبة تنازليًا حسب التشابه (يرتب search_type=blocklisted_or_approved المدخلات المدرجة في قائمة الحظر أولاً، ثم المدرجة في قائمة السماح، ثم حسب التشابه).
  • source يوضح لك المكان الذي تم تسجيل الوجه المتطابق منه: session — جلسة تحقق أو استدعاء API مستقل محفوظ؛ imported — وجه تم رفعه مباشرة إلى ملف تعريف المستخدم؛ list_entry — وجه مرتبط بإحدى قوائمك؛ retained_template — قالب بيومتري خالٍ من الصور احتفظ به التطبيق بعد حذف الجلسة المصدر. تكون قيم session_id وsession_number وstatus وapi_service هي null لتطابقات imported وlist_entry وretained_template.
  • تطابقات retained_template تحمل vendor_user_id وvendor_data وbiometric_template_id، ودائمًا ما تكون null لكل من match_image_url وuser_details وكل ما يتعلق بالجلسة: فالجلسة التي أنشأت الوجه لم تعد موجودة ولا يحتوي القالب على أي صورة أو بيانات هوية. تكون قيمة is_blocklisted دائمًا false للقالب المحتفظ به؛ ويتم الإبلاغ عن الوجه المدرج في قائمة الحظر بشكل منفصل كتطابق list_entry. أزل القالب نهائيًا باستخدام DELETE /v3/biometric-templates/{biometric_template_id}/.
  • api_service هو نوع API المستقل للجلسة المتطابقة (بأحرف كبيرة، مثل PASSIVE_LIVENESS) ويكون null عندما يكون الوجه المتطابق قادمًا من جلسة تحقق عادية في سير العمل.
  • user_details يأتي من التحقق من المستند الخاص بالجلسة المتطابقة. بالنسبة لتطابقات source: imported، يتم ملؤه من الملف الشخصي للمستخدم بدلاً من ذلك (يتم تعيين full_name، وتكون قيمة document_type/document_number هي null)؛ ويكون null عند عدم وجود بيانات هوية (على سبيل المثال جلسات كشف الحيوية فقط).
  • تستخدم التحذيرات شكلاً مصغرًا مقارنةً بتحذيرات سير العمل: لا يوجد node_id. يحدد عقد الاستجابة الموثق (FaceSearchResponseSerializer) الحقول الخمسة risk وadditional_data وlog_type وshort_description وlong_description؛ كما يحمل الـ payload في وقت التشغيل حقل feature إضافيًا، والذي يكون دائمًا "LIVENESS" هنا. راجع تحذيرات البحث بالوجه.
  • لا يتم استبعاد تطابقات نفس المستخدم — على عكس اكتشاف التكرار في سير العمل، لا يقوم الـ endpoint المستقل بتصفية الجلسات السابقة التي تحمل نفس vendor_data، لذلك فإن المستخدم الشرعي العائد سيتطابق مع جلساته السابقة.

قيم الحالة

يتم اشتقاق face_search.status في المستوى الأعلى من warnings[]. تعكس قيمة status على مستوى التطابق نتيجة التحقق من الجلسة المتطابقة وهي مستقلة. ملاحظة: عندما لا تحتوي صورة البحث على وجه يمكن اكتشافه، يعيد الـ API الرمز HTTP 400 مع {"error": "No face detected in the image"} قبل إنشاء كائن face_search — ولا توجد حالة Declined لتلك الحالة. كما يؤدي عدم كفاية الرصيد إلى إرجاع HTTP 403 قبل أي معالجة للصور.

أمثلة

Approved — تطابق مكرر، لا وجود لقائمة الحظر

Declined — تطابق مع قائمة الحظر

ذات صلة

عندما تكون save_api_request=true، تكون قيم match_image_url عبارة عن عناوين URL موقّعة وقصيرة الأجل — أعد استدعاء endpoint لقرار الجلسة باستخدام request_id المُعاد للحصول على روابط جديدة. وعندما تكون save_api_request=false، فإنها تكون مسارات تخزين داخلية وليست قابلة للتنزيل مباشرةً. قم بتخزين معرّف الجلسة المتطابقة، والحالة، وsimilarity_percentage فقط من جانبك — ولا تحتفظ بالصورة البيومترية الأصلية.
آخر تعديل في ٧ نوفمبر ٢٠٢٦