Плаваюча істинна цінність: фіксація версії набору даних у комплексах для оцінки ШІ

Коли результат тестування ШІ змінюється між двома запусками, ви хочете знати, чи змінився сама модель, чи дані, за якими вона оцінювалася. У більшості схем відкритої оцінки ніщо не фіксує другу можливість. Нещодавня перевірка каталогу завдань у 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 комітів від 2020-08-27 до версії HEAD від 2026-09-10, причому вимірювання було проведено 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. У частині каталогу завдань, написаній на Python, з 15 файлів, які використовують load_dataset, 2 передають параметр revision=; серед 673 файлів на Python у цьому каталозі лише один з цих двох використовує посилання на pull-request для фіксації.

Отже, функція закріплення є, але нею майже ніхто не користується, і в усьому процесі роботи немає нічого, що б спонукало учасників до її використання. Коли стандартним варіантом є режим плаваючих конфігурацій, існує каталог з 841 такою конфігурацією, адже саме на стандартних налаштуваннях фактично працюють великі каталоги.

Якщо ви підтримуєте процес оцінювання, найдешевшим кроком буде сьогодні ж пошук у власних визначеннях завдань поля з інформацією про ревізію та перевірка кількості знайдених результатів.

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

openai/evals відповідає на ту саме запитання з протилежного боку, і його підхід не є явно гіршим. Серед 463 конфігурацій оцінювання 455 використовують файл samples_jsonl, який зберігається безпосередньо у репозиторії, і який містить 722 файли даних для їх підтримки. Альтернативні дані є готовими, тобто за своєю структурою вони закріплені: дані версіонуються разом із усім іншим за допомогою Git.

Перевагою є ідеальна відтворюваність: оцінку, зроблену у 2024 році, можна повторити з ідентичними за форматом даними. Ціною є використання грошей. Копія, придбана у постачальника, ніколи не отримує виправлень з верхнього рівня, тож хоча цей набір не може відхилятися, він може поступово перетворитися на „музей“, оцінюючи нові моделі за старим зразком, помилки якого були виправлені роками тому.

Жоден з цих наборів не обирає третій шлях – фіксацію певної версії та її свідоме оновлення. Один з них залишається у руху без жодних записів; інший замерзає без оновлень. У обох випадках вибір робиться за замовчуванням, а не на основі рішення.

Що не показує вимірювання

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

• Змін у наборі даних не спостерігалося. Політика мережі середовища аудиту відхиляла з’єднання до huggingface.co; проксі повертав код 403 під час запиту CONNECT з обох пристроїв, тому не вдалося отримати інформацію про резолюцію та час останньої зміни. Усе тут стосується можливості виявлення змін, а не того, чи справді вони відбулися.
• Відсутність позначки „прикріплено“ не означає помилки. Багато з цих наборів даних, ймовірно, ніколи не змінювалися. Йдеться про відсутність контролю, а не про наявну помилку.
• Старі дані не означають їх ігнорування. Конфігурація, яку ніхто не редагував протягом 700 днів, може бути повною та точною. Вік свідчить лише про те, що її ніхто більше не перевіряв, що відрізняється від наявності дефекту.

Один пристрій — це не весь спектр. Один каталог було проаналізовано детально, а інший використано для порівняння. Інструменти на кшталт promptfoo, deepeval та ragas є бібліотеками, а не реєстрами, і у них немає відповідного каталогу завдань у форматі YAML, тому результати їх не характеризують.

Вирішення щодо виключення файлів include: — це суб’єктивний вибір. Більш суворе тлумачення може передбачати перевірку, чи батьківські конфігурації фіксують параметри за своїми дочірніми. Їх було перевірено, і вони цього не роблять.

Поширені запитання

Чи означає це, що опубліковані результати тестування ненадійні?

Ні, і таке тлумачення слід відкинути. Бракує певного елемента контролю. Оцінка стає сумнівною лише тоді, коли змінюються базові дані; аудит показує, що у такому разі система не зберігає записів, які дозволили б це виявити пізніше.

Чому просто не перевірити, чи змінилися набори даних?

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

Чи є фіксація завжди правильною відповіддю?

Не завжди. Фіксована оцінка ніколи не виявляє справжніх корекцій неправильних міток, через що openai/evals може залишатися ідеально відтворюваним, але водночас поступово ставати неточним. Більш обґрунтованою політикою є поєднання фіксації та поступових змін: фіксувати певну версію, навмисно переходити до наступної та фіксувати кожну зміну, що насправді майже ніхто не робить.

Як можна перевірити власний набір інструментів?

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

Підсумок

• Розглядайте набори даних для оцінки як залежності: фіксуйте точну версію разом із кожним показником, який ви збираєтесь порівнювати.
• Будьте насторожі щодо різких співвідношень, поки не перевірите, що містить знаменник; успадковані та агреговані конфігурації майже перетворили незначне виявлення на оманливе.
• Динамічні та фіксовані дані призводять до проблем у протилежних напрямках: одні змінюються без сліду, інші старіють без корекції. Використання механізму фіксації та оновлень разом із журналом змін допомагає уникнути обох проблем.

Застарілість даних та відсутність пінів є ознаками відсутності механізмів контролю, а не доказами пошкоджених результатів.

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

Пов’язана література

• Ієрархічна карта концепцій інженерії ШІ та ситуацій, коли вони мають значення — Дізнайтеся, які концепції інженерії ШІ визначають, чи буде система взагалі працювати, які мають значення під час створення продукту для експлуатації, а які можна відкласти.
• Керування LLM як суддею як живою системою для експлуатації — Дізнайтеся, як чотириетапний цикл життя Netflix — дані з реального світу, навчання з використанням критеріїв оцінки, безпечне впровадження та постійний моніторинг — забезпечує точність LLM-судді у масштабах.