طلب تنبؤ عبر REST يحتاج إلى بنية توافق عقد الخدمة، إلى جانب نص JSON قابل للقراءة. توثق TensorFlow Serving للتنبؤ صيغة صفية باسم instances وصيغة عمودية باسم inputs. [1]
الخلاصة السريعة
حدد أسماء المدخلات وأنواعها، ثم استخدم تنسيق الخدمة المقصود؛ قراءة JSON لا تثبت اكتمال المدخل أو صحة التنبؤ.
- صيغة التنبؤ الموثقة تختار instances أو inputs، ولا تجمع المفتاحين في الطلب نفسه. [1]
- في عقدنا الافتراضي يلزم العددان left وright، والخرج left + 2 × right؛ وجود left وحده أو right كنص لا يفي بالشروط التي اخترناها.
- تجمع الصيغة الصفية الأمثلة، وتتطلب أن تشترك المدخلات المسماة في حجم البعد الأول؛ المدخلات ذات الأحجام المختلفة تستعمل الصيغة العمودية الموثقة. [1]
- لزوجين (2، 5) و(4، 1) نحسب 12 و 6 تحت القاعدة نفسها؛ ربط الخرج بالمدخل لا يثبت دقته الواقعية أو تشغيل خدمة.
اختر شكل الطلب الذي تقبله الواجهة
تصف وثائق Predict طلبًا من كائن JSON، مع تمثيل صفّي عبر instances أو عمودي عبر inputs. وجود الاثنين معًا غير مسموح في هذا العقد. [1]
الأسماء هنا جزء من واجهة محددة، وليست قاعدة لكل خدمة REST أو لكل نموذج. قبل كتابة طلب، اعرف نوع المهمة والعقد الذي تستقبله الواجهة. مثال تنسيق رأيته في خدمة أخرى قد يكون سليمًا نصيًا، ثم لا يكون طلب تنبؤ صالحًا هنا.
فكر في جدول له حقول معروفة: تستطيع قراءة جملة عربية كاملة لكنها لا تملأ الحقول المطلوبة تلقائيًا. بالمثل، صلاحية النص للنقل والقراءة خطوة أولى، يتبعها تفسيره وفق عقد المهمة.
ماذا لو قرئ النص وغاب مدخل؟
نضع عقدًا افتراضيًا لآلة حساب: تحتاج إلى مدخلين مسميين left وright، كلاهما عدد، ثم تعطي left + 2 × right. نعلن أن هذه الآلة لا تحول النصوص إلى أعداد تلقائيًا. هذه شروط اخترناها للشرح، وليست وصفًا لسلوك كل خادم.
بطاقة فيها left يساوي 2 وحده تترك right غير محدد. لا يجوز أن نفترض أن الغياب يعني صفرًا؛ لم يعلن العقد قيمة افتراضية. وبطاقة فيها right يساوي النص «5» لا تحقق شرط العدد في سياستنا، مع أن النص قابل للقراءة.
أما الزوج العددي left يساوي 2 وright يساوي 5، فيعطي 2 + 2 × 5 = 12. تسجيل أسماء المدخلات يجعل الخطأ قابلًا للتحديد: غياب حقل، أو نوع غير مقبول، أو حساب مختلف. لم نرسل هذه البطاقات إلى خادم ولم نرصد رمز خطأ.
كيف تمثل أكثر من مثال؟
في التنسيق الصفّي الموثق تضم instances أمثلة متتابعة، ويمكن لكل مثال تسمية مدخلاته. تشترك المدخلات المسماة في حجم البعد الأول؛ إذا اختلفت أحجامه فالتنسيق العمودي هو الصيغة الموثقة المناسبة. [1]
نختار زوجين للآلة نفسها: (2، 5) ثم (4، 1). تستطيع بطاقتنا التعليمية أن تعرض صفين، في كل منهما left وright. أو تعرض عمود left بالقيمتين 2 و 4، وعمود right بالقيمتين 5 و 1. في هذا المثال يتساوى العددان: مدخلان لكل عمود.
لا تضف قيمة ثالثة إلى right ثم تفترض أنها تقابل صفًا موجودًا في left. تغيرت البنية التي وصفناها. هذا يوضح لماذا نقرأ شرط حجم البعد؛ لا يقرر شكل كل موتر أو تحويل آلي لم ننفذه.
ما الذي تعنيه نتيجة الطلب؟
بحساب القاعدة المعلنة نحصل على 12 للزوج الأول و 6 للثاني. نسجل بجوار كل نتيجة زوجها، ولا نكتب «نتيجتان صحيحتان» اعتمادًا على العدد وحده. لو انعكس ترتيب عرضنا، احتجنا إلى تحديث الربط معه.
هذه المخرجات صحيحة حسابيًا للآلة الافتراضية. لم نحدد هدفًا واقعيًا أو إجابات مرجعية لقياس جودة نموذج. نجاح قراءة الطلب واستيفائه للعقد لا يحول كل تنبؤ لاحق إلى حقيقة.
عند مراجعة واجهة فعلية، اقرأ عقد المدخل والمخرج الخاص بها، واحفظ مثالًا يبين الأسماء والأنواع وعلاقة النتائج بالسجلات. الرسم يلخص الطريق من الحقول إلى الحساب اليدوي؛ لا يمثل استدعاء REST أو تجربة TensorFlow Serving.
المصادر ومتابعة القراءة
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.