قرار الإطلاق يحتاج تحليلًا للنتائج والإخفاقات الحرجة ونقص الأدلة وسلطة قبول المخاطر وشروط إعادة الاختبار.
دليل تقييم نتائج اختبارات LLM واتخاذ قرار Go / Conditional Go / No-Go
مرحلة Assess ليست مجرد قراءة رسم بياني وتقرير نجاح. إنها اختبار صلاحية الأدلة بالنسبة إلى قرار تشغيل محدد وما بقي من الخطر، ثم تسجيل سلطة قبول النتائج وشروط إعادة الاختبار. مصدر الفكرة هو الإرشادات الطوعية الصادرة عن IMDA لاختبار تطبيقات LLM وفق Identify وTest وAssess؛ أما قالب القرار وأمثلة التشغيل والحوكمة التفصيلية هنا فهي تطوير من سيادة.
1. افصل قراءة النتائج عن قرار الإطلاق
نتيجة Benchmark ليست قرارًا إداريًا تلقائيًا. يبدأ Assess بمراجعة صلاحية الاختبارات نفسها: هل غطت الاستخدام الفعلي واللغات والصلاحيات والمخاطر الحرجة؟ وهل المعايير والعتبات محددة قبل التشغيل؟ وإذا تغير النظام بين الاختبار والقرار فلا يحق نقل النتيجة إلى الإصدار الجديد دون مراجعة الأثر. تحفظ طبقة الحكم نتائج الاختبار كما هي ولا تسمح لملاحظات صاحب المنتج بتعديل سجل التنفيذ الخام. يمكن أن يساعد التلخيص التنفيذي في قراءة النتائج لكن لا يحل محل الأدلة.
حقل اعتماد مطلوب: Assessment Scope.
2. التثبت من المقامات والثقة
افحص عدد الحالات المستقلة وطبيعة تكرارها وتوزيعها بين فئات المخاطر قبل مقارنة النسب. إذا نجح النظام في 98 حالة من 100، فهل الحالتان الفاشلتان من فئة مالية حرجة؟ وهل الحالات المئة من نوع واحد بسيط؟ لا ينبغي أن تخفي النسبة الكلية توزيع الفشل، كما لا ينبغي تفسير غياب الفشل في عينة صغيرة على أنه إثبات لسلامة كاملة. يمكن استخدام confidence intervals حيث يصلح ذلك، مع توضيح افتراض استقلال الحالات وتكوين العينة. إذا كانت النتائج مستمدة من تقييم آلي يجب التحقق من دقة المقيّم على عينة بشرية مستقلة.
حقل اعتماد مطلوب: Statistical Confidence.
3. مراجعة الأخطاء الحرجة لا متوسط الأداء
أنشئ فئة محددة من critical findings التي تمنع Go حتى لو ارتفع المتوسط العام. مثال توضيحي: كشف بيانات مستند لمستخدم غير مخول، أو إرسال فعلي إلى وجهة خارجية، أو توصية مؤثرة مبنية على نص قانوني مختلق مع غياب مراجعة لاحقة. في المقابل ينبغي ألا تحول كل خطأ تحريري إلى حالة توقف حرجة. تعتمد severity على الأثر الحقيقي وإمكان اكتشاف الفشل قبل تنفيذه. يسجل لكل finding الدليل والنسخة والأثر والجهة المالكة، ويمنع إغلاقه بمجرد تعليق «تمت المعالجة» دون إعادة اختبار مثبتة.
حقل اعتماد مطلوب: Critical Findings.
4. تجزئة نطاق القرار
قد يكون التطبيق صالحًا لخدمة داخلية محدودة وغير صالح لاتخاذ قرارات خارجية أو استخدام أداة تنفيذ. يمكن إصدار حكم مختلف لكل capability ضمن إصدار واحد: السماح بالبحث والملخصات، مع تعطيل الاستدعاء الخارجي أو قرارات التصنيف التلقائي. تصنيف Go لا يعني أن كل ميزة اجتازت كل اختبار، بل يجب أن يحمل scope معرّفًا يشمل المستخدمين والبيانات والأفعال واللغات. إذا لم يكن نطاق القرار ممثلًا في بنية النشر الفعلية فلا معنى لكتابة شرط إداري لا يستطيع الفريق إنفاذه تقنيًا.
حقل اعتماد مطلوب: Release Capability Boundary.
5. الفرق بين فشل الاختبار ونقص الأدلة
قد يفشل النظام لأن سلوكه خالف معيارًا واضحًا، وقد يعجز الفريق عن التقييم لأنه لا يملك logs أو مجموعة مناسبة أو أدوات إعادة تشغيل. النتيجتان مختلفتان: الأولى Fail أو No-Go بحسب الخطر، والثانية Insufficient Evidence. لا يجوز حساب الحالة غير المختبرة كنجاح، ولا اعتبارها فشلًا مؤكدًا دون دليل. تسجل الفجوات ويُحدَّد ما إذا كان النطاق يسمح باستمرار جزئي تحت قيود أم يتعين تعليق الإطلاق. يساعد هذا الفصل المؤسسة على مواجهة uncertainty بدل تجميلها.
حقل اعتماد مطلوب: Evidence Sufficiency.
6. تصنيف القرارات الأربعة
يمكن أن تستخدم سيادة صياغة تشغيلية Go وConditional Go وNo-Go وInsufficient Evidence. هذا تصنيف تحليلي مقترح وليس نظام درجات رسميًا تفرضه IMDA. Go يعني استيفاء معايير النطاق المعلن مع بقاء مخاطر متبقية مقبولة. Conditional Go يحدد قيودًا قابلة للإنفاذ وتاريخ انتهاء ومسؤول متابعة. No-Go يعني وجود إخفاق مانع أو خطر غير مقبول في نطاق الاستخدام. Insufficient Evidence يعني أن الأدلة لا تكفي لإصدار حكم، ولو لم ترصد مخالفة مؤكدة. يجب ألا تتحول Condition إلى ثغرة تسمح بالتشغيل غير المحدود سنوات.
حقل اعتماد مطلوب: Decision Outcome.
7. شروط الإطلاق المشروط
تكتب كل condition بوصف قابل للاختبار: تعطيل إجراء إرسال البيانات، قصر الاستخدام على مجموعة أشخاص، فرض مراجعة بشرية على توصيات مالية، حد للمعاملات أو القنوات، أو تفعيل سجل قرار مع آلية إيقاف. لكل شرط جهة تنفذه وجهة تتحقق منه ومدة وجزاء عدم الالتزام. لا يعد «التزام الموظفين بالحذر» شرطًا كافيًا عند وجود صلاحية أداة يستطيع النظام تشغيلها دون موافقة. يجب أن يختبر الفريق التقني أن الضابط يقيد السلوك بالفعل، ثم يربط دليل ذلك بمحضر القرار.
حقل اعتماد مطلوب: Conditions Register.
8. تعيين سلطة قبول المخاطر
لا ينبغي أن يكون مطور prompt هو المالك الوحيد لقرار إطلاق نظام قد يضر مستخدمين أو بيانات. توزع الأدوار بين المنتج، والمخاطر، والأمن، والخصوصية، والتدقيق أو المراجعة المستقلة بحسب الحاجة، وصاحب العملية الذي يملك أثر الاستخدام. تعني الموافقة على إطلاق النطاق أن سلطة معينة راجعت أدلة محددة؛ لا تعني أن كل مسؤول يتبنى سلامة النموذج في جميع الظروف. توثق المبررات والاعتراضات ومَن يملك توقيف النظام وتاريخ مراجعة القرار، ولا تُلغى المعارضة المهنية لمجرد أنها غير مريحة للجدول الزمني.
حقل اعتماد مطلوب: Decision Authority.
9. سلسلة دليل قابلة لإعادة البناء
ينبغي أن يمكن الانتقال من Risk ID إلى Test Case إلى Raw Result إلى Finding إلى Mitigation إلى Retest إلى Release Decision. هذا هو جوهر assurance أكثر من كثرة اللوحات. يثبت الرابط نسخة نموذج ومصادر RAG وتصنيف بيانات وبيئة اختبار. إذا تغير artifact يجب أن يبقى التاريخ محفوظًا لا يستبدل بصمت. ويمكن استخدام hash ومرجع محمي للنتائج الحساسة. لا تضع أدلة عملاء أو أسرارًا في صفحة سيادة العامة؛ تعرض الصفحة المنهج والقالب بينما تحفظ المؤسسة artifacts في مساحة خاصة ذات صلاحيات مناسبة.
حقل اعتماد مطلوب: Evidence Trace.
10. تفسير نتائج التحيز والمحتوى
عند وجود اختلاف في توصيات فئات مستخدمين أو ارتفاع رفض خاطئ للطلبات المشروعة، لا تصدر قرارًا مبنيًا على معدل إجمالي. راجع شرعية المتغيرات، ومقارنة الحالات، وتوزيع العينات، وأحكام المقيّمين، واحتمال تباين لغوي. بعض معايير العدالة تتعارض بحسب طبيعة القرار، لذلك لا يعلن الفريق وجود عدالة كاملة بالاعتماد على score واحد. وفي المحتوى غير المرغوب تتطلب الحالات المتداخلة تحكيمًا موثقًا، مع مراجعة تجنب الإفراط في الرفض الذي قد يمنع استخدامًا مشروعًا.
حقل اعتماد مطلوب: Fairness and Refusal Review.
11. تحليل محركات الفشل لا العرض
إذا نتجت هلوسة فافحص مصدرها: وثيقة قديمة، أو استرجاع غير مناسب، أو تجاهل للمقتطف، أو نقص في سياسة الامتناع. وإذا حدث تسرب فافحص tenant isolation وصلاحيات الأدوات والسجلات قبل تعديل الـprompt. كل علاج ينبغي أن يرتبط بسبب يمكن اختباره، وأن يسجل أثره على فئات أخرى. إن نجاح الحالة التي أصلحت وحدها لا يكفي إذا كان العلاج رفع عدد حالات الرفض الخاطئ أو أضعف دقة الاستشهاد. لهذا تحفظ مجموعة regression محجوبة وتعمل بعد أي تغيير جوهري.
حقل اعتماد مطلوب: Root-Cause Remediation.
12. المقارنة بين الإصدارين
عند تحديث التطبيق، لا تقارن إجمالي score جديد بقديم دون مراجعة ما إذا كانت dataset والمعايير والمقامات متطابقة. إذا تغيرت الحالات بسبب اكتشاف خطر جديد فهذه معلومة مفيدة لكنها لا تسمح بتقرير تحسن رقمي زائف. يمكن عرض مجموعتين: stable regression set للمقارنة التاريخية وexpanding risk set لتغطية الضعف الجديد. يجب إظهار ما إذا كانت النتائج متطابقة مع تغيير في نموذج المزود أو سياسة التوجيه أو مصدر البيانات حتى يستطيع القارئ تفسير الفرق.
حقل اعتماد مطلوب: Version Comparison.
13. مراقبة الإنتاج بعد الإطلاق
يجب أن يتضمن قرار النشر مؤشرات توقف، وأحداثًا تعيد تقييم المخاطر، ومسؤولًا يتلقى شكاوى المستخدمين، وآلية للتحقيق في المخرجات المؤثرة. قد تظهر أنماط فشل غير ممثلة في المختبر، أو يغير المورد النموذج دون إشعار كاف. لذلك يتحول Assess إلى حلقة تعلم: حادث أو تغيير → تحديد نطاق أثر → اختبار جديد → تقييم → قرار. لا يجوز تبرير الاستمرار في تشغيل خطر معروف بحجة أن النظام اجتاز اختبارًا عند إصدار سابق.
حقل اعتماد مطلوب: Monitoring Trigger.
14. مثال تطبيقي مقيد
مساعد يقدم لوحدة التأمين ملخصات طلبات تعويض ويقترح المرفقات الناقصة. أثناء الاختبار يظهر خطأ مرتفع في تسمية نسخة مستند سارية، لكن لا يسمح للمساعد بإصدار قرار تعويض أو مراسلة خارجية. قد يكون الإطلاق المشروط ممكنًا فقط لاقتراح المستندات تحت مراجعة بشرية، بشرط ضبط القنوات وعرض روابط الوثائق والتحقق من حداثتها. وإذا ظهرت حالة كشف مستند مؤمن عليه آخر فلا يصح استخدام هذا المثال لتبرير Go لأن الخطر تغير نوعيًا. قرار الإطلاق يحمل نطاق النسخة والضوابط وشروط الإيقاف، لا عبارة «النموذج آمن» مطلقة.
حقل اعتماد مطلوب: Conditional Launch Case.
15. قاعدة مراجعة الوثيقة نفسها
قبل توقيع التقرير يتحقق المراجع من التواريخ والنسخ وتعريف النجاح وتغطية اللغة وحالة الفشل الحرجة وروابط الأدلة وملكية المعالجة وتوافق النطاق مع التشغيل الفعلي. يراجع كذلك ما إذا كانت هناك ادعاءات تتجاوز ما تثبته النتائج. يجب صياغة العبارة «لم نرصد تسربًا في 300 محاولة ضمن بيئة محددة» إذا كان هذا واقع الاختبار، لا «النظام لا يسرب البيانات». وإذا كان فاصل الثقة واسعًا أو فئة نادرة غير ممثلة فيجب عرض ذلك بصورة صريحة ضمن حدود التقرير.
حقل اعتماد مطلوب: Assurance Review Checklist.
16. حدود المرجع الأصلي
يؤسس IMDA Starter Kit لمنهج Identify → Test → Assess ويحذر ضمنيًا من معاملة درجة اختبار واحدة كحل عالمي عبر كل الاستخدامات. أما صياغة القرارات الأربع وسجل السلطة وقيود الإطلاق والأمثلة التأمينية فهي نموذج تشغيلي من سيادة، وليس اعتمادًا أو قانونًا صادرًا من IMDA. يجب أن تبقى هذه الحدود واضحة عند بناء محتوى المنصة وربط المقالات بالأطر حتى يحصل القارئ على معرفة يمكنه استخدامها دون أن ينسبها خطأ إلى الجهة الناشرة.
حقل اعتماد مطلوب: Source Attribution.