2024 সালের আগস্টে আমরা প্রথম SWE-bench Verified প্রকাশ করার পর থেকে, ইন্ডাস্ট্রি জুড়ে এটি স্বায়ত্তশাসিত সফটওয়্যার ইঞ্জিনিয়ারিং কাজগুলিতে মডেলগুলোর অগ্রগতি পরিমাপ করতে ব্যাপকভাবে ব্যবহার করা হয়েছে. এটি প্রকাশের পর, SWE-bench Verified সক্ষমতার অগ্রগতির একটি শক্তিশালী সংকেত প্রদান করে এবং অত্যাধুনিক মডেল রিলিজে রিপোর্ট করা একটি মানসম্পন্ন মেট্রিক হয়ে ওঠে. এই সক্ষমতাগুলোর অগ্রগতি ট্র্যাক করা এবং পূর্বাভাস দেওয়াও OpenAI-এর প্রিপেয়ার্ডনেস ফ্রেমওয়ার্ক-এর একটি গুরুত্বপূর্ণ অংশ. যখন আমরা প্রথমে Verified বেঞ্চমার্ক তৈরি করি, তখন আমরা মূল মূল্যায়নের এমন সমস্যাগুলো সমাধান করার চেষ্টা করেছিলাম, যা SWE-bench ডেটাসেটে(একটি নতুন উইন্ডোতে খোলে) নির্দিষ্ট কিছু কাজ সম্পন্ন করা অসম্ভব করে তুলেছিল.
প্রাথমিক দ্রুত অগ্রগতির পর, 'SWE-bench Verified'-এ অত্যাধুনিক (State-of-the-art) উন্নয়নের গতি কিছুটা ধীর হয়ে এসেছে; গত ছয় মাসে এটি 74.9% থেকে বেড়ে 80.9%-এ উন্নীত হয়েছে(একটি নতুন উইন্ডোতে খোলে). এটি প্রশ্ন তোলে: অবশিষ্ট ব্যর্থতাগুলি কি মডেলের সীমাবদ্ধতা প্রতিফলিত করে, নাকি ডেটাসেটের নিজস্ব বৈশিষ্ট্য?
একটি নতুন বিশ্লেষণে, আমরা 'ভেরিফাইড সেট'-এর সঙ্গে দুটি প্রধান সমস্যা খুঁজে পেয়েছি, যা ইঙ্গিত করে যে আজকের পারফরম্যান্স স্তরে অত্যাধুনিক লঞ্চগুলির জন্য স্বায়ত্তশাসিত সফটওয়্যার ইঞ্জিনিয়ারিং সক্ষমতায় অগ্রগতি মাপার ক্ষেত্রে এই 'বেঞ্চমার্ক' আর উপযুক্ত নয়.
- পরীক্ষাগুলো সঠিক সমাধান প্রত্যাখ্যান করে: আমরা ডেটাসেটের এমন একটি 27.6% সাবসেট অডিট করেছি যা সমাধান করতে মডেলগুলো প্রায়ই ব্যর্থ হচ্ছিল; সেখানে দেখা গেছে যে, অডিট করা সমস্যাগুলোর অন্তত 59.4% ক্ষেত্রে ত্রুটিপূর্ণ 'টেস্ট কেস' রয়েছে. এই ত্রুটিপূর্ণ টেস্ট কেসগুলো মূলত কার্যকারিতার দিক থেকে সঠিক সমাধানগুলোকেও বাতিল করে দিচ্ছে - যদিও 'SWE-bench Verified' তৈরির প্রাথমিক পর্যায়ে আমরা এ ধরনের ত্রুটি সংশোধনে সর্বোচ্চ চেষ্টা করেছিলাম.
- সমাধানগুলির উপর প্রশিক্ষণ: যেহেতু বড় অত্যাধুনিক মডেলগুলো তাদের প্রশিক্ষণ থেকে তথ্য শিখতে পারে, তাই তারা যে সমস্যা ও সমাধানগুলির উপর মূল্যায়িত হয়, সেগুলির উপর কখনও প্রশিক্ষণ না দেওয়া গুরুত্বপূর্ণ. এটা অনেকটা পরীক্ষার আগে শিক্ষার্থীদের সঙ্গে আসন্ন পরীক্ষার সমস্যা ও সমাধান শেয়ার করার মতো - তারা হয়তো উত্তর মুখস্থ করবে না, কিন্তু যারা আগে উত্তরগুলো দেখেছে তারা অবশ্যই তাদের চেয়ে ভালো করবে যারা দেখেনি. SWE-bench সমস্যাগুলি ওপেন-সোর্স রিপোজিটরি থেকে নেওয়া হয়, যা অনেক মডেল প্রদানকারী প্রশিক্ষণের উদ্দেশ্যে ব্যবহার করে. আমাদের বিশ্লেষণে আমরা দেখেছি যে আমরা যে সমস্ত অত্যাধুনিক মডেল পরীক্ষা করেছি, সেগুলো সবই গ্রাউন্ড-ট্রুথ রেফারেন্স হিসেবে ব্যবহৃত মূল, মানুষের লেখা বাগ ফিক্স—যা গোল্ড প্যাচ নামে পরিচিত—অথবা নির্দিষ্ট কিছু কাজের ক্ষেত্রে সমস্যার বিবৃতির হুবহু নির্দিষ্ট তথ্য পুনরুত্পাদন করতে সক্ষম ছিল, যা ইঙ্গিত করে যে প্রশিক্ষণের সময় তাদের সবাই অন্তত কিছু সমস্যা ও সমাধান দেখেছে.
আমরা আরও প্রমাণ পেয়েছি যে প্রশিক্ষণের সময় যে মডেলগুলো সমস্যাগুলো দেখেছে, সেগুলোর সফল হওয়ার সম্ভাবনা বেশি, কারণ যথেষ্টভাবে নির্দিষ্ট করা হয়নি এমন টেস্টগুলো পাস করার জন্য প্রয়োজনীয় অতিরিক্ত তথ্য তাদের কাছে থাকে.
এর মানে হলো SWE-bench Verified-এ উন্নতিগুলো আর মডেলগুলোর বাস্তব-জগতের সফটওয়্যার ডেভেলপমেন্ট সক্ষমতায় অর্থবহ উন্নতি প্রতিফলিত করে না. পরিবর্তে, এগুলো ক্রমবর্ধমানভাবে প্রতিফলিত করে যে প্রশিক্ষণের সময় বেঞ্চমার্কের সাথে মডেলটি কতটা পরিচিত ছিল. এই কারণেই আমরা SWE-bench Verified স্কোর রিপোর্ট করা বন্ধ করেছি এবং আমরা সুপারিশ করি যে অন্যান্য মডেল ডেভেলপাররাও যেন একই কাজ করে.
আমরা কোডিং সক্ষমতাগুলি আরও ভালোভাবে ট্র্যাক করতে নতুন, দূষণমুক্ত ইভ্যালুয়েশন তৈরি করছি এবং আমরা মনে করি বৃহত্তর গবেষণা কমিউনিটির জন্য এটি ফোকাস করার একটি গুরুত্বপূর্ণ ক্ষেত্র. সেগুলো না পাওয়া পর্যন্ত, OpenAI SWE-bench Pro-এর জন্য ফলাফল রিপোর্ট করার সুপারিশ করে.
মূল SWE-bench(একটি নতুন উইন্ডোতে খোলে) মূল্যায়ন 2023 সালে প্রকাশিত হয়েছিল. প্রতিটি সমস্যা 12-টি ওপেন-সোর্স Python রিপোজিটরির মধ্যে একটির একটি সমাধানকৃত GitHub issue থেকে নেওয়া হয়েছে এবং সংশ্লিষ্ট পুল রিকোয়েস্ট (PR)-এর সাথে জোড়া করা হয়েছে. মডেলের তৈরি করা কোনো কোড পরিবর্তন সঠিক কি না তা নির্ধারণ করার জন্য, প্রতিটি সমস্যার সাথে দুই সেট 'টেস্ট' দেওয়া থাকে:
- অপরিবর্তিত কোডবেসে ব্যর্থ হয় কিন্তু সমস্যাটি সঠিকভাবে সমাধান করলে পাস করে এমন পরীক্ষা
- অসংশ্লিষ্ট কার্যকারিতা অক্ষত আছে তা নিশ্চিত করতে, সমাধানের আগে এবং পরে উভয় সময়েই পাস করে এমন রিগ্রেশন টেস্ট.
মডেলটি পরীক্ষাগুলো দেখতে পায় না. এটিকে শুধুমাত্র মূল ইস্যু টেক্সট এবং ফিক্সের আগে রিপোজিটরির অবস্থা দেওয়া থাকলে একটি কোড পরিবর্তন তৈরি করতে হবে. কোড পরিবর্তন প্রয়োগ করার পর সমস্ত টেস্ট পাস করলেই এটি একটি সমস্যা পাস করে.
আমরা সেই মূল্যায়নে অনেক সমস্যা খুঁজে পেয়েছি, যা মডেলগুলোর সক্ষমতা কম রিপোর্ট হওয়ার দিকে নিয়ে যেতে পারে.
- কিছু ইউনিট টেস্ট অতিরিক্তভাবে নির্দিষ্ট ছিল বা কাজটির সাথে অসামঞ্জস্যপূর্ণ ছিল, ফলে সঠিক ফিক্সগুলোও প্রত্যাখ্যাত হতে পারত.
- অনেক কাজের বিবরণ অস্পষ্ট ছিল, যার ফলে একাধিক সঠিক ব্যাখ্যা বা ইন্টারপ্রিটেশনের সুযোগ ছিল - অথচ পরীক্ষাগুলোতে কেবল একটি নির্দিষ্ট ব্যাখ্যাই যাচাই করা হয়েছে.
- পরিবেশের সেটআপের উপর নির্ভর করে (যেমন Linux বনাম Windows বা Python সংস্করণ), কিছু টেস্ট ভুলবশত ব্যর্থ হতে পারে.
এই সমস্যাগুলোর সমাধান করতে আমরা 2024 সালে SWE-bench Verified তৈরি করেছি. আমরা বিশেষজ্ঞ সফটওয়্যার ইঞ্জিনিয়ারদের সঙ্গে কাজ করে 1,699-টি SWE-bench সমস্যা পর্যালোচনা করেছি এবং যেসব সমস্যায় এই ধরনের সমস্যা ছিল সেগুলো বাদ দিয়েছি. প্রতিটি সমস্যা তিনজন বিশেষজ্ঞ দ্বারা স্বাধীনভাবে পর্যালোচনা করা হয়েছিল. এই পর্যালোচনা প্রক্রিয়ার ফলে SWE-bench Verified তৈরি হয়, যা 500-টি সমস্যার একটি কিউরেটেড সেট.
যদিও SWE-bench Verified প্রাথমিক সংস্করণের তুলনায় একটি বড় উন্নতি, তবুও কিছু অবশিষ্ট সমস্যা রয়ে গেছে. আমরা 138-টি SWE-bench Verified সমস্যার একটি অডিট পরিচালনা করেছি, যেগুলো OpenAI o3 64-টি স্বাধীন রান জুড়ে ধারাবাহিকভাবে সমাধান করতে পারেনি. প্রতিটি কেস অন্তত ছয়জন অভিজ্ঞ সফটওয়্যার ইঞ্জিনিয়ার দ্বারা স্বাধীনভাবে পর্যালোচনা করা হয়েছে. যদি কোনো বিশেষজ্ঞ কোনো সমস্যা চিহ্নিত করেন, তাহলে তা একটি অতিরিক্ত দল দ্বারা পুনরায় যাচাই করা হয়.
আমরা দেখেছি যে 138-টি সমস্যার মধ্যে 59.4% সমস্যায় টেস্ট ডিজাইন এবং/অথবা সমস্যা বর্ণনায় মৌলিক ত্রুটি ছিল, যা এগুলোকে এমনকি সবচেয়ে সক্ষম মডেল বা মানুষের পক্ষেও সমাধান করা অত্যন্ত কঠিন বা অসম্ভব করে তুলেছে.
- অডিট করা টাস্কগুলোর মধ্যে 35.5% ক্ষেত্রে দেখা গেছে যে, সেগুলোতে অত্যন্ত 'কঠোর টেস্ট কেস' রয়েছে যা সুনির্দিষ্ট কিছু প্রয়োগরীতির উপর জোর দেয়; ফলে কার্যকারিতার দিক থেকে সঠিক হওয়া সত্ত্বেও অনেক সাবমিশন বাতিল হয়ে যাচ্ছে—যাকে আমরা 'সংকীর্ণ টেস্ট কেস' (Narrow test cases) বলি.
- অডিট করা টাস্কগুলোর মধ্যে 18.8% ক্ষেত্রে দেখা গেছে যে, সেগুলোর 'টেস্ট' এমন কিছু অতিরিক্ত কার্যকারিতা যাচাই করছে যা মূল সমস্যার বর্ণনায় উল্লেখই ছিল না; এগুলোকে আমরা 'প্রশস্ত টেস্ট কেস' (Wide test cases) বলি.
- বাকি 5.1% কাজের মধ্যে বিভিন্ন ধরনের ইস্যু ছিল, যেগুলো এই ট্যাক্সোনমির সঙ্গে ভালোভাবে গ্রুপ করা যায়নি.
প্রথম ব্যর্থতার ধরনটির একটি ব্যাখ্যামূলক উদাহরণ হলো pylint-dev__pylint-4551(একটি নতুন উইন্ডোতে খোলে), যেখানে সামগ্রিক সমাধানের অংশ হিসেবে PR একটি নতুন ফাংশন `get_annotation` প্রবর্তন করে. এই ফাংশনের নামটি সমস্যা বিবরণে উল্লেখ করা নেই, তবে টেস্টগুলো এটি সরাসরি ইমপোর্ট করে. যদিও কিছু মডেল স্বতঃস্ফূর্তভাবে এমন একটি ফাংশন তৈরি করতে পারে, সমস্যাটি সঠিকভাবে সমাধান করতে এই নির্দিষ্ট নামের একটি ফাংশন বাস্তবায়ন করা কঠোরভাবে প্রয়োজনীয় নয়. অনেক বৈধ সমাধান ইমপোর্ট ত্রুটির কারণে পরীক্ষায় ব্যর্থ হয়.
সমস্যার বর্ণনা
PR টেস্ট স্নিপেট
PR টেস্টের ব্যর্থতাসমূহ (পঠনযোগ্যতার সুবিধার্থে সংক্ষেপিত)
অতিরিক্ত প্রশস্ত টেস্ট কেসগুলির একটি উদাহরণ হলো sympy__sympy-18199(একটি নতুন উইন্ডোতে খোলে). এই কাজটি একটি PR থেকে নেওয়া হয়েছে, যা `nthroot_mod` ফাংশনের তিনটি পৃথক সমস্যার সমাধান করেছিল, বিশেষভাবে #17373(একটি নতুন উইন্ডোতে খোলে), #17377(একটি নতুন উইন্ডোতে খোলে), এবং #18212(একটি নতুন উইন্ডোতে খোলে). তবে, SWE-bench Verified টাস্কের বর্ণনা কেবল চূড়ান্ত ইস্যু #18212(একটি নতুন উইন্ডোতে খোলে) কভার করে. এটি একটি অসামঞ্জস্য তৈরি করে: যেখানে PR টেস্টগুলো তিনটি সমস্যার সবকটিই কভার করে, সেখানে বর্ণনায় বিস্তারিতভাবে কেবল একটির কথা উল্লেখ আছে. আমাদের রানগুলোতে, মডেলগুলো প্রায়ই বর্ণিত সমাধানটি সঠিকভাবে বাস্তবায়ন করে এবং তারপর অন্য দুইটি সমস্যার জন্য ইমপ্লিমেন্টেশন কভার করে এমন টেস্টগুলোতে ব্যর্থ হয়.
মূল PR বিবরণ (GitHub PR থেকে)
#18212-এর জন্য সমস্যার বর্ণনা
SWE-bench Verified টাস্কের জন্য সমস্যার বিবরণ (শুধুমাত্র #18212 থেকে নেওয়া):
SWE-bench Verified এবং রিপোজিটরি (কোড বেস এবং রিলিজ নোট) উভয়ই ওপেন-সোর্স এবং ব্যাপকভাবে ব্যবহৃত ও আলোচিত, যা মডেল ডেভেলপারদের জন্য দূষণ এড়ানোকে কঠিন করে তোলে.
আমরা প্রথমে আমাদের নিজস্ব মডেলগুলিতে দূষণের লক্ষণ দেখতে পাই. উদাহরণস্বরূপ, যখন GPT‑5.2 31-টি কাজ সমাধান করেছিল, যেগুলোকে আমরা সমাধান করা প্রায় অসম্ভব বলে শনাক্ত করেছিলাম. django__django-14725(একটি নতুন উইন্ডোতে খোলে) -এ টেস্টগুলিতে একটি নির্দিষ্ট নতুন প্যারামিটার `edit_only` প্রয়োজন, যা সমস্যার বিবৃতিতে স্পষ্টভাবে প্রয়োজনীয় হিসেবে উল্লেখ করা হয়নি. সমস্যাটি সমাধান করার সময়, GPT‑5.2 তার চেইন-অফ-থট দেখায় যে কোডবেসে পরিবর্তনগুলির বিস্তারিত বর্ণনা করা রিলিজ নোট সম্পর্কে তার কাছে তথ্য আছে এবং সঠিকভাবে শনাক্ত করে যে `edit_only` প্যারামিটারটি Django 4.1-এ প্রবর্তিত হয়েছিল.
GPT‑5.2 CoT
দূষণ কতটা গুরুত্বপূর্ণ তা আরও বিস্তৃতভাবে মূল্যায়ন করতে, আমরা একটি স্বয়ংক্রিয় রেড টিমিং সেটআপ তৈরি করেছি. প্রতিটি SWE-bench Verified প্রশ্নের জন্য, আমরা GPT‑5‑কে GPT‑5.2‑Chat‑কে প্রোব করার দায়িত্ব দিয়েছিলাম. Claude Opus 4.5 এবং Gemini 3 Flash Preview দূষণ নির্ণয়ের জন্য. এই মডেলগুলো রিজনিং মডেলগুলোকে বাদ দেওয়ার জন্য বেছে নেওয়া হয়েছিল, তবে আমরা স্বীকার করি যে তাদের মধ্যে সম্ভবত একটি গুরুত্বপূর্ণ সক্ষমতার ব্যবধান রয়েছে.
দূষণ শনাক্ত করতে GPT‑5‑কে দেওয়া হয়েছিল: SWE-bench Verified টাস্কের ID, বিবরণ, গোল্ড প্যাচ এবং PR টেস্ট. 15-টি পর্যায় বা টার্ন জুড়ে, আমরা GPT‑5‑কে সিস্টেম/ডেভেলপার প্রম্পট, ইউজার প্রম্পট, অ্যাসিস্ট্যান্ট প্রি-ফিল এবং বিভিন্ন তথ্য-ফাঁস শনাক্তকরণ কৌশল পরিবর্তন করার সুযোগ দিয়েছিলাম. প্রতিটি টার্নের পরে, একটি বিচারক মডেল লেবেল করেছিল কতটা নতুন টাস্ক-নির্দিষ্ট তথ্য উপস্থিত ছিল এবং প্রতিটি প্রতিক্রিয়াকে “none” থেকে “strong” পর্যন্ত দূষণ তীব্রতার জন্য লেবেল করা হয়েছিল. GPT‑5‑কে আগের টার্নগুলোর ভিত্তিতে তার কৌশল খাপ খাইয়ে নিয়ে পুনরাবৃত্তিমূলকভাবে টাস্ক-নির্দিষ্ট বিস্তারিত তথ্য পুনরুদ্ধার করতে দেওয়া হয়েছিল. শক্তিশালী দূষণের প্রতিটি উদাহরণের জন্য, আমরা আরেকজন মূল্যায়নকারীর মাধ্যমে যাচাই করেছি যে GPT‑5 টার্গেট মডেলে খুব বেশি তথ্য ফাঁস করেনি. অবশেষে, এরপর আমরা এই পোস্টের ট্রান্সক্রিপ্টগুলো গঠন করে এমন “strong” উদাহরণগুলো ম্যানুয়ালি রিভিউ করেছি.
নিচে বিভিন্ন মডেল প্রদানকারীর মধ্যে শক্তিশালী দূষণের উদাহরণ দেওয়া হয়েছে.
টাস্ক বর্ণনা থেকে একটি ছোট স্নিপেট দেওয়া হলে, GPT‑5.2 সঠিক সমাধানটি আউটপুট করে. বিশেষ করে, এটি সঠিক ক্লাস এবং মেথডের নাম জানে, এবং নতুন প্রাথমিক রিটার্ন শর্ত `if username is None or password is None` যা প্রবর্তন করা হয়েছে.
টাস্ক আইডি: django__django-11451(একটি নতুন উইন্ডোতে খোলে)
দূষণ বা তথ্য-ফাঁস শনাক্তকরণ
গোল্ড প্যাচ
Opus কেবল ঐ PR-এ আনা 4-লাইনের সুনির্দিষ্ট কার্যকরী পরিবর্তন, ফাইলটির নাম এবং সংশ্লিষ্ট মেথডটিই মনে রাখতে সক্ষম নয়, বরং ডিফের (diff) অংশ হিসেবে থাকা ইনলাইন কমেন্টটিও হুবহু উদ্ধৃত করতে পারে.
টাস্ক আইডি: astropy__astropy-13236(একটি নতুন উইন্ডোতে খোলে)
দূষণ বা তথ্য-ফাঁস শনাক্তকরণ
গোল্ড প্যাচ
Gemini 3 Flash, যখন ID ছাড়া কাজটি সম্পর্কে আর কোনো অতিরিক্ত তথ্য দেওয়া হয় না, তখন কাজের বিবরণ এবং গোল্ড প্যাচ থেকে হুবহু বিস্তারিত আউটপুট করতে সক্ষম. এতে ইউজারনেম যাচাইকরণের জন্য নতুন regex ফর্মুলা এবং পরিবর্তনের জন্য সঠিক লাইন নম্বর অন্তর্ভুক্ত রয়েছে.
টাস্ক আইডি: django__django-11099(একটি নতুন উইন্ডোতে খোলে)
দূষণ বা তথ্য-ফাঁস শনাক্তকরণ
গোল্ড প্যাচ
SWE-bench Verified-এর এই অডিট থেকে, মূল্যায়ন নকশার জন্য আমরা দুটি বিস্তৃত শিক্ষা দেখতে পাই. প্রথমত, সর্বজনীনভাবে উপলব্ধ উপকরণ থেকে নেওয়া বেঞ্চমার্কগুলোতে দূষণের ঝুঁকি থাকে, যেখানে ট্রেনিং ডেটার সংস্পর্শ নীরবে স্কোর বাড়িয়ে দিতে পারে. যদি বেঞ্চমার্ক নির্মাণে সর্বজনীনভাবে ক্রল করা ডেটা ব্যবহার করা হয়, তাহলে মডেল ডেভেলপারদের দূষণ শনাক্ত করতে অতিরিক্ত পরীক্ষা করা উচিত. বেঞ্চমার্ক এবং এমনকি তাদের সমাধানও, প্রকাশ্যে পোস্ট করা হলে ট্রেনিং ডেটায় অন্তর্ভুক্ত হয়ে যেতে পারে. নিম্নোক্ত ক্ষেত্রে অতিরিক্ত সতর্কতা অবলম্বন করা উচিত যেখানে ডেটাসেটগুলো কিভাবে পোস্ট করা হচ্ছে (যেমন:— পাসওয়ার্ড সুরক্ষিত) এবং প্রশিক্ষণ ডেটা ফিল্টারিং (যেমন ক্যানারি স্ট্রিংগুলোর প্রতি কঠোরভাবে অনুসরণ).
দ্বিতীয়ত, স্বয়ংক্রিয় স্কোরিং সঠিকভাবে করা কঠিন; নিখুঁত পরীক্ষার কেসগুলো সঠিক কার্যকারিতা সম্পূর্ণভাবে যাচাই করা উচিত, যাতে সেগুলো নির্দিষ্ট, গুরুত্বহীন ইমপ্লিমেন্টেশন ডিটেইলসের প্রতি নিরপেক্ষ থাকে এবং শর্টকাট সমাধানের বিরুদ্ধেও দৃঢ় থাকে. এই সমস্যাগুলো স্বভাবতই জটিল এবং সমাধান করা কঠিন. এই সমস্যাগুলো শনাক্ত করতে একাধিক বিস্তৃত মানব লেবেলিং ক্যাম্পেইন করতে হয়েছে.
আমরা এই ফলাফলগুলো আমাদের সাম্প্রতিক মূল্যায়ন প্রচেষ্টায় অন্তর্ভুক্ত করেছি. গত কয়েক মাসে আমরা SWE-Bench Pro-এর পাবলিক স্প্লিট থেকে ফলাফল রিপোর্ট করার সিদ্ধান্ত নিয়েছি. আমরা অন্যান্য মডেল ডেভেলপারদেরও একই কাজ করতে সুপারিশ করি. SWE-bench Pro নিখুঁত নয়, তবে অভিজ্ঞতালব্ধভাবে মনে হয় এটি দূষণজনিত সমস্যায় তুলনামূলকভাবে কম ভোগে. আমাদের দূষণ শনাক্তকরণ পাইপলাইন কিছু দূষণের ঘটনা খুঁজে পেয়েছে, কিন্তু এই ঘটনাগুলি SWE-bench Verified-এর তুলনায় উল্লেখযোগ্যভাবে আরও বিরল এবং কম গুরুতর ছিল এবং কোনো মডেলই সম্পূর্ণ হুবহু গোল্ড প্যাচ তৈরি করতে সক্ষম হয়নি.
আমরা মৌলিক এবং ব্যক্তিগতভাবে তৈরি বেঞ্চমার্কগুলোতে বিনিয়োগ অব্যাহত রাখব এবং শিল্পখাত ও শিক্ষামহলের কাছেও একই পদক্ষেপ নেওয়ার জন্য আহ্বান জানাব. GDPVal-এ, কাজগুলো ডোমেন বিশেষজ্ঞদের দ্বারা ব্যক্তিগতভাবে প্রণীত হয়, যা এক্সপোজার ঝুঁকি কমায় এবং সমাধানগুলো প্রশিক্ষিত রিভিউয়ারদের দ্বারা সামগ্রিকভাবে মূল্যায়ন করা হয়. এই পদ্ধতিটি সম্পদ-নিবিড়, কিন্তু প্রকৃত সক্ষমতা উন্নতি পরিমাপের জন্য ক্রমবর্ধমানভাবে প্রয়োজনীয়.


