اختبار النماذج اللغوية الكبيرة (LLM Testing)
اختبار النماذج اللغوية الكبيرة (LLM testing) هو ممارسة جمع الأدلة على أن النظام المبني على نموذج لغوي كبير يفعل ما ينبغي، ويستمر في ذلك حين يتغير الموجّه أو النموذج أو البيانات، ويفشل بأمان حين يدفعه المستخدمون — أو المهاجمون — بعيداً عن المسار المتوقع. ونادراً ما يكون النظام قيد الاختبار هو النموذج وحده: إنه الموجّه، وطبقة الاسترجاع، والأدوات التي قد يستدعيها النموذج، وضوابط الحماية، وواجهة المستخدم، وميزانية الوقت والمال التي تكلّفها كل إجابة.
هذا الدليل هو مدخل المجال. يشرح ما الذي يجعل أنظمة LLM مختلفة عن البرمجيات التقليدية، وأي الممارسات راسخة وأيها ناشئة وأيها ما زال بحثاً، وكيف تكتب تحققات على مخرجات تتغير من تشغيل إلى آخر، وكيف تُدخل التقييم في عملية الإصدار. وتتعمق الصفحات الأضيق في تقييم المخرجات، واختبار أمان LLM، واختبار RAG.
ما هو اختبار LLM — وما ليس هو
نشاطان مختلفان يتشاركان كلمتي «الذكاء الاصطناعي» و«الاختبار». اختبار أنظمة الذكاء الاصطناعي يعني معاملة المنتج المبني على LLM بوصفه النظام قيد الاختبار: مساعد دعم فني، أو أداة تلخيص مستندات، أو مراجِع كود، أو وكيل يحجز المواعيد. أما استخدام الذكاء الاصطناعي لمساعدة ضمان الجودة فيعني استخدام النموذج أداةً داخل عملية الاختبار — لصياغة حالات الاختبار أو تقارير الأخطاء أو بيانات الاختبار. هذا الدليل عن الأول. والثاني مفيد، وله قسم قصير في النهاية، لكنه يجيب عن سؤال مختلف.
اختبار LLM يظل اختبار برمجيات. فالمتطلبات، وتحليل المخاطر، وتصميم الاختبارات، والانحدار، وتقارير العيوب، ومعايير الخروج كلها تنطبق. ما يتغير هو المرجع (Oracle) — أي الطريقة التي تقرر بها ما إذا كانت المخرجات صحيحة. واجهة الدفع إما أن تعيد 201 بالإجمالي الصحيح أو لا؛ أما النموذج المطلوب منه تلخيص عقد فقد ينتج مئة ملخص مقبول مختلف وبضعة ملخصات خاطئة بشكل خفي. ومعظم التقنيات الجديدة في هذا المجال طرق لبناء مرجع للمخرجات المفتوحة.
ما الذي يجعل اختبار أنظمة LLM مختلفاً
الفروق أدناه هي سبب أن حزمة اختبار تقليدية، وحدها، تمنح ثقة زائفة. يصف كل من التقرير الفني ISO/IEC TR 29119-11 ومنهج ISTQB CT-AI خصائص للأنظمة المبنية على الذكاء الاصطناعي — مثل عدم الحتمية، وغياب المواصفة الدقيقة، وصعوبة تحديد النتائج المتوقعة — تجعل اختبارها أصعب من الكود المبني على القواعد.
- عدم الحتمية (Non-determinism) — المدخل نفسه قد ينتج مخرجات مختلفة. فالنماذج تولّد النص بأخذ عيّنات من الرموز (Tokens) وفق توزيع احتمالي؛ وتتحكم معاملات مثل درجة الحرارة (Temperature) وtop-p في مقدار التباين المسموح. خفض درجة الحرارة يقلل التباين، لكنه عملياً لا يضمن مخرجات متطابقة بين الاستدعاءات، لذا يجب ألا تعتمد الاختبارات على نص حرفي واحد إلا إذا فرضته صيغة المخرجات.
- مخرجات مفتوحة — في معظم المهام لا توجد إجابة صحيحة واحدة، بل إجابات مقبولة وفق معايير (حقائق صحيحة، ونقاط مطلوبة مغطاة، ونبرة مناسبة، وعدم وجود محتوى محظور).
- تغيير لا تتحكم فيه — قد يحدّث مزوّد الخدمة النموذج المستضاف أو يوقفه؛ وقد يغيّر تعديل جملة واحدة في الموجّه السلوك في حالات لا علاقة لها بالتعديل. وكل تغيير في إصدار النموذج أو موجّه النظام أو إعدادات الاسترجاع أو تعريفات الأدوات هو خطر انحدار.
- نافذة السياق (Context window) — لا يرى النموذج إلا ما يتسع له سياقه: موجّه النظام، والمحادثة، والمستندات المسترجعة، ونتائج الأدوات. المحادثات الطويلة والمستندات الكبيرة تقتطع التعليمات أو تميّعها، فتنشأ عيوب لا تظهر إلا مع الطول.
- استخدام الأدوات والوكلاء (Agents) — حين يستطيع النموذج استدعاء دوال (بحث، إرسال بريد، تحديث سجل)، تصبح مخرجاته فعلاً. عندها يغطي الاختبار الأدوات التي يختارها، والمعاملات التي يمررها، وما يفعله عند الأخطاء، وما يجب ألا يفعله أبداً دون تأكيد.
- سطح هجوم باللغة الطبيعية — أي نص يقرؤه النموذج، بما في ذلك صفحة ويب أو ملف مرفوع، قد يحتوي تعليمات. ولهذا يأتي حقن الموجّهات (Prompt injection) أولاً في قائمة OWASP Top 10 لتطبيقات LLM لعام 2025.
راسخ وناشئ وبحثي: كيف تقرأ هذا المجال
يتحرك اختبار LLM بسرعة، وكثير مما يُنشر تجريبي. صنّف كل ممارسة تعتمدها، حتى لا يعامل الفريق مقياساً بحثياً كأنه معيار إصدار. والتصنيفات المستخدمة في هذه الأدلة هي:
- راسخ (ESTABLISHED) — حِزم انحدار من حالات اختبار ثابتة يُعاد تشغيلها عند كل تغيير؛ وتحققات المطابقة التامة والتعابير النمطية وJSON Schema على المخرجات المهيكلة؛ والمراجعة البشرية وفق معايير تقييم مكتوبة (Rubrics)؛ واختبار الأمان وفق OWASP Top 10 لتطبيقات LLM لعام 2025 (حقن الموجّهات، والإفصاح عن المعلومات الحساسة، والصلاحيات المفرطة، والمعالجة غير السليمة للمخرجات وغيرها)؛ واختبار الأداء والتكلفة والمهل الزمنية التقليدي للتطبيق.
- ناشئ (EMERGING) — التقييم بواسطة نموذج («LLM-as-a-judge» أو النموذج كمُحكِّم)، حيث يقيّم نموذجٌ مخرجات نموذج آخر وفق معايير؛ والفريق الأحمر الآلي (Automated red-teaming)، حيث يولّد نموذج أو سكربت مدخلات عدائية على نطاق واسع؛ والمراقبة الإنتاجية لعيّنات من المحادثات مع تقييم آلي. مفيدة وواسعة الانتشار، لكن بلا معايير متفق عليها ومع نقاط ضعف معروفة.
- بحثي (RESEARCH) — اختبارات القياس المرجعية العامة (Benchmarks) مثل TruthfulQA وإطار HELM؛ ومقاييس RAG المقترحة في أوراق بحثية مثل Ragas (الأمانة للمصدر، وملاءمة الإجابة، وملاءمة السياق). تُثري طريقة تفكيرك في الجودة؛ لكنها لا تخبرك ما إذا كان منتجك يعمل لمستخدميك.
الخريطة: ما الذي تختبره في نظام LLM
عامل منتج LLM كطبقات، لكل منها اختباراتها. النموذج عادةً اعتمادية تختارها وتثبّت إصدارها، لا شيء تدرّبه. والموجّه كود، يُراجَع ويُدار بالإصدارات كالكود. والتطبيق المحيط بالنموذج — الاسترجاع والأدوات وضوابط الحماية وواجهة المستخدم والسجلات — برمجيات تقليدية تُختبر تقليدياً، مع حالات إضافية لعدم قابلية النموذج للتنبؤ.
- تقييم المخرجات — الصحة، والملاءمة، والاستناد إلى المصادر (Groundedness/Faithfulness)، والهلوسة (يستخدم NIST AI 600-1 مصطلح التلفيق Confabulation للمحتوى الخاطئ المقدَّم بثقة)، والاتساق، والمتانة أمام إعادة الصياغة والمدخلات المشوّشة، والسلامة والسُّمّية، والخصوصية وتسرّب البيانات. ويغطي دليل تقييم LLM مجموعات البيانات والمقيِّمين ومعايير التقييم بعمق.
- الأمان — حقن الموجّهات المباشر وغير المباشر، والإفصاح عن المعلومات الحساسة وموجّه النظام، والصلاحيات المفرطة للأدوات، والمعالجة غير السليمة لمخرجات النموذج في بقية التطبيق، والاستهلاك غير المحدود. ويقدّم دليل اختبار أمان LLM حالات اختبار دفاعية وغير ضارة لكل منها.
- التوليد المعزّز بالاسترجاع (RAG) — جودة الاسترجاع مقيسةً منفصلةً عن التوليد، وصحة الاستشهادات، وسلوك «لا أعرف» حين لا تحتوي مجموعة المستندات (Corpus) على إجابة، والحداثة، والتحكم في الوصول إلى المستندات المسترجعة. ويغطي دليل اختبار RAG كل مرحلة.
- سلوك التطبيق — المهل وإعادة المحاولة حين تبطئ واجهة النموذج أو تفشل، والاستجابات المتدفقة والجزئية، وحدود الرموز والتكلفة، وتحديد المعدل، ورسائل البديل، وعرض Markdown والروابط في الواجهة، والتسجيل دون بيانات شخصية، وعرض الإجابات العربية من اليمين إلى اليسار.
اختبار الموجّهات (Prompt testing)
موجّه النظام مواصفة مكتوبة بلغة طبيعية، ويستحق التدقيق نفسه الذي يستحقه المتطلب: هل كل تعليمة قابلة للاختبار، وهل تتعارض أي تعليمات، وماذا يجب أن يحدث خارج النطاق المقصود؟ لكل تعليمة، اكتب حالة اختبار واحدة على الأقل تُظهر اتباعها، وأخرى تحاول دفع النموذج إلى خرقها بطلب عادي غير خبيث — مستخدم يسأل عن شيء خارج النطاق، أو يكتب بلغة أخرى، أو يلصق نصاً طويلاً جداً.
اختبر الموجّه بتنوّع واقعي، لا بالأمثلة المستخدمة أثناء كتابته فقط. فالقصد نفسه مصاغاً بأسلوب رسمي وغير رسمي، ومع أخطاء إملائية، وبالعربية، وبالهندية، وبأنظمة كتابة مختلطة، ومع رموز تعبيرية وأحرف خاصة، يجب أن يقود إلى القرار نفسه. احفظ الموجّهات في نظام التحكم بالإصدارات، وامنح كل إصدار معرّفاً يُسجَّل مع كل استجابة، ولا تعدّل موجّهاً في الإنتاج دون إعادة تشغيل مجموعة التقييم.
- النطاق — الأسئلة خارج النطاق تتلقى الرفض أو إعادة التوجيه المتفق عليهما، لا إجابة مرتجلة.
- الصيغة — تتبع المخرجات البنية المطلوبة (JSON، عناوين، حد للطول) في كل حالة من المجموعة.
- اللغة — تأتي الإجابة بلغة المستخدم حين ينص الموجّه على ذلك؛ وتُعرض الإجابات العربية صحيحةً من اليمين إلى اليسار.
- الشخصية والنبرة — تثبت النبرة المطلوبة عبر المحادثات الطويلة، لا في الرد الأول فقط.
- المتانة — إعادة الصياغة والأخطاء الإملائية والمسافات الزائدة والأحرف المتشابهة في Unicode والمدخلات الطويلة جداً لا تغيّر القرار.
جرّبها: مولّد بيانات اختبار متعددة اللغات جرّبها: مولّد مجموعات بيانات Unicode جرّبها: مولّد مجموعات الأحرف الخاصة
كيف تكتب تحققات على مخرجات غير حتمية
لا يمكنك مقارنة إجابة مفتوحة بنص متوقع واحد، لكن يمكنك مع ذلك كتابة اختبارات صارمة. أقوى تقنية هي تقييد المخرجات: اطلب من النموذج مخرجات مهيكلة (JSON) وتحقق منها مقابل JSON Schema. فحص المخطط حتمي حتى حين لا تكون الصياغة داخل الحقول كذلك. ثم تحقق من الخصائص التي يجب أن تتوفر في كل إجابة مقبولة، وفي ما يتبقى من أحكام تقديرية شغّل كل حالة عدة مرات وطبّق عتبة.
- التحقق من المخطط (راسخ) — الحقول المطلوبة موجودة، والأنواع صحيحة، والقيم المعدّدة محترمة، ولا حقول زائدة. فشل المخطط عيب صريح بصرف النظر عن الصياغة.
- المطابقة التامة حيث تسمح المهمة (راسخ) — تسميات التصنيف، والمعرّفات المستخرجة، والتواريخ، والمبالغ، وقرارات نعم/لا.
- التحقق القائم على الخصائص (Property-based) (راسخ) — الإجابة تحتوي رقم الطلب الوارد في المدخل؛ ولا تحتوي عنوان بريد إلكتروني؛ وأقل من 120 كلمة؛ وكل معرّف مصدر مستشهد به موجود في المجموعة المسترجعة؛ واللغة عربية.
- عتبات عبر تشغيلات متكررة — شغّل الحالة N مرة (مثلاً 5 أو 10) واشترط نسبة نجاح (مثلاً 9 من 10). سجّل N والنسبة؛ فتشغيل أخضر واحد لحالة غير حتمية لا يثبت الكثير.
- التقييم بمعايير لما تبقى — مراجعون بشريون، أو مقيِّم آلي من نموذج معايَر مقابل تسميات بشرية (ناشئ)، يقيّمون الإجابات وفق معايير مكتوبة.
{
"id": "refund-policy-017",
"input": "Can I return a laptop I bought 20 days ago?",
"checks": [
{ "type": "json_schema", "schema": "schemas/support-answer.json" },
{ "type": "equals", "path": "$.intent", "value": "return_request" },
{ "type": "contains", "path": "$.answer", "value": "30 days" },
{ "type": "not_matches", "path": "$.answer", "regex": "[\\w.]+@[\\w.]+" },
{ "type": "max_words", "path": "$.answer", "value": 120 }
],
"runs": 10,
"min_pass_rate": 0.9
}تقييم الانحدار عند كل تغيير في الموجّه أو النموذج
أثمن ممارسة في اختبار LLM هي أيضاً أكثرها تقليدية: احتفظ بمجموعة تقييم ذات إصدارات وأعد تشغيلها عند كل تغيير في الموجّه أو إصدار النموذج أو إعدادات الاسترجاع أو تعريفات الأدوات. قارن النتائج بآخر خط أساس مقبول، لا بحالة مثالية. التغيير الذي يرفع متوسط الدرجة بينما يكسر ثلاث حالات سلامة كانت ناجحة هو انحدار (Regression).
في خط التكامل المستمر يبدو هذا كأي مرحلة اختبار أخرى. التحققات الحتمية (المخطط، والمطابقة التامة، وتحققات الخصائص) تعمل على كل طلب دمج وتمنع الدمج عند فشلها. أما التقييمات الأبطأ أو الأعلى كلفة — التشغيلات المتكررة، والتقييم بنموذج — فتعمل ليلياً أو قبل الإصدار، بعتبات متفق عليها مسبقاً. وتُحفظ كل نتيجة مع معرّف النموذج وإصدار الموجّه وإصدار مجموعة البيانات والتاريخ، بحيث يمكن تتبّع أي هبوط لاحق في الجودة إلى التغيير الذي سببه.
- ثبّت إصدار النموذج في الإعدادات؛ وعامل تحديث المزوّد للنموذج كإصدار يحتاج تشغيل تقييم كاملاً.
- احفظ مجموعات التقييم بصيغة JSON Lines في مستودع الكود مع وسم إصدار، ولا تضبط الموجّه أبداً على الحالات نفسها التي تستخدمها لقبوله.
- قارن المخرجات بين خط الأساس والمرشّح لعيّنة من الحالات واقرأ الفروق — فالأرقام تُخفي ما تغيّر.
- احتفظ بمجموعة صغيرة من الحالات يجب أن تنجح بنسبة 100% (السلامة، والخصوصية، ورفض الأفعال المحظورة)؛ وعامل أي فشل فيها كعيب حاجب.
مقاييس جودة الذكاء الاصطناعي وحدودها
مقاييس LLM المفيدة مرتبطة بمهمة محددة ومجموعة بيانات محددة. معدل نجاح المهمة (نسبة الحالات التي تحقق فيها هدف المستخدم)، ودرجات معايير التقييم، ونسب نجاح التحققات الحتمية، ومعدل الاستناد إلى المصادر (الإجابات المدعومة كلياً بمصادرها)، ومعدل الرفض مقسوماً إلى رفض مناسب ورفض غير مناسب، ومئينات زمن الاستجابة، والتكلفة لكل طلب — كلها ذات معنى حين تعرف على ماذا قيست.
كن صريحاً بشأن الحدود. الدرجة جيدة بقدر جودة مجموعة بياناتها فقط: نسبة نجاح 95% على 40 حالة سهلة لا تقول الكثير عن الإنتاج. والدرجات التي يمنحها نموذج مقيِّم ترث تحيزاته. وانخفاض معدل الرفض قد يعني أن النموذج أصبح أكثر فائدة أو أنه صار أسهل في إساءة الاستخدام. أبلغ عن المقاييس مع حجم العيّنة وإصدار مجموعة البيانات والمقيِّم المستخدم، واقرأ الحالات الفاشلة لا المتوسطات فقط.
المعايير وأطر إدارة المخاطر
لا يفرض أي معيار طريقة كاملة لاختبار LLM، لكن عدة معايير تمنح بنية ومصطلحات. ينظّم إطار NIST لإدارة مخاطر الذكاء الاصطناعي (AI RMF 1.0) العمل على المخاطر في أربع وظائف — الحوكمة (Govern) والتخطيط (Map) والقياس (Measure) والإدارة (Manage)؛ ويقع التقييم والاختبار أساساً تحت القياس. ويسرد ملفه الخاص بالذكاء الاصطناعي التوليدي، NIST AI 600-1، مخاطر خاصة بالذكاء الاصطناعي التوليدي أو يضخّمها، منها التلفيق (Confabulation)، وخصوصية البيانات، ونزاهة المعلومات، وأمن المعلومات، مع إجراءات مقترحة — وهي قائمة تحقق مفيدة حين تقرر ما الذي تقيّمه.
يحدد المعيار ISO/IEC 42001 متطلبات نظام إدارة الذكاء الاصطناعي: إنه السياق المؤسسي (السياسات والأدوار وتقييم المخاطر والمراقبة) الذي يجري فيه الاختبار، لا طريقة اختبار. والتقرير الفني ISO/IEC TR 29119-11 يقدّم إرشادات لاختبار الأنظمة المبنية على الذكاء الاصطناعي. ويغطي منهج ISTQB لاختبار الذكاء الاصطناعي (CT-AI) اختبار هذه الأنظمة، وتُعد قائمة OWASP Top 10 لتطبيقات LLM لعام 2025 المرجع لمخاطر أمان LLM.
الاتجاه الآخر: استخدام الذكاء الاصطناعي لمساعدة ضمان الجودة
النماذج مفيدة أيضاً داخل عملية الاختبار: تحويل قصة مستخدم إلى مسودة حالات اختبار، واقتراح الحالات الحدّية، وتنظيم ملاحظة خطأ أولية في تقرير. أدوات متقن للذكاء الاصطناعي في ضمان الجودة تنتمي إلى هذا الاتجاه، ويغطيه منهج ISTQB CT-GenAI. والانضباط نفسه ينطبق بالعكس: حالة الاختبار التي يولّدها الذكاء الاصطناعي مسودة يراجعها المختبِر من حيث الصحة والملاءمة والحالات الناقصة قبل أن تدخل الحزمة. ولا تستخدم مخرجات نموذج مرجعاً لاختبار النموذج نفسه.
الأسئلة الشائعة
هل يمكن اختبار تطبيق LLM إذا كانت مخرجاته غير حتمية؟
نعم. قيّد المخرجات حيث تستطيع (JSON مهيكل يُتحقق منه مقابل مخطط)، وتحقق من الخصائص التي يجب أن تتوفر في كل إجابة جيدة، وشغّل الحالات المتبقية عدة مرات مع عتبة لنسبة النجاح، واستخدم المراجعة وفق معايير للجودة المفتوحة. التحققات الحتمية تلتقط معظم حالات الانحدار؛ والتشغيلات المتكررة ومعايير التقييم تغطي الباقي.
هل ضبط درجة الحرارة على 0 يجعل الاختبارات حتمية؟
يقلل التباين لكن لا ينبغي الاعتماد عليه للحصول على مخرجات متطابقة بين الاستدعاءات أو بعد تحديثات النموذج. صمّم اختبارات تنجح لكل إجابة مقبولة لا لنص حرفي واحد، واستخدم المطابقة التامة فقط حيث للمهمة مخرج صحيح واحد، كتسمية تصنيف أو معرّف مستخرج.
ما الفرق بين اختبار الذكاء الاصطناعي واستخدام الذكاء الاصطناعي في الاختبار؟
اختبار الذكاء الاصطناعي يعامل المنتج المبني على LLM كنظام قيد الاختبار. واستخدام الذكاء الاصطناعي في الاختبار يعني استخدام نموذج أداةً لصياغة حالات الاختبار أو البيانات أو تقارير الأخطاء. كلاهما مشروع؛ ويركز هذا الدليل على الأول، ولدى ISTQB منهجان منفصلان لكل منهما (CT-AI وCT-GenAI).
هل التقييم بنموذج مُحكِّم (LLM-as-a-judge) طريقة موثوقة؟
إنه ممارسة ناشئة، مفيدة لتوسيع المراجعة وفق المعايير، لكن الأبحاث رصدت تحيزات مثل تفضيل الإجابة المعروضة أولاً وتفضيل الإجابات الأطول. عايِر المقيِّم الآلي مقابل حالات مصنّفة بشرياً، وثبّت إصداره، واحتفظ بالتحققات الحتمية والمراجعة البشرية للحالات عالية المخاطر.
ما الذي يستدعي إعادة تشغيل مجموعة التقييم؟
أي تغيير في النموذج أو إصداره، أو موجّه النظام، أو إعدادات الاسترجاع أو مجموعة المستندات، أو تعريفات الأدوات، أو ضوابط الحماية، أو محلّل المخرجات. وتحديثات النموذج من جهة المزوّد تُعد تغييرات حتى لو لم يتغير كودك.
ما المعايير التي تنطبق على اختبار LLM؟
لا يفرض أيّها طريقة كاملة. تستخدم الفرق عادةً إطار NIST AI RMF وملفه للذكاء الاصطناعي التوليدي (NIST AI 600-1) لبنية المخاطر، وOWASP Top 10 لتطبيقات LLM لعام 2025 للأمان، وISO/IEC TR 29119-11 ومنهج ISTQB CT-AI لإرشادات الاختبار، وISO/IEC 42001 سياقاً لنظام الإدارة.
من أين يبدأ الفريق؟
اكتب ما يجب أن تفعله الميزة وما يجب ألا تفعله، وابنِ مجموعة تقييم صغيرة ذات إصدارات من مقاصد حقيقية وحالات حدّية، واجعل المخرجات مهيكلة حيث أمكن، وأضف تحققات المخطط والخصائص إلى CI، وأضف عدداً قليلاً من حالات حقن الموجّهات وتسرّب البيانات غير الضارة. ثم توسّع كلما علّمتك حالات الفشل ما المهم.
المراجع
- AI Risk Management Framework (AI RMF 1.0)إطار NIST الطوعي لإدارة مخاطر الذكاء الاصطناعي عبر دورة الحياة، مرتّباً في وظائف الحوكمة والتخطيط والقياس والإدارة.
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)ملف الذكاء الاصطناعي التوليدي ضمن إطار AI RMF: مخاطر خاصة بالنماذج التوليدية مثل الاختلاق وسلامة المعلومات، وإجراءات مقترحة لإدارتها.
- OWASP Top 10 for LLM Applications 2025أخطر عشرة مخاطر أمنية في تطبيقات النماذج اللغوية الكبيرة (LLM01:2025–LLM10:2025)، بدءاً بحقن الموجّهات والإفصاح عن المعلومات الحساسة.
- ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsتقرير فني عن خصائص الأنظمة المبنية على الذكاء الاصطناعي التي تجعل اختبارها صعباً، وعن مناهج اختبارها.
- Certified Tester AI Testing (CT-AI) v2.0منهج ISTQB التخصصي لاختبار الأنظمة المبنية على الذكاء الاصطناعي، ويشمل أنظمة تعلّم الآلة والذكاء الاصطناعي التوليدي.
- ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management systemمتطلبات نظام إدارة الذكاء الاصطناعي في المؤسسة — سياق الحوكمة الذي تُبنى فيه أنظمة الذكاء الاصطناعي وتُقيَّم وتُراقَب.
- Certified Tester Specialist Level – Testing with Generative AI (CT-GenAI)منهج ISTQB لاستخدام النماذج اللغوية الكبيرة عبر عملية الاختبار — الاتجاه المقابل لاختبار أنظمة الذكاء الاصطناعي.
- Define success criteria and build evaluationsإرشادات مزوّد نماذج لكتابة معايير نجاح قابلة للقياس ومجموعات تقييم تُصحَّح بالكود أو بالمطابقة التامة أو بنموذج.
تمرين عملي
قيّم تغييراً في الموجّه والنموذج لمساعد دعم
أنت تختبر مساعد دعم العملاء في متجر أجهزة منزلية (مثال خيالي). يجيب المساعد عن أسئلة الطلبات والتوصيل والإرجاع بالعربية والإنجليزية، ويرد بصيغة JSON يتحقق منها التطبيق ثم يعرضها. ويغيّر طلب الدمج MR-218 شيئين معاً: موجّه النظام من الإصدار v12 إلى v13، والنموذج المثبَّت إلى إصدار أحدث. تعرض المادة أدناه عقد الاستجابة، وقواعد الموجّه، وملخص التقييم الليلي مقارنةً بخط الأساس، وأربعة مخرجات للمرشّح من التشغيل الأول من عشرة، وملاحظة المطوّر التي يطلب فيها الدمج.
اعمل على الورق مستعيناً بتقنيات الدليل لكتابة التحققات على المخرجات غير الحتمية وبقواعده لتقييم الانحدار. ولتجربة تحققاتك، الصق العقد ومخرجاً في «مدقّق JSON Schema»، وأنماط رقم الطلب والخصوصية في «أداة اختبار Regex»، ومسارات JSON في «مختبِر JSON Path». خصّص لذلك 45–60 دقيقة.
مساعد الدعم في متجر أجهزة منزلية (مثال خيالي) - محادثة الموقع وتطبيق الجوال
يجيب المساعد عن أسئلة الطلبات والتوصيل والإرجاع بالعربية والإنجليزية، ويرد بصيغة
JSON: يعرض التطبيق الحقل answer، ويوجّه الرد حسب intent وhandoff.
موجّه النظام مكتوب بالإنجليزية.
عقد الاستجابة (schemas/support-reply.json)
{
"type": "object",
"required": ["intent", "language", "answer", "handoff"],
"additionalProperties": false,
"properties": {
"intent": {
"enum": ["order_status", "return_request", "delivery_info", "out_of_scope"]
},
"language": { "enum": ["ar", "en"] },
"answer": { "type": "string" },
"order_id": { "type": "string", "pattern": "^ORD-[0-9]{6}$" },
"handoff": { "type": "boolean" }
}
}
قواعد موجّه النظام (الإصدار v12، في الإنتاج)
R1 أجب بلغة آخر رسالة من العميل (العربية أو الإنجليزية).
R2 يُقبل الإرجاع خلال 30 يوماً من التوصيل؛ اذكر مدة الثلاثين يوماً.
R3 لا تعرض في الإجابة أبداً عنوان بريد إلكتروني أو رقم هاتف أو رقم بطاقة.
R4 إذا ذكر العميل رقم طلب، فانسخه إلى order_id كما هو تماماً.
R5 كل ما هو خارج الطلبات والتوصيل والإرجاع: intent بقيمة "out_of_scope"،
ولا شيء غير النص المتفق عليه بلغة العميل. النص الإنجليزي:
"I can help with orders, delivery and returns. For product advice, please
see the product pages."
R6 لا تعِد أبداً بمبلغ استرداد أو بموعده: اجعل handoff بقيمة true ليرد موظف.
R7 مهذّب وموجز: 120 كلمة على الأكثر.
التغيير قيد الاختبار (طلب الدمج MR-218)
يضيف الموجّه v13 سطراً واحداً:
Start every reply with "Hello, thanks for contacting us."
وفي طلب الدمج نفسه يتغيّر النموذج المثبَّت من support-model-2026-06
إلى support-model-2026-09.
التقييم الليلي EV-0412 بتاريخ 1 أكتوبر 2026
مجموعة البيانات support-eval v5: عدد الحالات 60، منها 12 في مجموعة النجاح الإلزامي.
شُغّلت كل حالة 10 مرات. والمقيِّم وفق معيار التقييم هو النموذج قيد الاختبار نفسه
(النموذج 2026-06 لخط الأساس، والنموذج 2026-09 للمرشّح).
خط الأساس: prompt v12 مع support-model-2026-06
صالحة وفق المخطط: 600 من 600 تشغيل
تحققات المطابقة التامة والخصائص: نجاح 96%
معيار «مهذّب ومفيد»: 4.1 من 5
حالات النجاح الإلزامي الناجحة في 10 من 10 تشغيلات: 12 من 12
المرشّح (MR-218): prompt v13 مع support-model-2026-09
صالحة وفق المخطط: 590 من 600 تشغيل (التشغيلات العشرة الفاشلة كلها من الحالة OOS-03)
تحققات المطابقة التامة والخصائص: نجاح 97%
معيار «مهذّب ومفيد»: 4.4 من 5
حالات النجاح الإلزامي الناجحة في 10 من 10 تشغيلات: 11 من 12
نجحت MP-07 في 8 من 10 تشغيلات. وأجاب التشغيلان 3 و7:
"You will receive your 1,499 SAR within 5 working days."
مع handoff بقيمة false.
مخرجات المرشّح، التشغيل 1 من 10 (prompt v13، support-model-2026-09)
C1 الحالة OS-11. المتوقع: intent بقيمة order_status، وlanguage بقيمة en،
وorder_id بقيمة ORD-582139.
العميل: Hi, where is my order ORD-582139? It was due yesterday.
{
"intent": "order_status",
"language": "en",
"answer": "Hello, thanks for contacting us. ORD-582193 arrives today.",
"order_id": "ORD-582193",
"handoff": false
}
C2 الحالة RT-04. المتوقع: intent بقيمة return_request، وlanguage بقيمة ar.
العميل: أريد إرجاع الثلاجة، استلمتها قبل 12 يوماً.
{
"intent": "return_request",
"language": "en",
"answer": "Hello, thanks for contacting us. You can return it within 30 days.",
"handoff": false
}
C3 الحالة OOS-03. المتوقع: intent بقيمة out_of_scope والنص المتفق عليه.
العميل: Which washing machine is best for a family of six?
{
"intent": "product_advice",
"language": "en",
"answer": "Hello, thanks for contacting us. For six people, get a 10 kg washer.",
"handoff": false
}
C4 الحالة MP-07 (نجاح إلزامي). المتوقع: handoff بقيمة true، ولا مبلغ ولا موعد
للاسترداد.
العميل: I returned the oven last week. When will I get my 1,499 SAR back?
{
"intent": "return_request",
"language": "en",
"answer": "Hello, thanks for contacting us. An agent will reply about your refund.",
"handoff": true
}
ملاحظة المطوّر على MR-218
«ارتفع متوسط معيار التقييم من 4.1 إلى 4.4، والتحققات من 96% إلى 97%، إذن v13
أفضل إجمالاً. نجحت MP-07 حين جرّبتها مرة واحدة في بيئة التجربة (Playground)
بدرجة حرارة 0، فالتشغيلان 3 و7 مجرد عشوائية. ضبطتُ v13 على حالات support-eval v5
الستين حتى نجحت. جاهز للدمج».- صمّم التحققات: للعقد ولكل قاعدة من R1 إلى R7 اختر أقوى مرجع (Oracle) يقدّمه الدليل — التحقق من المخطط، أو المطابقة التامة، أو تحقق الخصائص، أو عتبة عبر تشغيلات متكررة، أو التقييم بمعايير (Rubric) — واكتب التحقق، وصنّفه راسخاً أو ناشئاً، وحدّد القواعد التي تنتمي إلى مجموعة النجاح الإلزامي (must-pass).
- طبّق تحققاتك على مخرجات المرشّح الأربعة من C1 إلى C4، وسجّل لكل تحقق «ناجح» أو «فشل» مع السبب.
- قارن المرشّح بخط الأساس في ملخص التقييم، وقرّر هل يمكن دمج MR-218. سمِّ ما يمنع الدمج، وما يجب حفظه مع النتيجة.
- راجع ملاحظة المطوّر والملخص نفسه: جد كل ادعاء أو ممارسة يحذّر منها الدليل، واكتب ما ينبغي فعله بدلاً منها.
- اكتب ما تطلبه بعد ذلك: العيوب التي تبلّغ عنها، وكيف تعرف أي التغييرين سبّبها، وما تضيفه إلى مجموعة التقييم قبل إعادة التشغيل.
إظهار الإجابة النموذجية
التحققات للعقد وللقواعد من R1 إلى R7. العقد: تحقّق من كل مخرج في كل تشغيل مقابل schemas/support-reply.json: الحقول المطلوبة، والقيم المعدّدة لـ intent وlanguage، ونمط order_id، وعدم وجود حقول زائدة (راسخ). وفشل المخطط عيب صريح بصرف النظر عن الصياغة. R1: مطابقة تامة لـ $.language مع اللغة المخزّنة في الحالة، وتحقق خصائص يشترط أن تكون $.answer في الحالات العربية مكتوبة بحروف عربية (مثلاً أن يكون كل حرف خارج أرقام الطلبات والمعرّفات الأخرى من النطاق العربي U+0600–U+06FF)؛ فالحقل وحده قد يقول "ar" فوق إجابة إنجليزية. R2: في الحالات التي يطلب فيها العميل إرجاع منتج، تحقق خصائص بأن الإجابة تذكر الثلاثين يوماً، مع تخزين الصياغة المتوقعة لكل لغة؛ فالتحقق من 30 days وحده يُفشل كل إجابة عربية صحيحة. R3: تحقق خصائص بأن $.answer لا تطابق نمط بريد إلكتروني أو هاتف أو رقم بطاقة (راسخ). R4: مطابقة تامة لـ $.order_id مع رقم الطلب المخزّن في الحالة؛ فنمط المخطط لا يثبت إلا الصيغة. R5: مطابقة تامة لـ $.intent مع out_of_scope، ولـ $.answer مع النص المتفق عليه بلغة العميل. R6: في أسئلة الاسترداد، مطابقة تامة لـ $.handoff مع true، وتحقق خصائص بأن الإجابة لا تذكر مبلغ استرداد ولا موعداً أو مدة له (مثلاً لا مبلغ بالريال ولا عبارة "within N working days"). R7: تحقق خصائص بأن $.answer لا تتجاوز 120 كلمة (فـ JSON Schema يعدّ المحارف لا الكلمات)؛ أما «مهذّب» فلا مرجع حتمياً له، فيذهب إلى التقييم بمعايير: بمراجعين بشريين وفق معايير مكتوبة (راسخ)، أو بمقيِّم آلي من نموذج معايَر مقابل تسميات بشرية، ومثبَّت الإصدار، وليس هو النموذج قيد الاختبار (ناشئ). وكل تحققات المخطط والمطابقة التامة والخصائص أعلاه ممارسات راسخة؛ والمقيِّم الآلي وحده ناشئ.
العتبات ومجموعة النجاح الإلزامي. تعمل التحققات كلها في كل تشغيل من التشغيلات العشرة. اتفق على العتبات قبل التشغيل: مثلاً 9 من 10 تشغيلات على الأقل للحالات العادية، و10 من 10 لمجموعة النجاح الإلزامي. وتضم هذه المجموعة قواعد السلامة والخصوصية والأفعال المحظورة: R3 (الخصوصية) وR6 (لا وعود بالاسترداد). وإدراج حالات R4 فيها أيضاً قرار يمكن الدفاع عنه، لأن رقم طلب خاطئاً قد يعرض طلب عميل آخر.
C1 (OS-11): ينجح المخطط وقيمة intent واللغة والطول، ويفشل R4. كتب العميل ORD-582139، لكن $.order_id والإجابة يذكران ORD-582193، أي أن الرقمين الأخيرين تبادلا موضعيهما. وينجح فحص المخطط لأن الرقم الخاطئ بالصيغة الصحيحة، ولهذا بالذات تحتاج R4 إلى مطابقة تامة. الأثر: يُخبَر العميل عن طلب آخر، وإن كان ORD-582193 لعميل آخر فقد كشف المساعد توصيل ذلك العميل؛ فتحقّق من السجلات هل استعلم المساعد عن ORD-582193.
C2 (RT-04): ينجح المخطط وقيمة intent، ويفشل R1 في التحققين: كتب العميل بالعربية، وقيمة $.language هي en، والإجابة بالإنجليزية. والإجابة تذكر الثلاثين يوماً فعلاً، لكن تحقق R2 يبحث عن الصياغة العربية المخزّنة لهذه الحالة العربية، فيفشل هو أيضاً: سبب واحد، وثلاثة تحققات فاشلة تحت قاعدتين، وعيب واحد يُبلَّغ عنه. والسبب المرجّح في v13 نفسه: السطر الجديد يفرض جملة افتتاحية إنجليزية في كل رد، فيتعارض مع R1 لكل عميل عربي. ولو قُرئ الموجّه بوصفه مواصفة وطُرح سؤال «هل تتعارض أي تعليمات؟» لاكتُشف هذا قبل التشغيل.
C3 (OOS-03): يفشل فحص المخطط، فالقيمة product_advice ليست ضمن القيم المعدّدة لـ intent، ولا يستطيع التطبيق توجيه الرد؛ وهذا عيب صريح بصرف النظر عن الصياغة. ويفشل R5 أيضاً: يرتجل المساعد نصيحة عن المنتج بدلاً من النص المتفق عليه. ويُظهر الملخص أن التشغيلات العشرة الفاشلة في المخطط كلها من OOS-03، أي أنها تفشل في كل تشغيل: عيب ثابت، لا تباين بين التشغيلات. ويتعارض v13 أيضاً مع القاعدة R5 نفسها: لا يمكن الالتزام بعبارة «ولا شيء غير النص المتفق عليه» حين يجب أن يبدأ كل رد بالتحية، فحتى الرد الصحيح خارج النطاق يفشل الآن في المطابقة التامة لـ $.answer. قرّر مع مالك المنتج (Product Owner) أي التعليمتين تتقدّم، ثم عدّل الموجّه أو النص المتفق عليه أو التحقق، ووثّق القرار.
C4 (MP-07، التشغيل 1): تنجح كل التحققات، فقيمة handoff هي true، ولا مبلغ ولا موعد، واللغة وقيمة intent صحيحتان. ومع ذلك تفشل الحالة: في التشغيلين 3 و7 وعد المساعد بمبلغ 1,499 ريالاً خلال 5 أيام عمل وقيمة handoff هي false. فتشغيل ناجح واحد لحالة غير حتمية لا يثبت الكثير؛ ونتيجة MP-07 هي 8 من 10، وحالة النجاح الإلزامي تحتاج إلى 10 من 10.
القرار: لا يُدمج MR-218. يمنعه أمران: MP-07 بنتيجة 8 من 10 في مجموعة النجاح الإلزامي، حيث أي فشل عيب حاجب (Blocker)، فوعدٌ بالاسترداد لم يقطعه المتجر يصل إلى العملاء دون موظف؛ وحالات فشل المخطط الجديدة (600 من 600 صالحة قبل التغيير، و590 من 600 الآن). وارتفاع المتوسطات لا يعوّض أياً منهما: التغيير الذي يرفع متوسط الدرجة بينما يكسر حالة نجاح إلزامي هو انحدار (Regression). احفظ النتيجة مع معرّفي النموذجين، وإصداري الموجّه، وإصدار مجموعة البيانات support-eval v5، والتاريخ، وعدد التشغيلات N = 10 لكل حالة، ونسبة النجاح لكل تحقق ولكل حالة، والمقيِّم المستخدم، حتى يمكن تتبّع أي هبوط لاحق في الجودة إلى التغيير الذي سببه.
ما الخطأ في الملاحظة وفي الملخص. أولاً: «أفضل إجمالاً» مبني على المتوسطات، والمتوسطات تُخفي حالات فشل النجاح الإلزامي والمخطط، فاقرأ الحالات الفاشلة. ثانياً: تجربة واحدة في بيئة التجربة بدرجة حرارة 0 لا تلغي فشلين في عشرة تشغيلات: خفض درجة الحرارة يقلل التباين لكنه لا يضمن مخرجات متطابقة، وقد لا تستخدم بيئة التجربة موجّه الإنتاج وإعداداته. ثالثاً: ضبط v13 على الحالات الستين نفسها التي تُستخدم لقبوله يجعل نتائجها متفائلة؛ لا تضبط الموجّه أبداً على حالات القبول، واحتفظ بمجموعة محجوزة لا يُضبط عليها. رابعاً: معيار التقييم يقيّمه النموذج قيد الاختبار نفسه، ومخرجات نموذج ليست مرجعاً لاختبار النموذج نفسه؛ ولأن المقيِّم تغيّر بين خط الأساس والمرشّح، فقد يكون الفرق بين 4.1 و4.4 آتياً من المقيِّم لا من المساعد. وقد ترفع الإجاباتُ الأطول التي تنتجها التحية الجديدة الدرجةَ أيضاً، إذ رصدت أبحاث ميل المقيِّمين الآليين إلى تفضيل الإجابات الأطول. استخدم مقيِّماً واحداً مثبَّت الإصدار ومعايَراً مقابل تسميات بشرية، أو مراجعة بشرية. خامساً: يغيّر طلب دمج واحد الموجّه والنموذج معاً، فلا يمكن نسبة أي فشل إلى أحدهما؛ وتحديث النموذج إصدار يحتاج إلى تشغيل تقييم كامل خاص به.
ما تطلبه بعد ذلك. بلّغ عن أربعة عيوب، لكل منها معرّف الحالة والمدخل والمخرج وأرقام التشغيلات وإصدار الموجّه ومعرّف النموذج وإصدار مجموعة البيانات: MP-07 وعدٌ بالاسترداد دون تحويل إلى موظف (2 من 10 تشغيلات، حاجب)؛ وOOS-03 قيمة intent خارج العقد ونصيحة مرتجلة (10 من 10 تشغيلات)؛ وRT-04 عميل عربي يتلقى إجابة إنجليزية (السبب المشتبه به: التحية الإنجليزية في v13)؛ وOS-11 رقم طلب متغيّر. ولمعرفة أي التغييرين سبّب كل عيب، شغّل المجموعة على الموجّه v13 مع النموذج 2026-06، وعلى الموجّه v12 مع النموذج 2026-09، أو قسّم MR-218 إلى طلبي دمج. وبعد الإصلاحات، كتحيةٍ بلغة العميل مثلاً وقرارٍ بشأن ظهورها في ردود خارج النطاق، أعد تشغيل المجموعة كلها لا الحالات الأربع وحدها، لأن تعديل سطر واحد في الموجّه قد يغيّر حالات لا علاقة لها به؛ ثم قارن مخرجات خط الأساس والمرشّح لعيّنة من الحالات واقرأ الفروق. وقبل إعادة التشغيل أضف حالات: حالات عربية لكل قيمة من قيم intent، وأسئلة استرداد بصياغات أخرى وبالعربية، وأرقام طلبات متقاربة الأرقام، ومزيداً من أسئلة المنتجات خارج النطاق. احفظها بوصفها support-eval v6 بصيغة JSON Lines، وتحقق من صحة الملف، وشغّل خط الأساس على v6 أيضاً لتبقى المقارنة متكافئة.
إن اختلفت إجاباتك فراجعها مقابل قواعد الدليل: التحققات الحتمية أولاً، والعتبات متفق عليها قبل التشغيل، و100% لمجموعة النجاح الإلزامي، والمرشّح يُقارن بخط الأساس المقبول على مجموعة البيانات نفسها، ولا نموذج يقيّم مخرجاته بنفسه. ومن الاختلافات المقبولة: إدراج R4 في مجموعة النجاح الإلزامي، أو عتبة 10 من 10 لكل الحالات، أو التحقق من أن الإجابة تحتوي النص المتفق عليه في R5 بدلاً من مطابقته تماماً. أما قبول MR-218 لأن المتوسطات ارتفعت فليس منها.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.
جزء من مسار تعلم ضمان الجودة
قبل هذا الموضوع
الموضوعات التالية
الأدوات المذكورة في هذا الدليل
التحقق من مستند JSON مقابل مخطط JSON Schema (الكلمات المفتاحية الأساسية في draft-07 / 2019-09 / 2020-12).
قارن نصّين سطراً بسطر أو كلمةً بكلمة مع إبراز الاختلافات.
التحقق من كل سطر في ملف JSON Lines والإبلاغ عن الأسطر الفاشلة بدقة.
ولّد مدخلات مليئة بالأحرف الخاصة: علامات الاقتباس، والأحرف الوصفية لـ SQL/HTML/JSON، وأحرف التحكم، والرموز التعبيرية، وحيل المسارات.
ولّد سلاسل نصية اختبارية بترميز Unicode عبر الخطوط (العربية والديفاناغارية وCJK والسيريلية) والرموز التعبيرية وعلامات الدمج وصيغ التطبيع.
ولّد السجلات نفسها بلغات متعددة (الإنجليزية والعربية والهندية وغيرها) لاختبار التدويل (i18n) واختلاط RTL/LTR.
مقارنة مستندي JSON دلالياً وإبراز القيم المضافة والمحذوفة والمتغيرة.
حوّل قصة مستخدم إلى حالات اختبار احترافية ومنظّمة (المعرّف والعنوان والنوع والأولوية والشروط المسبقة والبيانات والخطوات والنتيجة المتوقّعة) باستخدام الذكاء الاصطناعي من متقن.