Как бенчмаркать ИИ, и как это делаем мы?

Одна из сложностей с LLM: как понять, какая модель способнее? Их создатели наперебой кричат «мы совершили революцию», но как пробиться сквозь хайп и измерить, кто чего реально добился?

Казалось бы, для этого есть много популярных бенчмарков. И о преимуществах моделей зачастую рассуждают со ссылками на них: «Смотрите, эта на 5% лучше». Однако с такими бенчмарками связан целый ряд проблем, и им нельзя слепо доверять.

А нам в Kodik важно разбираться, потому что мы делаем редактор кода с ИИ, так что должны понимать, какая модель в нём как себя покажет. И в результате мы не только смотрим на результаты чужих бенчмарков, но и создали для внутреннего использования свой KodikBenchmark.

Сегодня и рассказываем Хабру о состоянии индустрии в целом, и делимся частью информации о нашем бенчмарке, и показываем результаты разных моделей в нём. Если у вас есть схожий опыт, было бы интересно узнать о нём в комментариях.

---

Проблема 1: лукавая цифра

Когда выходит любая значимая версия LLM, в официальном посте можно увидеть не только громкие слова, но и «подтверждающие их числа». Мол, смотрите, как мы по бенчмаркам всех обогнали!

Но в красивых пресс-релизах встречается лукавство. Самый поразительный случай был на слайде с презентации GPT-5, где число 52.8 у новой модели как-то магически оказывалось «больше», чем 69.1 у старой:

Даже когда обходится без таких явных манипуляций, надо учитывать и другие факторы. Например, Y-ось на графиках зачастую начинают не от нуля. Так что при виде эффектного роста важно помнить, что если столбик «83%» втрое выше столбика «81%», это не значит «всё стало втрое лучше», это значит «график начали с 80%».

Ну и совсем простое: в официальных постах обычно показывают те бенчмарки, по которым модель получилась удачной, но молчат о тех, где результаты получились печальнее. В этом нет прямого вранья, но по такому не составишь полной картины.

Казалось бы, проблема решается просто: помимо официальных пресс-релизов, читать сторонние источники с разными бенчмарками. В сравнении разных источников действительно есть польза, однако и сторонние тексты тоже могут быть непоказательными из-за других проблем.

---

Проблема 2: что они вообще считают?

Часто можно прочитать что-то такое: «Новая модель набрала больше всех в Humanity’s Last Exam, TerminalBench и GDPval». Слова «последний экзамен человечества» звучат красиво. Получается, она самая лучшая?

Тут стоит задуматься «лучшая в чём именно». Что бенчмарки меряют-то? Например, три перечисленных оценивают совсем разные вещи:

• Humanity’s Last Exam — ответы по темам от биологии до математики

• Terminal-Bench — умение выполнять задачи в терминале

• GDPval — умение выполнять «задачи популярных профессий»

И тут возникает вопрос «а что важно вам». Например, если вы с помощью модели собираетесь писать код, то важно ли вам, как она отвечает на вопросы по биологии или выполняет задачи бухгалтера?

Получается, что многие бенчмарки лично для вас могут быть нерелевантны и только затруднять оценку. А вот бенчмарк про терминал полезен? Ну, в определённой степени да, но эта степень тоже зависит от ситуации.

Нельзя ведь измерить абстрактное «владение терминалом в вакууме». Можно измерить какие-то конкретные его проявления, как в Terminal-Bench. Там есть набор из 89 задач, например, таких:

• вот код, найди и устрани уязвимость

• вот картинка с шахматной доской, найди лучший ход за белых

• вот картинка с псевдокодом на ней, распознай и имплементируй по-настоящему

Задания любопытные, но тоже возникает вопрос: а способность «найти лучший ход за белых» лично вам пригодится? У разных людей очень разное использование терминала, и польза Terminal-Bench тоже будет различаться. Так что и тут по числу не стоит делать категоричные выводы, лишь частичные.

---

Проблема 3: data contamination

У создателей популярных бенчмарков возникает понятная сложность. Если просто сделать известный «набор вопросов с правильными ответами», то их будут активно публиковать и обсуждать в интернете. И тогда они попадут в датасеты, на которых обучаются новые модели.

А тогда модели могут уверенно давать ответы и получать высокие оценки, но это мало о чём будет говорить. Всё равно что заранее получить «правильные ответы» для экзамена и зазубрить их без понимания.

