20 بالمئة من جميع استجابات الويب «موافق» التي تتلقاها أنظمة الذكاء الاصطناعي ليست كذلك

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

وهذا عذر وجيه للنطاقات كي تفعل ما أراد كثير منها فعله منذ وقت طويل: إتاحة محتواها للمستخدمين المسجلين دخولهم فقط (مع أن Googlebot يُسمح له عادةً بالوصول دون قيود). أتمّ Facebook تطبيق هذه السياسة تدريجيًا في عام 2023، وفعل Twitter/X الشيء نفسه في العام نفسه. وستعتمد Reddit هذه السياسة في وقت لاحق من هذا الشهر.

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

وفي أماكن أخرى، ارتفعت التدابير الموجهة مباشرةً إلى التصدي للروبوتات (بدلًا من تسجيل المستخدمين) بأكثر من 58% على أساس سنوي، وفقًا لـCloudflare؛ ومن الطبيعي أن يدفع هذا النشاط المتصاعد للروبوتات المواقع الإلكترونية إلى التدقيق في عناوين VPN والوكيلة، ما قد يحرم المستخدمين الشرعيين من الوصول، إلى جانب حجب أي حركة مرور «ضارة».

أما الجانب الذي ألاحظه شخصيًا، فهو أنني أواجه استجابات «حظر» أو اختبارات تحدٍّ بوتيرة متزايدة، إلى حد أنني قد أتخلى عن موقع يبدأ بعرضها؛ وبما أن حواجز CAPTCHA ثبت أنها تثني المستخدمين والعملاء المحتملين عن استخدام المواقع، يمكن للمرء أن يتخيل حجم الضغط الذي يدفع أصحاب النطاقات إلى اعتمادها رغم هذا الجانب السلبي.

اختبار CAPTCHA من archive.is، وهو أحد المواقع الكثيرة التي اعتمدت اختبارات التحدي، غالبًا ردًا على الطلبات الآلية المفرطة، لا الطلبات البشرية.

هذا الاحتكاك الجديد والمتزايد يعود جزئيًا إلى أسباب لوجستية (إذ لا تستطيع جميع النطاقات تحمّل هذا الضغط)، لكنه غالبًا ما يكون أيضًا ضربًا من أساليب التفاوض، لمعرفة ما إذا كانت شركات الذكاء الاصطناعي ستقدم شكلًا من أشكال التعويض، منفردة أو جماعيًا، مقابل كل تلك البيانات التي تتوق إليها بشدة، والتي ظلت مجانية طوال هذه المدة حتى الآن.

نظرًا إلى أن زواحف الذكاء الاصطناعي تعمل على نطاق واسع، فإنها تميل إلى استخدام نسخ «بلا واجهة» من Chrome ضمن إطار عمل Playwright. وفي الوقت الراهن، تؤدي هذه الطريقة، لدى عدد متزايد من النطاقات، إلى خطأ 403 («ممنوع») (أي إن المضيف يعرف أنك حركة مرور آلية، ويطلب منك المغادرة فورًا):

يحاول تثبيت محلي لـchangedetection.io استطلاع موقع، لكن الموقع لا يستسيغ المتصفح الذي يكتشفه إطار العمل ويستخدمه، فيُرجع استجابة 403 («ممنوع»).

المطلوب هو استجابة العميل «200» («موافق»)، حتى لو اضطر المرء إلى دفع مبلغ كبير لمزرعة وكلاء سكنيين، إلى جانب اللجوء إلى حيل خفية أخرى متنوعة غير بشرية، للحصول عليها.

لا شيء أفضل من استجابة 200؛ أي إنه لا يوجد رمز استجابة للعميل يحمل إشارة إيجابية أقوى. كما أنها ليست استجابة ملتبسة؛ فهي لا تعني مطلقًا «يكاد يكون كل شيء على ما يرام»، أو «سيصبح كل شيء على ما يرام لاحقًا»، أو «يتحسن الوضع أكثر فأكثر»؛ بل تعني «كل شيء على ما يرام!». وإذا لم يكن كل شيء على ما يرام، فليست الاستجابة 200.

مرحبًا! ابتعد

لكن هذه المحدودية في التمييز، وفقًا لورقة بحثية جديدة، قد تؤدي إلى تحريف كبير في مجموعات بيانات الذكاء الاصطناعي والتقديرات الإحصائية، وإلى الإبلاغ عن حالة «جيدة» حين لا تكون كذلك.

وتقدّر الدراسة* أن نحو خُمس الاستجابات المصنفة ضمن الفئة 200 لا يتضمن أي محتوى قابل للاستخدام من الصفحة، بل يعرض هياكل مواقع فارغة أو اختبارات CAPTCHA أو قيودًا على الوصول أو صفحات بديلة.

وجاء في الورقة البحثية:

«20.9% من الصفحات التي يتلقاها عميل ثابت برمز الحالة 200 لا تتضمن المحتوى الرئيسي للصفحة: هياكل التطبيقات، واختبارات الروبوتات، وصفحات الحظر، وصفحات الأخطاء والعناصر النائبة، والمحتوى الجزئي.»

