تقنية

كيف نحول مشكلة عملية إلى سؤال واضح لتعلم الآلة؟

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

صياغة مشكلة تعلم الآلة تبدأ بما تريد تحقيقه في العمل، ثم تحدد الناتج الذي سيقدمه النموذج وكيف سيستخدمه النظام. تفرق إرشادات Google بين النتيجة المثالية للمنتج وهدف النموذج، وبين نجاح الخدمة ومقاييس التقييم. لا يكفي طلب «إضافة ذكاء اصطناعي». [1]

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

اكتب النتيجة العملية، وسؤال النموذج، ولحظة التوقع، ودليل النجاح قبل اختيار طريقة التعلم.

  • ميز هدف الخدمة من ناتج النموذج؛ التوقع قد يدخل في قرار ولا يكون القرار كله. [1]
  • حدد المدخلات التي ستكون متاحة في لحظة الاستخدام، ووحدة كل توقع.
  • إذا استخدمت مؤشرا بديلا، فبين ما يقيسه وما لا يثبت عن الهدف الحقيقي. [1]
  • قيم أثر الحل على الخدمة إلى جانب جودة التوقع، ووثق حدود البيانات والمعنى. [1] [2]

ما النتيجة التي نريدها فعلا؟

تخيل خدمة افتراضية لإعارة معدات لمركز أنشطة. تريد تقليل تعارض الحجوزات ومساعدة الموظف على تجهيز المعدات في الوقت المناسب. هذا هدف عمل. أما سؤال نموذج ممكن فهو: «كم جهازا من كل نوع سنحتاج غدا؟». ليس التوقع نفسه جدول الحجز ولا إجراء تسليم جهاز.

توضح Google أن التطبيق قد يتخذ قرارا استنادا إلى التوقع، وأن ناتج النموذج قد يختلف عن ناتج التطبيق. [1] اكتب كيف سيستخدم الموظف العدد المتوقع وما الذي سيفعله عند غياب معلومات كافية. بهذه الخطوة نحدد موقع التنبؤ داخل الخدمة قبل الانشغال باسم النموذج.

ماذا نعرف عند طلب التوقع؟

في المثال، حدد وقت التشغيل: نهاية يوم العمل لتجهيز اليوم التالي. ربما تتوفر حجوزات مؤكدة وجدول أنشطة معلن. أما عدد الأجهزة التي تسلمت فعليا غدا فلا يتوفر في هذه اللحظة. لا تخلط قياس النتيجة اللاحق بمعلومة يستطيع النظام استخدامها قبل حدوثها.

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

هل القياس المتاح يساوي الهدف؟

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

تحذر Google من التسميات البديلة التي لا تقيس النتيجة المرغوبة مباشرة. [1] وتحث إرشادات جودة البيانات على تعريف ما يقاس بدقة وفهم القياس البديل. [2] اكتب بجوار العمود «محاولات حجز» إذا كان هذا ما سجل فعلا. تسمية المؤشر «احتياج» لن تمنحه معنى لم تجمعه البيانات.

كيف نحدد دليلا مفيدا على النجاح؟

تميّز Google بين مقاييس نجاح المنتج ومقاييس تقييم النموذج؛ تحسن التقييم لا يضمن الاقتراب من النتيجة العملية. [1]

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

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

  1. Google: وضع إطار لمشكلة تعلم الآلة (يفتح في نافذة جديدة)developers.google.com
  2. Google for Developers: Data quality and interpretation (يفتح في نافذة جديدة)developers.google.com

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