← كل المقالات
حالة استخدام قراءة 6 دقائق

مشكلة إعادة الزحف: الحفاظ على تحديث مسارات RAG

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

ragai-trainingdata-collectionvertical-aiuse-case

التحدي

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

لقد رأينا فرقًا تبني جانب الذكاء الاصطناعي بدقة متناهية بينما تتعامل مع جانب البيانات كأمر ثانوي. يكون مسار استيعاب البيانات (ingestion pipeline) مجرد نص برمجي بلغة Python يعمل على حاسوب شخصي لأحد المطورين. يقوم بجمع البيانات من 200 رابط URL مصدري لمرة واحدة، ويفرغ محتوى Markdown نظيفًا في مخزن متجهات (vector store)، ويحتفل الجميع. بعد ستة أسابيع، تصبح نصف الإجابات تشير إلى صفحات محذوفة، أو واجهات API مهملة، أو ميزات منتج تم إطلاقها في مارس وعُدلت مجددًا في مايو.

يبدو الحل بسيطًا: أعد الزحف إلى كل مصدر أسبوعيًا. الواقع أكثر تعقيدًا. بحلول عام 2026، أصبح نحو 60% من المواقع الموثوقة تحظر زواحف الذكاء الاصطناعي (ارتفاعًا من 23% في أواخر عام 2023)، ولم تعد آليات الحماية مجرد فحوصات User-Agent بسيطة. بل أصبحت تراقب سلوك الجلسة، وإيقاع الطلبات (request rhythm)، وإشارات مستوى المصافحة (handshake-level signals). النص البرمجي البسيط الذي كان يعمل في يناير يعيد بصمت صفحات فارغة في مارس.

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

المنهجية

تنقسم مشكلة إعادة الزحف إلى ثلاثة قرارات ملموسة يجب اتخاذها مع كل طلب:

  1. هل نستخدم التصيير (Render) أم لا؟ توفر معظم بوابات التوثيق كود HTML نظيفًا. لكن نسبة متزايدة (أي موقع مبني على Next.js، أو يعتمد على التصيير من جانب العميل) تتطلب تصييرًا كاملًا عبر المتصفح لإرجاع محتوى مفيد.
  2. أي بروكسي نستخدم؟ سكني (Residential)، أو مراكز بيانات (datacenter)، أو محمول (mobile)، أو محدد جغرافيًا (geo-pinned)، أو خاص بمزود خدمة إنترنت معين (ISP-specific). يتغير الخيار المناسب بحسب الهدف.
  3. هل نجحت العملية بالفعل؟ استجابة برمز 200 مع نص فارغ، أو صفحة تحقق (verification page)، تمثل طلب HTTP ناجحًا ولكنها عملية زحف فاشلة.

تتعامل منصة مثل FourA مع كل نقطة من هذه النقاط كعنصر أساسي من الدرجة الأولى.

بالنسبة لقرار التصيير، يمكنك استدعاء Single للحالات السريعة ومنخفضة التكلفة، واستدعاء Browser للأهداف التي تعتمد بكثافة على JS. بنية جسم الاستدعاء متطابقة، لذا يتفرع كود الاستيعاب لديك مرة واحدة بناءً على خيار لكل مصدر بدلًا من التعامل مع مئات التعقيدات الخاصة بكل موقع.

بالنسبة لاختيار البروكسي، يعمل Proxy Finder كجزء من كل استدعاء عبر Single وBrowser وAuto. تختار المنصة منفذ خروج فعالًا لكل طلب، وتعيد معرفه الفريد (opaque id) في الاستجابة (عند r.proxy في المستوى الأعلى عبر Single/Browser، أو r.session.proxy عبر Auto)، ويمكنك إعادة استخدام هذا المعرف في الاستدعاءات التالية عندما تحتاج إلى الاستمرار في استخدام نفس نقطة الخروج. لن يحتاج زاحف البيانات لديك لتشغيل خوارزمية ترتيب بروكسيات خاصة به. (كتبنا عن أسباب عدم اعتبار حجم مجموعة البروكسيات هو العامل الحاسم في مقالنا Why Proxy Pool Size Stopped Mattering in 2026.)

