نظرة عامة
البحث بالوجه هو بحث بيومتري بنسبة 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 — تطابق مع قائمة الحظر
ذات صلة
- تحذيرات البحث بالوجه — كل رمز تحذير يمكن أن يصدر عن عملية البحث
- مرجع API الخاص بالبحث بالوجه — معامِلات الطلب وأنماط
search_type - نماذج البيانات — البحث بالوجه — المخطط المعتمد
- webhook — بيانات payload لـ
status.updatedللجلسات المحفوظة
عندما تكون
save_api_request=true، تكون قيم match_image_url عبارة عن عناوين URL موقّعة وقصيرة الأجل — أعد استدعاء endpoint لقرار الجلسة باستخدام request_id المُعاد للحصول على روابط جديدة. وعندما تكون save_api_request=false، فإنها تكون مسارات تخزين داخلية وليست قابلة للتنزيل مباشرةً. قم بتخزين معرّف الجلسة المتطابقة، والحالة، وsimilarity_percentage فقط من جانبك — ولا تحتفظ بالصورة البيومترية الأصلية.