مرحلة Identify تبدأ بتثبيت النظام والمستخدمين والبيانات والآثار وصياغة سيناريوهات خطر قابلة للاختبار قبل اختيار الأدوات.
دليل تحديد نطاق اختبارات LLM والمخاطر ذات الأولوية وفق منهج Identify
هذا الدليل يحول أول مراحل IMDA Starter Kit إلى عملية تصميم اختبار داخل المؤسسة: قبل إدخال أي prompts إلى أداة Benchmark يجب تحديد ما الذي نختبره، ولماذا، ولمن، وبأي بيانات، وما الحد الذي يجعل الخطأ غير مقبول. التصميمات التشغيلية والقوالب هنا من سيادة، والمصدر السنغافوري مرجع منهجي طوعي لا ينشئ التزامًا قانونيًا بحد رقمي محدد.
1. بناء سجل الاستخدام قبل المخاطر
أول خطوة في Identify ليست نقل أسماء مخاطر عامة إلى جدول. يجب تحديد المنتج الذي سيستخدمه المستخدم فعليًا: غرضه، من يفتحه، البيانات المتاحة له، المحتوى الذي يستطيع إنتاجه، الإجراءات التي يستطيع اتخاذها، وما يتوقع أن يفعله الإنسان بالمخرجات. الفرق بين مساعد يكتب ملخصًا داخليًا ومساعد يحدد أولوية دفع مستحقات مهم، حتى لو استُخدم النموذج نفسه. يُعطى لكل استخدام معرف ثابت وصاحب أعمال وإصدار مستهدف وحدود تشغيل، ثم يوثق المسار من prompt إلى عرض النتيجة أو تنفيذ فعل.
الدليل المتوقع لهذه الخطوة: Use-Case Register.
2. تحديد الجهات المتأثرة
قد يكون المستخدم المباشر موظفًا لكن الطرف الذي يتحمل أثر الخطأ عميلًا أو موردًا أو متقدمًا لوظيفة أو مواطنًا. لذلك يعدد سجل الاستخدام أصحاب المصلحة المباشرين وغير المباشرين ويحدد الأذى الممكن لكل منهم. في خدمة تقدم ملخصًا لشكوى عميل قد يؤدي حذف قيد استثنائي إلى خسارة حق، رغم أن الموظف يعتقد أنه تلقى ملخصًا جيدًا. كما تُراجع البيئات متعددة الدول واللغات، لأن الاختبار المناسب لقناة داخلية لا يغطي تلقائيًا استخدام خدمة عامة مفتوحة.
الدليل المتوقع لهذه الخطوة: Stakeholder Impact Map.
3. جرد المكونات والاعتماديات
ارسم مسار البيانات والأدوات: النموذج والنسخة، system prompt، RAG، مصادر المعرفة، مصنف المحتوى، المرشحات، واجهة العرض، التخزين، السجلات، واجهات مزودين آخرين، أدوات الوكيل، ونقاط موافقة البشر. لا يكتفي الجرد بأسماء المنتجات؛ يسجل من يتحكم بكل مكون، وأين يحدث التغيير، ومن يستطيع منعه أو اكتشافه. عندما يغير المورد الإصدار خلف API، قد تتغير نتائج الاختبار دون تعديل ظاهر في تطبيق العميل، ولذلك يجب أن يراعي سجل الاعتماديات حدود قدرة المؤسسة على التثبيت أو التتبع.
الدليل المتوقع لهذه الخطوة: Component/Dependency Inventory.
4. صياغة السيناريو بصورة اختبارية
الخطر لا يكتب «الهلوسة» فقط؛ بل «يقدم المساعد مادة تنظيمية من نسخة ملغاة فتُقبل معاملة مخالفة». ولا يكتب «التحيز» فقط؛ بل «يخفض ترتيب طلبين متكافئين بسبب اختلاف الصياغة أو الهوية». بهذه الصياغة يمكن تحديد مدخل الاختبار والمخرج المتوقع والجهة المتضررة ونقطة اكتشاف الخطأ. ينبغي فصل حدث الفشل عن أسبابه والضوابط المقترحة، لأن الخلط يجعل قياس نجاح العلاج غير ممكن. ويمكن أن ينتج خطر واحد عن عدة أسباب: بيانات قديمة أو سوء استرجاع أو تعليمات ملتبسة أو تجاهل حدود الوصول.
الدليل المتوقع لهذه الخطوة: Risk Scenario Narrative.
5. تعيين الشدة والأولوية
تحدد المؤسسة شدة الأثر بناءً على نوع القرار وإمكان عكسه وحجم الضرر والاعتماد البشري على النتيجة، لا على إثارة المثال. قد لا يكون خطأ تنسيقي في نص تسويقي مساويًا لإرسال معلومة تخص عميلًا إلى طرف آخر. وتساعد قابلية الكشف وسرعة انتشار المخرجات في تقييم الأولوية. لا ينبغي إنشاء score دقيق ظاهريًا دون بيانات تدعم الأوزان، ولا ينبغي أن يسمح المتوسط بإخفاء خطر حرج. الأفضل تصنيف مبرر يظهر السيناريو والدليل وعدم اليقين ثم يوجه عمق الاختبار المناسب.
الدليل المتوقع لهذه الخطوة: Severity Rationale.
6. تمييز المخاطر الخمسة من مخاطر مضافة
تتضمن مجموعة IMDA الهلوسة وعدم الدقة، والتحيز في اتخاذ القرار، والمحتوى غير المرغوب، وتسرب البيانات، والتعرض للمطالبات العدائية. هذه نقطة انطلاق وليست جردًا حصريًا لأخطار كل نظام. قد يحتاج التطبيق إلى قياس استمرارية الخدمة، واعتمادية الأدوات، وسلطة الوكيل، وسلامة التكامل أو تغير مورد النموذج حسب النطاق. يجب ربط ما يشتق من دليل IMDA مباشرة بالمصدر، ووضع المخاطر الإضافية بوصفها تحليل سيادة أو متطلبات سياقية أخرى، حتى لا تنسب إلى IMDA ما لم تنص عليه.
الدليل المتوقع لهذه الخطوة: Risk Coverage Matrix.
7. التفريق بين مستوى النموذج والتطبيق
اختبار النموذج مباشرة يمكن أن يكشف خصائص مفيدة، لكنه لا يثبت سيطرة التطبيق على الصلاحيات أو سلامة الاسترجاع أو عدم كشف بيانات tenant أخرى. لذلك يسجل كل سيناريو المستوى المناسب: output end-to-end، component، integration، permission enforcement، أو run-time operation. إذا كان السيناريو يتعلق بسحب مستند من فهرس لا يملك المستخدم حق الوصول إليه، فالمقياس الحاسم قد يكون سجل الاسترجاع لا جودة الجملة الناتجة. يجب أن تظهر هذه العلاقة صراحة في مصفوفة الاختبار بدل اختيار benchmark واحدة لكل مشكلة.
الدليل المتوقع لهذه الخطوة: Testing Layer Map.
8. بناء التغطية المرجعية
تحدد البيانات المطلوبة للاختبار بتوزيع يشمل حالات التشغيل العادية والحدود وحالات قليلة الحدوث عالية الأثر والمحاولات العدائية. وعند وجود لغة عربية أو مستخدمين متعددين يجب أن تمثل مجموعات الاستخدام بطريقة صالحة لا عبر ترجمة نصوص إنجليزية فقط. يوثق الفريق مصدر الحالات ومبرر اختيارها وإصدارها والطرف المصرح له باستخدامها. كما تُنشأ مجموعة محجوبة للتقييم النهائي حتى لا يتعلم فريق التطوير إجاباتها خلال ضبط prompt أو مرشحات النظام.
الدليل المتوقع لهذه الخطوة: Dataset Manifest.
9. تعريف العتبات قبل ظهور النتائج
لكل خطر مقياس أو مجموعة مقاييس، مع تعريف واضح للنجاح والفشل والمقام وحجم العينة وعلاقة النتيجة بقرار الإطلاق. لا يستند الحد إلى «ما حققه النموذج أمس» ثم يسمى baseline آمنًا. يحدد صاحب أعمال ومالك مخاطر الحد في ضوء أثر الفشل والضوابط والتدفقات التشغيلية، ويسجل rationale. يمكن أن توجد حالات توقف غير قابلة للتعويض بأداء مرتفع في حالات أخرى. وإذا كان عدم اليقين كبيرًا أو كانت العينات قليلة فلا توصف النتيجة بأنها إثبات سلامة كامل.
الدليل المتوقع لهذه الخطوة: Threshold Decision Record.
10. الخصوصية في بيئة الاختبار
البيانات التي تجمع لاختبار السلامة قد تكون في حد ذاتها حساسة. يُفضّل استخدام بيانات اصطناعية دقيقة السلوك أو إخفاء الهوية حيثما يكون ذلك مناسبًا، ولا يفترض أن synthetic data تمثل تلقائيًا كل الحالات. تحدد سياسة الاحتفاظ وحق الوصول ووجهة إرسال الاختبارات، خصوصًا عند استخدام APIs خارجية أو نماذج تقيم مخرجات نماذج أخرى. يجب ألا تظهر بيانات مستخدم حقيقي في مستودع Knowledge عام أو في وصف مصطلح على الموقع. قد يحتاج المدقق إلى مرجع محمي يثبت أصل الدليل، لا إلى نسخة منشورة منه.
الدليل المتوقع لهذه الخطوة: Test Data Protection Plan.
11. تسجيل الفجوات لا اختلاق التغطية
إذا لم يستطع فريق الاختبار الوصول إلى traces الخاصة بأداة خارجية، فيجب تسجيل هذا القيد وفحص ما يمكن إثباته من output ومن event logs المتاحة. وإذا لم تتوفر أمثلة عربية لفئة نادرة أو لا يوجد خبير تحكيم، لا تملأ الفراغ بعينات عامة ثم تعلن النجاح. تظهر الحدود ضمن Assurance Evidence Gap وتؤثر في قرار القبول، وقد تؤدي إلى Insufficient Evidence. هذه النتيجة ليست فشلًا إداريًا؛ إنها حكم صادق بأن الأدلة الحالية لا تكفي لاستخلاص نتيجة أوسع.
الدليل المتوقع لهذه الخطوة: Coverage Gap Register.
12. رسم مصفوفة السيناريو-اختبار-دليل
ينشأ لكل Scenario سجل يربط Risk ID وApplication Version وDecision Impact وThreat Source وTest Method وExpected Behaviour وMetric وThreshold وDataset وReviewer وEvidence وRemediation وRelease Impact. يمكن إضافة تصنيف شدة ونوع المستخدم واللغة والحق في الوصول. المهم أن تكون العلاقات صريحة، بحيث يستطيع المراجع الانتقال من ادعاء «التحكم في التسرب» إلى حالات استرجاع البيانات وأدلة نتائجها. لا يجوز اعتبار مجرد وجود عمود Evidence دليلاً؛ يجب أن يكون هناك سجل أو مرجع يمكن اختباره.
الدليل المتوقع لهذه الخطوة: Traceability Matrix.
13. مراجعة توافق السياق القطاعي
تُراجع الخطة وفق البيئة القانونية والمؤسسية المستخدمة فيها دون تحويل دليل طوعي إلى إلزام عالمي. لدى القطاع الصحي حدود أشد للأخطاء المؤثرة في سلامة الفرد؛ ولدى الجهات الحكومية واجبات معينة نحو إجراءات عادلة وإتاحة الخدمة؛ وقد يحتاج القطاع المصرفي إلى ضوابط بيانات وتصعيد وموافقة مستقلة. لا نستورد threshold رقمية من جهة أخرى دون التحقق من ملاءمتها. وتُراجع واجبات التسجيل والإخطار وحماية البيانات والاعتماد البشري وفق الأحكام السارية فعلًا على صاحب التطبيق.
الدليل المتوقع لهذه الخطوة: Jurisdiction Applicability Review.
14. إغلاق Identify بقرار جاهزية الاختبار
لا تنقل الحزمة إلى مرحلة Test قبل إغلاق شروط الدخول: نظام محدد الإصدار، وسيناريوهات أثر واضحة، وفئات مستخدمين، وعينات مرجعية، وقياسات وعتبات، وأدوار مسؤولية، وخطة حماية بيانات الاختبار. إذا بقيت فجوات، توثق وتحدد هل يمكن البدء باختبار جزئي مع منع استخدام نتائجه لإقرار الإطلاق. يحتاج صاحب المنتج إلى الاعتماد بأن الفرضيات التشغيلية صحيحة، ومسؤول Assurance إلى الاعتماد بأن التصميم قابل لاستخلاص حكم محدود ومفهوم.
الدليل المتوقع لهذه الخطوة: Testing Readiness Gate.
15. مثال متخصص ونتيجة مهنية
لنفترض مساعدًا يساعد ميناءً على فرز إشعارات دخول الحاويات وإعداد ملخصات موجهة لموظفي الامتثال. تظهر مخاطر متعددة: التباس بين وثائق ملاحية متشابهة، كشف تفاصيل شحنة لجهة غير مصرح بها، قراءة تعليمات داخل ملفات من طرف خارجي، والتحيز ضد صيغ عربية أو أسماء دول ضمن بيانات الشحنة. يبني الفريق لكل خطر سيناريو يفصل نوع المستند وحدود المصدر وصلاحية المستخدم والنتيجة المطلوبة. إذا لم يملك النظام أي أداة تنفيذ مباشر، تختلف شدة سيناريو تعديل سجل الجمارك عما لو كان يستطيع إجراء التعديل فعليًا. والنتيجة المطلوبة ليست علامة 90/100، بل اختبار يمكن الدفاع عن نطاقه وأثره وقيوده.
الدليل المتوقع لهذه الخطوة: Worked Risk Register.