Бенчмарки AI-моделей в 2026 году не дают надёжного ответа на вопрос «какая модель лучше». На TechCrunch Disrupt директор по политике Hugging Face Айрин Солаиман сформулировала это прямо: методики оценки устроены сложно и находятся в стадии становления, отрасль не умеет осмысленно сравнивать бенчмарки между собой, а сами тесты быстро теряют эффективность (TechCrunch).
Главный критерий доверия к цифре из лидерборда Солаиман сводит к одному вопросу: можно ли воспроизвести результат оценки. Для этого нужен достаточный доступ к самой модели, и здесь открытые веса дают то, чего не даёт закрытый API. Вторая линия аргумента: оценка переезжает с модели на систему вокруг неё, включая harness и агента.
Ниже разбор тезисов, механизмы за ними и практические правила, которые можно применить при выборе модели уже сегодня. Оговорка: это позиция одного из руководителей Hugging Face в изложении TechCrunch, а не консенсус всей индустрии.
Что именно сказала Hugging Face на TechCrunch Disrupt
Выступление прошло на конференции TechCrunch Disrupt. Русскоязычный пересказ тех же тезисов опубликован отдельно и повторяет ключевые формулировки: методики проверок сложные и пока незрелые, а тестирование должно стать более последовательной наукой, иначе отрасль не сможет на него опираться в будущем (пересказ).
Кто такая Айрин Солаиман и почему её слова весомы
Айрин (Ирен) Солаиман занимает должность директора по политике Hugging Face. Hugging Face - платформа с открытыми моделями и датасетами, и это объясняет расстановку акцентов: воспроизводимость и доступ к весам стоят в её аргументации на первом месте. У компании есть и собственный опыт в теме: Hugging Face сам стал объектом одного из инцидентов безопасности, на фоне которых вырос спрос на сторонних оценщиков.
Весомость аргумента не отменяет его границ. Солаиман говорит о методологии оценки в целом, но опирается на опыт платформы, которая продвигает открытые веса. Читателю стоит проверять тезисы на своих задачах, а не принимать их как финальную истину.
Семь тезисов, из которых складывается картина
- Методология незрелая. Оценка AI-моделей сложна и пока находится в стадии становления.
- Бенчмарки несопоставимы. Отрасль не знает, как осмысленно сравнивать разные тесты между собой.
- Тесты быстро устаревают. Оценки теряют эффективность относительно быстро, а нужной экосистемы в сфере оценки не сложилось.
- Доверие равно воспроизводимости. «Доверие» - нагруженный термин, а его практическая часть - возможность повторить чужой результат.
- Нужен доступ к модели. Воспроизводимость упирается в уровень доступа, и открытые веса дают его в полном объёме.
- Оценивать приходится систему. Проверка смещается с модели на harness и агента вокруг неё.
- Оценщики без стандартов. Спрос на встроенных сторонних оценщиков есть, критериев их квалификации и нейтральности нет.
Дальше каждый пункт разворачивается отдельно, с практическими следствиями для тех, кто выбирает модель под локальный запуск или рабочий процесс.
Почему методология оценки AI-моделей до сих пор незрелая
Формулировка Солаиман звучит так: «методики таких проверок устроены сложно и пока находятся в стадии становления». Из этого следует практический вывод: единого способа сопоставить два результата из разных лидербордов не существует, потому что за числом стоят разные условия замера.
Второй тезис усиливает первый: «это развивающаяся наука, и пока неясно, как осмысленно сравнивать тесты между собой». Пока способа нет, любая сводная таблица «модель A против модели B» держится на допущениях автора таблицы, а не на общей методике.
Бенчмарки измеряют разное - и это не всегда очевидно
За одной цифрой в лидерборде стоят: набор задач, формулировки промптов, параметры инференса (температура, top-p, лимит токенов), версия теста и способ подсчёта правильных ответов. Поменяйте температуру или формат ответа, и результат сдвинется без единого изменения в модели.
Отсюда типичная ошибка: сравнить «85 в бенчмарке A» и «80 в бенчмарке B» и сделать вывод о превосходстве первой модели. Корректное сравнение требует, чтобы совпадали хотя бы задачи, промпты и версия теста. Если методика не опубликована, сравнивать нечего: цифры просто не связаны между собой.
Почему тесты быстро устаревают
Источник фиксирует сам факт: оценки «довольно быстро теряют эффективность». Сроков и условий там нет, поэтому механизмы стоит назвать как общие объяснения, а не как измеренные причины:
- Утечка тестовых данных. Задачи из публичного бенчмарка попадают в обучающие корпуса, и модель отвечает по памяти, а не по способности решать.
- Подгонка под известный тест. Команды оптимизируют модели под популярные метрики, и метрика перестаёт отражать общее качество.
- Насыщение. Когда все участники упираются в потолок шкалы, тест перестаёт различать модели.
Практический вывод простой: результат полугодовой давности заслуживает меньшего доверия, чем свежий, при прочих равных. Дата публикации теста - такой же параметр оценки, как и его название.
Воспроизводимость - главный критерий доверия к результатам
Солаиман называет доверие «очень нагруженным термином» и переводит разговор в измеримую плоскость: «можете ли вы воспроизвести результаты оценки?». Воспроизводимость давно остаётся одной из самых проблемных сторон бенчмаркинга и по-прежнему вызывает серьёзные споры в отрасли.
Чтобы повторить чужой результат, нужен набор условий: доступ к модели или её весам, опубликованные промпты и настройки инференса, зафиксированная версия теста, прозрачный harness и описание оборудования. Отсутствие любого пункта превращает число в непроверяемое утверждение.
Чек-лист: 6 вопросов к любому бенчмарку перед выводами
- Какая версия теста и когда она обновлялась? Старая версия могла утечь в обучающие данные или насытиться.
- Опубликованы ли промпты и настройки инференса? Без них результат не повторить даже на той же модели.
- Можно ли воспроизвести результат независимо? Есть ли отчёт, код, конфиги, описание железа.
- Что именно измерялось: модель или система вокруг неё? Если в замере участвовали инструменты и цикл агента, это оценка harness, а не чистой модели.
- Есть ли риск утечки тестовых данных? Публичный набор задач с открытыми ответами рано или поздно попадает в обучение.
- Кто проводил оценку и какова его квалификация? Здесь полезен разбор красных флагов из материала о корпоративном шиллинге в AI-обзорах.
Ответы на все шесть вопросов получить удаётся редко. Это и есть практическое следствие незрелости методологии: часть оценочных отчётов придётся отбросить просто потому, что проверить их нельзя.
Открытые веса и доступ к модели: зачем это нужно для оценки
Логика Солаиман: для воспроизводимости нужен «достаточный уровень доступа к модели», и открытые веса дают этот доступ в объёме, которого не даёт закрытый API. Когда веса опубликованы, любой может запустить модель, повторить чужой прогон и проверить, не подогнан ли результат под конкретный набор промптов (пересказ выступления).
У закрытых моделей воспроизведение зависит от доброй воли провайдера: доступа к весам нет, поведение версии может измениться без предупреждения, а часть настроек скрыта. Это не делает закрытые модели хуже по качеству. Речь только о проверяемости оценки.
Открытые веса при этом не гарантируют корректной оценки. Нужны опубликованные промпты, зафиксированные настройки и прозрачный harness, иначе независимый прогон даст третье число, отличное от двух предыдущих.
Что открытые веса дают на практике пользователю локальных LLM
Воспроизводимость в бытовом смысле означает простую вещь: вы скачиваете модель и прогоняете её на своих задачах, не полагаясь на чужие цифры. Никто не мешает проверить, выдержит ли модель ваш контекст, формат ответа и язык запросов.
Ограничения тоже реальные. Локальный запуск требует железа: объём VRAM и класс GPU определяют, влезет ли модель и с каким квантованием. Разное квантование и разное железо дают разные результаты, поэтому ваш прогон не обязан совпасть с чужим. Краудсорсинговые проекты вроде открытого бенчмарка локальных LLM locallm.top пытаются собрать такие данные от сообщества, но и там ограничения методики авторы называют сами.
Оценка смещается с модели на систему: harness и агент
Солаиман фиксирует сдвиг: оценка переходит от проверки самой модели к проверке всей системы вокруг неё, включая обвязку (harness) и агента. Причина в том, что harness, то есть инструмент, через который пользователь обращается к модели, сильно влияет на результат: более слабая модель с лучшей обвязкой легко может обойти передовую (TechCrunch).
Почему слабая модель с хорошим harness обходит фронтирную
Harness определяет, как модель получает контекст, какие инструменты ей доступны, как обрабатываются ошибки, повторы и обрезанный вывод. Хорошо спроектированная обвязка компенсирует слабости модели: разбивает задачу на шаги, подкладывает нужные данные, проверяет результат перед выдачей. Плохая обвязка топит сильную модель: теряет контекст, ломает формат вызова инструмента, отдаёт пользователю сырой вывод.
Конкретные пары моделей и цифры сравнений источник не приводит, поэтому тезис стоит читать как направление, а не как измеренный разрыв. Практический пример того, как обвязка меняет картину для небольшой модели, разобран в материале про MiniCPM5-2B с современным harness против фронтирных моделей.
Агентные оценки: почему они дорогие и сложные
Формулировка Солаиман: «агентные оценки очень сложны и дороги». Тестов для моделей становится больше, тестов для harness по-прежнему мало, а более качественные оценки для целостного агента только разрабатываются.
Причины понятны из устройства агентных сценариев. Задача многошаговая, результат зависит от среды и доступных инструментов, часть шагов недетерминирована, а прогон стоит денег и времени: каждый запуск, это десятки вызовов модели. Воспроизвести чужой агентный результат труднее, чем статический тест, потому что фиксировать нужно больше переменных: версию инструментов, состояние среды, лимиты шагов, политику повторов. Насколько сырой бывает методология у таких тестов, видно по разбору Real-SWE, где деталей о наборе задач и результатах пока нет.
Встроенные сторонние оценщики: спрос есть, стандартов нет
Идея встроенных оценщиков, когда внутрь AI-организации сажают якобы нейтральных сторонних наблюдателей, стала популярной за последние месяцы. Поводом стали участившиеся инциденты в сфере безопасности, и одной из жертв такого происшествия оказался сам Hugging Face.
Солаиман описывает расстановку сил: вместо активного государственного регулирования лаборатории продвигают стороннее решение. Сомнения в нейтральности и эффективности таких оценщиков при этом сохраняются. Её формулировка о рынке: «Спрос на встроенных оценщиков уже есть, но критерии, определяющие, кто способен качественно оценивать модели и на каких задачах, требуют гораздо большей стандартизации» (TechCrunch).
Кейс Anthropic и Accenture: что именно вызвало критику
Anthropic привлекла Accenture в качестве первого оценщика. Решение вызвало волну критики: часть скептиков высмеяла саму мысль, что консалтинговая фирма способна справиться с задачей оценки моделей. Деталей контракта и условий работы источник не приводит, и выдавать критику за консенсус отрасли нельзя: это показатель того, насколько непроработанным выглядит вопрос квалификации.
Для практика кейс полезен как индикатор: рынок оценочных услуг формируется быстрее, чем правила игры на нём. Если вы опираетесь на внешнюю оценку модели, имеет смысл выяснить, кто её проводил и на каком основании считает себя компетентным именно в вашем типе задач.
Что нужно стандартизировать: квалификация и нейтральность
Требование Солаиман раскладывается на два измерения. Квалификация означает компетенцию в конкретных типах задач: оценщик, сильный в безопасности, может быть бесполезен в оценке кодинга или работы с длинным контекстом. Нейтральность означает отсутствие конфликта интересов с лабораторией, которая платит за оценку.
Готовых стандартов в источниках нет, и это ключевая проблема, а не упущение пересказа. Пока критериев нет, «встроенный оценщик» остаётся ярлыком без проверяемого содержания.
Почему единый отраслевой подход пока не сложился
Солаиман называет сферу оценки «свободной игрой без единых правил» и отдельно отмечает: нужной экосистемы в этой сфере пока не сложилось. Сложите это с остальными тезисами, и получится клубок взаимосвязанных проблем, а не один дефект:
- методология незрелая, единой науки тестирования нет;
- бенчмарки несопоставимы между собой;
- тесты быстро устаревают, а обновлять их дорого;
- оценка смещается к системе, что усложняет и удорожает замер;
- квалификация и нейтральность оценщиков не стандартизированы;
- лаборатории продвигают сторонних оценщиков вместо государственного регулирования.
Каждый пункт усиливает следующий. Незрелая методология не даёт сравнивать бенчмарки, отсутствие сравнения мешает выработать стандарт оценки систем, а без стандарта нельзя сертифицировать оценщиков.
Что должно измениться, чтобы бенчмаркам можно было доверять
Условия вытекают из тезисов Солаиман, но готового отраслевого плана источник не содержит. Как минимум потребуются:
- воспроизводимые методики с опубликованными промптами, конфигами и описанием железа;
- прозрачный harness, чтобы отделять вклад модели от вклада обвязки;
- стандарты квалификации оценщиков с привязкой к типам задач;
- регулярное обновление тестов против утечек и насыщения;
- отдельные методики для агентных сценариев, а не перенос статических тестов на многошаговые задачи.
Сроков никто не называет, и выдавать желаемое за принятое не стоит. Показательно, что сами формулировки докладчика описывают задачу, а не достигнутый результат.
Практические выводы: как сравнивать AI-модели, пока бенчмарки ненадёжны
Ненадёжность бенчмарков не отменяет необходимости выбирать модель. Меняется роль цифр: это один из сигналов, а не приговор.
- Не принимайте решение по одной цифре из лидерборда. Один результат без методики не значит ничего, особенно если рядом нет даты теста.
- Проверьте, что измерялось. Если в замере участвовали инструменты, RAG или цикл агента, вы сравниваете системы, а не модели.
- Смотрите на дату и версию теста. Старый бенчмарк мог утечь в обучение или насытиться.
- Для открытых весов прогоняйте модель на своих задачах. 20-30 реальных промптов с зафиксированными настройками инференса дадут более полезный сигнал, чем сводная таблица. Записывайте конфиг, чтобы результат можно было повторить.
- Учитывайте harness, если сравниваете агентные сценарии. Разница в обвязке часто весит больше, чем разница между моделями одного класса.
- Проверяйте, кто проводил оценку. Внешний вид отчёта не сообщает о квалификации и конфликте интересов.
Для локальных сценариев добавьте к списку проверку ресурсов: поместится ли модель в VRAM с нужным квантованием и с какой скоростью будет работать на вашем железе. Модель, которая выигрывает чужой бенчмарк, но не запускается на вашей карте в нужной конфигурации, для вашей задачи не существует.
Рабочее правило на сейчас: относитесь к бенчмарку как к гипотезе, а к собственному прогону на репрезентативных задачах - как к проверке. Начните с двух-трёх моделей из шортлиста, прогоните их на своих промптах с одинаковыми настройками и сравните не средний балл, а число провалов на критичных для вас типах запросов.