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

التحدي

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

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

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

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

النهج

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

العرض أم لا؟ تقدم معظم بوابات التوثيق HTML نظيفا. تحتاج نسبة متزايدة (أي شيء مبني على Next.js، أي شيء يعتمد على العرض من جانب العميل) إلى عرض كامل للمتصفح لإرجاع محتوى مفيد.
أي وكيل (proxy)؟ سكني، أو مركز بيانات، أو محمول، أو محدد جغرافيا، أو خاص بمزود خدمة إنترنت. يتغير الاختيار الصحيح حسب الهدف.
هل عمل بالفعل؟ الاستجابة 200 مع جسم فارغ، أو صفحة HTML تحتوي على CAPTCHA، هي طلب HTTP ناجح وزحف فاشل.

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

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

بالنسبة لاختيار الوكيل، يعمل Proxy Finder كجزء من كل استدعاء Single و Browser و Auto. تختار المنصة مخرجا يعمل لكل طلب، وتعيد معرفه الغامض في الاستجابة (في r.proxy المستوى الأعلى في Single/Browser، أو r.session.proxy في Auto)، وتعيد استخدام هذا المعرف في الاستدعاءات اللاحقة عندما تحتاج إلى الالتزام بنفس المخرج. لا يحمل الزاحف الخاص بك خوارزمية ترتيب الوكلاء الخاصة به. (لقد كتبنا عن سبب توقف حجم التجمع عن كونه العامل المميز في لماذا توقف حجم تجمع الوكلاء عن كونه مهما في عام 2026).

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

إليك كيف يبدو استدعاء إعادة الزحف لبوابة مستندات تحتاج إلى عرض JS. ندع Auto ينسق العملية، فهو يختار المنتج المناسب (Single، أو Proxy، أو Browser)، ويتعامل مع دفاعات الروبوتات، ويعيد الجلسة الثلاثية حتى تتمكن عملية إعادة الزحف التالية من الالتزام بنفس المخرج:

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. أنت لا تدفع مقابل ذلك، وكود الاستيعاب الخاص بك يعرف أنه يجب إعادة المحاولة بوكيل مختلف بدلا من تغذية صفحة "لحظة واحدة..." في التضمينات.

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

النتائج

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

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

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

النتيجة الرئيسية

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

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