62% من التعليمات البرمجية التي تم إنشاؤها بواسطة GPT-4 تحتوي على إساءة استخدام واجهة برمجة التطبيقات (API).
الملخص: في الآونة الأخيرة، أظهرت نماذج اللغات الكبيرة (LLMs) قدرة غير عادية على فهم اللغة الطبيعية وإنشاء كود البرمجة. من الشائع أن يستشير مهندسو البرمجيات LLMs عندما يواجهون أسئلة تتعلق بالبرمجة. على الرغم من الجهود المبذولة لتجنب الأخطاء النحوية ومواءمة الكود مع الدلالات المقصودة، إلا أن موثوقية وقوة إنشاء الكود من LLMs لم تتم دراستها بشكل متعمق بعد. التعليمات البرمجية القابلة للتنفيذ لا تعادل تعليمات برمجية موثوقة وقوية، خاصة في سياق تطوير البرامج الحقيقية. يمكن أن تؤدي إساءة استخدام واجهات برمجة التطبيقات في الكود الذي تم إنشاؤه إلى مشكلات خطيرة، مثل تسرب الموارد، وتعطل البرنامج، وهذا الرابط http يجعل الأسوأ من ذلك، أن مستخدمي خدمات إنشاء كود LLM هم في الواقع المطورون الأكثر عرضة لهذا الكود الذي يبدو صحيحًا: إنهم دائمًا المطورين المبتدئين الذين ليسوا على دراية بواجهات برمجة التطبيقات التي تنشئها لهم LLMs. ونتيجة لذلك، لم يتمكنوا من اكتشاف سوء استخدام التعليمات البرمجية التي تم إنشاؤها بواسطة LLM، مما يجعل من الأسهل تطبيق تعليمات برمجية غير صحيحة في برامج العالم الحقيقي. تركز معايير تقييم الكود ومجموعات البيانات الحالية على حل المهام الصغيرة مثل أسئلة البرمجة أثناء مقابلات البرمجة، والتي تنحرف عن المشكلة التي قد يطلبها المطورون من LLM للمساعدة في البرمجة في العالم الحقيقي. لملء الجزء المفقود، في هذا العمل، نقترح مجموعة بيانات RobustAPI لتقييم موثوقية وقوة التعليمات البرمجية التي تم إنشاؤها بواسطة LLMs. نقوم بجمع 1208 أسئلة ترميزية من StackOverflow على 24 واجهة برمجة تطبيقات Java تمثيلية. نقوم بتلخيص أنماط سوء الاستخدام الشائعة لواجهات برمجة التطبيقات هذه وتقييمها على LLMs الشائعة الحالية. تظهر نتائج التقييم أنه حتى بالنسبة لـ GPT-4، فإن 62% من التعليمات البرمجية التي تم إنشاؤها تحتوي على انتهاكات لواجهة برمجة التطبيقات (API)، مما قد يؤدي إلى عواقب غير مقصودة إذا تم إدخال التعليمات البرمجية في برنامج حقيقي.
الملخص: في الآونة الأخيرة، أظهرت نماذج اللغات الكبيرة (LLMs) قدرة غير عادية على فهم اللغة الطبيعية وإنشاء كود البرمجة. من الشائع أن يستشير مهندسو البرمجيات LLMs عندما يواجهون أسئلة تتعلق بالبرمجة. على الرغم من الجهود المبذولة لتجنب الأخطاء النحوية ومواءمة الكود مع الدلالات المقصودة، إلا أن موثوقية وقوة إنشاء الكود من LLMs لم تتم دراستها بشكل متعمق بعد. التعليمات البرمجية القابلة للتنفيذ لا تعادل تعليمات برمجية موثوقة وقوية، خاصة في سياق تطوير البرامج الحقيقية. يمكن أن تؤدي إساءة استخدام واجهات برمجة التطبيقات في الكود الذي تم إنشاؤه إلى مشكلات خطيرة، مثل تسرب الموارد، وتعطل البرنامج، وهذا الرابط http يجعل الأسوأ من ذلك، أن مستخدمي خدمات إنشاء كود LLM هم في الواقع المطورون الأكثر عرضة لهذا الكود الذي يبدو صحيحًا: إنهم دائمًا المطورين المبتدئين الذين ليسوا على دراية بواجهات برمجة التطبيقات التي تنشئها لهم LLMs. ونتيجة لذلك، لم يتمكنوا من اكتشاف سوء استخدام التعليمات البرمجية التي تم إنشاؤها بواسطة LLM، مما يجعل من الأسهل تطبيق تعليمات برمجية غير صحيحة في برامج العالم الحقيقي. تركز معايير تقييم الكود ومجموعات البيانات الحالية على حل المهام الصغيرة مثل أسئلة البرمجة أثناء مقابلات البرمجة، والتي تنحرف عن المشكلة التي قد يطلبها المطورون من LLM للمساعدة في البرمجة في العالم الحقيقي. لملء الجزء المفقود، في هذا العمل، نقترح مجموعة بيانات RobustAPI لتقييم موثوقية وقوة التعليمات البرمجية التي تم إنشاؤها بواسطة LLMs. نقوم بجمع 1208 أسئلة ترميزية من StackOverflow على 24 واجهة برمجة تطبيقات Java تمثيلية. نقوم بتلخيص أنماط سوء الاستخدام الشائعة لواجهات برمجة التطبيقات هذه وتقييمها على LLMs الشائعة الحالية. تظهر نتائج التقييم أنه حتى بالنسبة لـ GPT-4، فإن 62% من التعليمات البرمجية التي تم إنشاؤها تحتوي على انتهاكات لواجهة برمجة التطبيقات (API)، مما قد يؤدي إلى عواقب غير مقصودة إذا تم إدخال التعليمات البرمجية في برنامج حقيقي.
What's Your Reaction?
