Как измеряют LLM: параметры, бенчмарки и тесты на коленке

В комментариях к моей предыдущей статье о тестировании трех флагманских LLM моделей были примерно такие мысли и вопросы:

• Я взял простую бесплатную LLM, запустил локально и она тоже справилась.

• А почему вы в свое сравнение не взяли никого от DeepSeek, они же тоже хороши?

• А зачем всем один и тот же промпт, они же по-разному их воспринимают?

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

В этой статье я хочу рассказать про общий подход к определению мощности моделей и пройтись по нюансам. Потом покажу самые популярные бенчмарки. И, наконец, расскажу, на что смотрят в бытовых тестах. Думаю, это будет правильно, прежде чем мы продолжим серию статей про сравнение разных LLM.

Важно! Эта статья написана для всех, кто хочет разобраться в теме, максимально простым языком. Я постараюсь не усложнять без необходимости и иногда буду приводить примеры из жизни. Надеюсь, вы простите мне некоторые упрощения.

Параметры

Число параметров – это первая характеристика модели, которую мы слышим. Нередко она даже вшита в название. Например, Llama-2 70B, что означает, что у модели 70 миллиардов параметров. Это много или мало? Давайте разберемся.

Параметры бывают трех основных видов:

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

Веса — это главное. Это числа, которые модель подобрала при обучении и через которые прогоняет каждый токен на всех своих слоях. Если эмбеддинг отвечает на вопрос “что это за токен”, то веса отвечают на вопрос “как понимать его в этом контексте”: на какие соседние слова смотреть и насколько сильно их учитывать. Важные связи модель усиливает, неважные — почти гасит. Весов в модели подавляющее большинство; когда говорят “70 миллиардов параметров”, речь почти целиком про них.

Смещения — помощники весов. На каждом шаге к результату добавляется небольшая поправка-константа, которая чуть сдвигает баланс в ту или иную сторону. Их мало, и на общий счётчик параметров они почти не влияют.

Мне нравится такой пример. В контексте полного имени после слова “Барак” логично ждать “Обама” — на таких продолжениях модель и обучилась, поэтому предсказывает их уверенно. Но срабатывает это не всегда. У бывшего американского президента есть второе имя (как и у большинства граждан США), потому полностью он “Барак Хуссейн Обама”. То есть бывают контексты, где за “Бараком” идёт не “Обама”, а “Хуссейн”. Что выбрать, модель решает сама: взвешивает весь контекст и подбирает самое вероятное продолжение, а в пограничных случаях её слегка подталкивают те самые смещения.

Есть четвертая вещь, которую часто путают с параметрами — гиперпараметры. Это число слоев и размер модели (задаются до обучения), температура при генерации (выставляется уже на инференсе) и подобные настройки. Разница простая: параметры модель подбирает сама во время обучения, а гиперпараметры до обучения выставляет человек. В число параметров они не входят.

Бывают модели с сотнями миллиардов или, наоборот, миллиардами параметров. Но сама по себе эта цифра, вырванная из контекста, нам ни о чем не говорит. 

Потому что судить о качестве и мощности модели по этому критерию – примерно как судить о машине по числу лошадиных сил в ее двигателе. Кое-какую информацию нам это число сообщить может, но дальше важна задача, которую мы решаем этой машиной. 180 лошадей в микролитражке и грузовике “Урал” – это прямо очень разные лошади в очень разном контексте использования. 

Но что мешает нам напрямую сравнить модели по числу параметров? Ведь LLM общего назначения должны решать примерно одни задачи и работать в одном классе?

Архитектура. Есть модели, которые прогоняют каждый токен запроса через все свои параметры, грубо говоря задействуют себя на полную мощность. Такие модели называются плотными. Однако, практика показала, что это не всегда требуется. Поэтому появилась архитектура MoE (Mixture of Experts, “смесь экспертов”). Она поступает иначе: вместо одной большой сети в каждом слое стоит несколько маленьких подсетей — “экспертов” — а специальный маршрутизатор решает, к каким из них направить конкретный токен.

Получается, что в MoE задействуют не все параметры, а только их часть. Например, Mixtral 8x7B имеет 46,7 миллиарда параметров суммарно, но на каждый токен активирует лишь около 13 миллиардов. Она прекрасно справляется с задачами и обходит многих конкурентов, но 46,7 миллиардов в ней все же не аналогичны 46,7 миллиардам у плотной модели.

