أداة النص الحر في الوكيل تحتاج إلى قراءة نوع المدخل، لا شكل طلب الشبكة وحده. قد يضم الطلب تعريف أداة في JSON، بينما يستقبل معالج الأداة سلسلة نصية. نقرأ المثال التعليمي الرسمي لـ OpenAI على Amazon Bedrock، ثم نؤلف ملاحظة قصيرة لشرح أثر الفاصل دون استدعاء نموذج أو محلل فعلي.
الخلاصة السريعة
ليس بالضرورة؛ الأداة المخصصة النصية في المثال تستقبل نصا حرا. غلاف تعريفها وقاعدة قراءة النص سؤالان آخران، ولا تثبت ملاحظة منسقة أن النموذج استدعاها.
- مثال OpenAI على Bedrock يقدم أداة custom ذات format من نوع text؛ ترسل نصا حرا إلى منطق التطبيق بدل كائن معاملات JSON مطلوب. [1] نقصر الإسناد على المثال المذكور.
- نعرف محليا ملاحظة من ثلاثة أجزاء مفصولة بعلامة |: بطاقة، لون، غرض. كتابة الفاصل داخل أحد الأجزاء تعطي أربعة أجزاء وتخالف قاعدتنا المعلنة؛ النص الحر لا يعرف معناها من تلقائه.
- كود المصدر يميز وجود custom_tool_call عن غيابه، ويعرض في حالة الغياب معالجة محلية بديلة. [1] لا ننسب ناتج البديل إلى استدعاء نموذج لم يظهر.
- راجع نوع المدخل وقاعدة التحليل ومعرف الطلب والناتج الفعلي كلًا على حدة؛ النص المنسق لا يثبت صحة اللون أو الغرض، ولم نشغل أداة أو نختبر توافق نموذج.
غلاف التعريف ليس مدخل المعالج
في مثال OpenAI على Bedrock، تعريف custom يستخدم format من نوع text، وتستقبل الأداة نصا حرا بدلا من كائن معاملات JSON المطلوب للأداة المنظمة. [1]
قد نرى الأقواس والمفاتيح في تعريف الأداة ونظن أن الملاحظة المرسلة إليها يجب أن تكون كائنا أيضا. لكن التعريف يخبر النظام بنوع الأداة، بينما المادة التي يقرأها معالجها هي المدخل المحدد لذلك النوع.
نسمي كل طبقة في ورقة المراجعة: تعريف الأداة، مدخلها، وما يرجعه التطبيق. لا ننقل قاعدة كائن المعاملات إلى سلسلة نصية بمجرد أن الاثنين داخل طلب واحد، ولا نعمم دعم المثال على كل نموذج أو خدمة.
كيف تغير علامة واحدة عدد الأجزاء؟
نضع قاعدة محلية مؤلفة: مدخلنا ثلاثة أجزاء، بهذا الترتيب: معرف البطاقة، اللون، الغرض؛ يفصل بينها |، ونرفض أي عدد آخر. الملاحظة «ب 9 | أزرق | نشاط طي» تعطي ثلاثة أجزاء عند الفصل بهذه العلامة.
ثم نؤلف الملاحظة «ب 9 | أزرق | نشاط طي | عرض». أصبحت أربعة أجزاء. إذا كان المقصود أن «نشاط طي | عرض» غرض واحد، فلا يمكن لقاعدتنا الحالية معرفته، لأننا خصصنا العلامة للفصل ولم نعلن طريقة لكتابتها داخل القيمة.
نسجل مخالفة القاعدة بدل إسقاط الجزء الرابع بصمت أو دمج أجزاء بالتخمين. يمكن اقتراح طريقة ترميز مختلفة قبل الاستخدام، لكن لا نزعم أنها مفعلة في المثال أو أنها صلحت طلبا فعليا.
هل الناتج المحلي يثبت استدعاء الأداة؟
يميز كود المثال بين وجود custom_tool_call وبين غيابه؛ في فرع الغياب يعرض معالجة محلية بديلة ويبين أنها ليست استدعاء أداة من النموذج. [1]
لهذا لا تكفي ملاحظة تظهر بعناوين مرتبة للحكم على المسار. نحتاج نوع العنصر الذي صدر، وما أدخله التطبيق إلى المعالج، وهل استعمل بديله المحلي. قد يشبه العرض النهائي عرضا كان سينتجه استدعاء، دون أن يكون الدليل على ذلك الاستدعاء.
في تمريننا لم يصدر أي عنصر من نموذج. فصلنا عبارتين على الورق بحسب قاعدة أعلنّاها. لا ننسب هذا العد إلى نظام Bedrock أو إلى نتيجة أداء منشورة، ولا ننقل بيانات متجر المثال إلى بطاقتنا.
أي مراجعة تبقى بعد سلامة الشكل؟
احتفظ بمعرف الطلب ونوع العنصر والمادة التي حللتها وقاعدة تقسيمها. ثم قابل اللون والغرض بسجل البطاقة المناسب؛ عدد الأجزاء الصحيح لا يثبت أن عبارة «أزرق» تصف البطاقة ب 9 فعلا.
إذا كانت المهمة مجرد عرض ملاحظة، فلا تحول النص إلى تنفيذ أمر لم يطلبه المستخدم. وجود كلمات قابلة للقراءة لا يمنح المعالج صلاحية إجراء خارج المهمة، ولا يثبت أنه يستطيع تنفيذ كل ما تذكره السلسلة.
الشرح هنا لفصل التمثيلات والمسارات: غلاف تعريف، ومدخل نصي، وتحليل محلي، ثم مراجعة معنى الناتج. لم نرسل طلب API أو نشغل الكود أو نقيس دقة أداة.
المصادر ومتابعة القراءة
- OpenAI Cookbook: Bedrock custom text tool example (يفتح في نافذة جديدة)developers.openai.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.