نجاح النموذج في Benchmark لا يثبت سلامة تطبيق متكامل يضم RAG وصلاحيات وأدوات وواجهات وقرارات بشرية.
اختبار النموذج أم التطبيق؟ أين تبدأ وتنتهي مسؤولية AI Assurance؟
يقع خطأ معماري عندما تشتري المؤسسة نموذجًا ذا ترتيب مرتفع ثم تعامله كأنه دليل ثقة لكل نظام يعتمد عليه. الـLLM المجرّد ليس التطبيق الذي يتفاعل مع مستخدم وبيانات وصلاحيات وموردين وقرارات. تهدف هذه المقالة إلى فصل موضوع التقييم ومعايير أدلته، كي لا تتحول نتيجة benchmark إلى موافقة شاملة على سلسلة تشغيل لم تدخل نطاق الاختبار.
1. الفرق الأساسي في موضوع التقييم
النموذج هو مكوّن احتمالي يتلقى سياقًا ويولد استجابة؛ أما التطبيق فهو نظام أعمال له مستخدمون وصلاحيات وبيانات وواجهات وتكاملات ومخرجات وتنفيذ. نجاح النموذج على Benchmark لا يضمن سلامة التطبيق الذي يتصل بملفات مستخدمين أو خدمات مالية. قد يفشل تطبيق بنموذج ممتاز بسبب استرجاع مستند غير ساري، أو أداة تستخدم صلاحية واسعة، أو واجهة تعرض توصية غير مؤكدة كقرار نهائي. وقد ينجح تطبيق محدود بفضل ضوابط واضحة حتى إن لم يكن النموذج الأعلى ترتيبًا في التصنيفات العامة. لذلك يجب أن يحمل كل ادعاء assurance موضوعه بدقة: Model Capability، Application Behaviour، Component Control، أو Enterprise Operational Readiness.
سؤال الاختبار: ما النظام الذي صدر عنه الادعاء؟
2. خريطة الطبقات السببية
تبدأ من input capture وauthentication ثم authorization وretrieval وcontext assembly ثم model inference ثم output filtering وtool routing وaction enforcement وhuman review وأخيرًا logging/monitoring. لكل طبقة فشل مختلف؛ إذا أعاد النظام مستندًا من قسم سري فهذا خطأ فصل وصول مهما بدا الجواب النهائي حذرًا. وإذا ولّد النموذج استشهادًا غير موجود رغم استرجاع مصادر سليمة فهذا خطأ grounding أو generation. ويجب أن يثبت الاختبار موضع الفشل بالبيانات المتاحة بدل نسبته تلقائيًا إلى «هلوسة AI». تتيح هذه الخريطة اختيار علاج تقني صحيح وحفظ تاريخ الإصدارات.
سؤال الاختبار: أين حدث الفشل؟
3. مسألة RAG واختبار المكونات
التطبيق قد يسترجع مقطعًا خاطئًا ويعطي جوابًا صحيحًا من المعرفة العامة؛ اختبار المخرجات يعتبره صحيحًا بينما يفشل اختبار الاسترجاع. وقد يسترجع الوثيقة الصحيحة ثم يختصرها بصورة تزيل شرطًا إلزاميًا. لذلك نفصل صلاحية اختيار الوثائق وحداثتها وفلترة حق الوصول، وصحة نقل الادعاءات من المقتطف، ودقة الاستشهاد. يفضل إنشاء حالات لها نسختان من السياسة؛ إحداهما نافذة وأخرى ملغاة، وحالات تتضمن وثيقة تخص جهة مختلفة. لا تُقاس جودة الاسترجاع بعدد نتائج البحث فقط، بل بوجود الأدلة التي يحتاجها القرار ضمن حدود السلطة.
سؤال الاختبار: هل ظهر خطأ في الاسترجاع رغم صحة الجواب؟
4. التحكم في الأدوات وعلاقة النص بالفعل
إذا كان النظام يستطيع إرسال بريد أو تحديث CRM أو إنشاء طلب شراء، يصبح نجاح اختبار المحتوى وحده غير كاف. يجب اختبار كيف يحدد النظام recipient وما إذا كان للمستخدم تفويض لإجراء العملية، وكيف يتحقق الخادم من حدود الإنفاق والتكرار، وما إذا كان هناك تصريح بشري قبل action حساس. يمكن أن يقدم النموذج اعتذارًا بعد تشغيل الأداة فعلًا، أو يعلن أنه نفذ إجراءً لم يحدث. لذلك تراجع الأحداث التنفيذية المستقلة عن النص: tool-call logs، معرّفات المعاملات، نتائج واجهة المورد، وحالة التراجع. وينبغي أن تكون حالات الاختبار داخل بيئة محاكية حتى لا تؤثر في أعمال حقيقية دون تصريح.
سؤال الاختبار: هل وقع فعل أم مجرد نص؟
5. المخاطر التي تتجاوز الـprompt
قد يفشل التطبيق بسبب cache يشترك فيه مستخدمون أو session state لا تنظف بعد تسجيل الخروج، أو خطأ في parser يقرأ جدولًا بطريقة تعكس قيمة، أو endpoint خارجي غير متاح، أو حدود rate limiting تفشل عند ارتفاع الحمل. هذه الأخطاء لا يمكن الحكم عليها باختبار نموذج لغوي وحيد. والمهم كذلك عدم نسبة كل مجالات الأمن التشغيلي إلى دليل IMDA؛ الوثيقة تركز على اختبارات السلامة والاعتمادية لمخاطر محددة، بينما يحتاج النظام الكامل إلى ضوابط أمن تطبيقات وخصوصية ومرونة إضافية وفق السياق. يظهر كل نطاق وأصل في الخطة بدل خلطه مع Source Claim.
سؤال الاختبار: ما المخاطر خارج Benchmark؟
6. السلوك عبر اللغات والإصدارات
قد يمتلك النموذج أداءً ممتازًا في الإنجليزية لكن التطبيق يخدم جمهورًا عربيًا يستخدم لهجات ومستندات تنظيمية. يجب اختبار النصوص العربية والجداول واتجاه الكتابة وتداخل المصطلحات الإنجليزية، وكذلك صحة الترجمة عند الاستشهاد. ويتعين تثبيت نموذج المزود أو مراقبة تغيّره لأن نفس prompt على إصدارين قد ينتج سلوكًا مختلفًا. كما أن تغيير ترتيب مستندات الاسترجاع أو system prompt قد يغير النتائج. إذا لم تحفظ نسخة النظام الخاضع للاختبار، فلن تستطيع إعادة بناء دليل التقييم عند وقوع حادث.
سؤال الاختبار: ما الإصدارات واللغات المغطاة؟
7. اختبار التجربة البشرية
واجهة تعرض إجابة بثقة عالية دون أدلة قد تدفع الموظف إلى اعتمادها، حتى إذا كانت دقتها الإحصائية مشابهة لتطبيق آخر يعرض مصادر ودرجة عدم يقين وخيار مراجعة. لذلك يجب تقييم Human-AI Configuration: هل يستطيع الإنسان مراجعة المصدر؟ هل يملك السلطة والوقت؟ هل توصل الواجهة الاستثناءات الحرجة؟ وهل توجد طريقة واضحة لتصحيح المخرجات والإبلاغ عن الخطأ؟ اختبار النموذج لا يتناول أثر ترتيب الخيارات أو تصميم التنبيه أو الضغط الزمني، لكنها قد تكون حاسمة في مدى تعرض المؤسسة للضرر.
سؤال الاختبار: هل يستطيع الإنسان التدخل؟
8. تفسير نجاح الـbenchmark
التقييم المرجعي مفيد لاختيار النماذج وتقدير مبدئي لبعض الخصائص، لكنه ليس قبولًا إنتاجيًا. تحتاج المؤسسة إلى تحليل مدى تمثيل مجموعة الاختبار لجمهورها وقراراتها، وقياس الأداء في حالات خاصة بالمنتج، وتقدير عدم اليقين، ورصد الفشل عالي الشدة. قد يحقق نموذج معدلًا عاليًا في تقييم الأسئلة العامة ولا يستطيع التعامل مع نظام ترقيم تعاميم معينة أو مستندات تخص فرعًا محليًا. كما لا يمكن مقارنة results من منصات مختلفة دون معرفة dataset وإعدادات inference وأسلوب التحكيم.
سؤال الاختبار: هل كانت بيانات المعيار ممثلة؟
9. تفسير Red Teaming
عندما تختبر هجوم prompt injection، لا يكفي سؤال النموذج أن يتجاهل تعليماته. في التطبيقات المتصلة بأدوات ومصادر خارجية يجب محاكاة قدرة المهاجم على حقن محتوى في document أو response ثم مراقبة ما إذا تحولت المعلومات إلى تعليمات ذات سلطة. يفرق السجل بين نص خرج من النموذج، ومحاولة استدعاء أداة، وتنفيذ معاملة. فشل الخداع النصي لا يعني أن حدود الصلاحيات صحيحة؛ ونجاح الخداع النصي لا يعني أن معاملة ضارة نفذت إذا منعتها طبقة الإنفاذ. هذه الفروق تحمي دقة التقارير الأمنية.
سؤال الاختبار: هل اختبرت نقطة الإنفاذ؟
10. إطار الأدلة متعدد الطبقات
يحتاج الملف إلى Model Card أو بيان نموذج حيث يتوفر، وApplication System Card، وDataset Manifest، ونسخ البرامج والمكونات، وسجل المخاطر، وTest Plan، وRaw Results، وComponent Traces، وFindings، وRemediation، وRelease Decision. يجب أن يميّز بوضوح ما صادر من المزود وما اختبرته المؤسسة وما أظهره مراجع مستقل. لا يعادل وجود وثيقة «الشركة ملتزمة بالأخلاقيات» اختبارًا قابلاً للإعادة. كما لا يجوز نسخ بيانات مؤسسات العملاء إلى مخزن توثيق عام باسم الشفافية؛ تحتفظ المؤسسة بالأدلة الخام ضمن حدود السرية والخصوصية.
سؤال الاختبار: هل يحتمل تتبع سلسلة الادعاء؟
11. تقييم مورّد خارجي
إذا اشترت مؤسسة تطبيق LLM كخدمة، فقد لا تستطيع الوصول إلى وزن النموذج أو trace داخلي كامل. هذا لا يعفيها من حوكمة المخاطر: يمكن اختبار سلوك التطبيق خارجيًا، وطلب تقارير ضمان المورد ونطاقها، وتحديد حدود البيانات والاحتفاظ، وضبط الصلاحيات المحلية، وتعريف شروط التغيير والإخطار والحوادث والخروج من المورد. ينبغي عدم مساواة شهادة عامة للمزود بسلامة حالة استخدام المؤسسة؛ فقد يختلف إعداد tenant أو تفعيل ميزة جديدة أو إتاحة أداة عن نطاق الشهادة. يُسجل ما لم يمكن التحقق منه ويؤثر في قرار قبول المخاطر.
سؤال الاختبار: ما ضمانات المورد وحدودها؟
12. اختبار النظام في دورة حياة كاملة
القرار الأولي قبل الإنتاج لا يغطي أثر تحديث فهرس المعرفة أو زيادة المستخدمين أو ربط وسيلة دفع أو إدخال وكيل متعدد الخطوات لاحقًا. يجب ربط تقييم المخاطر والضوابط بالتغيير التشغيلي، مع regression للحالات الحرجة وإعادة اختبار للتغييرات الجذرية. وعند وقوع حادث، لا نكتفي باسترجاع Score سابق؛ نراجع إصدار النظام وtrace للحادث ومصدره، ونعيد النظر في شروط الإطلاق. هذه استمرارية assurance وليست حملة اختبار لحظة الإطلاق فقط.
سؤال الاختبار: متى يبطل القرار السابق؟
13. سيناريو تخصصي للنقل البحري
لنأخذ مساعدًا يقرأ إشعارات وصول السفن ويوفر اقتراحات توزيع أرصفة. نموذج قوي قد يفهم المصطلحات البحرية بشكل جيد، لكنه إذا استرجع جدول رسو قديمًا أو قرأ وقت وصول محليًا على أنه توقيت UTC قد يقدم اقتراحًا خطرًا على التشغيل. وإذا كان يتصل بنظام إدارة الأرصفة، يصبح التحقق من سلطة إجراء التغيير أهم من جودة الشرح. يجب اختبار المصدر والوقت وحداثة المستند والصلاحية وما إذا كان الاقتراح يتحول تلقائيًا إلى حجز أو يبقى توصية. نجاح model benchmark في فهم العربية أو الملاحة لا يغني عن كل ذلك.
سؤال الاختبار: هل تعمل ضوابط الزمن والسلطة؟
14. قرار التطبيق لا قرار النموذج
عند إقرار Go يجب أن تسجل المؤسسة أنها أجازت نسخة تطبيق محددة وفئة وظائف ومستخدمين وأدوات تحت ضوابط واضحة، لا أنها قررت أن «النموذج موثوق» على نحو مطلق. إذا كان مورد النموذج يتغير، تحدد آلية الكشف وإعادة الاختبار والإيقاف. ويجب أن تظهر أي فجوة في الرؤية أو المكونات بوصفها Insufficient Evidence أو خطرًا متبقيًا، لا نقطة صامتة. من هنا يتحول اختبار تطبيق LLM إلى سلسلة قرار: نطاق → مخاطر → أدلة → تشغيل → مراقبة.
سؤال الاختبار: من يملك قرار قبول التطبيق؟
15. محدودية المصدر والنسبة الصحيحة
يقدم IMDA Starter Kit منهجًا منظمًا لاختبار تطبيقات LLM عبر المخرجات والمكونات وفق سياق الاستخدام، ويركز على خمسة مخاطر للسلامة والاعتمادية. أما خريطة أنظمة الميناء واختبارات cache والقرارات المؤسسية متعددة الطبقات الواردة هنا فهي بناء تحليلي من سيادة لمساعدة الممارسين على توسيع النظر دون الإيحاء بأنها جميعًا عناصر إلزامية في الوثيقة الرسمية. وتبقى أي نتيجة على مورد أو نموذج أو تطبيق محدد رهينة الاختبار الفعلي، فلا يصح استخدام هذه المقالة كإثبات سلامة لنظام لم يُختبر.
سؤال الاختبار: ما مصدر الادعاء؟