استدعاء الدوال في LLM لعام 2026: تصميم المخططات ومقارنة الموردين وأفضل الممارسات

آخر تحديث: 6 يوليو 2026

استدعاء الدوال (Function Calling) في LLM هو الآلية التي يُترجم بها النموذج طلبًا بلغة طبيعية إلى استدعاء منظَّم لأداة أو دالة يعرِّفها تطبيقك عبر مخطط JSON Schema، ثم يعيد الحجج مطابقة للمخطط ليتولى تطبيقك تنفيذها. في 2026 أصبحت هذه الآلية العمود الفقري للوكلاء الذكية وأنظمة الاسترجاع وأي منتج يتجاوز الدردشة المفتوحة. بصراحة، هذا الدليل ملخّص لما تعلمته بعد تطبيق مئات المخططات إنتاجيًا: كيف تصمم المخطط، وكيف تختار بين موردي النماذج، وكيف تُقيّم بشكل يمنع الانحدار في الإنتاج (أرقام حقيقية وأخطاء وقعت فيها بنفسي).

• موثوقية استدعاء الدوال في 2026 وصلت إلى 99.9% عند تفعيل فك التشفير المقيَّد لدى OpenAI و99.8% لدى Anthropic و99.7% لدى Gemini، مقابل 85-92% لوضع JSON بلا مخطط.
• OpenAI وGemini تعتمدان على فك التشفير المقيَّد على مستوى التوكن، بينما Anthropic تستخدم استخدام الأدوات (tool use) الذي يعيد الحقول في كتلة واحدة نهاية البث.
• القاعدة الذهبية: أسماء دوال لا لبس فيها، حقول required صريحة، ولا تتجاوز 20 دالة في نفس النداء وإلا ارتفع خطأ الاختيار.
• تحقق المخطط لا يضمن جودة القيم؛ أضِف طبقة تحقق دلالية بـ Pydantic أو Zod ثم قيّم عبر مجموعات اختبار مستمرة قبل كل نشر.
• افصل أدوات القراءة عن أدوات الكتابة، وطبّق مبدأ أقل صلاحية على كل أداة؛ عامِل كل نداء أداة باعتباره غير موثوق حتى يمر التحقق.
• تفعيل النداءات المتوازية للأدوات يقلل الكمون بنسبة 40-60% في مهام الاسترجاع، لكنه يفرض تصميم حالات لا اعتماد بين النداءات.

ما هو استدعاء الدوال في LLM؟

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

الاختلاف الجوهري بين هذا النمط وبين طلب JSON عام هو الالتزام على مستوى التوكن. عند تفعيل فك التشفير المقيَّد، يمنع مُشغّل الاستدلال النموذجَ من إصدار توكن لا يوافق قواعد المخطط، فتصبح مخالفة البنية مستحيلة تقنيًا لا مجرد غير مُرجَّحة. في تجربتي الشخصية، هذه هي أهم قفزة في الموثوقية بين 2023 و2026. قبلها كنا نلف كل استدعاء بحلقات إعادة محاولة (وطبقات تحقق ثلاثية أحيانًا)، والآن يذهب هذا التعقيد إلى طبقة الاستدلال ذاتها.

هذا النمط يمكِّن حالات استخدام لم تكن ممكنة بموثوقية إنتاجية: استخراج البيانات من مستندات غير منظَّمة، تنسيق وكلاء متعددة، توليد أوامر SQL آمنة، وربط نماذج اللغة بواجهات برمجة تطبيقات مؤسساتية. إذا كنت تبني نظام استرجاع معزز إنتاجي (RAG) فاستدعاء الدوال هو ما يسمح للنموذج بتنسيق مراحل الاسترجاع وإعادة الترتيب والفلترة الوصفية بدل خطوة استرجاع واحدة عمياء.

ما مدى موثوقية استدعاء الدوال في 2026؟

وفق المعايير المرجعية المنشورة في الربع الثاني من 2026، تتجاوز نسبة الالتزام بالمخطط 99.7% لدى جميع الموردين الرئيسيين حين تُفعَّل واجهة استدعاء الدوال الرسمية مع فك التشفير المقيَّد. تفصيليًا: OpenAI Structured Outputs عند 99.9%، Anthropic tool use عند 99.8%، Gemini responseSchema عند 99.7%. في المقابل، وضع JSON بدون فرض مخطط يخفق بين 8% و15% من النداءات، وهو رقم لا يحتمله أي مسار إنتاجي.

