واجهة Newscatcher CatchAll البرمجية: اختبرتُ البحث ذا أولوية الاستدعاء المصمَّم لوكلاء الذكاء الاصطناعي

واجهة Newscatcher CatchAll البرمجية: اختبرتُ البحث ذا أولوية الاستدعاء المصمَّم لوكلاء الذكاء الاصطناعي

طرحتُ على Newscatcher CatchAll API سؤالاً عنيداً: أوجِد كل حريق مستودع في أوروبا خلال هذا الربع. ليس أفضل عشرة، بل كلها. تُعيد واجهة البحث العادية صفحة روابط مرتبة وتُسقط الذيل الطويل في صمت؛ وهذا مقبول لعبارة "أفضل بيتزا قريب مني"، لكنه عديم الفائدة لمهمة تعداد شاملة. بعد نحو 15 دقيقة في الوضع Base، أعادت CatchAll أحداثاً من صحف إقليمية ومطبوعات متخصصة لم تُسطِّحها أيٌّ من واجهات البحث القائمة على الترتيب التي أدرجناها في اختبار best-ai-search-apis-2026. وصل كل نتيجة كائن JSON منظَّم واحد، لا رابط. هذا الفارق هو القصة كلها.

إليك النسخة المختصرة قبل أن نتعمق في التفاصيل التقنية.

أبرز النقاط

• CatchAll هي واجهة بحث برمجية ذات أولوية استدعاء: تُعيد سجلات أحداث منظَّمة، لا صفحة نتائج بحث مرتبة.
• تُفيد Newscatcher بنسبة استدعاء 79.8% ودرجة F1 تبلغ 0.705 على 32 استعلاماً؛ وتُقرِّب الصفحة الرئيسية هذا إلى 86%.
• وضعان للتشغيل: Lite (بثوانٍ، بسقف نتائج يبلغ ~100) وBase (غير متزامن، ~15 دقيقة، بلا سقف).
• الأنسب لمهام التعداد (الامتثال، الاستخبارات التنافسية، رصد سلاسل التوريد)؛ وليست أداة تتبع ترتيب في نتائج البحث.

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

ما هي CatchAll؟ (البحث ذو أولوية الاستدعاء، مشروحاً)

CatchAll هي واجهة بحث برمجية ذات أولوية استدعاء من Newscatcher: بدلاً من قائمة مرتبة تضم ~10 روابط، تُعيد مجموعة غير مكررة من سجلات الأحداث المنظَّمة، كل منها كائن JSON واحد يحتوي على مصادر مُحالة وكيانات مستخرَجة. أولوية الاستدعاء تعني أن الهدف هو الشمولية، أي إيجاد كل حدث ذي صلة، لا ترتيب قائمة قصيرة بحسب الملاءمة.

تُصيغ Newscatcher هذا بمثال ذهني صريح: إذا كانت 200 حدث صالح موجودة واستطاع نظامك إيجاد 5 منها، فنسبة استدعائك تساوي 2.5%. لعبارة "ما أفضل حاسوب محمول"، هذا مقبول. أما لعبارة "كل إجراء تنظيمي ضد شركات التكنولوجيا المالية في الاتحاد الأوروبي هذا العام"، فإجابة بنسبة 2.5% أسوأ من الجهل، لأنك لا ترى ما يفوتك.

هذه هي الفجوة التصنيفية التي تستهدفها CatchAll، وتستحق الفهم حتى لو لم تشترك قط. تصف رحلة الإطلاق على YC هذه الأداة بـ"واجهة البحث البرمجية ذات أولوية الاستدعاء"، ويمكنك قراءة هذا التأطير مباشرةً على صفحة منتج Newscatcher CatchAll Web Search API. التأطير الصادق: واجهة SERP البرمجية تُجيب على "ماذا يجب أن أقرأ أولاً؟"، بينما تُجيب CatchAll على "ما القائمة الكاملة؟"

كيف تعمل CatchAll: مسار الاسترجاع والتحقق

تشغِّل CatchAll مساراً من خمس مراحل: يُعيد تخطيط الاستعلام صياغة طلبك في عدة زوايا استرجاع، ويفحص الاسترجاع الواسع النطاق أكثر من 50,000 صفحة لكل مهمة، وتُجمِّع خوارزمية Leiden الصفحات المترابطة في أحداث منفردة، ويُقيِّم نموذج لغوي كبير (LLM) كل مجموعة مقابل استعلامك، وتعود الناجحة منها بوصفها JSON منظَّماً. يأتي الاستدعاء من الفحص؛ وتأتي الدقة من التحقق.

