SWE-bench (benchmark) (BN)

From Systems analysis Wiki
Jump to navigation Jump to search

SWE-bench — এটি একটি বৃহৎ benchmark (পরীক্ষামূলক কাজের সংগ্রহ) যা বড় ভাষা মডেল (LLM)-গুলোর স্বয়ংক্রিয় সফটওয়্যার ডেভেলপমেন্ট ও ডিবাগিং সক্ষমতা মূল্যায়নের জন্য তৈরি করা হয়েছে[1]। এটি প্রিন্সটন বিশ্ববিদ্যালয় এবং অন্যান্য প্রতিষ্ঠানের একদল গবেষক দ্বারা তৈরি করা হয়েছিল এবং ICLR 2024 সম্মেলনে উপস্থাপিত হয়েছিল[2]। SWE-bench ঐতিহ্যবাহী কোড benchmark থেকে আলাদা কারণ এটি ডেভেলপমেন্ট অনুশীলনের বাস্তব কাজ ব্যবহার করে: পরীক্ষার সেটে GitHub-এর ১২টি জনপ্রিয় ওপেন-সোর্স Python রিপোজিটরি থেকে বন্ধ হওয়া সমস্যা (issue) এবং সংশ্লিষ্ট সংশোধন (pull request)-এর উপর ভিত্তি করে ২২৯৪টি কাজ রয়েছে[1][3]। প্রতিটি কাজে সমস্যার বিবরণ (issue) থাকে এবং মডেলকে সংশ্লিষ্ট প্রকল্পের সোর্স কোডে প্রবেশাধিকার দেওয়া হয়; মডেলের লক্ষ্য হলো কোডবেসে ন্যূনতম পরিবর্তন (patch) তৈরি করা যা নির্দিষ্ট সমস্যাটি সমাধান করবে[1][3]।

মূল্যায়নের পদ্ধতি ও বৈশিষ্ট্য

SWE-bench সফটওয়্যার ডেভেলপমেন্টের বাস্তব প্রক্রিয়াকে অনুকরণ করে। প্রতিটি কাজের জন্য মডেলকে মূল GitHub issue-এর পাঠ্য (সমস্যার বিবরণ) এবং সংশোধন প্রয়োগের আগের সংস্করণে রিপোজিটরি কোডের snapshot দেওয়া হয়[4]। মডেল (বা মডেল-ভিত্তিক agent)-কে সোর্স কোড বিশ্লেষণ করতে হয়, ত্রুটি বা প্রয়োজনীয় পরিবর্তনের প্রকৃতি বুঝতে হয় এবং সংশ্লিষ্ট কোড ফাইলে সম্পাদনা করে সমস্যাটি সমাধান করতে হয়[4][5]। সমাধান যাচাইকরণ স্বয়ংক্রিয়: প্রতিটি কাজের সাথে সেই সমস্যা বন্ধকারী pull request-এর বাস্তব unit test যুক্ত থাকে। এর মধ্যে রয়েছে «fail-to-pass» পরীক্ষা (যা মূল কোডে পাস হয় না, কিন্তু সঠিক সংশোধন প্রয়োগের পরে পাস হওয়া উচিত) এবং রিগ্রেশন পরীক্ষা (pass-to-pass, যা শুরু থেকে পাস হয় এবং পরিবর্তনের পরেও পাস হতে থাকা উচিত)[3]। মডেলের প্রস্তাবিত patch কোডে প্রয়োগ করা হয়, তারপর সংশ্লিষ্ট পরীক্ষাগুলো চালানো হয়: যদি সমস্ত fail-to-pass পরীক্ষা পাস হয় এবং pass-to-pass পরীক্ষাগুলো অব্যাহত থাকে, তাহলে কাজটি সঠিকভাবে সমাধান হয়েছে বলে বিবেচিত হয়[3]। মূল্যায়নের এই পদ্ধতি কেবল মডেলের সিনট্যাক্টিক্যালি সঠিক কোড তৈরির ক্ষমতাই নয়, বরং বিদ্যমান কার্যকারিতা ক্ষতি না করে সত্যিকারের কাজটি সমাধান করার দক্ষতাও যাচাই করে। একই সময়ে মডেলকে বড় প্রসঙ্গ (পুরো কোড রিপোজিটরি) নিয়ে কাজ করতে হয়, উপাদানগুলোর মধ্যে সম্পর্ক বুঝতে হয় এবং একসাথে একাধিক ফাইলে পরিবর্তনগুলো সমন্বয় করতে হয়[1] — এই সব কিছু বর্ণনা থেকে ফাংশন লেখার সাধারণ কাজের চেয়ে উল্লেখযোগ্যভাবে জটিল।

