"Главная проблема исследователей — работа с плохо собранными данными и некорректными тестами. Это не техническая ошибка, а система, которая мешает оценить методы честно. Здесь речь о том, как плохо сделанные наборы данных и некорректные метрики могут исказить развитие науки и как их можно исправить — как те, кто уже проверяет алгоритмы по строгим правилам вроде аттестации ФСТЭК."
Скрытые ловушки в датасетах и тестах
Обычный исследователь, проверяя новый алгоритм поиска объектов на изображениях, берёт известный датасет — COCO или Open Images. Набор уже используется годами, статьи на него ссылаются. Но как собирали эти данные? Часто берут изображения из интернета, размечают аннотаторами на джуниор-позициях. Разметка может быть небрежной: объекты на границе кадра помечены частично, одинаковые объекты в разных фотографиях классифицированы разными людьми с разными критериями. Если алгоритм спотыкается на таких случаях, это его проблема или проблема данных?
Для российских компаний, работающих в области распознавания лиц, компьютерного зрения или обработки текстов, эта проблема особенно актуальна. Создавая собственные датасеты под специфические задачи, можно столкнуться с отсутствием стандартов разметки. Как помечать маску на человеке — как часть лица или как отдельный объект? Какие критерии для определения качества разговорной речи в датасете диалогов? Отсутствие таких стандартов приводит к тому, что даже внутри одной компании разные команды собирают данные по своим внутренним правилам, что затрудняет сравнение моделей.
Исследователи проверяют работу моделей на популярных тестах типа GLUE для языковых задач или ImageNet для классификации. Но тесты редко обновляются — мир меняется, в данных появляются новые типы объектов или языковые конструкции, которые не были представлены в исходном датасете. Обновлённая версия датасета редко делается с сохранением полной истории изменений: какие изображения добавлены, какие удалены, как изменения влияют на итоговые цифры. Если вы сегодня опубликовали статью с результатами на ImageNet 2012, а в 2023 выходит ImageNet 2023 с изменённым набором классов, сравнивать результаты напрямую не получится — метрики сдвинулись.
Это похоже на то, как в аттестации средств защиты информации есть эталонные тесты и методики проверки — без них нельзя гарантировать, что система защищает одинаково в разных условиях. Если тест для проверки криптостойкости меняется без публичной документации, результаты предыдущих проверок теряют смысл.
Почему тесты иногда не отражают реальность
Benchmarks, это не просто набор задач. Это свод правил: как запускать модель, как измерять скорость, как считать точность. Часто правила не учитывают реальные условия эксплуатации. Например, тест для языковой модели может измерять точность ответов на вопросы, но не учитывать, что в реальной системе модель будет получать вопросы с ошибками в тексте или в специфическом для отрасли контексте.
Ещё одна ловушка — зависимость от аппаратуры. Результаты теста, опубликованные на мощном сервере с GPU, не будут повторены на более слабом оборудовании. Но в исследованиях это часто не указывается: какая версия драйверов использовалась, какие настройки энергопотребления. Для инженера, который собирается применять модель в продукте, это критично: если тесты были на NVIDIA A100, а в эксплуатации будет отечественный процессор или карта другого производителя, производительность может снизиться вдвое, и это не будет отражено в статье.
В компьютерном зрении тесты часто измеряют точность на статичных изображениях, но не на видео — где объекты движутся, появляются помехи. Метрика mAP (mean Average Precision) может показать высокие цифры на датасете с чёткой разметкой, но в потоковом видео с низким освещением модель будет работать хуже. Разработчики систем наблюдения или автономных транспортных средств сталкиваются с этим: академические тесты не отражают специфику их задачи.
Такая ситуация приводит к тому, что исследователи выбирают тесты, которые «хорошо продают» статью — где их метод показывает высокие цифры. Но это не всегда тесты, которые отражают сложность реальной задачи.
Как стандарты могли бы помочь
Стандартизация, это не только единый формат файлов. Это процесс описания того, как данные собирались, какие критерии применялись при разметке, как тесты проводятся и как результаты считаются.
Набор данных должен включать:
- Метаданные о происхождении: где взяты исходные материалы, дата создания, лицензия.
- Процесс разметки: кто размечал, какие инструкции получили, как проверялось качество разметки, статистика по согласованности между разметчиками.
- Структура данных: как организованы файлы, как кодированы аннотации, есть ли возможность добавлять новые метки без нарушения структуры.
- Журнал изменений: если датасет обновляется, должна быть запись о том, что добавили, что удалили и почему.
Для тестов стандарты должны описывать:
- Условия запуска: точная аппаратная конфигурация, версии программного обеспечения, настройки, влияющие на производительность.
- Процесс вычисления метрик: как именно считается точность, какие этапы предобработки данных применяются перед тестом.
- Критерии успеха: какие метрики считаются основными, какие — дополнительными, как интерпретировать результаты.
- Правила сравнения: как сравнивать результаты разных исследований, если условия немного отличаются.
В российском ИТ, особенно в областях, связанных с обработкой персональных данных или критической инфраструктурой, такие стандарты могли бы стать частью практики аттестации. Если модель машинного обучения используется в системе, которая подпадает под требования 152-ФЗ, её корректность нужно проверять на тестах, которые отражают реальные условия работы. Стандартизированные датасеты и тесты могли бы стать частью методик аттестационных испытаний.
От идеи к практике
Создать стандарты — задача не для одного человека или лаборатории. Это требует согласия среди исследователей, инженеров и регуляторов. Процесс может быть похож на разработку технических стандартов в области защиты информации — где есть рабочие группы, обсуждения, версии документов.
Первым шагом могло бы стать создание открытых репозиториев с датасетами, которые уже соответствуют предложенным критериям. Например, датасет для распознавания дорожных знаков в российских условиях, с чётко документированными метаданными и процессом разметки. Или тест для проверки моделей классификации текстов на русском языке, с описанием аппаратных условий запуска и правилами подсчёта метрик.
Вторым шагом — внедрение таких стандартов в процессы рецензирования научных работ. Если статья использует датасет без метаданных или тест с неописанными условиями, рецензенты могут требовать предоставить эту информацию.
Третьим шагом — интеграция с регуляторными процессами. Если модель применяется в системе, требующей аттестации, наличие стандартизированных тестов и датасетов для её проверки могло бы упростить и объективизировать процесс испытаний.
Что можно сделать сейчас
Исследователь или инженер, работающий с машинным обучением, может начать с небольших изменений в своей практике:
- Документировать свои датасеты. Даже если набор данных небольшой, записать: откуда взяты данные, кто размечал, по каким правилам, какие инструменты использовались. Это повысит доверие к результатам.
- Публиковать условия тестов. В статьях или технических отчетах указывать не только итоговые метрики, но и детали аппаратной и программной среды, настройки, которые влияют на производительность.
- Создавать тесты под свои задачи. Если стандартные тесты не отражают специфику, разработать свой — с чётким описанием методики и метрик. И опубликовать его как открытый ресурс.
- Сравнивать модели на нескольких тестах. Использовать не один популярный benchmark, а набор — чтобы показать, как модель работает в разных условиях.
- Участвовать в обсуждениях стандартов. В профессиональных сообществах или на конференциях предлагать критерии для стандартизации данных и тестов в своей области.
Для российского ИТ это особенно важно: многие задачи уникальны — работа с русским языком в его современных формах, распознавание объектов в специфических условиях (например, при низкой освещённости зимой), обработка данных в отраслях с строгими регуляторными требованиями. Стандартизация здесь не просто удобство, а возможность строить более надёжные системы, которые будут корректно оцениваться как в исследованиях, так и в процессе внедрения.