გადადით მთავარ შინაარსზე
OpenAI

კოდის შეფასებებში სიგნალის გამიჯვნა ხმაურისგან

დეტალური აუდიტით SWE-Bench Pro-ში დავალებებთან დაკავშირებულ გავრცელებულ პრობლემებს ვავლენთ და ვვარაუდობთ, რომ დავალებების ~30% ხარვეზიანია.

იტვირთება…

ჩვენი მოდელების შესაძლებლობების ზუსტად გაზომვა მნიშვნელოვანია დანერგვისა და უსაფრთხოების მხრივ საფუძვლიანი გადაწყვეტილებების მისაღებად, რაც მოიცავს OpenAI-ს მზაობის ჩარჩოს(იხსნება ახალ ფანჯარაში) ფარგლებში მიღებულ გადაწყვეტილებებსაც. ყოველი მოდელის გამოშვებისას ვაქვეყნებთ შედეგებს სხვადასხვა გარე და შიდა ბენჩმარკზე, რათა მოდელის პროგრესს მივადევნოთ თვალი. როცა შეფასებებში არის ხარვეზები, რომლებიც შედეგებზე მოქმედებს, ისინი შესაძლებლობებზე მცდარ წარმოდგენას ქმნის, დამახინჯებულად წარმოადგენს უსაფრთხოების შემთხვევებს და გავლენას ახდენს კვლევით პრიორიტეტებზე.

ჩვენ ახლახან გამოვიკვლიეთ, როგორ ჰქონდა ერთ-ერთ ყველაზე ფართოდ გამოყენებულ კოდის ბენჩმარკს, SWE-bench Verified-ს, ფუნდამენტური პრობლემები დიზაინისა და დაბინძურების მხრივ და დავადგინეთ, რომ ეს შეფასება პროგრამული უზრუნველყოფის განვითარების შესაძლებლობებზე არსებით სიგნალს აღარ იძლეოდა. იმ დროს ფართო საზოგადოებას SWE-Bench Pro-ზე გადასვლისკენ მოვუწოდეთ.

SWE-Bench Pro(იხსნება ახალ ფანჯარაში) შეიქმნა SWE-bench Verified ბენჩმარკის გასაუმჯობესებლად: ის მოდელებს უფრო გრძელ ჰორიზონტებზე და უფრო რეალისტურ პროგრამირების დავალებებზე ამოწმებს, რათა აგენტური პროგრამირების შესაძლებლობები უკეთ გაზომოს. როგორც SWE-bench Verified ბენჩმარკში, დავალებები პროგრამულად მიიღება საჯარო და კერძო რეპოზიტორიუმების ნაკრებში ფუნქციური ცვლილებების ისტორიიდან. მოდელებს მოეთხოვება, დანერგოს გადაწყვეტა, რომელიც ფუნქციის ახალ ტესტებს გაივლის ისე, რომ არსებულ ფუნქციონალს არ დააზიანებს. 731-დავალებიან საჯარო ნაწილზე მოწინავე მოდელებმა რვა თვეში წარმატებით გავლის მაჩვენებელი 23,3 %-დან 80,3%-მდე გააუმჯობესეს.

მას შემდეგ SWE-Bench Pro-ზეც ჩავატარეთ მსგავსი აუდიტი და მონაცემთა ნაკრები მონაცემთა წერტილების ანალიზის კონვეიერით განვიხილეთ. კონვეიერმა განიხილა მოდელის მცდელობები დავალებაზე, დავალების მეტამონაცემები და მარცხის კვლები, რათა სავარაუდო ხარვეზები მოენიშნა შეფასების მხრივ. შემდეგ თითოეული მონიშნული დავალება შეფასდა აგენტ-მკვლევრის რამდენიმე შემოწმების მეშვეობით და დამოუკიდებლად განიხილა პროგრამული უზრუნველყოფის ხუთმა გამოცდილმა ინჟინერმა; უთანხმოებები გადამისამართდა დამატებით გამოსაკვლევად.

მონაცემთა ნაკრების მნიშვნელოვან ნაწილში ხარვეზიანი საკითხების ნიშნებს ვპოულობთ. ჩვენმა მონაცემთა წერტილების ანალიზის კონვეიერმა 200 (27,4%) ხარვეზიანი დავალება გამოავლინა, ხოლო ადამიანების მონაწილეობით ჩატარებულმა ანოტაციის კამპანიამ — 249 (34,1%).

