Pułapki i kontaminacja danych

Kontaminacja: test w zbiorze treningowym

Najczęstszy powód, dla którego wyniki benchmarków kłamią, to kontaminacja danych — obecność zadań testowych (lub ich bliskich wariantów) w danych treningowych modelu. Model nie rozwiązuje wtedy zadania, tylko odtwarza je z pamięci. Problem jest stary, ale skala korpusów treningowych LLM uczyniła go centralnym tematem ewaluacji; obawy o wyciek zbiorów ewaluacyjnych do danych treningowych dokumentował już raport techniczny GPT-4 (OpenAI).

Formy kontaminacji

• bezpośredni wyciek — zadania testowe w treningu dosłownie (np. przez skrobanie stron z rozwiązaniami);
• warianty i parafrazy — zadania przepisane innymi słowami; wykrycie wymaga analizy semantycznej (Yang i in.);
• kontaminacja czasowa — trening na dokumentach „z przyszłości" względem daty odcięcia; testem są zadania opublikowane po dacie treningu (Golchin i Surdeanu);
• spec leakage — wyciek nie treści, a formatu lub etykiet, który pozwala modelowi zgadywać schemat odpowiedzi.

Prostym detektorem wycieku jest pokrycie n-gramów między zadaniem a korpusem treningowym:

$contam(x) = \max_{d \in \mathcal{D}} \frac{|\operatorname{ngram}_n(x) \cap \operatorname{ngram}_n(d)|}{|\operatorname{ngram}_n(x)|}$

Wartości bliskie 1 dla dużych $n$ oznaczają niemal dosłowny wyciek; krótsze $n$-gramy wykrywają też parafrazy.

Jak benchmarki się bronią

• świeże zadania — LiveCodeBench wybiera zadania z okna po dacie odcięcia treningu;
• zestawy prywatne — HLE trzyma część zadań w tajemnicy właśnie po to, by uniemożliwić trening na nich (Scale AI i CAIS);
• decontaminacja — autorzy raportują procedury usuwania nakładających się przykładów; społeczność mierzy sam problem w zadaniach typu CONDA.

Praktyczne zasady

1. Raportuj metodologię. Jaki zbiór, jaka wersja, jaka procedura decontaminacji — bez tego wyniku nie da się ocenić.
2. Weryfikuj podejrzane wyniki. Nienaturalnie wysokie wyniki na starych, publicznych zbiorach to czerwona flaga; sprawdź model na zestawie holdout lub świeżym wariancie.
3. Nie trenuj na zbiorach testowych i nie stroj promptów na części testowej — to kontaminacja „własna", równie groźna.

Inne pułapki

• prawo Goodharta — gdy scorer staje się celem, przestaje być miarą: optymalizacja pod BLEU potrafi psuć tłumaczenia;
• efekt daty i wersji — „ten sam" benchmark zmienia się w czasie; porównania wymagają tej samej wersji;
• przeuczenie ewaluacji — model wielokrotnie poprawiany pod publiczny ranking bywa przystosowany do benchmarku, nie do zadania.

Zobacz też: Jak czytać karty scorerów, Przegląd benchmarków.