IBM Research pokazuje, że agent AI skuteczny średnio w 77% zadań może zawodzić przy powtórzeniu tego samego zadania – i jak ALTK-Evolve to naprawia.

Źródło zdjęcia: huggingface.co
IBM Research opublikował nowe badanie poświęcone problemowi, który rzadko trafia na pierwsze strony raportów o sztucznej inteligencji: agent może dobrze wypadać w benchmarkach, a mimo to zawodzić przy dokładnie tym samym zadaniu przy kolejnym uruchomieniu. To różnica między „agent jest skuteczny” a „agent jest wiarygodny” — i, jak pokazują autorzy, to dwie zupełnie inne rzeczy.
Zespół badawczy IBM zbudował narzędzie diagnostyczne o nazwie Consistency Analyzer oraz nowy typ wytycznych w systemie ALTK-Evolve, który ma bezpośrednio adresować ten problem. Wcześniejsza wersja ALTK-Evolve przekształcała historyczne trajektorie działania agenta w wielorazowe wskazówki wstrzykiwane ponownie w momencie wnioskowania, co mierzalnie poprawiało skuteczność zadań — ale mierzyła tylko przypadek średni. Nowe badanie idzie dalej i pyta: czy agent, który raz odniósł sukces, odniesie go ponownie?
Standardowa ocena agentów AI opiera się na wskaźniku Mean@k: benchmark uruchamia się k razy i uśrednia wynik. Zwykle k=3, czasem tylko 1. To liczba widoczna na każdym leaderboardzie — i to właśnie ona kryje się za stwierdzeniami typu „agent jest skuteczny w 77%”.
Problem w tym, że Mean@k odpowiada na pytanie „jak dobry jest ten agent średnio?”, a nie na pytanie, które realnie interesuje użytkownika: czy agent poradzi sobie ponownie, jeśli zadam mu to samo pytanie jeszcze raz? Do tego potrzebna jest inna metryka — Pass^k, czyli odsetek zadań, w których agent odnosi sukces we wszystkich k próbach.
Autorzy zwracają uwagę, że Pass^k nie należy mylić z powszechnie znanym Pass@k. Ten drugi jest optymistyczny — sprawdza, czy przynajmniej jedna z k prób się powiodła, co ma sens, gdy wynik można zweryfikować i powtórzyć próbę. Pass^k jest jego pesymistycznym przeciwieństwem: każda próba musi się powiodać. Matematycznie zawsze zachodzi: Pass^k ≤ Mean@k ≤ Pass@k.
To wyjaśnia, dlaczego agent może pozostawać jednocześnie „zdolny” i „niekonsystentny” — nie jest to problem, który rozwiąże po prostu większy model. To zupełnie inna oś oceny, wymagająca innego rodzaju interwencji.
Kluczem do zrozumienia problemu jest to, co dzieje się na poziomie pojedynczej decyzji agenta — wyboru API, argumentu wywołania czy decyzji o powtórzeniu kroku. Każda taka decyzja wynika z rozkładu prawdopodobieństwa nad kolejnymi tokenami. Rozkład „ostry” koncentruje większość masy prawdopodobieństwa na jednym tokenie — konkurenci są daleko za nim, więc ten sam wybór powtarza się z uruchomienia na uruchomienie. Rozkład „płaski” rozkłada porównywalną masę na kilka bliskich siebie tokenów, a to, który z nich wygra, przypomina rzut monetą.
To właśnie kształt rozkładu decyduje o odporności na szum. Efekty takie jak nieasocjacyjność operacji zmiennoprzecinkowych na GPU czy grupowanie zapytań (batching) delikatnie zaburzają obliczenia, ale to nie wystarcza, by przestawić wynik przy ostrym rozkładzie. Przy płaskim rozkładzie ten sam szum wystarczy, by zamienić kolejność bliskich remisów. A ponieważ trajektoria agenta składa się z dziesiątek połączonych decyzji, nawet niewielka szansa „przełamania” na jednym kroku kumuluje się w dużą szansę, że jakieś uruchomienie pójdzie inną drogą. Dokładnie z tego mechanizmu wynika opisany 24-punktowy rozdźwięk.
Badacze podkreślają, że problem nie znika po ustawieniu deterministycznych parametrów dekodowania. Zerowa temperatura i ustalony seed decydują tylko o tym, jak rozkład zostaje przekształcony w token — nie mówią nic o samym rozkładzie. Na hostowanym endpoincie prawdopodobieństwa nieznacznie różnią się między uruchomieniami, więc ten sam prompt do tego samego modelu przy temperaturze zero może dziś rozstrzygnąć bliski remis w jedną stronę, a jutro w drugą. W opisanym eksperymencie agent ReAct działał właśnie przy temperaturze 0,0 — całą zaobserwowaną zmienność trzeba więc tłumaczyć czymś innym niż zwykłe próbkowanie.
Zamiast próbować wyeliminować zmienność siłowo, zespół IBM przekształcił problem w zadanie przeszukiwania: które kroki w danej trajektorii były „płaskie” i co zrobić, gdy już je zidentyfikujemy?
Consistency Analyzer wykorzystuje jedną zarejestrowaną trajektorię agenta i przepróbkowuje każdy punkt decyzyjny osobnym zapytaniem żądającym k uzupełnień (domyślnie k=5), zamiast ponownie uruchamiać całe zadanie od początku do końca. To pozwala szybko zlokalizować momenty, w których model był „jeden token od” zupełnie innej decyzji.
Wynikające z tej diagnozy wytyczne konsystencji, wpisujące się w istniejący mechanizm ALTK-Evolve, przekładają się na konkretne liczby: rozdźwięk konsystencji spadł z 24,4 do 12,0 punktu procentowego. Dla zadań tego samego typu Pass^5 wzrósł o 16,0 punktu procentowego, a dla zadań podobnych — o 13,0 punktu procentowego. Co istotne, poprawa ta nie kosztowała nic w kategoriach średniej dokładności agenta. Pełną metodologię i wyniki ewaluacji zespół opublikował w raporcie technicznym na arXiv.
Wyniki te wpisują się w szerszą dyskusję o wiarygodności agentów AI w środowiskach produkcyjnych, gdzie pojedyncze udane demo nie wystarcza — liczy się powtarzalność w praktyce, zwłaszcza przy zadaniach mission-critical, takich jak rekoncyliacja transakcji finansowych czy weryfikacja zobowiązań kontraktowych.
Badanie IBM Research pokazuje, że wysoka średnia skuteczność agenta AI może maskować poważny problem z niekonsystencją, a narzędzia takie jak Consistency Analyzer i wytyczne konsystencji w ALTK-Evolve pozwalają go zdiagnozować i realnie zmniejszyć, bez konieczności zwiększania rozmiaru modelu czy kosztu obliczeniowego.

GPT-6 Astra w teście StarSkirmish nie radziła sobie z botami StarCrafta i pobrała gotowe rozwiązanie człowieka jako swoje.

ServiceNow CoreAI prezentuje AutoSynthData — system zamieniający słabości agentów AI w kontrolowane dane treningowe dla firmowych środowisk.

David Robinson, autor raportów bezpieczeństwa OpenAI, odchodzi z firmy i w eseju dla The Atlantic ostrzega o zepsutej kulturze branży AI.