كيف تختبر تطبيقات LLM قبل الإطلاق؟ من نتيجة Benchmark إلى قرار إطلاق قابل للدفاع

كيف تختبر تطبيقات LLM قبل الإطلاق؟ من نتيجة Benchmark إلى قرار إطلاق قابل للدفاع

لماذا لا يكفي أن تقول المؤسسة «اختبرنا النموذج»؟

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

دليل IMDA لاختبار تطبيقات LLM للسلامة والاعتمادية يتعامل مع هذه المشكلة من زاوية عملية: الاختبار يجب أن يركز على التطبيق كما سيعمل قبل النشر، لا على الادعاء العام بأن النموذج «جيد» أو «آمن». وهو يضع الاختبار في مرحلة pre-deployment بعد إدخال الضوابط والحواجز الأساسية، أي عندما يكون التطبيق قريبًا من صورته التشغيلية الفعلية. الهدف هو التأكد من أن التطبيق يعمل كما هو مقصود ويحقق baseline safety and reliability مناسبًا لسياقه قبل أن يصل إلى المستخدم النهائي.

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

الخطوة الأولى: Identify — اختبر ما يهم فعلًا

منهجية IMDA تبدأ قبل تشغيل أي benchmark. أول سؤال ليس «أي أداة نستخدم؟» بل «ما المخاطر المادية لهذا التطبيق؟». هذا التفريق مهم لأن أدوات الاختبار قد تدفع الفرق إلى قياس ما هو سهل القياس بدل ما هو مهم.

في تطبيق داخلي لتلخيص مستندات غير حساسة، قد تكون الهلوسة وعدم الدقة هي المخاطر الأبرز. في مساعد يتصل ببيانات عملاء، يصبح تسرب البيانات أكثر خطورة. في نظام يدعم قرار توظيف أو ائتمان أو قبول، يظهر التحيز في اتخاذ القرار كخطر مادي. في chatbot عام قد يصبح المحتوى غير المرغوب، والهجمات عبر المطالبات العدائية، ومحاولات تجاوز guardrails جزءًا أساسيًا من خطة الاختبار.

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

إذا لم تحدد العتبة قبل رؤية النتائج، فأنت معرض لخطأ حوكمي خطير: إعادة تعريف النجاح بعد الفشل. مؤسسة ترى 72% ثم تقرر أن 70% كان «مقبولًا» لمجرد أن النتيجة تجاوزته لا تدير المخاطر؛ هي تبرر نتيجة موجودة مسبقًا. لذلك يجب أن يكون threshold جزءًا من قرار الاختبار لا نتيجة لاحقة له.

Baseline Safety and Reliability ليس رقمًا عالميًا

من أكثر الأفكار أهمية في الدليل أن baseline safety and reliability يعتمد على السياق. لا توجد درجة واحدة يجب أن تحققها جميع التطبيقات.

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

هذه ليست دعوة إلى خفض المعايير في التطبيقات منخفضة المخاطر. بل هي دعوة إلى منع fake precision. الدرجة لا تصبح ذات معنى إلا إذا كانت مرتبطة بسياق وقرار. يمكن أن تكون نتيجة 95% غير مقبولة في use case عالي المخاطر إذا كانت الـ5% المتبقية تقع في حالات حرجة، بينما نتيجة أقل قد تكون مقبولة في مهمة إبداعية منخفضة الأثر إذا كانت حالات الفشل غير مادية ويمكن للمستخدم تصحيحها بسهولة.

الخطوة الثانية: Test — ابدأ بالمخرجات ثم ادخل إلى المكونات

يقسم الدليل الاختبار إلى مستويين متكاملين: Output Testing وComponent Testing.

Output Testing يعامل التطبيق ككل. ترسل مدخلات وتشاهد المخرجات كما لو كنت مستخدمًا فعليًا. هذه الطريقة مهمة لأنها تقيس السلوك النهائي بعد أن تعمل كل المكونات معًا. إذا كانت لديك سياسات منع، مرشح محتوى، RAG، system prompt، أو post-processing، فالنتيجة النهائية هي التي يراها المستخدم.

لكن output testing وحده لا يكفي. قد يعطي النظام جوابًا صحيحًا للأسباب الخطأ. في تطبيق RAG مثلًا، قد يسترجع النظام وثائق غير ذات صلة لكن النموذج يجيب من معرفته الداخلية. النتيجة النهائية تبدو ممتازة، لكن architecture فيها عيب. عند تغيير السؤال أو المجال أو النموذج قد يتحول هذا العيب إلى فشل حقيقي. هنا يأتي Component Testing: فحص الاسترجاع، الوثائق المختارة، ranking، prompt، filters، وغيرها من المكونات لمعرفة هل الناتج مر عبر المسار المقصود.

