ثمانية أشهر داخل طابور الدمج (merge queue) في GitHub Actions تعلمك شيئاً لن تعلمك إياه مصفوفات مقارنة الميزات أبداً. يمكن لإطار عمل أن يقدم خمسين مقياساً، ولوحات تحكم رائعة، واقتباسات من مختبرات بحثية مرموقة. ولكن إذا كان يعيق عملية النشر الخاصة بك لأن درجة "vibe check" انحرفت من 0.72 إلى 0.68 مقابل نفس الكود تماماً، فهو أسوأ من عديم الفائدة؛ بل يصبح تهديداً فعلياً لسرعة إصداراتك (shipping velocity).
هذا هو المعيار الذي تفتقده معظم ملخصات تقييم نماذج اللغة الكبيرة (LLM). فهي تعد القدرات، لكنها نادراً ما تطرح السؤال الوحيد الذي يهم في طابور الدمج: هل ينجح هذا الفحص ويفشل بنفس الطريقة تماماً في كل مرة يتم تشغيله فيها؟
تعلمت هذا من خلال القيام بالعمل الشاق والمزعج. قمت بربط ستة أطر عمل مفتوحة المصدر لتقييم LLM في خط أنابيب CI حقيقي. عملت هذه الأطر مقابل طلبات سحب (pull requests) حية في بيئة الإنتاج لمدة ثمانية أشهر. استحق اثنان منها البقاء كحراس للبوابة (gatekeepers)، بينما تم خفض رتبة البقية إلى لوحات تحكم استشارية، أو نقلهم إلى مهام ليلية (nightly jobs)، أو إزالتهم تماماً. كان الدرس قاسياً ومكلفاً: الهيكل الحتمي (deterministic structure) يتفوق على الجودة الاحتمالية (probabilistic quality) عندما تكون حارساً للفرع الرئيسي (main branch).
المهمة الحقيقية لبوابة الدمج
بوابة الـ CI ليست بيئة بحثية، بل هي حارس أمن (bouncer). غرضها الكامل هو النظر في تغيير معين والإجابة بنعم أو لا. نعم، يمكن لطلب السحب (PR) هذا الانضمام إلى الفرع الرئيسي. لا، لا يمكنه ذلك. يجب أن تصل هذه الإجابة في ثوانٍ، وبتكلفة زهيدة، وألا تتغير بأثر رجعي أبداً. إذا أعدت تشغيل نفس خط الأنابيب مقابل نفس الالتزام (commit) في يوم ثلاثاء هادئ ويوم جمعة مزدحم، يجب أن تكون النتيجة متطابقة.
هنا تتعثر معظم أطر عمل تقييم LLM. فقد تم بناؤها بواسطة علماء بيانات ومن أجل علماء البيانات؛ حيث تركز على التحليل، والاستكشاف، والتقييم الدقيق. أما طابور الدمج فيركز على القرارات الثنائية، والسرعة، وانعدام عدم الاستقرار (zero flakiness). وهذان الهدفان لا يتداخلان إلا جزئياً.
لماذا يؤدي أسلوب LLM-as-Judge إلى تعطيل الطابور
الأدوات التي فشلت في اختباري اشتركت في خطيئة تصميم واحدة: الاعتماد المفرط على استدعاءات LLM-as-judge كآلية أساسية للبوابة.
يطلب أمر (prompt) الـ LLM-as-judge من النموذج تقييم مخرج ما على مقياس من واحد إلى عشرة، أو اختيار الأفضل من بين استجابتين، أو تقييم الصحة الواقعية. هذا النهج قوي لفهم اتجاهات الجودة، لكنه بمثابة سم لعملية فحص CI التي تعيق الدمج. يمكن لنفس المدخلات أن تنتج درجات مختلفة في أيام مختلفة لأن درجة الحرارة (temperature)، وإصدار النموذج، وتنسيق الأمر (prompt formatting) كلها عوامل تسبب ضجيجاً (noise). وعندما ترتبط تلك الدرجة بعتبة محددة (hard threshold) ورمز خروج (exit code) صارم، يتوقف طابورك بسبب "أشباح".
تتوالى الإخفاقات بسرعة. فالفحص غير الحتمي (nondeterministic check) يؤدي إلى تراكم الطلبات في الطابور. يتعلم المهندسون إعادة المحاولة حتى تظهر النتيجة بشكل إيجابي، مما يدرب الفريق على تجاهل عمليات البناء (builds) الفاشلة. كما تتراكم تكاليف الرموز (tokens) لأن كل إعادة محاولة تستهلك المزيد من رصيد الـ API. والأسوأ من ذلك كله، أن الإشارة تصبح بلا معنى؛ فعملية البناء الفاشلة يجب أن تعني "لقد تسببت في خطأ برمجى"، ولكن إذا كانت تعني "نموذج الحكم استيقظ بمزاج انتقادي اليوم"، فإن الثقة تتآكل.
ما الذي تفعله الأدوات الناجحة بشكل مختلف
صمدت Promptfoo و DeepEval لأنهما تعاملان الفحوصات الحتمية كعناصر أساسية (first-class citizens)، وتتعاملان مع درجات حكم الـ LLM كإشارات ثانوية غير معطلة. فهما تدركان أن البوابة تحتاج إلى رمز خروج (exit code)، وليس إلى رقم عشري (floating-point number) يحمل رأياً.
Promptfoo، الصادر بموجب رخصة MIT، مصمم لواجهة السطر البرمجي (command line). يقوم بتشغيل تأكيدات (assertions) مثل مطابقة التعبيرات النمطية (regex matches)، والتحقق من مخطط JSON (JSON schema validation)، وفحوصات الاحتواء (contains checks)، ومقارنات النصوص الدقيقة. هذه ليست أموراً معقدة، بل هي مجرد أوامر grep و jq مطورة. وهذا هو بالضبط سبب نجاحها في الـ CI. فالتعبير النمطي إما أن يتطابق أو لا يتطابق، ومخطط JSON إما أن يتم التحقق منه أو يطلق خطأً. تعيد Promptfoo رموز خروج Unix القياسية، لذا تفهم GitHub Actions بشكل طبيعي متى يجب إيقاف الدمج. كما أنها مستقلة عن لغة البرمجة (language-agnostic) لأنها تعمل كأداة CLI. لست بحاجة لتثبيت بيئة Python داخل مستودع خدمة Node.js لمجرد التحقق من المخرجات.
DeepEval، المرخص بموجب Apache 2.0، هو الخيار الأمثل لفرق Python. يتكامل تماماً مثل pytest؛ حيث تكتب الاختبارات بصيغة مألوفة، ويؤدي الفشل إلى إيقاف مجموعة الاختبارات بشكل طبيعي. توفر DeepEval قائمة ضخمة من المقاييس، ولكن التفصيل الحاسم هو ضرورة استخدامها بحذر. اعتمد على المقاييس الحتمية أو الاستدلالية (heuristic metrics) للبوابات. وإذا استخدمت G-Eval أو غيرها من أدوات التقييم القائمة على الحكم، فقم بتغليفها في مولدات تقارير غير معطلة بدلاً من استخدام تأكيدات صارمة (hard asserts). عند استخدامها بهذه الطريقة، تمنحك DeepEval سلاسة أطر عمل الاختبار دون عدم استقرار دفاتر الأبحاث (research notebooks).
أين تقع الأطر الأربعة الأخرى
أطر العمل الأربعة التي لم تصمد كبوابات لا تزال ذات قيمة، لكنها ببساطة تنتمي إلى مكان آخر في سلسلة أدواتك (toolchain).
Future AGI (Apache 2.0) يوفر أكثر من خمسين مقياساً ويستهدف الفرق التي تبني SDKs مخصصة. المقاييس شاملة، لكن المشكلة تكمن في أن الأداة تتطلب منك كتابة "harness" خاص بك لتشغيلها في طابور CI. في سياق الأبحاث، تعد هذه مقايضة معقولة. أما في طابور الدمج (merge queue)، فإن كل طبقة من التوصيلات المخصصة تمثل مصدراً جديداً لعدم الاستقرار. إنها محرك تقييم قادر، لكنها ليست "حارس بوابة" جاهزاً.
تتفوق RAGAS (Apache 2.0) في قياس جودة التوليد المعزز بالاسترجاع (RAG). مقاييس "الأمانة" (faithfulness) و"صلة الإجابة" (answer relevance) مفيدة حقاً لفهم أداء قاعدة المعرفة بمرور الوقت. لسوء الحظ، تعتمد هذه المقاييس بشكل كبير على حكام LLM. إنها ممتازة لمهام الجودة الليلية التي تنشر الاتجاهات على Slack، لكنها ضعيفة جداً كحارس لطلبات السحب (pull requests). انقل RAGAS إلى خط أنابيب التحليل المجدول الخاص بك، وليس إلى بوابات منع الدمج.
تحمل Arize Phoenix ترخيص Elastic License 2.0 وتقف عند تقاطع مختلف تماماً. فهي تربط التتبع الموزع (distributed tracing) بالتقييم، مما يمنحك قدرة على الملاحظة (observability) لمعرفة سبب تصرف النموذج بطريقة معينة. ستحتاج إلى هذه الأداة عند تصحيح حادث في بيئة الإنتاج أو تتبع "هلوسة" وصولاً إلى جزء استرجاع سيئ. لكنك لن ترغب في استخدام أداة تتبع لتقرر ما إذا كان يمكن دمج فرع ميزة (feature branch) لمطور مبتدئ. بنيتها مصممة للاستبصار، وليس للبوابات الثنائية (binary gates).
يرث MLflow Evaluate (Apache 2.0) عراقتة من تتبع التجارب. إنه أداة ثقيلة؛ فإدراجها في صورة CI خفيفة يضيف وقت بدء التشغيل والاعتمادات التي تبطئ كل مهمة. إذا كان لابد من استخدامه داخل خط أنابيب، فالتزم بمقاييسه الاستدلالية (heuristic metrics) للفحوصات الهيكلية. وحتى في هذه الحالة، ستكون في صراع مع التصميم الأساسي للإطار. MLflow يريد تسجيل عمليات التشغيل ومقارنة التجارب عبر الأسابيع، بينما يريد طابور الدمج حكماً في أقل من دقيقة.
قواعد عملية لعمليات الـ Gating
إذا لم تستفد شيئاً آخر من هذه التجربة، فاستفد من هذه القواعد الثلاث.
أولاً، اعتمد على الهيكل، لا على "الانطباع" (vibe). يمكنك فرض أن يكون المخرج بتنسيق JSON صالح، أو التأكد من احتوائه على المفاتيح المطلوبة، أو فرض أن ينتمي ملصق التصنيف إلى enum مسموح به. هذه الفحوصات سريعة، رخيصة، وحتمية (deterministic). لا يمكنك فرض أن يكون الملخص "ودوداً" أو أن تكون إعادة الكتابة "إبداعية" بشكل موثوق. هذه الصفات مكانها المراجعة البشرية أو التقييم الدوري للمجموعات، وليس البوابات المؤتمتة.
ثانياً، إذا تغيرت النتيجة مع مدخلات لم تتغير، فقم بخفض رتبتها فوراً. قم بتشغيل مجموعة التقييم الخاصة بك مرتين على نفس المنتج (artifact) تماماً. إذا تغير أي مقياس من "ناجح" إلى "راسب"، فقد فقد حقه في منع الدمج. قم بترقيته إلى لوحة معلومات استشارية حيث يكون التباين متوقعاً ومقبولاً.
ثالثاً، احترم رمز الخروج (exit code). تقرير HTML جميل مع شريط أحمر لا يوقف عملية الدمج، لكن رمز الخروج غير الصفر (nonzero exit code) يفعل ذلك. يجب أن تتحدث أداة التقييم الخاصة بك اللغة الأصلية لمنصة CI الخاصة بك. المخرجات القياسية (Standard out) للبشر، أما رموز الخروج فهي للآلات.
الخلاصة
ما زلنا في المراحل الأولى من اكتشاف كيفية اختبار التطبيقات المدعومة بـ LLM. الإغراء يكمن في معاملة التقييم كمعايير تصحيح بشرية: دقيقة، وسياقية، وذاتية قليلاً. هذا ينجح في الأوراق البحثية، لكنه ينهار في طابور الدمج.
بعد ثمانية أشهر من حركة مرور الإنتاج، أصبح خط الأنابيب الخاص بي يشغل الآن Promptfoo للتأكيدات الهيكلية وتأكيدات المخطط (schema assertions) عبر الخدمات، وDeepEval لفحوصات السلوك من جانب Python التي تترجم بوضوح إلى حالات النجاح والفشل. كل شيء آخر يرسل تقاريره إلى لوحات المعلومات الليلية. الطابور مستقر، والإشارات واضحة، والفريق أصبح يثق في "البناء الأحمر" (red build) مرة أخرى.
أنت لا تحتاج إلى المزيد من المقاييس عند بوابتك. أنت بحاجة إلى مقاييس أقل تقول الحقيقة في كل مرة.
بناءً على الاختبارات الأصلية والمقال المشترك على Dev.to. لمزيد من المناقشات حول بناء أنظمة ذكاء اصطناعي موثوقة، انضم إلى مجتمع GyaanSetu على Telegram.