تقييم مخرجات نموذج اللغة قبل الإطلاق

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

السبب أنك تختبر يدويًا. والاختبار اليدوي يقيس انطباعك في تلك اللحظة، لا سلوك النظام.

ما معنى تقييم النماذج؟

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

بدونها كل تعديل في التعليمات هو نشر بلا اختبارات، وأول من يكتشف التراجع هو المستخدم.

ما الذي يُقاس فعلًا؟

الصفّان الأولان يغطّيان أكثر مما يتوقّع الناس. ابدأ بهما قبل أي شيء أعقد.

من أين تأتي الأمثلة؟

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

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

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

كيف تعرف أن التعديل حسّن الأمور؟

بأربع خطوات فقط:

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

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

ما الذي يجب تسجيله في الإنتاج؟

التعليمات كاملة كما أُرسلت، ورقم إصدارها، واسم النموذج وإصداره، وعدد الرموز، والزمن، والنتيجة. بدون رقم إصدار التعليمات لا يمكنك ربط تراجع بتغيير، وهذا أكثر ما يُنسى.

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

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

متى تتوقّف؟

حين تصير الأمثلة الفاشلة حالات نادرة تقبل بها صراحة، لا حين تصل إلى 100٪. النسبة الكاملة على مجموعة صغيرة تعني غالبًا أن المجموعة سهلة لا أن النظام جيد.

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

ما الذي يفشل عمليًا؟

قائمة قصيرة تغطّي أغلب ما يظهر في الإنتاج:

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

البند الأخير هو سبب تثبيت إصدار النموذج وتشغيل المجموعة عند كل تغيير في التثبيت.

كيف تبني المجموعة الأولى؟

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

ما الفرق بين التقييم والمراقبة؟

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

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

قبل الإطلاق بيوم

ثلاثة أسئلة تُجاب بنعم أو لا:

• هل تعرف نسبة النجاح على مجموعة ثابتة، لا على انطباع؟
• هل تعرف ماذا يحدث حين يخطئ النظام، ومن يدفع ثمن الخطأ؟
• هل تستطيع ربط أي تراجع مستقبلي بتغيير بعينه؟

إن كانت إجابة أيّ منها "لا"، فما ينقصك ليس نموذجًا أفضل بل مجموعة تقييم أصغر مما تظنّ وأسرع في البناء مما تتوقّع.

ما هي مجموعة التقييم؟

مجموعة التقييم هي عدد ثابت من الأمثلة مع معيار قبول لكل واحد منها، تُشغَّل كاملة بعد أي تغيير. حجمها أقلّ أهمية من ثباتها: مجموعة من عشرين مثالًا تُشغَّل في كل مرة أنفع من مئتين تُشغَّل مرّة واحدة عند البناء.

وثلاث خصائص تجعل مجموعة التقييم مفيدة فعلًا:

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

متى تكفي مجموعة التقييم وحدها؟

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

هذا هو السؤال الذي يستحقّ أن يُطرح قبل الإطلاق بيوم واحد، وقبل أي نقاش عن النموذج أو التعليمات.

من يملك مجموعة التقييم؟

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

المسؤوليات الثلاث التي تُسنَد صراحة:

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

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

ماذا تقيس بعد الإطلاق؟

بعد أن يعمل تقييم النماذج قبل الإطلاق، تبقى ثلاثة أرقام تُتابَع أسبوعيًا وتكشف التراجع قبل أن يشتكي أحد:

• نسبة إعادة التوليد: المستخدم يطلب إجابة أخرى. أسرع مؤشّر على تراجع الجودة.
• نسبة التعديل قبل الاستخدام: كم يغيّر المستخدم في المخرج قبل أن يقبله.
• نسبة الرفض الصامت: طلب لم يُستخدَم مخرجه إطلاقًا.

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

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