قبل تشغيل تجربة الذكاء الاصطناعي فعلياً، أطلب من الفريق إجراء هذه الاختبارات

يهمني ما تفعله خدمة الذكاء الاصطناعي بعد سحب مستند من مصادرها أكثر مما يهمني أن تجيب مرة أخرى عن السؤال نفسه الذي نجح في العرض التجريبي.

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

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

في أعمال ألتايوس لتكامل الأنظمة، أفضّل توثيق هذا الفرق في سجل قبول. أمام كل متطلب، نضع الاختبار ونتيجته والمسؤول عنه وما سنفعله إذا أخفق.

ابدأ بسير عمل محدد

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

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

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

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

حوّل التوقعات إلى اختبارات

هذا نموذج أولي لسجل أعدّله مع المسؤول عن الخدمة. هو مثال عملي، وليس معياراً موحداً لإطلاق كل الأنظمة.

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

اجتياز مجموعة الاختبارات لا يثبت سلامة كل طلب سيأتي مستقبلاً. لكنه يوضح ما اختُبر، ويوفر أساساً للقرار التالي.

قيّم النظام باللغات التي سيخدم بها المستخدمين

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

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

فالإجابة السليمة لغوياً التي توجّه الطلب إلى جهة موافقة خاطئة تظل نتيجة فاشلة. ويجب تسجيل ذلك حتى لو كانت جودة اللغة جيدة.

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

أجرِ تغييراً بعد أول اختبار ناجح

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

وثّق الإصدارات المستخدمة. وإلا فقد ينتهي الفريق بتقرير نجاح يخص إعداداً لم يعد هو الإعداد الجاري.

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

لهذا أربط التصميم المعماري بالتشغيل. في ألتايوس لتكامل الأنظمة، أريد مشاركة من سيتسلمون النظام في مرحلة تسمح لهم بالتأثير في تصميمه.

حدّد من يتخذ القرار النهائي

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

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

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

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

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