دعنا نستعرض هذه المراحل بسرعة:

1. تخطيط الاستعلام. يتحول استعلامك الواحد إلى عدة طلبات استرجاع تُغطي صياغات وأنواع أحداث مختلفة، فعبارة "حريق مستودع" تلتقط أيضاً "حريق في مستودع لوجستي".
2. الاسترجاع الواسع النطاق. تقول Newscatcher إن المهمة الواحدة تسحب أكثر من 50,000 صفحة بمعدل ~10,000 صفحة في الدقيقة دون سقف للنتائج، وتصل إلى الصحافة الإقليمية والمطبوعات المتخصصة والملفات التنظيمية التي تطمرها محركات البحث الرئيسية.
3. التجميع. تُجمِّع خوارزمية Leiden الصفحات المترابطة بكثافة في مجموعات. بعبارات بسيطة: تتقلص 30 مقالة عن نفس حريق روتردام إلى حدث واحد، لا 30 صفاً.
4. تحقق النموذج اللغوي. تُحسَب درجة كل مجموعة مقابل استعلامك، وتُحذف غير ذات الصلة. هذه المرحلة تستهلك طلبات LLM فعلية، لذا في مكدس الوكلاء الإنتاجي قد تُوجِّه تلك الطلبات عبر بوابة LLM للتحكم في الإنفاق والاحتياطيات.
5. المخرجات المنظَّمة. كائن JSON واحد لكل حدث موثَّق، بمخطط بيانات ديناميكي.

تُفيد Newscatcher بفهرسة أكثر من مليوني حدث واقعي يومياً، تصل الأحداث الجديدة منها خلال ساعات. تُغطي الورقة التقنية "The Architecture of Completeness" تفاصيل Leiden والتحقق للراغبين في التعمق.

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

الميزات الرئيسية: Monitors وWatchlists واستخراج الأحداث

تشمل CatchAll إضافةً إلى البحث الفردي ميزتَي Monitors وWatchlists. Monitors هي عمليات إعادة تشغيل مجدولة (بحد أدنى ساعة في الساعة) تُعيد فقط الأحداث الجديدة غير المكررة منذ آخر تشغيل. Watchlists تُصفِّي بحسب الكيان مع درجة ملاءمة من 1 إلى 10، وحل الكيانات يُطابق الشركة ذاتها عبر اللغات والسلطات القضائية.

تُحوِّل Monitors البحث الفردي إلى مراقبة مستمرة: كل تشغيل يُعيد فقط الأحداث الجديدة منذ المرة الأخيرة. الفرق بين "ابحث في الويب اليوم" و"أخبرني في اللحظة التي يتغير فيها شيء".

تحفظ صريح حول عبارة "واجهة مراقبة الأحداث في الوقت الفعلي": "الوقت الفعلي" هنا يعني إعادة التشغيل كل ساعة، لا بثاً بأجزاء من الثانية. إذا كنت تحتاج إشعارات فورية بالميلي ثانية، فهذه ليست أداتك. لفريق الامتثال الذي يتحقق مرتين يومياً، الساعة أكثر من كافية. Company Watchlist هي الميزة البارزة للاستخبارات التنافسية، إذ تحل "Acme GmbH" و"Acme Inc" و"Acme Holdings" في كيان متتَّبع واحد بدلاً من ثلاثة كيانات متشعبة.

مخرجات JSON المنظَّمة (مع مثال حقيقي)

كل نتيجة هي حدث واحد ككائن JSON واحد: cluster_id وعنوان title ودرجة ملاءمة relevance ومصفوفة كيانات entities ومصفوفة مصادر source_citations. لا كشط HTML، لا قائمة روابط للتحليل. هذا ما يجعل CatchAll واجهة برمجية لبحث الويب المنظَّم الحقيقية، لا مجرد غلاف لنتائج SERP.

إليك حدثاً مقتضَباً من اختباري لحرائق المستودعات، مُنظَّفاً قليلاً لكن حقيقياً في شكله:

{
  "events": [
    {
      "cluster_id": "evt_8f21a",
      "title": "Fire at logistics warehouse near Rotterdam",
      "relevance": 9,
      "entities": [
        {"name": "Rotterdam", "type": "location"},
        {"name": "Maasvlakte", "type": "facility"}
      ],
      "source_citations": [
        {
          "url": "https://...",
          "publisher": "regional trade press",
          "published_at": "2026-..."
        }
      ]
    }
  ]
}

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

