Pływająca prawda podstawowa: fiksacja wersji zestawu danych w zestawach do oceny modeli językowych

Gdy wynik testu modelu językowego zmienia się pomiędzy dwoma przeprowadzeniami, chce się wiedzieć, czy to model uległ zmianie, czy dane, na podstawie których był oceniany. W większości otwartych systemów oceny nic nie rejestruje drugiej możliwości. Niedawna audytura katalogu zadań w lm-evaluation-harness, jednym z najczęściej używanych narzędzi do generowania wyników modeli otwartych, wykazała dokładnie jeden konfigurator spośród 841, który zawierał pole dotyczące wersji zestawu danych, przy czym ta wartość wcale nie była identyfikatorem wersji. Ten artykuł wyjaśnia, w jaki sposób uzyskano tę liczbę, dlaczego mianownik ma takie samo znaczenie jak licznik, jak inne narzędzia dokonały odwrotnej decyzji oraz jak można przeprowadzić taką samą weryfikację we własnych ocenach.

Główna liczba oraz ta, która została odrzucona

Miarę tę warto zbadać po części ze względu na to, jak najpierw doszło do błędu. Wczesna wersja raportu wskazywała, że jedna z 13 986 konfiguracji zamknęła swoje dane, co stanowiło znacznie bardziej dramatyczny wynik. Została odrzucona w ciągu kilku godzin. Z tych 13 986 plików 10 391 nie określa samodzielnie żadnego zestawu danych, lecz odziedzicza go od pliku nadrzędnego za pomocą include:, natomiast 2 966 to pliki grupowe, które w ogóle nie określają żadnego zestawu danych. Żaden z tych typów plików nie ma nic do zamknięcia, więc ich uwzględnienie powoduje zawyżenie mianownika i sprawia, że wynik wydaje się znacznie mocniejszy, niż jest w rzeczywistości. Analitycy zauważyli, że to już drugi raz w ciągu jednego tygodnia, gdy imponujący wynik powstał z powodu braku sprawdzenia zawartości mianownika, co stanowi przydatne ostrzeżenie dla wszystkich, którzy sami tworzą wskaźniki.

Po korekcie wyniki są następujące: w lm-evaluation-harness 841 konfiguracji zadań wymienia bezpośrednio nazwę zestawu danych, a dokładnie jedna z nich wypełnia pole rewizji. Pole to zawiera refs/convert/parquet, co jest odniesieniem do formatu przechowywania, a nie do konkretnej wersji danych. W praktyce żadna konfiguracja nie jest ustalana jako stała. Każde uruchomienie ocenia dane na podstawie stanu, jaki akurat ma zestaw danych we dniu jego wykonywania.

Główne ustalenia w skrócie

• Z 13 986 konfiguracji zadań 841 wymienia bezpośrednio nazwę zestawu danych. Pozostałe 13 145 dzielą się na 10 391 plików, które odziedziczyły zestaw danych za pomocą include:, oraz 2 966 plików grupujących, które nie mają własnego zestawu danych.
• Tylko jeden z tych 841 plików ustawia klucz rewizji lub SHA, a wartość, którą zawiera, refs/convert/parquet, określa format pliku zamiast ustalać konkretną wersję.

Wśród 673 plików z zadaniami w Pythonie tylko 15 wywołuje funkcję load_dataset, a z nich zaledwie 2 podają wartość revision=.

Konfiguracje wskazują na 273 różne zbiory danych. W przypadku medianowego zbioru danych żadna konfiguracja go odnosząca się nie została zmodyfikowana przez 547,9 dnia. 196 z tych 273 (71,8%) miało to miejsce ponad rok temu, a 245 (89,7%) – ponad sześć miesięcy temu.

openai/evals stosuje przeciwny podejście: 455 z 463 ocen w tym projekcie czyta plik samples_jsonl znajdujący się w repozytorium, który jest wspierany przez 722 pliki danych zapisane w tym repozytorium. Prawdziwe wartości nie mogą ulec zmianie, ale mogą stać się przestarzałe.

Nie sprawdzono, czy jakikolwiek z oryginalnych zbiorów danych faktycznie uległ zmianie, ponieważ z środowiska audytowego nie było możliwe połączenie z huggingface.co. Wniosek brzmi, że zmiany mogłyby pozostać niezauważone, a nie że takie zmiany rzeczywiście wystąpiły.

Krótko mówiąc

