عن المؤسس4 أكتوبر 20264 دقائق قراءة

تقييم مخرجات الذكاء الاصطناعي Evals مع عبدالله عبدالرحيم بن سنكر

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

عبدالله عبدالرحيم بن سنكر — تقييم الذكاء الاصطناعي
AZHAL

تقييم الذكاء الاصطناعي

عبدالله عبدالرحيم بن سنكر

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

ليش التجربة اليدوية تكذب عليك؟

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

من وين تجيب الحالات؟

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

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

ابدأ بخمسين حالة مدروسة أحسن من خمسمية عشوائية. المجموعة تكبر مع الوقت، والأهم إنها تمثّل الواقع.

كيف تحكم على الجواب؟

لكل حالة لازم تحدد وش يعتبر نجاح. وهنا ثلاث طرق، من الأرخص للأغلى. الأولى فحص بالكود: لو الجواب المطلوب محدد، مثل تصنيف الرسالة إلى «شكوى» أو «استفسار»، أو رقم طلب، أو صيغة JSON صالحة، فالكود يحكم بدقة وبلا تكلفة. استخدمها كل ما قدرت.

الثانية نموذج مقيّم: لما يكون الجواب نصاً حراً، تعطي نموذجاً ثانياً الحالة والرد ومعياراً مكتوباً، ويحكم. السر في المعيار: «هل الرد جيد؟» سؤال سيئ يطلع أحكاماً عشوائية. الأفضل أسئلة محددة بنعم أو لا: «هل ذكر الرد مدة الاسترجاع الصحيحة؟ هل طلب رقم الطلب قبل ما يعد بشي؟ هل الرد بالعربي؟». وكل فترة، راجع عينة من أحكام المقيّم بنفسك وتأكد إنه يتفق معك.

الثالثة مراجعة بشرية: أغلى طريقة وأبطأها، بس لا غنى عنها في البداية لضبط المعيار، وفي الحالات الحساسة. الحكم البشري هو المرجع اللي تقيس عليه دقة المقيّم الآلي.

شكل الحالة الواحدة

عشان يكون الكلام ملموساً، هذي حالة من مجموعة تقييم لبوت متجر. المدخل: «طلبت عباية مقاسها غلط وابي ارجعها، كم يوم عندي؟». المتوقع: الرد يذكر مدة الاسترجاع المكتوبة في سياسة المتجر، ويطلب رقم الطلب، وما يعد باسترجاع المبلغ قبل ما يتحقق. طريقة الحكم: فحص بالكود إن الرد فيه رقم المدة الصحيح، ثم نموذج مقيّم يجاوب بنعم أو لا على سؤالين: هل طلب رقم الطلب؟ وهل تجنّب الوعد بالاسترجاع؟

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

اقرأ الفشل بعينك

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

قواعد تحفظ نزاهة القياس

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

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

عندك فكرة؟ الاستشارة الأولى علينا

كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.

مقالات ذات صلة

كل المقالات
عبدالله بن سنكر — البيانات المنظمة
AZHAL

البيانات المنظمة

عبدالله بن سنكر

4 أكتوبر 20264 دقائق قراءة

عبدالله بن سنكر: البيانات المنظّمة Schema هي اللغة اللي يفهمها قوقل

عبدالله بن سنكر يشرح البيانات المنظّمة Schema كلغة لها مفردات وصفات وضمائر: الأنواع والخصائص وربط الكيانات بـ @id و sameAs، مع أمثلة لأنواع يستخدمها موقع أزهل فعلاً.

اقرأ المقال
عبدالله عبدالرحيم بن سنكر — هوية العلامة التجارية
AZHAL

هوية العلامة التجارية

عبدالله عبدالرحيم بن سنكر

3 أكتوبر 20264 دقائق قراءة

عبدالله عبدالرحيم بن سنكر: ٧ أخطاء تشتّت هوية علامتك في الإعلانات

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

اقرأ المقال
عبدالله عبدالرحيم سنكر — ربط بوابة دفع
AZHAL

ربط بوابة دفع

عبدالله عبدالرحيم سنكر

4 أكتوبر 20265 دقائق قراءة

رحلة الدفع خطوة بخطوة: عبدالله عبدالرحيم سنكر يشرح ربط مدى و Apple Pay

عبدالله عبدالرحيم سنكر يشرح رحلة الدفع في التطبيقات السعودية خطوة بخطوة: مدى و Apple Pay وبوابة الدفع، والتحقق 3-D Secure، والـ webhook، والاسترداد والفاتورة.

اقرأ المقال