Український техноподкаст УТ‑2, де ведучі Юрко, Саня та Ілля регулярно розбирають новини штучного інтелекту, цього разу почав розмову з теми, яка болить усій індустрії: чи можна ще вірити бенчмаркам великих мовних моделей і код‑агентів. Приводом стала історія з інструментом ForgCode, який опинився на вершині рейтингу кодінг‑тулів, але зробив це, як виявилося, не завдяки розуму моделі, а завдяки банальному хардкоду відповідей.
На цьому тлі ведучі говорять про системну проблему: більшість популярних LLM‑бенчмарків рано чи пізно опиняються в тренувальних датасетах моделей, перетворюючись із тесту на «шпаргалку». У такій реальності, на їхню думку, майже єдиним бенчмарком, якому ще можна довіряти, залишається LMSYS LLM Arena — саме тому, що вона спирається на людські порівняльні оцінки, а не на заздалегідь відомий набір задач.
ForgCode і «чарівний» ривок у топ: коли бенчмарк перемагає не модель, а конфіг
Історія з ForgCode виглядає як концентрований приклад того, наскільки легко сьогодні маніпулювати рейтингами AI‑інструментів. Інструмент для роботи з кодом, який до цього виглядав досить сумнівно й не мав помітної репутації серед розробників, раптом опинився номером один у бенчмарку для код‑агентів.
Йдеться про тест, який оцінює так звані «coding harnesses» — надбудови над LLM, що інтегруються в IDE або інші середовища розробки й допомагають моделі працювати з файлами, запускати команди, виконувати кроки плану. Умовно в цю категорію потрапляють інструменти на кшталт Cursor чи інших «розумних» оболонок навколо моделей.
У випадку ForgCode з’ясувалося, що розробники пішли найпростішим шляхом: вони захардкодили відповіді на конкретні завдання бенчмарку безпосередньо в конфігурацію агента. Тобто замість того, щоб дозволити моделі розв’язувати задачі, система фактично впізнавала знайому умову й повертала заготовлене рішення.
З технічної точки зору це виглядає як набір «if‑ів» у промптах або конфігурації: якщо вхідний опис задачі збігається з відомим шаблоном, агент не «думає», а просто підставляє готовий код. Для бенчмарку це виглядає як ідеальне виконання: висока точність, мінімум помилок, швидкий результат. Для реального користувача — як ілюзія якості, яка розсипається при першому ж нетиповому завданні.
Цей кейс підсвічує одразу кілька проблем.
По‑перше, бенчмарки код‑агентів часто мають фіксований набір задач, які легко вивчити й «зашити» в продукт. Якщо організатори тесту не контролюють, як саме інструмент приймає рішення, виявити хардкод складно.
По‑друге, високі позиції в рейтингах починають працювати як маркетинговий інструмент. Користувач бачить «№1 у бенчмарку X» і робить висновок про якість, не маючи можливості перевірити, чи не стоїть за цим набір спеціальних «костилів» під конкретний тест.
По‑третє, сама логіка бенчмарків без людської участі створює спокусу грати заради цифр, а не заради реальної якості. Якщо метрика — це просто відсоток успішно розв’язаних відомих задач, то хардкодинг стає не багом, а «опцією оптимізації».
Історія ForgCode показує: навіть перше місце в рейтингу код‑агентів сьогодні не гарантує, що інструмент буде корисним у живих сценаріях розробки. Навпаки, чим вищий тиск на позицію в таблиці, тим більше сенсу перевіряти, чи не стоїть за нею штучно натренована поведінка.
Коли бенчмарк стає тренувальним датасетом: системна хвороба LLM‑оцінювання
Проблема ForgCode — це лише симптом ширшого процесу. Ведучі звертають увагу на те, що з часом більшість популярних LLM‑бенчмарків опиняються в тренувальних датасетах самих моделей. Причини зрозумілі: відкриті набори задач, які всі використовують для порівняння, стають частиною публічного корпусу текстів, що збирають для навчання. У результаті модель не просто «бачила» ці задачі раніше — вона могла буквально вчитися на них.
У класичному машинному навчанні це називається «data leakage» — витік тестових даних у тренувальний набір. У випадку LLM це набуває масового характеру: бенчмарки публікуються на GitHub, обговорюються в блогах, цитуються в документації, потрапляють у великі веб‑архіви, які потім використовують для тренування нових поколінь моделей.
Наслідок очевидний: результати тестів перестають відображати реальну здатність моделей до узагальнення. Замість того, щоб вимірювати, наскільки добре LLM розуміє нові задачі, ми вимірюємо, наскільки добре вона запам’ятала старі.
Це особливо критично для код‑бенчмарків. Якщо модель багаторазово бачила один і той самий алгоритмічний пазл або типовий баг у коді, вона може відтворювати «правильну» відповідь без справжнього розуміння контексту. У реальному проєкті, де кодова база унікальна, а вимоги змінюються, така модель починає «ламатися» на дрібницях, хоча на папері виглядає блискуче.
Ведучі підкреслюють, що в такій ситуації бенчмарк перетворюється радше на показник натренованості на конкретні питання, ніж на тест інтелектуальної гнучкості. Чим популярніший бенчмарк, тим вища ймовірність, що він уже «зашитий» у ваги моделі. І тим менше сенсу сприймати його результати як об’єктивну оцінку.
Це створює парадокс: індустрія потребує стандартних тестів для порівняння моделей, але сам факт стандартизації робить ці тести мішенню для переобучення — як явного (через донавчання під конкретний бенчмарк), так і неявного (через потрапляння в загальний тренувальний корпус).
Чому бенчмарки без людей легко геймляться — від хардкоду до спеціального донавчання
На тлі історії ForgCode ведучі роблять ширший висновок: будь‑який бенчмарк без людської участі легко геймиться. І це стосується не лише хардкоду відповідей у конфігурації агента.
Перший спосіб маніпуляції — той самий, що використав ForgCode. Якщо набір задач фіксований і відомий, розробник може побудувати навколо моделі «оболонку», яка розпізнає конкретні формулювання й повертає заздалегідь підготовлені рішення. Формально модель «проходить» тест, але фактично її інтелектуальна участь мінімальна.
Другий спосіб — спеціальне донавчання моделі під конкретний бенчмарк. Якщо виробник має доступ до повного набору тестових задач, ніщо не заважає йому включити їх у fine‑tuning. У результаті модель не просто бачила ці задачі, а й оптимізувала свої ваги саме під них. На графіку це виглядає як стрибок точності, у маркетингових матеріалах — як «революційний прогрес», але з погляду реальної узагальнюваності це крок назад.
Третій, більш тонкий спосіб — налаштування промптів і системних інструкцій під структуру конкретного бенчмарку. Якщо відомо, як саме формулюються питання, які формати відповідей приймаються, які підзадачі найчастіше трапляються, можна оптимізувати поведінку агента так, щоб він «грав у тест», а не розв’язував задачу в загальному вигляді.
Усі ці підходи об’єднує одне: вони працюють лише тому, що бенчмарк є статичним, передбачуваним і повністю автоматизованим. Машина оцінює машину за фіксованими правилами, і розробник може підлаштуватися під ці правила, не покращуючи реальну якість.
Саме тому ведучі скептично ставляться до більшості сучасних LLM‑бенчмарків, особливо коли йдеться про код‑агентів. На їхню думку, без людської участі будь‑який тест рано чи пізно перетворюється на гру в «хто краще підмухлює», а не в «хто краще розв’язує задачі».
LLM Arena як виняток: сила людських порівняльних оцінок
На цьому тлі LMSYS LLM Arena виглядає майже аномалією. Ведучі прямо кажуть, що це єдиний бенчмарк, якому вони зараз готові довіряти. Причина — у принципово іншому підході до оцінювання.
LLM Arena побудована на людських порівняльних оцінках відповідей моделей. Користувачі бачать два варіанти відповіді на одне й те саме запитання, не знаючи, яка модель стоїть за кожною з них, і обирають кращу. На основі великої кількості таких парних порівнянь формується рейтинг.
У такій схемі немає фіксованого набору задач, який можна вивчити напам’ять. Питання генеруються живими людьми, їхня тематика й формулювання постійно змінюються, а сам процес оцінювання спирається на людське відчуття якості, а не на формальну відповідність еталонній відповіді.
Це різко знижує можливість геймінгу.
По‑перше, немає сенсу хардкодити відповіді: неможливо передбачити, які саме питання поставлять користувачі завтра.
По‑друге, спеціальне донавчання під Arena виглядає малоефективним: щоб «підлаштуватися», потрібно було б відтворити весь розподіл реальних запитів користувачів, а це вже й є завданням загального навчання моделі.
По‑третє, людські оцінки вловлюють нюанси, які важко формалізувати в класичних бенчмарках: ясність пояснення, коректність кроків міркування, відповідність тону, відсутність небезпечних порад. Модель, яка просто «вгадала» правильний рядок коду, але зробила це без контексту, може програти моделі, що дала більш осмислену, хоч і трохи довшу відповідь.
У результаті Arena перетворюється не на тест «запам’ятовування», а на тест «поведінки в дикій природі». Вона ближча до реального використання LLM, ніж до лабораторного експерименту. Саме тому ведучі вважають її наразі єдиним бенчмарком, який дає хоч якусь надійну картину відносної якості моделей.
Це не означає, що Arena ідеальна. Але в умовах, коли класичні бенчмарки масово витікають у тренувальні датасети й стають мішенню для хардкоду, будь‑яка система з людською участю виглядає кроком уперед.
Високі рейтинги проти реальності: чому розробникам доведеться знову тестувати руками
Комбінація кількох факторів — хардкодинг під бенчмарки, витік тестів у тренувальні дані, можливість спеціального донавчання — веде до неприємного висновку: довіра до цифр у таблицях стрімко девальвує. Історія ForgCode лише зробила це очевидним.
Для розробників це означає повернення до більш «ручних» методів оцінювання. Замість того, щоб орієнтуватися на позицію в рейтингу код‑агентів, доведеться знову запускати інструменти на власних проєктах, дивитися, як вони поводяться з реальною кодовою базою, як справляються з нетиповими помилками, як реагують на зміну вимог.
Бенчмарки при цьому не зникають, але змінюють роль. Вони стають не вироком, а початковим фільтром: індикатором того, що модель принаймні не повністю провальна. Остаточне рішення все одно доведеться приймати на основі живого досвіду.
У цьому сенсі LLM Arena задає корисний вектор: замість того, щоб шукати «ідеальний» автоматизований тест, індустрія, ймовірно, рухатиметься до гібридних схем, де машинні метрики поєднуються з людськими оцінками. Це дорожче й повільніше, але в умовах масового геймінгу бенчмарків іншого виходу може й не бути.
Історія з ForgCode нагадує: у світі, де моделі навчаються на всьому, що бачать, сам факт публікації бенчмарку робить його частиною тренувального середовища. Якщо тест можна завантажити з GitHub, його можна й «зашити» в модель або в оболонку навколо неї. А отже, справжнім маркером якості стає не місце в таблиці, а поведінка в живих, непередбачуваних сценаріях.
Висновок: ера «сліпої віри» в бенчмарки закінчилася
Скандал із ForgCode, який захардкодив відповіді на конкретні завдання бенчмарку, щоб стрибнути на вершину рейтингу, лише підсумував те, що давно назрівало. Більшість популярних LLM‑бенчмарків перетворилися з інструменту вимірювання на ще один тренувальний датасет. Моделі переобучаються на тестах, розробники геймлять метрики, а користувачі отримують красиві графіки, які мало що говорять про реальну якість.
На цьому тлі LMSYS LLM Arena виглядає рідкісним винятком — бенчмарком, який намагається відтворити реальне використання моделей через людські порівняльні оцінки. Він не захищений від усіх можливих маніпуляцій, але принаймні не зводиться до набору задач, які можна вивчити напам’ять або захардкодити в конфіг.
Для індустрії це сигнал: час перестати сприймати бенчмарки як остаточну істину. Вони залишаються корисним інструментом, але лише в поєднанні з живими тестами, людською експертизою та здоровим скепсисом. А для розробників, які обирають код‑агентів і LLM‑інструменти, головним критерієм стає не місце в рейтингу, а те, як модель поводиться у вашому власному репозиторії.
Джерело
Повна розмова доступна на YouTube: Бенчмарки — ФЕЙК, Claude ТУПІЄ, а ФБР читає ваш Signal та інші важливі новини! mvc #24