كيف تستدعي CatchAll في Python؟ (بداية سريعة للكود)

تحصل على مفتاح API، وتُرسل طلب POST إلى /v3/search مع ترويسة x-api-token، وتُحلِّل مصفوفة events. هذه هي الحلقة كلها. إليك طلب Python بسيطاً:

import requests

resp = requests.post(
    "https://api.newscatcherapi.com/v3/search",
    headers={"x-api-token": "YOUR_API_KEY"},
    json={"query": "warehouse fires in Europe", "page_size": 10},
)
events = resp.json()["events"]
for ev in events:
    print(ev["title"], "—", ev["relevance"])

نصيحة عملية وتحذير في آنٍ واحد: Lite يُعيد خلال ثوانٍ لكن سقفه ~100 نتيجة، بينما Base غير متزامن ويستغرق ~15 دقيقة لمهمة عميقة دون سقف للنتائج. في Base، تُرسل الطلب وتستطلع النتائج بدلاً من الانتظار الانسدادي على طلب واحد، لذا صمِّم وكيلك للإرسال والمراجعة لا الانتظار. إذا كنت توصِّل CatchAll في وكيل، ستستدعيها عادةً كأداة عبر استدعاء الوظائف. تأكد من معاملات الطلب الدقيقة وعَلَم Lite مقابل Base من وثائق CatchAll قبل النشر؛ ترويسة المصادقة هي x-api-token.

ما تكلفة CatchAll؟ هل يوجد مستوى مجاني؟

التسعير مبني على الاستخدام بالدفع مقابل كل سجل موثَّق، بنحو $0.10 للسجل، وصفر نتائج يعني صفر رسوم. يوجد مستوى مجاني بنحو 2,000 رصيد عند التسجيل بالإضافة إلى ~10 عمليات بحث شهرياً دون الحاجة لبطاقة ائتمانية، حتى تتمكن من إجراء اختبار تعداد حقيقي قبل الالتزام.

نموذج "لا نتائج = لا رسوم" مهم لمهام التعداد: الاستعلام الذي لا يجد أحداثاً مطابقة لا يستهلك الميزانية. وعلى السؤال الشائع عما إذا كانت واجهة بحث Google مجانية، فإن Google وBing الأصليَّيْن ليستا هذا. تُعيدان روابط مرتبة لا أحداثاً منظَّمة موثَّقة، وBing Search API في طريقها إلى الإيقاف، وهذا جزء من سبب صعود الفهارس المستقلة.

حالات الاستخدام الواقعية

CatchAll تناسب أي مهمة يكون فيها تفويت عنصر واحد هو وضع الفشل. الامتثال والتتبع التنظيمي يعتمدان على Monitors مع تغطية الملفات التنظيمية. الاستخبارات التنافسية تعمل على Company Watchlist. رصد سلاسل التوريد يعتمد نمط حرائق المستودعات، مُراقِباً أحداث الاضطراب. بحوث السوق تستخدم التعداد على الصحافة المتخصصة.

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

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

المعايير القياسية: هل CatchAll أفضل فعلاً بثلاث مرات من Exa؟

في معيار Newscatcher الخاص لشهر مارس 2026 على 32 استعلاماً، تُفيد CatchAll بدرجة F1 تبلغ 0.705 ونسبة استدعاء 79.8% (4,807 أحداث)، فائزةً في 27 من 32 استعلاماً أمام Exa Websets وParallel AI FindAll وOpenAI Deep Research. تصف Newscatcher هذا بأنه ~3 أضعاف الأحداث ذات الصلة مقارنةً بالمنافسين. كل هذه الأرقام صادرة عن البائع نفسه.

والآن الجانب الصادق. يقول المعيار الداخلي الدقيق لـNewscatcher 79.8% استدعاءً؛ بينما تُقرِّب الصفحة الرئيسية هذا إلى 86%. سنستشهد بالرقم الأدنى. يأتي رقم 79.8% من جدول صفحة المنتج المفصَّل بتاريخه على 32 استعلاماً، بينما نسبة 86% ادعاء مُقرَّب من قطع مختلف على الصفحة الرئيسية ومنشور مدونة. كلاهما من Newscatcher. أبدأ بالأدنى لأن الاستشهاد بالرقم الداخلي الأكثر تحفظاً للبائع هو ما لا تستطيع صفحة التسويق فعله. في كلتا الحالتين، الاستنتاج الاتجاهي تأكَّد في اختباري: الاستدعاء أعلى فعلاً من الأدوات ذات أولوية الترتيب. للاطلاع على التفاصيل الكاملة، راجع كيف تُصنَّف CatchAll مقابل 12 واجهة بحث للذكاء الاصطناعي في مراجعتنا لأفضل واجهات البحث البرمجية للذكاء الاصطناعي، وتحقق بنفسك من الجدول الخام على صفحة منتج Newscatcher.

