عام 2025 هو عام الوكلاء ، والقدرة الرئيسية للوكلاء هي أدوات الاستدعاء. عند استخدام Claude Code ، يمكنني إخبار الذكاء الاصطناعي بالتدقيق في النشرة الإخبارية ، والعثور على جميع الروابط للشركات الناشئة ، والتحقق من وجودها في CRM الخاص بنا ، بأمر واحد. قد يتضمن ذلك استدعاء اثنين أو ثلاثة أدوات مختلفة. ولكن هنا تكمن المشكلة: استخدام نموذج أساس كبير لهذا الغرض مكلف ، وغالبا ما يكون محدودا بمعدل ، ويتم التغلب عليه لمهمة الاختيار. ما هي أفضل طريقة لبناء نظام وكيل باستخدام استدعاء الأداة؟ الجواب يكمن في نماذج العمل الصغيرة. أصدرت NVIDIA ورقة مقنعة تجادل بأن "نماذج اللغات الصغيرة (SLMs) قوية بما فيه الكفاية ، وأكثر ملاءمة بطبيعتها ، وبالضرورة أكثر اقتصادا للعديد من الدعاء في الأنظمة الوكيلة". لقد كنت أختبر نماذج محلية مختلفة للتحقق من صحة تمرين خفض التكاليف. لقد بدأت بنموذج معلمة Qwen3: 30b ، والذي يعمل ولكنه يمكن أن يكون بطيئا جدا لأنه نموذج كبير ، على الرغم من أن 3 مليارات فقط من تلك المعلمات البالغ عددها 30 مليار معلمة نشطة في أي وقت. توصي ورقة NVIDIA بنموذج Salesforce xLAM - وهي بنية مختلفة تسمى نموذج عمل كبير مصمم خصيصا لاختيار الأداة. لذلك ، أجريت اختبارا خاصا بي ، كل نموذج يستدعي أداة لإدراج مهام Asana الخاصة بي. كانت النتائج مذهلة: أكملت xLAM المهام في 2.61 ثانية بنجاح 100٪ ، بينما استغرق Qwen 9.82 ثانية بنجاح 92٪ - ما يقرب من أربعة أضعاف الوقت. تظهر هذه التجربة كسب السرعة ، ولكن هناك مقايضة: مقدار الذكاء الذي يجب أن يعيش في النموذج مقابل الأدوات نفسها. هذا محدود مع النماذج الأكبر مثل Qwen ، يمكن أن تكون الأدوات أبسط لأن النموذج يتمتع بقدرة أفضل على تحمل الأخطاء ويمكنه التغلب على واجهات سيئة التصميم. يعوض النموذج عن قيود الأداة من خلال التفكير بالقوة الغاشمة. مع النماذج الأصغر ، يكون للنموذج قدرة أقل على التعافي من الأخطاء ، لذلك يجب أن تكون الأدوات أكثر قوة ومنطق الاختيار أكثر دقة. قد يبدو هذا قيدا ، لكنه في الواقع ميزة. يزيل هذا القيد معدل الخطأ المركب للأدوات المتسلسلة LLM. عندما تقوم النماذج الكبيرة بإجراء استدعاءات متسلسلة للأدوات ، تتراكم الأخطاء بشكل كبير. تفرض نماذج الحركة الصغيرة تصميما أفضل للنظام ، مع الحفاظ على أفضل ما في LLMs ودمجها مع النماذج المتخصصة. هذه البنية أكثر كفاءة وأسرع وأكثر قابلية للتنبؤ.