لو نموذج اللغة بيقولك "النهاردة الجو حلو" وانت متأكد إنه مش بيشوف بيانات الطقس فعلاً، يبقى انت محتاج Function Calling. ده الـ feature اللي بتحوّل الـ AI من شخص بيتكلم لشخص بينفّذ.

شبكة عصبونية مضيئة ترمز لاتصال نموذج اللغة بأدوات خارجية عبر function calling

Function Calling: ليه ده أهم تطور في الـ AI APIs

قبل 2023، الـ LLM كان sandbox مغلق. بياخد نص ويرجّع نص. لو سألته "كام الساعة دلوقتي في القاهرة؟" هيجاوبك بكلام يبدو واثق، لكنه في الحقيقة بيخمّن. مفيش طريقة يعرف بيها الوقت الفعلي.

الـ Function Calling (أو Tool Use عند Anthropic) بيكسر الجدار ده. انت بتعرّف للنموذج "أنا عندي أداة اسمها get_current_time بتاخد city وبترجّع الوقت". النموذج بقى يقدر يقرر بنفسه إنه يستدعيها لمّا يلاقي السؤال محتاجها.

المشكلة باختصار

أي تطبيق AI حقيقي محتاج بيانات live: حالة طلب في e-commerce، رصيد في bank، طقس، أسعار، أي حاجة بتتغيّر. النموذج لوحده مالوش وصول للبيانات دي. الحل القديم كان: انت تكتب prompt parser يدوي يحاول يفهم نية المستخدم، ينده على الـ API الصح، ويرجّع الرد للنموذج. ده كان هش جداً وكان بيفشل في 30-40% من الحالات.

اشرحلي زي ما إنت بتشرح لطفل

تخيّل عندك صديق ذكي جداً بس قاعد جوّه أوضة مفيهاش نوافذ. لو سألته "النهاردة الجو ايه؟"، هو بيخمّن من خبرته السابقة، أو يقولك "مش عارف". مفيش طريقة تانية.

دلوقتي تخيّل إنك حطيت قدامه جرس صغير مكتوب عليه "اضغط لتعرف الجو". لو ضغط، بتجيله ورقة فيها الجو. الجرس ده هو الـ tool، والـ Function Calling هو القاعدة اللي بتقول للصديق "انت مسموحلك تستخدم الجرس ده لمّا حد يسألك عن الطقس". الصديق هو اللي بيقرر يضغط ولا لأ، مش انت.

التعريف العلمي الدقيق

Function Calling هو آلية بتسمح للـ LLM بإصدار structured output بصيغة JSON يلتزم بـ schema انت بتعرّفه مسبقاً، لتمثيل نية استدعاء دالة معيّنة بمعاملات محددة. النموذج لا ينفّذ الدالة بنفسه؛ هو بس بيرجّع للـ runtime بتاعك إنه عايز يستدعيها بالقيم الفلانية. التنفيذ الفعلي مسؤوليتك انت، وبعدين بترجّع نتيجة التنفيذ للنموذج عشان يكمّل المحادثة.

الدورة الكاملة: user message → model decides to call tool → your code executes tool → tool result → model generates final response. ده بيتعمل في request واحد ممتد أو في multi-turn حسب الـ SDK.

سيناريو واقعي: bot خدمة عملاء لمتجر إلكتروني

تخيّل عندك متجر بيستقبل 5000 سؤال يومياً من نوع "فين طلبي؟" و "ايه سياسة الإرجاع؟". النوع التاني سهل (محتوى ثابت). النوع الأول محتاج بيانات live من DB الطلبات.

بدون Function Calling: لازم تكتب regex يفهم رقم الطلب من السؤال، وبعدين تستعلم، وترجّع النتيجة في prompt للنموذج يصيغها. التعقيد بيتراكم لمّا المستخدم يقول "طلبي اللي اشتريته إمبارح" بدل ما يقول رقم.

مع Function Calling: انت بتعرّف get_order_status(order_id) و list_recent_orders(user_id, days). النموذج بيقرر بنفسه أي واحدة يستدعي بناءً على صياغة السؤال. النتيجة في الـ benchmarks الرسمية: دقّة اختيار الأداة الصح بين 96% و 99% على Claude Sonnet 4.6 و GPT-4o.

كود شغّال: مثال بـ Anthropic Python SDK

Python

from anthropic import Anthropic

client = Anthropic()

tools = [
    {
        "name": "get_order_status",
        "description": "ارجع حالة الطلب وتفاصيل الشحن للـ order_id المطلوب.",
        "input_schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "description": "رقم الطلب، مثال: ORD-12345"
                }
            },
            "required": ["order_id"]
        }
    }
]