SWE-bench মূল্যায়নে সাধারণত শুধু LLM নয়, বরং এজেন্টিক সিস্টেম অংশগ্রহণ করে যা মডেলকে সহায়ক সরঞ্জাম (যেমন ফাইল নেভিগেশন, কোড এক্সিকিউশন, ডিবাগার ব্যবহার ইত্যাদি) দিয়ে মুড়িয়ে দেয়[4][6]। এই ধরনের সিস্টেম বাস্তব ডেভেলপমেন্ট চক্রের অনুকরণ করে: মডেল ক্রমাক্রমে ফাইল দেখতে পারে, পরীক্ষা বা স্ক্রিপ্ট চালাতে পারে এবং ধাপে ধাপে সমাধান উন্নত করতে পারে যতক্ষণ না সফল ফলাফল পৌঁছায়[4]। উল্লেখযোগ্যভাবে, SWE-bench কাজ সমাধানের কার্যকারিতা মূলত এই «scaffolding» (agent পরিকাঠামো)-এর মানের উপর নির্ভর করে: একই মূল মডেলগুলো রিপোজিটরি ও সরঞ্জামের সাথে মিথস্ক্রিয়া কীভাবে সংগঠিত তার উপর নির্ভর করে ভিন্ন ফলাফল দেখাতে পারে[4][7]। এভাবে, SWE-bench মডেল ও তার কাজ সমাধানের কৌশলের সমন্বিত সক্ষমতার পরিমাপক হিসেবে কাজ করে, মূল্যায়নকে স্বায়ত্তশাসিত AI ডেভেলপার-এর বাস্তব কাজের পরিস্থিতির কাছাকাছি নিয়ে আসে[4][7]।

কাজের সেটের রূপভেদ