هذه نقطة مهمة في التدقيق: correct output لا يساوي controlled process. إذا كان النظام ينتج الإجابة الصحيحة بدون الاعتماد على مصدر المؤسسة الذي يفترض أن يكون مصدر الحقيقة، فنجاحه اللحظي لا يثبت reliability. بل قد يخفي dependency على معرفة النموذج أو سلوك غير مضمون.

Benchmarking: مفيد لكنه ليس حكمًا نهائيًا

Benchmarking يوفر مرجعية موحدة. يمكن تشغيل مجموعة حالات معلومة وقياس نتائج متكررة باستخدام metrics محددة. هذا مفيد للمقارنة بين إصدارات التطبيق، أو بين configurations، أو قبل وبعد إضافة guardrail.

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

لذلك يجب أن تسأل المؤسسة: هل مجموعة الاختبار representative؟ هل تقيس المخاطر التي حددناها؟ هل تحتوي حالات تشبه استخدامنا؟ هل تختبر لغاتنا وسياقاتنا؟ هل تغطي الحالات الحدية؟ وإذا كانت الإجابة لا، فالمطلوب ليس رفض benchmark بل استكماله باختبارات مخصصة.

Red Teaming: اكتشاف ما لم تخطط له

الـred teaming يكمل benchmarking لأنه لا يفترض أن كل طرق الفشل معروفة مسبقًا. الهدف هو محاولة دفع التطبيق خارج حدوده، واكتشاف blind spots، والحالات الحدية، وسلوكيات تجاوز الضوابط.

في تطبيق LLM يمكن أن يشمل ذلك prompts ملتفة، حقن تعليمات، محاولات استخراج بيانات، تغيير السياق، استغلال الترتيب بين system/user instructions، إدخال محتوى يخدع retrieval أو filter، أو مزج أهداف مشروعة وغير مشروعة داخل نفس الطلب.

القيمة ليست في عدد prompts العدائية التي جربتها. القيمة في ما إذا كان الاختبار مصممًا لاستكشاف أهداف هجوم حقيقية مرتبطة بتطبيقك، وفي ما إذا كنت تستطيع تفسير سبب النجاح أو الفشل. لذلك من المفيد الفصل بين attack technique وattack goal. التقنية قد تكون prompt injection، لكن الهدف قد يكون تسريب بيانات أو تعطيل policy أو الحصول على محتوى ممنوع. إذا لم تفرق بين الاثنين، ستنتج تقارير مليئة بأسماء هجمات بدون فهم أثرها.

الخطر الأول: الهلوسة وعدم الدقة

الهلاوس ليست مجرد «معلومة خاطئة». في سياق assurance يجب تفكيك نوع الفشل. هل الإجابة غير صحيحة؟ هل تتضمن claim غير مدعوم؟ هل لخصت المصدر بطريقة حذفت شرطًا حاسمًا؟ هل نسبت معلومة لمصدر غير موجود؟ هل الإجابة خارج نطاق الوثائق المسترجعة؟ هل retrieval نفسه جلب مواد غير ذات صلة؟

في تطبيقات RAG، الاختبار الجيد لا يكتفي بقياس similarity بين الإجابة والنص المرجعي. يجب فحص relevance لما استرجع، grounding للإجابة في السياق المسترجع، completeness، وربما precision على مستوى claims. يمكن أن تكون الإجابة لغويًا ممتازة لكنها مزيجًا من claim صحيح وclaim مختلق؛ average score قد يخفي هذا.

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

الخطر الثاني: التحيز في اتخاذ القرار

عندما يستخدم LLM في دعم قرار أو تصنيف أو توصية تخص أفرادًا أو مجموعات، المتوسط العام ليس كافيًا. قد يبدو النظام دقيقًا إجمالًا بينما يختلف أداؤه بين مجموعات.

Parity Testing يقارن النتائج بين مجموعات عندما يكون ذلك مناسبًا. لكن parity وحده قد لا يخبرك إن كان المتغير نفسه يؤثر في القرار. هنا يمكن استخدام Perturbation Testing: إنشاء نسخ متقاربة من نفس الحالة مع تغيير سمة محددة لمعرفة هل يتغير الناتج دون مبرر.

