Как я собрал публичный AI benchmark и довёл его до GitHub, Kaggle, Zenodo и arXiv-ready состояния

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

Я захотел проверить более практичный вопрос: повторяются ли ошибки моделей распознавания объектов, когда одно и то же изображение проходит через такие стрессовые условия?

Так появился CURE-OR++.

Что такое CURE-OR++

CURE-OR++ — это публичный `benchmark package` поверх CURE-OR. Он не пытается заменить большие академические наборы данных. Его задача уже:

  • проверить устойчивость моделей на нативных искажениях CURE-OR;
  • добавить небольшой слой реальной передачи изображений через телефон и приложения;
  • отдельно проверить VLM, которые отвечают текстом, а не просто выдают класс.

В текущем релизе v0.4.1 есть:

  • 500 чистых строк Full-CURE-OR;
  • 38 999 строк с нативными искажениями;
  • 8 пригодных базовых моделей;
  • 180 изображений после реальной передачи;
  • 7 завершённых open-weight VLM строк на prompt pack из 900 строк;
  • 9 строк внешних провайдеров на меньшем prompt pack;
  • отдельный ряд xAI Grok 4.3 на 900 строк и повторный прогон.

Почему это не просто ещё одна таблица с accuracy

Обычный leaderboard отвечает на вопрос "кто выше". Мне хотелось получить другой ответ: "где разные модели ломаются одинаково".

Например, на уровне 5 Full-CURE-OR все 8 пригодных моделей попадают в нижний порог на трёх семействах искажений:

Как я собрал публичный AI benchmark и довёл его до GitHub, Kaggle, Zenodo и arXiv-ready состояния

Это важнее, чем просто сказать "модель A лучше модели B". Видно устойчивое ядро ошибок, которое повторяется между разными семействами моделей.

Как я собрал публичный AI benchmark и довёл его до GitHub, Kaggle, Zenodo и arXiv-ready состояния

Что показала реальная передача изображений

В проекте есть маленький блок `real-transfer`: 30 исходных изображений проходят через три пайплайна:

  • WhatsApp upload/download;
  • скриншот и пересохранение на iPhone;
  • захват кадра из FaceTime.

Результат оказался не драматичным, но полезным. Эффекты умеренные:

  • видеозвонок даёт среднее падение 2.1 процентного пункта;
  • мессенджер — 1.7 пункта;
  • скриншот и пересохранение в среднем не ухудшили результат в текущем маленьком блоке.

Это не значит, что все приложения безопасны для распознавания. Это значит, что нужен аккуратный `source-matched` протокол: сравнивать переданное изображение с тем же исходником, а не с другим clean set.

Как я собрал публичный AI benchmark и довёл его до GitHub, Kaggle, Zenodo и arXiv-ready состояния
Как я собрал публичный AI benchmark и довёл его до GitHub, Kaggle, Zenodo и arXiv-ready состояния

Почему VLM пришлось выделить отдельно

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

  1. правильный ли ответ;
  • можно ли его распарсить;
  • соблюдает ли модель формат;
  • как ведёт себя на чистых и переданных изображениях;
  • не меняется ли поведение из-за внешнего провайдера.

В текущем `open-weight VLM` блоке самый сильный завершённый ряд — LLaVA-OneVision-Qwen2-7B:

Как я собрал публичный AI benchmark и довёл его до GitHub, Kaggle, Zenodo и arXiv-ready состояния

Qwen2.5-VL-3B интересен именно как пример другого сбоя: много ответов становятся неразбираемыми. Для ассистентской модели это проблема даже тогда, когда часть распознаваний правильная.

Почему я не выкладываю все исходные данные

Публичный релиз CURE-OR++ сделан как агрегированный пакет. Это осознанное решение.

Публично доступны:

  • код;
  • конфиги;
  • агрегированные таблицы;
  • графики;
  • исходники статьи;
  • карточки датасета и оценки;
  • манифесты и проверки релиза;
  • Kaggle package;
  • DOI на Zenodo.

Не публикуются:

  • исходные изображения CURE-OR;
  • локальные фотографии из real-transfer;
  • сырые ответы внешних провайдеров;
  • API-кэши;
  • ключи и .env.

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

Что уже опубликовано

Сейчас проект находится в состоянии публичного релиза и подготовки arXiv.

Уже есть:

Исходники для arXiv уже собраны и локально компилируются. Сейчас упёрся в стандартный для нового аккаунта шаг: arXiv требует endorsement для категории cs.CV.

Что я вынес из проекта

Главные выводы не только про модели, но и про процесс:

  1. Маленький benchmark может быть полезным, если он проверяемый.
  2. Граница публичного релиза важна не меньше самих таблиц.
  3. Для VLM нужно считать не только точность, но и стабильность ответа.
  4. Реальные пайплайны передачи изображений лучше измерять отдельно, даже если блок маленький.
  5. GitHub, Kaggle и Zenodo хорошо дополняют друг друга: код, интерактивное чтение и архивная ссылка.

Что дальше

Ближайший план:

  • пройти arXiv endorsement;
  • опубликовать preprint;
  • обновить README, citation metadata и публичные ссылки;
  • собрать фидбек;
  • на основе фидбека подготовить v0.5.

Если у вас есть замечания по дизайну benchmark, оценке моделей, границе публичного релиза или воспроизводимости, буду рад комментариям и GitHub Issues.

Если у вас есть опыт публикаций в cs.CV или близких категориях arXiv и вы готовы посмотреть проект как потенциальный endorser, это тоже сейчас актуально.

2