Качество обучения. В начале 2020-х бытовало упрощенное мнение: чем больше параметров, тем умнее модель. Его подкрепляли первые законы масштабирования OpenAI: из них следовало, что вычислительные ресурсы выгоднее вкладывать в размер модели, а данные вторичны. Но в 2022 году DeepMind работой про Chinchilla показала, что это не так.

Оказалось, что нужно не просто наращивать число параметров, а гармонично увеличивать и количество тренировочных токенов. Модели-гиганты вроде GPT-3 были “недокормлены” данными. Llama-2 70B, обученная на 2 триллионах токенов, обходила куда более жирный GPT-3 175B по большинству бенчмарков просто потому, что ее качество обучения было выше.

Специализация. В целом, если мы говорим про LLM общего назначения, то есть такие, которые одинаково хороши (или плохи) в разных задачах. Однако, почти каждая нейронка имеет “перекос”, какие-то качества у нее развиты лучше, а какие-то сильно страдают.

Здесь приведу пример из практики. Чтобы оценить логику изложения в своих статьях, после написания я всегда прогоняю их через ChatGPT и DeepSeek. Делаю я это для того, чтобы мне указали на возможные фактические ошибки, орфографию или проблемы по стилю/логике изложения. 

И при прочих равных DeepSeek – это такой рубаха-парень, который объясняет все более бытовым языком, отлично подмечает места, где я перемудрил, но крайне невнимателен к фактам.

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

Потому, можно попасть в больное место очень хорошей LLM и получить ерунду. А можно плохенькую нейросеть использовать для того, в чем она сильна и вполне себе радоваться жизни.

Бенчмарки

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

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

Бенчмарки — это стандартизированные наборы задач, на которых гоняют все модели подряд, чтобы получить сравнимые цифры. Их сегодня сотни, и в них легко утонуть. Давайте пройдемся по основным и посмотрим, что они там проверяют.

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

MMLU (Massive Multitask Language Understanding) — самый цитируемый бенчмарк последних лет. Это около 16 тысяч вопросов с вариантами ответов по 57 предметам: от элементарной математики и анатомии до права, философии и микроэкономики. По сути, проверка широты эрудиции. Долгое время именно MMLU был эталоном сравнений.

Но у успеха есть обратная сторона. Сегодня MMLU устарел: топовые модели набирают на нем за 90%, и разница в один-два процента уже теряется в шуме. Грубо говоря, это перестало быть экзаменом для сильнейших и стало тестом на грамотность. Почему? Потому что растет общий уровень моделей. Что было круто в 2022 году сегодня уже выглядит слабенько.

Чтобы вновь сделать оценку показательной появился MMLU-Pro — версия с более сложными вопросами и большим числом вариантов ответа.

GPQA Diamond — это вопросы уровня PhD по биологии, химии и физике, причем настолько сложные, что непрофильные специалисты с доступом к интернету ошибаются на большой их части. Если модель уверенно берет такой барьер, ей можно доверить разбор по-настоящему сложного научного, юридического или финансового материала. Именно GPQA многие сегодня считают золотым стандартом: он измеряет не красноречие, а способность реально соображать.

Humanity’s Last Exam (HLE) — “последний экзамен человечества”, около трех тысяч экспертных вопросов из десятков дисциплин, специально собранных так, чтобы пробить потолок насыщения (ситуация, когда тесты становятся слишком простыми для большинства).

ARC-AGI — отдельная история: тесты на абстрактное мышление, где надо угадать правило по нескольким примерам. Для человека это головоломки уровня детских, для LLM — на удивление трудные, потому что тут нельзя “вспомнить” ответ из обучающих данных, надо именно вывести закономерность.

HellaSwag — здравый смысл через продолжение фразы. Дается начало бытовой ситуации, надо выбрать самое правдоподобное продолжение из четырех. Для топ-моделей он давно насыщен (за 95%), но остается хорошей лакмусовой бумажкой для маленьких и дообученных моделей.

