بناء جرد وسجل لنماذج الذكاء الاصطناعي

لا يمكنك حَوكمة ما لا يمكنك حصره. جرد النماذج (model inventory) هو السجل المرجعي لكل نموذج يعمل داخل مؤسستك: ما هو، ومَن يملكه، وما الذي يقرره، وما الذي يُغذّيه. أما السجل (registry) فهو المخزن الهندسي الكامن تحته، الذي يحتفظ بالمُخرجات الفنية (artefacts) المُدارة بالإصدارات وبالنَّسَب (lineage). وهما معًا يُمكّنان إدارة المخاطر والتدقيق من الإجابة عن سؤال محدد بشأن أي قرار بعينه، لا عن سؤال عام حول سياستك.

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

ما الذي يدخل فعليًا في الجرد

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

لكل نموذج نُسجّل، كحد أدنى:

• مُعرِّف ثابت يلازم النموذج عبر البيئات ولا يُعاد استخدامه أبدًا، بحيث يمكن ربط قرار مُسجَّل في مارس بالسجل الذي أنتجه تحديدًا
• المالك والمسؤول التنفيذي المُساءَل، بأسماء أفراد بعينهم لا صندوق بريد فريق، لأن مراجعات الأهمية النسبية وعمليات الاعتماد تقع على شخص
• الغرض وصلاحية اتخاذ القرار، أي ماذا يُخرج النموذج، وهل يراجعه إنسان، وأين يقع بين المعالجة الآلية الكاملة (straight-through processing) والاستخدام الاستشاري
• مستوى الأهمية النسبية (materiality tier)، الذي يحدد مقدار الإشراف الذي يحظى به النموذج؛ فالنموذج الذي يرفض الائتمان آليًا لا يُحكم بالطريقة نفسها التي يُحكم بها نموذج يُحرّر تعليقات داخلية
• المُدخلات ومصادر البيانات، بما في ذلك ما إذا كانت أي سمة (feature) تحمل قيودًا زمنية لحظية (point-in-time)، لأن النموذج الذي يُغذّى حقلًا لم يكن معروفًا وقت اتخاذ القرار هو حادثة تسرُّب بيانات (leakage) تنتظر الاكتشاف
• المورّد والاستضافة، بما في ذلك ما إذا كانت الأوزان (weights) قابعة خلف واجهة برمجة تطبيقات لا يمكنك فحصها، وما إذا كان المزوّد يحتفظ بحق تحديث النموذج دون إشعار

مستوى الأهمية النسبية هو الحقل الذي يستحق مكانه. فبدونه، يبدو كل نموذج على القدر نفسه من الأهمية، فتغرق عملية الحَوكمة أو تُمرّر كل شيء دون تدقيق. ومعه، يمكنك تبرير أين أنفقت جهدك في التحقق (validation).

السجل هو حيث تعيش الهندسة

يقول الجرد إن نموذجًا موجود وله أهمية. أما السجل فيقول ما هو النموذج فعليًا، بمستوى من التفصيل يستطيع مهندس أن يُعيد إنتاجه معه. هذا هو المخزن الذي يكتب فيه مسار التكامل المستمر (CI pipeline) وتقرأ منه طبقة الخدمة (serving layer).

يحمل سجلٌّ مُفيد المُخرَج المُدرَّب (artefact)، ومجموعات بيانات التدريب والتقييم الدقيقة مُعرَّفةً بالبصمة الرقمية (hash)، وتعريفات السمات (features) التي يعتمد عليها، ومجموعة التقييم (eval set) والدرجات التي حققها ذلك الإصدار من النموذج، وبالنسبة لنموذج لغوي كبير (LLM) المُوجِّه (prompt) وإعدادات الاسترجاع (retrieval) الخاضعة لإدارة الإصدارات. الهدف هو إعادة البناء. فإذا نازع أحدهم قرارًا صدر الربع الماضي، ينبغي أن تكون قادرًا على تسمية إصدار النموذج، والبيانات كما كانت عليه آنذاك، والمُوجِّه، ونتائج التقييم التي سمحت بإطلاقه، دون تنقيب أثري عبر خمسة أنظمة.

النَّسَب (lineage) هو الجزء الذي تتجاوزه الفرق أكثر ما تتجاوزه وتحتاجه أكثر ما تحتاجه. فحين يتغير تعريف عمود في مخزن السمات (feature store)، تريد أن تعرف كل نموذج استهلكه. وحين يتبيّن أن مجموعة تدريب تحتوي على حقل مُسرَّب، تريد قائمة النماذج التي دُرِّبت عليها ما دام هناك وقت لسحبها، قبل أن تكتشفها جهة رقابية أولًا. لا يكون هذا الاستعلام رخيصًا إلا إذا سُجِّل النَّسَب وقت التسجيل بدلًا من إعادة بنائه لاحقًا من سِجل الالتزامات (commit history).

البيانات الوصفية التي تجعل السجل يستحق الاحتفاظ به

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

الملكية وحالة دورة الحياة: هل النموذج قيد التطوير، أم في وضع الظل (shadow)، أم في الإنتاج، أم مُتقاعد؟ النموذج في وضع النشر الظلّي (shadow deployment) الذي يُسجّل بالتوازي مع نموذج بطل (champion) له توقعات مراقبة مختلفة عن النموذج الذي يحمل قرارات حية، وينبغي أن يجعل السجل هذا التمييز قابلًا للقراءة آليًا لا معرفةً شفهية متوارثة.

المراقبة وحالة الانحراف (drift): تاريخ آخر تقييم، والأداء الحالي مقابل النتائج المُتحققة، وما إذا كانت مجموعة التقييم القائمة لا تزال خضراء. هنا يكفّ الجرد عن كونه أرشيفًا ساكنًا ويبدأ في أن يكون عرضًا تشغيليًا. فالنموذج الذي ظلت مجموعة تقييمه حمراء لستة أسابيع ينبغي أن يظهر أحمر في المكان نفسه الذي تبحث فيه عن مالكه.

روابط الأدلة: تقرير التحقق (validation report)، وبطاقة النموذج (model card)، وسجل الاعتماد، وميزانية الإيجابيات الكاذبة (false-positive budget) المُتفق عليها مع جهة العمل. لا يحتاج الجرد إلى الاحتفاظ بهذه المستندات، لكن عليه أن يحتفظ بمؤشرات موثوقة إليها، بحيث يكون العثور على نموذج والعثور على مسار تدقيقه (audit trail) الإجراء ذاته.

الجزء الصعب ليس تصميم هذه الحقول. بل الحفاظ على صدقها. الجرد الذي يُدار يدويًا يتقادم خلال ربع سنة. لذا يجب أن تقع خطوة التسجيل داخل مسار النشر (deployment path): النموذج الذي لم يُسجَّل ولم يُصنَّف ولم يُعطَ مالكًا لا يحصل على بيانات اعتماد الخدمة (serving credential). ثم تطابق السجل مع ما يتلقى الطلبات فعليًا وفق جدول زمني، وتعامل أي نموذج يخدم الطلبات دون سجل مطابق بوصفه حادثة، لا ثغرة إجراءات ورقية. تلك المطابقة هي الغاية كلها. فالسجل لا يستحق الاحتفاظ به إلا إذا كانت الإجابة عن سؤال “هل هذا كل شيء؟” إجابةً تستطيع الدفاع عنها حين يتحقق منها شخص مستقل مقابل بيئة الإنتاج.