Breaking News

Jak minimalne skażenie zbioru treningowego niszczy wiarygodność modelu

Nawet niewielkie skażenie zbioru treningowego może podważyć wiarygodność oceny modelu AI. Jeśli model zetknął się wcześniej z zadaniami testowymi lub ich odpowiedziami, dobry wynik nie pokazuje już jednoznacznie, jak poradzi sobie z nowym problemem. Nie oznacza to, że każdy taki model działa źle. Oznacza, że jego wynik może mierzyć częściowo pamięć, a nie tylko umiejętność rozwiązywania zadań.

Słowo „skażenie” obejmuje przy tym dwa różne zjawiska. Przeciek danych testowych utrudnia rzetelną ocenę możliwości modelu. Celowe zatruwanie danych może natomiast nauczyć go niepożądanej reakcji, która ujawni się dopiero w określonych warunkach. W obu przypadkach mały udział problematycznych przykładów w ogromnym zbiorze nie gwarantuje, że ich wpływ będzie mały.

Dlaczego kontakt z testem zmienia znaczenie wyniku?

Model trenuje się na przykładach, a następnie sprawdza na zadaniach, które mają być dla niego nowe. Taki podział pozwala ocenić uogólnianie: czy model wykorzystał to, czego się nauczył, do rozwiązania problemu spoza danych treningowych. Gdy pytanie testowe trafia do treningu, warunek niezależności przestaje być spełniony.

Wyobraź sobie test tłumaczenia, w którym model ma przełożyć zdanie na inny język. Jeżeli wcześniej widział zarówno oryginał, jak i gotowe tłumaczenie, może odtworzyć znaną parę zdań. Wysoka ocena takiej odpowiedzi nie daje tej samej informacji co poprawne tłumaczenie zdania, z którym model nigdy się nie zetknął. Podobny problem występuje w testach programowania: znajomość rozwiązania konkretnego zadania może poprawić wynik bez dowodu, że model równie dobrze napisze kod dla nowego polecenia.

Przeciek nie musi oznaczać dosłownej kopii pytania. W zbiorze treningowym może znaleźć się odpowiedź, rozwiązanie zapisane w nieco innej formie albo przykład bardzo podobny do testowego. Z drugiej strony samo podobieństwo nie dowodzi jeszcze, że model skopiował odpowiedź. To jeden z powodów, dla których wykrycie nakładania się danych jest łatwiejsze niż dokładne ustalenie, o ile zawyżyło ono końcowy wynik.

Jak niewielkie skażenie może zawyżyć ocenę?

Wpływ przecieku zależy nie tylko od tego, ile przykładów przeniknęło do treningu, lecz także od ich treści, sposobu podania i rodzaju testu. Jeśli ocena opiera się na ograniczonym zestawie zadań, znajomość części z nich może wyraźnie zmienić wynik. Szczególnie istotne jest to wtedy, gdy model widział nie samo pytanie, ale również poprawną odpowiedź.

Pokazuje to kontrolowany eksperyment dotyczący tłumaczenia maszynowego. Badacze porównali modele o wielkości 1 miliarda i 8 miliardów parametrów, celowo wprowadzając różne rodzaje skażenia. Gdy dane treningowe zawierały zarówno tekst źródłowy, jak i docelowy, wynik mierzony wskaźnikiem BLEU rósł. W badanych warunkach wzrost dla większego modelu był do 2,5 raza większy niż dla mniejszego i sięgał 30 punktów BLEU. BLEU mierzy podobieństwo tłumaczenia do wersji wzorcowej, więc taki wzrost może sprawiać wrażenie poprawy jakości, choć częściowo wynika z wcześniejszego kontaktu z przykładami.

W analizowanej mieszance treningowej autorzy znaleźli też około 10% przykładów testowych. Ta liczba dotyczy konkretnego badania, a nie wszystkich modeli tłumaczeniowych. Ważniejszy jest mechanizm: ten sam rodzaj przecieku może wpływać na różne modele w różnym stopniu. Nie da się więc bezpiecznie odjąć od każdego wyniku jednej stałej „poprawki na skażenie”.

Podobne ryzyko dotyczy testów generowania kodu. W badaniu benchmarków HumanEval i MBPP stwierdzono, że w zależności od zestawu zadań i analizowanego korpusu treningowego nakładanie się rozwiązań wynosiło od 3,6% do 20,8%. Dla HumanEval oszacowano obecność 12,2% rozwiązań w korpusie Pile i 18,9% w The Stack. Badacze zaobserwowali również lepsze wyniki modeli dla zadań, których identyczne lub podobne rozwiązania były widoczne podczas treningu. Nie oznacza to, że każda poprawna odpowiedź jest odtworzoną kopią. Oznacza jednak, że wynik całego benchmarku trudniej uznać za czysty pomiar samodzielnego rozwiązywania nowych problemów.

Dlaczego publiczne benchmarki są podatne na przeciek?

Benchmark to ustalony zestaw zadań służący do porównywania modeli. Publiczne benchmarki mają dużą zaletę: różne zespoły mogą sprawdzać swoje systemy na tych samych przykładach. Ta dostępność zwiększa jednak ryzyko, że pytania, odpowiedzi lub omówienia rozwiązań znajdą się w materiałach wykorzystanych później do treningu. Przeciek może nastąpić także bez celowego dodania testu do danych.