في التطبيق العملي يجب أن تنتبه إلى ground truth، توازن مجموعة الاختبار، وحجم العينة. إذا كانت مجموعة فرعية صغيرة جدًا، فقد يبدو الفرق كبيرًا بلا دلالة مستقرة. وإذا كانت labels نفسها منحازة، قد تكرر bias داخل معيار القياس بدل كشفه.

الخطر الثالث: المحتوى غير المرغوب

السلامة لا تعني منع كل شيء. النظام الذي يرفض كل الأسئلة الحساسة قد يحقق انخفاضًا في بعض أنواع المحتوى الضار لكنه يفشل في usefulness. لذلك يشير منهج الاختبار إلى ضرورة النظر أيضًا إلى over-refusal.

اختبار المحتوى غير المرغوب يحتاج taxonomy واضحة: ما أنواع المحتوى التي يجب منعها أو تقييدها؟ ما الحالات المسموحة؟ هل توجد فروق لغوية وثقافية؟ هل guardrail يعمل بنفس الكفاءة بالعربية والإنجليزية؟ هل تغيير الصياغة أو اللهجة أو الكتابة المختلطة يؤدي إلى تجاوز؟

هذه النقطة مهمة جدًا للمؤسسات العربية. الاعتماد على test set إنجليزي فقط قد يعطي ثقة زائفة. يجب اختبار اللغة الفعلية التي يستخدمها الجمهور، بما في ذلك صياغات محلية أو code-switching عندما تكون جزءًا واقعيًا من الاستخدام.

الخطر الرابع: تسرب البيانات

اختبار data leakage يجب أن يبدأ من تعريف ما يعتبر حساسًا. بيانات شخصية؟ أسرار تجارية؟ system prompt؟ وثائق داخلية؟ محتوى من corpus يفترض ألا يظهر لمستخدم معين؟ API keys أو identifiers؟

يمكن تصميم canary values لاختبار ما إذا كانت معلومات حساسة قابلة للاستخراج دون استخدام بيانات حقيقية. كما يمكن قياس disclosure rate أو compliance rate، ثم استخدام component testing لتحديد هل التسرب جاء من retrieval، prompt، filter، أو configuration.

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

الخطر الخامس: القابلية للمطالبات العدائية

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

يجب ألا تحول المؤسسة هذه الفئة إلى checklist من jailbreak prompts. الاختبار القوي يربط كل محاولة بهدف: هل استطاع المهاجم تجاوز policy؟ هل حصل على معلومة غير مصرح بها؟ هل جعل النموذج يتجاهل مصدر الحقيقة؟ هل شغّل أداة أو فعلًا خارج السلطة؟ هل خدع الحواجز؟

والنجاح ليس binary دائمًا. قد يرفض النظام الهدف الأساسي لكنه يكشف partial information أو يعطي hint يساعد في محاولة لاحقة. لذلك qualitative failure analysis مهم جدًا، خصوصًا عندما تكون النتائج مركبة.

الخطوة الثالثة: Assess — الرقم بداية التحليل لا نهايته

بعد تشغيل الاختبارات، يجب أن تقارن النتائج بالعتبات المحددة مسبقًا. لكن التقييم لا يتوقف عند Pass/Fail.

يجب تحليل توزيع النتائج، confidence، وأنواع حالات الفشل. AI Verify Foundation توضح أن Project Moonshot، المرتبط بالـStarter Kit، يتبع ممارسات تشمل تفسير النتائج عبر confidence intervals والتحليل النوعي لحالات الفشل. هذا مهم لأن الفرق بين نتيجتين قد لا يكون ذا معنى إذا كانت العينة صغيرة أو التباين عاليًا.

التقييم الصحيح يسأل: ما الذي فشل؟ هل الفشل عشوائي أم نمطي؟ هل يتركز في فئة مستخدمين أو لغة أو موضوع؟ هل نحتاج تعديل model أم prompt أم retrieval أم guardrail؟ هل التخفيف يخلق ضررًا جديدًا مثل over-refusal؟ هل يجب إعادة الاختبار كاملًا أم فئة محددة؟ هل المخاطر المتبقية مقبولة لصاحب القرار؟

من نتيجة اختبار إلى قرار إطلاق

