Agents 6 min2026-06-01

Exa مقابل Google Search API: لماذا يغير البحث الدلالي قدرات وكلاء الذكاء الاصطناعي

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

معظم وكلاء الذكاء الاصطناعي (AI agents)، بمجرد خروجهم من البيئة التجريبية (demo environment)، يصطدمون بجدار الواقع فوراً عندما يُطلب منهم القيام بأي شيء يتجاوز بيانات تدريبهم. يبدأون في اختلاق الحقائق بثقة تامة (hallucinations)، أو يسيئون فهم الطلبات الدقيقة، أو يفشلون ببساطة في العثور على معلومات خارجية ذات صلة. هذا ليس خللاً في الـ LLM، بل هو محدودية أساسية ناتجة عن الاعتماد الكلي على تاريخ انقطاع المعرفة الثابت (static knowledge cutoff)، أو ربطه بآلية بحث غير ملائمة للمهمة. لقد رأينا في Verel Systems عدداً لا يحصى من المشاريع التجريبية تتعثر هنا، متراكمةً بـ "ديون الذكاء الاصطناعي" (AI debt) بسبب سلاسل الـ prompts المعقدة والوكلاء غير المراقبين الذين يقدمون نتائج غير متسقة. المشكلة الجوهرية هي معضلة الربط بالواقع (grounding problem): كيف تضمن أن يعمل الوكيل بمعلومات دقيقة، حديثة، وذات صلة بالسياق؟

النهج التقليدي المتمثل في تعزيز الـ LLMs باستخدام search APIs خارجية غالباً ما يفشل. البحث القائم على الكلمات المفتاحية (Keyword-based search)، رغم شيوعه بين البشر، يُعد أساساً هشاً لوكيل الذكاء الاصطناعي. عندما يطلب الـ LLM "آخر التطورات في التعلم الاتحادي (federated learning) لتحسين سلاسل الإمداد"، فإن API الكلمات المفتاحية مثل Google Search API يعود بصفحات مخصصة لزيادة نقرات المستخدمين (human clicks)، مليئة بالإعلانات، المعلومات القديمة، أو حشو الـ SEO. بعد ذلك، يقوم الوكيل باستيعاب هذه البيانات المليئة بالضوضاء وغير ذات الصلة، مما يؤدي إلى مخرجات مشوهة وهلوسة مستمرة. ما يحتاجه الوكلاء ليس كلمات مفتاحية، بل المعنى. يحتاجون إلى فهم دلالي (semantic understanding) لاسترجاع المعلومات بناءً على المفهوم والنية، وليس مجرد التطابق اللفظي (lexical match).

هنا يأتي دور Exa لتغيير المعادلة بالكامل.

نهج Exa: البحث الدلالي للوكلاء

إن Exa ليس مجرد محرك بحث آخر؛ بل هو API بحث مصمم خصيصاً للذكاء الاصطناعي (AI-native) ومبني من الصفر للوكلاء. تكمن ميزته التنافسية الأساسية في بنية البحث العصبي (neural search architecture) المدربة على مجموعة ضخمة من صفحات الويب. يتيح ذلك لـ Exa فهم المعنى الدلالي الكامن وراء الاستعلام (query) وإرجاع نتائج متشابهة مفاهيمياً، حتى لو لم تتطابق الكلمات المفتاحية بدقة. إنه يتجاوز قيود الفهارس المعكوسة التقليدية (inverted indexes).

فكر في استعلام مثل "كيف يؤثر قانون الذكاء الاصطناعي الأوروبي الجديد على تطوير الـ LLMs مفتوحة المصدر؟". قد يعود البحث بالكلمات المفتاحية بملخصات قانونية أو مقالات إخبارية عامة. لكن Exa يفهم العلاقة الدقيقة بين هذه المفاهيم. يمكنه إظهار مدونات تقنية محددة، أو نقاشات على GitHub، أو تحليلات تنظيمية تتعمق في التداعيات على المطورين والمشاريع مفتوحة المصدر، حتى لو لم تكن تلك الصفحات تحتوي صراحة على عبارة "تطوير الـ LLMs مفتوحة المصدر" في عناوينها. الفارق في مدى الصلة (relevance delta) هائل.

