Google DeepMind ostrzega: większość gotowych umiejętności AI nigdy nie przeszła testów

Philipp Schmid, inżynier Google DeepMind odpowiedzialny za rozwój agentów i API Gemini, opublikował ostrzeżenie pod adresem całej branży budującej agentów AI. W nowym wystąpieniu 'Don't Ship Skills Without Evals' i towarzyszącym mu wpisie na blogu przekonuje, że tysiące tak zwanych agent skills, czyli pakietów instrukcji i procedur doszkalających agentów AI do konkretnych zadań, trafia do produkcji bez jakiejkolwiek systematycznej ewaluacji.

Agent skills to stosunkowo nowy element ekosystemu agentów AI, popularny zwłaszcza wokół Claude Code, Cursora i innych narzędzi programistycznych. Zamiast pisać nowego agenta od zera, deweloperzy dokładają do jego kontekstu gotowy pakiet instrukcji, przykładów i procedur, licząc, że model lepiej wykona konkretne zadanie, na przykład pracę z określonym API czy formatem pliku.

Vibe check zamiast testów

Według Schmida typowa droga takiej skill na produkcję wygląda tak: ktoś napisze ją ręcznie albo, coraz częściej, wygeneruje przy pomocy samego modelu AI, uruchomi dwa lub trzy razy, dostanie kciuk w górę od kolegi z zespołu i wysyła dalej. Nazywa to 'vibe checkiem' w kontraście do standardowych praktyk inżynierskich, w których kod bez testów jednostkowych po prostu nie trafia do produkcji.

Agent skills są potężne, ale często są generowane przez AI i nietestowane - Philipp Schmid, Google DeepMind

Problem pogłębia fakt, że skille działają w środowisku nie deterministycznym. Ten sam prompt z tą samą skillą w kontekście może dać różny wynik przy kolejnym uruchomieniu, więc dwa ręczne testy nie mówią nic wiarygodnego o tym, jak pakiet zachowa się w tysiącach realnych wywołań.

Skille, które szkodzą

Najbardziej niepokojący wątek w wystąpieniu Schmida dotyczy nie tylko braku testów, ale odwrotnego skutku: część skills mierzalnie pogarsza jakość odpowiedzi agenta względem sytuacji, w której w ogóle by z niej nie korzystał. Niezależna analiza dokumentacyjna, na którą powołują się komentatorzy tematu, opisuje przypadek, w którym model bez żadnej skill poprawnie wykonywał zadanie programistyczne, a po dołożeniu skill do kontekstu zaczął generować błędny kod w większości prób.

Autorka tej niezależnej analizy, Dachary Carey, przeanalizowała 673 skille dostępne publicznie i szczegółowo przetestowała 20 z nich, identyfikując sześć odrębnych mechanizmów, przez które dodatkowy kontekst zamiast pomagać, przeszkadza modelowi w wykonaniu zadania. Zbyt długie, 'kompleksowe' instrukcje wypadają w testach gorzej niż zwięzłe, bo zajmują miejsce w oknie kontekstu i rozmywają uwagę modelu.

Jak Google DeepMind proponuje testować

Schmid proponuje konkretną metodologię zamiast samej krytyki. Rekomenduje zdefiniowanie trzech wymiarów sukcesu dla każdej skill: czy wynik faktycznie działa (outcome), czy trzyma się przyjętych konwencji i stylu (style) oraz czy nie marnuje tokenów i powtórzeń (efficiency). Na tej podstawie buduje się zestaw 10-20 promptów testowych z deterministycznymi sprawdzeniami, najczęściej opartymi na wyrażeniach regularnych, uzupełnionymi w razie potrzeby o ocenę LLM jako sędziego dla bardziej jakościowych kryteriów.

W praktycznym przykładzie z własnego bloga Schmid pokazuje, jak przepisanie samego opisu skill do Gemini Interactions API, bez zmiany głównej logiki, podniosło odsetek zaliczonych testów z 66,7 do 100 procent. To sugeruje, że problemem bywa nie merytoryka instrukcji, lecz sposób, w jaki model interpretuje moment, w którym w ogóle powinien danej skill użyć.

Znaczenie dla polskich zespołów

Dla polskich firm i zespołów programistycznych korzystających z Claude Code, Cursora czy podobnych narzędzi agentowych wnioski Schmida są praktyczne, nie akademickie. Wiele publicznie dostępnych bibliotek skills, w tym repozytoriów promowanych jako gotowe do użycia, powstało bez żadnej ewaluacji i może w konkretnym środowisku produkcyjnym obniżać, a nie podnosić jakość pracy agenta.

Rekomendacja Schmida sprowadza się do prostego testu przed wdrożeniem: uruchomić zadanie z daną skill i bez niej na tym samym zestawie promptów, porównać wskaźnik powodzenia i zostawić skill w kontekście tylko wtedy, gdy realnie podnosi wynik. W przeciwnym razie, jak podkreśla, skill zajmuje miejsce w oknie kontekstu bez żadnej korzyści.