Auditable Acceptance of LLM-Generated Code:An Evidence-Based Testing Architecture and Multi-Source Evaluation

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

تكمن هذه المسألة في قلب دراسة جديدة من باحثين في جامعة ساوث ويست جياوتونغ، وجامعة بريستول، وجامعة سيتشوان الزراعية. لقد وضعوا نصب أعينهم بناء نظام لا يكتفي بالقول "نجح" أو "فشل"، بل ينشئ بدلاً من ذلك سجلاً مفصلاً وقابلاً للتدقيق يوضح سبب قبول قطعة من الكود، أو رفضها، أو إرسالها لمزيد من المراجعة. وقد أطلقوا على هذا النظام اسم "البنية التحتية للاختبار الذكي" (Intelligent Testing Infrastructure أو ITI). وبدلاً من معاملة توليد الكود كصندوق أسود سحري، ركز الباحثون على الواقع الفوضوي للتحقق: تسجيل أي الاختبارات تم تشغيلها بالضبط، وما الذي غطته، ومدى الثقة التي ينبغي أن تثيرها تلك الاختبارات حقاً. وتكشف أعمالهم أنه بينما يمكننا جعل الاختبارات أكثر صرامة، فإن مجرد إضافة المزيد من الاختبارات لا يجعل اختيارنا النهائي للكود أكثر أماناً بشكل تلقائي. في الواقع، تشير تجاربهم إلى أن القواعد الأكثر صرامة غالباً ما ترفض الكود الجيد بقدر ما تضبط الكود السيئ، مما يترك المخاطر الإجمالية لقبول برنامج معيب دون تغيير.

لقد نهج الباحثون هذه المشكلة من خلال تصميم سير عمل يعمل كحارس بوابة حذر. فعندما يصل كود ما، لا يخضع لفحص سريع فحسب؛ بل يتعرض لسلسلة من عمليات التحقق تحت ظروف محكومة. يسجل النظام كل تفصيل: النسخة المحددة من الكود، والأدوات المستخدمة لاختباره، والبيئة الدقيقة التي عمل فيها. والأهم من ذلك، أن النظام يميز بين ثلاث نتائج: إذا وجد الاختبار خطأً واضحاً، يتم رفض الكود؛ وإذا لم تجد الاختبارات أي خطأ ولكن الأدلة تبدو غير مكتملة أو لم تكن الاختبارات قوية بما يكفي، يتم تصعيد الكود لمزيد من التدقيق؛ وفقط إذا كانت الأدلة كاملة وإيجابية، يتم قبول الكود. تخلق هذه العملية "تجميداً للقرار" (decision freeze)، وهي لحظة يتم فيها قفل الأدلة قبل الكشف عن أي معرفة خارجية حول ما إذا كان الكود صحيحاً حقاً. وهذا يضمن أن القرار يستند فقط إلى ما كان معروفاً في ذلك الوقت، مما يجعل العملية بأكملها شفافة وقابلة للمراجعة لاحقاً.

ولمعرفة ما إذا كان هذا النهج قد نجح، أجرى الفريق نوعين متميزين من التجارب. كانت الأولى دراسة محكومة بدقة باستخدام 80 قطعة من الكود التي صممها الباحثون بأنفسهم لتتضمن أخطاءً محددة ومعروفة. اختبروا هذه القطع مقابل مجموعة أساسية من الفحوصات ثم مقابل مجموعة ثانية أكثر شمولاً. وكانت النتائج كاشفة؛ فقد ضبطت المجموعة الثانية من الاختبارات 16 قطعة من الكود السيئ التي فاتتها المجموعة الأولى، مما يثبت أن الاختبارات الأقوى يمكنها بالفعل إيجاد المزيد من الأخطاء. ومع ذلك، عندما طبق الباحثون قواعدهم الصارمة (اقبل-صعّد-ارفض)، كانت النتيجة أقل تفاؤلاً. فقد نجحت القواعد الأكثر صرامة في تقليل عدد قطع الكود السيئة التي تم قبولها، لكنها رفضت أيضاً عدداً متناسباً من قطع الكود الجيدة. والنتيجة هي أن المجموعة النهائية من الكود المقبول لا تزال تحتوي على أخطاء بنفس المعدل السابق: 50 بالمائة. بعبارة أخرى، من خلال كونهم أكثر حذراً، لم يجعلوا الدفعة النهائية من الكود أكثر أماناً، بل جعلوا الدفعة أصغر حجماً فقط.

ثم اختبر الباحثون هذا النظام على نطاق أكبر وأكثر واقعية باستخدام 200 قطعة من الكود التي ولدها نموذجان مختلفان من الذكاء الاصطناعي، وهما Qwen وDeepSeek، عبر 50 مهمة برمجة مختلفة. وهنا، أظهر النظام نوعاً مختلفاً من القيمة؛ فباستخدام استراتيجية تصعيد ذكية، تمكن النظام من الوصول إلى نفس القرارات النهائية كما لو كان قد أجرى اختباراته الأكثر تكلفة وقوة على كل قطعة من القطع الـ 200، لكنه فعل ذلك عن طريق تشغيل تلك الاختبارات الثقيلة على 132 مرشحاً فقط من أصل 200. وقد وفر هذا وقتاً وموارد حوسبية كبيرة. ومع ذلك، عندما نظروا إلى جودة الكود الذي تم قبوله، لم يكن أداء النظام أفضل من الاختيار العشوائي لنفس الحجم. لم ينجح النظام "الذكي" في اختيار كود أفضل مما قد يفعله الاختيار العشوائي؛ بل اكتفى ببساطة بتوفير المال عبر تجنب الفحوصات غير الضرورية للكود الذي كان سيئاً أو جيداً بشكل واضح.

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

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