لكن الالتزام بالبنية شيء وصحة القيم الدلالية شيء آخر تمامًا. رأيت نماذج تمر بالمخطط بينما تعيد قيم enum "آمنة" افتراضيًا لأن ملخص الوصف كان مبهمًا. لهذا أفصل دومًا بين مقياسين في التقييم: نسبة الاستدعاءات المُنسَّقة جيدًا (Well-formed rate) ونسبة الاستدعاءات الصحيحة دلاليًا (Semantic accuracy). الأول يقاس بمُدقِّق المخطط، والثاني يحتاج مجموعة مرجعية مكتوبة يدويًا أو نمط تقييم الوكلاء الذكية.

على المستوى العملي، النماذج المفتوحة المنشورة محليًا مثل Llama 3.3 70B وQwen3 32B وصلت إلى نطاق 93-97% في نداءات جيدة التنسيق ضمن اختبارات MCP، مع فجوة ملحوظة مقارنةً بالأنظمة المُدارة عند سلاسل الأدوات المتعددة الخطوات. إن كنت تحتاج نموذجًا محليًا لسبب امتثالي، ابدأ بمجموعة اختبار ضيقة قبل تعميم الحل. هذا ما فعلته في مشروع بنكي قبل أشهر، ولولا مجموعة الاختبار المسبقة لدفعنا انحدارًا صامتًا للإنتاج.

الفرق بين المخرجات المنظمة واستدعاء الدوال

هذا السؤال يتكرر في كل مراجعة تصميم أُجريها، لذا أوضحه هنا مرة واحدة. "المخرجات المنظَّمة" (Structured Outputs) هي فرض بنية JSON على استجابة النموذج النصية النهائية. "استدعاء الدوال" (Function Calling) هو آلية اختيار أداة من كتالوج ثم تمرير حجج منظَّمة لتنفيذ خارجي. الآلية الأساسية (فك تشفير مقيَّد بمخطط) واحدة، لكن الاستخدام مختلف جذريًا.

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

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

مقارنة الموردين: OpenAI وAnthropic وGemini

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

الميزة	OpenAI	Anthropic Claude	Google Gemini
موثوقية المخطط	99.9%	99.8%	99.7%
آلية الفرض	فك تشفير مقيَّد + Pydantic	tool use مع input_schema	responseSchema + مقيَّد
الحد الأقصى لعمق المخطط	5 مستويات	بدون حد	5 مستويات
البث الحقلي	مدعوم	غير مدعوم	مدعوم
النداءات المتوازية	مدعومة أصليًا	مدعومة أصليًا	مدعومة
معالجة الرفض	حقل refusal صريح	غير مدعوم	عبر safetyRatings
عبء التوكن	30-100 توكن/نداء	80-250 توكن/نداء	30-150 توكن/نداء
الأفضل عند	مخططات ضيقة، بث تدريجي	مخططات عميقة، اتباع التعليمات	تكلفة أدنى لحجم كبير

لاحظ نقطتين. أولًا: انعدام الحد الأقصى لعمق المخطط عند Anthropic يجعله الخيار المفضل لهياكل شبيهة بالبروتوكولات (مثل تعريفات AST أو المخططات الشجرية). ثانيًا: البث الحقلي عند OpenAI وGemini يسمح ببناء واجهات مستخدم تعرض الحقول أثناء التوليد، وهذا مهم في تطبيقات النماذج والاستمارات الذكية.

تصميم مخطط JSON للأدوات

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

1. أسماء دوال محدَّدة الغرض: search_products وsearch_orders أوضح للنموذج من search مع معامل type. أسماء متمايزة تقلل خطأ الاختيار بنسبة ملحوظة.
2. وصف مختصر وسلوكي: صف ما تفعله الأداة ومتى تُستدعى، لا آلية عملها الداخلية. النموذج يقرأ الوصف كإشارة قرار، لا كوثيقة API.
3. حقول required صريحة: النموذج يتعامل مع الاختيارية غير المُصرَّحة بعشوائية. أعلن كل حقل مطلوب في مصفوفة required.
4. قيم enum بدل السلاسل الحرة: إن كان الحقل يقبل مجموعة محدودة (لغة، حالة، تصنيف)، فاستخدم enum. الاختيار المحدود يقفز من ~85% دقة إلى ~99% في اختباراتي.
5. حد أقصى 20 دالة لكل نداء: فوق هذا الحد ترتفع أخطاء الاختيار. استخدم نمط توجيه ثنائي المرحلة: نموذج صغير يختار مجموعة الأدوات ذات الصلة، ثم نموذج أكبر ينفذ.

مثال عملي بلغة Python يوضح تعريف أداة مع تحقق Pydantic لطبقة ثانية من الأمان الدلالي:

from pydantic import BaseModel, Field
from typing import Literal
from openai import OpenAI

client = OpenAI()