Zestaw do oceny to w rzeczywistości graf zależności, a zespoły programistyczne fiksują te zależności z ważnych powodów. Przejrzenie każdej konfiguracji zadania w lm-evaluation-harness, wydobycie zestawu danych, na podstawie którego każde z nich dokonuje oceny, oraz poszukiwanie zapisanej wersji przyniosło jeden kandydat, który tak naprawdę nie stanowił fiksu. Pomiar czasu, przez jaki te konfiguracje pozostawały nienaruszone, pokazał, że dla medianowego zestawu danych żadna konfiguracja odnosząca się do niego nie była edytowana przez około osiemnaście miesięcy. Nic z tego nie wskazuje na to, że jakakolwiek opublikowana liczba z benchmarku jest błędna. Pokazuje to natomiast, że jeśli liczba ta stałaby się błędna z powodu zmian w danych, sam zestaw nie dałby żadnego sygnału.

Dlaczego benchmark potrzebuje zapisanej wersji zestawu danych

Model testowany nie jest jedyną rzeczą, która może ulec zmianie. Każda konfiguracja zadania odnosi się do zestawu danych, na przykład alexandrainst/m_truthfulqa, OALL/ACVA lub CogComp/mc_taco, a zestaw danych umieszczony na platformie publicznej stanowi żywy artefakt. Ma on opiekunów, otrzymuje korekty, zmiany licencji, nowe konfiguracje oraz od czasu do czasu cichą korektę etykiety, o której wiadomo, że była błędna. Taka działalność jest normalna i przeważnie korzystna.

Problem polega na tym, jak to wpływa na porównania. Wynik ma sens tylko w odniesieniu do stabilnego punktu odniesienia. Gdy nowa wersja modelu daje inny wynik, dowiadujemy się czegoś o tym modelu. Gdy natomiast zmieniają się dane, mamy do czynienia z artefaktem pomiarowym, który przypomina rzeczywisty wynik. Bez zapisanej wersji nie ma sposobu, by odróżnić te dwa przypadki, ani w perspektywie czasu, ani w momencie przeprowadzania oceny.

Wynik bez zapisu to pomiar, którego parametry nigdy nie zostały zanotowane.

To jest ta sama logika, która leży u podstaw plików lockfile w projektach JavaScript: zakres w pliku package.json, taki jak ^4.2.0, pozwala na cichą integrację nowego kodu, natomiast plik lockfile zapisuje dokładną wersję, która została użyta. Dane do oceny zasługują na takie samo traktowanie.

Sposób uzyskania tej liczby

Metodologia jest miejscem, w którym podejmowane są najciekawsze decyzje, szczególnie jeśli chodzi o mianownik.

• Repozytorium: EleutherAI/lm-evaluation-harness, sklonowane z pełną historią przy użyciu --filter=blob:none --unshallow. Obejmuje to 4 115 komitetów od 2020-08-27 aż do HEAD z dnia 2026-09-10, przy czym pomiary zostały przeprowadzone 12 września 2026 roku. Katalog stale się zmienia, więc późniejsze wykonywania dadzą inne liczby.
• Przegląd konfiguracji: każdy plik .yaml i .yml znajdujący się w katalogu lm_eval/tasks. Dla każdego pliku skrypt wyodrębniał wartości dataset_path lub hf_path, szukał informacji o dataset_revision, revision, dataset_sha lub sha, a także rejestrował, czy plik używał opcji include:.

Współczynnik kwalifikujący: tylko pliki, które same określają nazwę zestawu danych. Konfiguracje odziedziczone oraz pliki grupowe, które jedynie pakują inne zadania, zostały wykluczone, ponieważ nie mają nic własnego do przypięcia.

Stareństwo: analiza git log dla każdego pliku pokazała datę jego dodania i ostatniej modyfikacji, mierzona względem daty komitu HEAD, a nie bieżącej daty, dzięki czemu liczby pozostają stałe z upływem czasu.

To filtrowanie pozostawiło 841 kwalifikujących się konfiguracji wskazujących na 273 różne zestawy danych.

Jak stare są te konfiguracje?

Stareństwo musi być raportowane na dwa sposoby, ponieważ oczywisty sposób obliczania okazał się mylący, co stało się jasne dopiero po ręcznej weryfikacji.

Licząc według poszczególnych konfiguracji, mediana czasu od ostatniej modyfikacji wynosi 729,8 dnia. 691 z 841 konfiguracji (82,2%) nie było edytowanych od ponad roku, a 551 (65,5%) w ogóle nie zostało zmienionych po dodaniu.

Ty dane przesadzają obraz sytuacji. Zaledwie pięć komitetów doprowadziło do zmian w 50,9% z 841 konfiguracji, a sam komitet decc533d wprowadził zmiany w 272 z nich w ciągu jednego dnia. Dlatego rozkład według poszczególnych konfiguracji nie odzwierciedla 841 niezależnych decyzji ewoluujących według własnych harmonogramów; odzwierciedla jedynie kilka dużych wkładów oraz długi ogon wartości.

