يساعد Function Calling النموذج على طلب تنفيذ وظائف محددة.
يستخدمه التطبيق لربط الذكاء الاصطناعي بالبيانات والأدوات.
في هذا الدليل سنشرح التدفق بمثال واضح وآمن.
ما المقصود بـ Function Calling؟
Function Calling هو أسلوب لطلب تنفيذ وظيفة عبر النموذج.
يرسل النموذج اسم الوظيفة والمعاملات بتنسيق منظم.
بعد ذلك ينفذ التطبيق الوظيفة، ثم يعيد النتيجة للنموذج.
قد تسمى الآلية أيضًا Tool Calling في بعض المنصات.
لماذا نحتاج إلى هذه التقنية؟
النموذج وحده لا يملك تلقائيًا صلاحية دخول أنظمتك.
ولا يستطيع قراءة قاعدة بيانات خاصة دون تكامل مصرح به.
يتيح Function Calling للتطبيق توفير وظائف محددة وآمنة.
مثل البحث عن طلب، أو حساب مبلغ، أو قراءة سجل.
كيف تسير عملية الاستدعاء؟
- يعرّف المطور الوظيفة ووصفها ومعاملاتها.
- يرسل التطبيق السؤال وتعريفات الأدوات إلى النموذج.
- قد يطلب النموذج استدعاء وظيفة مناسبة.
- يتحقق التطبيق من المعاملات والصلاحيات.
- ينفذ التطبيق الوظيفة ويعيد نتيجتها إلى النموذج.
- يصيغ النموذج الرد النهائي بناءً على النتيجة.
الخطوات الدقيقة تختلف حسب واجهة API المستخدمة.
لكن المهم أن طلب النموذج لا يعني أن الإجراء نُفذ بالفعل.
مثال عملي: معرفة حالة طلب
لنفترض أن العميل يسأل عن طلب رقمه 4587.
يمكن أن يختار النموذج وظيفة باسم get_order_status.
ويطلب تمرير رقم الطلب فقط.
{
"name": "get_order_status",
"arguments": {
"order_id": "4587"
}
}هذا مثال توضيحي لشكل الاستدعاء، وليس تنفيذًا حقيقيًا.
يتحقق التطبيق من هوية المستخدم وصلاحيته أولًا.
ثم يبحث في النظام ويرسل النتيجة الفعلية إلى النموذج.
إذا لم يجد الطلب، يجب أن يعيد نتيجة واضحة بذلك.
تعريف الوظيفة باستخدام JSON Schema
يحتاج النموذج إلى وصف واضح لما تفعله الوظيفة.
كما يحتاج إلى معرفة أسماء المعاملات وأنواعها.
يساعد JSON Schema في تحديد شكل المدخلات المقبولة.
{
"type": "function",
"name": "get_order_status",
"description": "Get the status of an order",
"parameters": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "The customer's order ID"
}
},
"required": ["order_id"],
"additionalProperties": false
},
"strict": true
}هذا مثال قريب من صيغة OpenAI الحديثة، وليس معيارًا موحدًا لكل المنصات.
تختلف الحقول المدعومة بين مزود وآخر.
راجع وثائق المنصة قبل نسخ التعريف إلى مشروعك.
ما أهمية التحقق من المعاملات؟
قد يرسل النموذج قيمة ناقصة أو غير متوقعة.
لذلك لا تمرر المعاملات مباشرة إلى النظام الحساس.
تحقق من النوع والطول والقيم المسموح بها.
واستخدم استعلامات آمنة عند التعامل مع قواعد البيانات.
يجب ألا تكون أوصاف الأدوات بديلًا عن التحقق البرمجي.
Function Calling لا ينفذ الأوامر وحده
إذا طلب النموذج وظيفة لإرسال بريد، فهو لم يرسل البريد بعد.
التطبيق هو الذي يستقبل الطلب ويقرر السماح بتنفيذه.
يمكنه طلب موافقة المستخدم قبل أي إجراء مؤثر.
وهذا مهم عند الدفع أو الحذف أو تغيير بيانات العملاء.
مثال لسير عمل آمن
- يطلب المستخدم إنشاء فاتورة.
- يقترح النموذج استدعاء وظيفة إنشاء الفاتورة.
- يتحقق النظام من تفاصيل الطلب والأسعار.
- يعرض ملخص الفاتورة للمستخدم للمراجعة.
- بعد الموافقة، ينفذ النظام الإجراء المصرح به.
- يحفظ النظام سجلًا بالنتيجة ووقت التنفيذ.
يمكن أن تختلف الخطوات وفق مستوى المخاطر وطبيعة العمل.
متى تستخدم Function Calling؟
- للبحث في بيانات العملاء والطلبات.
- لحساب الأسعار والخصومات وفق قواعد واضحة.
- للوصول إلى خدمات خارجية عبر API.
- لإنشاء مسودة تقرير من بيانات معتمدة.
- لتنفيذ خطوات محددة بعد التحقق والموافقة.
لا تستخدمه لمجرد إضافة تعقيد إلى سؤال بسيط.
إن كانت الإجابة لا تحتاج بيانات أو إجراءً خارجيًا، فقد يكفي الرد العادي.
ما الفرق بين Function Calling وMCP؟
Function Calling يصف طريقة طلب النموذج تنفيذ وظيفة.
أما MCP فهو بروتوكول لربط التطبيقات بالأدوات والموارد.
يمكن أن يعمل الاثنان معًا داخل نظام واحد.
اقرأ أيضًا شرح MCP في الذكاء الاصطناعي.
ما الفرق بين Function Calling وAI Agents؟
Function Calling آلية لاستدعاء الأدوات من داخل التطبيق.
أما الوكيل فقد يخطط لخطوات متعددة ويستخدم أدوات متتابعة.
استدعاء الوظيفة قد يكون جزءًا من عمل الوكيل.
اقرأ دليل وكلاء الذكاء الاصطناعي AI Agents.
ويمكنك الاطلاع على تنسيق سير عمل الذكاء الاصطناعي.
كيف تختبر جودة Function Calling؟
ابدأ بأسئلة واضحة، ثم أضف الحالات غير المكتملة.
اختبر المعاملات الخاطئة والقيم المفقودة والمتعارضة.
راجع هل اختار النموذج الوظيفة المناسبة أم لا.
تحقق من دقة التنفيذ، لا من صياغة الرد فقط.
وسجل التكلفة والوقت والأخطاء وعمليات الرفض الآمنة.
| المقياس | ما الذي يقيسه؟ |
|---|---|
| اختيار الوظيفة | هل اختيرت الأداة الصحيحة؟ |
| صحة المعاملات | هل كانت المدخلات مكتملة وصحيحة؟ |
| نجاح التنفيذ | هل أعاد النظام النتيجة المتوقعة؟ |
| الأمان | هل رُفضت العمليات غير المصرح بها؟ |
أخطاء شائعة يجب تجنبها
- أسماء وظائف غامضة لا توضح استخدامها.
- إتاحة أدوات كثيرة بلا حاجة فعلية.
- الثقة بمعاملات النموذج دون تحقق.
- تنفيذ إجراءات خطيرة دون موافقة مناسبة.
- إظهار نجاح العملية قبل تأكيد النظام تنفيذها.
- إهمال تسجيل الأخطاء ونتائج الأدوات.
أوامر جاهزة لتخطيط الوظائف
يمكنك استخدام الأمر التالي عند تصميم وظيفة جديدة.
صمّم تعريف Function Calling لوظيفة محددة. حدد الهدف والمعاملات وأنواعها والقيم المسموحة. اذكر حالات الخطأ والتحقق والصلاحيات المطلوبة. لا تفترض أن النموذج ينفذ الوظيفة بنفسه.
ما البيانات التي يحتوي عليها تعريف الوظيفة؟
يبدأ التعريف باسم قصير يعبّر عن الإجراء.
ثم يأتي وصف يوضح متى تستخدم الوظيفة ومتى لا تستخدمها.
بعد ذلك تحدد المعاملات وأنواعها والقيم المقبولة.
وأخيرًا توضح بنية البيانات التي يتوقعها التطبيق.
كلما كان الوصف دقيقًا، قلّ احتمال اختيار وظيفة غير مناسبة.
لكن الوصف الجيد لا يلغي ضرورة التحقق داخل التطبيق.
كيف تختار النموذج الوظيفة المناسبة؟
يرسل التطبيق السؤال مع الوظائف المتاحة للنموذج.
يقرر النموذج هل يحتاج إلى أداة أم يستطيع الإجابة مباشرة.
إذا اختار أداة، يعيد اسمها ومعاملاتها دون تنفيذها.
قد تسمح الواجهة بالاختيار التلقائي أو فرض وظيفة معينة.
وقد تسمح بتحديد مجموعة صغيرة من الأدوات المسموح بها.
تختلف أسماء الإعدادات وطريقة استخدامها حسب مزود الخدمة.
ماذا يحدث إذا كانت المعاملات غير صحيحة؟
لا ينبغي اعتبار مخرجات النموذج مدخلات موثوقة تلقائيًا.
افحص الحقول المطلوبة وأنواع البيانات والقيم المسموحة.
ارفض رقم طلب غير صالح قبل الاتصال بقاعدة البيانات.
ولا تسمح بتغيير معرّف مستخدم لا يملك صلاحية الوصول إليه.
أعد خطأً واضحًا ومحدودًا إذا تعذر تنفيذ الوظيفة.
بعدها يمكن للنموذج شرح المشكلة أو طلب معلومات إضافية.
مثال تطبيقي في متجر إلكتروني
تريد خدمة العملاء معرفة حالة طلب أحد العملاء.
يعرض التطبيق وظيفة واحدة اسمها get_order_status.
تقبل الوظيفة رقم الطلب فقط، ولا تقبل حقولًا إضافية.
يطلب النموذج تنفيذها مع الرقم الذي ذكره العميل.
يتأكد الخادم من هوية العميل وملكيته للطلب.
ثم يسترجع حالة الطلب من نظام المتجر.
قد تكون النتيجة: قيد التجهيز، أو تم الشحن، أو تم التسليم.
يرسل التطبيق الحالة الفعلية إلى النموذج.
يصيغ النموذج ردًا مفهومًا اعتمادًا على تلك النتيجة.
إذا فشل الاتصال، فلا يجوز ادعاء أن الطلب تم العثور عليه.
مثال مبسط لمنطق التنفيذ
التنفيذ الحقيقي يعتمد على اللغة ومكتبة API المستخدمة.
لكن منطق التطبيق يمكن تلخيصه كما يلي:
if tool_call.name == "get_order_status":
args = validate(tool_call.arguments)
authorize_user(current_user, args["order_id"])
result = order_service.get_status(args["order_id"])
send_tool_result(tool_call.id, result)
else:
reject_unknown_tool(tool_call.name)هذا نموذج توضيحي، وليس كودًا جاهزًا للإنتاج.
يجب أن تتضمن النسخة الفعلية معالجة للأخطاء والسجلات والصلاحيات.
متى يمكن تشغيل عدة وظائف بالتوازي؟
قد يحتاج التقرير إلى قراءة المبيعات والمخزون في الوقت نفسه.
يمكن تنفيذ الطلبين بالتوازي إذا كانا مستقلين.
أما إذا احتاج الثاني إلى نتيجة الأول، فيجب انتظارها.
التنفيذ المتوازي قد يقلل زمن الانتظار في المهام المناسبة.
لكنه يحتاج إلى إدارة أخطاء كل وظيفة على حدة.
ولا يعني تزامن الطلبات أن النتائج صحيحة أو مكتملة.
كيف تقيس نجاح النظام؟
أنشئ مجموعة اختبار تمثل طلبات المستخدمين المعتادة.
أضف إليها أسئلة غامضة وطلبات ناقصة وحالات غير مسموحة.
سجّل الوظيفة التي اختارها النموذج لكل طلب.
ثم تحقق من صحة المعاملات ونتيجة التنفيذ.
قِس عدد مرات الفشل وزمن الاستجابة والتكلفة.
اختبر أيضًا هل رفض النظام الإجراء عندما لم تتوفر الصلاحية.
أعد الاختبارات بعد تعديل وصف الوظيفة أو مخطط المعاملات.
مخاطر تحتاج إلى ضوابط خاصة
إرسال بريد أو حذف سجل يختلف عن قراءة معلومة عامة.
حدد الإجراءات التي تحتاج موافقة بشرية صريحة.
استخدم صلاحيات محدودة بدل حساب إداري شامل.
لا تضع مفاتيح API أو كلمات المرور في وصف الوظيفة.
قلل البيانات الشخصية التي ترسل إلى النموذج.
احتفظ بسجل للطلبات والنتائج وفق سياسة الخصوصية المعتمدة.
ضع حدودًا للوقت والتكلفة وعدد مرات إعادة المحاولة.
متى لا يكون Function Calling هو الحل الأفضل؟
لا تحتاج كل محادثة إلى استدعاء وظيفة خارجية.
الأسئلة العامة قد لا تتطلب تنفيذ أي إجراء.
إذا كان سير العمل ثابتًا تمامًا، فقد تكفي قواعد برمجية.
وإذا احتاجت المهمة إلى بيانات داخل مستندات، فقد يناسبها RAG.
يمكن الجمع بين الأساليب عندما تخدم كل آلية جزءًا واضحًا.
مصادر موثوقة للتعلم
- دليل Function Calling الرسمي من OpenAI
- Function Calling في Gemini API
- دليل استخدام الأدوات في Claude
أسئلة شائعة
هل ينفذ النموذج الوظيفة بنفسه؟
لا، التطبيق ينفذها بعد استلام الطلب والتحقق منه.
هل يحتاج Function Calling إلى API؟
ليس دائمًا، لكن كثيرًا من الوظائف تتصل بخدمات أو بيانات خارجية.
هل Function Calling آمن تلقائيًا؟
لا. الأمان يعتمد على التحقق والصلاحيات والموافقات وتصميم التطبيق.
هل يمكن استدعاء أكثر من وظيفة؟
نعم، إذا كانت المنصة تدعم ذلك وصُمم التطبيق لإدارة النتائج.
الخلاصة
يجعل Function Calling ربط النماذج بالأدوات أكثر تنظيمًا.
لكن نجاحه يعتمد على تعريف الوظائف والتحقق والأمان.
ابدأ بوظيفة واحدة، واختبرها، ثم وسّع النظام حسب الحاجة.
التعليقات