Відокремлення сигналу від шуму в оцінюваннях коду

Точне вимірювання можливостей наших моделей важливе для обґрунтованих рішень щодо розгортання й безпеки, зокрема рішень у межах рамкової системи готовності⁠(відкривається у новому вікні) OpenAI. З кожним випуском моделі ми повідомляємо результати за низкою зовнішніх і внутрішніх бенчмарків, щоб відстежувати прогрес моделей. Коли в оцінюваннях є вади, що впливають на результати, вони можуть створювати хибне уявлення про можливості, спотворювати обґрунтування безпеки й впливати на дослідницькі пріоритети.

Нещодавно ми з’ясували, що один із найпоширеніших бенчмарків для програмування, SWE-bench Verified, мав фундаментальні проблеми дизайну й контамінації, і виявили, що це оцінювання більше не давало змістовного сигналу про можливості розробки програмного забезпечення. Тоді ми закликали ширшу спільноту перейти на SWE-Bench Pro.

SWE-Bench Pro⁠(відкривається у новому вікні) було розроблено як поліпшення SWE-bench Verified: він тестує моделі на довших горизонтах і реалістичніших завданнях кодування, щоб краще відстежувати можливості автономної розробки коду. Як і в SWE-bench Verified, завдання програмно беруться з історії змін функцій у наборі публічних і приватних репозиторіїв. Моделі мають реалізувати рішення, яке проходить нові тести для функції, не порушуючи наявну функціональність. На публічному розділі із 731 завдання передові моделі за вісім місяців підвищили частку успішних проходжень із 23,3% до 80,3%.

Відтоді ми провели подібний аудит SWE-Bench Pro, переглянувши набір даних за допомогою конвеєра аналізу точок даних. Конвеєр переглядав спроби моделі виконати завдання, метадані завдання й траси відмов, щоб позначити ймовірні вади оцінювання. Кожне позначене завдання потім оцінювали через кілька проходів агентів-дослідників і незалежно переглядали п’ять досвідчених інженерів-програмістів; розбіжності передавалися на подальше дослідження.

Проблеми переважно поділялися на чотири категорії:

• Надмірно суворі тести¹ вимагають конкретних деталей реалізації, не зазначених у запиті, через що багато функціонально правильних подань визнаються недійсними.
• Недостатньо визначені запити² пропускають вимоги, які застосовують приховані тести й які неможливо обґрунтовано вивести.
• Тести з низьким покриттям недостатньо перевіряють запитану функцію, тож неповні виправлення можуть пройти.
• Оманливий запит спрямовує моделі до неправильної поведінки або суперечить тому, що вимагають тести.

Наші висновки вказують на складність добору складних, але справедливих бенчмарків і на дедалі більшу корисність агентів для масштабованих перевірок якості даних. З огляду на ці результати ми оцінюємо, що приблизно 30% завдань SWE-bench Pro є зламаними, і радимо розробникам моделей уважно аналізувати результати.

Наша мета — забезпечити, щоб невдачі в завданнях відображали справжні обмеження моделі, а успіхи — повні й коректні рішення відповідно до вимог запиту. Щоб перевірити якість даних, використаних в оцінюванні, ми створили конвеєр забезпечення якості для оцінки того, чи кожна точка даних точно відображає можливості моделі.

Початковий автоматизований фільтр переглядає інструкції, надані моделі, спроби моделі розв’язати завдання та тести, використані для оцінювання цих спроб, щоб позначити ймовірно зламані або проблемні приклади. Цей фільтр позначив 286 потенційно зламаних завдань. Потім ми провели глибший перегляд цієї підмножини двома способами: перевіркою агентом під наглядом людини, що передбачає розширені перевірки агентами-дослідниками й остаточне людське судження; та кампанією людської анотації із залученням досвідчених розробників програмного забезпечення.