وفي هذا الصدد، تتعثر الأنظمة الآلية التي لا تتحلى بالصبر بسبب قصورها هي، إذ يُسمح لها باعتبار استجابة «200» دليلاً على نجاح جلب الصفحة، حتى عندما لا يؤدي الجلب إلا إلى ظهور حاجز CAPTCHA أو جدار دفع أو عائق آخر.

وتعرض الورقة البحثية الأنواع السبعة للمحتوى التي كثيرًا ما تعقّد استجابة 200:

الفئات السبع للمحتوى التي لا تمت بصلة إلى «الموافقة» في استجابة 200. المصدر

على مدى ثلاثة أيام، اختُبرت في الدراسة 10,307 عناوين ويب باستخدام برنامج أساسي لجلب صفحات الويب ومتصفح قادر على تحميل JavaScript، وصُنفت الاستجابات بحسب المحتوى الذي جرى جلبه، لا بحسب رموز حالة HTTP.

كانت أكبر فئتين من استجابات 202 «غير القابلة للاستخدام» هما هياكل المواقع الفارغة وصفحات الخطأ أو الصفحات البديلة، وقد شكّلتا معًا أكثر من ثلثي حالات الإخفاق.

في حالة هياكل المواقع الفارغة، قد يعرض الموقع قوائمه وأدوات التنقل، بينما يترك المقال أو قائمة المنتجات المطلوبة فارغة؛ أما في الحالة الأخيرة، فقد تظهر صفحة لا صلة لها بالموضوع أو الصفحة الرئيسية بدلًا من المحتوى المطلوب. ومع ذلك، قد تحصل الحالتان على رمز حالة HTTP 200 نفسه الذي تحصل عليه عملية جلب ناجحة تقدم محتوى مفيدًا وقابلًا للاستخدام.

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

بعد ذلك، يمكن الاستعانة بأدوات المتصفح الأعلى استهلاكًا للموارد فقط عندما يبدو أن تحميل الصفحة لم يكتمل على النحو الصحيح. وإضافة إلى ذلك، يمكن لتقييمات الذكاء الاصطناعي التحقق مما إذا كانت المصادر المستشهَد بها تتضمن المعلومات المتوقعة فعلًا، بدلًا من افتراض أن استجابة HTTP 200 تعني نجاح جلب المحتوى.

ويشير مؤلف العمل الجديد أيضًا إلى أن «الاستدلالات التقريبية البسيطة» تستطيع بسهولة تحديد نحو 86% من الاستجابات غير القابلة للاستخدام، بالاستناد إلى فحوص أساسية لطول الصفحة، وعمليات إعادة التوجيه، ومدى تشابه الصفحات مع صفحات غير موجودة:

مقارنة استراتيجيات جلب صفحات الويب: أتاح عرض الصفحات التي وُسِمت بأنها مشبوهة فقط استعادة قدر أكبر قليلًا من المحتوى القابل للاستخدام (81.4%) مقارنة بعرض كل الصفحات (80.3%)، مع خفض متوسط وقت جلب الصفحة من 20.6 إلى 5.8 ثوانٍ.

لماذا تكثر استجابات 200 الخاطئة؟

دار بعض الجدل على مر السنين في أوساط المطورين حول إمكانية استخدام خطأ 202 («مقبول») («قُبل الطلب، لكنه لم يُستكمل بعد») لإزالة الالتباس بشأن هذه الطلبات التي فشلت رغم إرجاعها حالة 200؛ لكن الواقع أن 202 لا يمكن أن يشمل جميع الحالات الواردة في الورقة البحثية الجديدة، ولا يوجد رمز قائم يستطيع ذلك.

مع أن الورقة البحثية لا تتناول هذه المسألة بالتفصيل، فقد يكون من المفيد أن تبحث أعمال لاحقة ذات صلة أسباب سماح مالكي النطاقات بظهور أخطاء 200.

قد يكون أحد الأسباب أن كل ما لا يحمل حالة 200 يُعد في الأساس نوعًا من صفحات الخطأ أو العوائق، بما في ذلك أكثرها شيوعًا، وهو أخطاء 404 («غير موجود»)، حيث يكون المحتوى المستهدف مفقودًا ببساطة. ويعتقد بعض المستخدمين أن كثرة هذه الأخطاء ستؤدي إلى عقوبات في تحسين محركات البحث (وربما تحسين الظهور في محركات التوليد، GEO)، إلا أن Google تنفي ذلك.

والواقع أن Google تعتبر استجابات 200 الخاطئة أخطاء 404 «لينة»، ومن الواضح أنها مرشحة لأن تُعامل على أنها مشكلة أكبر من أخطاء 404 العادية، لأنها في جوهرها نتائج «مضللة»، سواء أكان ذلك متعمدًا أم لا.

انحراف الاستشهادات