يعالج Exa أيضاً المشكلة الحرجة المتعلقة بنظافة البيانات. تُعد نقطة النهاية contents الخاصة به بمثابة نقلة نوعية في كيفية استهلاك الوكلاء للبيانات. بدلاً من إرجاع كود HTML الخام، والذي يواجه الـ LLM صعوبة في تحليله (parsing) بكفاءة ودقة، توفر contents نسخة نصية نظيفة ومستخرجة من الصفحة. هذه الخطوة من المعالجة المسبقة (pre-processing) لا تقدر بثمن؛ فهي تقلل من هدر الـ tokens، وتحسن دقة التحليل، وتخفض العبء المعرفي (cognitive load) على الـ LLM بشكل كبير. نحن لا نغذي الوكلاء بصفحة ويب عشوائية، بل نغذيهم بمعلومات مهيكلة.

إلى جانب الفهم الدلالي والنصوص النظيفة، يقدم Exa إمكانيات تصفية (filtering) قوية وضرورية لتوجيه سلوك الوكيل بدقة:

▸النطاق الزمني (Date Range): أمر بالغ الأهمية للحصول على معلومات حديثة. يمكن للوكلاء تحديد start_published_date و end_published_date.
▸تصفية النطاقات (Domain Filtering): حصر البحث في نطاقات محددة أو استبعاد مواقع السبام المعروفة.
▸نوع المحتوى (Content Type): التصفية حسب نوع الملف filetype مثل PDF للحصول على مستندات محددة.
▸الكاتب/الناشر (Author/Publisher): استهداف المحتوى المنشور من مصادر موثوقة.

تمكن هذه الميزات الوكيل من العمل بدقة عالية، حيث يسترجع نوع المعلومات التي يحتاجها تماماً، بدلاً من تصفح نتائج الويب العامة وغير المجدية.

أين نستخدم Exa في Verel Systems

في Verel Systems، نحن متخصصون في نقل مشاريع الذكاء الاصطناعي من مرحلة التجارب الأولية المتعثرة إلى مرحلة الإنتاج الفعلي (production). غالباً ما يأتي إلينا عملاؤنا بأنظمة RAG تجريبية أو وكلاء يفشلون تحت ضغط الاستخدام الفعلي. يمثل Exa مكوناً أساسياً في أدواتنا لبناء أنظمة وكلاء جاهزة للإنتاج تقدم نتائج متسقة ودقيقة. نقوم بدمجه عبر عدة حالات استخدام رئيسية:

▸وكلاء البحث لذكاء الأعمال التنافسي (Competitive Intelligence): يحتاج وكلاء البحث لدينا إلى تتبع الأسواق سريعة التطور، وفهم تحركات المنافسين، وتحديد الاتجاهات التكنولوجية الناشئة. الاعتماد على قاعدة المعرفة الداخلية وحدها لا يكفي، فهي دائماً ما تكون قديمة. بالنسبة لأحد عملائنا في قطاع أشباه الموصلات، يستخدم وكيل مكلف بمراقبة "تقنيات الطباعة الحجرية من الجيل القادم لمنافسي ASML" أداة Exa للعثور على أحدث الأوراق البحثية، وبراءات الاختراع، والأخبار من منشورات الصناعة المتخصصة. إن القدرة على التصفية حسب التاريخ (مثل start_published_date: "2023-01-01") واسترجاع نصوص نظيفة تضمن أن يعمل وكلاؤنا دائماً بأحدث البيانات وأكثرها صلة، متجنبين المعلومات القديمة التي غالباً ما تظهر في البحث بالكلمات المفتاحية.
▸تعزيز الـ RAG ببيانات الويب المباشرة: يتم بناء العديد من أنظمة RAG على وثائق داخلية ثابتة. ولكن ماذا يحدث عندما يطرح المستخدم سؤالاً يتطلب بيانات خارجية مباشرة من الويب؟ أو عندما تكون الوثائق الداخلية غير مكتملة؟ تدمج أنماط تعزيز الـ RAG لدينا Exa كأداة بحث احتياطية (fallback) أو أساسية. إذا أسفر البحث في قاعدة المعرفة الداخلية عن نتائج ذات ثقة منخفضة (على سبيل المثال، درجة تشابه دلالي أقل من 0.75)، يقوم الوكيل تلقائياً بالاستعلام عبر Exa. على سبيل المثال، يمكن لوكيل الدعم الفني الذي يحتاج إلى حل مشكلة في ميزة منتج جديدة لم يتم توثيقها داخلياً بالكامل بعد، الاستعلام في Exa عن "المشكلات المعروفة [اسم المنتج] [اسم الميزة] في المنتديات" واسترجاع المناقشات ذات الصلة أو الأدلة الخارجية، ثم تلخيص تلك النتائج للمستخدم. هذا يمنع الوكلاء من الاصطدام بحدود المعرفة والوقوع في الهلوسة.
▸أدوات الوكلاء لأبحاث السوق والتوثيق التقني: نحن نبني أدوات متخصصة للوكلاء. قد يستخدم وكيل أبحاث السوق Exa لتحديد "آراء المستهلكين تجاه التعبئة والتغليف المستدام في صناعة الأغذية"، مستفيداً من قدرات Exa الدلالية للعثور على تحليلات وسائل التواصل الاجتماعي، وتقارير الصناعة، والمقالات الإخبارية. وبالمثل، يمكن لوكيل التوثيق التقني الاستعلام في Exa عن تفاصيل ثغرة أمنية محددة مثل "CVE-2023-XXXX exploit details" لسحب إرشادات الأمان وإصلاحات الثغرات مباشرة إلى سياقه (context)، مما يوفر معلومات فورية وقابلة للتنفيذ للمطور. هذا الوصول المباشر إلى معلومات خارجية حديثة وذات صلة هو أمر لا غنى عنه للوكلاء الذين يعملون في بيئات ديناميكية.

