كيف تختبر مساعد ذكاء اصطناعي قبل الإطلاق: بناء مجموعة اختبار من حالاتك أنت، ووضع حدود النجاح، وتحديد من يعتمد الإطلاق

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

لماذا لا يُعدّ العرض التوضيحي الجيد للذكاء الاصطناعي اختبارًا؟

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

ويفتتح دليل OpenAI لأفضل ممارسات التقييم بهذه النقطة: «الذكاء الاصطناعي التوليدي متغيّر. فالنماذج تُنتج أحيانًا مخرجات مختلفة من المدخل نفسه، ما يجعل أساليب اختبار البرمجيات التقليدية غير كافية لبنى الذكاء الاصطناعي». وقد جرى الاطلاع على جميع المصادر في هذه المقالة في 4 نوفمبر 2026.

ويسمّي الدليل اختبارات إجابات النموذج evals، اختصارًا لـ evaluations، أي التقييمات. ومن الأخطاء التي يذكرها ما يسمّيه vibe-based eval، أي التقييم القائم على الانطباع: «استخدام عبارة “يبدو أنه يعمل” استراتيجيةً للتقييم، أو الانتظار حتى الإطلاق قبل تنفيذ أي evals».

نشر NIST، وهو المعهد الوطني للمعايير والتقنية في الولايات المتحدة، وثيقة Generative AI Profile في يوليو 2024 بوصفها إرشادات طوعية. وتختصر الوثيقة عبارة generative AI، أي الذكاء الاصطناعي التوليدي، إلى GAI. ومن الإجراءات التي تقترحها: «تجنّب استقراء أداء نظام GAI أو قدراته من تقييمات ضيقة وغير منهجية وقائمة على شواهد فردية».

مجموعة الاختبار تؤدي ما لا يستطيعه العرض التوضيحي: قائمة بحالات حقيقية، لكلٍّ منها الإجابة التي تتوقعها، وتُقيَّم بالطريقة نفسها بعد كل تغيير.

من أين ينبغي أن تأتي حالات الاختبار؟

من عملك أنت، وبمزيج يقارب ما سيواجهه المساعد. ويقول دليل Anthropic الخاص بتحديد معايير النجاح وبناء التقييمات لنماذج Claude: «صمّم evals تعكس توزيع المهام لديك في العالم الحقيقي».

ويضيف دليل OpenAI: «تأكّد من أن بيانات الاختبار لديك تشمل الحالات المعتادة والحالات الاستثنائية والحالات العدائية». والحالات الاستثنائية مدخلات نادرة أو مُربِكة. أما الحالات العدائية فتحاول أن تدفع المساعد إلى سلوك خاطئ. واستمدّ الحالات من المصادر التالية:

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

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

تحتوي المجموعة على بيانات حقيقية للعملاء، لذا طبّق عليها قواعد الوصول نفسها التي تطبّقها على التذاكر والمستندات التي أُخذت منها.

من يكتب الإجابات المتوقعة، وماذا تتضمن؟

يكتب خبراؤك أنت الإجابات المتوقعة، لا الشركة التي تبني المساعد. والإجابة المتوقعة، التي يسمّيها المهندسون الحقيقة المرجعية (ground truth)، هي الإجابة التي يقبلها موظف متأنٍّ. ويتوقف شكلها على طبيعة العمل:

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

ومثال OpenAI الخاص بالأسئلة على المستندات يبني بيانات الاختبار جزئيًا من «إجابات صحيحة مُثبّتة مسبقًا عن أسئلة أعدّها خبراء المجال». وفي شركتك، هؤلاء الخبراء هم قادة فرق الدعم ومالكو السياسات.

يتحقق خبير ثانٍ من كل إجابة. وحين يختلف شخصان متأنّيان، فالأرجح أن السياسة التي تحكم الحالة غير واضحة، وسيجد المساعد الذي يقرؤها صعوبة أيضًا. ويُدرج دليل Anthropic مثل هذه الحالات ضمن أمثلته على الحالات الاستثنائية: «حالات اختبار ملتبسة يصعب فيها حتى على البشر التوصل إلى توافق في التقييم». ويقرر مالك السياسة، وتُصلح أنت المستند مع حالة الاختبار.