def execute_tool(name, args):
    if name == "get_order_status":
        # هنا بتنده على DB أو API الحقيقي
        return {"status": "shipped", "eta": "2026-04-23", "carrier": "Aramex"}
    raise ValueError(f"Unknown tool: {name}")

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=tools,
    messages=[
        {"role": "user", "content": "فين طلبي رقم ORD-12345؟"}
    ]
)

# لو النموذج قرر يستدعي tool
if response.stop_reason == "tool_use":
    tool_block = next(b for b in response.content if b.type == "tool_use")
    result = execute_tool(tool_block.name, tool_block.input)

    # ابعت النتيجة للنموذج عشان يكتب الرد النهائي
    final = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        tools=tools,
        messages=[
            {"role": "user", "content": "فين طلبي رقم ORD-12345؟"},
            {"role": "assistant", "content": response.content},
            {"role": "user", "content": [{
                "type": "tool_result",
                "tool_use_id": tool_block.id,
                "content": str(result)
            }]}
        ]
    )
    print(final.content[0].text)

الفرق بين Anthropic و OpenAI في التطبيق

الفكرة واحدة، التفاصيل بتختلف. OpenAI بتدّعم strict: true اللي بيضمن الـ schema بيتطبّق 100%، وبتدعم 128 أداة في الـ request الواحد. Anthropic بتستخدم content blocks منفصلة (text block + tool_use block) في نفس الرد، وبتدعم 64 أداة كحد أقصى، لكن بتدّيك مرونة أكبر في الـ schema.

من ناحية الـ overhead: تعريف 3 إلى 5 أدوات بيضيف تقريباً 200–400 token على OpenAI و 300–500 token على Anthropic لكل request. ده مش هيّن لو بتعمل ملايين الطلبات يومياً.

Trade-offs لازم تعرفها قبل ما تشتغل به في production

التكلفة: كل tool definition بيتحاسب tokens في الـ system prompt. 10 أدوات معقّدة ممكن يضيفولك 1500 token في كل request. الحل: استخدم Tool Search Tool من Anthropic لو عندك آلاف الأدوات.
الـ latency: دورة كاملة (call → execute → respond) معناها 2 API calls على الأقل. اللي كان بياخد 1.5 ثانية بقى ياخد 3–4 ثواني. لو تطبيقك حساس للزمن، فكّر في streaming.
الـ hallucinated arguments: النموذج ممكن يخترع order_id غير موجود لو المستخدم ما ذكرش رقم. الحل: validation layer قبل التنفيذ، ودايماً اعتبر مخرجات النموذج untrusted input.
الأمان: لو الأداة بتعمل write operation (delete, transfer, send email)، لازم confirmation step بشري. النموذج ما يستحقش صلاحية مباشرة على عمليات حساسة.

متى لا تستخدم Function Calling

لو السؤال جوابه ثابت (FAQ)، ما تستعملوش. RAG بـ embeddings أرخص وأسرع. لو الأداة بتترجع نفس النتيجة دايماً للـ input نفسه، اعملها cache أو deterministic call مباشر بدل ما تخلي النموذج يقرّر.

كمان، لو عندك ≤ 3 احتمالات واضحة (مثلاً: تصنيف رسالة كـ شكوى/استفسار/شراء)، classification model عادي أرخص بـ 100x وأدق. Function Calling قوّته بتظهر لمّا يكون فيه قرار غير محدد مسبقاً.

الافتراضات اللي الكلام ده مبني عليها

الأرقام والأمثلة هنا مبنية على فرضية إنك بتستخدم نماذج Tier-1 الحديثة (Claude Sonnet 4.6, GPT-4o, Gemini 2.5). النماذج الأصغر (Haiku, GPT-4o-mini) دقّتها بتقل لـ 85–92% في اختيار الأداة الصح، خصوصاً لمّا تعدّي 10 أدوات.

الخطوة التالية

افتح أبسط use case في تطبيقك (واحد فيه استعلام بيانات live)، عرّف tool واحد بس بـ 1–2 parameter، وجرّبه على 20 سؤال حقيقي من users. لو دقّة الاستدعاء الصحيح أعلى من 90%، ابدأ توسّع. لو أقل، الـ description بتاع الـ tool محتاج تحسين قبل أي حاجة تانية.

Function Calling في الـ AI: إزاي تخلي Claude و GPT ينفّذوا أوامر فعلاً