Ну да, на экзамене получишь высокую оценку. Но что будет в жизни, когда понадобится реальное понимание предмета, а вопросы будут отличаться от экзаменационных? И что полезного нам тогда сообщает такой экзамен?

Конечно, создатели бенчмарков в курсе этой проблемы, и применяют различные способы борьбы с ней. Но она пока что даёт о себе знать. Например, у бенчмарка GPQA в описании датасета прямо написано «мы просим вас не публиковать примеры из этого датасета плейнтекстом». Однако нет ведь способа заставить людей совсем этого не делать.

---

Проблема 4: ангажированность

Когда в Cursor представляют новую версию модели Composer, показывают результаты своего же бенчмарка CursorBench.

Есть логика в том, что они меряют модель способом, который считают самым точным. Но у пользователей возникает вопрос: а как проверить, что бенчмарк не «подкрутили» в пользу Composer? В результате на их анонсы порой отвечали этим мемом:

Но это ещё благополучный вариант. Тут по названию бенчмарка сразу можно понять, кто его делает, и самостоятельно решить, как относиться к результатам.

Хуже другая история. Когда OpenAI представляли новую модель, показывали результаты в бенчмарке FrontierMath. А потом выяснилось, что создание этого бенчмарка… финансировалось самой компанией OpenAI. Сам факт финансирования ещё не означает автоматически «бенчмарк неправильный» (как-то он даже присуждал больше очков конкурентам OpenAI). Но проблема в том, что связь скрывалась, и публично картину представляли так, будто измеряет модель абсолютно независимая сторона. В итоге это привело к скандалу и недоверию сообщества.

---

Проблема 5: benchmaxxing

Даже если бы не предыдущие проблемы, «результаты по бенчмаркам» всё равно могли бы не соответствовать «результатам в жизни». Почему?

Создатели моделей знают, что их будут оценивать популярными бенчмарками. Они хотят получить красивые числа. А значит, изо всех сил будут оптимизировать свои модели для этого. Отчасти это хорошо: модель в процессе получает реальные улучшения. Но эти улучшения могут оказываться очень неравномерными и непоказательными, а в итоге сбивать с толку.

Скажем, есть набор из 89 задач для терминала в Terminal-Bench, и все в лепёшку разбиваются, чтобы их модели выполняли как можно больше из этого набора. А есть другие задачи в терминале, о которых думают куда меньше. И может оказываться так, что модель отрастила мощнейшие мышцы для узкого круга задач, но за их пределами на ваших задачах «превращается в тыкву».

А тогда результат бенчмарка мало о чём говорит, помимо того, что создатели модели заморочились с оптимизацией под него. Всё превращается в бессмысленную гонку чисел, вроде старой «гонки мегапикселей» в телефонах.

В результате, например, ИИ-рисёрчер Андрей Карпатый в своих итогах 2025-го написал, что потерял веру в бенчмарки. Но вопрос «какая модель способнее» остаётся важным. И что тогда с ним делать?

---

Что с этим делать

Может показаться «если даже самые известные бенчмарки ненадёжны, то полезную информацию вообще не получить».

Но здесь есть интересный контринтуитивный момент. «Самые известные» не обязательно значит «самые показательные». У закрытых бенчмарков, которые в разных компаниях делают для внутреннего использования, есть свои преимущества:

• Если делаешь бенчмарк сам, создатели LLM не исказят его «в свою пользу».

• В нём можешь оценивать именно те способности моделей, которые полезны для тебя.

• Если не публикуешь его датасет в интернете, он не попадает в знания новых моделей.

• Если бенчмарк не нашумел на весь мир, крупные компании не будут искусственно оптимизировать свои модели под него.

Конечно, при этом создание хорошего бенчмарка — это не тривиальная задача на пять минут. Тут легко можно по ошибке намерять что-то не то, и тут нужно много над чем подумать. Так что для многих создание собственного может быть излишней вознёй.

Но для компании, которой особенно важно качество ИИ-моделей, это оправданная задача. А мы как раз такая компания, поскольку делаем редактор кода с ИИ. И поэтому сделали для внутреннего использования собственный бенчмарк.

---

KodikBenchmark

Как мы уже сказали, часть информации о частном бенчмарке (вроде конкретных заданий) не стоит публиковать, чтобы это не оказывалось в датасетах новых моделей. Но интересно рассказать об общих принципах, с которыми мы подошли к созданию своего: они могут быть полезны тем, кто тоже задумывается о подобном.

Просто броситься и «что-то посчитать» легко. И после выхода любой модели люди наперегонки постят разные числа. Порой довольно бессмысленные, вроде «количества строк кода», как будто его качество измеряется этим.

