خطة الاختبار الجيدة تربط سيناريوهات الخطر بالبيانات والمقاييس وحدود القبول والأدلة وأصحاب القرار، ولا تكتفي بدرجة نجاح إجمالية.
دليل بناء خطة اختبار السلامة والاعتمادية لتطبيقات LLM قبل الإنتاج
هذا دليل تشغيلي من سيادة يعتمد على فلسفة Identify → Test → Assess المستخدمة في Starter Kit الصادر عن IMDA، ويترجمها إلى سجل تخطيط وقياس وأدلة وقرارات يمكن للمؤسسة تطبيقه. لا يفترض الدليل أن IMDA منحت اعتمادًا للتطبيق، أو أن معايير قبول منشورة هنا إلزامية قانونيًا. اختلاف سياقات الاستخدام يجعل خطة الاختبار الفعلية مرتبطة بالأعمال والقطاع والبيانات والسلطة التنفيذية الممنوحة للتطبيق.
1. تحديد نطاق الاختبار
تبدأ خطة الاختبار من تعريف حالة الاستخدام وحدود نظام التشغيل لا من شراء أداة قياس. يحدد الفريق المستخدمين المقصودين، والقرارات المدعومة، والبيانات التي تمر عبر التطبيق، ومزودي النماذج، ونسخ الـprompts، ومستودعات RAG، والموصلات، والأدوات التنفيذية. يسجل كذلك ما لا يشمله الاختبار: لغات غير مدعومة، وفئات مستخدمين لم تمثلها العينات، وعمليات تتطلب اعتمادًا بشريًا خارج النظام. ينبغي أن يكون system-under-test إصدارًا محددًا قابلاً لإعادة البناء. لا يجوز نقل نتيجة نموذج منفرد إلى تطبيق مدمج مع أدوات مختلفة ثم وصف التطبيق بأنه اجتاز الاختبار. المخرج المطلوب هنا Scope Record مؤرخ يوقع عليه مالك المنتج ومسؤول المخاطر.
المخرج المطلوب من هذه المرحلة: سجل نطاق النسخة وحدود النظام.
2. خريطة سيناريوهات الخطر
تحول الخطة هدفًا عامًا مثل «منع تسرب المعلومات» إلى سيناريوهات يمكن اختبارها: مستخدم بلا تفويض يطلب معلومات ملف آخر؛ مستند خارجي يحتوي تعليمات تحاول تعطيل سياسات النظام؛ نموذج يقدم معلومة قانونية غير سارية؛ أو خدمة تعيد مخرجات متحيزة في إجراء مفاضلة. لكل سيناريو سجل يصف مصدر المدخل، قدرة الفاعل، نقطة عبور الثقة، المعلومة أو الإجراء المستهدف، النتيجة المتوقعة، الآثار المحتملة، وسائل الكشف، والجهة المالكة. لا ينبغي اعتبار خمسة محاور IMDA حصرًا لكل مخاطر المؤسسة؛ إنها مجموعة موضوعات اختبار أساسية، بينما قد يضيف سياق استخدام الأدوات والاستقلالية والقرار والموردين مخاطر تشغيلية أخرى.
المخرج المطلوب من هذه المرحلة: سجل سيناريوهات المخاطر وتبعاتها.
3. مصادر بيانات الاختبار
تحتاج الاختبارات إلى corpus موثقة المنشأ ونسخة مرجعية صالحة. تستخدم حالات طبيعية مأخوذة من عمليات عمل بعد إخفاء الهوية إن كانت البيانات حساسة، وحالات حدودية يضعها خبراء المجال، وحالات عدائية مضبوطة، وحالات غياب الدليل أو تضارب المصادر. من الخطأ الاكتفاء بأسئلة شائعة من الإنترنت لأنها قد لا تمثل اللهجات العربية أو نماذج العقود أو حدود المعلومات في المؤسسة. يسجل كل test case معرفًا، ومدخلًا، وسياقًا، والمصدر المرجعي، والإجابة المتوقعة أو معايير الحكم، وشدة الخطر، واللغة، وحقول البيانات المصطنعة أو الحقيقية، وحقوق استخدامها في الاختبار. يجب أن تختلف مجموعة المعايرة عن مجموعة الحكم النهائي.
المخرج المطلوب من هذه المرحلة: مصفوفة بيانات وحقوق استخدام.
4. مصفوفة القياسات وحدود القبول
يعرّف لكل خطر مقياس مستقل مع numerator وdenominator ومبرر قابلية استخدامه. في الدقة نفحص ادعاءات يمكن التحقق منها، واكتمال الجواب، ودعم الاستشهاد؛ وفي التحيز نفحص تغير المخرجات عبر مقارنات مناسبة سياقيًا؛ وفي التسرب نفحص استخراج معلومات لا يحق للطرف الوصول إليها؛ وفي adversarial testing نفصل نجاح التلاعب بالنص عن تنفيذ إجراء فعلي. عتبات القبول تعتمد على أثر الفشل وسياق القرار، ولا ينبغي وضعها بعد مشاهدة النتيجة. يمكن أن توجد شروط توقف حرجة غير قابلة للتعويض بمعدل إجمالي ممتاز. تسجل الخطة مؤشرات عدم اليقين وعدد المحاولات وطريقة تكرار الاختبار، بحيث لا تتحول نتيجة صغيرة العينة إلى ادعاء واسع.
المخرج المطلوب من هذه المرحلة: سجل مقاييس مع حدود مسبقة.
5. اختبار المخرجات والمكونات
تشمل الخطة مرحلتين متكاملتين: اختبار السلوك الظاهر للمستخدم، واختبار المكونات التي تنتج السلوك. الأولى تسجل السؤال والمخرجات والرفض والاستشهاد والعمل المرئي؛ الثانية تفحص صلاحية الاسترجاع، اختيار الوثائق السارية، تقييم الوصول، توجيه الأداة، حماية المدخلات، والمراقبة التنفيذية. قد تكون الإجابة صحيحة بينما جلب RAG وثيقة لا تخص المستخدم؛ لذلك لا تعد جودة النص وحدها نجاحًا للمنظومة. ينبغي أن تحدد الخطة الأدلة التقنية التي يجب الاحتفاظ بها مع مراعاة الخصوصية، مثل trace معرف غير حساس بدل نسخ الوثائق الأصلية في تقرير منشور.
المخرج المطلوب من هذه المرحلة: نتائج اختبار مخرجات ومكونات منفصلة.
6. منهج الاختبار العدائي
يُحَدَّد نموذج تهديد واقعي بدل إطلاق مطالبات هجومية عشوائية. من يملك كتابة المستندات أو صفحات الويب أو محتوى رسائل البريد؟ ما الامتيازات التي قد يرثها الوكيل عند قراءة ذلك المحتوى؟ هل يُسمح له بالإرسال أو تغيير السجلات أو الاستدعاء الخارجي؟ ثم تكتب حالات تستخدم تلك الأسطح لتحريض النظام على تجاوز الحدود. تسجل التقنية المستخدمة والهدف والحد المتوقع للفصل بين البيانات والأوامر والنتيجة المرصودة. إن ردّ النظام «سأرسل البيانات» دون تشغيل أداة ليس دليلًا على حصول إرسال فعلي. عند النجاح، يجب توثيق مسار التنفيذ وإثباته في بيئة اختبار مصرح بها؛ وعند الفشل توثيق الضابط الذي منع الانتقال.
المخرج المطلوب من هذه المرحلة: سجل الهجمات ونتائجها الفعلية.
7. قياس الرفض الزائد ونقص الثقة
تحتاج الخطة اختبارات لطلبات مشروعة وآمنة، لأن مرشحًا يرفض كل سؤال قد يبدو خاليًا من المخرجات الضارة لكنه غير صالح للاستخدام. صنّف الرفض إلى رفض أمني مشروع، وامتناع بسبب غياب دليل، وتعطل نظام، ورفض خاطئ، وحلل توزيعه عبر اللغات وفئات الأسئلة. ومن جهة أخرى لا يجوز مكافأة النموذج على إجابات جازمة عندما لا يتوفر مصدر أو توجد نسختان متعارضتان من سياسة. ينبغي أن تتضمن مجموعة التقييم حالات يكون السلوك الصحيح فيها طلب توضيح أو إظهار حدود المعرفة، وحالات يتعين فيها الإجابة من مصدر واضح دون مبالغة في المنع.
المخرج المطلوب من هذه المرحلة: مصفوفة الرفض المشروع والخاطئ.
8. التحكيم البشري واستقلالية المراجعة
حدد أدوارًا مستقلة نسبيًا لإعداد الحالات، وتشغيلها، وتحكيم النتائج، وقبول الخطر. المقيّم الذي صمم prompt يستطيع تفسير نتائجه بطريقة منحازة إذا لم توجد مراجعة. في موضوعات التحيز والمحتوى غير المرغوب يحتاج الفريق تعليمات تقييم موحدة، وحالات تحكيم مزدوجة ووسيلة تصعيد عند الخلاف. يمكن استخدام نموذج لغوي مساعد في وسم النتائج، لكن يجب فحص أخطائه هو أيضًا على عينات بشرية. لا يجوز إعلان «تقييم مستقل» إذا كان المراجع يعتمد حصريًا على ملخص الفريق نفسه ولم يطلع على الأدلة أو الحالات الحرجة.
المخرج المطلوب من هذه المرحلة: قرارات تحكيم موثقة.
9. فصل الاستنتاجات عن الأدلة
عند إغلاق التشغيل يوضع لكل finding النص الأصلي للحالة، وإصدار النظام، وقيمة المقياس، والمرجع، وتحليل السبب، وشدة الأثر، والإجراء المقترح، ومالك المعالجة، وحالة إعادة الاختبار. لا تسند إلى IMDA شروطًا رقمية محلية أو تصنيفات قرار من إنشاء المؤسسة. وثيقة IMDA مرجع منهجي للاختبار المرتبط بالسياق؛ أما الأرقام التي تختارها الجهة والتوقيعات وسلسلة القرار فهي سياساتها الخاصة، وتحتاج تسويغًا يختلف حسب القطاع. حالة لم يمكن اختبارها بسبب نقص الوصول أو غياب البيانات لا تُعد Passed، وإنما تُسجل فجوة evidence.
المخرج المطلوب من هذه المرحلة: سجل findings قابل للتتبع.
10. إعادة الاختبار وإدارة الإصدارات
لا ينتهي التخطيط بمجرد الحصول على نتيجة مقبولة. حدد التغييرات التي تفرض إعادة تشغيل الاختبار: تحديث model version، تعديل system prompt، إضافة مصدر RAG حساس، تعديل حق الوصول، تبديل أداة، توسعة فئة المستخدمين، تحديث قاعدة تصنيف، أو ظهور حادث. يجب التمييز بين regression صغيرة تغطي تغييرًا محدودًا واختبار شامل لتغيير في حدود السلطة أو معالجة البيانات. يمكن إضافة فحص دوري، لكن الزمن وحده لا يغطي تغييرات غير مرئية من المزود. يثبت سجل التغيير التباين بين التكوين السابق والحالي، والاختبارات المعادة، والجهة التي أقرت صلاحية القرار الجديد.
المخرج المطلوب من هذه المرحلة: خطة regression مرتبطة بالتغيير.
11. حزمة القرار الإداري
الوثيقة الناتجة يجب أن تمكّن صاحب السلطة من إجابة أسئلة مباشرة: ما الذي اختبرناه؟ ما الذي لم نختبره؟ هل توجد حالات حرجة مفتوحة؟ ما صلاحية البيانات المرجعية؟ ما حجم عدم اليقين؟ هل يمكن اكتشاف الخطأ قبل وقوع أثر؟ من يستطيع وقف النظام؟ وإذا صدر Conditional Go فما القيود ومتى تنتهي؟ يفضل قرار ذو أربع حالات تشغيلية: Go، Conditional Go، No-Go، Insufficient Evidence، مع توضيح أنها صياغة إدارية مقترحة وليست تصنيفًا مفروضًا من المصدر السنغافوري. من دون evidence links وsign-off ونسخة معلومة يصبح قرار الإطلاق شكلًا إداريًا لا ضمانًا قابلًا للتدقيق.
المخرج المطلوب من هذه المرحلة: محضر قرار وشروط محددة.
12. سيناريو تطبيقي للقطاع المصرفي
تصور مساعدًا يولد مسودات ردود على اعتراضات العملاء مستندًا إلى سياسات الحسابات. تُنشأ مجموعة حالات فيها سياسة قديمة ومذكرة تعديل جديدة، وأرقام حسابات افتراضية، ومطالبات من مستخدم بصلاحيات فرع آخر، ورسالة واردة تحتوي أمرًا خفيًا لإرسال ملخص إلى بريد غير مصرح. تُختبر صحة المعلومة وربط الاستشهاد بالسياسة النافذة، وحجب البيانات، وحدود الوصول بين الفروع، وكشف الهجوم، وسلوك الرفض عند غياب الموافقة. لا يكفي نجاح ألف سؤال بسيط إذا ظهرت حالة مؤكدة تسمح بتجاوز الفصل بين الحسابات. يُرفق كل حكم بواقعة الاختبار وأثرها، دون استخدام بيانات زبائن فعلية خارج البيئة المصرح بها.
المخرج المطلوب من هذه المرحلة: حالات اختبار مصرفية تمثيلية.
13. شكل جدول الاختبار وحوكمة التعبئة
تحتوي الخطة أعمدة Application Version؛ Risk ID؛ Scenario؛ User Role؛ Source Trust Level؛ Test Case ID؛ Input Dataset Version؛ Expected Behaviour؛ Metric؛ Acceptance Rule؛ Observed Outcome؛ Severity؛ Evidence Reference؛ Reviewer؛ Remediation Owner؛ Retest Status؛ Release Impact. ولكل حقل تعريف حتى لا يستخدم شخص «PASS» للدلالة على تنفيذ الحالة ويستخدم آخر الكلمة للدلالة على استيفاء الحد. يفضّل فصل raw execution عن adjudicated finding وعن release decision في مستندات أو سجلات تربطها معرفات ثابتة. ويمكن أن تتضمن النسخة المنشورة من المنهج قالبًا فارغًا، بينما تحتفظ المؤسسة بأدلتها الحساسة في مستودعها المحمي.
المخرج المطلوب من هذه المرحلة: قاموس حقول وقالب تنفيذ.
14. بوابة الجودة النهائية
قبل اعتماد الخطة يجب التحقق من وجود صاحب قرار محدد، ومن تغطية اللغات والمخاطر الحرجة، ومن أن كل عتبة موثقة قبل التشغيل، ومن أن المرجع المستخدَم في التقييم صالح للإصدار قيد الاختبار. تراجع عينات مكررة للكشف عن تضارب التحكيم، وتراجع نتائج فشل صفرية للتأكد أنها لا تعكس مجموعة ضيقة، وتختبر آلية الاحتواء والإيقاف بواقعة مسموح بها. إذا تعذر إكمال أي اختبار حرج، لا يُستخدم متوسط باقي المقاييس لتعويضه. فالهدف من الخطة ليس استخراج شهادة نجاح مبكرة، بل تقرير منضبط يمكن للمؤسسة أن تتحمل مسؤوليته.
المخرج المطلوب من هذه المرحلة: مراجعة صلاحية أدلة الإطلاق.
المصادر وحدود النسبة
المصدر الأساس هو IMDA Starter Kit for Testing LLM-Based Applications for Safety and Reliability. التفاصيل التشغيلية والقوالب والأمثلة البنكية المقترحة في هذه المقالة إنتاج تحريري من سيادة وليست نصوصًا رسمية من IMDA. يطبّق أي فريق النموذج بما يتناسب مع المعايير والالتزامات الفعلية التي تخصه.