Хватит мерить удава попугаями: зачем нужен единый язык отчетов
Если ты когда-нибудь пытался сравнить две модели по метрикам из разных бенчмарков, то знаешь это чувство: один отдает accuracy, второй — f1, третий — perplexity, а четвертый вообще придумал свою «эффективность». Бардак, который AI-сообщество терпело годами. Hugging Face решил, что с этим пора завязывать. Их ответ — JSON-схема EEE (EvalEval Evaluation). И нет, это не очередная «резиновая» спецификация. Это попытка навести порядок в доме, где каждый таракан поет свою песню.
EEE — часть инициативы EvalEval Coalition, стартовавшей еще в 2024-м, но к середине 2026 года обросшей зубами и плотью. Схема задает жесткую структуру для любого отчета об оценке: от названия модели и датасета до единиц измерения метрик и гиперпараметров. Зачем? Чтобы все отчеты стали читаемыми, машинно-валидируемыми и, самое главное, сравнимыми. Никаких больше «у нас ответ 0.89, ну вы поняли».
Суть EEE: один JSON — один отчет о прогоне модели на одном датасете с фиксированными полями. Никакой вольности.
В отличие от того же Community Evals, где оценка децентрализована через PR, EEE фокусируется именно на формате хранения результата. Это как если бы в лаборатории химиков вместо «накидал в пробирку» появился протокол с четкими полями: температура, время, количество реагентов. Мозги встают на место.
Разбираем скелет EEE: что внутри схемы
На момент 30 июня 2026 года актуальная версия схемы — v0.2.3. Она доступна в репозитории Hugging Face EvalEval. JSON-схема eval-report-schema.json содержит около 80 полей, но основные блоки такие:
- metadata — информация об оценке: инструмент (например, lm-eval-harness v0.4.2), дата, автор, версия схемы.
- model — каноническое имя модели (например,
mistralai/Mistral-7B-v0.3), тип (base, instruct, fine-tuned), ссылка на репозиторий. - dataset — название датасета, конфигурация, разбивка (test/validation), количество примеров.
- task — конкретная задача (arc_challenge, mmlu, truthfulqa).
- metrics — массив объектов. Каждый объект содержит: имя метрики (exact_match, f1, bleu), значение (число), единицу измерения (проценты, дробь), метод агрегации (micro, macro, weighted).
- configuration — гиперпараметры: batch size, max new tokens, temperature, seed.
- environment — железо: GPU, память, версия библиотеки.
accuracy: 0.95, схема потребует {name: "accuracy", value: 95.0, unit: "percent"}. Да, это больно, но это лечит.Сравни с подходами из Structured Outputs в Amazon Bedrock — там тоже валидный JSON, но без жесткой типизации метрик. EEE идет дальше, требуя enum для единиц (percent, ratio, raw) и обязательное поле aggregation.
EEE против альтернатив: драка в песочнице
Схем для хранения метрик — как грязи. Самые популярные конкуренты EEE на середину 2026 года:
| Подход | Философия | Главный минус |
|---|---|---|
| LM Evaluation Harness (EleutherAI) | Свой внутренний формат .json с метриками, плавающий набор полей | Нет централизованной валидации; каждый запуск может быть неполным |
| MLPerf / MLCommons | Фокус на производительность, а не на качество; жесткие правила для конкуренции | Не подходит для быстрых экспериментов и кастомных метрик |
| Hugging Face Community Evals | Децентрализованные PR с результатами, формат JSON свободный | Отсутствие обязательных полей ведет к мусору — мы писали об этом |
| EEE | JSON-схема с обязательными и опциональными полями, строгая типизация | Сложнее для ручного написания, требует инструментов |
EEE выигрывает за счет принудительной полноты. Если ты пропустил поле environment.gpu — схема плюнет ошибкой. Это бесит, но спасает от ситуаций, когда через год ты не помнишь, на каком железе гонял модель. Как Flatten JSON помогает в поиске, так EEE помогает в воспроизводимости.
Еще одна крутая фишка — поддержка вложенных метрик. Для задачи вроде MMLU ты можешь указать accuracy по каждому сабсету (astronomy, biology...) внутри одного отчета, а агрегировать через macro average. Никакой другой формат так не умеет.
Пример: как собрать отчет по EEE и не сойти с ума
Допустим, ты оценивал Qwen2.5-7B-Instruct на датасете ARC-Challenge. Вот минимальный валидный EEE-блок:
{
"metadata": {
"eval_library": "lm-eval-harness",
"eval_library_version": "0.4.2",
"timestamp": "2026-06-28T14:30:00Z",
"schema_version": "0.2.3"
},
"model": {
"name": "Qwen/Qwen2.5-7B-Instruct",
"type": "instruct",
"repository": "https://huggingface.co/Qwen/Qwen2.5-7B-Instruct"
},
"dataset": {
"name": "arc_challenge",
"config": "ARC-Challenge",
"split": "test",
"num_examples": 1172
},
"task": {
"name": "arc_challenge",
"config": "default"
},
"metrics": [
{
"name": "acc_norm",
"value": 62.54,
"unit": "percent",
"aggregation": "micro"
}
],
"configuration": {
"batch_size": 8,
"max_new_tokens": 50,
"temperature": 0.0,
"seed": 42
},
"environment": {
"gpu_model": "NVIDIA A100-SXM4-80GB",
"cuda_version": "12.4",
"python_version": "3.11"
}
}В чем соль? Всего один файл — полная картина. Если ты загрузишь его в репозиторий Hugging Face как eval-results/arc_challenge.json, любой желающий (или CI) сможет распарсить, сравнить с другими моделями и понять, что метрика — это не просто цифра, а осмысленный контекст.
Кстати, EEE можно использовать и для кастомных бенчмарков, которые ты строишь через Community Evals. Схема не требует, чтобы датасет был на хабе — достаточно поля dataset.name. Главное, чтобы имя было уникальным. Нет больше причин писать «оценка нашей модели на тесте с абстракциями» без указания количества примеров.
Частая ошибка: путать unit и aggregation. unit — это шкала (percent/ratio/raw), aggregation — способ усреднения. Если ты гонял на нескольких seed'ах, то в configuration.seeds можно указать список, а в метрике — среднее по ним с агрегацией macro. Схема это поддерживает.
Кому это реально нужно (и кому — нет)
EEE — не серебряная пуля. Если ты студент, который один раз прогнал модель ради курсовой, тебе проще открыть блокнот и записать метрики вручную. Схема съест час жизни на освоение.
Но если ты:
- Работаешь в команде, где нужно сравнивать модели между собой и с чужими.
- Публикуешь модель на Hugging Face и хочешь, чтобы ее результаты доверяли.
- Участвуешь в лидербордах (Open LLM Leaderboard, Chatbot Arena) — они уже начали требовать EEE-отчеты для валидации.
- Автоматизируешь пайплайны оценки с CI/CD — EEE можно проверить скриптом за миллисекунду.
Тогда EEE — твой новый лучший друг. Он не дает мухлевать с метриками (попробуй записать accuracy: 0.8 без единицы — схема выдаст ошибку). Он заставляет документировать окружение, что особенно важно для воспроизводимости. Кстати, если тебе не нравится писать JSON вручную, Hugging Face выпустил Python-библиотеку eval-reporter, которая принимает объект модели и датасета и генерирует EEE-отчет автоматически. В нее уже встроена интеграция с Community Evals.
Есть и слабые места. EEE пока не поддерживает многомодальные оценки (изображения+текст) — для них нужна отдельная схема. И схема не регламентирует, как именно проводить оценку: ты можешь сгенерировать идеальный JSON, но на самом деле использовать кривой промпт или неправильный датасет. Но это уже вопрос культуры, а не формата.
Взгляни на ситуацию шире. В 2026 году мы уже перестали спорить, что JSON — это стандарт общения между системами. EEE — это попытка зацементировать этот стандарт для оценок. Может, через пару лет любая публикация о модели без EEE-файла будет считаться моветоном, как раньше — отсутствие кода в репозитории. И тогда вопрос «а где твои метрики?» отпадет сам собой. Потому что метрики будут лежать в eval-results/, подписанные, с полной историей семплов.
Попробуй начать с малого: возьми свою любимую модель, прогони на одном тесте, заверни результат в EEE-схему и выложи в модель-карточку. Увидишь, как приятно, когда твой файл проходит валидацию без ошибок. Как будто собрал сложный пазл без единого торчащего края.