SWE-bench-এর লেখক ও সম্প্রদায় পরবর্তীতে বিভিন্ন মূল্যায়ন উদ্দেশ্যে বেশ কয়েকটি ডেরিভেটিভ সেট উপস্থাপন করেছেন:

  • SWE-bench Lite — benchmark-এর একটি হালকা সংস্করণ যাতে ~৩০০টি কাজ রয়েছে[8], যা মডেল পরীক্ষার জটিলতা ও গণনামূলক ব্যয় কমাতে নির্বাচিত। এই উপসেটটি মডেলগুলোর দ্রুত পরীক্ষার জন্য তৈরি করা হয়েছিল এবং সবচেয়ে শ্রম-নিবিড় যাচাইকরণগুলো বাদ দেয়, মূল সমস্যাগুলোর প্রতিনিধিত্ব বজায় রেখে[7]। মূলত, Lite-এ সহজ ও ছোট বাগ ফিক্সের কাজ রয়েছে, এবং Lite-এ মডেলের ফলাফল সাধারণত পূর্ণ সেটের চেয়ে বেশি কারণ সবচেয়ে জটিল ক্ষেত্রগুলো বাদ দেওয়া হয়েছে[7]।
  • SWE-bench Verified — ম্যানুয়াল যাচাইকরণ দ্বারা ফিল্টার করা একটি উপসেট, যা ২০২৪ সালের আগস্টে OpenAI-এর সাথে যৌথভাবে উপস্থাপিত হয়েছিল[7]। গবেষকরা মূল benchmark-এর প্রতিটি কাজ বিশ্লেষণের জন্য ৯৩ জন পেশাদার ডেভেলপার নিয়োগ করেছিলেন এবং এমন ক্ষেত্রগুলো বাদ দিয়েছেন যেখানে মূল সমস্যার বিবরণ অত্যন্ত অস্পষ্ট বা পরীক্ষার দ্বারা প্রয়োজনীয় আচরণ কাজের শর্ত থেকে স্পষ্টভাবে উদ্ভূত হয় না[7]। পরিবেশগত সমস্যা বা ভুল পরীক্ষার কারণে বাস্তবে সমাধান করা সম্ভব নয় এমন কাজগুলোও বাদ দেওয়া হয়েছিল[7]। ফলস্বরূপ ৫০০টি কাজ নিয়ে একটি সেট তৈরি হয়েছে যা নিশ্চিতভাবে সমাধানযোগ্য ও সঠিকভাবে প্রণীত[7]। SWE-bench Verified মডেলের সক্ষমতার আরও নির্ভরযোগ্য মূল্যায়ন নিশ্চিত করতে চায়, এমন ক্ষেত্রগুলো দূর করে যেখানে সঠিক সমাধানও পরীক্ষা বা কাজের অপর্যাপ্ততার কারণে প্রত্যাখ্যাত হয়[7]। এই সেটটি মডেল তুলনার প্রধান মানদণ্ড হিসেবে মূল SWE-bench পরীক্ষার নমুনা (পূর্ণ এবং Lite উভয়)-কে প্রতিস্থাপন করেছে[7]। এছাড়াও, Verified-এর সাথে কাজের জটিলতার মূল্যায়ন প্রকাশিত হয়েছে (যেমন মানুষের জন্য <১৫ মিনিটে সমাধানযোগ্য «সহজ» এবং >১ ঘণ্টা প্রয়োজনীয় «কঠিন» কাজ চিহ্নিত করা হয়েছে)[7], এবং আরও স্থিতিশীল ও পুনরুৎপাদনযোগ্য পরীক্ষা চালানোর জন্য Docker-ভিত্তিক একটি নতুন টুলিং ফ্রেমওয়ার্কও প্রকাশিত হয়েছে[7]।
  • SWE-bench Multimodal — benchmark-এর একটি সম্প্রসারণ, যা ২০২৫ সালের জানুয়ারিতে উপস্থাপিত হয়েছিল, যেখানে এমন কাজ রয়েছে যেখানে সমস্যার বিবরণে শুধু পাঠ্য নয়, ভিজ্যুয়াল উপাদানও রয়েছে (যেমন ইন্টারফেস চিত্র, ত্রুটির স্ক্রিনশট ইত্যাদি)[8]। এই সেট (৫১৭টি কাজ[8]) প্রোগ্রামিং কাজ সমাধানে মডেল ও agent-গুলোর ভিজ্যুয়াল তথ্য বোঝার ও ব্যবহারের সক্ষমতা যাচাই করে। মাল্টিমোডাল সেটে মূল্যায়ন একইভাবে সংগঠিত, তবে মডেলের কাছ থেকে multi-modal সক্ষমতা (যেমন চিত্রে পাঠ্য স্বীকৃতি) প্রয়োজন। SWE-bench Multimodal-এর পরীক্ষার অংশ পরিচিত উত্তরের সাথে সমাধান মেলানো রোধ করতে বন্ধ (গোপন) রাখা হয়েছে; ডেভেলপাররা এই কাজগুলোতে তাদের মডেল মূল্যায়নের জন্য দূরবর্তী লিডারবোর্ডে সমাধান জমা দিতে পারেন[2]।

