Одна из сложностей с 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. И получили такие числа:
Success rate
Iteration score
Average iterations
Time per project
Tokens spent
Tool calls
anthropic/claude-opus-4.6
anthropic/claude-sonnet-4.6
z-ai/glm-5.1
z-ai/glm-5
anthropic/claude-sonnet-4.5
moonshotai/kimi-k2.5
openai/gpt-5.4
openai/gpt-5.3-codex
google/gemini-3.1-pro-preview
openai/gpt-5.2-codex
google/gemini-3-flash-preview
z-ai/glm-4.7
qwen/qwen3.6-plus
minimax/minimax-m2.7
openai/gpt-5.1-codex
openai/gpt-5.1-codex-mini
z-ai/glm-4.6
qwen/qwen3-coder-next
deepseek/deepseek-v3.2
minimax/minimax-m2.5
z-ai/glm-4.5
Ну всё, теперь можно начинать холиварить в комментариях «кто лучше»!
Но можно вместо этого подойти чуть продуманнее и заметить, что нет единого «лучшего». Кому-то важнее качество любой ценой, кто-то заботится о расходе токенов, кому-то значима скорость. И если упорядочивать эту таблицу по разным колонкам, то и рейтинги получатся совсем разными.
А ещё можно с помощью этих чисел выводить другие интересные метрики. Например, токеноэффективность: если мы знаем общие результаты и количество токенов, какая модель даёт наибольший результат в пересчёте «на тысячу токенов»?
В результате, когда выходит очередная громкая модель и мир читает официальный блог-пост с тщательно выбранными числами, мы можем сразу прогнать наш бенчмарк с ней и понять что-то применительно к нашей практике.
Конечно, это даёт частичное знание, а не какое-то волшебное «абсолютное». В кодинге есть множество вещей, которые не посчитать конкретно этим бенчмарком. А некоторые и вовсе можно понять только при активном личном использовании.
К тому же нельзя сделать бенчмарк один раз и навсегда расслабиться, потому что модели становятся всё способнее. Когда мы создавали свой, большинство моделей справлялось лишь с частью заданий в нём. Но теперь флагманские модели выполняют все задания, и разница становится лишь в том, «какой ценой». Так что бенчмарки со временем надо обновлять и усложнять: и нам, и другим.
Но даже с таким частичным и временным знанием уже куда лучше, чем без него. Это помогает при работе с ИИ не двигаться «вслепую», а ориентироваться на конкретику. Очень полезная возможность, когда хочется не просто вайбкодить, а добиваться результатов профессионально.
Возможно, на Хабре кто-то тоже сталкивался с подобными вопросами и пришёл к своим решениям, соответствующим его сценариям? Было бы интересно послушать о них, пусть даже «общими словами», чтобы случайно не выдать LLM все наши секреты о том, как их оцениваем.
