نقض قرارات الوكلاء البرمجية يهدد سلامة العمليات: بوابة الإثبات تحد من اجتهاد المراجع

اعتادت الفرق الهندسية التي تبني منظومات الوكلاء متعددي النماذج أن تضيف وكيل مراجعة مستقل لتدقيق مخرجات الوكيل الأساسي وتصحيح أخطائه قبل التنفيذ، ظنا أن مضاعفة العيون البرمجية ترفع دقة القرار تلقائيا. غير أن ورقة بحثية أودعها الباحث فؤاد علي عبر أرخايف، تحت عنوان «Who May Overrule the Agent? Evidence-Gated Authority in LLM Review Institutions»، برهنت على أن وكيل التدقيق لا يكتفي بإصلاح العثرات، بل يعمد في كثير من الأحيان إلى إفساد قرارات كانت صحيحة بالأساس واستبدالها باجتهادات خاطئة.

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

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

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

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

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

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