مقارنة ملموسة: Google Search API مقابل Exa

دعونا نوضح الفرق بمثال عملي. تخيل وكيلاً مكلفاً بفهم "تأثير التلدين الكمي (quantum annealing) على أبحاث علم المواد". هذا مجال تقني للغاية ومتطور باستمرار.

الاستعلام (Query): "impact of quantum annealing on materials science research"

Google Search API (عبر google-search-results أو ما شابه): تتكون النتائج عادةً من:

▸صفحات ويكيبيديا حول التلدين الكمي أو علم المواد.
▸مقالات عامة من مواقع أخبار التكنولوجيا (مثل "كيف سيغير الحوسبة الكمية المواد").
▸صفحات نظرة عامة لأقسام الأبحاث الجامعية.
▸أوراق مراجعة أو وقائع مؤتمرات قد تكون قديمة.

▸مدى الصلة (Relevance): قد تسجل أفضل 5 نتائج متوسط درجة تشابه دلالي يبلغ 0.65 مقارنة بالنية الحقيقية للاستعلام. هي تحتوي على كلمات مفتاحية ولكنها غالباً ما تفتقر إلى العمق أو التخصيص المطلوب لوكيل الذكاء الاصطناعي لاستخلاص استنتاجات ذات مغزى حول التأثير على الأبحاث.
▸جودة البيانات (Data Quality): كود HTML خام. سيحتاج الـ LLM إلى تحليل هذا الكود، واستخراج المحتوى، وتصفية عناصر التنقل، الإعلانات، والأقسام غير ذات الصلة. هذا يزيد من زمن الاستجابة (latency) ويتسبب في حدوث أخطاء.
▸زمن الاستجابة (Latency): قد تستغرق مكالمة Google Search API النموذجية للحصول على النتائج الأولية ما بين 300 إلى 500 مللي ثانية.

Exa (عبر exa_py): يعطي محرك البحث العصبي الخاص بـ Exa الأولوية للصلة المفاهيمية. النتائج هنا مختلفة تماماً:

▸أوراق بحثية حديثة ما قبل النشر (pre-print) من arXiv أو مجلات متخصصة (مثل "Quantum Annealing for Accelerated Materials Discovery: A Review" المنشورة في الربع الأخير).
▸تدوينات تقنية من مختبرات أبحاث أو شركات حوسبة كمية تفصل تجارب محددة.
▸بيانات صحفية جامعية تسلط الضوء على نتائج أبحاث جديدة في هذا المجال.
▸ملخصات وقائع المؤتمرات الصادرة خلال الـ 12 إلى 18 شهراً الماضية.