إذا بدا كل هذا تدقيقًا مفرطًا في التفاصيل، فلا بد من أخذ حجم البيانات، الذي يبلغ مستوى البيتابايت، في الحسبان؛ فهذه البيانات تُجمع باستمرار (أو تُبذل محاولات لجمعها) لأغراض تدريب الذكاء الاصطناعي. وإذا كان خُمس هذه البيانات بالكامل غير موثوق أو مضللًا صراحةً، فمن الصعب تجاهل العواقب اللاحقة باعتبارها مجرد «عدم دقة جانبي»؛ إذ يمكن لهذه الاستجابات الزائفة أن تؤثر سلبًا وبدرجة كبيرة في توزيع البيانات ضمن مجموعات البيانات وفي نتائج تدريب نماذج الذكاء الاصطناعي عليها.

فعلى سبيل المثال، تتعلق إحدى المشكلات البارزة المرتبطة باستجابات 200 الخاطئة بـ«انحراف الاستشهادات»، وهي حالة لا تعود فيها صفحة الويب التي استُشهد بها أصلًا دليلًا يدعم إجابة أنشأها الذكاء الاصطناعي؛ أي إن الصفحة ربما تكون قد تغيرت، أو حُذف منها النص ذي الصلة، أو أصبح الرابط يؤدي إلى مكان آخر.

ووجدت الدراسة الجديدة أن الانحراف الظاهري في الاستشهادات ارتفع من 5.8% إلى 21.9% عند قبول جميع استجابات HTTP 200 على أنها عمليات جلب ناجحة، بصرف النظر عما تتضمنه.

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

قل فقط إنه كذلك!

وأظهرت الاختبارات التي استخدمت عمدًا عناوين ويب غير موجودة هذه المشكلة أيضًا. فعندما طُلبت مسارات عشوائية ومختلقة من مواقع الويب، أعادت 13.1% من المواقع التي استجابت رمز الحالة 200 («موافق»)، رغم أن الصفحات المطلوبة لم تكن موجودة^†.

«أعادت 13.1% من المواقع التي استجابت لمسبار المسارات العشوائية حالة 200 (S1 10.5%، S2 13.3%، S3 17.3%، S4 13.7%، S5 13.1%). وكل استجابة من هذا النوع هي بحكم تعريفها خطأ 404 لين، لكن ليس كل استجابة تشير إلى ذلك.»

«في تحليل استكشافي لـ172 استجابة من نوع 404 الناعمة، صنّف المعلِّق 98 منها على أنها صفحات خطأ أو صفحات بديلة، و32 على أنها هياكل فارغة، و28 على أنها محتوى: فالصفحة الرئيسية أو صفحة القوائم التي تُعرض عند مسار عشوائي تبدو كأنها صفحة عادية».

الخلاصة

إذا جرى التعرّف على المشكلة على مستوى أعلى، فقد تتمكن IANA من إنشاء رمز حالة HTTP جديد وأكثر ملاءمة، مثل [X] («نجح الطلب، لكن المحتوى المطلوب لم يُقدَّم»). ومع أن هذا سيصف ما يحدث بالفعل، فإنه سيتطلب بطبيعة الحال قدرًا غير مرجح من الإلمام بتفاصيل المعاملة من جانب المضيف.

توجد بالفعل رموز مشابهة، لكن لا ينطبق أي منها تمامًا: 451 («غير متاح لأسباب قانونية»)، وهو ملتبس ومثير للقلق إلى حد ما (!); و206 («محتوى جزئي»)، وهو ملائم من الناحية التقنية، لكنه مخصص للبيانات غير المكتملة (عمليات الجلب)؛ والرمز المثير للدهشة لوجوده 203 («معلومات غير موثوقة»)، الذي أُنشئ عام 1997، ولا يرتبط إلا ارتباطًا هامشيًا بحالة الاستخدام المطروحة هنا.

لعل أقرب الخيارات هو في الواقع 103 («تلميحات مبكرة»)، وهو اسم لا يوحي بوظيفته، ويشير إلى أن بعض موارد عنوان URL لم تُحمَّل بعد (مع أن هذا سيكون بوضوح تفسيرًا خاطئًا إلى حد بعيد للمقصود من الرمز).

* بعنوان ‘عندما لا تكون استجابة 200 OK جوابًا: إخفاقات الجلب الصامتة في اكتساب محتوى الويب القائم على الوكلاء.‘ يرجى الانتباه إلى أن الورقة مكتوبة، على ما يبدو، لتكون قابلة للقراءة آليًا في المقام الأول، وربما للاستعلام منها بواسطة الذكاء الاصطناعي، كما أن قراءتها ليست سهلة بحد ذاتها.

^† أعتذر عن الاقتباس الآلي، لكن الورقة بأكملها مكتوبة بهذه الطريقة، كما أشرت أعلاه، لتكون «قابلة للقراءة آليًا» بدلًا من أن تكون مفهومة للبشر، مع أنها لا تصل إلى حد تقديمها بصيغة JSON.

نُشر لأول مرة يوم الأربعاء، 4 نوفمبر 2026