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

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

كيفية عمل SENAR

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

ضمن مهمة واحدة، يعتمد SENAR على عدة عناصر إلزامية:

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

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

ما تفحصه البوابات

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

"تم تخطي الخطوة ليس من قبل الوكيل، بل من قبلي."

على الإخراج، تعمل QG-2 — بوابة تمنع إغلاق المهمة حتى يتم التحقق من النتيجة مقابل الوعود المقطوعة على الإدخال. في المقالة، يبرز المؤلف ثلاث فحوصات إلزامية: تأكيد كل معيار قبول بواسطة اختبار أو فحص يدوي أو قطعة؛ تثبيت جميع التصحيحات اليدوية بعد عمل الوكيل؛ تحديث ذاكرة المشروع إذا كشفت المهمة عن حالة حدية جديدة أو خصوصية البنية الأساسية. مثل هذا الوضع ضروري ليس من أجل البيروقراطية، بل لكي لا يكرر الوكيل في المهمة التالية نفس الأخطاء بسبب التصحيحات الصامتة التي أدخلها الإنسان.

المقاييس والحدود

يكرس قسم منفصل من المقالة للمقاييس التي يستخدمها SENAR كإشارات لحالة العملية. يوضح FPSR نسبة المهام التي تم حلها من المحاولة الأولى؛ MIR — كم مرة كان التصحيح اليدوي ضرورياً بعد الوكيل؛ يقيس DER الفروع الطريق المسدود وخسائر الوقت؛ ERR تعكس المهام التي اضطرت لإصلاحها فقط بعد الإغلاق.

وفقاً لسجل عمل المؤلف، على مهام الخادم في المجال المألوف، نما FPSR تقريباً من 40% إلى 75–80%؛ انخفض MIR في مشروع Sortule من 20% إلى 5–7%، وانخفض ERR إلى حوالي 6% من 15%. وفي الوقت نفسه، يصف يوماشيف بصراحة حدود المنهجية. البوابات تساعد قليلاً حيث يكون من الصعب صياغة النتيجة: في المهام المتعلقة بـ "الشعور" بالواجهة، أو نبرة النص، أو الحدس بالمنتج. كما أنها لا تساعد عند العمل مع الخدمات الخارجية، إذا كانت وثائق الطرف الثالث تتعارض مع السلوك الفعلي لـ API. في مثل هذه الحالات، قد تحافظ العملية الرسمية على هيكل المهمة، لكنها لا تحل محل معرفة المجال والاختبار اليدوي للفرضيات والبحث المسبق عن التكامل.

ماذا يعني هذا

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