التنفيذ والتسليم
اكتب اختبارات القبول قبل ما تشوف أي عرض ذكاء اصطناعي
اختبارات قبول للذكاء الاصطناعي تنكتب قبل أي عرض: وش يعتبر نجاحًا، والحالات اللي يخفيها العرض، ومن يعتمد النتيجة.
داخل الدليل6 أقسام
العرض يوضح الحالات اللي اختارها اللي بناه. اختبارات القبول تحدد مسبقًا وش الحالات اللي تنحسب، ووش المخرج اللي ينجح، ووش الفشل اللي يوقف الاختبار، عشان ما يحط العرض امتحانه بنفسه، سواء كان من مورّد أو من فريقك. اكتب المخرج المتوقع والأخطاء غير المقبولة قبل اختيار أمثلة العرض. التجربة المقترحة هنا تختبر توجيه طلبات خدمة افتراضية بدون إرسال رسائل أو تعديل سجلات عمل. نجاح الاختبار يدعم القرار المحدود فقط، مو الجاهزية الإنتاجية أو الامتثال أو العائد المالي. وفي طريقتنا هذي الاختبارات تنكتب في القسم السابع من مخطط حل الذكاء الاصطناعي، «القبول والنطاق وعرض السعر»، قبل أي بناء.
حدد القرار والأشياء خارج النطاق
استخدم قرارًا مثل: هل المرشح يوجّه نص الطلب المصرح به للطوابير المتفق عليها ويتوقف عند الطلب المجهول؟ سمِّ الطوابير وصيغة المخرج والمسؤول والإجراءات المستبعدة. لا تجمع دقة التوجيه والتنبؤ واستخراج المستندات ومحادثة العملاء في درجة واحدة. دليل تقييم OpenAI يبدأ بهدف محدد وبيانات مناسبة له.1
ثبّت مجموعة تقييم تم التحقق منها بشكل مستقل
جهّز أمثلة بإجابات متوقعة معتمدة، تشمل الصياغة العربية والمدخلات الناقصة والتعارض والطلبات خارج النطاق. افصل أمثلة ضبط المرشح عن مجموعة تقييم مستقلة. سجّل إصدار البيانات وطريقة اختيارها والاستبعادات. الحالات المصطنعة تختبر قواعد معلنة، لكنها ما تثبت الأداء على الاستخدام الحقيقي. لا تحذف الحالات الصعبة بصمت بعد ظهور النتائج. إرشادات OWASP في LLM01:2025 توصي باختبارات هجومية تتعامل مع النموذج كمستخدم غير موثوق، فضمّن محاولات لتجاوز التعليمات في مجموعة التقييم المستقلة.2
استخدم مثال توجيه فيه مسار توقف حقيقي
السياسة الافتراضية: طلب الفاتورة الواضح يروح للفوترة، وطلب كلمة مرور الحساب الواضح يروح للدعم، والطلب الملتبس يرجع needs_clarificationيحتاج توضيح. المدخل «أحتاج نسخة من الفاتورة» متوقع يرجع billingالفوترة. والمدخل «عندي مشكلة» يرجع needs_clarificationيحتاج توضيح، مو طابورًا مخمنًا. الطلب اللي يجمع القصدين يتبع قاعدة معلنة مستقلة. هذي نتائج متوقعة مقترحة، مو نتائج تشغيل نموذج.
الشكلسجل اختبار القبول
قبل ما تعتمد أي عرض من المورّد، وقّع هذا السجل: كل حالة، والنتيجة المتوقعة، ووش يعتبر فشل. «نكمل» بس إذا نجحت كل الحالات، و«نعدّل» إذا الخلل معروف وينصلح، و«نوقف» إذا الفشل ما ينحل داخل النطاق.
سجل اختبار القبولراسخ للسيارات · توجيه مركز الاتصال v0.3
لازم تنجح الحالات الأربع كلها
| الحالة | المدخل | المتوقع | يفشل لما | نتيجة التشغيل |
|---|---|---|---|---|
| 01طلب صريح | أبغى أحجز موعد صيانة لسيارتي | مواعيد الصيانة | يروح لأي قائمة ثانية | |
| 02طلب غير واضح | عندي مشكلة | يسأل وش المطلوب | يخمّن قائمة | |
| 03طلبين في رسالة وحدة | الطلبين في نفس الرسالة | قاعدة الطلبات المختلطة المعلنة | يختار سياسة من عنده بصمت | |
| 04انتهاء المهلة أو رد JSON غير صالح | فشل محاكى | ما فيه توجيه ولا إجراء، والفشل مسجّل | أي إجراء على العمل |
مثال توضيحيمجموعة راسخ القابضة افتراضية
القرارنكمل بس إذا نجحت الحالات الأربع. فشل حالة وحدة يعني نعدّل ونعيد التشغيل، مو نكمل جزئياً.
قِس أنواع الفشل، مو الدرجة الإجمالية فقط
في الاختبار المقترح، افصل التوجيه الصحيح للطلبات القابلة للإجابة عن التوجيه الخاطئ لحالات التوقف، والمخرجات غير الصالحة، ومحاولات الإجراء غير المصرح. وضّح المقامات والفئات الفارغة؛ عدم وجود حالات توقف يعني إن السلوك ما تقيّم. حدد حدود القبول حسب العمل قبل التشغيل. المتوسط العالي ما يخفي إجراءً غير مصرح وغير مقبول؛ وبند OWASP رقم LLM06:2025 يعرّف الصلاحية المفرطة بأنها الثغرة اللي تخلي إجراءات ضارة تنفَّذ بسبب مخرجات غير متوقعة أو ملتبسة أو متلاعب فيها من النموذج.3 قارن بقاعدة توجيه ثابتة بسيطة تحت نفس الظروف.
خل التشغيل قابلًا للتكرار والتغييرات واضحة
سجّل إصدار المرشح وإعداداته والبيانات والمخرج والوقت والتكلفة لكل حالة، بما فيها الفاشلة والمنتهية بمهلة. الطلب المكرر ممكن يختلف، فحدد سياسة التكرار قبل الاختبار واذكر حدودها. OpenAI يوصي باستمرار التقييم مع تغير التطبيق.1 هذا مرجع للعملية، مو اشتراط لاستخدام نماذجه أو منصة Evals أو أدواته.
وثّق قرار الاستمرار أو التعديل أو التوقف
يعتمد النتيجة صاحب العمل اللي بيشغّل سير العمل ومعه مراجع تقني، مو الفريق اللي بنى العرض. استخدم قرار الاستمرار للمرحلة المحددة التالية فقط إذا نجحت معايير القبول المعلنة مسبقًا. التعديل لخلل مشخص وقابل للإصلاح مع إعادة اختبار محدودة. التوقف إذا المهمة أو الوصول للبيانات أو الفشل غير المقبول ما ينحل ضمن النطاق. أرفق الأسئلة المفتوحة ومسؤوليها. وكمرجع سعودي، مبادئ سدايا لأخلاقيات الذكاء الاصطناعي (2025) تطلب في مرحلة البناء والتحقق اختبار سلوك النظام في الحالات الشاذة والسيناريوهات القصوى (الصفحة 23).4 إطار NIST إرشاد اختياري لإدارة المخاطر؛ لا هو ولا نجاح اختبار التوجيه يعطي اعتمادًا قانونيًا أو خطة تشغيل إنتاجية.5
أداة عملية لاتخاذ القرار
حالات قبول مقترحة لسجل الاختبار
- طلب فاتورة ←
billingالفوترة؛ قارن الطابور بالإجابة المتوقعة بالضبط. - طلب ملتبس ←
needs_clarificationيحتاج توضيح؛ اختلاق طابور يعتبر فشلًا. - قصدان مختلفان ← القاعدة المعلنة لهذي الحالة؛ بدون اختلاق سياسة.
- انتهاء مهلة أو JSON غير صالح ← بدون توجيه أو إجراء عمل؛ سجّل الفشل والتعافي المسموح.
سياسة التوجيه والحالات أمثلة افتراضية ما تم تشغيلها. الدليل ما يثبت حدود قبول أو تكلفة أو أداء إنتاجي.
المصادر
مراجعة الأدلة ·
مصادر أصلية: جهات تنظيمية ومعايير ووثائق رسمية
- ممارسات التقييم: الأهداف والبيانات والتقييم المستمرOpenAIتاريخ الاطلاع: 6 نوفمبر 2026
- LLM01:2025 — حقن التعليماتOWASP Gen AI Security Projectتاريخ الاطلاع: 6 نوفمبر 2026
- LLM06:2025 — الصلاحية المفرطةOWASP Gen AI Security Projectتاريخ الاطلاع: 6 نوفمبر 2026
- مبادئ أخلاقيات الذكاء الاصطناعي — إصدار 2025سداياتاريخ الاطلاع: 6 نوفمبر 2026مصدر حكومي سعودي رسمي
- إطار إدارة مخاطر الذكاء الاصطناعي: الاستخدام الاختياري والنطاقNISTتاريخ الاطلاع: 6 نوفمبر 2026
الأسئلة الشائعة
وش الفرق بين العرض واختبار القبول؟
العرض يوضح سلوكًا مختارًا. اختبار القبول يسجل الأداء مقابل بيانات وسياسة فشل ومعيار قرار محددة مسبقًا.
وش نسبة النجاح المطلوبة؟
حدد الحدود حسب أثر كل خطأ وقياس الوضع الحالي. الدليل ما يفرض نسبة عامة.
هل الأمثلة المصطنعة تثبت دقة الإنتاج؟
لا. تقدر تختبر حالات معلنة، لكن الأداء الفعلي يحتاج بيانات مصرح بها وتمثل الاستخدام وحدود تقييم واضحة.
وش يصير إذا فشلت التجربة؟
سجّل الفشل وقرر هل إصلاح محدد ومحدود يستحق أو توقف المرشح. لا تغير الحدود لمجرد النجاح.
أدلة مرتبطة
راجعناه في 7 نوفمبر 2026
