Плавающая истинная ценность: фиксация версии набора данных в средствах оценки больших языковых моделей

Когда показатель бенчмарка большой языковой модели меняется между двумя тестированиями, необходимо выяснить, изменилась ли сама модель или данные, на основе которых оценивалась. В большинстве схем открытой оценки не фиксируется вторая возможность. Недавняя проверка каталога заданий в lm-evaluation-harness, одном из наиболее популярных инструментов для оценки открытых моделей, показала, что из 841 конфигурации лишь одна содержит поле для указания версии набора данных, причем это значение вовсе не является фиксированной версией. В этой статье рассматривается, как было получено это число, почему знаменатель имеет такое же значение, как и числитель, как другой набор инструментов сделал противоположный выбор, и как можно провести аналогичную проверку для собственных оценок.

Основное число и число, которое было отклонено

Этот показатель стоит изучения отчасти из-за того, как сначала пошли ошибки при его расчёте. Ранняя версия отчёта указывала, что один из 13 986 конфигураций зафиксировал свои данные, что является гораздо более значительным показателем. Этот результат был отклонён в течение нескольких часов. Из этих 13 986 файлов 10 391 не указывают собственный набор данных, а получают его от родительского файла через include:, а 2 966 — это групповые файлы, которые вообще не указывают никакого набора данных. Ни один из этих типов файлов не содержит элементов для фиксации, поэтому их учёт завышает знаменатель, заставляя результат казаться гораздо более значимым, чем он есть на самом деле. Аналитики отметили, что это уже второй раз за неделю, когда впечатляющие цифры получались из-за непроверки содержимого знаменателя, что служит полезным предупреждением для всех, кто самостоятельно формирует показатели.

После корректировки был сделан следующий вывод: в lm-evaluation-harness 841 конфигурация задач прямо указывает название набора данных, причем ровно одна из них заполняет поле с информацией о ревизии. В этом поле указано refs/convert/parquet — ссылка, выбирающая формат хранения, а не конкретную версию данных. На практике ни одна конфигурация не фиксирует определенную версию данных. Каждая запуском оценивается исходя из того состояния, в котором на момент выполнения находится исходный набор данных.

Основные выводы в кратком изложении

• Из 13,986 конфигураций задач 841 прямо указывают название набора данных. Остальные 13,145 делятся на 10,391 файла, которые наследуют набор данных через элемент include:, и 2,966 групповых файлов, не имеющих собственного набора данных.
• Только одна из этих 841 конфигураций устанавливает ключ ревизии или SHA, причем значение этого поля refs/convert/parquet выбирает формат файла вместо фиксации конкретной версии.

Из 673 файлов задач на Python только 15 используют функцию load_dataset, причем в 2 из них указан параметр revision=.

Конфигурации соответствуют 273 различным наборам данных. Что касается среднего по значению набора данных, то ни одна конфигурация, ссылающаяся на него, не изменялась в течение 547,9 дней. 196 из 273 (71,8%) наборов данных были не обновлены более года, а 245 (89,7%) — более шести месяцев.

Проект openai/evals придерживается противоположного подхода: 455 из 463 тестов в нем читают файл samples_jsonl, находящийся в репозитории, который подкрепляется 722 файлами данных, сохранёнными в репозитории. Истинные значения для сравнения не могут меняться, но могут устареть.

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

Кратко

Набор инструментов для оценки по сути представляет собой граф зависимостей, и команды разработчиков фиксируют эти зависимости по веским причинам. Просмотр каждой конфигурации задачи в lm-evaluation-harness, извлечение набора данных, по которому оценивается каждая задача, и поиск фиксированной версии привели к одному кандидату на роль фиксированной версии, который на самом деле ею не являлся. Анализ того, как долго эти конфигурации оставались незатронутыми, показал, что для среднего по значению набора данных последняя измененная конфигурация не использовалась примерно восемнадцать месяцев. Всё это не доказывает, что какие-либо опубликованные показатели тестирования неверны. Это лишь показывает, что если показатель станет неверным из-за изменения данных, сам набор инструментов не подаст никаких сигналов об этом.

Почему для тестирования необходима фиксированная версия набора данных

Модель, находящаяся на тестировании, — не единственный элемент, который может измениться. Каждая конфигурация задачи соответствует набору данных, такому как alexandrainst/m_truthfulqa, OALL/ACVA или CogComp/mc_taco, причем наборы данных, размещенные на публичных платформах, представляют собой постоянно развивающиеся ресурсы. У них есть владельцы, которые вносят исправления, изменения лицензий, перераспределение данных, новые конфигурации, а время от времени — безвестные корректировки меток, о которых было известно, что они неверны. Такая деятельность является нормальной и в основном полезной.