Но если хочется сделать по-настоящему полезный бенчмарк, надо сначала задаться рядом вопросов:

1. Что мы вообще хотим узнать?

Конкретно нам важно понимать, как разные LLM проявляют себя, когда люди используют их в Kodik. Насколько хорошо они помогают нашим пользователям добиваться своих целей?

И это сразу отличает наш подход от многих популярных бенчмарков.

Во-первых, часть из чужих измеряет «общий кругозор». Но люди используют редактор кода не для того, чтобы узнать ареал серой цапли. Так что нам необходимо сосредоточиться на программистском, а другие вещи только «зашумляли» бы результат.

Во-вторых, многие бенчмарки оценивают модели по «правильным ответам». Но теоретические ответы подходят для оценки чат-бота. А в редакторе кода ИИ-модели используют в агентском режиме: не чтобы они статьи из Википедии пересказывали, а чтобы действовали.

Значит, и наш бенчмарк должен проверять не теорию, а практику. Надо не устраивать викторину и пытаться подловить модели на различии мегабайта с мебибайтом, а ставить задачи и проверять, как модели справятся с ними.

2. А на каких задачах проверять?

Это непростой вопрос. Работа с кодом — вещь многогранная, и одним бенчмарком её не измерить целиком, а некоторые важные вещи и вовсе неизмеримы.

Но если всё же делать бенчмарк, с чем в нём обращаться к моделям?

Наш главный принцип такой: задачи должны быть как можно ближе к реальным. Поэтому используем не псевдокод, синтетические данные или вырванные из контекста строки кода, а маленькие, но цельные проекты.

И поэтому подаём задачу на вход в таких формулировках, с какими может обратиться реальный человек. То есть в промпте используется не какая-то искусственная спецификация на пять листов, а живой язык: «Сделай так, чтобы этот проект успешно собирался».

При этом, конечно, результат должен быть измерим. Задачи должны быть такими, чтобы можно было тестами определить «получилось или нет».

Поэтому типичная задача в датасете выглядит так: есть реальный код, содержащий заранее известную ошибку. От LLM требуется её исправить. Как именно исправлять — модели надо разобраться самой, изучая проект и применяя инструменты. В итоге у неё должен получиться код, проходящий тесты. А пока это не получится, она должна итерироваться: до победного конца или пока не израсходует выделенные ресурсы.

Так вместо общих умений «переворачивать деревья» проверяется практическая способность приносить конкретную пользу: какая модель лучше справится с заданием?

3. А что такое «лучше»?

Этот вопрос сложнее, чем может показаться по интернет-обсуждениям популярных бенчмарков. Там обычно говорят только о метрике «сколько задач модель осилила», выбирая лучшую по этому.

Но в жизни людей волнует не только «справилась ли LLM с задачей». Ещё их волнует, например, «сколько токенов она на это потратила».

Это производители LLM могут жечь токены без раздумий и говорить только о том, как много сделала их новая модель. А реальные пользователи Kodik могут рассуждать, например, так: «Сложную задачу поручу самой мощной модели, а на простеньких лучше сэкономлю».

А ещё важно и время выполнения задачи, и другие метрики. Результаты по разным могут очень различаться, лидеры получаются совершенно разные. То есть даже для одного пользователя разные модели могут оказываться «лучшими» в разных ситуациях». А уж для разных пользователей тем более.

И что тогда делать? На что смотреть, если нас волнуют все наши пользователи? Наш ответ в ответ в том, чтобы смотреть на всё:

— «Success rate»: с какой частью наших заданий модель справилась
— «Iteration score»: наша общая оценка её способностей, посчитанная по формуле
— Ряд отдельных метрик: потраченное время, потраченное количество токенов (такое приведено на графике в начале текста), и так далее

Сравнивая их все, можно понять «какую модель когда логичнее использовать». А без этого всё часто превращается в глупые холивары, когда людям просто хочется назвать одну «лучшей» и советовать всем для всего.

4. Как правильно считать?

Мы упомянули «общую оценку по формуле», а как её высчитываем? Опишем общие принципы без раскрытия полностью самой формулы.

Для нас важно не только «сколько задач удалось выполнить», но и «как именно». Например, одно дело, если модель с ходу всё правильно сделала, и совсем другое — если до успеха долго «ходила кругами», выжирая время и токены пользователя.