პრობლემები ძირითადად ოთხ კატეგორიაში მოექცა:

  • ზედმეტად მკაცრი ტესტები1 მოითხოვს იმპლემენტაციის ისეთი კონკრეტული დეტალების დაცვას, რომლებიც პრომპტში მითითებული არ არის, რითაც ბევრ ფუნქციურად სწორ ნამუშევარს აბათილებს.
  • არასაკმარისად დაზუსტებული პრომპტები2 არ ითვალისწინებს იმ მოთხოვნებს, რომლებსაც ფარული ტესტები აყენებს და რომლებიც არ არის გონივრულად გამოტანადი.
  • დაბალი დაფარვის ტესტები მოთხოვნილ ფუნქციას არასაკმარისად ამოწმებს, ამიტომ არასრულმა შესწორებებმა შეიძლება ტესტები წარმატებით გაიაროს.
  • შეცდომაში შემყვანი პრომპტი მოდელებს არასწორი ქცევისკენ უბიძგებს ან ეწინააღმდეგება იმას, რასაც ტესტები ითხოვს.

ჩვენი მიგნებები მიუთითებს რთული, მაგრამ სამართლიანი ბენჩმარკების კურირების სირთულეზე და მასშტაბირებადი მონაცემთა ხარისხის შემოწმებებისთვის აგენტების მზარდ სარგებლიანობაზე. ამ შედეგების გათვალისწინებით, ვაფასებთ, რომ SWE-bench Pro ბენჩმარკის დავალებების დაახლოებით ~30% ხარვეზიანია და მოდელების დეველოპერებს შედეგების გულდასმით შესწავლას ვურჩევთ.

მეთოდოლოგია

ჩვენი მიზანია, დავრწმუნდეთ, რომ დავალების მარცხები მოდელის ნამდვილ შეზღუდვებს ასახავს, ხოლო წარმატებები — პრომპტის პირობების სრულ და მართებულ გადაწყვეტებს. შეფასებაში გამოყენებული მონაცემების ხარისხის შესამოწმებლად შევქმენით ხარისხის უზრუნველყოფის კონვეიერი, რომელიც აფასებს, რამდენად ზუსტად ასახავს თითოეული მონაცემთა წერტილი მოდელის შესაძლებლობებს.

ხარისხის უზრუნველყოფის სამუშაო პროცესი, რომელიც ავტომატიზებულ სკრინინგსა და ადამიანის მიერ შესრულებულ მიმოხილვას აერთიანებს დავალებების ხარისხის შესაფასებლად.

საწყისი მონაცემთა ხარისხის კონვეიერი პრობლემებს განხილვისთვის მონიშნავს. მონიშნულ დავალებებს ვამოწმებთ აგენტის დახმარებით შესრულებული უფრო ღრმა აუდიტითა და ადამიანის ჩართულობით ჩატარებული ანოტაციის კამპანიით, რომელშიც გამოცდილი ინჟინრები მონაწილეობენ.

საწყისი ავტომატიზებული ფილტრი განიხილავს მოდელისთვის მიცემულ ინსტრუქციებს, მოდელის მცდელობებს დავალების ამოხსნის მხრივ და ამ მცდელობების შესაფასებლად გამოყენებულ ტესტებს, რათა სავარაუდო ხარვეზიანი ან პრობლემური მაგალითები მონიშნოს. ამ ფილტრმა 286 პოტენციურად ხარვეზიანი დავალება მონიშნა. შემდეგ ორნაირად ჩავატარეთ ამ ქვეჯგუფის უფრო ღრმა შემოწმება: აგენტების მეშვეობით ადამიანის ზედამხედველობის ქვეშ შემოწმება, რომელიც გულისხმობს ინტენსიურ შემოწმებას აგენტ-მკვლევრების მეშვეობით და ადამიანის მიერ საბოლოო გადაწყვეტილების მიღებას; და ანოტაციის კამპანია ადამიანის ჩართულობითა და გამოცდილი პროგრამისტების მონაწილეობით.

ადამიანის ზედამხედველობით ჩატარებული აგენტის მიმოხილვა

