EdgeBench: Глубокий анализ бенчмарка для AI-агентов

В эпоху, когда искусственный интеллект перешел от простого генерации текста к автономному выполнению сложных задач, возникла острая необходимость в новых стандартах оценки. Традиционные бенчмарки, такие как MMLU или GSM8K, измеряют статические знания, но они не способны оценить способность модели планировать, действовать в среде и корректировать свои действия на основе обратной связи. На сцену выходит EdgeBench — комплексный фреймворк для оценки продвинутых AI-агентов, разработанный командой ByteDance Seed. Это не просто список задач, а целая экосистема, включающая спецификации окружения, логику судейства и метрики масштабирования.

В этой статье мы подробно разберем архитектуру EdgeBench, проанализируем данные лидерборда, изучим законы масштабирования (scaling laws) и поймем, как время взаимодействия с агентом влияет на его эффективность. Мы не просто посмотрим на цифры, а построим аналитический пайплайн, который позволит вам самостоятельно воспроизвести результаты, понять внутреннюю кухню бенчмарка и принять взвешенное решение при выборе модели для своих проектов. Это руководство для тех, кто хочет выйти за пределы поверхностного сравнения и понять механику работы современных агентов.

011. Архитектура и загрузка данных EdgeBench

EdgeBench позиционируется как практический бенчмарк для оценки AI-агентов в разнообразных категориях задач, с разными runtime-окружениями и бюджетами времени взаимодействия. Чтобы начать анализ, необходимо получить доступ к набору данных. Все ресурсы доступны через Hugging Face в репозитории ByteDance-Seed/EdgeBench.

Процесс начинается с загрузки снапшота датасета. Это позволяет локально кэшировать все спецификации задач, конфигурации окружения и метаданные. В основе анализа лежит использование Python-библиотек, таких как pandas для работы с табличными данными, scipy для статистического моделирования и matplotlib для визуализации. Важно отметить, что для корректной работы требуется установить специфические версии библиотек, включая huggingface_hub для взаимодействия с платформой.

pip install "huggingface_hub>=0.23" pandas numpy scipy matplotlib pyyaml

import os
import glob
import json
import textwrap
import warnings
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
from scipy.optimize import curve_fit
from huggingface_hub import snapshot_download

warnings.filterwarnings("ignore")
pd.set_option("display.max_colwidth", 90)
pd.set_option("display.width", 160)

REPO_ID = "ByteDance-Seed/EdgeBench"
TIME_BUDGETS = [10, 12]
MODELS = ["Claude Opus 4.8", "GPT-5.5", "GPT-5.4", "GLM-5.1", "DS-V4-Pro"]

def banner(t):
    print("\n" + "=" * 78 + f"\n  {t}\n" + "=" * 78)

def canon_model_name(name):
    name = name.lower()
    if "opus" in name: return "Claude Opus 4.8"
    if "5.5" in name: return "GPT-5.5"
    if "5.4" in name: return "GPT-5.4"
    if "glm" in name: return "GLM-5.1"
    if "ds-v4" in name or "deepseek" in name: return "DS-V4-Pro"
    return name

banner("1. DOWNLOADING DATASET SNAPSHOT")
local_dir = snapshot_download(repo_id=REPO_ID, repo_type="dataset")
print("Snapshot cached at:", local_dir)

Ключевым моментом здесь является стандартизация имен моделей. Разные источники могут использовать различные префиксы или суффиксы для обозначения одних и тех же моделей (например, "claude-3-opus" vs "Claude Opus 4.8"). Функция canon_model_name обеспечивает единообразие данных, что критически важно для корректного агрегирования результатов.

022. Таксономия задач и спецификации

EdgeBench не ограничивается простым текстовым вводом. Каждая задача в бенчмарке имеет строгую спецификацию, которая включает в себя:

• Категорию задачи: Например, программирование, анализ данных, веб-сёрфинг или работа с графическим интерфейсом.
• Базовое изображение (base_image): Контейнер Docker или виртуальная среда, в которой выполняется агент. Это гарантирует воспроизводимость результатов, так как разные модели могут требовать разных библиотек или версий Python.
• Доступ к интернету: Флаг, указывающий, имеет ли агент доступ к внешним ресурсам. Это разделяет задачи на изолированные (где агент полагается только на свои знания) и открытые (где требуется поиск информации).
• Режим игры (game_mode): Специфичный параметр для задач, имитирующих взаимодействие с играми или сложными интерактивными системами.
• Логику судейства (judge logic): Алгоритм, который оценивает результат работы агента. Это может быть парсер кода, проверка вывода через LLM-as-a-judge или сравнение с эталонным ответом.

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

033. Анализ лидерборда и парсинг результатов

Основной источник данных для сравнения моделей — это README-файл репозитория, который содержит таблицы с результатами. Однако эти таблицы часто имеют сложную структуру, с объединенными ячейками и специфическим форматированием Markdown. Для анализа нам необходимо «распарсить» эти данные в плоскую таблицу (tidy data format).

Источник: MarkTechPost ↗