এই মূল রূপভেদগুলো ছাড়াও, SWE-bench-কে কেন্দ্র করে একটি সরঞ্জাম ইকোসিস্টেম গড়ে উঠেছে: SWE-agent — একটি ওপেন-সোর্স সফটওয়্যার «agent»-সমাধানকারী যা benchmark কাজে অগ্রণী ফলাফল প্রদর্শন করে[2]; SWE-smith — নিজস্ব ডেভেলপার-মডেল প্রশিক্ষণের জন্য একটি ফ্রেমওয়ার্ক; SWE-REX — রিপোজিটরি থেকে উন্নত তথ্য নিষ্কাশন ও প্রক্রিয়াকরণের একটি সরঞ্জাম ইত্যাদি। এই প্রকল্পগুলো ফলাফল পুনরুৎপাদন সহজ করতে এবং স্বায়ত্তশাসিত প্রোগ্রামিং সিস্টেমের গবেষণা এগিয়ে নিতে লক্ষ্য রাখে।

মডেলের ফলাফল ও অগ্রগতি

SWE-bench প্রথম আবির্ভাবে আধুনিক LLM এবং অভিজ্ঞ প্রোগ্রামারদের দক্ষতার মধ্যে একটি উল্লেখযোগ্য ব্যবধান উন্মোচন করেছিল। লেখকরা জানিয়েছিলেন যে ২০২৩ সালের শুরুর দিকের সবচেয়ে শক্তিশালী মডেলগুলোও মাত্র কয়েক শতাংশ কাজ সমাধান করতে পারত: উদাহরণস্বরূপ, Anthropic-এর Claude 2 মডেল পূর্ণ সেটের ২%-এরও কম কাজ সফলভাবে সমাধান করেছিল[1]। benchmark লেখকদের দ্বারা বিশেষভাবে প্রশিক্ষিত মডেল (LLaMA-ভিত্তিক, SWE-Llama নামে পরিচিত) এবং GPT-4-এর মতো মালিকানাধীন মডেলগুলো মূলত শুধুমাত্র সহজ ত্রুটিগুলো সমাধান করতে পারত[1]। এই প্রাথমিক নিম্ন মেট্রিকগুলো SWE-bench-এর জটিলতা তুলে ধরেছিল এবং নতুন পদ্ধতির উন্নয়নে অনুপ্রেরণা জুগিয়েছিল।

২০২৪ সালে আরও উন্নত মডেল ও এজেন্টিক স্কিম আসার সাথে সাথে ফলাফল উল্লেখযোগ্যভাবে উন্নত হয়েছে। Princeton-এর গবেষকরা SWE-agent সিস্টেম উপস্থাপন করেছেন যা GPT-4-কে কোড অনুসন্ধান, পরিকল্পনা ও অন্যান্য সরঞ্জামের সাথে একত্রিত করে; এটি পূর্ণ সেটে প্রায় ১২.৫% সমাধান কাজ অর্জন করেছে, একাডেমিক মডেলের জন্য একটি নতুন মানদণ্ড স্থাপন করেছে[5]। ২০২৪ সালের মাঝামাঝিতে, SWE-bench-এর অফিসিয়াল লিডারবোর্ডে সেরা সমাধানগুলো (মালিকানাধীনসহ) পূর্ণ benchmark-এ প্রায় ২০% এবং সরলীকৃত Lite সেটে ৪৩% পর্যন্ত সফল সমাধান অর্জন করেছে[7]। এই বৃদ্ধি মডেলের উন্নতির (যেমন GPT-4, Claude 2 ও 3-এর আবির্ভাব) এবং বিশেষত «scaffolding»-এর বিকাশের সাথে সম্পর্কিত — বাহ্যিক কৌশলগুলো যা মডেলকে কাজটি কার্যকরভাবে ধাপে বিভক্ত করতে, ডকুমেন্টেশন পড়তে, ডিবাগিং সেশন চালাতে ইত্যাদিতে সাহায্য করে[7]।

