الذكاء الاصطناعي أدوات الترميز مثل ChatGPT مهددة ، ويتم تسريح Stack Overflow مرة أخرى! ومع ذلك ، وجدت برينستون وشيكاغو أن GPT-4 لديها معدل دقة 0٪ لمشاكل GitHub في العالم الحقيقي.
تجاوز المكدس ، الذي تم إنشاؤه بالفعل بواسطة ChatGPT!
نظرا لأن المبرمجين توافدوا على ChatGPT و Github Copilot ، كان على Stack Overflow الإعلان عن تسريح أكثر من 100 موظف اليوم ، وهو ما يمثل ما يقرب من 1/3 من عدد الموظفين.
لذا ، الذكاء الاصطناعي أدوات الترميز مثل ChatGPT ستؤدي حقا إلى تخريب الصناعة بأكملها؟
لكن دراسة حديثة أجرتها برينستون وشيكاغو وجدت أن LLM ليس من السهل القيام به كمزارع كود.
عنوان الورقة:
في مواجهة 2294 مشكلة GitHub حقيقية ، تبين أن معدل نجاح GPT-4 في حل مشكلات GitHub العشوائية هو 0٪!
حتى أفضل طراز ، كلود 2 ، يحل 1.96٪ منها فقط.
هل يمكن أن يفقد المبرمجون وظائفهم بسبب ChatGPT؟ الجواب هو - بالتأكيد ليس في الوقت الحالي.
التكيف أو الهلاك
نظرا لأن الموقع المفضل بمساعدة التعليمات البرمجية لكل مطور في العالم ، كان Stack Overflow يعمل بشكل جيد من قبل ، مما أدى إلى فورة التوظيف في العام الماضي ، مما ضاعف القوى العاملة في الشركة إلى 540.
ومع ذلك ، فقد تغير كل شيء منذ أن أصدرت OpenAI ChatGPT في نوفمبر الماضي.
المساعدة التي تقدمها روبوتات المحادثة الذكاء الاصطناعي أكثر تحديدا من منشور المنتدى قبل 5 سنوات. باستخدام LLM ، يمكن للمطورين تصحيح الكود الدقيق واقتراحات التحسين ووصف ما يفعله كل سطر من التعليمات البرمجية على الفور.
على الرغم من أن LLM لا تقدم إجابات موثوقة بنسبة 100٪ ، إلا أن القدرة الفريدة على التحقق من صحة الكود على الفور بمجرد اختباره في بيئة التطوير المتكاملة IDE تجعل كتابة التعليمات البرمجية حالة استخدام مثالية ل ChatGPT.
نتيجة لذلك ، تم تقليل حركة مرور Stack Overflow بشكل كبير ، وأصبحت أدوات البرمجة الذكاء الاصطناعي مثل ChatGPT و Github Copilot التي تعمل بنظام GPT-4 أماكن جديدة لمزارعي التعليمات البرمجية.
اليوم ، أعلن الرئيس التنفيذي براشانث شاندراسيكار أن Stack Overflow قد سرحت أكثر من مائة موظف ، أو 28٪ من قوتها العاملة.
تفسير الرئيس التنفيذي لتسريح العمال هو أن Stack Overflow تحاول السير على طريق الربحية تحت ضغط الاقتصاد الكلي ، وتواصل تقديم ابتكارات المنتجات.
** عبور النهر وهدم الجسر؟ **
أكبر مفارقة في تأثير ChatGPT على Stack Overflow هي أن قوة نموذج اللغة الكبيرة تأتي إلى حد كبير من كشط مواقع مثل Stack Overflow.
ماذا يحدث إذا أفرغت نماذج اللغة الكبيرة هذه البيانات دون إعادة أي شيء ، وإذا أجبرت جميع مصادر البيانات على الخروج من العمل؟
الآن ، تواجه العديد من شركات التكنولوجيا بالفعل مشكلة تلوح في الأفق: إذا كان هناك عدد أقل من المبرمجين ، فسيكون هناك بيانات اصطناعية أقل.
كيف تقوم بتدريب نماذج الذكاء الاصطناعي جديدة بدون بيانات محدثة؟
هل تريد استخدام بياناتنا؟ خذ المال**
بالطبع ، لا يمكن ل Stack Overflow الجلوس ساكنا ، فقد اختار طريقتين لإنقاذ نفسه -
الأول هو تطوير أداة ترميز الذكاء الاصطناعي الخاصة بها ، OverflowAI ، والآخر هو البحث عن شراكات مباشرة مع شركات التكنولوجيا مثل OpenAI ، التي تستخدم بيانات Stack Overflow لبناء نماذج الذكاء الاصطناعي.
تعمل OpenAI على تطوير عناصر تحكم زاحف الويب ل ChatGPT بحيث لا يمكن الزحف إلى البيانات من مواقع مثل Stack Overflow.
قال الرئيس التنفيذي إن Stack Overflow قد اتخذت موقفها: من يريد استخدام بياناتنا لتدريب LLM يدفع.
يعتقد الرؤساء التنفيذيون أن مواقع مثل Stack Overflow ضرورية لتطوير نماذج اللغة الكبيرة ، ومن أجل التقدم ، يجب تدريبهم على معرفة جديدة.
براشانث شاندراسيكار ، الرئيس التنفيذي لشركة Stack Overflow
** يريد LLM الحصول على مزارع الكود ، لا يزال مبكرا **
لذا ، هل يمكن لنماذج اللغة الكبيرة حقا أن تأخذ مزارعي الكود؟
وجد فريقا برينستون وشيكاغو أن الأمر لم يكن بهذه السهولة!
في الورقة الأخيرة ، يقترح الباحثون إطارا جديدا ، SWE-bench ، لتقييم قدرة النماذج الكبيرة على حل 2294 مشكلة في العالم الحقيقي على GitHub.
وقد وجد أن النماذج الكبيرة الرائدة مثل GPT-4 و Claude 2 لديها أقل من 5٪ من القدرة على حل المشكلات الحقيقية.
لكي نكون أكثر تحديدا ، يمكن ل GPT-4 حل مشكلات GitHub العشوائية بمعدل نجاح 0٪ ، في حين أن أفضل نموذج ، كلود 2 ، يمكنه حل 1.96٪ منها فقط.
علاوة على ذلك ، عند استخدام BM-25 لاسترداد ملفات التعليمات البرمجية ذات الصلة لكل مشكلة ، كانت 23٪ فقط من التصحيحات التي كتبها كلود 2 صالحة (جاهزة للريبو) ، وفقط ~ 1٪ حل المشكلة بالفعل.
بالإضافة إلى ذلك ، يختلف أيضا أداء النماذج المختلفة في حل المشكلات مع 12 مكتبة Python شائعة.
لقد حقق نموذج GPT-4 مثل هذه النتيجة ، وهو أمر مثير للدهشة حقا ، بعد كل شيء ، اعتبره الكثير من الناس منذ فترة طويلة "سلاح برمجة".
ولكن لنرى بوضوح ، القوة الحقيقية الذكاء الاصطناعي ، لا يتم تسجيلها وتقلق.
قال بعض مستخدمي الإنترنت إن هذا هو أفضل إجابة على سؤال «ما إذا كان مزارعو الكود عاطلين عن العمل بسبب البرمجة».
أخيرا ، قام شخص ما بعمل مجموعة بيانات حقيقية لنموذج الكود ، وكان Hum مجرد مقابلة leetcode ل LLM. نعلم جميعا أن هذا هو الإجراء الخاطئ للمهندسين البشريين. أقل من 4٪ يبدو صحيحا ، حيث لا تزال النماذج الكبيرة بعيدة عن الاستقلال الكامل.
إذن ، هل هذا هو الحال حقا مع نتائج SWE-bench في تقييم قدرات النماذج الكبيرة؟
**مقعد SWE: مصمم لنماذج الترميز **
في هذه الدراسة ، وجد المؤلفون أن العديد من المعايير الحالية لقياس قدرة الترميز للنماذج الكبيرة أصبحت مشبعة ولا يمكنها قياس القوة الحقيقية للنماذج الكبيرة.
على سبيل المثال ، في Human ، مشكلة التحدي بسيطة للغاية ، ولا يحتاج LLM إلا إلى بضعة أسطر من التعليمات البرمجية لحل مشكلة قائمة بذاتها.
ومع ذلك ، فإن هندسة البرمجيات ليست بهذه البساطة في الواقع.
قد يتطلب إصلاح الخلل تصفح مكتبة ضخمة من الموارد ، أو فهم العلاقات بين الوظائف في الملفات المختلفة ، أو العثور على خطأ صغير في الكود المعقد.
مستوحاة من هذا ، قدم باحثون من برينستون وشيكاغو SWE-bench.
يحصل SWE-bench على مثيلات المهام من مستودع Python حقيقي عن طريق ربط مشكلات GitHub ودمج حلول الطلبات لحل الاختبارات ذات الصلة.
كما هو موضح في الصورة ، تتمثل مهمة النموذج ، عادة ما تكون تقرير خطأ أو طلب ميزة ، في حل مشكلة ملتزمة بمستودع GitHub.
تتطلب كل مهمة إنشاء تصحيح ووصف التغييرات التي سيتم تطبيقها على قاعدة التعليمات البرمجية الموجودة.
ثم استخدم إطار اختبار المستودع SWE-bench لتقييم قاعدة التعليمات البرمجية المعدلة.
للعثور على أمثلة عالية الجودة للمهام واسعة النطاق ، مر الباحثون بثلاث مراحل من الفحص:
** المرحلة 1: اختيار المستودع والبحث عن البيانات. **
تم جمع طلبات السحب (PRs) لأول مرة من 12 مستودع Python مفتوح المصدر على GitHub ، مما أدى إلى توليد ما مجموعه حوالي 90,000 PRs.
ركز الباحثون على المستودعات الشائعة لأنها تميل إلى صيانتها بشكل أفضل ، ولديها إرشادات واضحة للمساهمين ، ولديها تغطية اختبار أفضل. يحتوي كل PR على قاعدة بيانات مرتبطة ، أي حالة المستودع قبل دمج العلاقات العامة.
**المرحلة 2: التصفية القائمة على السمات. **
يتم إنشاء مهمة المرشح عن طريق تحديد العلاقات العامة المدمجة التي تفي بالمعايير التالية: (1) يحل مشكلة GitHub ؛ (2) تعديل ملف الاختبار الخاص بالمستودع ، مما يشير إلى أن المستخدم ساهم على الأرجح في اختبارات للتحقق مما إذا كان قد تم حل المشكلة.
** المرحلة 3: التصفية القائمة على التنفيذ. **
لكل مهمة مرشحة ، يتم تطبيق محتوى اختبار العلاقات العامة ، ويتم تطبيق نتائج الاختبار ذات الصلة قبل وبعد تطبيق المحتوى الآخر للعلاقات العامة.
يقوم الباحث بتصفية حالات المهام التي لا تحتوي على اختبار واحد على الأقل ، وتتغير حالة هذه الاختبارات من فشل في النجاح (يشار إليها فيما يلي باسم "فشل اجتياز الاختبار"). بالإضافة إلى ذلك، تتم تصفية المثيلات التي تسبب أخطاء التثبيت أو التشغيل.
من خلال مراحل الفحص هذه ، يتم فحص 90,000 PRs الأصلية في 2,294 حالة مهمة ، والتي تشكل SWE-bench.
يظهر التصنيف النهائي لمثيلات المهام هذه في مستودعات مختلفة في الشكل 3 أدناه ، مع كون الجدول هو السمة الرئيسية لمثيلات مهام SWE-bench.
يؤكد الباحثون أن قواعد التعليمات البرمجية هذه كبيرة ، وتحتوي على آلاف الملفات ، وأن طلبات السحب المرجعية غالبا ما تعدل ملفات متعددة في نفس الوقت.
تقدم SWE-bench العديد من المزايا مقارنة بمعايير البرمجة LM الحالية.
وتشمل هذه الإعدادات في العالم الحقيقي مع المشكلات والحلول المقدمة من المستخدم ، والمدخلات المتنوعة التي تتميز بأسئلة رمز فريدة من 12 مستودعا ، وإطار تقييم قوي قائم على التنفيذ ، والقدرة على تحديث المعايير باستمرار بمثيلات جديدة بأقل تدخل بشري.
** مهمة LLM: تحرير قاعدة التعليمات البرمجية ، وحل المشكلات **
سيقدم الباحث للنموذج الكبير وصفا نصيا للمشكلة ، بالإضافة إلى قاعدة كود كاملة.
تتمثل مهمة النموذج الكبير في تحرير قاعدة التعليمات البرمجية لحل المشكلة.
في الممارسة العملية ، يمثل الباحثون التغييرات كملفات تصحيح ، والتي تحدد الأسطر في قاعدة التعليمات البرمجية التي يجب تعديلها لحل المشكلة.
كيفية تقييم ما إذا كان الحل الذي قدمته LLM جيدا أم لا؟
يستخدم الباحثون تصحيحات Unix ، ويطبقون التصحيحات التي تم إنشاؤها على قاعدة التعليمات البرمجية ، ثم يقومون بإجراء اختبارات الوحدة والنظام المتعلقة بمثيلات المهام.
إذا تم تطبيق التصحيح بنجاح ، وتم اجتياز جميع هذه الاختبارات ، فيمكن اعتبار المخطط الموصى به من قبل LLM قد حل المشكلة بنجاح.
مقياس للخط الأساسي، وهو النسبة المئوية لمثيلات المهام التي تم حلها.
بناء مجموعة بيانات فريدة لمقعد SWE
عادة ما تتضمن معايير البرمجة اللغوية العصبية التقليدية تسلسلات مدخلات ومخرجات قصيرة فقط وتنظر في بعض المشكلات "الاصطناعية" التي تم إنشاؤها خصيصا للمعايير.
في المقابل ، لبناء مقعد SWE ، قام الباحثون بحقن خصائص فريدة في مجموعة البيانات.
على سبيل المثال ، يتم استخدام مهام هندسة البرمجيات الحقيقية.
نظرا لأن كل مثيل مهمة في SWE-bench يحتوي على قاعدة تعليمات برمجية كبيرة ومعقدة ووصف للمشكلة المرتبطة ، فإن حل SWE-bench يتطلب مهارات ومعرفة معقدة لمهندسي البرمجيات ذوي الخبرة ، والتي غالبا ما لا يتم تقييمها في معايير إنشاء التعليمات البرمجية التقليدية.
علاوة على ذلك ، يمكن تطبيق عملية التجميع بسهولة على أي مستودع Python على GitHub مع تدخل بشري ضئيل أو معدوم.
نتيجة لذلك ، يمكن للباحثين توسيع SWE-bench من خلال توفير مثيلات مهام جديدة وتقييم نموذج اللغة للمشاكل التي تم إنشاؤها بعد تاريخ التدريب ، مما يضمن أن مجموعة التدريب لا تحتوي على حل.
بالإضافة إلى ذلك ، يضمن الباحثون مدخلات طويلة مختلفة في المعيار ، والتقييم القوي ، وتحرير التعليمات البرمجية عبر السياق ، ومجموعة واسعة من الحلول ، وما إلى ذلك.
**ضبط SWE-Llama **
بعد ذلك ، حان الوقت لتقييم فعالية النماذج المفتوحة والملكية في إطار SWE-bench.
ومع ذلك ، وجد الباحثون أن نماذج الضبط الدقيق CodeLlama الجاهزة لا يمكنها اتباع تعليمات مفصلة لإنشاء تعديلات على التعليمات البرمجية على مستوى المكتبة ، وغالبا ما تخرج استجابات العناصر النائبة أو التعليمات البرمجية غير ذات الصلة.
لتقييم قدرات هذه النماذج ، أجرى الباحثون ضبطا دقيقا تحت الإشراف (SFT) على نموذج CodeLlama-Python البالغ 7 مليارات معلمة ونموذج CodeLlama-Python البالغ 13 مليار معلمة.
النموذج الناتج هو محرر مستودع متخصص يعمل على أجهزة من فئة المستهلك ويحل مشكلات GitHub.
### النماذج الكبيرة تفشل
بعد ذلك ، قام الباحثون بتقييم GPT-3.5 و GPT-4 و Cluade 2 والنماذج المضبوطة بدقة.
اتضح أن جميع النماذج فشلت - لم يحل أي منها جميع المشاكل باستثناء أبسطها.
على سبيل المثال ، يمكن ل Claude 2 و GPT-4 حل 4.8٪ و 1.7٪ فقط من المهام ، على التوالي.
بعد استخدام مسترد BM25 ، انخفض أداء كلود 2 إلى 1.96٪.
** المكتبات المختلفة لديها مستويات مختلفة من الصعوبة. **
إذا قمت بتقسيم الأداء حسب المستودع، فسترى أن جميع النماذج تعرض اتجاهات مماثلة عبر المكتبات.
ومع ذلك، فإن المشاكل التي يعالجها كل نموذج لا تتداخل بالضرورة على نطاق واسع. على سبيل المثال ، في إعداد أوراكل ، يعمل كلود 2 و SWE-Llama 13b بشكل مقارن ، حيث يحلان 110 و 91 مثيلا لكل نموذج ، على التوالي.
** تعتمد الصعوبة على طول السياق. **
يمكن تدريب النماذج مسبقا على تسلسلات التعليمات البرمجية الطويلة ، ولكنها تتطلب عادة إنشاء وظيفة واحدة في كل مرة وتوفير إطار عمل مع سياق محدود لتحديد المشكلة.
كما هو موضح ، يمكنك أن ترى أن أداء كلود 2 يتدهور بشكل كبير مع زيادة الطول الإجمالي للسياق ، والذي يمكن ملاحظته أيضا في الطرز الأخرى.
حتى لو كانت زيادة الحد الأقصى لحجم سياق BM25 من شأنه تحسين الاستدعاء بالنسبة لملفات Oracle ، فسيظل الأداء يتدهور لأن النموذج ببساطة لم يتمكن من تحديد موقع الكود الإشكالي في قاموس المرادفات الشاسع.
** الصعوبة مستقلة عن تاريخ حل المشكلة. **
يوضح الجدول 7 نتائج النموذج حسب التاريخ للعلاقات العامة التي تم إنشاؤها قبل أو بعد عام 2023 ضمن إعدادات البحث "أوراكل".
بالنسبة لمعظم الطرز ، باستثناء GPT-4 ، هناك اختلاف بسيط في الأداء قبل أو بعد هذا التاريخ.
بالإضافة إلى ذلك ، وجدت الدراسة أن ضبط النموذج حساس للتغيرات في توزيع السياق ، ومن الأسهل إنشاء تصحيح بدلا من إنشاء ملف كامل. وتميل النماذج الكبيرة إلى إنتاج تعديلات أقصر وأبسط.
**LLM ليس بديلا عن المبرمجين ، ولكن يمكنه تسريع سير العمل **
بعض مستخدمي الإنترنت لديهم آمال وآمال لمستقبل "النموذج العام".
هذا صحيح ، هذا ما أقوله. النموذج العام ليس جيدا بما يكفي للحصول على طول سياق واسع بما يكفي للترميز بمفرده ، باستثناء مقتطفات التعليمات البرمجية القصيرة نسبيا.
لكنني أعتقد أنها مسألة وقت فقط. أستطيع أن أتوقع أنه في المستقبل القريب ، سيصبح LLM العام مع تدريب محدد نموذجا احترافيا للغاية.
في حين أن النماذج الكبيرة ليست بديلا عن المبرمجين ، إلا أنها يمكن أن تسرع سير عملهم. ما كان يستغرق فريقا من 10 أشخاص قد يحتاج الآن إلى 4 أشخاص فقط. هذا يحرر الموارد لأهداف أخرى أعدتها الشركة.
بدلا من تسريح الموظفين لتوفير المال ، دع المطورين ينجزون أشياء رائعة بسرعة فائقة!
موارد:
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
النماذج الكبيرة لا يمكن أن تكون مزارعين رمزيين! اكتشاف برينستون المفاجئ: GPT-4 لديه معدل نجاح 0 في حل مشاكل برمجة GitHub
مصدر المقال: شين جي يوان
تجاوز المكدس ، الذي تم إنشاؤه بالفعل بواسطة ChatGPT!
نظرا لأن المبرمجين توافدوا على ChatGPT و Github Copilot ، كان على Stack Overflow الإعلان عن تسريح أكثر من 100 موظف اليوم ، وهو ما يمثل ما يقرب من 1/3 من عدد الموظفين.
لكن دراسة حديثة أجرتها برينستون وشيكاغو وجدت أن LLM ليس من السهل القيام به كمزارع كود.
في مواجهة 2294 مشكلة GitHub حقيقية ، تبين أن معدل نجاح GPT-4 في حل مشكلات GitHub العشوائية هو 0٪!
حتى أفضل طراز ، كلود 2 ، يحل 1.96٪ منها فقط.
التكيف أو الهلاك
نظرا لأن الموقع المفضل بمساعدة التعليمات البرمجية لكل مطور في العالم ، كان Stack Overflow يعمل بشكل جيد من قبل ، مما أدى إلى فورة التوظيف في العام الماضي ، مما ضاعف القوى العاملة في الشركة إلى 540.
ومع ذلك ، فقد تغير كل شيء منذ أن أصدرت OpenAI ChatGPT في نوفمبر الماضي.
على الرغم من أن LLM لا تقدم إجابات موثوقة بنسبة 100٪ ، إلا أن القدرة الفريدة على التحقق من صحة الكود على الفور بمجرد اختباره في بيئة التطوير المتكاملة IDE تجعل كتابة التعليمات البرمجية حالة استخدام مثالية ل ChatGPT.
نتيجة لذلك ، تم تقليل حركة مرور Stack Overflow بشكل كبير ، وأصبحت أدوات البرمجة الذكاء الاصطناعي مثل ChatGPT و Github Copilot التي تعمل بنظام GPT-4 أماكن جديدة لمزارعي التعليمات البرمجية.
اليوم ، أعلن الرئيس التنفيذي براشانث شاندراسيكار أن Stack Overflow قد سرحت أكثر من مائة موظف ، أو 28٪ من قوتها العاملة.
** عبور النهر وهدم الجسر؟ **
أكبر مفارقة في تأثير ChatGPT على Stack Overflow هي أن قوة نموذج اللغة الكبيرة تأتي إلى حد كبير من كشط مواقع مثل Stack Overflow.
ماذا يحدث إذا أفرغت نماذج اللغة الكبيرة هذه البيانات دون إعادة أي شيء ، وإذا أجبرت جميع مصادر البيانات على الخروج من العمل؟
الآن ، تواجه العديد من شركات التكنولوجيا بالفعل مشكلة تلوح في الأفق: إذا كان هناك عدد أقل من المبرمجين ، فسيكون هناك بيانات اصطناعية أقل.
كيف تقوم بتدريب نماذج الذكاء الاصطناعي جديدة بدون بيانات محدثة؟
هل تريد استخدام بياناتنا؟ خذ المال**
بالطبع ، لا يمكن ل Stack Overflow الجلوس ساكنا ، فقد اختار طريقتين لإنقاذ نفسه -
الأول هو تطوير أداة ترميز الذكاء الاصطناعي الخاصة بها ، OverflowAI ، والآخر هو البحث عن شراكات مباشرة مع شركات التكنولوجيا مثل OpenAI ، التي تستخدم بيانات Stack Overflow لبناء نماذج الذكاء الاصطناعي.
قال الرئيس التنفيذي إن Stack Overflow قد اتخذت موقفها: من يريد استخدام بياناتنا لتدريب LLM يدفع.
يعتقد الرؤساء التنفيذيون أن مواقع مثل Stack Overflow ضرورية لتطوير نماذج اللغة الكبيرة ، ومن أجل التقدم ، يجب تدريبهم على معرفة جديدة.
** يريد LLM الحصول على مزارع الكود ، لا يزال مبكرا **
لذا ، هل يمكن لنماذج اللغة الكبيرة حقا أن تأخذ مزارعي الكود؟
وجد فريقا برينستون وشيكاغو أن الأمر لم يكن بهذه السهولة!
وقد وجد أن النماذج الكبيرة الرائدة مثل GPT-4 و Claude 2 لديها أقل من 5٪ من القدرة على حل المشكلات الحقيقية.
لكي نكون أكثر تحديدا ، يمكن ل GPT-4 حل مشكلات GitHub العشوائية بمعدل نجاح 0٪ ، في حين أن أفضل نموذج ، كلود 2 ، يمكنه حل 1.96٪ منها فقط.
بالإضافة إلى ذلك ، يختلف أيضا أداء النماذج المختلفة في حل المشكلات مع 12 مكتبة Python شائعة.
ولكن لنرى بوضوح ، القوة الحقيقية الذكاء الاصطناعي ، لا يتم تسجيلها وتقلق.
**مقعد SWE: مصمم لنماذج الترميز **
في هذه الدراسة ، وجد المؤلفون أن العديد من المعايير الحالية لقياس قدرة الترميز للنماذج الكبيرة أصبحت مشبعة ولا يمكنها قياس القوة الحقيقية للنماذج الكبيرة.
على سبيل المثال ، في Human ، مشكلة التحدي بسيطة للغاية ، ولا يحتاج LLM إلا إلى بضعة أسطر من التعليمات البرمجية لحل مشكلة قائمة بذاتها.
ومع ذلك ، فإن هندسة البرمجيات ليست بهذه البساطة في الواقع.
مستوحاة من هذا ، قدم باحثون من برينستون وشيكاغو SWE-bench.
يحصل SWE-bench على مثيلات المهام من مستودع Python حقيقي عن طريق ربط مشكلات GitHub ودمج حلول الطلبات لحل الاختبارات ذات الصلة.
كما هو موضح في الصورة ، تتمثل مهمة النموذج ، عادة ما تكون تقرير خطأ أو طلب ميزة ، في حل مشكلة ملتزمة بمستودع GitHub.
تتطلب كل مهمة إنشاء تصحيح ووصف التغييرات التي سيتم تطبيقها على قاعدة التعليمات البرمجية الموجودة.
ثم استخدم إطار اختبار المستودع SWE-bench لتقييم قاعدة التعليمات البرمجية المعدلة.
تم جمع طلبات السحب (PRs) لأول مرة من 12 مستودع Python مفتوح المصدر على GitHub ، مما أدى إلى توليد ما مجموعه حوالي 90,000 PRs.
ركز الباحثون على المستودعات الشائعة لأنها تميل إلى صيانتها بشكل أفضل ، ولديها إرشادات واضحة للمساهمين ، ولديها تغطية اختبار أفضل. يحتوي كل PR على قاعدة بيانات مرتبطة ، أي حالة المستودع قبل دمج العلاقات العامة.
**المرحلة 2: التصفية القائمة على السمات. **
يتم إنشاء مهمة المرشح عن طريق تحديد العلاقات العامة المدمجة التي تفي بالمعايير التالية: (1) يحل مشكلة GitHub ؛ (2) تعديل ملف الاختبار الخاص بالمستودع ، مما يشير إلى أن المستخدم ساهم على الأرجح في اختبارات للتحقق مما إذا كان قد تم حل المشكلة.
** المرحلة 3: التصفية القائمة على التنفيذ. **
لكل مهمة مرشحة ، يتم تطبيق محتوى اختبار العلاقات العامة ، ويتم تطبيق نتائج الاختبار ذات الصلة قبل وبعد تطبيق المحتوى الآخر للعلاقات العامة.
يقوم الباحث بتصفية حالات المهام التي لا تحتوي على اختبار واحد على الأقل ، وتتغير حالة هذه الاختبارات من فشل في النجاح (يشار إليها فيما يلي باسم "فشل اجتياز الاختبار"). بالإضافة إلى ذلك، تتم تصفية المثيلات التي تسبب أخطاء التثبيت أو التشغيل.
من خلال مراحل الفحص هذه ، يتم فحص 90,000 PRs الأصلية في 2,294 حالة مهمة ، والتي تشكل SWE-bench.
يظهر التصنيف النهائي لمثيلات المهام هذه في مستودعات مختلفة في الشكل 3 أدناه ، مع كون الجدول هو السمة الرئيسية لمثيلات مهام SWE-bench.
يؤكد الباحثون أن قواعد التعليمات البرمجية هذه كبيرة ، وتحتوي على آلاف الملفات ، وأن طلبات السحب المرجعية غالبا ما تعدل ملفات متعددة في نفس الوقت.
تقدم SWE-bench العديد من المزايا مقارنة بمعايير البرمجة LM الحالية.
وتشمل هذه الإعدادات في العالم الحقيقي مع المشكلات والحلول المقدمة من المستخدم ، والمدخلات المتنوعة التي تتميز بأسئلة رمز فريدة من 12 مستودعا ، وإطار تقييم قوي قائم على التنفيذ ، والقدرة على تحديث المعايير باستمرار بمثيلات جديدة بأقل تدخل بشري.
** مهمة LLM: تحرير قاعدة التعليمات البرمجية ، وحل المشكلات **
سيقدم الباحث للنموذج الكبير وصفا نصيا للمشكلة ، بالإضافة إلى قاعدة كود كاملة.
تتمثل مهمة النموذج الكبير في تحرير قاعدة التعليمات البرمجية لحل المشكلة.
في الممارسة العملية ، يمثل الباحثون التغييرات كملفات تصحيح ، والتي تحدد الأسطر في قاعدة التعليمات البرمجية التي يجب تعديلها لحل المشكلة.
يستخدم الباحثون تصحيحات Unix ، ويطبقون التصحيحات التي تم إنشاؤها على قاعدة التعليمات البرمجية ، ثم يقومون بإجراء اختبارات الوحدة والنظام المتعلقة بمثيلات المهام.
مقياس للخط الأساسي، وهو النسبة المئوية لمثيلات المهام التي تم حلها.
بناء مجموعة بيانات فريدة لمقعد SWE
عادة ما تتضمن معايير البرمجة اللغوية العصبية التقليدية تسلسلات مدخلات ومخرجات قصيرة فقط وتنظر في بعض المشكلات "الاصطناعية" التي تم إنشاؤها خصيصا للمعايير.
في المقابل ، لبناء مقعد SWE ، قام الباحثون بحقن خصائص فريدة في مجموعة البيانات.
على سبيل المثال ، يتم استخدام مهام هندسة البرمجيات الحقيقية.
علاوة على ذلك ، يمكن تطبيق عملية التجميع بسهولة على أي مستودع Python على GitHub مع تدخل بشري ضئيل أو معدوم.
نتيجة لذلك ، يمكن للباحثين توسيع SWE-bench من خلال توفير مثيلات مهام جديدة وتقييم نموذج اللغة للمشاكل التي تم إنشاؤها بعد تاريخ التدريب ، مما يضمن أن مجموعة التدريب لا تحتوي على حل.
بالإضافة إلى ذلك ، يضمن الباحثون مدخلات طويلة مختلفة في المعيار ، والتقييم القوي ، وتحرير التعليمات البرمجية عبر السياق ، ومجموعة واسعة من الحلول ، وما إلى ذلك.
**ضبط SWE-Llama **
بعد ذلك ، حان الوقت لتقييم فعالية النماذج المفتوحة والملكية في إطار SWE-bench.
ومع ذلك ، وجد الباحثون أن نماذج الضبط الدقيق CodeLlama الجاهزة لا يمكنها اتباع تعليمات مفصلة لإنشاء تعديلات على التعليمات البرمجية على مستوى المكتبة ، وغالبا ما تخرج استجابات العناصر النائبة أو التعليمات البرمجية غير ذات الصلة.
لتقييم قدرات هذه النماذج ، أجرى الباحثون ضبطا دقيقا تحت الإشراف (SFT) على نموذج CodeLlama-Python البالغ 7 مليارات معلمة ونموذج CodeLlama-Python البالغ 13 مليار معلمة.
النموذج الناتج هو محرر مستودع متخصص يعمل على أجهزة من فئة المستهلك ويحل مشكلات GitHub.
بعد ذلك ، قام الباحثون بتقييم GPT-3.5 و GPT-4 و Cluade 2 والنماذج المضبوطة بدقة.
اتضح أن جميع النماذج فشلت - لم يحل أي منها جميع المشاكل باستثناء أبسطها.
على سبيل المثال ، يمكن ل Claude 2 و GPT-4 حل 4.8٪ و 1.7٪ فقط من المهام ، على التوالي.
بعد استخدام مسترد BM25 ، انخفض أداء كلود 2 إلى 1.96٪.
** المكتبات المختلفة لديها مستويات مختلفة من الصعوبة. **
إذا قمت بتقسيم الأداء حسب المستودع، فسترى أن جميع النماذج تعرض اتجاهات مماثلة عبر المكتبات.
ومع ذلك، فإن المشاكل التي يعالجها كل نموذج لا تتداخل بالضرورة على نطاق واسع. على سبيل المثال ، في إعداد أوراكل ، يعمل كلود 2 و SWE-Llama 13b بشكل مقارن ، حيث يحلان 110 و 91 مثيلا لكل نموذج ، على التوالي.
** تعتمد الصعوبة على طول السياق. **
يمكن تدريب النماذج مسبقا على تسلسلات التعليمات البرمجية الطويلة ، ولكنها تتطلب عادة إنشاء وظيفة واحدة في كل مرة وتوفير إطار عمل مع سياق محدود لتحديد المشكلة.
كما هو موضح ، يمكنك أن ترى أن أداء كلود 2 يتدهور بشكل كبير مع زيادة الطول الإجمالي للسياق ، والذي يمكن ملاحظته أيضا في الطرز الأخرى.
حتى لو كانت زيادة الحد الأقصى لحجم سياق BM25 من شأنه تحسين الاستدعاء بالنسبة لملفات Oracle ، فسيظل الأداء يتدهور لأن النموذج ببساطة لم يتمكن من تحديد موقع الكود الإشكالي في قاموس المرادفات الشاسع.
يوضح الجدول 7 نتائج النموذج حسب التاريخ للعلاقات العامة التي تم إنشاؤها قبل أو بعد عام 2023 ضمن إعدادات البحث "أوراكل".
بالنسبة لمعظم الطرز ، باستثناء GPT-4 ، هناك اختلاف بسيط في الأداء قبل أو بعد هذا التاريخ.
**LLM ليس بديلا عن المبرمجين ، ولكن يمكنه تسريع سير العمل **
بعض مستخدمي الإنترنت لديهم آمال وآمال لمستقبل "النموذج العام".
هذا صحيح ، هذا ما أقوله. النموذج العام ليس جيدا بما يكفي للحصول على طول سياق واسع بما يكفي للترميز بمفرده ، باستثناء مقتطفات التعليمات البرمجية القصيرة نسبيا.
لكنني أعتقد أنها مسألة وقت فقط. أستطيع أن أتوقع أنه في المستقبل القريب ، سيصبح LLM العام مع تدريب محدد نموذجا احترافيا للغاية.
بدلا من تسريح الموظفين لتوفير المال ، دع المطورين ينجزون أشياء رائعة بسرعة فائقة!