Кожну позначену проблему аудитують агенти-дослідники на основі Codex, яким надано доступ до репозиторію завдання та середовища. Це допомагає їм відрізняти обґрунтовану неоднозначність завдання, яку часто можна зняти, вивчивши сусідній код і конвенції репозиторію, від справжньої недовизначеності. Агент може запускати тести, переглядати файли в репозиторії та досліджувати спроби моделі й поширені режими відмов у цьому завданні. Після кількох незалежних повторень цих глибших аудитів дослідник переглянув підсумки, ухвалив остаточне рішення та позначив імовірні проблеми.

Паралельно ми провели кампанію людської анотації для позначеної підмножини. Ми працювали з досвідченими інженерами-програмістами, яких перед переглядом завдань навчили щодо цілей бенчмарку, класифікації проблем і крайових випадків. Кожне завдання переглядали п’ять інженерів.

Рецензенти формували незалежне судження на основі видимого формулювання проблеми, тестових випадків і еталонного референсного рішення (відомого як gold patch), перш ніж використовувати аналіз конвеєра або транскрипт як допоміжний контекст. Потім рецензенти призначали мітку й оцінку серйозності на основі конкретних доказів, а розбіжності або випадки з низькою впевненістю передавали на подальший перегляд.

Людські рецензенти частіше, ніж агенти-дослідники, позначали завдання як зламані. Між двома шляхами перевірки також були певні розбіжності щодо категорій, але в жодному позначеному завданні «не зламано» не було найпоширенішою людською міткою. Серед категорій, які позначив конвеєр агентів, судження рецензентів збігалися в 74% випадків.

Порівняно з конвеєром агентів, людські рецензенти також частіше обирали кілька міток для одного завдання, що вказує: вони вважали завдання зламаними кількома способами або такими, що не вкладаються чітко в одну категорію. Це свідчить, що конвеєр «агент плюс рецензент» дав консервативне маркування: він охопив ті самі широкі режими відмов, які виявили люди, але недорахував випадки, де рецензенти бачили додаткові або перехресні проблеми. Найбільша різниця стосувалася тестів із низьким покриттям: люди обрали їх як найпоширенішу проблему для 9,4% бенчмарку порівняно з 4,1% у конвеєрі агентів.

Виявлені нами проблеми разом із подібними випадками в SWE-bench Verified підкреслюють важливість ретельної перевірки бенчмарків. Issues і pull requests з репозиторіїв із відкритим кодом спершу створювалися для людської співпраці, часто через тривалі обговорення між мейнтейнерами та контриб’юторами. Тому описи проблем, змерджений код і модульні тести не завжди узгоджуються так, щоб утворити чисті, ізольовані завдання для надійного оцінювання моделей. Зокрема, тести, включені до pull requests, можуть бути надмірно суворими, бо їх пишуть для перевірки конкретної зміни, а не для визначення незалежного від реалізації стандарту розв’язання завдання.

Водночас вади оцінювання тепер виявляти легше, ніж це було б навіть зовсім недавно. У міру поліпшення можливостей моделей ми можемо використовувати ці моделі, щоб значно глибше й послідовніше перевіряти запити, тести, патчі, траси та крайові випадки, допомагаючи виявляти проблеми бенчмарків, які раніше було дорого або непрактично знаходити в масштабі.

Ми сподіваємося, що ширша спільнота оцінювання розроблятиме нові бенчмарки, створені досвідченими розробниками програмного забезпечення спеціально для тестування можливостей моделей. Такий підхід може зберегти високий стандарт і реалістичність, потрібні нам для вимірювання можливостей моделей, і забезпечує кращий людський нагляд протягом усього процесу. З огляду на проблеми, виявлені в цьому аналізі, ми відкликаємо нашу попередню рекомендацію впровадити SWE-Bench Pro.

Зрештою, оцінювання має давати змістовний сигнал через бенчмарки, які важко обійти, яким легко довіряти і які справді відображають можливості або вирівнювання моделі. Оскільки ці результати впливають на рішення OpenAI щодо розгортання й безпеки, оцінювання, які ми відстежуємо, мають бути валідними та інформативними.