ومع كل حالة، سجّل نوع سؤالها وإصدار المستند الذي تستند إليه. وحين تتغير سياسة ما، حدّث تلك الحالات، وإلا فستحكم المجموعة بإخفاق إجابات صارت صحيحة الآن.

كيف نحدد حدود النجاح؟

حدّ النجاح هو أدنى نتيجة تقبلها قبل الإطلاق. حدّد حدًّا لكل نوع من الأسئلة ولكل نوع من الأخطاء، لأن حدّ نجاح واحدًا للمساعد كله يُخفي الكثير. ويلاحظ دليل Anthropic: «تحتاج معظم حالات الاستخدام إلى تقييم متعدد الأبعاد وفق عدة معايير للنجاح».

صنّف كل حالة أخفقت تحت نوع واحد من الأخطاء:

• معلومة خاطئة: تذكر الإجابة شيئًا غير صحيح. وتسمّي وثيقة NIST ذلك التلفيق (confabulation): «إنتاج محتوى يُقدَّم بثقة لكنه خاطئ أو زائف (ويُعرف في الاستخدام الدارج بـ“الهلوسات” أو “الاختلاقات”)، وقد يُضلِّل المستخدمين أو يخدعهم».
• إجابة ناقصة: كانت الإجابة في المستندات، لكن المساعد قال إنه لا يعرف أو أغفل معلومة أساسية
• مصدر خاطئ: تستشهد الإجابة بمستند لا يدعمها، أو بإصدار قديم منه
• إجابة غير آمنة: أخفق المساعد في حالة من حالات الخط الأحمر
• الشكل والنبرة: الوقائع صحيحة، لكن الرد مقتضب أكثر من اللازم أو بتنسيق خاطئ

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

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

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

من يقيّم إجابات المساعد، أو ما الذي يقيّمها؟

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

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

النموذج الذي يُستخدم مقيِّمًا له عادات معروفة. فدليل OpenAI يُدرج «انحياز الموضع (ترتيب الإجابات)، وانحياز الإسهاب (تفضيل الإجابات الأطول)» ضمن التحديات التي يذكرها. أي إن ترتيب الإجابات قد يؤثر في الحكم، وقد تفوز الإجابة الأطول لطولها وحده. ومن نصائح الدليل: «استخدم التغذية الراجعة البشرية لمعايرة التقييم الآلي». وعمليًا، يقيّم خبراؤك عيّنةً يقيّمها النموذج أيضًا، وتُصلح قائمة التحقق حيثما اختلف الطرفان.

وفي المسودات، يفيد الاختبار الأعمى. اخلط مسودات المساعد بردود موظفيك على التذاكر نفسها، ودع المراجعين يقيّمونها دون أن يعرفوا مصدر كل منها. ويذكر دليل OpenAI «اختبارًا عشوائيًا أعمى» مثالًا على التقييم على يد البشر.

ولأن كل إجابة متوقعة تسمّي مصدرها، يمكنك أيضًا فحص الاسترجاع، أي خطوة البحث التي تعثر على المقاطع التي يقرؤها النموذج. فإن لم يعثر البحث قط على المقطع الصحيح، فأصلح البحث لا النموذج. وتقترح وثيقة NIST فحصًا ذا صلة: «راجِع المصادر والاستشهادات في مخرجات نظام GAI وتحقّق منها في أثناء قياس المخاطر قبل النشر وفي أنشطة المراقبة المستمرة».

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

متى نعيد تشغيل مجموعة الاختبار؟

بعد كل تغيير، وقبل أن يصل إلى العملاء. ويعني ذلك إصدارًا جديدًا من النموذج، أو مستندات معدّلة، أو إعدادات بحث جديدة، أو موجّهًا جديدًا، أي التعليمات المكتوبة التي يتبعها النموذج. ويجعل دليل OpenAI ذلك خطوة قائمة بذاتها: «أعِدّ التقييم المستمر (CE) لتشغيل evals مع كل تغيير».

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

• لا تخفق أي حالة من حالات الخط الأحمر
• لا يهبط أي نوع من الأسئلة دون حدّ نجاحه
• يكون شخصٌ قد قرأ كل إخفاق جديد ويعرف سببه

