Бенчмарк v1 від CodeVetter пропускає 27 синтетичних випадків через конвеєр перевірки коду на базі ШІ та фіксує, чи виявляє інструмент закладені помилки. Потім він підраховує кількість успішних або невдалих результатів для кожного випадку.

Чому цей бенчмарк важливий

Тест ставить вузьке питання: чи може конкретний рев'юер розпізнати саме ті дефекти, які розробники бенчмарка заклали в цей фіксований набір фрагментів коду? Розробники можуть використовувати результат як швидку перевірку охоплення проблем. Оскільки репозиторій містить пакети завдань і скрипт оцінювання, будь-хто може перезапустити тест і отримати ті самі показники.

Що бенчмарк не доводить

Синтетичний набір із 27 випадків не є заміною тисячам pull requests, з якими команда працює щодня. Бенчмарк нічого не говорить про:

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

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

Як цей бенчмарк вписується в ширшу екосистему тестування

Бенчмарки типу «розпізнавання», як-от у CodeVetter, визначають область застосування інструменту. Вони доповнюють функціональні бенчмарки, такі як SWE-bench, які перевіряють, чи справді патч, згенерований ШІ, вирішує реальну проблему в існуючій кодовій базі. Разом вони дають повнішу картину: охоплення проти ефективності.

Хороший бенчмарк агентів має розкривати повний стек:

  1. Набір даних — необроблені вхідні дані та очікувані результати.
  2. Документація для кожного випадку — сторінка для кожного тесту, що показує помилку, правильне виправлення та відповідь інструменту.
  3. Результати рев'юера — точні коментарі або пропозиції, які згенерував ШІ.
  4. Методологія оцінювання — як оцінюються відповідності, включаючи допуск для часткового зарахування.
  5. Інструкції щодо відтворюваності — фіксація версій, деталі обладнання та скрипти для повторного запуску тесту.

Тільки коли всі ці складові є прозорими, ми можемо довіряти єдиному агрегованому показнику.

Обмеження, які наводить сам бенчмарк

  • Синтетичні випадки, а не взяті з живих репозиторіїв.
  • Вузький вибір мов та типів помилок.
  • Відсутність даних про час або вартість, тому ефективність невідома.
  • Обмеження точності, які можуть приховувати граничні невдачі.

На що звернути увагу далі

Наступним кроком для CodeVetter — і для кожного, хто використовує ШІ-рев'юерів — є отримання повторних підтверджень на більших і різноманітніших корпусах даних. Це означає публікацію результатів на реальних потоках pull requests, звітування про затримку та споживання обчислювальних ресурсів, а також класифікацію режимів помилок за категоріями. Поки такі дані не з'являться, ставтеся до результату за 27 випадків як до раннього індикатора, а не як до гарантії готовності.

Висновок: Бенчмарк, який лише показує, чи може інструмент виявити кілька заздалегідь написаних помилок, корисний для перевірки адекватності, але він не гарантує, що інструмент витримає складнішу та чутливу до витрат реальність перевірки коду в production.