BIG-Bench Hard (BBH) — набор из 23 заданий, специально подобранных так, чтобы их нельзя было решить “срезав угол”: логические выводы, причинно-следственные цепочки, алгоритмические задачки. В отличие от MMLU, BBH без пошагового рассуждения не взять, и потому он лучше предсказывает реальное мышление у моделей среднего эшелона.

Отдельная боль и отдельная категория – мультиязычность. Большинство классических бенчмарков — англоязычные, и высокий балл на них ничего не говорит о том, как модель справится с русским, хинди или суахили. Поэтому появились Global-MMLU (тот же MMLU, переведенный и культурно адаптированный на четыре десятка языков) и MMLU-ProX (многоязычная версия MMLU-Pro на тринадцать типологически разных языков). Для нас с вами это важно: модель, блестяще работающая на английском, на русском может оказаться заметно слабее. И проверять это нужно отдельно.

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

• Многие бенчмарки публичны или данные с них уже утекли в публичное пространство. А потому можно натренировать модель на их прохождение и слегка сжульничать. Ведь таким образом можно добавить своей модели маркетингового веса. Это называется законом Гудхарта: “когда метрика становится целью, она перестает быть хорошей метрикой”.

• Общий уровень моделей растет постоянно. Бенчмарки быстро устаревают, ибо возникает тот самый потолок насыщения. Это решается новыми бенчмарками, потому процесс оценки меняется и развивается вместе с технологиями. 

• Зависимость от обвязки. Как вы знаете, у моделей есть много помощников (или костылей), которые помогают ей эффективнее справляться с определенными типами задач. Самый яркий пример мы видели в нашем тесте на работу агрегата. Ни одна из флагманских моделей не смогла посчитать то, что Excel считает одной формулой и за секунды. Иногда, правильно настроенные инструменты могут помочь со многими тестами. И вот как такое считать?

Человеческие бенчмарки

Раз автоматические тесты можно обмануть и они насыщаются, родилась альтернатива — спросить живых людей. Так появилась Chatbot Arena (ныне LMArena), запущенная в 2023 году исследователями из Беркли.

Механика гениально проста. Вы пишете запрос, получаете два ответа от анонимных моделей — “Модель A” и “Модель B”. Голосуете за ту, что лучше. И только после голосования вам открывают, кто есть кто. Голоса (а их собрано уже миллионы) скармливаются рейтинговой системе.

Арена ловит то, что не видят автотесты: тон, естественность, умение следовать сложной инструкции, ощущение “этот ответ просто приятнее”. Но и у нее свои грехи. 

Главный — смещение к многословию: люди склонны выбирать ответы подлиннее и покрасивее оформленные, даже когда короткий ответ точнее. Из-за этого модели в среднем “разнесло” в сторону болтливости. Поэтому ввели отдельную колонку Style Control, которая делает поправку на длину и форматирование.

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

Живые голоса собирать дорого и медленно, поэтому появился гибрид — LLM-as-a-judge, когда судьей выступает сильная модель, оценивающая ответы других. На этой идее построен Arena-Hard: автоматический набор сложных запросов, который пытается воспроизвести вердикты живой арены. Но у судьи-машины свои перекосы: та же любовь к длине и предвзятость к позиции ответа, так что и здесь нет серебряной пули.

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

В общем, не существует одного числа, которым измеряется “ум” модели. Бенчмарк на знания, бенчмарк на рассуждение, бенчмарк на код и арена с людьми измеряют разные вещи. Сильная на одном модель может проседать на другом. Грамотный подход – это смотреть не на одну цифру, а на профиль по нескольким разнотипным тестам. Помнить про потолок насыщения, жульничество на тестах, и — обязательно — проверять модель на своих собственных задачах.

Что может мощная LLM и чего не может простенькая

Прежде чем мы перейдем к категориям тестов, которые можем делать сами и объясним их, важно разделить в голове лиги, в которых играют модели. Снова вспомним, как меня спрашивали в комментариях, почему я не включил в обзор DeepSeek. Давайте разберемся с этим вопросом. Итак…