თითოეული მონიშნული პრობლემა მოწმდება Codex-ზე დაფუძნებული მკვლევარი აგენტებით, რომლებსაც დავალების რეპოზიტორიუმსა და გარემოზე წვდომა მიეცათ. ეს მათ ეხმარება, ნამდვილი არასაკმარისი დაზუსტებისგან განასხვაონ დავალების გონივრული ბუნდოვანება, რომელიც ხშირად ახლომდებარე კოდისა და რეპოზიტორიუმის კონვენციების შესწავლით წყდება. აგენტს შეუძლია ტესტების გაშვება, რეპოზიტორიუმში ფაილების დათვალიერება და დავალებაზე მოდელის მცდელობებისა და მათი საერთო მარცხის რეჟიმების გამოკვლევა. ამ უფრო ღრმა აუდიტების რამდენიმე დამოუკიდებელი გამეორების შემდეგ მკვლევარმა შეისწავლა შეჯამებები, გამოიტანა საბოლოო დასკვნა და სავარაუდო პრობლემებს იარლიყები მიანიჭა.

ადამიანის მეშვეობით შესრულებული ანოტაციის კამპანია

პარალელურად, მონიშნულ ქვეჯგუფზე ანოტაციის კამპანია ჩავატარეთ ადამიანის ჩართულობით. ვიმუშავეთ გამოცდილ პროგრამული უზრუნველყოფის ინჟინრებთან, რომლებმაც დავალებების განხილვამდე გაიარეს სწავლება ბენჩმარკის მიზნებზე, პრობლემების ტაქსონომიასა და ზღვრულ შემთხვევებზე. თითოეული დავალება ხუთმა ინჟინერმა შეამოწმა.

შემფასებლები დამოუკიდებელ დასკვნას აყალიბებდნენ ხილული პრობლემის აღწერიდან, ტესტების შემთხვევებიდან და ეტალონური საცნობარო გადაწყვეტიდან, რომელიც ცნობილია როგორც gold patch (ოქროს პატჩი), სანამ კონვეიერის ანალიზს ან ტრანსკრიპტს დამხმარე კონტექსტად გამოიყენებდნენ. შემდეგ შემფასებლები კონკრეტულ მტკიცებულებებზე დაყრდნობით ანიჭებდნენ იარლიყსა და სიმძიმის შეფასებას, ხოლო უთანხმოებებს ან დაბალი ნდობის შემთხვევებს დამატებით განსახილველად გზავნიდნენ.

ადამიანი შემფასებლები მკვლევარ აგენტებზე უფრო ხშირად ნიშნავდნენ დავალებებს ხარვეზიანად. შემოწმების ორ გზას შორის კატეგორიებშიც იყო გარკვეული უთანხმოება, მაგრამ არცერთ მონიშნულ დავალებაში ადამიანის მიერ გამოყენებული ყველაზე ხშირი იარლიყი არ ყოფილა „არ არის ხარვეზიანი“ . იმ კატეგორიებიდან, რომლებიც აგენტის კონვეიერმა მონიშნა, შემფასებლების დასკვნები შემთხვევების 74%-ში ემთხვეოდა.

აგენტის კონვეიერთან შედარებით, ადამიანი შემფასებლები უფრო ხშირად ირჩევდნენ რამდენიმე იარლიყს ერთი დავალებისთვის, რაც მიუთითებს, რომ ისინი დავალებებს რამდენიმე გზით ხარვეზიანად მიიჩნევდნენ ან ისინი ერთ კატეგორიაში მკაფიოდ არ ჯდებოდა. ეს მიუთითებს, რომ აგენტს დამატებული შემფასებლის ტიპის კონვეიერმა კონსერვატიული იარლიყები წარმოქმნა: მან დაიჭირა მარცხის იგივე ფართო რეჟიმები, რომლებიც ადამიანებმა გამოავლინეს, თუმცა ნაკლებად დათვალა შემთხვევები, სადაც შემფასებლები დამატებით ან ურთიერთგადამფარავ პრობლემებს ხედავდნენ. ყველაზე დიდი სხვაობა დაბალი დაფარვის ტესტებში იყო: ადამიანებმა ის ყველაზე გავრცელებულ პრობლემად ბენჩმარკის 9,4 %-ის შემთხვევაში აირჩიეს, მაშინ როცა აგენტის კონვეიერის მიერ დაფიქსირებული მაჩვენებელი 4,1 % იყო.

მარცხის რეჟიმები

