كيف تبني مسار برمجة بالذكاء الاصطناعي يمكن الوثوق به؟

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

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

ماذا نعني بمسار يمكن الوثوق به؟

لا نعني أن الوكيل لا يخطئ. نعني أن المهمة محددة، والصلاحيات معلومة، والتغيير معزول، والدليل ظاهر، والتراجع ممكن. إذا أخطأ النظام، نعرف أين أخطأ ولا نحتاج إلى تخمين ما حدث في محادثة طويلة.

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

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

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

الحقول الستة

1. النتيجة: ما الذي سيتغير للمستخدم أو للفريق؟
2. النطاق: ما الملفات أو الخدمات الداخلة، وما المستبعد صراحةً؟
3. المدخلات: ما البيانات والسياق المسموح باستخدامهما؟
4. الصلاحيات: ماذا يقرأ الوكيل ويكتب ويشغّل وينشر؟
5. القبول: ما الأدلة التي تثبت السلوك المطلوب وحالات الفشل؟
6. التوقف والتراجع: متى يتوقف، وكيف نعود إلى الحالة السابقة؟

مثال لمهمة عربية صغيرة

النتيجة: تحسين البحث عن أسماء الخدمات عند اختلاف أشكال الهمزة
النطاق:
  مسموح: lib/search.ts وملف اختبارات البحث
  مستبعد: الصلاحيات وقاعدة البيانات وواجهة النشر
المدخلات: قائمة مصطنعة من أسماء الخدمات
الصلاحيات: قراءة المستودع وكتابة الملفين المحددين وتشغيل الاختبارات
القبول:
  - تنجح أمثلة أ، إ، آ وفق سياسة التطبيع المكتوبة
  - لا تتغير الكلمة الأصلية المخزنة
  - تبقى صلاحيات النتائج كما هي
التوقف: أي تعديل خارج الملفين أو فشل في اختبار الصلاحيات
التراجع: حذف الفرع المعزول والعودة إلى الإصدار السابق

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

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

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

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

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

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

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

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

توضح HELM Arabic وورقة ORCA أن تقييم العربية يحتاج إلى مهام وبيانات متنوعة. فائدتهما هنا ليست نقل نتيجة نموذج إلى منتجك، بل تذكيرك بأن «العربية» ليست حالة اختبار واحدة. ابنِ مجموعة صغيرة تمثل جمهورك، ثم راجعها مع مختص لغوي وصاحب المجال.

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

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

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

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

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

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

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

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

حدود مهمة

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