class SearchProductsArgs(BaseModel):
    query: str = Field(..., description="Product keywords, 1-6 words")
    category: Literal["electronics", "books", "clothing", "home"] = Field(
        ..., description="Product category to restrict search"
    )
    max_price: float | None = Field(None, ge=0, le=100000)
    in_stock_only: bool = Field(default=True)

tools = [{
    "type": "function",
    "function": {
        "name": "search_products",
        "description": "Search the product catalog by keywords and category. "
                       "Use when the user asks to find, browse, or filter products.",
        "parameters": SearchProductsArgs.model_json_schema(),
        "strict": True,
    },
}]

response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": "ابحث لي عن سماعات بلوتوث تحت 300 ريال"}],
    tools=tools,
    tool_choice="auto",
)

call = response.choices[0].message.tool_calls[0]
args = SearchProductsArgs.model_validate_json(call.function.arguments)
print(args)

لاحظ خطوة model_validate_json. المخطط يضمن البنية، وPydantic يفرض القيود الدلالية (النطاق، المصفوفات، الحقول المشتقة). هذه الطبقة الثانية اكتشفت لي قيم max_price بأرقام سالبة صدرت عن نموذج قديم لم يحترم قيد ge في وصف الحقل. حالة صغيرة، لكنها كانت ستكسر منطق العرض بالكامل لو مرّت.

النداءات المتوازية وسلاسل الأدوات

النداءات المتوازية (Parallel Tool Calls) تسمح للنموذج بإصدار عدة استدعاءات أدوات مستقلة في دورة استدلال واحدة. عمليًا، هذا يخفض الكمون بنسبة 40-60% في مهام مثل: جلب حالة عدة طلبات، مقارنة أسعار عبر موردين، أو استرجاع بيانات وصفية لمستندات متعددة. الشرط الجوهري: النداءات يجب أن تكون بلا اعتماد بينها (لا تحتاج نتيجة نداء آخر).

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

لسلاسل الأدوات متعددة الخطوات (مثلًا: ابحث ثم اختر ثم اطلب)، اعتبر النموذج مُخطِّطًا لا مُنفِّذًا. أعرض له نتيجة كل خطوة قبل الخطوة التالية، ولا تُدمج خطوات مستقلة منطقيًا في نداء واحد. للأنماط الأعمق راجع دليل بناء خوادم MCP للوكلاء الذكية الذي يُغطّي فصل طبقة الأدوات عن طبقة اتخاذ القرار.

كيف تُعالج الأخطاء في استدعاء الدوال؟

لا يوجد "معالجة أخطاء" عامة لاستدعاء الدوال. توجد أربع فئات أخطاء لكلٍّ منها استراتيجية مختلفة:

• خطأ اختيار الأداة: النموذج استدعى الأداة الخاطئة أو لم يستدعِ أداة. المعالجة: راجع وصف الأداة، أضِف مثالًا واحدًا في الرسالة النظامية، أو استخدم tool_choice صريحًا لإجبار الاختيار في السياقات الحرجة.
• خطأ الحجج: نداء يمر بالمخطط لكن القيم دلاليًا خاطئة (نطاق، مرجع، تاريخ). المعالجة: طبقة تحقق Pydantic/Zod ثانوية، ثم إعادة المحاولة مع رسالة خطأ وصفية للنموذج.
• خطأ تنفيذ الأداة: الأداة نفسها فشلت (خطأ شبكة، خدمة خارجية، قاعدة بيانات). المعالجة: أعِد الخطأ كرسالة أداة إلى النموذج ليقرر: إعادة محاولة، تعديل الحجج، أو الإبلاغ للمستخدم.
• خطأ الرفض: النموذج رفض الاستدعاء لأسباب سلامة. عند OpenAI يظهر في حقل refusal مخصص. عالجه صراحةً بدل افتراض النجاح.

from pydantic import ValidationError

def execute_tool_call(call, tools_registry):
    try:
        args_model = tools_registry[call.function.name]["schema"]
        args = args_model.model_validate_json(call.function.arguments)
    except ValidationError as e:
        return {"role": "tool", "tool_call_id": call.id,
                "content": f"Argument validation failed: {e.errors()}"}
    try:
        result = tools_registry[call.function.name]["fn"](args)
        return {"role": "tool", "tool_call_id": call.id,
                "content": result.model_dump_json()}
    except Exception as e:
        return {"role": "tool", "tool_call_id": call.id,
                "content": f"Tool execution error: {type(e).__name__}: {e}"}

التقييم المستمر ومنع الانحدار

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

1. 50-100 مثال لكل أداة مُصنَّفة يدويًا بحجج مرجعية.
2. 10-20 مثال تصادمي يختبر أطراف المخطط: قيم فارغة، تنسيقات لغوية بديلة، تعليمات متضاربة.
3. مقياس ثنائي: Well-formed rate (يمر التحقق)، وArgument accuracy (يطابق المرجع دلاليًا بمقارنة حقلية أو LLM-as-Judge).