Проблема заключается в том, как это влияет на сравнения. Оценка имеет смысл только в отношении стабильного эталона. Когда новая версия модели дает другую оценку, это позволяет узнать что-то о самой модели. Однако если изменяются данные, речь идет о погрешности измерения, которая выглядит как результат исследования. Без записи версии невозможно отличить одно от другого ни в последующем анализе, ни в момент проведения оценки.

Оценка без фиксации — это измерение, результаты которого никогда не были занесены в записи.

Это тот же принцип, что лежит в основе файлов блокировки в проектах на JavaScript: диапазон в package.json, такой как ^4.2.0, позволяет системе автоматически использовать новый код, а файл блокировки фиксирует точную версию, используемую в проекте. Данным оценки следует относиться аналогичным образом.

Как был получен этот показатель

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

• Хранилище: EleutherAI/lm-evaluation-harness, скопированное с полной историей изменений с использованием параметров --filter=blob:none --unshallow. В него вошли 4,115 коммитов с 27.08.2020 по дату HEAD 10.09.2026; измерения проводились 12 сентября 2026 года. Каталог постоянно обновляется, поэтому последующие запуски принесут другие цифры.
• Просмотр конфигурации: все файлы формата .yaml и .yml, находящиеся в папке lm_eval/tasks. Для каждого файла скрипт извлекал значения dataset_path или hf_path, искал наличие ключей dataset_revision, revision, dataset_sha или sha, а также фиксировал, используется ли в файле параметр include:.

Подходящий знаменатель: только файлы, сами являющиеся названием набора данных. Конфигурации, унаследованные по наследству, и групповые файлы, которые лишь объединяют другие задачи, были исключены, поскольку у них нет собственных элементов для фиксации.

Старость: для каждого файла с помощью команды git log определялась дата добавления и последней модификации; эта дата сравнивалась не с текущей датой, а с датой коммита HEAD, чтобы значения оставались неизменными со временем.

В результате такой фильтрации осталось 841 подходящая конфигурация, указывающая на 273 отдельных набора данных.

Насколько стары эти конфигурации?

Степень старости необходимо указывать двумя способами, поскольку очевидный расчет оказался вводящим в заблуждение, и это стало ясно только после ручной проверки.

При учете каждой конфигурации среднее время с момента последней модификации составляет 729,8 дня. У 691 из 841 конфигурации (82,2%) не происходило изменений в течение более года, а у 551 (65,5%) изменения вообще не проводились с момента их добавления.

Эти цифры искажают реальную картину. Всего пять коммитов добавили 50,9% от общего числа конфигураций — 841 штуку, причем один коммит decc533d добавил 272 из них за один день. Следовательно, распределение по отдельным конфигурациям не отражает 841 независимый вариант, развивающийся по собственному графику; оно отражает лишь несколько крупных вкладов и небольшое количество более редких изменений.

Группировка по наборам данных вместо файлов устраняет такую концентрацию:

• Для среднего набора данных с момента последней модификации любой связанной конфигурации прошло 547,9 дня.
• У 196 из 273 наборов данных (71,8%) срок превысил один год.
• У 245 из 273 наборов данных (89,7%) срок превысил 180 дней.

Самый заброшенный пример просуществовал 994,1 дня.

Цифра по отдельным наборам данных — вот та, которую стоит приводить, поскольку она выдерживает критику, связанную с группировкой данных. Медиана по-прежнему составляет примерно восемнадцать месяцев, а девять из десяти наборов данных просуществовали более шести месяцев.

Поддерживается фиксация версии, но редко используется

Было бы несправедливо критиковать этот набор инструментов за то, что он делает фиксацию версии невозможной, однако это не так. В основе лежит стандартная библиотека Hugging Face datasets, и функция load_dataset принимает параметр revision. Среди 15 файлов в разделе задач на Python, которые вызывают load_dataset, 2 из них передают параметр revision=; среди 673 файлов на Python в этом каталоге — также 2 файла, причем один из них фиксирует версию по ссылке на pull-request.

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

Если вы занимаетесь ведением оценок, самый дешевый способ действий — сегодня же поискать в собственных определениях задач поле для версий и посмотреть, сколько результатов будет найдено.

Противоположный вариант компромисса: готовые данные в openai/evals

openai/evals отвечает на тот же вопрос, но с противоположной точки зрения, и его подход явно не уступает первому. Из 463 конфигураций оценок 455 используют файл samples_jsonl, хранящийся непосредственно в репозитории, который содержит 722 файла данных для их обработки. Истинные значения также предоставляются в виде готовых данных, что означает, что они фиксируются по умолчанию: данные версионируются с помощью Git вместе со всем остальным.

Преимущество заключается в полной воспроизводимости: оценка, сделанная в 2024 году, может быть повторена с использованием идентичных по содержимому данных. Ценой этого является использование денежной валюты. Готовая версия никогда не получает исправлений из источника, поэтому, хотя набор инструментов не может изменяться, он может постепенно превратиться в своего рода музей, где новые модели оцениваются по устаревшим данным, ошибки в которых были исправлены годами ранее.

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