Grupowanie według zbiorów danych zamiast według plików eliminuje to skupianie się w określonych grupach:

• Dla medianowego zbioru danych minęło 547,9 dnia od ostatniej modyfikacji jakiejkolwiek konfiguracji, która do niego odnosiła się.
• 196 z 273 zbiorów danych (71,8%) znajdowało się w okresie dłuższym niż rok.
• 245 z 273 (89,7%) znajdowało się w okresie dłuższym niż 180 dni.

Najbardziej zaniedbane przypadki trwały 994,1 dnia.

Warto przytaczać wartość dla poszczególnych zestawów danych, ponieważ przetrwała ona zarzut związany z grupowaniem. Mediana wciąż wynosi około osiemnastu miesięcy, a dziewięć na dziesięć zestawów danych przekracza sześć miesięcy.

Pinning jest obsługiwany, choć rzadko używany

Byłoby niesprawiedliwe krytykować ten zestaw narzędzi, gdyby uniemożliwiał użycie pinningu, ale tak nie jest. Używana biblioteka do ładowania to standardowa biblioteka Hugging Face datasets, a funkcja load_dataset przyjmuje argument revision. W części zadań napisanej w Pythonie, z 15 plików, które wywołują load_dataset, dwa przekazują parametr revision=; wśród 673 plików Pythona w tym katalogu jeden z tych dwóch odnosi się do referencji pull-requesta.

Zatem chociaż funkcja przymocowania jest dostępna, prawie nikt jej nie używa, a żaden element procesu pracy nie zachęca autorów do jej stosowania. Gdy domyślnym ustawieniem jest tryb pływający, pojawia się katalog 841 konfiguracji w tym trybie, ponieważ to właśnie domyślne ustawienia są wykorzystywane w dużych katalogach.

Jeśli zarządzasz ocenami, najtańszym krokiem dalszym jest poszukiwanie w swoich definicjach zadań pola dotyczącego rewizji już dziś i sprawdzenie, ile wyników się pojawi.

Odwrotna kwestia kompromisu: dane dostarczane przez openai/evals

openai/evals odpowiada na to samo pytanie z innej perspektywy, a jego podejście nie jest wyraźnie gorsze. Wśród 463 konfiguracji ocen 455 korzysta z pliku samples_jsonl przechowywanego w samym repozytorium, który zawiera 722 pliki danych służące do ich obsługi. Prawdziwe dane są dostarczane z zewnątrz, co oznacza, że są one przymocowane przez samą strukturę systemu: dane te są wersjonowane przez Git razem ze wszystkim innym.

Zaletą jest doskonała powtarzalność: ocenę przeprowadzoną po raz pierwszy w 2024 roku można powtórzyć przy danych identycznych do bitu. Cena to waluta. Kopie dostarczane przez producenta nigdy nie otrzymują korekt z góry, więc chociaż zestaw nie może ulec dewiacjom, może powoli stać się „muzeum”, oceniając nowe modele na podstawie zrzutu stanu sprzed lat, w którym błędy zostały już poprawione.

Żaden z tych zestawów nie wybiera trzeciej drogi: utrzymywania konkretnej wersji i celowego jej rozwijania. Jeden z nich ewoluuje bez żadnych zapisków, drugi zastyga bez odświeżania. W obu przypadkach decyzja jest podejmowana domyślnie, a nie na podstawie świadomej decyzji.

Czego pomiar nie pokazuje

Ograniczenia analizy mają takie samo znaczenie jak jej wyniki.

• Nie zaobserwowano żadnych zmian w zestawie danych. Polityka sieciowa środowiska audytowego odrzucała połączenia z huggingface.co; proxy zwracał błąd 403 przy próbie połączenia z obu sprawdzanych maszyn, więc nie można było uzyskać informacji o rozwiązaniu problemu ani datie ostatniej modyfikacji. Wszystko tutaj dotyczy tego, czy zmiana zostałaby wykryta, a nie tego, czy rzeczywiście nastąpiła.
• Fakt, że dane nie są przypisane do konkretnego elementu, nie oznacza błędu. Wiele z tych zestawów danych prawdopodobnie nigdy się nie zmieniło. Problem dotyczy braku kontroli, a nie istniejącego błędu.
• Fakt, że dane są przestarzałe, nie oznacza ich zaniedbania. Konfiguracja, której nikt nie edytował od 700 dni, może być kompletna i dokładna. Wiek wskazuje jedynie na to, że nikt jej ponownie nie sprawdził, co różni się od wady.