▸مدى الصلة (Relevance): تظهر أفضل 5 نتائج من Exa باستمرار متوسط درجة تشابه دلالي يزيد عن 0.90+. هي تتناول مباشرة التأثير على الأبحاث، وغالباً ما تقدم منهجيات ونتائج محددة. هذه هي بالضبط البيانات عالية الجودة (high-signal data) التي يحتاجها الـ LLM.
▸جودة البيانات (Data Quality): باستخدام نقطة النهاية contents نحصل على نص نظيف ومستخرج. بالنسبة لمقال يتكون من 1000 كلمة، قد يمثل هذا حوالي 1500 إلى 2000 token من المحتوى النقي الجاهز للـ LLM، دون أي أعباء إضافية للتحليل (parsing overhead).
▸زمن الاستجابة (Latency): تستغرق مكالمة البحث الأولية عادةً من 200 إلى 300 مللي ثانية. جلب الـ contents لأفضل 2-3 نتائج يضيف 100 إلى 200 مللي ثانية أخرى لكل مقال. الوقت الإجمالي للحصول على محتوى نظيف وذي صلة غالباً ما يكون مقارباً أو أسرع من معالجة نتائج Google المليئة بالضوضاء.

الفرق لا يقتصر فقط على العثور على شيء ما؛ بل يتعلق بالعثور على الشيء الصحيح وجعله قابلاً للاستهلاك. بالنسبة للوكيل، هذا يعني الفرق بين هلوسة إجابة تبدو معقولة ولكنها خاطئة، وتقديم استجابة دقيقة ومبنية على حقائق صلبة (well-grounded).

كود التكامل: Exa كعقدة أداة (Tool Node) في LangGraph

إن دمج Exa في إطار عمل للوكلاء مثل LangGraph هو أمر مباشر. نحن نعرفه كأداة (tool)، مما يسمح للـ LLM باستدعائه عندما تكون هناك حاجة لمعلومات خارجية. التعامل الصحيح مع الأخطاء وتنسيق النتائج هما أمران لا غنى عنهما في الأنظمة الجاهزة للإنتاج.

import os
from exa_py import Exa
from langchain_core.tools import tool
from langchain_core.messages import ToolMessage
from typing import List, Dict, Any

# Initialize Exa client with API key
# Ensure EXA_API_KEY is set as an environment variable
exa_client = Exa(api_key=os.getenv("EXA_API_KEY"))

@tool
def exa_search(query: str, num_results: int = 5, start_published_date: str = None) -> List[Dict[str, Any]]:
    """
    Searches Exa for relevant documents based on a query.
    Returns a list of dictionaries, each containing 'title', 'url', and 'text_content'.
    Optionally filters results by publication date.

    Args:
        query (str): The search query.
        num_results (int): The maximum number of search results to return (default: 5).
        start_published_date (str, optional): ISO 8601 formatted date string (e.g., "2023-01-01")
                                              to filter results published after this date.
    """
    try:
        search_params = {
            "query": query,
            "num_results": num_results,
            "type": "neural", # Use neural search for semantic understanding
            "start_published_date": start_published_date,
            "text": True # Request full text content immediately
        }
        
        # Filter out None values to prevent API errors
        search_params = {k: v for k, v in search_params.items() if v is not None}

        print(f"DEBUG: Calling Exa with params: {search_params}")
        response = exa_client.search(**search_params)
        
        results = []
        for result in response.results:
            # Check if text is available, as sometimes it might not be for certain pages
            if result.text:
                results.append({
                    "title": result.title,
                    "url": result.url,
                    "text_content": result.text
                })
            else:
                # Fallback to fetching content if not included, or just skip if text is primary
                # For simplicity here, we assume text is usually present with text=True
                # In production, you might call exa_client.get_contents([result.url])
                # and handle that response.
                print(f"WARNING: No text content found for {result.url}, skipping.")
        
        if not results:
            return [{"error": "No relevant content found by Exa."}]

        # Format results for LLM consumption: concise and clear
        formatted_results = []
        for i, res in enumerate(results):
            # Truncate text_content to fit context window,
            # ensuring enough information without overwhelming the LLM.
            # A common strategy is to take the first N tokens or characters.
            truncated_text = res['text_content'][:1000] + "..." if len(res['text_content']) > 1000 else res['text_content']
            formatted_results.append(
                f"Result {i+1}:\n"
                f"Title: {res['title']}\n"
                f"URL: {res['url']}\n"
                f"Content: {truncated_text}\n"
                f"---"
            )
        
        return formatted_results

    except Exception as e:
        print(f"ERROR: Exa search failed: {e}")
        return [{"error": f"Exa search failed: {str(e)}. Please try a different query or check API key."}]

