أجزاء معاملات الأداة المتدفقة قد تعرض لنا اتجاه الطلب قبل اكتماله، لكنها ليست بالضرورة كائنات مستقلة جاهزة للتنفيذ. نقرأ مسار Responses الموثق ونؤلف جزأين يكونان عددا واحدا، كي لا يتحول ظهور رقم مبكر إلى مدخل مختلف عما اكتمل لاحقا.
الخلاصة السريعة
اجمع الأجزاء التابعة للاستدعاء نفسه وفق عقد التدفق؛ اكتمال نص المعاملات خطوة منفصلة عن فحصه وعن تنفيذ الدالة.
- يعرض دليل OpenAI أجزاء arguments في أحداث delta ثم حدث done بمعاملات مكتملة. [1] نقرأ أسماء أحداث المسار المحدد ولا نعممها على كل واجهة.
- في مثالنا يأتي الجزء {"count":1 ثم الجزء 2}؛ النص المجمع {"count":12}، وليس طلبا بعدد 1 تلاه طلب بعدد 2.
- نحفظ انتماء الأجزاء وترتيبها وإشارة الاكتمال الموثقة. عدد تحديثات العرض لا يساوي عدد الاستدعاءات، ولا نغلق الأقواس الناقصة بتخمين.
- بعد اكتمال المعاملات نفحص شكلها ومعناها قبل أي تنفيذ معتمد؛ done للمعاملات لا يثبت أن الدالة نفذت أو أن عملية واقعية نجحت.
ماذا يصل في التدفق الموثق؟
يبين دليل OpenAI لأحداث Responses أجزاء arguments في response.function_call_arguments.delta، ثم المعاملات المكتملة في response.function_call_arguments.done. [1]
نسمي arguments نص المعاملات الذي سيستعمله استدعاء بعينه. عرضه تدريجيا يختلف عن عرض جواب سردي للقارئ؛ فالمطلوب هنا إعادة بناء مدخل له بنية محددة. لا نعامل كل دفعة تصل كأنها طلب جديد مكتمل.
هذه أسماء أحداث في مسار موثق، لا مصطلحات عامة لكل موصل. عند استعمال مكتبة أخرى ينبغي قراءة ما تعيده هي، بدلا من البحث عن كلمة done في نص كتبه المساعد.
كيف يتغير معنى الرقم في مثالنا؟
نكتب مثالا تعليميا لدالة تحتاج عدد بطاقات في الحقل count. الجزء الأول الذي اخترناه هو {"count":1 والجزء الثاني 2}. وعند وصلهما بالترتيب يصبح النص {"count":12}. لم نولد هذين الجزأين بنموذج ولم نختبر محلل JSON.
الرقم 1 الذي ظهر أولا بادئة للقيمة 12 داخل النص الذي ألفناه. لذلك فإن بدء العملية على العدد 1 قبل وصول الجزء الثاني يستعمل مدخلا غير المدخل النهائي للمثال. كما أن قراءة 2 بوصفه طلبا مستقلا تضيع دوره في إتمام العدد.
لو كان المدخل النهائي مختلفا، تتغير المراجعة معه. لا نتوقع من أي جزء عددا معينا، ولا نجعل المثال وصفا لأحجام الدفعات المعتادة أو لطريقة تقسيم الرموز في كل نظام.
ما الذي نحتفظ به عند التجميع؟
في ورقة المراجعة المقترحة نسجل الاستدعاء المقصود وتتابع أجزائه والنص الذي تجمع وإشارة اكتماله. لو كانت لدينا أجزاء تخص استدعاءين، لا نضمها لمجرد أنها ظهرت على الشاشة بالتتابع؛ ينبغي حفظ انتمائها إلى مدخل كل واحد.
إذا انقطع المثال بعد الجزء الأول، لا نضيف قوسا من عندنا ثم نسمي القيمة مكتملة. غياب بقية الأجزاء نقص في المادة المتاحة، وليس دليلا على أن صاحب الطلب اختار العدد 1 أو أن الدالة فشلت.
وتظل تحديثات العرض وسيلة عرض، لا مقياسا لعدد طلبات الدوال. في مثال الجزأين لدينا كائن واحد مقترح؛ لم يصبح العدد اثنين لأن الشاشة تغيرت مرتين.
ماذا يأتي بعد النص المكتمل؟
نراجع هل صار النص كائنا تقبله واجهة الدالة، ثم هل count يمثل العدد الذي تتطلبه المهمة. اكتمال القوس والعدد لا يخبرنا هل المقصود بطاقات مطلوبة أو متاحة؛ يحتاج المعنى إلى تعريف المدخل ومصدر القيمة.
إذا نفذ معالج لاحقا، يراجع ناتجه في خطوة أخرى. لا نحول حدث اكتمال المعاملات إلى سجل تنفيذ أو إلى دليل على تجهيز اثنتي عشرة بطاقة. لم ننفذ تجميعا برمجيا أو استدعاء؛ فصلنا كتابة المدخل من استعماله.
المصادر ومتابعة القراءة
- OpenAI: Function calling — streaming (يفتح في نافذة جديدة)developers.openai.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.