1. Граница номер один – это глубина рассуждения. Слабая модель отлично справляется с одним логическим шагом, но на цепочке из пяти-шести взаимосвязанных шагов теряет нить: забывает раннее условие, противоречит сама себе, выдает правдоподобный, но неверный итог. Мощная держит длинную цепочку рассуждений связной — каждый шаг опирается на предыдущий. Именно поэтому топовые модели берут GPQA и олимпиадную математику, а простенькие — нет. Если ваша задача требует разложить проблему на части и пройти по ним последовательно, разница будет драматической.

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

3. Работа с кодом и особенно с правками. Слабая модель — это продвинутое автодополнение: допишет функцию, подскажет синтаксис, объяснит ошибку. Полезно, но локально. Мощная модель в связке с инструментами работает как агент: читает большую незнакомую кодовую базу, находит причину реального бага, пишет патч, прогоняет тесты, итеративно правит. Именно это меряет SWE-bench, и именно здесь бюджетные модели резко отстают. 

4. Точность следования инструкциям. Мощная модель надежно выполняет составные требования: формат, ограничения, структуру вывода. Слабая — выполняет частично, особенно когда требований несколько. На уровне болтовни это незаметно, но как только вы строите на модели продукт, где важен предсказуемый формат ответа (JSON, строгая структура, заданная длина), пропасть становится очевидной.

5. Честность и калибровка. Топовые модели лучше осознают границы своих знаний и чаще честно говорят “не уверена” вместо того, чтобы сочинять. Слабые галлюцинируют охотнее и увереннее. Это не значит, что флагманы не врут вовсе — врут, но реже и аккуратнее, а главное — лучше отличают “знаю” от “придумываю”.

6. Языки и мультимодальность. Мощные модели прилично работают с десятками языков и понимают не только текст, но и изображения, графики, документы, иногда звук и видео. Бюджетные обычно сильны лишь в английском и нескольких популярных языках и часто вообще не умеют в картинки. Если вам нужен редкий язык или анализ изображения — это сразу отсекает простые модели.

7. Агентность и инструменты. Самый свежий рубеж. Сильная модель умеет планировать многошаговые действия, вызывать внешние инструменты, ходить в интернет, работать с файлами, выстраивать и корректировать стратегию по ходу дела. Слабая теряется уже на втором-третьем шаге автономного сценария. Поскольку именно агентные применения сейчас на острие, этот разрыв в 2026 году — один из самых практически значимых.

Но! Далеко не везде нужны флагманы. Для огромного числа задач — классификация, извлечение данных, короткие ответы, черновики, простые переписывания, рутинная сортировка — маленькая модель работает прекрасно, в разы быстрее и в десятки, а то и в сотни раз дешевле. Запускать флагман на 671 миллиард параметров, чтобы рассортировать письма по папкам — все равно что ездить за хлебом на том самом “Урале” в 180 лошадей. Технически можно, но на редкость расточительно.

Флагман отвечает медленнее и стоит в разы, а то и в сотни раз дороже за тот же объем текста. 

Именно поэтому в серьезных системах применяют маршрутизацию: простые запросы уходят к дешевой быстрой модели, сложные — к мощной. Это экономит огромные деньги без особой потери качества там, где оно реально нужно. Вспомните, как в нашем тестировании Gemini 3.1 Pro буквально уделал всех конкурентов по цене.

Есть и еще одна причина, по которой маленькие модели в последние годы так похорошели — дистилляция. Грубо говоря, большую умную модель-учителя заставляют обучать маленькую модель-ученика, передавая ей не сырые данные, а свои собственные ответы и распределения вероятностей. Ученик получается на порядок компактнее, но впитывает изрядную долю поведения учителя. Поэтому современная “малышка” на несколько миллиардов параметров нередко ведет себя умнее, чем гигант трехлетней давности. Все дело в том, что она основана на большой модели, которая ее натаскала. Это еще один гвоздь в гроб тезиса, что число параметров = ум/мощность/качество.

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

Тесты на коленке

ОК, есть число параметров, бенчмарки и понимание, что у каждого теста есть слабая сторона. Можно ли как-то для себя устроить мини-соревнование между моделями, чтобы понять, что лучше подходит именно нам?

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

Сложные паттерны

Возьмите книгу, которую вы хорошо знаете и загрузите на вход (но следите, чтобы влезть в контекстное окно). Попросите дать нестыковки.

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

Языки и перевод