احتفظ بنتائج كل تشغيل، مع إصدارات النموذج والموجّه والمستندات التي اختُبرت.

ويوقف المزوّدون النماذج أيضًا وفق جداولهم الزمنية الخاصة. فصفحة الإيقاف لدى OpenAI تنص على إشعار مسبق لا يقل عن ستة أشهر للنماذج المتاحة للعموم، ما لم تستدعِ اعتبارات السلامة أو الامتثال جدولًا زمنيًا أسرع. وقد تُوقَف نماذج المعاينة (preview) بإشعار أقصر بكثير. أما صفحة Anthropic فتنص على إشعار مسبق لا يقل عن 60 يومًا للنماذج المطروحة للعموم، وتحذّر: «ستفشل الطلبات الموجّهة إلى النماذج التي تجاوزت تاريخ إيقافها».

وهذا الإشعار هو مهلتك لتشغيل المجموعة على النموذج البديل، وإصلاح ما يخفق، واعتماد النتائج من جديد. فخطّط لذلك وخصّص له ميزانية منذ البداية.

ما الذي نتحقق منه بعد الإطلاق؟

كل أسبوع، يقيّم خبيرٌ عيّنة عشوائية من الإجابات والمسودات الحقيقية بقائمة التحقق نفسها، لأن الحركة الحية تأتي بحالات لم يفكر فيها أحد. وهذه مراجعة بشرية لعيّنة، لا لكل إجابة.

يقول إطار NIST لإدارة مخاطر الذكاء الاصطناعي (AI Risk Management Framework)، وهو إرشادات طوعية صدرت في يناير 2023: «ينبغي اختبار أنظمة الذكاء الاصطناعي قبل نشرها، وبانتظام أثناء تشغيلها». ويقول NIST إن نسخة منقّحة منه قيد الإعداد.

امنح الموظفين والعملاء طريقة سهلة للإبلاغ عن الإجابة السيئة، وحوّل كل إخفاق مؤكَّد إلى حالة اختبار جديدة. وتقول إحدى نصائح OpenAI: «سجّل أثناء التطوير كي تتمكن من التنقيب في سجلاتك عن حالات تقييم جيدة».

من يعتمد الإطلاق، وبناءً على أي أدلة؟

يعتمد الإطلاقَ مالكُ العملية: رئيس قسم الدعم في حالة مساعد الدعم، مثلًا. ويعتمد قسم الامتثال أو القسم القانوني حالات الخط الأحمر. أما الجهة المنفّذة فتعرض النتائج، لكنها لا توافق على عملها بنفسها.

ويصف إطار NIST فصلًا مشابهًا في التقييمات: «يشارك في التقييمات والتحديثات المنتظمة خبراء داخليون لم يعملوا مطوّرين مباشرين للنظام، و/أو مقيّمون مستقلون». ثم يبدأ الجزء المسمّى Manage (الإدارة) من الإطار بقرار بشأن نظام الذكاء الاصطناعي: «ما إذا كان ينبغي المضيّ في تطويره أو نشره».

وينبغي أن يُظهر ملف الأدلة لهذا القرار ما يلي:

• كيف بُنيت المجموعة، وحجمها لكل نوع من الأسئلة، ومن كتب الإجابات
• الإصدارات التي اختُبرت: النموذج، والموجّه، والمستندات، وإعدادات البحث
• النتائج لكل نوع من الأسئلة ولكل نوع من الأخطاء، مقارنةً بحدود نجاح متفق عليها مسبقًا
• كل حالة من حالات الخط الأحمر ونتيجتها
• كل إخفاق، بعد قراءته وشرح سببه
• نتائج فريقك على الحالات نفسها
• ما لا يتولاه المساعد، ومن يراجع العيّنة الأسبوعية بعد الإطلاق

يمكن أن يكون الاعتماد جزئيًا. فيمكن أن يدخل المساعد الخدمة في أنواع الأسئلة التي نجحت، بينما تذهب البقية إلى شخص إلى أن تنجح هي أيضًا.

من يملك مجموعة الاختبار؟

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