২০২৪ সালের শেষে Verified সেট (ভুল কাজ থেকে পরিষ্কৃত) চালু হওয়ার পরে পরিমাপযোগ্য কর্মক্ষমতা আরও বৃদ্ধি পেয়েছে। GPT-4 মডেল (GPT-4o ভেরিয়েন্ট) Verified-এ সাথে সাথে প্রায় ৩৩% সফল সমাধান দেখিয়েছে, যেখানে আগে মূল সেটে ~১৬% ছিল[7]। সেরা ওপেন-সোর্স agent ফ্রেমওয়ার্কগুলো (যেমন Agentless) Verified-এ ~১৬% থেকে ৩২%-এ তাদের ফলাফল দ্বিগুণ করেছে[7]। এটি নিশ্চিত করেছে যে মূল benchmark সমাধানযোগ্য নয় এমন ক্ষেত্রের কারণে ফলাফলকে কিছুটা কম দেখাচ্ছিল[7]। একই সময়ে Lite-এর তুলনায় Verified-এ ফলাফলের উন্নতি এতটা নাটকীয় নয় (সেরা মডেলগুলো ইতিমধ্যে Lite-এ ~৪৩% অর্জন করেছিল), যা যুক্তিসঙ্গত: Lite মূলত সহজ উদাহরণ নির্বাচন করেছিল, আর Verified অসম্ভব কাজগুলো বাদ দিয়েছে কিন্তু কঠিনগুলো রেখেছে[7]। গুরুত্বপূর্ণভাবে, Verified-এ যাওয়ার সময় ফলাফলের বৃদ্ধি কাজের জটিলতার সব বিভাগেই ঘটেছে, শুধু সবচেয়ে কঠিনগুলো দূর করার কারণে নয় — অর্থাৎ ফিল্টারিং তুলনামূলকভাবে সহজ কাজের মধ্যে থেকেও গোপনে অসমাধানযোগ্য ক্ষেত্রগুলো দূর করেছে[7]।

২০২৫ সালের শুরুতে শীর্ষস্থানীয় AI সিস্টেমগুলো যাচাইকৃত কাজের সেটে ইতিমধ্যে মানুষের কাছাকাছি কর্মক্ষমতা দেখাচ্ছে, যদিও ১০০%-এর সীমা এখনও দূরে। ২০২৫ সালের জানুয়ারিতে Anthropic জানিয়েছে যে তাদের নতুন Claude 3.5 Sonnet মডেল উন্নত agent-এর সাথে SWE-bench Verified-এর ৪৯% কাজ সমাধান করেছে[4], সাময়িকভাবে প্রথম স্থানে উঠে এসেছে। বড় প্রযুক্তি কোম্পানি ও স্বাধীন দলগুলোও এই benchmark-এ অনানুষ্ঠানিক প্রতিযোগিতায় সক্রিয়ভাবে অংশ নিচ্ছে। উদাহরণস্বরূপ, CodeStory দল বিকল্পগুলো অনুসন্ধানের সাথে একটি মাল্টি-মডেল পদ্ধতি («Midwit Agent») তৈরি করেছে যা Verified-এ রেকর্ড ৬২.২% সমাধান কাজ অর্জন করেছে (২০২৫ সালের শুরুর তথ্য)[5][9]। উল্লেখ করা হয়েছিল যে এর জন্য মডেল inference ধাপে (inference time scaling নামে পরিচিত) গণনামূলক সম্পদ উল্লেখযোগ্যভাবে বৃদ্ধি করতে হয়েছিল, অনেকগুলো সমাধানের প্রচেষ্টা চালিয়ে সেরা ফলাফল নির্বাচন করা হয়েছিল[5]। পাশাপাশি, OpenAI-এর উপকরণে পরীক্ষামূলক GPT-03 সিস্টেমের উল্লেখ ছিল, যা যথেষ্ট গণনা স্কেলিংয়ে Verified-এ ৭০%-এর সীমা অতিক্রম করেছে বলে জানা গেছে (অনানুষ্ঠানিক তথ্য)[5]। তবে এই ফলাফলের স্বাধীন যাচাইকরণ নেই, এবং এত উচ্চ সংখ্যা ভবিষ্যৎ গবেষণার দিকনির্দেশনার চেয়ে বরং অর্জিত মানদণ্ড হিসেবে কম বিবেচিত।