الحدود الصريحة: ما الذي لا تصلح له CatchAll؟

تمتلك CatchAll أربعة قيود حقيقية تطمرها صفحات التسويق، وينبغيك الموازنة بينها قبل البناء. ليست أداةً للاستجابة الفورية، ولا غير محدودة في الوضع السريع، ولا جاهزة للتوصيل الفوري بالوكلاء، ولا أداة لتتبع الترتيب. لا شيء منها عائق مطلق، لكن كلٌّ منها يستبعد حالة استخدام.

• وضع Base غير متزامن (~15 دقيقة للمهمة الواحدة). الأداة الخاطئة لروبوت محادثة يحتاج إجابة في ثانيتين.
• Lite يقتصر على ~100 نتيجة. هل تريد استدعاءً عميقاً سريعاً؟ لا يمكن الجمع بينهما؛ الاستدعاء العميق يدفع ثمن زمن الانتظار.
• لا خادم MCP رسمي بعد. تلتف حول نقطة النهاية REST بنفسك. إذا أردت استخدامها كأداة وكيل أصلية، تُغلِّف نقطة النهاية REST كخادم MCP بالطريقة ذاتها التي نبني بها خوادم MCP التي نستخدمها بالفعل.
• ليست أداة SERP أو تتبع ترتيب. لن تُخبرك بمكان صفحتك على Google. مهمة مختلفة تماماً.

هذا القسم هو ما لن تكتبه أي صفحة أولى الطرف نيابةً عنك. إذا كان الكمون غير المتزامن أو غياب خادم MCP يُعطِّل حالة استخدامك، فمن الأفضل معرفة هذا هنا لا بعد التكامل.

بدائل CatchAll ومتى تختارها

تتفوق CatchAll في الاستدعاء الخام للتعداد، لكنها ليست الخيار الصحيح لكل مهمة بحثية. إليك سبعة بدائل حقيقية مع الشرط الصادق لـ"اختر هذه بدلاً منها". لا قشٍّ.

القاعدة التجريبية السريعة: التعداد والمراقبة تشير إلى CatchAll، وRAG الحواري يشير إلى Tavily، والاكتشاف الدلالي يشير إلى Exa، وتتبع الترتيب يشير إلى SerpAPI.

كيف تستخدم Techsy البحث ذا أولوية الاستدعاء في بناء الوكلاء

في Techsy، نشحن وكلاء ذكاء اصطناعي لعملاء B2B، ويندرج البحث ذو أولوية الاستدعاء بسلاسة في مهام التعداد والمراقبة: فكِّر في وكيل امتثال يحتاج القائمة الكاملة لإجراءات التنفيذ، لا أفضل خمسة فحسب. نلجأ هناك إلى واجهة برمجية ذات أولوية استدعاء كـCatchAll، ونلجأ صادقاً إلى Tavily أو Exa حين تكون المهمة RAG حوارياً أو بحثاً دلالياً. اختيار البدائي الخاطئ للبحث هو أحد أكثر أخطاء بناء الوكلاء شيوعاً التي نُصلحها. هل تريد المساعدة في الاختيار؟ احصل على استشارة مجانية.

الأسئلة الشائعة

ما هي Newscatcher CatchAll API؟

CatchAll هي واجهة بحث ويب برمجية ذات أولوية استدعاء من Newscatcher. بدلاً من قائمة روابط مرتبة، تُعيد سجلات أحداث منظَّمة، كائن JSON واحد لكل حدث واقعي، كل منه يحتوي على مصادر مُحالة وكيانات مستخرَجة. مبنية لوكلاء الذكاء الاصطناعي والبحوث المؤسسية ومهام المراقبة حيث إيجاد كل حدث ذي صلة أهم من ترتيب قائمة قصيرة.

كيف تختلف CatchAll عن واجهة البحث العادية (SERP)؟