احفظها على وحدة تخزين تتحكم فيها، لأن أدوات المورّدين تُوقَف هي الأخرى. فصفحة الإيقاف لدى OpenAI تقول إن الشركة أبلغت المطوّرين الذين يستخدمون منصة Evals لديها، في 3 يونيو 2026، بأن المنتج في طور الإيقاف. وتذكر الصفحة 31 أكتوبر 2026 موعدًا لتصبح evals الحالية للقراءة فقط، و30 نوفمبر 2026 موعدًا للإغلاق المقرر للوحة التحكم وواجهة API.

سمِّ مالكًا للمجموعة من جهتك، لديه الوقت لإضافة الحالات وتحديث الإجابات حين تتغير السياسات.

ماذا نسأل المورّد أو الشركة التي ستبني المساعد؟

حين يذكر مورّد رقمًا للدقة، فاسأل على ماذا قِيس. وتقترح وثيقة NIST: «قيّم الادعاءات المتعلقة بقدرات النموذج باستخدام أساليب مُتحقَّق منها تجريبيًا». ثم اطرح هذه الأسئلة على كل مورّد أو شركة في قائمتك:

• هل ستختبرون على حالاتنا، بإجابات متوقعة كتبها موظفونا؟
• أي جزء من مجموعة الاختبار لن تطّلعوا عليه قبل التشغيل النهائي؟
• ما حدود النجاح التي تقترحونها لكل نوع من الأسئلة ولكل نوع من الأخطاء، ولماذا؟
• كيف تقيّمون النص الحر، وكيف تحققتم من النموذج المقيِّم لديكم بمقارنته بتقييم البشر؟
• هل نستطيع إعادة تشغيل المجموعة كاملةً بأنفسنا بعد كل تغيير، من دونكم؟
• من يدفع تكلفة إعادة الاختبار حين يوقف مزوّد النموذج النموذجَ؟
• هل سنتسلّم الحالات وقوائم التحقق والسكربتات وسجل النتائج في النهاية؟

أين موقع amBrain من ذلك؟

تنشر amBrain هذه المدونة. وعن منتجها الخاص تقول: «منتجنا الخاص، shyash.ai، يعمل بوكلاء ذكاء اصطناعي يبحثون ويكتبون ويتحققون ويقيسون انطلاقًا من ذاكرة مشتركة واحدة لوقائع الشركة. ويوافق شخص على كل ما يصدر».

وعن عملها المنفَّذ للعملاء مع نموذج لغوي، تقول amBrain: «أوصلنا تكاملًا مع LLM إلى الإنتاج داخل محيط FinTech لدى أحد العملاء: استخراج إشعارات غير مهيكلة من الوسطاء ومنصات التداول وتطبيعها — إجراءات الشركات، وتغييرات الأدوات المالية والهامش — إلى سجلات مهيكلة يستهلكها نظام التداول».

هذه المقالة ليست دراسة حالة، ولا تصف أي عمل لعميل غير ما ورد في ذلك السطر، وهو لا يقول كيف اختُبر المشروع. ولا شيء هنا يدّعي أن amBrain بنت مجموعات الاختبار أو حدود النجاح أو خطوات الاعتماد الموصوفة أعلاه، أو يقول كيف يُختبر shyash.ai. والأمثلة عامة، وليست مأخوذة من عمل amBrain.

الجهات المذكورة هنا مقتبسة من صفحاتها المنشورة. ولا تدّعي المقالة أي علاقة بين amBrain وأي منها، ولا تذكر أسعارًا أو جداول زمنية لـ amBrain.

تبني amBrain البرمجيات منذ عام 2019. وعن طريقة عملها مع العملاء تقول: «ثلاث صيغ: تنفيذ كامل، أو فريق مخصّص، أو مهندسون مدمجون في فريقك». أما في الملكية فسطرها هو: «يحتفظ العميل بالملكية الكاملة للمنتج وللكود، باستثناء مكوّناتنا القابلة لإعادة الاستخدام». واطلب قائمة هذه المكوّنات بالأسماء قبل أن توقّع.

وهذه المقالة ليست استشارة قانونية كذلك. اسأل محاميك كيف ينطبق قانون الخصوصية على مجموعات الاختبار المبنية من بيانات العملاء. وإن كانت amBrain في قائمتك المختصرة، فاطرح عليها الأسئلة نفسها التي تطرحها على أي شركة أخرى.