Microsoft Research-এর (২০২৫) গবেষণা অনুযায়ী, এমনকি সর্বশেষ মডেলগুলোও ডিবাগিং সরঞ্জাম দিয়ে সজ্জিত হলেও SWE-bench Lite থেকে বাগ সংশোধনের ৫০%-এর সীমা অতিক্রম করতে পারেনি[6]। এই পরীক্ষায় সেরা ছিল Claude 3.7 Sonnet যা ~৪৮.৪% কাজ সমাধান করেছে, যেখানে GPT-4 (OpenAI o1)-ভিত্তিক সিস্টেম প্রায় ৩০% এবং হালকা o3-mini মডেল মাত্র ২২% সমাধান করেছে[6]। এই ফলাফলগুলো জোর দেয় যে দ্রুত অগ্রগতি সত্ত্বেও আধুনিক AI এখনও অভিজ্ঞ প্রোগ্রামারদের চেয়ে পিছিয়ে: মানুষের জন্য এই ধরনের কাজ সমাধান (কোড বোঝার সাথে) কঠিন নয়, যেখানে মডেল প্রায়ই ডিবাগিং সরঞ্জাম কার্যকরভাবে ব্যবহার করতে পারে না বা বহু-ধাপের বাগ সংশোধন প্রক্রিয়া প্রতিফলিত প্রশিক্ষণ ডেটার অভাবে ভোগে[6]।

সীমাবদ্ধতা ও সম্ভাবনা

SWE-bench বুদ্ধিমান কোড agent মূল্যায়নের জন্য একটি মানসম্পন্ন প্ল্যাটফর্মে পরিণত হয়েছে, তবে গবেষণা এর বেশ কিছু সীমাবদ্ধতাও উন্মোচন করেছে। মূল সমস্যা হলো পরীক্ষার অসম্পূর্ণতা: প্রতিটি কাজের যাচাইকরণ পরীক্ষার সেট নির্দিষ্ট pull request থেকে নেওয়া হয় এবং সাধারণত শুধুমাত্র সেই unit test অন্তর্ভুক্ত করে যা বাগ ফিক্সের সময় পরিবর্তিত হয়েছিল[3]। ঝেজিয়াং বিশ্ববিদ্যালয় ও স্টুটগার্ট বিশ্ববিদ্যালয়ের বিজ্ঞানীদের (Wang et al. 2025) বিশ্লেষণ যেমন দেখিয়েছে, প্রকল্পের বাকি পরীক্ষাগুলো উপেক্ষা করা কিছু সমাধানের ভুলতা লুকিয়ে রাখতে পারে[3]। রিপোজিটরির পূর্ণ পরীক্ষার সেটে সমাধান পুনরায় যাচাই করে দেখা গেছে যে গড়ে SWE-bench-এ সফল হিসেবে চিহ্নিত ৭.৮% patch আসলে প্রকল্পের অন্যান্য পরীক্ষায় পাস হয় না[3]। এটি «সমাধান হয়েছে» মেট্রিককে প্রায় ৪-৬ শতাংশ পয়েন্ট পর্যন্ত বাড়িয়ে দেখায়[3]। আরও সূক্ষ্ম ক্ষেত্র হলো যখন তৈরি করা patch মূল পরীক্ষাগুলো পাস করে, কিন্তু এটি ডেভেলপারের সমাধানের সাথে সমতুল্য নয় এবং প্রত্যাশিতভাবে প্রোগ্রামের আচরণ পরিবর্তন করে না। অতিরিক্ত টেস্ট কেস তৈরির (PatchDiff পদ্ধতি) মাধ্যমে গবেষকরা আবিষ্কার করেছেন যে AI প্রস্তাবিত প্রায় ৩০% সংশোধন রেফারেন্স patch থেকে ভিন্নভাবে আচরণ করে, এবং প্রায় ১১% নিশ্চিতভাবে ভুল, যদিও বিদ্যমান পরীক্ষাগুলো দ্বারা সেগুলো ধরা পড়ে না[3]। এভাবে, সীমিত পরীক্ষার সেট পাসের উপর নির্ভর করলে মডেলের বাস্তব সক্ষমতা অতিমূল্যায়িত হতে পারে। SWE-bench-এর নির্মাতারা এই দুর্বলতা স্বীকার করেন এবং জোর দেন যে benchmark সময়ের সাথে বিকশিত হওয়া উচিত: পরীক্ষার কভারেজ উন্নত হওয়া, অবাঞ্ছিত পার্শ্ব প্রতিক্রিয়ার অনুপস্থিতির যাচাইকরণ যোগ করা, কাজের ধরনের সংগ্রহ সম্প্রসারিত হওয়া উচিত[7]। এই ধরনের মূল্যায়ন মাধ্যমের উন্নয়ন ক্রমবর্ধমান স্বায়ত্তশাসিত ও শক্তিশালী AI ডেভেলপারদের আবির্ভাবের প্রস্তুতির একটি গুরুত্বপূর্ণ অংশ, এবং SWE-bench-এর অভিজ্ঞতা benchmark-এর মানের প্রতি সতর্ক মনোযোগের প্রয়োজনীয়তা দেখায়[7]।

