تتحول الواجبات المتعلقة بمرحلة البناء -بموجب قانون الذكاء الاصطناعي للاتحاد الأوروبي- إلى مهام هندسية قبل وقت طويل من كتابة أي مذكرة قانونية. تركز هذه الدورة التدريبية على التزامات “المزود” (أي الواجبات الملقاة على عاتق الفريق الذي يطرح نظام الذكاء الاصطناعي للاستخدام)، وذلك لأن المهندسين وعلماء البيانات هم من يُنشئون معظم الأدلة التي تستند إليها تلك الالتزامات. وغالباً ما تغيب هذه الحقيقة عن أذهان الفرق؛ لأن العمل يبدو في ظاهره مجرد بناءٍ للميزات والخصائص، في حين أن معيار النجاح أو الفشل لاحقاً يعتمد على ما تم توثيقه واختباره والحفاظ على اتساقه عبر مختلف إصدارات النظام. إن سبب الفشل الشائع ليس سوء النية، بل هو وجود فجوة بين ما يفعله النظام فعلياً وبين ما يستطيع الفريق إثبات قيام النظام به. [المصادر][/المصادر]
لا يمكن للمزود الدفاع عن أي إصدار إلا إذا كانت عملية البناء واضحة المعالم منذ البداية. وتتحدد هذه المعالم من خلال طبيعة النظام قيد الإنشاء، والغرض منه، وقدراته (وما يعجز عنه) في بيئة التشغيل الواقعية. كما تشمل هذه المعالم البيانات المُدخلة، وآليات التحكم المرفقة بالنظام، وسجلات التشغيل المتاحة، والإجراءات التي يمكن للعنصر البشري اتخاذها عند ظهور مخرجات غير صحيحة. وتكمن أهمية النظر إلى هذه الجوانب مجتمعةً في أن اكتشاف أي عنصر مفقود عادةً ما يحدث بعد أن يكون الفريق قد أتم بالفعل مراحل التدريب والدمج والنشر. وتُقدم الخريطة أدناه تصوراً شاملاً للمجال بأكمله قبل الخوض في تفاصيل أي جزء منه على حدة. [المصادر][/المصادر]
في هذه الدورة التدريبية، لا يُعد نظام الذكاء الاصطناعي مجرد ملف نموذج أو “أمر توجيهي” (prompt) ذكي؛ بل هو المنظومة المتكاملة التي تتلقى المدخلات من عمليات العمل، وتنتج مخرجات يعتمد عليها البشر، وتتصرف بطرق تشكلها البرمجيات والبيانات والإعدادات وواجهة المستخدم المحيطة بها. ولهذا السبب، يمكن لتغيير بسيط في مسار العمل (pipeline) أن يغير تأثير النظام على أرض الواقع، حتى وإن ظلت أوزان النموذج ثابتة. [المصادر][/المصادر]
قد يظن الفريق أن الأمر يقتصر على “مجرد دمج نموذج”، لكن العنصر الخاضع للتنظيم هو النظام المجمّع بالكامل بمجرد أن يبدأ في اتخاذ قرارات أو تقديم توصيات أو إنشاء محتوى يشكل جزءاً من سير العمل. إذ تحدد مجتمعةً كل من: مهمة التدريب، ومخزن السمات (feature store)، وفهرس الاسترجاع، وضوابط الأمان (guardrails)، وقواعد المراقبة، والنصوص المكتوبة في واجهة المستخدم؛ ما يراه المستخدم وما يُسمح له بفعله لاحقاً. وإذا لم تكن هذه الأجزاء مرتبطة بإصدار وغرض محددين، فلن تتطابق عمليات الاختبار والتوثيق اللاحقة مع ما تم طرحه فعلياً للاستخدام. [المصادر][/المصادر]
عادةً ما يقع على عاتق المهندسين وعلماء البيانات اتخاذ القرارات التي تحدد الغرض المقصود من النظام ومدخلاته وحدوده، لأن هذه القرارات تُتخذ ضمن تذاكر العمل، ومجموعات البيانات، وخطط التقييم، ومراجعات الكود البرمجي. يمكن لفرق الشؤون القانونية والامتثال تفسير التشريعات، لكنهم لا يستطيعون إعادة تكوين ما رآه النموذج أثناء التدريب أو ما سمحت به واجهة المستخدم وقت اتخاذ القرار. كما يمكن لفرق المنتج تحديد الأهداف، لكنهم لا يستطيعون تعويض السجلات المفقودة أو إعادة تشغيل تجربة لم يتم تتبعها. [المصادر][/المصادر]
تبدأ عملية التسليم إلى فرق النشر والتشغيل (deployers) منذ مرحلة البناء؛ إذ يحتاج هؤلاء إلى تعليمات واضحة، وشفافية عملية في الواجهة، وآليات رقابة فعالة حتى تحت الضغط، لأن ملف سياسات (بصيغة PDF) لا يمكنه تعويض أوجه القصور في نظام يخفي حالة عدم اليقين الخاصة به أو يمنع التدخل البشري. وعندما يتعامل المطورون مع هذه الجوانب باعتبارها “أعمالاً ورقية تؤجل لما بعد”، فإنهم غالباً ما يضطرون في النهاية إلى إجراء ترقيعات للواجهة وإعادة كتابة الوثائق لتتطابق مع الواقع، وهي عملية أبطأ بكثير من التصميم الصحيح من المرة الأولى. [المصادر][/المصادر]
قبل المضي قدماً، من المفيد تحديد أنماط الفشل التي قد تكون مألوفة لديك بالفعل. [المصادر][/المصادر]