Jeden zestaw narzędzi nie reprezentuje całego obszaru. Jeden katalog został przeanalizowany w głębi, a drugi użyto jako punkt odniesienia. Narzędzia takie jak promptfoo, deepeval i ragas to biblioteki, a nie rejestracje, i nie posiadają porównywalnego katalogu zadań w formacie YAML, więc wynik nie mówi nic o nich.

Wykluczanie plików include: to decyzja subiektywna. Stricter interpretacja mogłaby zakładać, że konfiguracje nadrzędne określają wartości za swoje potomne. Sprawdzono to i okazało się, że tak nie jest.

Częste pytania

Czy w takim razie opublikowane wyniki testów nie są wiarygodne?

Nie, i należy oprzeć się takiej interpretacji. Brakuje konkretnej kontroli. Wynik staje się niewiarygodny tylko wtedy, gdy zmieniają się dane podstawowe; audyt pokazuje, że w takim przypadku zestaw narzędzi nie zachowuje żadnych zapisów, które umożliwiłyby późniejsze wykrycie tej zmiany.

Dlaczego po prostu nie sprawdzić, czy zbiory danych się zmieniły?

To wymaga dostępu do huggingface.co, aby ustalić wersje zbiorków danych, co zostało zablokowane przez politykę sieciową audytu poprzez błąd 403 przy próbie połączenia CONNECT zarówno na chmurze, jak i na lokalnym komputerze. Zamiast wnioskować o odchyleniach na podstawie słabszych sygnałów, zakres sprawdzania został ograniczony do tego, co można zweryfikować wyłącznie na podstawie repozytorium, dlatego ustalenia dotyczą raczej fiksuwania wartości niż ich zmiany.

Czy fiksowanie wartości zawsze jest właściwą odpowiedzią?

Nie automatycznie. Fiksuje się tylko te wartości, które rzeczywiście nie uległy zmianie, więc prawdziwe korekty błędnych etykiet nie są uwzględniane, co sprawia, że openai/evals może być doskonale powtarzalny, a jednocześnie stopniowo nieprecyzyjny. Lepszą polityką jest podejście typu „fiksuj i aktualizuj”: zablokuj określoną wersję, celowo przesuń ją do przodu i zapisz każdą taką zmianę, co praktycznie nikt nie robi.

Jak sprawdzić swój własny zestaw narzędzi?

Niech definicje zadań będą przewodnikiem – wydobyj nazwy pól z zestawu danych i sprawdź w tych plikach poszukiwając jakichkolwiek informacji o rewizjach lub kluczach SHA. Stosunek drugiej liczby do pierwszej to miara omawiana tutaj. Audyt wskazał około trzydziestu sekund obliczeń na tysiąc plików, więc jest to tania procedura do włączenia do procesu CI.

Podsumowanie

• Traktuj zestawy danych do oceny jako zależności: zapisz dokładną rewizję obok każdej oceny, którą zamierzasz porównać.
• Bądź podejrzliwy wobec drastycznych stosunków, dopóki nie sprawdzisz, co zawiera mianownik; dziedziczone i agregowane konfiguracje niemal przekształciły skromne ustalenia w mylące.
• Dane zmienne i dane zamrożone sprawiają problemy w przeciwnych kierunkach: jedne zmieniają się bez śladu, drugie starzeją się bez korekty. Metoda „pin-and-bump” w połączeniu z dziennikiem zmian pomaga uniknąć obu problemów.

Zastarzenie i brak elementów montażowych to oznaki braku mechanizmów kontroli, a nie dowód na błędne wyniki.

Otwarte pytanie dla każdego zespołu przeprowadzającego oceny w środowisku CI jest konkretne: gdy wynik zmienia się pomiędzy różnymi próbami, co w Twojej konfiguracji pozwala stwierdzić, czy to model, czy dane uległy zmianie? Jeśli odpowiedzią jest „nic”, pole do edycji w definicjach zadań to najtańszy punkt wyjścia. Możesz bezpośrednio przejrzeć katalog zadań lm-evaluation-harness oraz rejestr openai/evals, aby porównać obie metody.

Literatura pokrewna

• Mapa poziomów koncepcji inżynierii SZI i kiedy są ważne — Dowiedz się, które koncepcje inżynierii SZI decydują o tym, czy system w ogóle funkcjonuje, które są istotne podczas tworzenia rozwiązań do produkcji, a które mogą poczekać.
• Zarządzanie LLM-jako-sędzią jako żywym systemem produkcyjnym — Przeczytaj, jak czterostopniowy cykl życia Netflixu – dane oparte na faktach, szkolenie dostosowane do kryteriów oceny, bezpieczne wdrożenie oraz ciągłe monitorowanie – zapewnia dokładność systemu oceny opartego na LLM w skali masowej.