اربط هذه المجموعة بخط CI. أي تراجع في أي من المقياسين يوقف النشر. بعد ثلاث سنوات من العمل بهذا النمط، لم أعد أتذكر متى دفعنا آخر انحدار في الإنتاج بسبب تغيير مخطط. للسياق الأشمل حول بنية التقييم راجع دليل تقييم وكلاء الذكاء الاصطناعي 2026.

أضف طبقة تتبع (Tracing) عبر أدوات مثل Langfuse أو LangSmith تُسجّل كل نداء وحججه والأداة المُختارة والاستجابة والزمن. عند حدوث انحدار في الإنتاج، هذه السجلات هي ما يسمح لك بعزل السبب في دقائق بدل ساعات. جرّبها ولن تعود.

أي نموذج LLM هو الأفضل لاستدعاء الدوال؟

لا يوجد "أفضل" مطلق. يوجد أفضل لمهمتك ومنظومتك. وفقًا للوحات الترتيب المرجعية في يوليو 2026: Llama 3.1 405B Instruct يتصدّر بنتيجة 41.1 على معايير استدعاء الأدوات، يليه Gemini 3.5 Flash عند 41.0 وClaude Opus 4.8 عند 40.8. الفجوة بين النماذج تظهر أكبر ما تكون في السلاسل متعددة الخطوات، لا في النداءات المفردة.

توصياتي العملية بحسب حالة الاستخدام:

• تطبيقات المستهلكين ذات الحجم العالي: Gemini 3.5 Flash لأفضل نسبة كلفة إلى موثوقية.
• وكلاء متعدد الخطوات في المؤسسات: Claude Opus 4.8 لعمق المخطط اللامحدود واتباع التعليمات القوي.
• البث الحقلي في واجهات المستخدم: OpenAI GPT-4.1 مع Structured Outputs.
• النشر المحلي/الامتثال: Llama 3.3 70B أو Qwen3 32B على بنية بـ 48 جيجابايت VRAM أو أكثر.

ولمن يسأل عن معيار موحّد: لوحة قيادة Berkeley Function-Calling Leaderboard هي المرجع الأكاديمي الأكثر تحديثًا واستخدامًا في المقارنات الرسمية.

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

هل استدعاء الدوال يعمل مع النماذج المحلية مفتوحة المصدر؟

نعم. Llama 3.3 وQwen3 وGemma 4 تدعم استدعاء الدوال أصليًا عبر واجهات مثل vLLM وllama.cpp. الموثوقية أقل قليلاً من الأنظمة المُدارة (93-97% مقابل 99.7%+)، ويُنصح بإضافة مكتبات فرض مخطط مثل Outlines أو Guidance للحصول على أرقام مقاربة للإنتاج.

ما الفرق بين tool_choice="auto" وtool_choice="required"؟

auto يترك للنموذج قرار الاستدعاء من عدمه، ويصلح للمساعدات العامة. required (أو تسمية أداة محددة) يُجبر النموذج على إصدار نداء، ويصلح لسياقات الاستخراج والتصنيف حين تعلم مسبقًا أن الاستجابة يجب أن تكون منظَّمة.

هل يجب تخزين تعريفات الأدوات في ذاكرة تخزين مؤقت؟

نعم إن كانت مستقرة. Anthropic وOpenAI يدعمان التخزين المؤقت للمُوجِّه (Prompt Caching) الذي يخفض تكلفة تعريفات الأدوات الطويلة بنسبة تصل إلى 90% للنداءات المتكررة. الشرط: ألا يتغير تعريف الأدوات بين النداءات.

كيف أمنع النموذج من "اختراع" أسماء دوال غير موجودة؟

فعِّل فك التشفير المقيَّد الرسمي (Structured Outputs أو tool use). يمنع هذا النموذجَ تقنيًا من إصدار أي اسم أداة خارج المُصرَّح. في وضع JSON العام بدون تقييد، هذه الظاهرة (Hallucinated tool names) تحدث في 3-7% من النداءات وتتطلب طبقة تحقق يدوية.

ما حد التعقيد الأقصى الذي يجب أن أستهدفه في مخطط أداة واحدة؟

قاعدة عملية: لا تتجاوز 12 حقلًا و3 مستويات تعشيش في المخطط الواحد. تجاوز هذا الحد يخفض دقة تعبئة الحجج بشكل ملحوظ. إن احتجت إلى بنية أعقد، قسّمها إلى أداتين متتابعتين، ولا تعتمد على قدرة النموذج على استيعاب كل الحقول دفعة واحدة.