الأدوات واستدعاء الدوال

القيد الأساسي للـ LLM

الـ LLM وحده لا يُنتج سوى النص، ويعجز عن:

• تصفّح الويب
• إجراء حسابات مضمونة الدقّة (يمكنه التفكير في الحساب، لكنه ليس آلة حاسبة دقيقة دائماً)
• الوصول إلى قواعد البيانات
• إرسال الرسائل
• قراءة الملفات
• استدعاء الـ APIs

يبقى محصوراً في عالم النص. اسأله "كم حاصل 7,392 × 8,451؟" فقد يخطئ تخمينٌ سريع مبنيّ على الأنماط، وحتى حين يستنتج الإجابة خطوةً خطوة، فهو ليس آلة الحساب المضمونة الدقّة التي تمنحك إياها الأداة. واسأله عن طقس اليوم فسيخمّن استناداً إلى بيانات تدريب مضى عليها أشهر.

الأدوات تحلّ هذا

الأدوات (وتُعرَف أيضاً بـ function calling) تتيح للمطوّرين أن يمنحوا النموذج قائمةً بالإجراءات التي يمكنه اتّخاذها.

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

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

مع الأدوات مقابل بدونها

النموذج نفسه، والسؤال نفسه. الأدوات تحوّل التخمين إلى معرفة.

من الـ tool calling إلى الـ agents

يُظهر المخطّط أعلاه استدعاءً واحداً لأداة: سؤال واحد، وأداة واحدة، وإجابة واحدة. لكن ماذا يحدث حين تحتاج المهمّة إلى خطوات متعدّدة؟

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

هنا يبدأ الـ agentic behavior. فبدلاً من ذهاب وإياب واحد، يدور النموذج في حلقة:

أترى الفرق؟ مخطّط الـ tool calling خطّ مستقيم. أمّا مخطّط الـ agentic ففيه حلقة، حيث يواصل النموذج المضيّ، مستدعياً أداةً بعد أداة، حتى يقرّر أنّ المهمّة اكتملت.

مشكلة الصلاحيات

هنا تصير الأمور جدّية.

إن منحت النموذج أدواتٍ لإرسال الرسائل وحذف الملفات، ثم خدعه أحدهم فاستدعى تلك الأدوات، فالضرر حقيقي. تُرسَل الرسالة فعلاً، ويُحذَف الملفّ فعلاً.

يتحوّل التلاعب بالنص إلى فعل ملموس في العالم الحقيقي.

وفي الـ agentic loop، يجرّ القرارُ السيّئ الواحد ما بعده. فالنموذج لا يكتفي باستدعاء خاطئ واحد، بل قد يحذف ملفاً، ويرسل محتواه بالبريد إلى الشخص الخطأ، ثم يمحو سجلّ البريد. كل إجراء يغذّي ما يليه، دون تدخّل بشري في الأثناء.

تخيّل نموذجاً يملك هذه الأدوات:

• send_email(to, subject, body)
• delete_file(path)
• query_database(sql)

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

لماذا يهمّ هذا

تحوّل الأدوات الـ LLMs من ألعاب طريفة إلى أنظمة قوية تتصرّف في العالم الحقيقي. والـ agentic loops تضخّم كل خطر، فتكفي تعليمة واحدة مُتلاعَبٌ بها لإطلاق سلسلة من الإجراءات الحقيقية. وهكذا تتراكم آثارها الأمنية:

• كيف تعمل الـ LLMs: النموذج في جوهره يتنبّأ بالنص دون أي فحص مدمج لما هو هذا النص، لذا يمكن خداعه
• الـ system prompts: تعليمات المطوِّر غير مُلزِمة؛ يمكن تجاوزها
• الـ RAG: البيانات الخارجية تتدفّق إلى الـ prompt، وقد تحمل تعليمات خفيّة
• الأدوات + الـ agents: نموذج مخدوع يملك أدوات قوية يُحدِث ضرراً حقيقياً، أمّا المستقلّ منه فيمضي في طريقه بلا توقّف

تبني كل طبقة على ما قبلها، ولهذا احتجت إلى إتقان الأساسيات أولاً.

جاهز لوحدات الأمن

صرت الآن تفهم اللبنات الأربع:

1. الـ LLMs متنبّئات بالنص، ذات context window محدود
2. الـ system prompts تُشكّل السلوك لكنها ليست حدوداً أمنية
3. الـ RAG يحقن مستندات خارجية في الـ prompt
4. الأدوات تتيح للنموذج إطلاق إجراءات في العالم الحقيقي، والـ agentic loops تتيح له تسلسلها

ستُريك وحدات الأمن كيف تستغلّ كلاً منها، وفي النهاية كيف تدافع عنها.