زاوية Anderson
الكود البشري من عام 2020 يهزم وكلاء التشفير في اختبارات الوكالة

تم اختبار أدوات التشفير مثل ChatGPT في ما يقرب من 40 ألف مباراة – وخسروا أمام كود كتبه طالب دراسات عليا قبل اختراع نماذج اللغة الكبيرة.
في دراسة جديدة من المملكة المتحدة، قام الباحثون بمواجهة وكلاء مدعومين بالكود البشري مع وكلاء تم تطويرهم باستخدام أحدث نماذج اللغة الكبيرة (LLMs)، مثل ChatGPT-5 و Claude، ووجدوا أن الوكلاء الذين تم إنشاؤهم بدون مساعدة الذكاء الاصطناعي هزمت بسهولة الإصدارات المدعومة بالذكاء الاصطناعي.
تم إنشاء كلا المجموعتين من الوكلاء من قبل أجيال مختلفة من الطلاب من مختبر الذكاء الاصطناعي في المعهد الفدرالي السويسري للتكنولوجيا في لوزان. تم تطوير وكلاء غير الذكاء الاصطناعي كجزء من الدورات الدراسية في عام 2020، قبل عامين من اختراع ChatGPT وبداية ثورة LLM، في حين تم إنشاء وكلاء جدد من قبل طلاب حاليين، بدعم من أحدث وأفضل LLMs المتاحة.
حتى مع لعب مقنعة، لم تتمكن حلول التشفير من الفوز، واحتلت المراكز الخمسة الأولى باستمرار من قبل وكلاء “نقيين”، مع هزيمة معظم وكلاء LLM (33 من أصل 40) بسهولة من قبل وكلاء أساسيين “بسيطين” جدًا، عبر 38,304 تحدي في بطولة، عبر عدد كبير من المتغيرات والظروف.
يذكر البحث ما يلي:
‘يعكس عملنا أن نماذج LLM المتقدمة يمكن أن تولد كودًا يعمل (أي خاليًا من أخطاء التركيبة النحوية)، ولكن الحل المولود ليس منافسًا لحلول التصميم البشري في أبعاد مثل التخطيط الاستراتيجي أو التحسين أو المنافسة متعددة الوكلاء.
‘لذلك، يهدف هذا العمل إلى إبراز هذا الحد الجديد في توليد الكود، ويسعى إلى تسهيل تطوير مقاييس، ومجموعات بيانات، وبرامج مفتوحة المصدر تؤكد على تركيبات الكود التي تقودها العقلانية.’
تم تصميم التحدي ليكون مشاركة إبداعية في المزادات، عبر مجموعة متنوعة من الاستراتيجيات، وتنظيم لوائح تسليم العناصر التي تم الفوز بها إلى الفائزين.
يلاحظ المؤلفون أن عددًا من المزايا تم منحها إلى LLMs، مثل التدخل في كودهم لتحسين أدائهم – وهو منحة لم يُسمح بها لكود عام 2020. على الرغم من ذلك، حتى عندما تم تزويد كود تصحيحي سيحسن بالتأكيد من نتائجهم، لم تتمكن LLMs من قبولها أو استخدامها:
‘[في] اختبارنا، حتى عندما نكشف عن حل جيد في السياق، لا تزال LLM غير قادرة على استخدامه.
‘هذا النتيجة يثير أيضًا أسئلة بحثية مستقبلية حول حدود التعلم في السياق والتحسين بمساعدة حل المشكلات في السيناريوهات المعقدة.’
تم استخدام LLMs التالية في الاختبار: GPT-5 Thinking، Gemini 2.5 Pro، Claude Opus 4.1، و DeepSeek R1*.
الورقة الجديدة هي الورقة بعنوان هل يمكن للتشفير أن يهزم طلاب الدراسات العليا؟ بطولة LLM مقابل كود بشري في التخطيط الاستراتيجي القائم على السوق، وهي تأتي من مؤلف واحد في جامعة ساوثهامبتون، ومؤلف آخر في جامعة أكسفورد ومعهد آلان تURING. سيتم إصدار مقياس الباحثين، كما يذكر المؤلفون، قريبًا.
الطريقة
يلاحظ المؤلفون أن الاختبارات التقليدية في هذا المجال تركز على تحديات ذات حلول ثنائية明حة (صحيح أو غير صحيح)، يتم التحقق منها من خلال اختبارات الوحدة. يزعمون أن هذا ليس الطريقة المثالية لاستكشاف حدود كود LLM، وبدلاً من ذلك قاموا بتصميم سيناريو تحدي أكثر تعقيدًا، مع معايير داخلية متعددة ومراحل، حيث يمكن الفوز ولكن ليس بسهولة:

مقارنة بين المناهج القائمة على اختبارات الوحدة (في الأعلى)، والسيناريو التحدي الأكثر مفتوحًا الذي صممه المؤلفون (في الأسفل باللون الأزرق). المصدر
تم استخدام مشكلة المزاد والشحن والتسليم (APDP) في دراسة المؤلفين، وهو جزئيًا بسبب توفر مجموعة من أعمال الطلاب في عام 2020 من الجامعة السويسرية؛ أعمال سعوا إلى إنشاء وكلاء أوتوماتيكيين لمهمة APDP، قبل أي khảية لدعم التطوير من خلال الذكاء الاصطناعي. لذلك كان من السهل نسبيًا أن يُطلب من الطلاب الحديثين القيام بنفس المهمة، ولكن مع توفير أدوات حالية.
سعى المؤلفون لتجنب إطارات اختبار شائعة مثل HumanEval، BigCodeBench، و WebDev Arena (من بين أخرى)، لأن هذا النوع من إجراءات الاختبار يعتبر معرضًا للتلوث البياناتي (أي الحالات التي قد يكون النظام قد تدرب على بيانات الاختبار بدلاً من احترام انقسام).
مشكلة APDP هي مشكلة لوجستية ثنائية المراحل تعتمد على المزادات العكسية و توجيه المركبات. في المرحلة الأولى، يتنافس الوكلاء للفوز بمهام التسليم من خلال تقديم عطاءات لمقدار يجب دفعها لاستكمال كل منها. العطاء المرتفع يعني خسارة المهمة؛ العطاء المنخفض قد يعني خسارة المال.
في المرحلة الثانية، يجب على كل وكيل إنشاء خطة كفؤة لاستكمال المهام التي فاز بها فقط، وتخصيصها لمركبات ذات سعات ورسوم مختلفة، تحت قيود زمنية وموارد:

في APDP، يتنافس الشركات في المزادات العكسية على مهام التسليم، ثم يضبطون مسارات المركبات لاستكمال المهام التي فازوا بها، معهدفهم تحقيق أقصى ربح.
الهدف ليس مجرد استكمال المهام، ولكن تحقيق أقصى ربح من خلال توقع الحزم من المهام التي ستعمل معًا بشكل أفضل، وتوقع استراتيجيات المنافسين الذين يحاولون القيام بنفس الشيء.
يرفع مقياس APDP صعوبة مهام توليد الكود من خلال إدخال التخطيط الاستراتيجي عبر تسلسل من المزادات التابعة، مع كل عطاء يعيد تشكيل مشهد الاختيارات المستقبلية؛ وبالتالي يتطلب من الوكلاء التفكير ليس فقط في التكاليف الفورية، ولكن في التموضع والتنسيق والنتائج طويلة الأمد.
المشكلة الأساسية للتسليم هي NP-hard، أي لا يوجد خوارزمية يمكنها العثور على الحل الأمثل في وقت معقول مع نمو عدد المهام. هذا يجعل القوة الغاشمة نهجًا غير قابل للتطبيق، ويشير إلى أن الوكلاء يجب أن يبادروا بالدقة من أجل السرعة.
السباق مستمر
قام المؤلفون بمقارنة 40 وكيلًا مدعومًا بالكود البشري مع 17 وكيلًا مدعومًا بالكود البشري في سلسلة من البطولات الفردية. كل من البطولات الـ 12 استخدمت مجموعة مختلفة من أربعة توپولوجيات شبكة، وتمت من خلال جميع اللعب ضد الجميع، مع وكلاء يواجهون كل خصم آخر مرتين: مرة واحدة يتحكمون في كل من الشركتين، مع مواصفات مركبات مختلفة.
هذا الإعداد أدى إلى 3,192 مباراة لكل بطولة، بمجموع 38,304 مباراة. في كل مباراة، تم بيع 50 مهمة تسليم، محددة بنقاط التقاط والإنزال ووزنها، وتم سحبها عشوائيًا عبر تخطيطات شبكة الطرق التي تم نمذجتها على سويسرا وفرنسا وبريطانيا العظمى وهولندا:

