كيف تعتمد تجربة ذكاء اصطناعي؟ حالات الاختبار وأنواع الفشل وقرار الإطلاق

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

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

عرّف المخرج المقبول قبل الاطلاع على النتائج

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

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

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

ابنِ مجموعة اختبار لها تفسير ومالك

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

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

مثال افتراضي: تصنيف مستندات واردة للمراجعة

لنفترض مجموعة تعليمية من 60 مستندًا مصرحًا به: 30 حالة واضحة، و12 ملتبسة، و10 ناقصة النص، و8 خارج المهمة. هذا تركيب افتراضي لتوضيح التصميم، وليس عينة كافية بالضرورة أو معيار دقة أو نتائج حققها LAB. يضع مراجع مجال مناسب قواعد الحكم قبل التشغيل، بما فيها الحالات التي يجب أن تعود إلى شخص بدل اختيار فئة.

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

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

افصل أنواع الفشل عن متوسط واحد

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

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

اختبر عبء المراجعة في سير العمل نفسه

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

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

ورقة قرار القبول

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

أسئلة شائعة

كم حالة نحتاج؟

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

هل نكتفي بنسبة الدقة؟

لا إذا كانت تخفي أنواع أخطاء مختلفة أو عبء مراجعة مرتفعًا. اعرض الحالات المهمة وأسبابها، ولا تستبدل الحكم المهني بمتوسط واحد.

هل يكفي أن يراجع المطور النتائج؟

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

ماذا نرسل لبحث تقييم التجربة؟

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

مرجع

NIST AI RMF Playbook: Measure، تمت مراجعته في 26 أكتوبر 2026. مجموعة المثال خيالية وليست اختبار أداء أو معيار نجاح.