واجهة SERP البرمجية تُرتِّب وتُعيد حفنة روابط مُحسِّنةً لـ"ماذا يجب أن أقرأ أولاً". CatchAll تُحسِّن للشمولية، فتفحص أكثر من 50,000 صفحة لكل مهمة وتُجمِّعها في أحداث منظَّمة غير مكررة. تحصل على كائن واحد لكل حدث مع مصادر وكيانات، لا صفحة HTML للنتائج عليك كشطها وتحليلها بنفسك.

هل CatchAll أفضل فعلاً بثلاث مرات من Exa Websets؟

تُفيد Newscatcher بهذا في اختبارهم الخاص لمارس 2026 على 32 استعلاماً: CatchAll بنسبة استدعاء 79.8% ودرجة F1 تبلغ 0.705 مقابل Exa Websets بنسبة 19.6%، فائزةً في 27 من 32 استعلاماً، وهو ما يُؤطِّرونه بـ~3 أضعاف أحداث ذات صلة. انتبه إلى أن الصفحة الرئيسية تُقرِّب الاستدعاء إلى 86% من قطع مختلف. جميع الأرقام صادرة عن البائع؛ تعامل معها كمنسوبة لا كمُدقَّقة مستقلاً.

ما تكلفة CatchAll؟ هل يوجد مستوى مجاني؟

التسعير مبني على الاستخدام بالدفع مقابل كل سجل موثَّق، بنحو $0.10 للسجل، مع صفر رسوم حين لا يُعيد الاستعلام نتائج. المستوى المجاني يمنح نحو 2,000 رصيد عند التسجيل بالإضافة إلى ~10 عمليات بحث شهرياً دون بطاقة ائتمانية. هذا كافٍ لإجراء اختبار تعداد حقيقي مقابل حالة استخدامك الخاصة قبل تخصيص ميزانية.

ما سرعة CatchAll؟

يعتمد على الوضع. Lite يُعيد خلال ثوانٍ لكن سقفه ~100 نتيجة. Base غير متزامن ويستغرق ~15 دقيقة للمهمة الواحدة دون سقف للنتائج، للتعداد العميق. في مهام Base تُرسل وتستطلع بدلاً من الانتظار الانسدادي على طلب واحد، لذا هو خاطئ لأي شيء يحتاج إجابة خلال أجزاء من الثانية كروبوت المحادثة الحي.

هل تمتلك CatchAll خادم MCP؟

ليس رسمياً حتى الآن. لاستخدامها كأداة وكيل أصلية اليوم، تُغلِّف نقطة النهاية REST بنفسك، وهو النمط ذاته المُغطَّى في دليل MCP لدينا. إنه غلاف رفيع حول POST واحد إلى /v3/search، لذا بناء خادم MCP صغير حوله يسير إذا كان نظامك يتحدث البروتوكول بالفعل.

ما هي Monitors وWatchlists؟

Monitors هي عمليات إعادة تشغيل مجدولة بحد أدنى ساعة، تُعيد فقط الأحداث الجديدة غير المكررة منذ آخر تشغيل، محوِّلةً البحث الفردي إلى مراقبة مستمرة. Watchlists تُصفِّي النتائج بالكيان مع درجة ملاءمة من 1 إلى 10 وتحل الشركة ذاتها عبر اللغات والسلطات القضائية. معاً يُغطيان تتبع الامتثال والاستخبارات التنافسية دون إعادة الاستعلام عن الويب كاملاً في كل مرة.

هل يمكنني استخدام CatchAll لتتبع ترتيب SEO؟

لا. تُعيد CatchAll أحداثاً منظَّمة موثَّقة، لا ترتيبات محركات البحث، لذا لن تُخبرك بمكان صفحتك على Google. لتتبع الترتيب وميزات SERP أو عكس ما تُظهره Google بالضبط، استخدم SerpAPI أو Serper بدلاً من ذلك. CatchAll ومتتبعات الترتيب تحلان مشكلتين مختلفتين فعلاً رغم أن كلتيهما تلمسان "بحث الويب".

ما أفضل حالات الاستخدام لـCatchAll؟

مهام التعداد والمراقبة حيث تهم الشمولية: الامتثال والتتبع التنظيمي، والاستخبارات التنافسية، ورصد اضطرابات سلاسل التوريد، وبحوث السوق على الصحافة المتخصصة. القاسم المشترك: تفويت حدث ذي صلة واحد هو وضع الفشل، وهو بالضبط ما صُمِّم البحث ذو أولوية الاستدعاء لمنعه. للRAG الحواري أو البحث الدلالي، تناسب أداة ذات أولوية الترتيب بشكل أفضل.

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