Чего не показывает измерение

Ограничения анализа имеют такое же значение, как и его результаты.

• Изменений в наборе данных не было обнаружено. Политика сети среды аудита отклоняла подключения к huggingface.co; прокси возвращал код 403 при попытке подключения с обоих тестированных устройств, поэтому невозможно было получить информацию о местоположении и дате последней модификации. Всё здесь касается возможности обнаружения изменений, а не факта их наступления.
• Отсутствие пометки «фиксировано» не означает ошибку. Многие из этих наборов данных, вероятно, никогда не менялись. Речь идет о отсутствии контроля, а не об уже существующей ошибке.
• Устаревшая информация не означает пренебрежение. Конфигурация, в которой никто не вносил изменений в течение 700 дней, может быть полной и точной. Старость указывает лишь на то, что её никто больше не проверял, что отличается от наличия дефекта.

Один харнес — это не весь набор инструментов. Был изучен один каталог подробно, а другой использован в качестве контроля. Инструменты вроде promptfoo, deepeval и ragas являются библиотеками, а не реестрами, и у них нет сопоставимого каталога задач в формате YAML, поэтому результаты их тестирования ничего не говорят об этих инструментах.

Решение о исключении файлов с параметром include: принимается на основе оценки. Более строгий подход может предполагать проверку того, фиксируют ли родительские конфигурации настройки для своих дочерних элементов. Это было проверено, и такого не происходит.

Часто задаваемые вопросы

Значит ли это, что публикуемые результаты тестирования ненадежны?

Нет, такое толкование следует отвергнуть. Отсутствует определенный элемент контроля. Результат тестирования становится недостоверным только в случае изменения основных данных; аудит показывает, что при таком сценарии система не сохраняет записей, позволяющих обнаружить это изменение впоследствии.

Почему бы просто не проверить, изменились ли наборы данных?

Для этого необходимо обратиться на huggingface.co, чтобы узнать версии наборов данных, однако сетевая политика аудита блокировала такие запросы, возвращая ошибку 403 при попытке подключения как на облачном, так и на локальном компьютере. Вместо выводов о смещении на основе слабых признаков критерии ограничились тем, что можно проверить непосредственно в репозитории, поэтому вывод касался скорее фиксации значений, чем их изменения.

Является ли фиксация всегда правильным решением?

Не обязательно. Фиксированные методы оценки никогда не выявляют реальные корректировки ошибочных меток, из-за чего openai/evals может оставаться идеально воспроизводимым, но при этом постепенно терять точность. Более обоснованной стратегией является комбинация фиксации и постепенных изменений: заблокировать определённую версию, намеренно продвинуть её вперед и задокументировать каждое изменение, чего практически никто не делает.

Как проверить собственный набор инструментов?

Пройдитесь по определениям задач, выделите имена полей из набора данных и посмотрите в этих файлах на наличие каких-либо версий или ключей SHA. Отношение второго показателя к первому и является метрикой, о которой идет речь здесь. В отчете аудита указано примерно тридцать секунд вычислений на тысячу файлов, поэтому это недорогая процедура, которую можно добавить в CI.

Заключение

• Рассматривайте наборы данных для оценки как зависимости: фиксируйте точную версию вместе с каждым показателем, который вы собираетесь сравнивать.
• Сомневайтесь в резких отношениях, пока не проверите содержимое знаменателя; наследуемые и агрегированные конфигурации почти превратили незначительное обнаружение в вводящее в заблуждение.
• Плавающие и зафиксированные данные демонстрируют противоположные проблемы: одни меняются бесследно, другие стареют без корректировок. Метод фиксации и проверки с использованием журнала изменений позволяет избежать обеих проблем.

Старение данных и отсутствие штифтов являются признаками отсутствия механизмов контроля, а не доказательствами ошибочных результатов.

Конкретный вопрос, с которым сталкиваются все команды, проводящие оценку в CI, заключается в следующем: когда оценка меняется между запусками, что в вашей системе позволяет определить, изменился ли модель или данные? Если ответ — ничего, то поле для корректировок в определениях задач — это самое простое место для начала. Вы можете直接 ознакомиться с каталогом задач lm-evaluation-harness и реестром openai/evals, чтобы сравнить эти два подхода.

Связанная литература

• Иерархическая карта концепций инженерии ИИ и моменты, когда они имеют значение — Узнайте, какие концепции инженерии ИИ определяют работоспособность системы в целом, какие важны при разработке для производства и какие можно отложить.
• Управление LLM как судьей в качестве динамической производственной системы — Узнайте, как четырехэтапный цикл жизни Netflix — данные с истинными значениями, обучение с использованием критериев оценки, безопасное внедрение и постоянный мониторинг — обеспечивает точность LLM в крупном масштабе.