Попросите перевести что-нибудь с английского на русский, сделать это литературно или подражая кому-то. Здесь особенно заметна разница в объеме и качестве обучающих данных: топовые модели держат десятки языков и писательских паттернов, бюджетные плывут на всем, что сложнее английского и пары других популярных языков.

Ответ с жесткими ограничениями

Отличный тест на гибкость — попросить написать текст с искусственным ограничением, при том, что это ограничение может затеряться на фоне другой, более серьезной задачи. Мы делали суммаризацию по LoRaWAN и ограничивали ее 2000 символов. Сильные модели удерживают и смысл, и форму одновременно — а это совсем другой уровень контроля над собственным выводом.

Внимание посередине

Дайте на вход большой текст и спрячьте в середине конкретную деталь, а потом спросите о ней. Слабые модели теряют середину длинного документа, сильные — находят иголку в стоге сена. Мы с вами делали эту проверку на документации LoRaWAN и про этот тест часто пишут. Я его делаю, но, честно говоря, среди серьезных моделей такой проблемы не встречал. Хотя, может еще встречу.

Использование инструментов

Дайте задачу, с которой LLM в силу своей архитектуры справиться не может и оцените адекватность и возможности использования “подпорок”. К примеру, анализ огромного числа данных со сложным паттерном. Мы для этого использовали показатели ампеража агрегата.

Как вы помните, работали мы через API и ни одна из моделей не смогла подтянуть инструмент для расчета. Но Opus хотя бы дал совет по формуле в Excel. 

Понимание рисунков

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

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

Тест на логику 

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

У этого теста тут есть проблема. Модель может знать ответ. Чтобы этого избежать используют следующий тест.

Тест на шаблонность

Возьмите классическую загадку и слегка ее измените, чтобы шаблонный ответ стал неверным. Слабая модель узнает знакомый узор и выдаст заученный ответ; сильная — заметит подвох.

Пример. Все знают загадку про хирурга, который отказывается оперировать мальчика со словами “это мой сын” (ответ: хирург — мать). Теперь задайте ее в варианте, где явно сказано, что отец и есть хирург, и спросите, как это возможно. Слабая модель на автомате выдаст “это мать!” — потому что узнала шаблон, не вчитавшись. Сильная заметит, что в вашей формулировке никакого парадокса нет.

Сюда же — задачи с лишними или противоречивыми данными. Цель одна: проверить, думает ли модель над конкретной формулировкой или вспоминает похожий шаблон. Это, пожалуй, лучший бытовой индикатор реального рассуждения.

Скрытый текст

В таких тестах важно не перехитрить самих себя. Одно время по Интернету активно гулял тест рецепта для “свиных крылышек”. Этим тестом многие “крутые ИИшники” показывали как галлюцинирует нейросеть. Потому что не существует рецептов свиных крылышек, нет у свиньи крыльев.

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

Проверка на галлюцинации

Спросите модель о чем-то несуществующем — выдуманной книге, вымышленном законе, придуманном вами ученом. Хорошая модель честно скажет “не знаю” или “не нахожу такого”. Слабая (а иногда и не очень слабая) с удовольствием сочинит правдоподобную биографию и список трудов. Это тест на калибровку — понимает ли модель границы своего знания. Один из самых важных в быту: модель, которая уверенно врет, опаснее модели, которая честно сомневается. Как вы помните, только GPT 5.5 предупредил нас о том, что ученого Андрея Слонова мы придумали.

Культурный код

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

Тест “клубника”: считаем буквы

Самый знаменитый народный тест. Спросите: “Сколько букв «r» в слове strawberry?” (правильный ответ — три). Долгое время даже мощные модели уверенно отвечали “две” и становились героями мемов.

Тут важно понять, почему так происходит, потому что тест глубже, чем кажется. Дело в том, что модель мыслит токенами, и слово strawberry распадается, например, на “st”, “raw”, “berry”. Модель оперирует этими кусками-числами, а не отдельными символами. Спросить ее, сколько “r” в слове, — это примерно как спросить человека, сколько пикселей в букве, которую он читает: информация просто не на том уровне, на котором он работает.

Это делает тест слегка нечестным — он бьет в фундаментальную особенность архитектуры, а не в качество модели. Но как лакмусовая бумажка он по-прежнему полезен: сильные современные модели научились такие вопросы обходить (часто внутренне “проговаривая” слово по буквам или дописывая в уме), а слабые продолжают спотыкаться. Кстати, надежный способ получить верный ответ от любой модели — попросить ее не считать в уме, а написать код, который посчитает. Тогда она разложит слово по символам и не ошибется.

Вариации той же идеи: попросить написать слово задом наперед, посчитать слова в собственном ответе, найти слова на заданную букву. Все это бьет в одну и ту же символьную слепоту.

Тест на работу с кодом и проектами

Один из главных и самых сложновоспроизводимых тестов. Тут как нигде важна задача. Если вы хотите, чтобы модель писала за вас код, находила ошибки в проекте или вообще вела сразу несколько параллельных задач по разработке и отладке, то тест придется придумывать самому. Чужой опыт тут будет хоть и показателен, но не даст стопроцентной гарантии, что модель справится именно с вашей задачей. Увы. Хотя, именно по вашему направлению можете поискать специализированные бенчмарки — они точно есть и вот здесь будут уместны.  

Совет. Не полагайтесь на один тест — соберите свой личный мини-набор из 10–20 вопросов разных типов (логика, счет, творчество с ограничением, проверка на вранье, ваша профессиональная задача) и прогоняйте через него каждую новую модель. Через пару итераций у вас выработается чутье лучше любого агрегатора бенчмарок, потому что вы будете мерить именно то, что нужно вам. По сути, вы построите собственный маленький бенчмарк.

Каждому свое

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

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

Потому, если мы тестируем модели, то необходимо ставить их в равные условия и подавать на вход одинаковые входные данные.

Есть еще вариант для сравнения двух моделей. Можно составить две группы промптов (наиболее оптимально для каждой) и прогонять тест как минимум два раза. Подавая на вход каждой оптимальный и неоптимальный и усредняя результат.

Тест же с разными вводными для каждой в отдельности – не тест, а ерунда. 

Как действуем дальше

После этих вводных я продолжу тестирование различных моделей. Мы уже проверили поведение флагманов. Теперь перейдем к тем, кто поскромнее. Ниже таблица с очень условным разбиением моделей на категории “флагман”, “сильные”, “средние” и так далее. GPT 5.5 Pro, Fable и Mythos, я отношу к суперфлагманам. И раз две из трех нам недоступны, то тестировать прошку одну мы пока не будем (может, отложим на попозже).

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

Важно! Числа SWE-bench Verified приведены как ориентир: на середину 2026 это в основном самоотчеты вендоров, метрика частично загрязнена утечкой данных, и OpenAI уже сместилась на SWE-bench Pro, где те же модели проседают почти вдвое. Воспринимать как порядок величины, а не точную линейку.

Единого точного значения по колонке Arena Elo на самом деле не существует. Во-первых, рейтинг динамический и пересчитывается ежедневно. Во-вторых, на одну и ту же дату рейтинг может быть в формате без поправок или с поправкой на стиль (Style Control), общий зачет или сложные промпты. А после смены методологии в начале 2026 года абсолютные числа вообще сдвинулись на десятки пунктов. Поэтому я привожу не точные значения, а порядок: модели сгруппированы по уровням, и важна не цифра, а то, в какой группе модель и кто рядом с ней. Если вам нужно точное число — берите его из первоисточника (arena.ai/leaderboard) на конкретную дату и с конкретным срезом.

Важные пояснения:

• * Вендорские числа: самоотчет производителя, независимо еще не перепроверены (особенно свежие открытые релизы — MiniMax M3, Qwen).

• HLE сильно зависит от режима (с инструментами / max effort): разброс у одной модели достигает 1,5–2 раз. Лидеры июня-2026: Mythos/Fable ≈64–65%, Opus 4.8 ≈46%, Gemini 3.1 Pro ≈45%.

• н/c — несравнимо: поисковые/RAG-модели (Sonar) по GPQA/SWE напрямую не меряются.

• N/P — не публикуется вендором.

• SWE-bench Verified для GPT-5.5 разнятся. Независимые прогоны ≈82,6%, самоотчёт OpenAI 88,7%. OpenAI подозревает (!!!), что бечмарки могли случайно утечь и попасть в модель. Потому надо читать как порядок.