Поэтому, кроме факта успеха, мы учитываем в оценке ещё ряд факторов. Баллы там могут не только начисляться за то, что приближает к успеху, но и сниматься, если модель «пробуксовывает» или вносит ухудшения.

При этом важно понимать, что не существует «единственно верной» формулы. Кто-то другой мог бы решить несколько иначе учитывать вес разных факторов, и у него результаты получились бы немного отличающимися. Так что числа полезны, но не надо принимать их за высшую истину.

А также для нас важно базовое организационное правило: сама модель никогда не должна знать, сколько баллов она набирает в нашем бенчмарке.

Ведь известна проблема reward hacking: когда модель знает «нужный результат», она может достигать его «обходными путями». И в интернете можно прочитать о том, как во всех популярных бенчмарках находили лазейки, теоретически позволяющие добиться красивых чисел без реального выполнения нужных задач.

Так что мы просто говорим модели «выполни эту задачу», и она знает только об этой цели. А о дугих факторах оценки не знает, и задачи улучшать их ей в промпте никто не ставит. И тогда мы можем увидеть, насколько создатели модели смогли развить в ней эти способности.

И ещё важная организационная деталь. Если в своих сценариях считаешь полезным какой-то подход (например, использование определённого инструмента), то в своём бенчмарке можно награждать баллами за это, но при этом важно устанавливать «потолок» награды. Иначе получится бенчмарк, где возможно просто бессмысленно запустить один инструмент тысячу раз и получить баллов больше всех. Даже если модель не знает о баллах и не стремится их оптимизировать, это всё равно дыра.

5. Как правильно запускать?

Тут скажем в целом известные вещи, однако их тоже важно проговаривать. Потому что без них можно сделать бенчмарк с удачной задумкой, но получать в нём неправильные данные, и потом уверенно исходить из них.

Во-первых, для качественного сравнения важно, чтобы все модели оказывались в равных условиях. А если запускать бенчмарк просто на случайных компьютерах, отличающихся друг от друга, то их отличия могут вносить помехи. Тут полезна изолированная среда (sandbox), и мы используем Docker-контейнеры.

Во-вторых, желательно, чтобы эта среда была как можно ближе к «реальным». В нашем случае она сразу включает и ОС, и рантаймы языков, и менеджеры пакетов, и системы сборки, и фреймворки тестирования — то, что может быть установлено на настоящем компьютере, где ведётся разработка.

Также в этом «сэндбоксе» у нас сразу находятся проекты, в которых необходимо будет исправлять ошибки. Разные проекты используют разные технологические стеки: мы не хотим проверять кучей способов использование одного-единственного фреймворка.

---

Результаты бенчмарка

При подготовке этого поста мы ещё раз прогнали бенчмарк на актуальном наборе моделей — включая совсем свежую GLM-5.1 от Z.ai. И получили такие числа:

Ну всё, теперь можно начинать холиварить в комментариях «кто лучше»!

Но можно вместо этого подойти чуть продуманнее и заметить, что нет единого «лучшего». Кому-то важнее качество любой ценой, кто-то заботится о расходе токенов, кому-то значима скорость. И если упорядочивать эту таблицу по разным колонкам, то и рейтинги получатся совсем разными.

А ещё можно с помощью этих чисел выводить другие интересные метрики. Например, токеноэффективность: если мы знаем общие результаты и количество токенов, какая модель даёт наибольший результат в пересчёте «на тысячу токенов»?

---

Итоги

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

Конечно, это даёт частичное знание, а не какое-то волшебное «абсолютное». В кодинге есть множество вещей, которые не посчитать конкретно этим бенчмарком. А некоторые и вовсе можно понять только при активном личном использовании.

К тому же нельзя сделать бенчмарк один раз и навсегда расслабиться, потому что модели становятся всё способнее. Когда мы создавали свой, большинство моделей справлялось лишь с частью заданий в нём. Но теперь флагманские модели выполняют все задания, и разница становится лишь в том, «какой ценой». Так что бенчмарки со временем надо обновлять и усложнять: и нам, и другим.

Но даже с таким частичным и временным знанием уже куда лучше, чем без него. Это помогает при работе с ИИ не двигаться «вслепую», а ориентироваться на конкретику. Очень полезная возможность, когда хочется не просто вайбкодить, а добиваться результатов профессионально.

Возможно, на Хабре кто-то тоже сталкивался с подобными вопросами и пришёл к своим решениям, соответствующим его сценариям? Было бы интересно послушать о них, пусть даже «общими словами», чтобы случайно не выдать LLM все наши секреты о том, как их оцениваем.