«Числа могут быть настоящими, а вывод — нет»: аудит карточек моделей разобрал семь бенчмарков как маркетинг

17 сентября 2026 года на Hugging Face вышел технический аудит «When Benchmark Numbers Become Marketing» — разбор публичных заявлений в карточках моделей DavidAU и Nightmedia: методология бенчмарков, воспроизводимость и то, насколько опубликованные числа поддерживают выводы, которые из них делают.

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

Семь задач вместо интеллекта

Сквозной сюжет аудита — один и тот же набор из семи коротких тестов: ARC-Challenge, ARC-Easy, BoolQ, HellaSwag, OpenBookQA, PIQA и WinoGrande. Это законные бенчмарки, но они вышли примерно в 2018–2020 годах и измеряют узкие способности: BoolQ — понимание текста с ответом «да/нет», PIQA — физический здравый смысл, HellaSwag — правдоподобное продолжение, WinoGrande — разрешение местоимений, ARC и OpenBookQA — школьные вопросы по естественным наукам.

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

ARC-C 0.700 — не порог «зоны OpenAI, Claude и Gemini»

Одна из самых сильных претензий аудита — карточка DavidAU Qwen3.6-27B Fable Fusion 711, где результат ARC-C около 0.700 связывается с «зоной интеллекта OpenAI, Claude и Gemini». Признанного научного стандарта, в котором ARC-C ≥ 0.700 означало бы уровень этих лабораторий, не существует: такого порога не определяют ни создатели ARC, ни lm-evaluation-harness, ни сами лаборатории.

Отдельно аудит ссылается на работу Łukasza Borchmanna об ARC-Challenge, где показано, что кажущаяся сложность этого набора во многом зависит от схемы оценки, а не только от сложности вопросов. ARC-C остаётся полезным историческим бенчмарком, но превращать конкретное значение 0.700 в универсальную границу интеллекта не из чего.

Что публикует официальная карточка Qwen3.6-27B

Сравнение важно потому, что Fable Fusion собран на базе Qwen3.6-27B. Официальная карточка Qwen/Qwen3.6-27B публикует гораздо более широкую батарею: SWE-bench Verified — 77.2, SWE-bench Pro — 53.5, SWE-bench Multilingual — 71.3, Terminal-Bench 2.0 — 59.3, SkillsBench Avg5 — 48.2, GPQA Diamond — 87.8, LiveCodeBench v6 — 83.9, AIME26 — 94.1, а также HMMT. Аудит подчёркивает: смысл не в том, что каждый community-файнтюн обязан перезапускать все дорогие бенчмарки, а в том, что заявление об «улучшении общего интеллекта» нельзя подтвердить семью короткими задачами.

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

«Полностью без цензуры» против шести отказов из ста

Второй тип замечаний — внутренние противоречия в карточках. В карточке Qwen3.5-9B The Defiant модель названа «Fully uncensored», но собственная таблица автора приводит 6 отказов на 100 запросов. Если понимать «полностью без цензуры» буквально как ноль отказов, данные противоречат ярлыку, и корректнее была бы формулировка «существенно меньше отказов, чем у базовой модели».

Похожая история с Qwen3.6-40B Grand Intelligence: в карточке говорится о превышении базовой Qwen3.6-27B «с большим отрывом», но в опубликованной строке 0.687, 0.857, 0.908, 0.825, 0.500, 0.818, 0.771 против базовой 0.647, 0.803, 0.910, 0.773, 0.450, 0.806, 0.742 выше шесть значений, а BoolQ ниже — 0.908 против 0.910. Аудит делает осторожный вывод: такие формулировки — маркетинговое упрощение, а не буквальное доминирование по каждому показателю.

Почему оценка «2M» ничего не доказывает

Самый технический блок — про заявление, что модель Qwen3.8-27B Brainwaves «безопасно RoPEd до 2M». В качестве доказательства приведены те же семь задач и перплексия, посчитанная скриптом mlx_lm.perplexity. По умолчанию этот скрипт использует длину последовательности 512 токенов, 256 сэмплов, батч 8 и датасет allenai/tulu-3-sft-mixture со сплитом train. Это значит, что модель с заявкой на 2 000 000 токенов проверяли блоками по 512 токенов.

Более того, загрузчик данных склеивает токены разных записей в один длинный поток, а затем нарезает его блоками фиксированной длины. Из-за этого блок может пересекать границу двух несвязанных диалогов, и потеря на таком искусственном стыке тоже попадает в перплексию. Чтобы говорить о длинном контексте, аудит предлагает реальные прогоны на 128K, 256K, 512K, 1M и 2M с поиском «иголки», множественными иголками, вопросами по длинным документам и кривой деградации по глубине.

Отдельная линия — трактовка метрик из того же скрипта. Отображаемая погрешность перплексии считается по потерям отдельных токенов: стандартное отклонение делится на корень из их числа, хотя токены внутри последовательности коррелированы. Скорость в отчёте — это tokens_evaluated, делённое на время оценки, то есть темп прямого прохода по известным токенам, а не привычная скорость генерации с KV-кэшем. «Peak memory» в том же выводе относится к конкретной нагрузке на блоках по 512 токенов и не является универсальным требованием к памяти.

«Стандартные метрики MLX» — чей это стандарт

В публичном ответе Nightmedia назвал семь задач «стандартными метриками MLX». Аудит проверяет это по коду: mlx_lm.evaluate не задаёт фиксированного набора из семи задач — параметр --tasks обязателен, а сама оценка делегируется lm-evaluation-harness через simple_evaluate(tasks=args.tasks). MLX предоставляет адаптер модели, а определения задач приходят из lm-evaluation-harness, и имена файлов результатов собираются в том числе из версии пакета lm_eval.

С версиями связан ещё один пункт аудита: в обсуждениях встречались имена результатов с lm-eval 0.4.9 и 0.4.10, тогда как релиз 0.4.12 опубликован 11 мая 2026 года. Это несоответствие требует пояснения — например, мог быть переиспользован архивный прогон, — но само по себе не доказывает подделку. Наконец, в актуальной конфигурации задачи winogrande используется метрика acc, а не acc_norm. Поэтому подпись, где все семь колонок выглядят как одна нормализованная метрика, технически неточна; аудит отмечает, что Nightmedia позже признал, что две задачи не являются acc_norm.

Матрица важности: универсальных «+2–4%» в документации нет

В карточке Fable Fusion заявлено, что NEO IMATRIX добавляет 2–4% точности и улучшает поведение на длинном контексте. Официальная документация llama.cpp формулирует иначе: матрица важности «может использоваться при квантовании, чтобы повысить качество квантованных моделей», без универсальной числовой гарантии.

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

Что аудит оговаривает отдельно

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

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

Что предлагает автор вместо этого

Критика в аудите конструктивная, потому что проблемы устранимы на уровне публикации данных. Для воспроизводимости предлагается указывать точные хеши модели и токенизатора, шаблон чата, версии mlx-lm и lm-eval, версии задач, командные строки, seed, настройки сэмплирования, сырые JSON и по-элементные предсказания там, где это позволяет лицензия. Дальше — современные наборы под каждый тип заявки: GPQA Diamond и MMLU-Pro для рассуждений, LiveCodeBench и задачи уровня репозитория для кода, Terminal-Bench, SWE-bench и BFCL для агентных сценариев, прогоны вблизи заявленной длины для длинного контекста, парные тесты для квантования и описанный протокол со слепой оценкой для человеческих сравнений.

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