Problem nie ogranicza się do jednego języka czy jednego rodzaju zadania. W badaniu popularnych benchmarków wielojęzycznych wykryto oznaki skażenia w niemal wszystkich analizowanych połączeniach modeli i zestawów; tylko cztery z badanych przypadków nie wykazały takich oznak. To sygnał ostrzegawczy, ale nie dowód, że modele zapamiętały każde pytanie z tych testów.

Nie ma też jednej liczby opisującej skalę problemu we wszystkich benchmarkach. Przegląd badań wskazuje na raportowane efekty skażenia rzędu około 6–40% w głównych zestawach testowych, lecz zestawione prace używają różnych metod i miar. Nie należy traktować tego zakresu jak uniwersalnej prognozy, o ile pogorszy się wynik dowolnego modelu po usunięciu przecieku. Nawet stwierdzona obecność przykładów testowych w danych nie przekłada się automatycznie na wzrost oceny o określoną wartość.

Dlatego trafniejsze od stwierdzenia „wynik jest nieważny” bywa pytanie: jak dużą część wyniku da się przypisać zdolności do uogólniania? Odpowiedź wymaga porównania z zadaniami, co do których istnieją lepsze podstawy, by uznać je za nowe dla modelu.

Celowe zatruwanie danych to inny rodzaj zagrożenia

Przypadkowy przeciek benchmarku przede wszystkim zniekształca pomiar. Przy zatruwaniu danych ktoś umieszcza w zbiorze treningowym przygotowane przykłady po to, by zmienić zachowanie modelu. Jednym z możliwych skutków jest ukryta podatność typu backdoor: model zachowuje się zwyczajnie, dopóki w poleceniu nie pojawi się określony wyzwalacz.

Jak mały może być udział takich danych? W eksperymencie Anthropic, UK AI Security Institute i Alan Turing Institute 250 złośliwych dokumentów wystarczyło do wywołania badanej podatności w modelach mających od 600 milionów do 13 miliardów parametrów. Dokumenty te stanowiły około 0,00016% wszystkich tokenów treningowych w tym eksperymencie. W badanym scenariuszu wyzwalacz powodował generowanie bezsensownego tekstu.

To wynik dotyczący konkretnego sposobu ataku i konkretnych warunków badania. Nie dowodzi, że 250 dokumentów pozwoli wywołać dowolne zachowanie w każdym modelu. Pokazuje natomiast, dlaczego sam procent złośliwych danych w korpusie jest niewystarczającą miarą bezpieczeństwa: nawet śladowa domieszka może mieć znaczenie, jeśli uczy model wąskiej, precyzyjnie wywoływanej reakcji.

Jak rozpoznać skażenie i rzetelniej ocenić model?

Najprostsza kontrola polega na porównaniu zadań testowych z danymi treningowymi w poszukiwaniu identycznych fragmentów. Nie wychwyci jednak wszystkich parafraz ani rozwiązań zapisanych inaczej. Badania nad testami kodowania wykorzystują z tego powodu zarówno dopasowanie tekstowe, jak i analizę podobieństwa znaczeniowego. Ta druga pomaga znaleźć mniej oczywiste powiązania, ale również wymaga ostrożnej interpretacji: dwa podobne programy mogą powstać niezależnie, zwłaszcza gdy rozwiązują proste zadanie.

Gdy pełny zbiór treningowy jest niedostępny, można szukać pośrednich śladów wcześniejszego kontaktu z benchmarkiem. Jedna z metod sprawdza, czy model wykazuje szczególną preferencję dla oryginalnej kolejności zadań w opublikowanym teście w porównaniu z kolejnościami losowo przemieszanymi. Taki sygnał może wskazywać na ekspozycję na zestaw, choć sam nie mówi, jak dokładnie przełożyła się ona na każdą odpowiedź.

Osoba przygotowująca ocenę może ograniczać ryzyko na trzech poziomach:

  • Oddzielić test od treningu. Zachować część zadań poza publicznym obiegiem do zakończenia oceny oraz tworzyć nowe przykłady po zamrożeniu danych treningowych, jeśli jest to możliwe.
  • Sprawdzać więcej niż dosłowne kopie. Porównywać także znaczenie pytań i odpowiedzi, a w zadaniach kodowania — podobieństwo rozwiązań.
  • Pokazywać niepewność wyniku. Opisać metodę wykrywania przecieku i zestawić wynik publicznego benchmarku z oceną na świeższych, niezależnych zadaniach.

Duża różnica między wynikiem na znanym benchmarku a wynikiem na nowych przykładach może być powodem do dalszej analizy, nie zaś samodzielnym dowodem skażenia. Wiarygodna ocena wymaga wiedzy o pochodzeniu danych, ostrożności w interpretowaniu wykrytych podobieństw i testów, które rzeczywiście sprawdzają zachowanie modelu poza materiałem, z którym mógł zetknąć się wcześniej.

Przeczytaj również: