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

مشكلة إعادة الزحف: الحفاظ على حيوية خطوط معالجة RAG

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

ragai-trainingdata-collectionvertical-aiuse-case

التحدي

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

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

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

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

النهج

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

  1. القيام بالـ Render أم لا؟ تقدم معظم بوابات التوثيق HTML نظيفاً. لكن هناك نسبة متزايدة (أي شيء مبني على Next.js، أو أي شيء يعتمد على client-side rendering) تحتاج إلى rendering كامل للمتصفح لإرجاع محتوى مفيد.
  2. أي proxy نستخدم؟ سكني (residential)، أو مركز بيانات (datacenter)، أو محمول (mobile)، أو محدد جغرافياً (geo-pinned)، أو خاص بمزود خدمة إنترنت معين (ISP-specific). الاختيار الصحيح يتغير حسب الهدف.
  3. هل نجح الأمر فعلاً؟ إن رمز الاستجابة 200 مع body فارغ، أو صفحة HTML تحتوي على CAPTCHA، يعتبر HTTP request ناجحاً ولكنه عملية زحف فاشلة.

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

بالنسبة لقرار الـ render، يمكنك استدعاء Single للحالات الرخيصة والسريعة، وBrowser للأهداف التي تعتمد بكثافة على JS. يتخذ body الاستدعاء الشكل نفسه، لذا يتفرع كود الإدخال الخاص بك مرة واحدة بناءً على علامة (flag) لكل مصدر بدلاً من التعامل مع مئات التفاصيل الغريبة الخاصة بكل موقع.

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

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

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

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"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["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. لن تدفع مقابلها، ويعرف كود الإدخال الخاص بك أنه يجب إعادة المحاولة باستخدام proxy آخر بدلاً من إدخال صفحة "Just a moment..." في الـ embeddings.

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

النتائج

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

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

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

الخلاصة الرئيسية

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

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