تقنية

معرف استدعاء الأداة: إلى أي طلب تعود النتيجة؟

مخطط يربط كل طلب لقراءة بطاقة بنتيجته رغم إعلان وصول نتيجة ب قبل أ.
رسم علاقات من إعداد بحر العلوم؛ لا يمثل وظائف نفذت.

ربط نتيجة الأداة بمعرف الاستدعاء يمنع نسبة جواب إلى الطلب الخطأ حين تتكرر الأداة. اسم read_card وحده لا يميز محاولة قراءة بطاقة من محاولة أخرى. نستعمل عقد call_id المسمي في دليل OpenAI ونؤلف طلبين ونتيجتين مختلفتين، دون إرسال عمل خلفي أو اختبار توازي.

الخلاصة السريعة

اربط الناتج بالاستدعاء المحدد وفقا للعقد؛ تشابه اسم الأداة أو ترتيب وصول الردود لا يقوم مقام هذا الربط.

  • يوجه دليل OpenAI للاستدعاء غير المتزامن إلى إعادة الناتج في طلب Responses لاحق مع call_id الأصلي لربطه باستدعائه. [1] لا نخترع معرفا من ترتيب الظهور.
  • لدينا طلب أ لقراءة بطاقة ج 1 وطلب ب لقراءة ج 2؛ أ وب معرفا استدعاء، بينما ج 1 وج 2 معرفا بطاقتين في مثالنا.
  • تصل نتيجة ب أولا وتحمل 9، ثم نتيجة أ وتحمل 5؛ نحفظ الربط أ مع 5 وب مع 9، ولا نبدل القيم بسبب ترتيب الوصول.
  • المعرف يحدد نسبة الناتج ولا يثبت صدق محتواه. عند غياب رابط موثوق تبقى النسبة مجهولة؛ لا يكمل جواب واحد الطلب الآخر ولا يثبت فشله.

أي معرف تقصده الوثائق؟

يوجه دليل OpenAI للاستدعاء غير المتزامن إلى تقديم الناتج في طلب Responses لاحق باستخدام call_id الأصلي لربطه بالاستدعاء. [1]

نحصر الفكرة في رابط الطلب بالناتج، لا في جميع إعدادات العمل الخلفي أو إتاحته لكل نموذج. المعرف هنا يتعلق بمحاولة الأداة المقصودة. ليس اسم الأداة وحده، ولا هو بالضرورة معرف الشيء الذي بحثت عنه.

هذا يتيح للمراجع طرح سؤال محدد: لأي استدعاء نسب هذا المحتوى؟ يأتي فحص المحتوى بعد معرفة هذه النسبة؛ لا يمنح حقل الربط شهادة بصحته.

كم هوية لدينا في مثال الطلبين؟

نؤلف طلب أ للأداة read_card مع البطاقة ج 1، وطلب ب للأداة نفسها مع البطاقة ج 2. أ وب اسمان تعليميان لمعرفي الاستدعاء، وج 1 وج 2 اسمان للبطاقتين المطلوبتين. هذه قائمة مصنوعة وليست بيانات خدمة.

تكرار اسم الأداة لا يدمج الطلبين. كما أن معرف البطاقة وحده لا يميز كل محاولة ممكنة لقراءتها؛ لو طلبت البطاقة نفسها مرتين، ينبغي أن نعرف أي محاولة نقارن بناتجها. لم نضف محاولة ثالثة إلى حسابنا.

نكتب في كل صف الأداة والبطاقة ومعرف الاستدعاء. إذا اختصرت واجهة العرض بعض هذه الحقول، فلا نستنتج الحقل المحذوف من لون الصف أو قربه من رسالة أخرى.

كيف نحفظ النسبة عند اختلاف الوصول؟

نعلن أن النتيجة المنسوبة إلى ب تحمل القيمة 9، وأنها وصلت أولا في ترتيب الورقة. وبعدها نضع النتيجة المنسوبة إلى أ وتحمل 5. القراءة الصحيحة للبطاقة هي أ مع 5 وب مع 9؛ أسبقية ظهور 9 لا تجعلها نتيجة أ.

لا نحدد ما تقيسه القيمتان لأن السؤال عن الربط، لا عن تقييم جودة تصنيف أو قياس. كذلك لا نزعم أن وصولهما بهذا الترتيب خاصية إلزامية للعمل الخلفي. اخترنا الترتيب العكسي كي يتضح خطأ المطابقة بالموضع وحده.

إذا بقي في سجلنا اسم read_card والرقم 9 فقط، دون نسبة إلى أ أو ب، تكون لدينا قيمة لا نعرف استدعاءها المقصود. لا نلصق ب بها لأنها تبدو مناسبة، ولا نخترع المعرف الناقص.

ماذا يبقى بعد معرفة الاستدعاء؟

بعد حفظ النسبة، نفحص معنى الحقل الذي عاد ومصدره ونسخة البطاقة التي تناولها. قد يكون الربط سليما والمحتوى بحاجة إلى مراجعة. وإذا وصل ناتج ب وحده، لا نصف ذلك بأنه اكتمال أ وب أو دليل فشل أ.

نقترح بطاقة تربط كل استدعاء بمدخله ومخرجه الذي راجعناه، مع إبقاء روابط النتائج المجهولة صريحة. لم نشغل وظائف أو نجرب واجهة؛ جعلنا تكرر الاسم واختلاف ترتيب الرد سببين واضحين للاحتفاظ بهوية كل محاولة.

المصادر ومتابعة القراءة

  1. OpenAI: Async tool calling (يفتح في نافذة جديدة)developers.openai.com

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.