# Example of how an agent might use this tool within a LangGraph node:
# from langchain_core.runnables import RunnableLambda
# from langchain_core.messages import HumanMessage
# from langchain_openai import ChatOpenAI
# from langgraph.graph import StateGraph, END

# Define a simple agent state
# class AgentState(TypedDict):
#     query: str
#     results: List[Dict[str, Any]]
#     messages: Annotated[List[Any], operator.add]

# Define a node that uses the tool
# def call_exa_tool(state: AgentState):
#     query = state["query"]
#     tool_output = exa_search.invoke({"query": query, "num_results": 3, "start_published_date": "2023-06-01"})
#     return {"results": tool_output, "messages": [ToolMessage(content=str(tool_output), name="exa_search")]}

# Define the graph... etc.

توفر أداة exa_search هذه للـ LLM معلومات مهيكلة وذات صلة، مما يقلل من الهلوسة ويحسن الدقة الواقعية. يُعد اقتطاع text_content أمراً حاسماً لإدارة استهلاك الـ tokens وضمان تلقي الـ LLM لمقتطفات قابلة للتنفيذ بدلاً من أحجام هائلة من النصوص. نحن نهدف عادةً إلى حوالي 1000 إلى 2000 حرف لكل نتيجة لتحقيق التوازن بين التفاصيل وقيود نافذة السياق (context window).

مقارنة بين Exa و Tavily و Perplexity API و SerpAPI: متى تستخدم كل منها

يتطور مشهد الـ search APIs المخصصة لوكلاء الذكاء الاصطناعي باستمرار. يعتمد اختيار الأداة المناسبة تماماً على حالة الاستخدام المحددة ومتطلبات الوكيل. نحن نقوم بتقييم هذه الخيارات بصرامة في Verel Systems لتجنب تراكم ديون الذكاء الاصطناعي الناتجة عن نشر حلول غير مثالية.

▸
SerpAPI / Bright Data: هي في الأساس APIs لكشط الويب (web scraping) تقوم بتحليل نتائج صفحات بحث Google (SERP). وهي ممتازة عندما تحتاج إلى بيانات مهيكلة مباشرة من صفحات نتائج البحث: أسعار المنتجات، قوائم الشركات المحلية، بيانات وصفية محددة من عناصر HTML، أو تتبع تغييرات ترتيب نتائج البحث. تعتمد هذه الأدوات على الكلمات المفتاحية وتعود بتمثيلات HTML أو JSON خام وغالباً ما تكون مليئة بالضوضاء لصفحات نتائج البحث.
- ▸متى تستخدمها: كشط بيانات محددة ومهيكلة من نتائج بحث Google. مراقبة أداء الـ SEO.
- ▸متى تجتنبها: الفهم الدلالي، استخراج النصوص النظيفة لاستهلاك الـ LLM، والبحث المفاهيمي العميق. نتائجها مصممة للاستهلاك البشري أولاً، وليس للذكاء الاصطناعي.
▸
Tavily API: إن Tavily هو API سريع وعام للبحث في الويب مصمم خصيصاً للوكلاء. يهدف إلى تقديم نتائج سريعة وذات صلة وغالباً ما يوفر ملخصات موجزة. إنه يمثل حلاً وسطاً جيداً للعديد من مهام الوكلاء الشائعة. ورغم أنه يستخدم بعض الذكاء لتصفية النتائج، إلا أنه قد يميل أكثر نحو الصلة بالكلمات المفتاحية مقارنة بالفهم الدلالي العميق الذي يقدمه Exa.
- ▸متى تستخدمها: البحث العام عن الحقائق، الإجابات السريعة، عندما تكون السرعة هي الشاغل الأساسي، أو عندما لا يكون العمق الدلالي لـ Exa ضرورياً بشكل صارم. إنه خيار افتراضي جيد للعديد من احتياجات RAG الأساسية.
- ▸متى تجتنبها: عندما تكون هناك حاجة إلى معلومات محددة للغاية، متخصصة، أو ذات طابع مفاهيمي عميق، خاصة من الأوراق الأكاديمية أو المدونات التقنية المتخصصة حيث يتفوق Exa.
▸
Perplexity API: يتميز Perplexity بكونه

الخدمات ذات الصلة

أنظمة وكلاء الذكاء الاصطناعي