Как я собрал публичный 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 пригодных моделей попадают в нижний порог на трёх семействах искажений:
Это важнее, чем просто сказать "модель A лучше модели B". Видно устойчивое ядро ошибок, которое повторяется между разными семействами моделей.
Что показала реальная передача изображений
В проекте есть маленький блок `real-transfer`: 30 исходных изображений проходят через три пайплайна:
- WhatsApp upload/download;
- скриншот и пересохранение на iPhone;
- захват кадра из FaceTime.
Результат оказался не драматичным, но полезным. Эффекты умеренные:
- видеозвонок даёт среднее падение 2.1 процентного пункта;
- мессенджер — 1.7 пункта;
- скриншот и пересохранение в среднем не ухудшили результат в текущем маленьком блоке.
Это не значит, что все приложения безопасны для распознавания. Это значит, что нужен аккуратный `source-matched` протокол: сравнивать переданное изображение с тем же исходником, а не с другим clean set.
Почему VLM пришлось выделить отдельно
Когда модель отвечает текстом, обычной точности недостаточно. Нужно проверить:
- правильный ли ответ;
- можно ли его распарсить;
- соблюдает ли модель формат;
- как ведёт себя на чистых и переданных изображениях;
- не меняется ли поведение из-за внешнего провайдера.
В текущем `open-weight VLM` блоке самый сильный завершённый ряд — LLaVA-OneVision-Qwen2-7B:
Qwen2.5-VL-3B интересен именно как пример другого сбоя: много ответов становятся неразбираемыми. Для ассистентской модели это проблема даже тогда, когда часть распознаваний правильная.
Почему я не выкладываю все исходные данные
Публичный релиз CURE-OR++ сделан как агрегированный пакет. Это осознанное решение.
Публично доступны:
- код;
- конфиги;
- агрегированные таблицы;
- графики;
- исходники статьи;
- карточки датасета и оценки;
- манифесты и проверки релиза;
- Kaggle package;
- DOI на Zenodo.
Не публикуются:
- исходные изображения CURE-OR;
- локальные фотографии из real-transfer;
- сырые ответы внешних провайдеров;
- API-кэши;
- ключи и .env.
Причина простая: хороший публичный релиз должен быть проверяемым, но не должен нарушать условия исходных данных, приватность локальных изображений или безопасность API-артефактов.
Что уже опубликовано
Сейчас проект находится в состоянии публичного релиза и подготовки arXiv.
Уже есть:
- репозиторий GitHub: https://github.com/qu1nty9/Cure-or-plus-plus
- релиз GitHub v0.4.1: https://github.com/qu1nty9/Cure-or-plus-plus/releases/tag/v0.4.1
- DOI на Zenodo: https://doi.org/10.5281/zenodo.21239828
- Kaggle dataset: https://www.kaggle.com/datasets/yaroslavkholmirzayev/cure-or-plus-plus-v041-public-flat
- ноутбук Kaggle: https://www.kaggle.com/code/yaroslavkholmirzayev/cure-or-v0-4-1-public-benchmark-writeup
- Kaggle writeup: https://www.kaggle.com/writeups/yaroslavkholmirzayev/cure-or-object-recognition-robustness-under-nat
Исходники для arXiv уже собраны и локально компилируются. Сейчас упёрся в стандартный для нового аккаунта шаг: arXiv требует endorsement для категории cs.CV.
Что я вынес из проекта
Главные выводы не только про модели, но и про процесс:
- Маленький benchmark может быть полезным, если он проверяемый.
- Граница публичного релиза важна не меньше самих таблиц.
- Для VLM нужно считать не только точность, но и стабильность ответа.
- Реальные пайплайны передачи изображений лучше измерять отдельно, даже если блок маленький.
- GitHub, Kaggle и Zenodo хорошо дополняют друг друга: код, интерактивное чтение и архивная ссылка.
Что дальше
Ближайший план:
- пройти arXiv endorsement;
- опубликовать preprint;
- обновить README, citation metadata и публичные ссылки;
- собрать фидбек;
- на основе фидбека подготовить v0.5.
Если у вас есть замечания по дизайну benchmark, оценке моделей, границе публичного релиза или воспроизводимости, буду рад комментариям и GitHub Issues.
Если у вас есть опыт публикаций в cs.CV или близких категориях arXiv и вы готовы посмотреть проект как потенциальный endorser, это тоже сейчас актуально.