რამდენიმე შემთხვევაში დავალების პრომპტი კონკრეტულ იმპლემენტაციას ითვალისწინებდა, მაგრამ ფარული ტესტი განსხვავებულ ქცევას ელოდა.

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

არცერთი

1
"[space]| Chapter 1 | 1"
2
"**[space]| Chapter 1 | 1"
3
"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

არცერთი

1
"[space][space]| Chapter 1 | 1"
2
"**[space][space]| Chapter 1 | 1"
3
"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

განხილვა

ჩვენ მიერ გამოვლენილი საკითხები, SWE-bench Verified-ში არსებულ მსგავს შემთხვევებთან ერთად, ბენჩმარკების მკაცრი შემოწმების მნიშვნელობას უსვამს ხაზს. ღია კოდის რეპოზიტორიუმებიდან აღებული პრობლემები და შერწყმის მოთხოვნები (pull requests) თავდაპირველად ადამიანებს შორის თანამშრომლობისთვის იქმნებოდა ხშირად ტექნიკურ სპეციალისტებსა (maintainers) და კონტრიბუტორებს (contributors) შორის ხანგრძლივი მიმოწერის გზით. ამის გამო პრობლემის აღწერები, შერწყმული კოდი და მოდულური ტესტები ყოველთვის არ ეწყობა სუფთა, იზოლირებულ დავალებებად, რომლებითაც მოდელების საიმედოდ შეფასება შეიძლება. კერძოდ, შერწყმის მოთხოვნებში (pull requests) შეტანილი ტესტები შეიძლება ზედმეტად მკაცრი იყოს, რადგან ისინი კონკრეტული ცვლილების დასადასტურებლად იწერება და არა დავალების ამოხსნისთვის იმპლემენტაციისგან დამოუკიდებელი სტანდარტის განსასაზღვრად.

ამავე დროს, შეფასების ხარვეზების აღმოჩენა ახლა უფრო ადვილია, ვიდრე თუნდაც ცოტა ხნის წინ იქნებოდა. მოდელების შესაძლებლობების გაუმჯობესებასთან ერთად შეგვიძლია, ეს მოდელები გაცილებით მეტი სიღრმითა და თანმიმდევრულობით გამოვიყენოთ მოთხოვნების, ტესტების, პატჩების, კვლებისა და ზღვრული შემთხვევების შესამოწმებლად, რაც გვეხმარება გამოვავლინოთ ბენჩმარკის პრობლემები, რომელთა მასშტაბურად პოვნა ადრე ძვირი ან არაპრაქტიკული იყო.

ვიმედოვნებთ, რომ შეფასების სფეროში ჩამოყალიბებული ფართო თემი შექმნის ახალ ბენჩმარკებს, რომლებსაც პროგრამული უზრუნველყოფის გამოცდილი დეველოპერები სპეციალურად მოდელების შესაძლებლობების შესამოწმებლად ააწყობენ. ამ მიდგომას შეუძლია შეინარჩუნოს ის მაღალი სტანდარტი და რეალიზმი, რომლითაც მოდელების შესაძლებლობების გაზომვა გვინდა, და პროცესის განმავლობაში უკეთესი ადამიანური ზედამხედველობა უზრუნველყოს. ამ ანალიზში გამოვლენილი პრობლემების გათვალისწინებით, ვაუქმებთ ჩვენს ადრინდელ რეკომენდაციას SWE-Bench Pro-ს დანერგვის შესახებ.

საბოლოოდ, შეფასებამ უნდა მოგვცეს არსებითი სიგნალი ისეთი ბენჩმარკების მეშვეობით, რომელთა მოტყუება რთულია, ნდობა ადვილია და რომლებიც ნამდვილად ასახავს მოდელის შესაძლებლობებს ან თანხვედრაში მოყვანას. რადგან ეს შედეგები გავლენას ახდენს OpenAI-ს გადაწყვეტილებებზე დანერგვისა და უსაფრთხოების მხრივ, მართებული და ინფორმაციული უნდა იყოს შეფასებები, რომლებსაც თვალს ვადევნებთ.

ავტორი

OpenAI

სქოლიოები

  1. 1

    ამ კატეგორიას ადრე ვიწრო ტესტებს ვუწოდებდით.

  2. 2

    ამ კატეგორიას ადრე ფართო ტესტებს ვუწოდებდით.