عند توصيف ميزة تحتوي مكوّنًا ذكيًا، يتوقّف معيار القبول عن كونه “بمعطى X تُعيد المنظومة Y”. يصبح معيار القبول تقييمًا (eval): مجموعة بيانات موسومة، ودالّة تسجيل نقاط، وعتبة يجب أن تتجاوزها المنظومة قبل الإطلاق وفي كل مرة من جديد بعد أي تبديل نموذج أو تعديل موجّه. القاعدة البسيطة: إن تعذّرت كتابة التقييم، فالميزة لم تُوصَّف بعد. يفصّل هذا المقال المكوّنات الأربعة لمعيار القبول الاحتمالي وكيفية كتابتها عمليًا.
ما الذي ينكسر تحديدًا في وثيقة التوصيف التقليدية
يستند التوصيف الكلاسيكي إلى افتراض واحد: المدخل نفسه يُنتج المخرج نفسه دائمًا. وكامل بنية الاختبارات والتعريفات وشروط الإنهاء مشتقّ منه. وما إن يصبح أحد مكوّنات المنظومة نموذجًا لغويًا حتى ينهار الافتراض، وتنهار معه كل الأدوات التي اتّكأت عليه.
أوضح تجلٍّ لذلك هو اختبار القبول. “يضغط المستخدم إرسال فيتلقّى ملخّصًا للبلاغ” ليست متطلّبًا قابلًا للاختبار، لأنه لا توجد إجابة صحيحة وحيدة. ملخّصان مختلفان قد يكونان ممتازين كلاهما، وثالث يبدو مشابهًا قد يكون خاطئًا تمامًا. المطلوب هو تعريف نطاق سلوك مقبول لا نتيجة وحيدة.
الاختبار الذي يوفّر شهور تطوير: قبل كتابة سطر برمجي، حاولوا صياغة التقييم. إن لم تنجحوا في تعريف ما يُعدّ إجابة جيدة وكيف تُقاس، فالمتطلّب ما زال ضبابيًا. الميزات التي تتعثّر في مرحلة التجريب تفشل غالبًا في هذه المرحلة، لا في مرحلة التنفيذ.
المكوّنات الأربعة لمعيار قبول ميزة ذكية
| المكوّن | ماذا يعرّف | مثال |
|---|---|---|
| وصف السلوك | ما يُفترض أن تفعله المنظومة، بصياغة تحتمل التباين | ملخّص بلاغ يتضمّن المشكلة والإجراء المتّخذ والحالة |
| عتبة القياس | حدّ أدنى من النقاط على مجموعة اختبار محفوظة لم تُستخدم في التطوير | 90% من الملخّصات تتضمّن المكوّنات الثلاثة |
| قيد السلامة | ما يُعدّ مخرجًا غير مقبول، بصرف النظر عن النتيجة | لا يتضمّن أي ملخّص رقم هاتف عميل |
| خطّاف بشري | ما يحدث في الحالات التي لا يحلّها النموذج | درجة ثقة منخفضة تُحوّل البلاغ إلى طابور بشري |
الفرق بين المكوّن الثاني والثالث جوهري. العتبة إحصائية وتقبل إخفاقات مفردة. أما القيد فثنائي ولا يقبل أي تجاوز. وبدون هذا الفصل تنشأ حالة تجتاز فيها الميزة الاختبار بنسبة نجاح 92%، بينما يختبئ داخل الـ8% المتبقية تسريب معلومات.
كيف يُبنى التقييم دون فريق بحث
التقييم ليس مشروعًا. في الحالة النموذجية هو ثلاثة أصول صغيرة تُصان عبر الزمن:
مجموعة البيانات. من 50 إلى 150 حالة حقيقية من المنظومة القائمة، بما فيها الحالات المزعجة. من المهم أن تُؤخذ من الميدان لا أن تُختلق، فالحالات المُختلقة مريحة أكثر من اللازم دائمًا. ويُرفق بكل حالة الجواب الذي كان خبير المحتوى سيقدّمه.
دالّة التسجيل. ليست ملزمة بأن تكون معقّدة. يكفي في حالات كثيرة فحص وجود مكوّنات إلزامية، أو المطابقة لبنية محدّدة، أو المقارنة بكلمات مفتاحية. وحين يلزم حكم تقديري يمكن استخدام نموذج كحَكَم، شريطة أخذ عيّنة يدوية من النتائج للتحقّق من أن الحَكَم نفسه لا ينحرف.
العتبة وخطّ الأساس. نقيس مرّة واحدة قبل تغيير أي شيء. فبدون خطّ أساس يستحيل معرفة ما إذا كان تعديل الموجّه قد حسّن أم كسر، ومعظم الفرق تكتشف ذلك متأخرة.
متى يُشغَّل: التقييم ليس فحصًا لمرّة واحدة قبل الإطلاق. يُعاد تشغيله عند كل تبديل نموذج، وكل تحرير موجّه، وكل تغيير في مصدر البيانات الذي يغذّي المنظومة. هذا بالضبط الفرق بين التقييم وحالة الاختبار، ولذلك يُستحسن ربطه بعملية البناء من اليوم الأول.
ستة فصول يجب إضافتها إلى وثيقة التوصيف
| الفصل | ماذا يدخل فيه |
|---|---|
| مواصفة سلوك النموذج | ما يُفترض أن يفعله النموذج، وبأي نبرة، وما هو خارج نطاقه |
| عتبات القبول | المقاييس والنتائج الدنيا، بما في ذلك على أي بيانات تُقاس |
| كتالوج حالات الفشل | قائمة الطرق التي قد تفشل بها الميزة وما يحدث في كل منها |
| قيود السلوك | خطوط حمراء ثنائية: ما يُمنع ظهوره في المخرج إطلاقًا |
| خطّة التقييم | مجموعة البيانات، وطريقة التسجيل، وتواتر التشغيل |
| البيانات والخصوصية | أي معلومات تدخل الموجّه وبأي مستوى تصنيف |
يتّصل الفصل الأخير مباشرة بسياسة التصنيف المؤسسية. وإن لم تكونوا قد حدّدتموها بعد، فنموذج المستويات الأربعة في تصنيف المعلومات هو نقطة البداية، إذ بدونه يعرّف التوصيف قدرة يُمنَع تشغيلها.
كتالوج حالات الفشل: الفصل الأعلى مردودًا
في منظومة حتمية، حالة الفشل خطأ. أما في منظومة ذات مكوّن ذكي فحالة الفشل غالبًا جواب يبدو سليمًا تمامًا وليس صحيحًا. لذلك يجب أن يعدّد الكتالوج الإخفاقات بحسب ما يختبره المستخدم، لا بحسب ما تُبلّغ عنه المنظومة.
- جواب واثق وخاطئ, يستلزم الاستشهاد بالمصدر كي يصبح قابلًا للتحقّق.
- رفض الإجابة على سؤال مشروع, يستلزم مسارًا بديلًا.
- جواب جزئي يُسقط شرطًا جوهريًا.
- الانجراف عبر الزمن, حين يتغيّر مصدر البيانات فيتدهور المخرج دون أن يغيّر أحد سطرًا برمجيًا. وهذا الأخير هو السبب الرئيسي لوجوب تشغيل التقييم دوريًا لا قبل الإطلاق فقط.
ما الذي يفعله هذا بالجدول الزمني والميزانية
الأثر العملي هو تغيّر توزيع الجهد. في التوصيف الكلاسيكي يذهب معظم الوقت إلى تعريف الشاشات والتدفّقات. أما في الميزة الذكية فينتقل جزء كبير من الجهد إلى جمع حالات الاختبار ووسمها، وهذا عمل خبير محتوى لا مطوّر. ويُستحسن تخصيص ميزانية له صراحةً، وإلا انزاح إلى الهامش ووصلنا إلى الإطلاق بلا وسيلة لمعرفة ما إذا كانت المنظومة تعمل.
التغيير الثاني: الميزة لا “تنتهي”. لها تكلفة صيانة ثابتة تشمل تشغيل التقييم وصيانة مجموعة الاختبار. وعند حساب الجدوى، هذه تكلفة يجب أن تدخل نموذج الوحدة مسبقًا لا أن تُكتشف في الربع الثاني.
وإن كانت الميزة تجيب من وثائق المؤسسة، فيجب أن يشمل التوصيف طبقة الاسترجاع أيضًا، فهناك يتحدّد معظم الدقة عمليًا. والتفصيل الكامل في دليل قاعدة المعرفة المؤسسية.
ما هو التقييم (eval) وبم يختلف عن اختبار قبول عادي؟
التقييم مجموعة بيانات موسومة مع دالّة تسجيل وعتبة دنيا. اختبار القبول العادي يفحص مخرجًا واحدًا ويُعيد نجاحًا أو فشلًا، بينما يقيس التقييم توزيع الجودة على عشرات الحالات ويُعاد تشغيله عند كل تغيير في النموذج أو الموجّه أو مصدر البيانات.
كم حالة اختبار يلزم للبدء؟
من 50 إلى 150 حالة حقيقية من المنظومة القائمة تكفي لمعظم الميزات. المهم أن تُجمع من الميدان لا أن تُختلق، وأن تشمل الحالات الصعبة لا المريحة فقط.
كيف يُكتب معيار قبول لمخرج بلا إجابة صحيحة وحيدة؟
تُعرَّف أربعة مكوّنات: وصف سلوك يحتمل التباين، وعتبة قياس على مجموعة اختبار محفوظة، وقيد سلامة ثنائي لا يقبل أي تجاوز، ومسار تحويل إلى إنسان للحالات التي لا يحلّها النموذج.
لماذا يجب الفصل بين عتبة القياس وقيد السلامة؟
لأن العتبة إحصائية وتقبل نسبة إخفاق معيّنة، بينما القيد ثنائي. وبدون الفصل قد تجتاز ميزة الاختبار بنتيجة عالية بينما يختبئ داخل نسبة الإخفاق تجاوز خطير مثل كشف معلومات شخصية.
هل يمكن استخدام نموذج كحَكَم يسجّل نقاط المخرج؟
نعم، وهي طريقة معتمدة حين يلزم حكم تقديري. الشرط هو أخذ عيّنة يدوية من النتائج ومقارنتها بحكم بشري، للتأكد من أن الحَكَم نفسه لا ينحرف مع الوقت.