SWE-bench শুধুমাত্র একটি স্থির কাজের সেট হওয়া সত্ত্বেও প্রোগ্রামিংয়ের প্রতিটি দিক কভার করে না, কিন্তু এটি ইতিমধ্যে কোড মডেলের তুলনামূলক বিশ্লেষণের জন্য ডি-ফ্যাক্টো মানদণ্ড হয়ে উঠেছে[3]। এটি বৈজ্ঞানিক কাজে নতুন পদ্ধতি ও অ্যালগরিদম প্রদর্শনে এবং শিল্প গবেষণা দলগুলোর দ্বারা প্রোগ্রামিং স্বয়ংক্রিয় করতে সক্ষম সিস্টেমের সম্ভাবনা মূল্যায়নে ব্যবহৃত হয়[3]। ২০২৩-২০২৫ সালে SWE-bench-এ ফলাফলের ক্রমাগত বৃদ্ধি ব্যবহারিক ডেভেলপমেন্ট কাজ সমাধানে LLM সক্ষমতার দ্রুত উন্নতি স্পষ্টভাবে প্রদর্শন করে। একই সময়ে এটি জটিলতার মানদণ্ড হিসেবে কাজ করে: ৫০-৬০% সমাধান হওয়া কাজের কাছে পৌঁছেও, মডেলগুলো এখনও মানুষের পূর্ণ প্রতিস্থাপন থেকে দূরে, বিশেষত সীমিত তথ্যের পরিস্থিতিতে ও সূক্ষ্ম প্রয়োজনীয়তা বোঝার প্রয়োজনে[4][7]। তবুও, অগ্রগতি থামছে না — SWE-bench-এর মতো উদ্যোগের কারণে সম্প্রদায় তাদের লক্ষ্য ও সীমাবদ্ধতা স্পষ্টভাবে দেখতে পাচ্ছে, এবং একজন মানব বিশেষজ্ঞের স্তরে স্বায়ত্তশাসিতভাবে প্রোগ্রাম কোড বোঝা ও সংশোধন করতে সক্ষম একটি পূর্ণাঙ্গ AI ডেভেলপার তৈরির দিকে এগিয়ে চলেছে[4][7]।

তথ্যসূত্র

  • GitHub-এ SWE-bench
  • SWE-bench-এর অফিসিয়াল লিডারবোর্ড

সাহিত্য

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

টীকা

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [১]
  2. ↑ 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [২]
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [৩]
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [৪]
  5. ↑ 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [৫]
  6. ↑ 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [৬]
  7. ↑ 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [৭]
  8. ↑ 8.0 8.1 8.2 «SWE-bench Leaderboard». [৮]
  9. ↑ «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [৯]
Retrieved from "https://systems-analysis.info/int/index.php?title=SWE-bench_(benchmark)_(BN)&oldid=6516"