وللإجابة عن سؤال "هل نجح الطلب فعليا؟"، يدعم كل request كتلة validate. يمكنك تحديد ما يُعتبر نجاحا: رموز الحالة المقبولة، وقيم header المطلوبة، ونصوص الـ body التي يجب أن تظهر أو ألا تظهر. تُرجع FourA إحدى النتائج السبع، وتكون success وحدها خاضعة للفوترة. الاستجابة 200 التي تفشل في تلبية قواعد المحتوى لديك تُوسم بالحالة application_fail ولا تدخل أبدا ضمن مجموعة بياناتك.

إليك شكل طلب إعادة الزحف لبوابة وثائق تتطلب معالجة JS. نترك مهمة التنسيق لـ Auto، حيث يحدد المنتج المناسب (Single أو Proxy أو Browser)، ويتعامل مع دفاعات الـ bot، ويُرجع القيم الثلاثية للجلسة لكي تستخدم عملية إعادة الزحف التالية نفس نقطة الخروج:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

إذا أظهر الهدف صفحة Cloudflare البينية، تلتقطها قاعدة validate.data.fail. النتيجة المسجلة في سجل استخدامك هي application_fail. لن تدفع مقابلها، وتعرف الشيفرة البرمجية المسؤولة عن الاستيعاب (ingestion) أن عليها إعادة المحاولة باستخدام proxy مختلف بدلا من تمرير صفحة "Just a moment..." إلى الـ embeddings.

بالنسبة لمجموعات البيانات الأكبر، يمكنك تطبيق النمط نفسه داخل طابور المهام (job queue) الحالي لديك. تقوم الفرق التي تحدثنا إليها بتشغيل عمليات diff ليلية مقارنة بالزحف السابق، وإعادة توليد embeddings فقط للمستندات التي تغيرت بالفعل، وتحديث قواعد بيانات تضم 500 مصدر خلال ساعتين فقط من الوقت الفعلي. طابور المهام يظل من مسؤوليتك، بينما يقع تبديل الـ proxy، وقرار العرض (render)، والتحقق من النجاح على عاتقنا.

النتائج

كيف تبدو دورة التحديث بمجرد أن تتوقف البنية التحتية عن كونها عنق الزجاجة (سيناريو توضيحي يعتمد على أنماط نراها عبر فرق الذكاء الاصطناعي المتخصص):

  • إعادة الزحف إلى 500 رابط URL مصدري أسبوعيا، بدلا من زحف لمرة واحدة لـ 200 رابط عند الإطلاق
  • الوقت الهندسي المستغرق في أداة الكشط (scraper): أقل من ساعتين أسبوعيا، انخفاضا من يوم أو يومين
  • نافذة تقادم الاسترجاع: 5 إلى 7 أيام، بدلا من أن تكون غير محدودة
  • نسبة البيانات غير الصالحة في مخزن المتجهات تقارب الصفر، لأن صفحات Cloudflare البينية وصفحات tarpit يتم رفضها عند طبقة validate قبل وصولها إلى نموذج الـ embedding لديك
  • تكلفة يمكن التنبؤ بها لكل مصدر، لأن عمليات الزحف الفاشلة لا تظهر في الفاتورة

الفكرة ليست أن أيا من هذه المزايا سحرية، بل إنها عمليات روتينية وموثوقة. وهذا بالضبط ما يحتاجه الذكاء الاصطناعي في بيئة الإنتاج. (لمزيد من التفاصيل حول الحالات التي تصبح فيها الحسابات غير مجدية مع استخراج البيانات عبر نماذج LLM المستضافة، راجع When LLM Extraction Stops Paying for Itself.)

الفكرة الأساسية

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

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