المكاسب:
- تعريف الوكيل بأنه "نموذج + أدوات + حلقة" وتحديد متى تكون هناك حاجة إليه
- كتابة تعريف الأداة بالاسم والوصف ومخطط الإدخال
- مراقبة التدفق ومعالجة الأخطاء في حلقة استخدام الأداة وحلقة نتيجة الأداة
حتى الآن، كان النموذج يقوم دائمًا بمهمة واحدة: تلقي إدخال النص، وإنتاج استجابات نصية. لكن العمل الحقيقي يتطلب في كثير من الأحيان أكثر من مجرد نص؛ إجراء عملية حسابية، والاستعلام عن قاعدة بيانات، واستدعاء واجهة برمجة التطبيقات (API)، ومعرفة سعر الصرف الحالي. لا تستطيع العارضة القيام بهذه الأشياء بنفسها، ولكن يمكنها أن تقرر متى يجب القيام بها وتطلب من شخص ما القيام بها. هذا ما يعطيه استخدام الأداة للنموذج، وهذا هو أساس وكلاء الذكاء الاصطناعي. في هذه الوحدة، سوف نتعلم ما هو الوكيل، وكيف يتم تعريف الأداة، وكيف تعمل حلقة استخدام الأداة.
ما هو الوكيل؟ نموذج + أدوات + حلقة
يتكون وكيل الذكاء الاصطناعي من ثلاثة أجزاء: النموذج (العقل الذي يتخذ القرار)، والأدوات (الوظائف التي يمكن أن يستدعيها النموذج: الطقس، واستعلام قاعدة البيانات، وإرسال البريد الإلكتروني)، والحلقة (الحلقة؛ يستدعي النموذج الأداة، ويحصل على النتيجة، ويقرر مرة أخرى ما يجب القيام به، وما إلى ذلك).
التمييز الحاسم: استدعاء النمط الفردي ليس وكيلاً. الوكيل عبارة عن عملية يتقدم فيها النموذج خطوة بخطوة، وفي كل خطوة يتم اختيار الخطوة التالية بناءً على نتيجة الأداة. "فكر كإنسان، استخدم يديك، انظر إلى النتيجة، فكر مرة أخرى."
حقيقة مهمة: النموذج نفسه لا يقوم بتشغيل السيارة. يقول النموذج فقط "أريد استدعاء هذه الأداة بهذه المدخلات". يقوم تطبيقك (الذي يُسمى "الأداة المساعدة") بتشغيل الأداة وإرجاع النتيجة إلى النموذج. يعد هذا أمرًا حيويًا للأمان: لا يلمس النموذج نظامك مباشرةً؛ كل عمل تحت سيطرتك.
نصيحة: لا تحاول حل كل مشكلة مع الوكيل. عامل؛ يزيد من خطر التأخير والتكاليف والأخطاء. اسأل أولاً: "هل سيتم حل هذه المشكلة بمكالمة واحدة أم بسير عمل ثابت؟" إذا كان الجواب بنعم فلا داعي للوكيل. الوكيل مخصص للمهام المفتوحة حيث لا يمكن معرفة الخطوات مسبقًا.
تعريف الأداة: الاسم، الوصف، مخطط الإدخال
لإدخال أداة في النموذج، عليك تقديم ثلاثة أشياء:
- الاسم: هوية السيارة، على سبيل المثال. get_weather.
- الوصف: ماذا تفعل الأداة ومتى يتم استدعاؤها. هذا هو المجال الأكثر أهمية الذي يسمح للنموذج باختيار الأداة المناسبة في الوقت المناسب. لا تكتب فقط "ماذا يفعل" ولكن أيضًا "اتصل متى".
- input_schema (مخطط الإدخال): مخطط JSON الذي يحدد المعلمات التي تتوقعها الأداة، وفي أي نوع.
# تعريف المركبة (مفاهيمي — مخطط JSON){ "name": "get_order_status"، "description": "يسترجع حالة الشحن الحالية للطلب. اتصل عندما يسأل المستخدم عن مكان رقم الطلب أو متى سيصل.", "input_schema": { "type": "object", "properties": { "order_no": {"type": "string", "description": "رقم الطلب، على سبيل المثال SP-1024"} }, "مطلوب": ["order_no"] }}
قواعد لوصف جيد للأداة: اسم واضح وموجز، وصف مع "متى يتم الاستخدام"، وصف لكل معلمة، ووضع المعلمات الإلزامية حقًا في المطلوب. حافظ على تركيز عدد المركبات؛ العشرات من نماذج المركبات المماثلة مثيرة للدهشة.
المنطقة
ماذا يفعل؟
مثال جيد
مثال سيء
اسم
معرف المركبة
order_status_getir
إحضار
الوصف
ماذا يفعل + متى يتم الاتصال
"إرجاع حالة الشحن؛ اتصل عندما يسأل المستخدم عن مكان الطلب"
"جلب البيانات"
input_schema
نوع المعلمة والمتطلبات
{order_no: سلسلة، مشروحة}
لا يوجد رسم تخطيطي / لا وصف
أداة_استخدام → حلقة أداة_النتيجة
تعمل الدورة على النحو التالي، خطوة بخطوة:
- تقوم بإرسال سؤال المستخدم + أوصاف الأداة إلى النموذج.
- يستجيب النموذج مباشرة أو ينشئ كتلة استخدام الأداة: "اتصل بـ order_durumu_getir مع order_no=SP-1024."
- يقوم تطبيقك بالفعل بتشغيل الأداة (الاستعلام عن قاعدة البيانات).
- يمكنك إرسال النتيجة مرة أخرى إلى النموذج كأداة_نتيجة.
- وبهذه النتيجة، يقوم النموذج إما بإنتاج الإجابة النهائية أو باستدعاء أداة أخرى. تستمر الدورة حتى يقول النموذج "لقد انتهيت".
# حلقة الوكيل (المفاهيمية)messages = [user_question]while True: Response = model.uret(messages, Tools=tool_definitions) if Response.tur == "tool_use": result = Harring.run(response.tool_name, Response.entries) # APPLICATION run messages += [response, tool_result(result)] # return result else:break # Final Response; تنتهي الحلقة
تقدم حزم SDK الحديثة برامج تشغيل للأدوات التي تقوم بتشغيل هذه الحلقة نيابةً عنك؛ ما عليك سوى كتابة وظائف الأداة. ولكن هذا بالضبط ما يحدث وراء الكواليس.
إدارة الأخطاء
قد تفشل الأدوات: لم يتم العثور على الطلب، انتهت مهلة واجهة برمجة التطبيقات، والإدخال غير صالح. إذا لم تتمكن من تشغيل الأداة، قم بإرجاع الخطأ إلى النموذج كنتيجة أداة وصفية ("خطأ: لم يتم العثور على رقم الطلب SP-9999") وعلامة الخطأ. يمكن للنموذج رؤية ذلك وشرحه للمستخدم بلطف، أو تجربة طريقة مختلفة. لا تبتلع الخطأ وترجع نتائج فارغة؛ يجب أن يعرف النموذج الخطأ الذي حدث.
وصف السيارة ضعيف/قوي
ضعيف (اسم غير مسمى، لا "متى"):
الاسم: "بيانات"، الوصف: "جلب البيانات"# النموذج لا يعرف متى وكيف يتم الاتصال؛ إما أنه لا يتصل على الإطلاق أو يتصل بشكل غير صحيح.
قوي (اسم الشبكة + متى + وصف المعلمة):
الاسم: "musteri_bakiyesi_getir"description: "إرجاع رصيد الحساب الحالي للعميل. اتصل عندما يطلب المستخدم الخصم أو الائتمان أو الرصيد. لا يقوم بالدفع."input_schema: {custeri_id: string ("Customer ID")}# يتصل النموذج في الوقت المناسب، باستخدام المعلمات الصحيحة، مع العلم بحده.
ثلاث حالات صغيرة
الحالة 1 - وكيل غير ضروري. قام أحد الفرق ببناء مشروع "تلخيص النص" باستخدام وكيل متعدد الأدوات؛ تستغرق كل خلاصة 4 مكالمات نموذجية و9 ثوانٍ. كانت الوظيفة في الواقع وظيفة مكالمة واحدة. وعندما قمنا بإزالة الوكيل وتقليصه إلى مكالمة واحدة، انخفض الوقت إلى 1.5 ثانية وانخفضت التكلفة إلى الربع. الدرس المستفاد: استخدم الوكيل عندما يكون ذلك ضروريًا حقًا.
الحالة 2 - تفسير ضعيف، دعوة خاطئة. في وكيل الدعم، تم استدعاء أداة غامضة تسمى الجلب بشكل عشوائي بواسطة النموذج في كل من سؤال الرصيد وسؤال الشحن. عندما تم تقسيم المركبات إلى Balance_getir وcargo_durumu_getir وتمت إضافة تفسيرات "الاتصال عندما"، انخفض الاختيار الخاطئ للمركبة من 18 إلى 1 في 50 مثال.
الحالة 3 - تم ابتلاع الخطأ. كان الوكيل يُرجع نتائج فارغة عندما لم يتم العثور على الطلب؛ فسر النموذج ذلك على أنه "تم تسليم الطلب" وقام بتضليل العميل. عندما تتم كتابة رسالة الخطأ بشكل صريح إلى tool_result ("لم يتم العثور على الطلب")، يقول النموذج بشكل صحيح "لم أتمكن من العثور على هذا الرقم، هل يمكنك التحقق منه؟" بدأ يقول.
الأخطاء الشائعة
- تحويل كل شيء إلى وكيل: في حين أن مكالمة واحدة كافية، إلا أن الوكيل يضيف التكلفة والتأخير.
- وصف غامض للمركبة: النموذج لا يعرف متى يتصل؛ يختار خطأ.
- معتقدًا أن النموذج يدير السيارة: الحزام يدير السيارة؛ النموذج يريد فقط.
- استيعاب الخطأ: يجب أن يعرف النموذج الخطأ الذي حدث؛ أعط الخطأ كأداة مفتوحة.
- عدد كبير جدًا من المركبات المشابهة: يتم الخلط بين النموذج؛ حافظ على تركيز مجموعة الأدوات والحد الأدنى منها.
تنبيه: مجرد أن النموذج يقول "اتصل بهذه السيارة" لا يعني أنه يجب اتخاذ الإجراء. في الأدوات المدمرة (الحذف، الخروج، البريد الإلكتروني) يجب ألا يقوم تطبيقك بتنفيذ المكالمة بشكل أعمى - وهذا هو جوهر موضوع الأمان في الوحدة التالية.
باختصار
- الوكيل = النموذج (القرار) + الأدوات (الوظائف) + الحلقة (أداة الاتصال، الحصول على النتيجة، اتخاذ القرار مرة أخرى).
- استدعاء نمط واحد ليس وكيلاً؛ الوكيل هي عملية خطوة بخطوة.
- النموذج لا يقوم بتشغيل السيارة؛ يعمل تطبيقك (تسخير) ويعيد النتيجة كأداة_نتيجة.
- يتم تعريف الأداة بالاسم والوصف (على وجه التحديد "متى يتم الاتصال") ومخطط الإدخال.
- تستمر الحلقة كأداة_استخدام → تشغيل تسخير → أداة_نتيجة → يستمر النموذج حتى يقول النموذج "تم"؛ يتم الإبلاغ عن الأخطاء بشكل صريح إلى النموذج.
مهمة التطبيق
صمم 3 أدوات من عملك الخاص يمكن تقديمها للوكيل. (1) اكتب الاسم والوصف باستخدام "متى يتم الاتصال" ومخطط الإدخال لكل منهما؛ دع واحدة على الأقل تكون أداة قراءة غير مدمرة وواحدة عملية حسابية. (2) اختر سؤال مستخدم واقعيًا واكتب يدويًا خطوة بخطوة (في حلقة) أي من هذه الأدوات سيتصل بها النموذج وبأي مدخلات وماذا سيفعل بعد وصول نتيجة الأداة. (3) قم بإعداد سيناريو تفشل فيه إحدى الأدوات وأظهر كيف ستعود رسالة الخطأ إلى النموذج.
قائمة مرجعية
- [ ] يمكنني تعريف الوكيل على أنه "نموذج + أدوات + حلقة" وتحديد متى تكون هناك حاجة إليه.
- [ ] أعلم أن الحزام يدير السيارة، والنموذج يريد ذلك فقط.
- يمكنني كتابة وصف ثابت للمركبة باستخدام [ ] الاسم والوصف ("متى يتم الاتصال") ومخطط الإدخال.
- يمكنني متابعة دورة [ ] tool_use → tool_result خطوة بخطوة.
- [ ] أقوم بالإبلاغ عن أخطاء الأداة إلى النموذج كـ open tool_result.