هنا يجب أن تدخل الحوكمة. الاختبار التقني لا يملك وحده سلطة قبول المخاطر. الأفضل أن يتحول إلى release evidence package يتضمن حدود التطبيق والنطاق، المخاطر التي اعتبرت مادية، سبب اختيار الاختبارات، test datasets ومصدرها وتمثيلها للسياق، metrics وthresholds المحددة مسبقًا، نتائج output testing، نتائج component testing حيث يلزم، benchmark results، red-team findings، failure cases ذات الدلالة، mitigations المنفذة، نتائج retest، residual risk، الاستثناءات المفتوحة، وصاحب قرار الإطلاق وشروطه.

هذا الملف يربط engineering بـrisk management وبـassurance. والأهم أنه يسمح لاحقًا بإجابة سؤال المدقق أو الإدارة: «على أي أساس أطلقنا هذا التطبيق؟»

لماذا الاختبار ليس حدثًا لمرة واحدة؟

حتى لو كان التركيز الرئيسي للدليل على pre-deployment، تطبيق LLM ليس ثابتًا. قد يتغير النموذج خلف API، أو system prompt، أو corpus، أو embedding model، أو retrieval logic، أو filter، أو provider policy. أي تغيير قد يبطل جزءًا من الأدلة السابقة.

لذلك يجب أن تعرف المؤسسة triggers لإعادة الاختبار. من الأمثلة المنطقية: تغيير model version، تغيير مزود، تعديل prompt جوهري، إضافة مصدر بيانات جديد، توسيع الجمهور، تغيير use case، تغيير صلاحيات أو أدوات، incident، أو تدهور monitoring metrics.

تحليل سيادة: هذا الامتداد إلى post-deployment governance ليس ادعاء بأن Starter Kit يفرض trigger list محددة؛ هو تطبيق لحقيقة أن pre-deployment evidence يفقد قيمته عندما تتغير الظروف التي بُني عليها.

أين يقع Project Moonshot؟

Project Moonshot ليس بديلًا عن المنهجية؛ هو أداة تساعد على تنفيذ أجزاء منها. AI Verify Foundation تصفه كأداة للـbenchmark testing والـred teaming لتطبيقات LLM، ويطبق core benchmarks مرتبطة بالمخاطر الخمسة في الـStarter Kit.

الاستخدام الخطأ هو تشغيل Moonshot أولًا ثم التعامل مع التقرير كأنه حكم نهائي. الاستخدام الصحيح هو: تحديد المخاطر → تحديد thresholds → اختيار benchmark/test مناسب → تشغيل الأداة → تحليل النتائج → تطبيق mitigations → retest → اتخاذ قرار.

الأداة تنفذ، لكن المؤسسة ما زالت مسؤولة عن relevance، threshold، interpretation، decision.

ماذا يجب أن تضيفه المؤسسة فوق IMDA؟

الدليل قوي كمنهج اختبار، لكنه ليس برنامج حوكمة كاملًا. المؤسسة تحتاج ربط نتائجه بسجل النظام، تقييم المخاطر، تصنيف البيانات، الأمن، الخصوصية، الموافقات، change management، incident response، monitoring، vendor governance، والتدقيق.

لذلك داخل سيادة يجب ألا نضع هذا المصدر في زاوية «اختبار تقني» فقط. مكانه الصحيح هو نقطة التقاء بين AI assurance وrisk management وsecurity وrelease governance.

قاعدة عملية

إذا لم تستطع المؤسسة الإجابة عن الأسئلة التالية، فهي لم تنهِ pre-deployment assurance فعليًا:

• ما الذي اختبرناه ولماذا؟
• ما المخاطر التي اعتبرناها غير مادية ولماذا؟
• ما العتبات التي وافقنا عليها قبل رؤية النتائج؟
• هل اختبرنا التطبيق النهائي أم نموذجًا معزولًا؟
• هل فحصنا المكونات عندما كانت النتيجة غير واضحة؟
• هل مجموعة الاختبار تمثل مستخدمينا ولغاتنا وسياقنا؟
• ما أخطر حالات الفشل حتى لو كان average score جيدًا؟
• ما الذي أصلحناه؟
• هل أعدنا الاختبار بعد الإصلاح؟
• من قبل residual risk؟
• ما الذي سيجبرنا على إعادة الاختبار بعد الإطلاق؟

إذا كانت الإجابات موثقة وقابلة للمراجعة، فالاختبار بدأ يتحول إلى assurance. إذا كانت الإجابة الوحيدة هي «حققنا 87% في benchmark»، فهذه نتيجة تقنية، لا قرار حوكمة.