نظرة عامة
يُصدر البحث بالوجه (Face Search) مجموعة صغيرة من التحذيرات حتى يتمكن فريقك من معرفة سبب إرجاع البحث للحالةApproved أو Declined. تُعاد التحذيرات في مصفوفة face_search.warnings[] ضمن استجابة POST /v3/face-search/ (راجع تقرير البحث بالوجه).
تستخدم التحذيرات هنا هيكلاً مصغراً مقارنة بتحذيرات سير العمل: لا يوجد node_id. يحدد عقد الاستجابة الموثق خمسة حقول — risk وadditional_data وlog_type وshort_description وlong_description — كما يحمل payload وقت التشغيل بشكل إضافي حقل feature، والذي يكون دائماً "LIVENESS" في هذا الـ endpoint.
التحذيرات الصادرة
المُنتِج:
FaceSearchAPIView.add_warnings (apis/views/face_search.py:250-330)؛ اشتقاق الحالة: get_face_search_status (apis/views/face_search.py:242-248)، والذي يرفض فقط عند وجود أحد خطري قائمة الحظر.
قواعد إصدار التحذيرات الجديرة بالمعرفة:
- قائمة الحظر لها الأولوية على التكرارات. يؤدي التطابق المؤكد مع قائمة الحظر إلى كتم
DUPLICATED_FACE، ويؤدي التطابق المحتمل مع قائمة الحظر إلى كتمPOSSIBLE_DUPLICATED_FACE— فلن تحصل أبداً على كلا طرفي الزوج لنفس نطاق الثقة. - يشير
additional_dataإلى أول وجه مطابق فقط، حتى لو كانتmatches[]تحتوي على عدة وجوه. تحمل تحذيرات قائمة الحظر{blocklisted_session_id, blocklisted_session_number, api_service}؛ وتحمل تحذيرات التكرار{duplicated_session_id, duplicated_session_number, api_service}؛ بينما يحملMULTIPLE_FACES_DETECTEDالقيمةnull. تكون قيمةapi_serviceبالأحرف الكبيرة (مثلPASSIVE_LIVENESS) أوnullلجلسات سير العمل. - الوجوه المدرجة في قائمة السماح تكتم تحذيرات التكرار — يؤدي تطابق قائمة السماح عالي الثقة إلى إزالة
DUPLICATED_FACE/POSSIBLE_DUPLICATED_FACE(ولا يؤدي أبداً إلى إزالة تحذيرات قائمة الحظر).
نصوص التحذيرات الدقيقة
بوابة التحقق من صورة البحث
عند عدم اكتشاف أي وجه فيuser_image، ترفض واجهة برمجة التطبيقات الطلب برمز HTTP 400 و{"error": "No face detected in the image"} قبل إنشاء كائن face_search — وبالتالي لا يظهر تحذير NO_FACE_DETECTED أبداً في استجابة بحث بالوجه ناجحة. يُعاد هذا كرسالة error في المستوى الأعلى، وليس ضمن warnings[].
الإعدادات القابلة للتهيئة
نطاقات التشابه التي تفصل بين التطابقات المؤكدة (FACE_IN_BLOCKLIST وDUPLICATED_FACE) والتطابقات المحتملة (POSSIBLE_FACE_IN_BLOCKLIST وPOSSIBLE_DUPLICATED_FACE) ثابتة داخلياً — إذ ينطبق ضبط الحدود لكل تطبيق على فحص الحيوية في سير العمل، وليس على هذا الـ endpoint. الخيارات التي يمكنك التحكم فيها لكل طلب هي:
search_type(القيمةmost_similar، الافتراضية |blocklisted_or_approved) — يرتب خيارmost_similarجميع الوجوه المسجلة بحسب درجة التشابه؛ بينما يقصر خيارblocklisted_or_approvedالمرشحين على الوجوه المدرجة في قائمة الحظر، والوجوه المدرجة في قائمة السماح، والوجوه المستخرجة من الجلسات المقبولة، ووجوه ملفات تعريف المستخدمين المستوردة، مع ترتيب المدخلات المدرجة في قائمة الحظر أولاً.save_api_request(القيمة الافتراضيةtrue) — يحفظ الاستدعاء كجلسة من نوع API ويسجل الوجه الذي تم البحث عنه في فهرس البحث بالوجه الخاص بك. يتم استبعاد الوجوه المسجلة عبر استدعاءات البحث بالوجه من نتائج البحث بالوجه المستقبلية. عيّنه علىfalseللاستعلام دون حفظ أو تسجيل.rotate_image(القيمة الافتراضيةfalse) — يجرّب تدويرات للصورة بزاوية 90 درجة ويحتفظ بالاتجاه الذي يحقق أفضل اكتشاف للوجه؛ وهو مفيد عندما تكون بيانات اتجاه EXIF مفقودة.
أمثلة
مطابقة في قائمة الحظر (تفرض Declined)
إشارة تكرار (تبقى الحالة Approved)
ذات صلة
- تقرير البحث بالوجه — شكل الاستجابة الكامل
- مرجع API للبحث بالوجه — معلمات الطلب
- تحذيرات مطابقة الوجه — تحذيرات المقارنة بنسبة 1:1 بين صورة السيلفي والمستند (منفصلة عن البحث بالوجه)
- نماذج البيانات — البحث بالوجه — المخطط القياسي