مشروع МАЯК يبني خط إنتاج QA من 58 كتلة ويلتقط 9 فخاخ من 10 في المواصفات الفنية

بنى مؤلف مشروع МАЯК خط إنتاج يقود المواصفات الفنية (ТЗ) حتى مرحلة تشغيل الاختبارات عبر 58 كتلة متخصصة. وفي اختبار على مواصفات فنية اصطناعية تضمّنت عشرة عيوب مزروعة عمدًا، التقط النظام الآلي تسعة منها. أما العيب العاشر فاكتشفه إنسان، لكن بالاعتماد على قائمة أسئلة أعدّتها الآلة. وخلال 90 ثانية أصدر النظام 26 سؤالًا لأصحاب المصلحة وحدّد 20 منطقة رمادية، ثم كتب خلال 26 دقيقة 37 سيناريو BDD.

الوثائق قبل الأزرار

يحدد اسم المشروع ترتيب العمل: نبدأ بتوضيح المتطلبات، ثم نكتب الاختبارات ونشغّلها. وتبدو السلسلة هكذا: «المواصفات الفنية → التوحيد المعياري → تصميم الاختبارات → التشغيل». وبحسب اسم المرحلة، فإن التوحيد المعياري (canonicalization) ينقل نص المتطلبات المبعثر إلى شكل منظّم موحّد، ثم يُبنى عليه تصميم الاختبارات. والمنطق واضح: الاختبارات المشتقة من مواصفات فنية غامضة ترث غموضها، ولا تفعل سوى إخفائه خلف صيغة مرتبة.

يندرج المشروع ضمن فئة متنامية من الأنظمة التي لا يعمل فيها LLM بموجّه واحد، بل عبر خط إنتاج طويل من الخطوات الضيقة. وعدد هذه الخطوات هنا 58.

بوابات الثقة بدلًا من التخمين

تكمن المشكلة الرئيسية للنماذج اللغوية في تصميم الاختبارات في ميلها إلى ملء النواقص بتفاصيل تبدو معقولة. فإذا ورد في المواصفات «يجب أن تفتح الصفحة بسرعة»، يخرج النموذج بسرعة بعبارة «لا تزيد عن 2 ثانية» ويصوغها معيار قبول. ويسدّ مؤلف МАЯК هذه الثغرة بقاعدتين:

• يستند كل معيار قبول إلى اقتباس من الوثيقة الأصلية؛ فإذا لم يوجد اقتباس فلا يوجد معيار.
• تتحول المنطقة الرمادية إلى سؤال لصاحب المصلحة، لا إلى قيمة مخمَّنة.

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

ماذا أظهر التشغيل

جرى الاختبار على مواصفات فنية اصطناعية زرع فيها المؤلف مسبقًا عشرة «أمراض». وهذه نتائجه كما وردت في الإعلان:

• التقط النظام الآلي 9 فخاخ من 10؛
• اكتشف إنسان الفخ العاشر مستعينًا بقائمة الأسئلة التي أعدّتها الآلة؛
• صيغت 26 سؤالًا لأصحاب المصلحة خلال 90 ثانية؛
• حُدّدت 20 منطقة رمادية؛
• أُنجز 37 سيناريو BDD خلال 26 دقيقة.

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

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

ما الذي يمكن تطبيقه

يمكن أخذ عدة أساليب من المشروع حتى دون نسخه بالكامل:

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

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