شبكات الطرق المبسطة المستخدمة في البطولة: بريطانيا العظمى (أعلى اليسار)، سويسرا (أعلى اليمين)، هولندا (أسفل اليسار)، وفرنسا (أسفل اليمين). تشير المربعات الزرقاء والحمراء إلى مهام التقاط والتسليم. تُظهر المثلثات الملونة المواقع الحالية لمركبات الوكلاء.
تم سحب وكلاء الطلاب من بطولة دورة دراسية في عام 2020. جاء ثمانية منهم من أفضل أداء في نهائي خروج المغلوب، وتم اختيار أربعة آخرون لاداءهم القوي ضد وكلاء الأساس في مباريات فردية.
اتبعت وكلاء الأساس استراتيجيات ثابتة. النائي حسب المسافة الإجمالية وعرض العطاء وفقًا لذلك، باستخدام مركبة واحدة فقط واهمال التجميع؛ ExpCostFixedBid قام بمحاكاة 10 مهام عشوائية، وعرض متوسط التكلفة الهامشية؛ الموضوع حسب التكلفة الهامشية الفعلية لإدراج المهمة في الجدول؛ ModelOpponent فعل الشيء نفسه ولكن أضاف تقديرًا لتكلفة المنافس، وعرض أقصى؛ و RiskSeeking خلط بين سابقة زمنية متضائلة مع تقدير التكلفة الحي، وعرض أعلى من الاثنين.
تمت إضافة 40 وكيلًا مدعومًا بالكود البشري باستخدام (الذكاء الاصطناعي المذكور أعلاه) GPT-5 Thinking، Claude Opus 4.1، Gemini 2.5 Pro، و DeepSeek R1. تم توجيه كل نموذج بخمسة استراتيجيات مختلفة، تم تطبيقها مرتين لكل نموذج.
استخدمت استراتيجيتان عطاءات ثابتة مكتوبة من قبل مؤلفين مختلفين، في حين سألت استراتيجية الثالثة النموذج عن إعادة النظر في وتعديل إخراجها الخاص؛ واستخدمت استراتيجية أخرى نقدًا وتعديلًا من قبل نموذج آخر. واستخدمت الاستراتيجية النهائية GPT-4 لتحليل جميع النهج السابقة الأربعة لصياغة عطاء جديد.
عكس العطاء الأساسي المهمة الأصلية للطالب، واصفًا بيئة التسليم وواصفًا النموذج لتقديم عطاءات وتخطيط لتحقيق أقصى ربح، دون الاعتماد على أساليب معقدة.
تم اختبار جميع وكلاء LLM في كل من اللعب الذاتي وبيئات البطولة حتى تم إصلاح جميع الأخطاء المرئية. تم التعامل مع إصلاح الأخطاء بشكل مستقل من قبل LLMs نفسها، مع توجيه المعلومات عن الأخطاء.
يشير البحث إلى أن حالات فشل LLM الشائعة تشمل انتهاكات حدود الوقت، وfailure في التقاط أو تسليم المهام المخصصة، وانتهاكات قيود سعة المركبات – أخطاء غالبًا ما تنشأ عن تجاهل التوجيهات الصريحة، أو من منطق إعادة التخطيط المعيب†:
‘مشكلة أخرى شائعة وجدناها (معظمها مع Gemini و Claude و DeepSeek، وليس مع GPT) هي أن LLM غالبًا ما يفشل بشكل متكرر في حل عيب.
‘على سبيل المثال، كان وكيل يتعطل بشكل متكرر، على الرغم من العديد من (مثل 5-15) دورات توجيه LLM بالخطأ و تلقي الإصدار المعاد من الكود.
‘الsolution الوحيدة التي وجدناها لمثل هذه الحالات (حيث يفشل LLM بشكل متكرر في حل نفس العيب) هي إعادة البدء من البداية. بشكل عام، لاحظنا الحاجة إلى جهد يدوي كبير لتحقيق كود خالي من الأخطاء. كان علينا توليد وكلاء أكثر بكثير للحصول على 40 وكيلًا خاليًا من الأخطاء الذين قيمناهم.’
تُظهر النتائج التالية تلخيص النتائج من 12 بطولة دورة مزدوجة، عبر أربعة توپولوجيات شبكة، وثلاث بطولات لكل توپولوجيا، مما أدى إلى ما يقرب من 40,000 مباراة:
| الوكيل | متوسط عدد الانتصارات / البطولة | انحراف معياري عدد الانتصارات / البطولة | متوسط عدد الهزائم / البطولة | انحراف معياري عدد الهزائم / البطولة | إجمالي الانتصارات | إجمالي الهزائم | معدل الفوز |
|---|---|---|---|---|---|---|---|
| طالب 1 | 108.167 | 1.193 | 3.833 | 1.193 | 1298 | 46 | 0.9658 |
| طالب 2 | 104.917 | 2.539 | 7.083 | 2.539 | 1259 | 85 | 0.9368 |
| طالب 3 | 103.917 | 2.466 | 8.083 | 2.466 | 1247 | 97 | 0.9278 |
| طالب 4 | 103.25 | 1.815 | 8.75 | 1.815 | 1239 | 105 | 0.9219 |
| طالب 5 | 96.5 | 2.908 | 15.5 | 2.908 | 1158 | 186 | 0.8616 |
| LLM(O, IR, 1) | 95.417 | 2.314 | 16.583 | 2.314 | 1145 | 199 | 0.8519 |
| LLM(O, A2, 1) | 94.583 | 2.314 | 17.417 | 2.314 | 1135 | 209 | 0.8445 |
| طالب 6 | 93.167 | 1.899 | 18.833 | 1.899 | 1118 | 226 | 0.8318 |
| طالب 7 | 93.167 | 3.563 | 18.833 | 3.563 | 1118 | 226 | 0.8318 |
| LLM(O, A1, 1) | 86.083 | 3.029 | 25.917 | 3.029 | 1033 | 311 | 0.7686 |
| LLM(O, GEN, 2) | 84.083 | 6.947 | 27.917 | 6.947 | 1009 | 335 | 0.7507 |
| LLM(O, CR, 2) | 83.5 | 4.442 | 28.5 | 4.442 | 1002 | 342 | 0.7455 |
| طالب 8 | 83.417 | 4.122 | 28.583 | 4.122 | 1001 | 343 | 0.7448 |
| RiskSeeking | 82.417 | 3.343 | 29.583 | 3.343 | 989 | 355 | 0.7359 |
| LLM(O, GEN, 1) | 80.667 | 4.355 | 31.25 | 4.372 | 968 | 375 | 0.7208 |
| ModelOpponent | 80.583 | 3.26 | 31.417 | 3.26 | 967 | 377 | 0.7195 |
| LLM(D, A1, 1) | 79.417 | 3.965 | 32.583 | 3.965 | 953 | 391 | 0.7091 |
| ExpCostFixedBid | 77.167 | 4.951 | 34.833 | 4.951 | 926 | 418 | 0.689 |
| LLM(O, IR, 2) | 73.917 | 3.502 | 38 | 3.618 | 887 | 456 | 0.6605 |
| LLM(O, A1, 2) | 72.417 | 2.193 | 39.583 | 2.193 | 869 | 475 | 0.6466 |
| LLM(G, A1, 2) | 68.5 | 3.555 | 43.5 | 3.555 | 822 | 522 | 0.6116 |
| LLM(A, GEN, 2) | 67.917 | 2.968 | 44.083 | 2.968 | 815 | 529 | 0.6064 |
| LLM(G, IR, 2) | 65.917 | 2.314 | 46.083 | 2.314 | 791 | 553 | 0.5885 |
| طالب 9 | 64.167 | 11.044 | 47.833 | 11.044 | 770 | 574 | 0.5729 |
| LLM(G, A1, 1) | 64 | 4.243 | 47.917 | 4.316 | 768 | 575 | 0.5719 |
| LLM(G, IR, 1) | 60.333 | 3.725 | 51.667 | 3.725 | 724 | 620 | 0.5387 |
| LLM(O, A2, 2) | 59.333 | 4.499 | 52.667 | 4.499 | 712 | 632 | 0.5298 |
| LLM(D, CR, 1) | 55.083 | 6.694 | 56.833 | 6.59 | 661 | 682 | 0.4922 |
| LLM(G, GEN, 2) | 53.167 | 3.664 | 58.833 | 3.664 | 638 | 706 | 0.4747 |
| LLM(D, GEN, 2) | 52.083 | 9.06 | 59.917 | 9.06 | 625 | 719 | 0.465 |
| Honest | 50.583 | 3.848 | 61.417 | 3.848 | 607 | 737 | 0.4516 |
| طالب 10 | 48.833 | 2.98 | 63.167 | 2.98 | 586 | 758 | 0.436 |
| LLM(D, IR, 1) | 48.583 | 10.211 | 63.417 | 10.211 | 583 | 761 | 0.4338 |
| LLM(A, A1, 1) | 48 | 4.69 | 64 | 4.69 | 576 | 768 | 0.4286 |
| LLM(G, A2, 1) | 47.25 | 3.864 | 64.75 | 3.864 | 567 | 777 | 0.4219 |
| LLM(A, CR, 1) | 43.833 | 4.609 | 68.167 | 4.609 | 526 | 818 | 0.3914 |
| LLM(A, A1, 2) | 43.75 | 2.05 | 68.25 | 2.05 | 525 | 819 | 0.3906 |
| طالب 11 | 42.083 | 5.664 | 69.917 | 5.664 | 505 | 839 | 0.3757 |
| LLM(A, IR, 1) | 39.5 | 2.541 | 72.5 | 2.541 | 474 | 870 | 0.3527 |
| Naive | 36.75 | 1.712 | 75.25 | 1.712 | 441 | 903 | 0.3281 |
| طالب 12 | 36.333 | 1.775 | 75.667 | 1.775 | 436 | 908 | 0.3244 |
| LLM(D, A2, 1) | 33.917 | 2.193 | 78.083 | 2.193 | 407 | 937 | 0.3028 |
| LLM(A, GEN, 1) | 30.167 | 1.749 | 81.833 | 1.749 | 362 | 982 | 0.2693 |
| LLM(D, A2, 2) | 29.833 | 2.038 | 82.167 | 2.038 | 358 | 986 | 0.2664 |
| LLM(G, A2, 2) | 27 | 2.256 | 85 | 2.256 | 324 | 1020 | 0.2411 |
| LLM(A, A2, 1) | 26.333 | 0.985 | 85.667 | 0.985 | 316 | 1028 | 0.2351 |
| LLM(O, CR, 1) | 25 | 3.411 | 87 | 3.411 | 300 | 1044 | 0.2232 |
| LLM(A, IR, 2) | 24.333 | 8.542 | 87.667 | 8.542 | 292 | 1052 | 0.2173 |
| LLM(A, A2, 2) | 24 | 1.809 | 88 | 1.809 | 288 | 1056 | 0.2143 |
| LLM(A, CR, 2) | 23.333 | 1.557 | 88.667 | 1.557 | 280 | 1064 | 0.2083 |
| LLM(D, GEN, 1) | 22.5 | 1.784 | 89.5 | 1.784 | 270 | 1074 | 0.2009 |
| LLM(D, A1, 2) | 13.333 | 1.826 | 98.667 | 1.826 | 160 | 1184 | 0.119 |
| LLM(G, CR, 1) | 9.5 | 1.087 | 102.5 | 1.087 | 114 | 1230 | 0.0848 |
| LLM(G, GEN, 1) | 9.167 | 0.937 | 102.833 | 0.937 | 110 | 1234 | 0.0818 |
| LLM(D, IR, 2) | 7.75 | 0.622 | 104.25 | 0.622 | 93 | 1251 | 0.0692 |
| LLM(G, CR, 2) | 7.25 | 1.422 | 104.75 | 1.422 | 87 | 1257 | 0.0647 |
| LLM(D, CR, 2) | 5.667 | 0.985 | 106.333 | 0.985 | 68 | 1276 | 0.0506 |
لمزيد من السياق، لعب كل وكيل 112 مباراة لكل بطولة، لذلك متوسط أقصى عدد للفوز أو الهزائم لكل وكيل هو 112. يُظهر الانحراف المعياري التباين عبر البطولات. الوكلاء المدعومون بالكود البشري يظهرون بالخط العريض. الوكلاء المدعومون بالكود البشري يتم تسميتهم بواسطة نموذج (O = GPT-5 Thinking، G = Gemini 2.5 Pro، A = Claude Opus 4.1، D = DeepSeek R1)، يليها رمز استراتيجية مكون من حرفين و رقم يشير إلى ما إذا كان الوكيل الأول أو الثاني تم إنشاؤه بهذا العطاء. المصدر
فيما يتعلق بالنتائج المذكورة أعلاه، يذكر المؤلفون†:
‘لم تولد LLMs كودًا متوقعًا / منافسًا حتى في أشكال أبسط من مشكلة APDP (على الرغم من أن الكود كان في الغالب خاليًا من أخطاء التركيبة النحوية). هذا يؤكد أهمية مقاييس تقييم الكود التي تقودها العقلانية التي تتجاوز الإكمال التلقائي وتحدد نقاط الضعف الجديدة لل LLMs.’
‘تظهر نتائجنا تفوقًا واضحًا لوكلاء الكود البشري: (i) تحتل المراكز الخمس الأولى باستمرار من قبل وكلاء الطلاب، و (ii) يُهزم غالبية وكلاء LLM (33 من أصل 40) من قبل وكلاء أساسيين بسيطين جدًا (مثل العطاء الثابت لتكلفة المتوقع).
‘من المهم أن نلاحظ أننا لم نصلح كود الطلاب (في حين قمنا بتحقيق اختبار وتصحيح شامل لكود LLM، في كل من اللعب الذاتي وبيئات البطولة). كل مرة يتعطل فيها وكيل طالب، كنا نمنح الفوز تلقائيًا لـ LLM. كان يمكن لوكلاء الطلاب الاحتفاظ بمكانة أعلى.’
كما قام المؤلفون بتجربة إضافية، حيث تم توجيه GPT-5 Thinking لتحسين كود الوكيل الأفضل أداءً من بين وكلاء الطلاب، طالب 1؛ ولكن الوكيل المعدل حديثًا بواسطة LLM انخفض إلى المركز العاشر، وهو الأسوأ من بين جميع نتائج الطلاب. بدلاً من تحسين الحل، أدت تغييرات LLMs إلى تدهورها بمقدار 20٪ تقريبًا.
يخلص المؤلفون إلى ما يلي:
‘تسلط نتائجنا الضوء على قيود توليد كود LLM، ولا سيما قدراتها المحدودة في التخطيط والتفكير أثناء توليد الكود. يمكن لل LLMs الحديثة توفير كود خالي من أخطاء التركيبة النحوية التي تعمل، ولكن هذا ليس المقياس الذي يجب أن نستخدمه لقياس التقدم نحو الذكاء الاصطناعي العام المتقدم.’
الخلاصة
يلاحظ المؤلفون أنفسهم نحو نهاية الورقة أن التشفير أمنح الناس من جميع الخلفيات الفنية، ووصفوا الممارسة في ضوء إيجابي، كقوة مساواة. ومع ذلك، فإنهم يشيران أيضًا إلى أن التشفير قد وصل للتو، وحدوده غير معروفة، وربما يُفترض أنها أعلى مما يمكن توقعها بصدق.
يختمون عطائهم bằng نداء لتحويل الهدف من “الكود الذي يترجم إلى كود يتنافس“.
قد يسأل القارئ العادي لهذا البحث الجديد سؤالًا عن ما إذا كان المؤلفون يضربون أعلى أو أسفل، لأن المهمة الوكيلية المذكورة هي أكثر تعقيدًا وملحة من إخراج نص برمجي لسكريبتات باور شيل وغيرها من أنواع الوظائف الصغيرة والتصحيحات التي يُفضل التشفير لها.
* يرجى ملاحظة أن الورقة تشير باستمرار إلى ‘DeepThink R1’، الذي يبدو أنه غير موجود، ويظهر فقط عدد قليل من المراجع على الإنترنت (يبدو أنهم كتبوا خطأ ‘DeepSeek R1’). إذا كان هذا خطأ من جانبي، يرجى الاتصال بي عبر تفاصيل ملفي الشخصي، وسأقوم بتعديله.
† تأكيد المؤلفين، وليس لي.
نُشر لأول مرة يوم الأربعاء، 26 نوفمبر 2025. تم تعديله في الساعة 17:35 بتوقيت شرق الولايات المتحدة لتحسين التنسيق.












