ਅਗਸਤ 2024 ਵਿੱਚ ਅਸੀਂ ਪਹਿਲੀ ਵਾਰ SWE-bench Verified ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਸੀ, ਤਦੋਂ ਤੋਂ ਉਦਯੋਗ ਨੇ ਇਸਦਾ ਵਿਆਪਕ ਤੌਰ ‘ਤੇ ਖੁਦਮੁਖਤਿਆਰ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮਾਂ ‘ਤੇ ਮਾਡਲਾਂ ਦੀ ਤਰੱਕੀ ਮਾਪਣ ਲਈ ਇਸਤੇਮਾਲ ਕੀਤਾ ਹੈ। ਇਸਦੇ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, SWE-bench Verified ਨੇ ਸਮਰੱਥਾ ਤਰੱਕੀ ਦਾ ਇੱਕ ਮਜ਼ਬੂਤ ਸੰਕੇਤ ਦਿੱਤਾ ਅਤੇ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲ ਰਿਲੀਜ਼ਾਂ ਵਿੱਚ ਰਿਪੋਰਟ ਕੀਤਾ ਜਾਣ ਵਾਲਾ ਇੱਕ ਮਿਆਰੀ ਮੈਟਰਿਕ ਬਣ ਗਿਆ। ਇਨ੍ਹਾਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਭਵਿੱਖਬਾਣੀ ਕਰਨਾ OpenAI ਦੇ ਪ੍ਰਿਪੇਅਰਡਨੈਸ ਫ੍ਰੇਮਵਰਕ ਦਾ ਵੀ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ Verified ਬੈਂਚਮਾਰਕ ਬਣਾਇਆ, ਅਸੀਂ ਮੂਲ ਮੁਲਾਂਕਣ ਵਿੱਚ ਮੌਜੂਦ ਉਹ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਿਨ੍ਹਾਂ ਕਾਰਨ SWE-bench dataset(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਿੱਚ ਕੁਝ ਕੰਮ ਪੂਰੇ ਕਰਨਾ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ ਸੀ।
ਸ਼ੁਰੂਆਤੀ ਛਾਲਾਂ ਤੋਂ ਬਾਅਦ, SWE-bench Verified ‘ਤੇ state-of-the-art ਤਰੱਕੀ ਧੀਮੀ ਹੋ ਗਈ ਹੈ, ਅਤੇ ਪਿਛਲੇ 6 ਮਹੀਨਿਆਂ ਵਿੱਚ 74.9% ਤੋਂ 80.9% ਤੱਕ ਸੁਧਾਰ(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੋਇਆ ਹੈ। ਇਸ ਨਾਲ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਕੀ ਬਾਕੀ ਰਹਿ ਗਈਆਂ ਅਸਫਲਤਾਵਾਂ ਮਾਡਲ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਜਾਂ ਖੁਦ ਡਾਟਾਸੈੱਟ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ?
ਇੱਕ ਨਵੇਂ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ, ਅਸੀਂ Verified ਸੈੱਟ ਨਾਲ ਜੁੜੀਆਂ ਦੋ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲੱਭੀਆਂ ਜੋ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਅੱਜ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਪੱਧਰਾਂ ‘ਤੇ ਅਤਿ-ਆਧੁਨਿਕ ਲਾਂਚਾਂ ਲਈ ਖੁਦਮੁਖਤਿਆਰ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਰੱਥਾਵਾਂ ਦੀ ਤਰੱਕੀ ਮਾਪਣ ਲਈ ਇਹ ਬੈਂਚਮਾਰਕ ਹੁਣ ਉਚਿਤ ਨਹੀਂ ਰਹਿ ਗਿਆ:
- ਟੈਸਟ ਸਹੀ ਹੱਲਾਂ ਨੂੰ ਰੱਦ ਕਰਦੇ ਹਨ: ਅਸੀਂ ਡਾਟਾਸੈੱਟ ਦੇ 27.6% ਹਿੱਸੇ ਦਾ ਆਡਿਟ ਕੀਤਾ, ਜਿਸਨੂੰ ਮਾਡਲ ਅਕਸਰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕੇ, ਅਤੇ ਪਤਾ ਲਗਾਇਆ ਕਿ ਆਡਿਟ ਕੀਤੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ 59.4% ਵਿੱਚ ਖਰਾਬ ਟੈਸਟ ਕੇਸ ਹਨ ਜੋ ਕਾਰਗੁਜ਼ਾਰੀ ਪੱਖੋਂ ਸਹੀ ਸਬਮਿਸ਼ਨਾਂ ਨੂੰ ਰੱਦ ਕਰਦੇ ਹਨ, ਹਾਲਾਂਕਿ SWE-bench Verified ਦੀ ਸ਼ੁਰੂਆਤੀ ਰਚਨਾ ਦੌਰਾਨ ਅਸੀਂ ਇਸਨੂੰ ਸੁਧਾਰਨ ਲਈ ਆਪਣੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਸੀ।
- ਹੱਲਾਂ ‘ਤੇ ਟ੍ਰੇਨਿੰਗ: ਕਿਉਂਕਿ ਵੱਡੇ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲ ਆਪਣੀ ਟ੍ਰੇਨਿੰਗ ਤੋਂ ਜਾਣਕਾਰੀ ਸਿੱਖ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਜਿਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਹੱਲਾਂ ‘ਤੇ ਉਹਨਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਹਨਾਂ ‘ਤੇ ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਟ੍ਰੇਨ ਨਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਇਹ ਉਸੇ ਵਾਂਗ ਹੈ ਜਿਵੇਂ ਟੈਸਟ ਤੋਂ ਪਹਿਲਾਂ ਵਿਦਿਆਰਥੀਆਂ ਨਾਲ ਆਉਣ ਵਾਲੇ ਟੈਸਟ ਦੇ ਸਵਾਲ ਅਤੇ ਹੱਲ ਸਾਂਝੇ ਕਰ ਦਿੱਤੇ ਜਾਣ — ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਜਵਾਬ ਸ਼ਬਦਸ਼ಃ ਯਾਦ ਨਾ ਕਰਨ, ਪਰ ਜਿਨ੍ਹਾਂ ਵਿਦਿਆਰਥੀਆਂ ਨੇ ਪਹਿਲਾਂ ਜਵਾਬ ਵੇਖੇ ਹਨ ਉਹ ਬਿਨਾਂ ਵੇਖਣ ਵਾਲਿਆਂ ਨਾਲੋਂ ਜ਼ਰੂਰ ਚੰਗਾ ਕਰਨਗੇ। SWE-bench ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਓਪਨ-ਸੋਰਸ ਰਿਪੋਜ਼ਟਰੀਆਂ ਤੋਂ ਲਿਆਂਦੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਈ ਮਾਡਲ ਪ੍ਰਦਾਤਾ ਟ੍ਰੇਨਿੰਗ ਲਈ ਵਰਤਦੇ ਹਨ। ਆਪਣੇ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਅਸੀਂ ਲੱਭਿਆ ਕਿ ਜਿਨ੍ਹਾਂ ਵੀ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਦੀ ਅਸੀਂ ਜਾਂਚ ਕੀਤੀ, ਉਹ ਮੂਲ, ਮਨੁੱਖ-ਲਿਖਤ bug fix ਨੂੰ ਦੁਹਰਾ ਸਕਦੇ ਸਨ ਜੋ ground-truth reference ਵਜੋਂ ਵਰਤਿਆ ਗਿਆ ਸੀ, ਜਿਸਨੂੰ gold patch ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਕੁਝ ਕੰਮਾਂ ਲਈ ਸਮੱਸਿਆ ਵੇਰਵੇ ਦੀਆਂ ਸ਼ਬਦਸ਼ಃ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵੀ, ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਉਹਨਾਂ ਸਭ ਨੇ ਘੱਟੋ-ਘੱਟ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਹੱਲ ਵੇਖੇ ਸਨ।
ਅਸੀਂ ਇਹ ਵੀ ਸਬੂਤ ਲੱਭੇ ਕਿ ਜਿਨ੍ਹਾਂ ਮਾਡਲਾਂ ਨੇ ਟ੍ਰੇਨਿੰਗ ਦੌਰਾਨ ਸਮੱਸਿਆਵਾਂ ਵੇਖੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੀ ਸਫਲ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਅਧੂਰੇ ਤੌਰ ‘ਤੇ ਨਿਰਧਾਰਤ ਟੈਸਟ ਪਾਸ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਵਾਧੂ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ SWE-bench Verified ‘ਤੇ ਸੁਧਾਰ ਹੁਣ ਮਾਡਲਾਂ ਦੀਆਂ ਅਸਲੀ ਦੁਨੀਆ ਵਾਲੀਆਂ ਸੌਫਟਵੇਅਰ ਵਿਕਾਸ ਯੋਗਤਾਵਾਂ ਵਿੱਚ ਅਰਥਪੂਰਨ ਸੁਧਾਰ ਨਹੀਂ ਦਰਸਾਉਂਦੇ। ਇਸਦੀ ਬਜਾਏ, ਇਹ ਵੱਧ ਤੋਂ ਵੱਧ ਇਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਟ੍ਰੇਨਿੰਗ ਸਮੇਂ ਮਾਡਲ ਦਾ ਇਸ ਬੈਂਚਮਾਰਕ ਨਾਲ ਕਿੰਨਾ ਸਪਰਸ਼ ਹੋਇਆ ਸੀ। ਇਸੀ ਲਈ ਅਸੀਂ SWE-bench Verified ਸਕੋਰ ਰਿਪੋਰਟ ਕਰਨ ਬੰਦ ਕਰ ਦਿੱਤੇ ਹਨ, ਅਤੇ ਅਸੀਂ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਹੋਰ ਮਾਡਲ ਡਿਵੈਲਪਰ ਵੀ ਇਹੀ ਕਰਨ।
ਅਸੀਂ ਕੋਡਿੰਗ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਹੋਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਟ੍ਰੈਕ ਕਰਨ ਲਈ ਨਵੇਂ, ਬਿਨਾਂ ਕੰਟੈਮੀਨੇਸ਼ਨ ਵਾਲੇ ਮੁਲਾਂਕਣ ਤਿਆਰ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਸਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਵੱਡੇ ਖੋਜ ਸਮੁਦਾਇ ਲਈ ਇਸ ਖੇਤਰ ‘ਤੇ ਧਿਆਨ ਦੇਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਦ ਤੱਕ ਸਾਡੇ ਕੋਲ ਉਹ ਨਹੀਂ ਹੁੰਦੇ, OpenAI SWE-bench Pro ਲਈ ਨਤੀਜੇ ਰਿਪੋਰਟ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ।
ਮੂਲ SWE-bench(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਮੁਲਾਂਕਣ 2023 ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ। ਹਰ ਸਮੱਸਿਆ 12 ਓਪਨ-ਸੋਰਸ Python ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਵਿੱਚ ਹੱਲ ਕੀਤੇ ਗਏ GitHub issue ਤੋਂ ਲਈ ਗਈ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸੰਬੰਧਤ pull request (PR) ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਹੈ। ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਿ ਮਾਡਲ-ਤਿਆਰ ਕੀਤਾ ਕੋਡ ਬਦਲਾਅ ਸਹੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਹਰ ਸਮੱਸਿਆ ਨਾਲ ਦੋ ਕਿਸਮ ਦੇ ਟੈਸਟ ਹੁੰਦੇ ਹਨ:
- ਉਹ ਟੈਸਟ ਜੋ ਬਿਨਾਂ ਸੋਧੇ ਕੋਡਬੇਸ ‘ਤੇ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਪਰ issue ਸਹੀ ਤਰ੍ਹਾਂ ਫਿਕਸ ਹੋਣ ‘ਤੇ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ।
- Regression ਟੈਸਟ ਜੋ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੋਵਾਂ ਵੇਲੇ ਪਾਸ ਹੁੰਦੇ ਹਨ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣੇ ਕਿ ਅਸੰਬੰਧਤ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਭਾਵਿਤ ਨਾ ਹੋਵੇ।
ਮਾਡਲ ਨੂੰ ਟੈਸਟ ਨਹੀਂ ਦਿਖਾਏ ਜਾਂਦੇ। ਉਸਨੂੰ ਕੇਵਲ ਮੂਲ issue ਪਾਠ ਅਤੇ ਫਿਕਸ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਹਾਲਤ ਦੇ ਆਧਾਰ ‘ਤੇ ਇੱਕ ਕੋਡ ਬਦਲਾਅ ਬਣਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਉਹ ਕਿਸੇ ਸਮੱਸਿਆ ਨੂੰ ਤਦੋਂ ਹੀ ਪਾਸ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਡ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਾਰੇ ਟੈਸਟ ਪਾਸ ਹੋ ਜਾਣ।
ਸਾਨੂੰ ਉਸ ਮੁਲਾਂਕਣ ਵਿੱਚ ਕਈ ਸਮੱਸਿਆਵਾਂ ਮਿਲੀਆਂ ਜੋ ਮਾਡਲਾਂ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਘੱਟ ਦਿਖਾਉਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਸਨ।
- ਕੁਝ unit test ਬਹੁਤ ਹੀ ਖ਼ਾਸ ਸਨ ਜਾਂ ਕੰਮ ਨਾਲ ਠੀਕ ਤਰ੍ਹਾਂ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਸਨ, ਜਿਸ ਕਰਕੇ ਸਹੀ fix ਵੀ ਰੱਦ ਹੋ ਸਕਦੇ ਸਨ।
- ਕਈ ਕੰਮ ਵੇਰਵੇ ਅਧੂਰੇ ਤੌਰ ‘ਤੇ ਨਿਰਧਾਰਤ ਸਨ, ਜਿਸ ਕਾਰਨ ਕਈ ਵੈਧ ਵਿਆਖਿਆਵਾਂ ਸੰਭਵ ਸਨ — ਜਦਕਿ ਟੈਸਟ ਸਿਰਫ਼ ਇੱਕ ਖ਼ਾਸ ਵਿਆਖਿਆ ਨੂੰ ਹੀ ਕਵਰ ਕਰਦੇ ਸਨ।
- ਵਾਤਾਵਰਣ ਦੀ ਸੈਟਅੱਪ (ਉਦਾਹਰਨ ਲਈ 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% ਵਿੱਚ ਸਖ਼ਤ ਟੈਸਟ ਕੇਸ ਹਨ ਜੋ ਖ਼ਾਸ implementation ਵੇਰਵਿਆਂ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕਾਰਗੁਜ਼ਾਰੀ ਪੱਖੋਂ ਸਹੀ ਕਈ ਸਬਮਿਸ਼ਨ ਅਵੈਧ ਹੋ ਜਾਂਦੇ ਹਨ; ਅਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ narrow test cases ਕਹਿੰਦੇ ਹਾਂ।
- ਆਡਿਟ ਕੀਤੇ ਕੰਮਾਂ ਵਿੱਚੋਂ 18.8% ਵਿੱਚ ਅਜੇਹੇ ਟੈਸਟ ਹਨ ਜੋ ਵਾਧੂ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ ਜਿਸਦਾ ਜ਼ਿਕਰ ਸਮੱਸਿਆ ਵੇਰਵੇ ਵਿੱਚ ਨਹੀਂ ਸੀ; ਅਸੀਂ ਇਨ੍ਹਾਂ ਨੂੰ wide test cases ਕਹਿੰਦੇ ਹਾਂ।
- ਬਾਕੀ 5.1% ਕੰਮਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ ਜੋ ਇਸ ਵਰਗੀਕਰਨ ਵਿੱਚ ਠੀਕ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਾਉਂਦੀਆਂ ਸਨ।
ਪਹਿਲੀ ਅਸਫਲਤਾ ਵਿਧੀ ਦਾ ਇੱਕ ਉਦਾਹਰਨ pylint-dev__pylint-4551(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੈ, ਜਿੱਥੇ PR ਕੁੱਲ ਹੱਲ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਇੱਕ ਨਵਾਂ function `get_annotation` ਲਿਆਉਂਦਾ ਹੈ। ਇਸ function ਦਾ ਨਾਮ ਸਮੱਸਿਆ ਵੇਰਵੇ ਵਿੱਚ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ, ਪਰ ਟੈਸਟ ਇਸਨੂੰ ਸਿੱਧਾ import ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ ਕੁਝ ਮਾਡਲ ਅੰਦਾਜ਼ੇ ਨਾਲ ਅਜਿਹਾ function ਬਣਾ ਸਕਦੇ ਹਨ, ਪਰ ਸਮੱਸਿਆ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਨ ਲਈ ਇਸ ਖ਼ਾਸ ਨਾਮ ਵਾਲਾ function ਬਣਾਉਣਾ ਕੜੇ ਤੌਰ ‘ਤੇ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ। ਕਈ ਵੈਧ ਹੱਲ import errors ਕਾਰਨ ਟੈਸਟਾਂ ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਸਮੱਸਿਆ ਦਾ ਵੇਰਵਾ
PR ਟੈਸਟ ਸਨਿੱਪਟ
PR ਟੈਸਟ ਫੇਲ (ਪੜ੍ਹਨਯੋਗਤਾ ਲਈ ਸੰਖੇਪ)
ਬਹੁਤ ਵਿਆਪਕ ਟੈਸਟ ਕੇਸਾਂ ਦਾ ਇੱਕ ਉਦਾਹਰਨ sympy__sympy-18199(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੈ। ਇਹ ਕੰਮ ਇੱਕ ਅਜੇਹੇ PR ਤੋਂ ਲਿਆ ਗਿਆ ਸੀ ਜਿਸਨੇ `nthroot_mod` function ਨਾਲ ਜੁੜੀਆਂ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਸੀ, ਖ਼ਾਸ ਤੌਰ ‘ਤੇ #17373(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), #17377(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), ਅਤੇ #18212(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)। ਪਰ SWE-bench Verified ਕੰਮ ਦਾ ਵੇਰਵਾ ਸਿਰਫ਼ ਆਖਰੀ issue #18212(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਨੂੰ ਹੀ ਕਵਰ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਇੱਕ ਅਣਮੇਲ ਬਣਦਾ ਹੈ: PR ਟੈਸਟ ਤਿੰਨਾਂ issues ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ, ਜਦਕਿ ਵੇਰਵਾ ਸਿਰਫ਼ ਇੱਕ ਦਾ ਹੀ ਵਿਸਤਾਰ ਦਿੰਦਾ ਹੈ। ਸਾਡੇ ਰਨਾਂ ਵਿੱਚ, ਮਾਡਲ ਅਕਸਰ ਦਰਸਾਏ ਗਏ fix ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕਰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਬਾਕੀ ਦੋ issues ਦੀ implementation ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੇ ਟੈਸਟਾਂ ਵਿੱਚ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਮੂਲ PR ਵੇਰਵਾ (GitHub PR ਤੋਂ)
#18212 ਲਈ ਸਮੱਸਿਆ ਦਾ ਵੇਰਵਾ
SWE-bench Verified ਕੰਮ ਲਈ ਸਮੱਸਿਆ ਦਾ ਵੇਰਵਾ (ਸਿਰਫ਼ #18212 ਤੋਂ ਲਿਆ ਗਿਆ):
SWE-bench Verified ਅਤੇ ਰਿਪੋਜ਼ਟਰੀਆਂ (code bases ਅਤੇ release notes) ਦੋਵੇਂ ਹੀ ਓਪਨ-ਸੋਰਸ ਹਨ ਅਤੇ ਵਿਆਪਕ ਤੌਰ ‘ਤੇ ਵਰਤੀਆਂ ਅਤੇ ਚਰਚਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਕਰਕੇ ਮਾਡਲ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕੰਟੈਮੀਨੇਸ਼ਨ ਤੋਂ ਬਚਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅਸੀਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਹੀ ਮਾਡਲਾਂ ਵਿੱਚ ਕੰਟੈਮੀਨੇਸ਼ਨ ਦੇ ਸੰਕੇਤ ਵੇਖੇ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ GPT‑5.2 ਨੇ ਉਹ 31 ਕੰਮ ਹੱਲ ਕਰ ਲਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸੀਂ ਲਗਭਗ ਅਸੰਭਵ ਮੰਨਿਆ ਸੀ। django__django-14725(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਿੱਚ ਟੈਸਟ ਇੱਕ ਖ਼ਾਸ ਨਵੇਂ parameter `edit_only` ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ, ਜਿਸਦੀ ਸਮੱਸਿਆ ਵੇਰਵੇ ਵਿੱਚ ਸਪਸ਼ਟ ਲੋੜ ਨਹੀਂ ਦਿੱਤੀ ਗਈ। ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਿਆਂ, GPT‑5.2 ਆਪਣੀ chain of thought ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਸਨੂੰ release notes ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੈ ਜੋ codebase ਵਿੱਚ ਬਦਲਾਵਾਂ ਦਾ ਵੇਰਵਾ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਸਹੀ ਤੌਰ ‘ਤੇ ਪਛਾਣਦਾ ਹੈ ਕਿ `edit_only` parameter Django 4.1 ਵਿੱਚ ਲਿਆਂਦਾ ਗਿਆ ਸੀ।
GPT‑5.2 CoT
ਵਿਆਪਕ ਪੱਧਰ ‘ਤੇ ਕੰਟੈਮੀਨੇਸ਼ਨ ਕਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਹ ਜਾਣਚਣ ਲਈ ਅਸੀਂ ਇੱਕ ਸਵੈਚਾਲਿਤ red-teaming ਸੈਟਅੱਪ ਬਣਾਇਆ। ਹਰ SWE-bench Verified ਪ੍ਰਸ਼ਨ ਲਈ, ਅਸੀਂ GPT‑5 ਨੂੰ GPT‑5.2‑Chat, Claude Opus 4.5 ਅਤੇ Gemini 3 Flash Preview ਵਿੱਚ ਕੰਟੈਮੀਨੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਕੰਮ ਦਿੱਤਾ। ਇਹ ਮਾਡਲ ਇਸ ਲਈ ਚੁਣੇ ਗਏ ਕਿ ਰੀਜ਼ਨਿੰਗ ਮਾਡਲਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਜਾ ਸਕੇ, ਹਾਲਾਂਕਿ ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਇਨ੍ਹਾਂ ਵਿੱਚ ਸਮਰੱਥਾ ਦਾ ਅੰਤਰ ਸ਼ਾਇਦ ਨਗਣ ਨਹੀਂ ਹੈ।
ਕੰਟੈਮੀਨੇਸ਼ਨ ਦੀ ਜਾਂਚ ਲਈ GPT‑5 ਨੂੰ ਇਹ ਮਿਲਿਆ: SWE-bench Verified ਕੰਮ ਦਾ ID, ਵੇਰਵਾ, gold patch ਅਤੇ PR ਟੈਸਟ। 15 ਟਰਨਾਂ ਦੌਰਾਨ, ਅਸੀਂ GPT‑5 ਨੂੰ system/developer prompt, user prompt, assistant prefill ਅਤੇ ਵੱਖ-ਵੱਖ elicitation ਰਣਨੀਤੀਆਂ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਹਰ ਟਰਨ ਤੋਂ ਬਾਅਦ, ਇੱਕ judge model ਨੇ ਲੇਬਲ ਕੀਤਾ ਕਿ ਕਿੰਨੀ ਨਵੀਂ ਕੰਮ-ਵਿਸ਼ੇਸ਼ ਜਾਣਕਾਰੀ ਸਾਹਮਣੇ ਆਈ, ਅਤੇ ਹਰ ਜਵਾਬ ਨੂੰ ਕੰਟੈਮੀਨੇਸ਼ਨ ਦੀ ਤੀਬਰਤਾ ਲਈ “none” ਤੋਂ “strong” ਤੱਕ ਲੇਬਲ ਕੀਤਾ ਗਿਆ। GPT‑5 ਨੂੰ ਪਹਿਲਾਂ ਦੇ ਟਰਨਾਂ ਦੇ ਆਧਾਰ ‘ਤੇ ਆਪਣੀ ਰਣਨੀਤੀ ਢਾਲਣ ਦੀ ਇਜਾਜ਼ਤ ਸੀ ਤਾਂ ਜੋ ਦੁਹਰਾਏ ਜਾਂਦੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ-ਵਿਸ਼ੇਸ਼ ਵੇਰਵੇ ਹਾਸਲ ਕੀਤੇ ਜਾ ਸਕਣ। strong contamination ਦੇ ਹਰ ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਹੋਰ judge ਨਾਲ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ GPT‑5 ਨੇ ਟਾਰਗੇਟ ਮਾਡਲ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਾਣਕਾਰੀ ਲੀਕ ਨਹੀਂ ਕੀਤੀ। ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਉਹਨਾਂ “strong” ਉਦਾਹਰਨਾਂ ਦੀ ਹੱਥੋਂ ਸਮੀਖਿਆ ਕੀਤੀ ਜੋ ਇਸ ਪੋਸਟ ਵਿੱਚ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਦਾ ਹਿੱਸਾ ਹਨ।
ਹੇਠਾਂ ਵੱਖ-ਵੱਖ ਮਾਡਲ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚ strong contamination ਦੇ ਉਦਾਹਰਨ ਦਿੱਤੇ ਗਏ ਹਨ।
ਟਾਸਕ ਵੇਰਵੇ ਦੇ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਨੂੰ ਦੇਖ ਕੇ, GPT‑5.2 ਸਹੀ gold patch ਨਿਕਾਲ ਦਿੰਦਾ ਹੈ। ਖ਼ਾਸ ਤੌਰ ‘ਤੇ, ਉਸਨੂੰ ਠੀਕ class ਅਤੇ method name ਪਤਾ ਹੈ, ਅਤੇ ਨਵੀਂ early return condition `if username is None or password is None` ਵੀ, ਜੋ ਇਸ ਵਿੱਚ ਲਿਆਂਦੀ ਗਈ ਹੈ।
ਕੰਟੈਮੀਨੇਸ਼ਨ ਐਲਿਸਿਟੇਸ਼ਨ
ਗੋਲਡ ਪੈਚ
Opus ਨਾ ਸਿਰਫ਼ PR ਦੁਆਰਾ ਲਿਆਂਦੇ ਗਏ ਸਹੀ 4-ਲਾਈਨਾਂ ਵਾਲੇ ਕਾਰਗੁਜ਼ਾਰੀ ਬਦਲਾਅ ਨੂੰ ਯਾਦ ਕਰ ਸਕਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਹ ਖ਼ਾਸ filename ਅਤੇ method ਨੂੰ ਵੀ ਪਛਾਣਦਾ ਹੈ ਜਿਸਨੂੰ ਉਸਨੇ ਛੂਹਿਆ ਸੀ, ਸਗੋਂ diff ਦਾ ਹਿੱਸਾ ਰਹੀ inline comment ਨੂੰ ਵੀ ਸ਼ਬਦਸ਼ಃ quote ਕਰਦਾ ਹੈ।
ਕੰਟੈਮੀਨੇਸ਼ਨ ਐਲਿਸਿਟੇਸ਼ਨ
ਗੋਲਡ ਪੈਚ
Gemini 3 Flash, ਜਦੋਂ ਉਸਨੂੰ ID ਤੋਂ ਇਲਾਵਾ ਟਾਸਕ ਬਾਰੇ ਹੋਰ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ, ਟਾਸਕ ਵੇਰਵੇ ਅਤੇ gold patch ਤੋਂ ਵੇਰਵੇ ਸ਼ਬਦਸ਼ಃ ਨਿਕਾਲ ਸਕਦਾ ਹੈ। ਇਸ ਵਿੱਚ username validation ਲਈ ਨਵਾਂ regex formula ਅਤੇ ਬਦਲਾਅ ਲਈ ਸਹੀ line numbers ਵੀ ਸ਼ਾਮਲ ਹਨ।
ਕੰਟੈਮੀਨੇਸ਼ਨ ਐਲਿਸਿਟੇਸ਼ਨ
ਗੋਲਡ ਪੈਚ
SWE-bench Verified ਦੇ ਇਸ ਆਡਿਟ ਤੋਂ ਸਾਨੂੰ ਮੁਲਾਂਕਣ ਡਿਜ਼ਾਇਨ ਬਾਰੇ ਦੋ ਵੱਡੇ ਸਬਕ ਮਿਲਦੇ ਹਨ। ਪਹਿਲਾਂ, ਜਨਤਕ ਤੌਰ ‘ਤੇ ਉਪਲਬਧ ਸਮੱਗਰੀ ਤੋਂ ਬਣੇ ਬੈਂਚਮਾਰਕਾਂ ਵਿੱਚ ਕੰਟੈਮੀਨੇਸ਼ਨ ਦਾ ਖ਼ਤਰਾ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ ਐਕਸਪੋਜ਼ਰ ਚੁੱਪਚਾਪ ਸਕੋਰ ਵਧਾ ਸਕਦਾ ਹੈ। ਜੇ ਜਨਤਕ ਤੌਰ ‘ਤੇ crawl ਕੀਤੇ ਡਾਟੇ ਨੂੰ ਬੈਂਚਮਾਰਕ ਬਣਾਉਣ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਮਾਡਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੰਟੈਮੀਨੇਸ਼ਨ ਲਈ ਵਾਧੂ ਟੈਸਟ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਜਨਤਕ ਤੌਰ ‘ਤੇ ਪੋਸਟ ਕੀਤੇ ਬੈਂਚਮਾਰਕ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਉਹਨਾਂ ਦੇ ਹੱਲ ਵੀ, ਟ੍ਰੇਨਿੰਗ ਡਾਟੇ ਵਿੱਚ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਵਾਧੂ ਸਾਵਧਾਨੀ ਇਸ ਗੱਲ ਵਿੱਚ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਡਾਟਾਸੈੱਟ ਕਿਵੇਂ ਪੋਸਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਜਿਵੇਂ password protected) ਅਤੇ ਟ੍ਰੇਨਿੰਗ ਡਾਟਾ filtering ਵਿੱਚ (ਜਿਵੇਂ canary strings ਦੀ ਸਖ਼ਤ ਪਾਲਣਾ)।
ਦੂਜਾ, ਸਵੈਚਾਲਿਤ ਸਕੋਰਿੰਗ ਨੂੰ ਠੀਕ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ; ਆਦਰਸ਼ ਟੈਸਟ ਕੇਸਾਂ ਨੂੰ ਸਹੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਪੂਰੀ ਤਸਦੀਕ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਰਥਾਤ ਉਹ ਨਾ-ਮਹੱਤਵਪੂਰਨ implementation ਵੇਰਵਿਆਂ ਤੋਂ ਅਲੱਗ ਹੋਣ ਅਤੇ shortcut ਹੱਲਾਂ ਦੇ ਮੁਕਾਬਲੇ ਮਜ਼ਬੂਤ ਵੀ ਹੋਣ। ਇਹ ਸਮੱਸਿਆਵਾਂ ਸੁਭਾਵਕ ਤੌਰ ‘ਤੇ ਜਟਿਲ ਹਨ ਅਤੇ ਹੱਲ ਕਰਨਾ ਔਖਾ ਹੈ। ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਕੜਨ ਲਈ ਕਈ ਵਿਸਤ੍ਰਿਤ ਮਨੁੱਖੀ ਲੇਬਲਿੰਗ ਮੁਹਿੰਮਾਂ ਲੱਗੀਆਂ।
ਅਸੀਂ ਆਪਣੀਆਂ ਹਾਲੀਆ ਮੁਲਾਂਕਣ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਇਨ੍ਹਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰ ਲਿਆ ਹੈ। ਪਿਛਲੇ ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ ਅਸੀਂ SWE-Bench Pro ਦੇ ਜਨਤਕ split ਤੋਂ ਨਤੀਜੇ ਰਿਪੋਰਟ ਕਰਨੇ ਚੁਣੇ ਹਨ। ਅਸੀਂ ਹੋਰ ਮਾਡਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਵੀ ਇਹੀ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ। SWE-bench Pro ਪੂਰਾ ਨਹੀਂ ਹੈ, ਪਰ ਤਜਰਬੇਕਾਰੀ ਤੌਰ ‘ਤੇ ਇਹ ਕੰਟੈਮੀਨੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਘੱਟ ਪ੍ਰਭਾਵਿਤ ਲੱਗਦਾ ਹੈ। ਸਾਡੀ contamination pipeline ਨੇ ਕੁਝ contamination ਦੇ ਕੇਸ ਲੱਭੇ, ਪਰ ਇਹ ਕੇਸ SWE-bench Verified ਨਾਲੋਂ ਕਾਫ਼ੀ ਵਿਰਲੇ ਅਤੇ ਘੱਟ ਗੰਭੀਰ ਸਨ, ਅਤੇ ਕੋਈ ਵੀ ਮਾਡਲ ਪੂਰਾ ਸ਼ਬਦਸ਼ಃ gold patch ਨਿਕਾਲ ਨਹੀਂ ਸਕਿਆ।
ਅਸੀਂ ਮੂਲ, ਨਿੱਜੀ ਤੌਰ ‘ਤੇ ਲਿਖੇ ਬੈਂਚਮਾਰਕਾਂ ਵਿੱਚ ਨਿਵੇਸ਼ ਜਾਰੀ ਰੱਖਾਂਗੇ ਅਤੇ ਉਦਯੋਗ ਅਤੇ ਅਕਾਦਮਿਕ ਖੇਤਰ ਤੋਂ ਵੀ ਇਹੀ ਕਰਨ ਲਈ ਮਦਦ ਮੰਗਦੇ ਹਾਂ। GDPVal ਵਿੱਚ ਕੰਮ ਡੋਮੇਨ ਮਾਹਰਾਂ ਦੁਆਰਾ ਨਿੱਜੀ ਤੌਰ ‘ਤੇ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਐਕਸਪੋਜ਼ਰ ਦਾ ਖ਼ਤਰਾ ਘਟਦਾ ਹੈ, ਅਤੇ ਹੱਲਾਂ ਨੂੰ ਪ੍ਰਸ਼ਿਕਸ਼ਿਤ ਸਮੀਖਿਆਕਾਰਾਂ ਦੁਆਰਾ ਸਮੂਹਿਕ ਢੰਗ ਨਾਲ ਅੰਕਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਸਰੋਤ-ਗਾਹਕ ਹੈ, ਪਰ ਅਸਲ ਸਮਰੱਥਾ ਸੁਧਾਰਾਂ ਨੂੰ ਮਾਪਣ ਲਈ ਵਧਦੀ ਹੋਈ ਲਾਜ਼ਮੀ ਬਣ ਰਹੀ ਹੈ।


