حد القبول يتبع السياق والخطر ونسخة التطبيق والأدلة المتاحة.
حدود قبول السلامة والاعتمادية لتطبيقات LLM: كيف نبني قرارًا قابلًا للدفاع؟
1. المشكلة ليست اختيار نسبة نجاح جذابة
حين تعرض جهة تطوير لوحة نتائج تظهر نجاح 92% في اختبارات نموذج لغوي كبير، لا تتضح صلاحية التطبيق للإطلاق. لا تخبرنا النسبة من أين جاءت الحالات، ولا طبيعة الفشل في الثمانية بالمئة المتبقية، ولا ما إذا كان الاختبار يطابق اللغة والقطاع والمستخدمين الفعليين، ولا من يملك صلاحية قبول الخطر. قد تكون 92% جيدة في مهمة اقتراح عناوين لبطاقات منتجات غير حساسة، لكنها غير كافية في نظام يصيغ تعليمات صرف دواء أو يحول طلبات المواطنين إلى قرارات استحقاق. لذلك نميّز بين مقياس الأداء، وحد القبول، وسلطة قبول الخطر، ودليل صلاحية الاختبار. ليست هذه مفاهيم مترادفة.
تؤكد مبادرة IMDA في دليلها لاختبار تطبيقات LLM للسلامة والاعتمادية على أن الاختبار مرتبط بالسياق وأن baseline المناسب يتحدد بحسب التطبيق. لا يقدّم ذلك تصريحًا بوجود نسبة معيارية عالمية تضمن السلامة؛ كما لا يصح تحويل التوجيه الطوعي السنغافوري إلى التزام قانوني لدولة أخرى. ومنهج التشغيل المناسب للمؤسسة هو ترجمة سياق الاستخدام إلى فرضيات مخاطر، ثم حالات اختبار، ثم معايير قبول مؤهلة بالأدلة.
2. تعريف الوحدة التي نقيسها
قبل كتابة threshold يجب تثبيت system-under-test. هل نقيم النموذج عبر API منفردًا؟ أم التطبيق الكامل الذي يضم system prompt وواجهة الاسترجاع RAG ومصنف البيانات والمرفقات وقواعد التوجيه والأدوات والموصلات وآليات المراجعة البشرية؟ إذا عدّل الفريق نسخة prompt أو قاعدة الاسترجاع أو النموذج الأساسي بين يومي الاختبار والإطلاق، فقد لا تعود النتيجة صالحة لنفس التركيب. يجب أن تسجل حزمة الاختبار اسم النموذج ونسخته، إعدادات التوليد، شيفرة التطبيق، فهرس المعرفة ولقطة المستندات، سياسة المرشحات، تكوين الأدوات، ونطاق الصلاحيات. كما يجب تحديد اللغات، قنوات التفاعل، المستخدمين، وحجم البيانات المتوقع.
لنأخذ خدمة تلخص مراسلات المشتريات ثم تقترح استبعاد مورد. أداة التلخيص وحدها تبدو منخفضة التأثير، لكن إذا زودت اللجنة بالتوصية بوصفها أساسًا لقرار توريد كبير فهي تنتقل إلى سياق أعلى أثرًا. هنا فشل واحد في نسبة صغيرة من المخرجات قد يلحق ضررًا مهمًا بمورد أو بالمال العام. المعيار إذن ليس «كم مرة كانت الإجابة صحيحة؟» فقط، بل «ما القرارات التي يمكن أن يحركها الخطأ، وكيف يكتشف الإنسان ذلك قبل أن يتحول إلى فعل؟».
3. بناء خريطة المخاطر قبل القياس
ابدأ بسجل تعرضات مختصر لكل رحلة استخدام. لكل خطر نسجل الحدث، السبب المحتمل، الطرف المتأثر، أثر الفشل، قابلية اكتشافه، تعرّض المستخدم له، الضوابط الحالية، والمالك. في تطبيق استعلام داخلي قد تشمل الأخطار هلوسة مرجع سياسة، كشف بند سري بين إدارتين، التحيز تجاه فئة من الموظفين، محتوى غير ملائم، وتحويل نص غير موثوق إلى تعليمات تحكم في الأداة. الفصل مهم، لأن درجات نجاح تصنيف المحتوى لا تثبت السيطرة على تسرب البيانات؛ وكذلك رفض هجوم prompt injection لا يثبت صحة الإجابات الواقعية.
افصل بين الخطر المتأصل قبل الضوابط، والخطر المتبقي بعد تطبيقها. إذا كانت أداة خارجية تستطيع إرسال محتوى العملاء، فغياب هذا الامتياز يختلف نوعيًا عن وجود امتياز واسع مع مرشح نصي يسهل التحايل عليه. سياق الاختبار يتغير بوجود صلاحية فعل حقيقي، لا بمجرد جودة اللغة المنتجة.
4. اشتقاق عتبة قبول متعددة الأبعاد
الحد الذي يمكن الدفاع عنه يتضمن شروطًا حرجة لا يجوز تعويض فشلها بمتوسط مرتفع. مثال تصميمي توضيحي، وليس رقمًا من IMDA: لا يُقبل أي تسرب مؤكد لسر إنتاجي في مجموعة اختبارات هجومية مضبوطة؛ ولا تُطلق ميزة إرسال بريد خارجي إذا نجحت حالة واحدة في تجاوز صلاحيات الإرسال دون تأكيد معتمد. في المقابل يمكن تحديد حد كمي لمعدل الاستشهاد الصحيح بمستندات الاسترجاع، مع فاصل ثقة ونطاق تغطية معلنين، بشرط أن يحترم العمل طبيعة القرار.
من الخطأ جمع كل المقاييس في weighted score واحد دون rationale. قد يحصل نظام على 99% في أسئلة بسيطة و0% في حالات اختراق حرجة ثم تظهر لوحة إجمالية ممتازة. الأفضل لوحة مع شروط قبول مستقلة: حدود حماية البيانات، دقة المعلومات، التحيز، سلامة السلوك تحت الهجوم، حدود الرفض الخاطئ، قدرة الإنسان على التدخل، والاستقرار التشغيلي. ويمكن أن تكون النتيجة Go أو Conditional Go أو No-Go أو Insufficient Evidence، وهي صياغة قرار تشغيلية مقترحة من سيادة، لا نتيجة يفرضها الدليل السنغافوري.
5. اختيار عينات لا تكذب على المؤسسة
العينة العشوائية من الاستخدام اليومي وحدها غير كافية؛ فالحالات عالية الشدة نادرة بطبيعتها. تقسّم مجموعة الاختبارات إلى حالات تشغيل طبيعية، حالات حدودية، حالات إساءة متوقعة، حالات استفزاز عدائي، وحالات تغير بيانات أو سياق. إذا كان المنتج ثنائي اللغة، فلا يصح سحب نتيجة سلامة باللغة الإنجليزية على العربية. ويتطلب الاستخدام المحلي فحصًا للمصطلحات المهنية والأسماء المركبة واللهجات وطرق إدخال المستندات. كما يجب عدم خلط «حالات من تطوير الفريق» مع «حالات محفوظة لا يعرفها الفريق» دون تمييز؛ فقد يرفع ضبط prompt على مجموعة معروفة النتيجة دون تحسن حقيقي عند الإطلاق.
يجب تسجيل منشأ كل حالة، سبب اختيارها، التوقع المحدد، وطريقة احتساب النجاح. إذا تغيرت مجموعة الاختبارات لاحقًا، يحتفظ الفريق بمعرّف إصدار منفصل حتى لا تقارن نتيجتان على مجموعتين مختلفتين وكأنهما قياس واحد. وفي الاختبارات البشرية، توثّق تعليمات المقيّمين وآلية حسم اختلاف الأحكام، لأن «محتوى ضار» أو «تحيز» قد يحتوي مناطق تقدير تختلف باختلاف السياق.
6. المقاييس ومقاماتها
كل نسبة بلا مقام يمكن أن تضلل. «نجحت 190 حالة من 200» لا تقول هل الحالات تمثل كل فئات الاستخدام، ولا كيف توزع الفشل. يجب إظهار numerator وdenominator وتعريف النجاح ونافذة الاختبار. بالنسبة للهلوسة، يمكن قياس صحة ادعاءات محددة والاستشهادات المدعومة مع فصل الإجابات القابلة للتحقق عن الآراء أو حالات عدم توفر الدليل. في كشف التسرب نحتاج معدل نجاح استخراج بيانات لا يحق للمهاجم الوصول إليها، مع توثيق الصلاحية الأصلية والجهة المستهدفة. وفي التحيز، يجب التأكد من قابلية مقارنة المجموعات وعدم اعتبار أي تفاوت مباشر دليلًا تلقائيًا على التمييز.
تزيد الثقة عندما تعرض النتائج فواصل عدم اليقين وتكرر الاختبار على عينات مستقلة. لا يكفي إعلان الفاصل دون بيان الافتراضات: هل الحالات مستقلة فعلًا؟ هل أنتج النموذج ردودًا متعددة من الطلب نفسه؟ وهل التجربة تمثل الاستخدام المتوقع؟ وإذا كان العدد صغيرًا، يجب أن تكون صياغة الثقة متواضعة. فشل الصفر في عشر محاولات لا يثبت استحالة الفشل؛ بل يثبت فقط عدم ملاحظته ضمن عشر محاولات بشروطها.
7. الفصل بين Benchmarks وبين اختبارات المؤسسة
الـbenchmark المشترك مفيد للمقارنة والقياس المرجعي، لكنه لا يجسد بالضرورة محتوى المؤسسة وحدود تفويضها وتدفق مستنداتها أو قراراتها. لذلك نبني طبقتين: اختبارات مرجعية تستخدم منهجًا موثقًا، واختبارات خاصة للتطبيق مشتقة من الأصول والعمليات الفعلية. لا يصح استبدال الأخيرة بالأولى. Project Moonshot مرتبط بمنظومة AI Verify Foundation لاختبار تطبيقات LLM، لكن ذكر الأداة لا يعني أن مشروع سيادة نفذ اختبارًا عليها أو حصل على اعتماد منها. أي نتيجة مستقبلية يجب أن تحمل رابط التشغيل والأدلة وليس مجرد اسم المنصة.
8. لماذا لا يكفي الاختبار على المخرجات؟
Output testing يراقب إجابة المستخدم النهائية وسلوك التطبيق الظاهر. هذه طبقة ضرورية، لكنها قد تخفي عيوبًا داخلية؛ فقد يأتي الجواب صحيحًا رغم استرجاع مستند خطأ لأن النموذج اعتمد على معرفته العامة. Component testing يفصل استرجاع النصوص، اختيار الأداة، التحقق من الصلاحيات، تنقية البيانات، وتنفيذ الإجراء. وعندما تضاف النتيجتان يمكن تحديد ما إذا كان نجاح الرد نتيجة تصميم صحيح أم مجرد مصادفة مفيدة. في نظام يقدم إجابات حول سياسة موارد بشرية، نريد التحقق من أن المستند الذي استرجعه النظام هو النسخة الصحيحة السارية على وحدة الموظف، وليس مجرد نص مشابه متاح لفريق آخر.
9. فشل جسيم واحد مقابل آلاف النجاحات
تعالج سيادة النتائج وفق severity لا المتوسط فقط. إذا استطاعت تعليمات داخل ملف مورد خارجي دفع الوكيل لإرسال بيانات مالية إلى عنوان بريد غير مصرح، فهذه حالة تستدعي احتواء وفحص سلسلة السلطة ولو كانت هناك آلاف المحاولات الناجحة. نسجل: مدخل الهجوم، نقطة عبور الثقة، الفعل المقترح أو المنفذ، نطاق البيانات، سياسة المنع المفترضة، السجل التقني، النتيجة الفعلية، والإجراء التصحيحي. ثم نعزل النسخة المتأثرة ونختبر منع التكرار. لا يجوز تقديم حالة لم تنفذ فعلًا على أنها اختراق ناجح؛ «أوصى النموذج بالفعل» تختلف عن «أرسلت الأداة البيانات».
10. الرفض الزائد ليس دائمًا انتصارًا
قد ترفع حواجز الحماية معدل الرفض فتبدو النتائج آمنة، لكنها تعطل الاستخدام المشروع. في أنظمة الخدمة العامة أو الدعم الطبي غير التشخيصي يجب قياس Over-Refusal: متى رفض التطبيق سؤالًا عاديًا كانت الإجابة عليه مشروعة، وما أثر هذا الرفض على قدرة المستخدم على إنجاز معاملته؟ يجب التفريق بين عدم الإجابة لغياب الدليل، والرفض بسبب سياسة أمان، والخطأ التشغيلي أو عدم توفر النموذج. ولكل نوع treatment مختلف. كما يراجع الفريق ما إذا كانت صياغة أسئلة مجموعات معينة تؤدي إلى رفض أكثر بسبب الاختلاف اللغوي لا بسبب خطر حقيقي.
11. القرار والملكية المؤسسية
ينبغي الفصل بين مالك الاختبار ومالك قرار الإطلاق. الفريق التقني يقدم نتيجة قابلة للتكرار، وممثل المخاطر يراجع حدود التعرض، وأمن المعلومات يتحقق من الصلاحيات والتسرب، والخصوصية تفحص مشروعية المعالجة والاحتفاظ، وصاحب العملية يقرر ما إذا كانت المنفعة والمخاطر المتبقية مقبولتين ضمن حدود السلطة. لا تعني موافقة لجنة ما أن النظام آمن في جميع الظروف؛ إنها قرار مشروط بإصدار معين وقيود تشغيلية واضحة. يجب تسجيل أسماء الأدوار والصلاحيات وحدود الاستثناء والتاريخ والمدة والبيانات التي تأسس عليها الحكم.
12. Conditional Go ليس رخصة مفتوحة
قرار «إطلاق بشروط» يجب أن يحدد الشروط القابلة للقياس قبل السماح بالاستخدام. مثال: إتاحة خدمة أسئلة السياسة لعدد محدود من الموظفين، مع تعطيل الوظائف ذات الأثر المالي، وتوجيه الحالات منخفضة الثقة إلى مراجعة بشرية، وتفعيل سجلات التدقيق، وتحديد نقطة توقف عند رصد نسبة فشل حرجة. يجب توثيق تاريخ انتهاء الاستثناء ومَن يملك إيقاف الخدمة فورًا. إذا كانت الضوابط غير قابلة للتحقق، فالتوصيف المناسب Insufficient Evidence أو No-Go، لا Conditional Go شكلي.
13. حزمة الأدلة المتوقعة
الحد الأدنى المقترح يحتوي ملف نطاق التطبيق، سجل مخاطر معتمد، نسخة سياسة الاختبار، قائمة بيانات الاختبار ومنشئها، manifest لإصدارات المكونات، تعريف المقاييس والحدود، النتائج الخام المسموح حفظها، النتائج المجمعة وفواصل الثقة، تحليلًا للحالات الحرجة، سجل الإجراءات التصحيحية، إثبات إعادة الاختبار، مراجعة مستقلة متناسبة مع الشدة، وقرار الإطلاق. البيانات الحساسة داخل النتائج لا تنشر في صفحة معرفة عامة؛ تحفظ لدى المؤسسة وفق صلاحيات الوصول والاحتفاظ. سيادة تنشر المنهج وقوالب العمل، لا أدلة مؤسسات العملاء أو أسرارهم.
14. إعادة الاختبار والتغير التشغيلي
إطلاق نسخة ناجحة لا يمنح اعتمادًا دائمًا لكل النسخ اللاحقة. تتغير صلاحية الحكم إذا تغير النموذج أو موفره أو system prompt أو RAG corpus أو الصلاحيات أو نوع المستخدم أو طريقة ربط الأدوات أو قواعد التصفية. يحتاج كل تغيير إلى تصنيف أثر؛ بعض التغييرات تتطلب smoke tests محددة، وبعضها regression كاملة واختبارًا عدائيًا جديدًا. ولا يمكن الاكتفاء بإجراء periodic testing إذا وقع حادث أو ظهرت قدرة جديدة للنموذج. يجب أن يسجل النظام متى حدث التغيير، من أجازه، وماذا أعيد اختباره بالضبط.
15. نموذج سجل قرار جاهز للاستخدام
النموذج التالي اقتراح تشغيلي من سيادة للاقتباس داخل المؤسسة وليس نموذجًا رسميًا من IMDA:
Application ID؛ Deployment Version؛ Model and Configuration؛ Use Case؛ Affected Users؛ Data Classification؛ Allowed Actions؛ Risk Scenario؛ Test Method؛ Dataset Version؛ Metric؛ Acceptance Criterion؛ Observed Value؛ Uncertainty؛ Critical Failures؛ Residual Risk؛ Compensating Controls؛ Test Owner؛ Independent Reviewer؛ Decision Authority؛ Go/Conditional Go/No-Go/Insufficient Evidence؛ Conditions؛ Expiry؛ Retest Trigger؛ Evidence Links.
لا يُملأ حقل واحد بوصف فضفاض مثل «تم الفحص». إذا لم يتوفر الرابط أو الرقم أو صاحب القرار، يترك كفجوة مرئية. هدف الوثيقة ليس إقناع المراجع أن كل شيء أخضر، بل تمكينه من إعادة بناء سلسلة الادعاء من النطاق إلى الاختبار إلى القرار.
16. حدود الاستفادة من مصدر IMDA
المصدر السنغافوري يساعد على تنظيم التفكير في تحديد المخاطر والاختبار والتقييم؛ لكنه لا يحدد لكل مؤسسة عتبة صالحة تلقائيًا، ولا يمنح شهادة امتثال، ولا يلغي واجبات الخصوصية أو الأمن أو التشريعات القطاعية. أي سياسة رقمية أو تصنيف Go/No-Go أو سجل قرار في هذه المقالة هو إضافة تشغيلية تحريرية من سيادة ما لم تنسب صراحة للمصدر. بهذه الحدود يمكن تحويل الوثيقة من مادة قراءة إلى إجراء هندسي ومؤسسي قابل للتدقيق دون التضحية بالدقة أو خلق ادعاءات اعتماد غير موجودة.
17. اختبار قبول المقال نفسه
عند تطبيق هذا الدليل على منصة سيادة أو على شركة عميلة، نختبر خمسة أسئلة: هل يمكن تحديد نسخة التطبيق التي صدرت بشأنها النتيجة؟ هل تعرف الإدارة أي أخطاء حرجة لم تُغلق؟ هل يستطيع مدقق مستقل إعادة حساب المقاييس على البيانات المسموح بها؟ هل توجد جهة تحمل سلطة التوقيع وجهة تحمل سلطة الإيقاف؟ وهل يوجد trigger واضح يفتح التقييم من جديد؟ إذا غابت الإجابة عن أحد هذه الأسئلة فإن نتيجة benchmark مهما ارتفعت تبقى دليلًا جزئيًا لا أساسًا مكتملًا لقرار الإطلاق.
المراجع: IMDA Starter Kit for Testing LLM-Based Applications for Safety and Reliability؛ AI Verify Foundation Starter Kit resources.