← أحدث الأبحاث
💻 علوم الحاسوب

Code Agents under Split Specifications: An Empirical Study of Silent Failure in System Integration

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

المؤلفون الأصليون: Camilo Chacón Sartori

نُشر 2026-10-13
📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

المؤلفون الأصليون: Camilo Chacón Sartori

البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

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

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

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

كما بحثت الدراسة فيما إذا كان مجرد السماح للوكيل بطرح سؤال سيحل المشكلة. ووجد الباحث أن الإجابة تعتمد كلياً على من يستمع إليه. فعندما سُمح للنماذج الأكثر تطوراً بالطرح، كانت تسأل في كل مرة تقريباً؛ فهي لم تخمن، بل بحثت عن الحقيقة. ومع ذلك، إذا لم يكن هناك أحد للإجابة، فإن عملية الربط تتوقف ببساطة؛ يتوقف العمل، ولا يتم إنتاج أي كود. هذا نوع آخر من الفشل، لكنه يظل فشلاً. ووجد الباحث أنه لكي يعمل النظام، يجب تصميم "خط الإنتاج" (Pipeline) - وهو العملية التي تشغل الوكيل - بحيث يتم توجيه سؤال الوكيل إلى إنسان أو نظام شريك يمكنه تقديم الإجابة. فمجرد وجود قناة مفتوحة لا يكفي إذا لم يكن هناك موظفون للرد عليها.

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

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →