نموذج LLM محلي جمع الإعلانات عبر DOM ثم توقف بعد الطلب السادس

غالبًا ما يتعطل محلل تقليدي لموقع إعلانات مبوبة قبل أن ينتج أول سطر مفيد: يرد الخادم بالخطأ 403، أو يحد من معدل الطلبات، أو يعيد صفحة تُنشئها JavaScript. جرّب صاحب التجربة مسارًا مختلفًا، إذ كلّف نموذج Qwen محليًا من فئة 7B/8B بالتعامل مع الموقع من خلال متصفح عادي واستخراج البيانات اعتمادًا على مؤشرات دلالية بدلًا من فئات CSS الهشة.

في المثال البسيط، كانت المهمة العثور على محطة عمل محمولة نادرة مزودة ببطاقة رسومية محددة، وجمع الاسم والسعر والمدينة ورابط البائع. كان الوكيل يفتح نتائج البحث في Edge تحت إدارة Playwright، ويفحص DOM، ويبحث عن نقاط ارتكاز مألوفة: رمز العملة، ونص كبير مجاور، ومعرّف الإعلان داخل الرابط. وإذا كانت معلومات البائع موجودة في جزء آخر من الصفحة، كان يربط السجلات باستخدام Item ID.

لماذا كان DOM أكثر فائدة من CSS

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

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

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

أين اصطدمت التجربة بالواقع

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

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

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

ما الذي يمكن للمطور الاستفادة منه

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

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

الخلاصة العملية بسيطة: تستطيع LLM محلية صغيرة بالفعل إدارة متصفح وجمع بيانات منظمة من صفحة ديناميكية. لكن جودة الوكيل لا تُقاس بقدرته على اجتياز أي حماية بأي ثمن، بل بقدرته على احترام القيود، ورصد التناقضات، والتوقف بأمان عندما يقول الموقع «كفى».