Testy spójności agentów IBM pokazują, dlaczego jeden sukces nie wystarczy

Testy spójności agentów IBM ujawniły wyraźny konflikt między sukcesem w benchmarkach a niezawodnym działaniem. Agent GPT-4.1 ukończył 77,4% uruchomień AppWorld, lecz wszystkie pięć prób zaliczył tylko w przypadku 53,0% zadań.

Ta różnica 24,4 punktu zmienia znaczenie udanej demonstracji agenta. Jedno poprawne uruchomienie może pokazać, że agent ma wymaganą zdolność. Nie może jednak dowieść, że użytkownicy otrzymają ten sam wynik jutro — ani nawet za pięć minut.

IBM Research zajmuje się tym rozróżnieniem poprzez nowe wytyczne dotyczące spójności w ALTK-Evolve. System wykrywa niestabilne decyzje w zarejestrowanej trajektorii agenta, a następnie zamienia te słabości w instrukcje wielokrotnego użytku. Wstępne wyniki sugerują, że poprawa niezawodności nie zawsze wymaga większego modelu.

Praca ta podważa także standardowy sposób prezentowania wydajności agentów przez dostawców. Średnia z rankingu może premiować agenta, który często działa poprawnie, jednocześnie ukrywając, jak często zawodzi po wcześniejszym sukcesie.

Wyniki testów spójności IBM ujawniają brakującą metrykę

Kluczowy wniosek IBM jest taki, że średnia dokładność i powtarzalny sukces opisują dwa istotnie różne produkty.

Badacze przetestowali agenta ReAct opartego na GPT-4.1 na 168 zadaniach ze zbioru test_normal AppWorld. ReAct to projekt agenta, który przeplata kroki rozumowania z działaniami, takimi jak wywołanie aplikacji lub przeszukiwanie zapisanych informacji.

Każde zadanie otrzymało pięć niezależnych uruchomień. Według badania IBM dotyczącego spójności agent bazowy osiągnął wynik Mean@5 na poziomie 77,4%. Mean@5 uśrednia wskaźnik sukcesu z pięciu prób.

Wynik ten brzmi odpowiednio dla mocnej demonstracji produktu. Agent osiągnął jednak wynik Pass^5 wynoszący zaledwie 53,0%. Pass^5 uznaje zadanie za udane tylko wtedy, gdy wszystkie pięć prób kończy się sukcesem.

Różnica między tymi wynikami to luka spójności. W tym przypadku osiągnęła ona 24,4 punktu procentowego. IBM twierdzi, że w najtrudniejszej grupie zadań luka wyniosła 30 punktów.

To rozróżnienie ma znaczenie, ponieważ Pass^5 nie jest znaną metryką Pass@5 stosowaną w niektórych ocenach programowania. Pass@5 pyta, czy przynajmniej jedna z pięciu prób zakończy się sukcesem. Pass^5 pyta, czy sukcesem zakończy się każda próba.

Te metryki odpowiadają różnym produktom. Pass@5 sprawdza się, gdy system może wygenerować kilka kandydatów, przetestować ich i zachować zwycięzcę. Pass^5 pasuje do procesów, w których każde wykonanie musi być niezawodne.

Deweloper proszący agenta o pięć możliwych poprawek kodu może skorzystać z jednej poprawnej odpowiedzi. Zespół księgowy proszący agenta o uzgodnienie transakcji nie może bezpiecznie zaakceptować czterech poprawnych uruchomień i jednego szkodliwego błędu.

Ten sam problem dotyczy analizy umów. Agent, który rozpoznaje zobowiązanie podczas jednego przeglądu, lecz pomija je podczas innego, nie jest po prostu zmienny. Tworzy niespójne decyzje biznesowe na podstawie identycznych dowodów.

Wyniki IBM nie pokazują, że GPT-4.1 nie potrafi wykonywać tych zadań. Średnia 77,4% dowodzi, że często potrafi. Wyniki pokazują, że ta zdolność nie zachowywała niezawodnie swojej skuteczności przy powtarzaniu w tej konkretnej konfiguracji agenta.

To jest kluczowe odwrócenie perspektywy w artykule. Pierwszy sukces jest dowodem możliwości, a nie dowodem niezawodności operacyjnej.

Szersza społeczność zajmująca się ewaluacją doszła do podobnego wniosku. Wytyczne Anthropic dotyczące oceny agentów rozróżniają Pass@k i Pass^k oraz zalecają dopasowanie metryki do wymagań produktu.

Anthropic przedstawia prostą ilustrację. Zadanie ze wskaźnikiem sukcesu 75% na pojedynczą próbę ma około 42% szans na powodzenie w trzech niezależnych próbach. Pozorna jakość spada, ponieważ wymaganie zmienia się z okazjonalnego sukcesu na nieprzerwany sukces.

Średnie nadal mają wartość. Pomagają porównywać ogólne możliwości i ujawniają, czy zmiana poprawia wyniki w całym zbiorze zadań. Stają się jednak mylące, gdy nabywcy interpretują je jako gwarancję niezawodności.

W przypadku wdrożeń korporacyjnych w ocenie powinny znaleźć się obie liczby. Mean@k mówi zespołom, jak często agent działa. Pass^k mówi im, ile zadań pozostaje niezawodnych przy wielokrotnym użyciu.

Dlaczego agent może zmienić kierunek przy temperaturze zero

Agent może stać się niespójny, nawet gdy prompt, model, narzędzia i temperatura dekodowania pozostają pozornie niezmienione.

LLM wybiera każdy kolejny token z rozkładu prawdopodobieństwa. Niektóre decyzje mają wyraźnego faworyta, podczas gdy inne obejmują kilka niemal równie prawdopodobnych opcji.

IBM opisuje je jako decyzje ostre i płaskie. Ostry rozkład przypisuje większość prawdopodobieństwa jednemu wyborowi. Niewielkie zmiany obliczeniowe raczej nie zmienią zwycięzcy.

Płaski rozkład rozkłada prawdopodobieństwo na kilka wiarygodnych wyborów. Minimalne przesunięcie numeryczne może zmienić, który token pojawi się pierwszy, kierując agenta na inną ścieżkę.

Różnica ta staje się ważna w systemach korzystających z narzędzi. Pojedynczy zmieniony token może zmienić wybór API, zapytanie wyszukiwania, argument narzędzia, decyzję o ponowieniu próby lub interpretację wyniku pośredniego.

Zwykły chatbot może absorbować pewną zmienność sformułowań bez zmiany końcowego znaczenia. Agent działa na podstawie swoich wyborów pośrednich. Każdy zmieniony wybór modyfikuje informacje dostępne w następnym kroku.

Ryzyko narasta w długiej trajektorii. Jeśli agent podejmuje dziesiątki decyzji, kilka z nich może znajdować się blisko niestabilnych granic. Wystarczy, że jedna się odwróci, aby późniejsze wywołanie narzędzia lub końcowa odpowiedź zakończyły się niepowodzeniem.

IBM uruchomił swojego agenta ReAct przy temperaturze 0.0. Badacze twierdzą więc, że zwykłe próbkowanie nie spowodowało zaobserwowanej zmienności.

Temperatura zero nie sprawia, że każde wykonanie hostowanego modelu jest matematycznie identyczne. Grupowanie żądań, zachowanie sprzętu, operacje zmiennoprzecinkowe i szczegóły implementacji po stronie dostawcy mogą nieznacznie zmieniać prawdopodobieństwa.

Te przesunięcia często pozostają niewidoczne podczas zwykłego generowania tekstu. Mają znaczenie, gdy dwa wybory są niemal remisowe. Niewielka zmiana może zmienić ich kolejność mimo niezmienionego żądania użytkownika.

Stały seed również ma ograniczenia. Kontroluje część procesu generowania, ale nie zamraża każdej warstwy zdalnego systemu inferencyjnego. Nie sprawia też, że niepewna decyzja staje się bardziej stanowcza.

Mechanizm ten wyjaśnia, dlaczego udana próba może zawieść podczas demonstracji na żywo. Agent niekoniecznie zapomniał zadania. Wszedł na inną gałąź tego samego drzewa decyzyjnego.

Rozważmy agenta poproszonego o policzenie ukończonych aktywności w notatce. W jednym uruchomieniu może zliczyć każdy znacznik pola wyboru. W innym może również zliczyć legendę wyjaśniającą format pól wyboru.

Obie ścieżki mogą początkowo wyglądać rozsądnie. Tylko jedna daje zamierzoną sumę. Błąd wynika z nierozstrzygniętej decyzji dotyczącej interpretacji dokumentu, a nie z braku dostępu do notatki.

Dłuższe procesy wzmacniają to zachowanie. Agent badawczy może wybrać inne źródło, błędnie zrozumieć niejednoznaczną datę lub zatrzymać się po pierwszym pasującym dokumencie. Każdy wybór kształtuje wszystko, co następuje później.

To sprawia, że niezawodność agentów AI jest częściowo problemem orkiestracji. Lepszy model bazowy może zwiększyć prawdopodobieństwo podejmowania dobrych decyzji, ale nie gwarantuje zniknięcia jego granicznych wyborów.

Warunki zewnętrzne dodają kolejną warstwę. ReliabilityBench ocenia wielokrotne wykonanie obok sparafrazowanych żądań i awarii narzędzi. Jego ramy testów obciążeniowych produkcji traktują spójność, odporność i tolerancję błędów jako odrębne wymiary.

Obecny eksperyment IBM wężej izoluje powtarzane uruchomienia. To skupienie ułatwia analizę luki spójności, lecz nie obejmuje każdej awarii produkcyjnej, z którą spotka się agent.

Rzeczywiste wdrożenia mierzą się ze zmienionymi danymi, wygasłymi poświadczeniami, limitami szybkości API, częściowymi odpowiedziami i ewoluującymi schematami. Stabilne zachowanie przy identycznych danych wejściowych jest więc wymaganiem początkowym, a nie całym standardem niezawodności.

ALTK-Evolve zamienia niepewność w ukierunkowane wskazówki

ALTK-Evolve próbuje naprawiać niestabilne decyzje bez ponownego odtwarzania każdego zadania w środowisku na żywo.

Nowy proces zaczyna się od jednej zarejestrowanej trajektorii. Trajektoria to uporządkowany zapis promptów, decyzji, wywołań narzędzi, obserwacji i odpowiedzi powstałych podczas uruchomienia agenta.

Consistency Analyzer IBM ponownie analizuje każdy punkt decyzyjny, wykorzystując kontekst zapisany już w tym śladzie. Żąda kilku alternatywnych uzupełnień i mierzy, jak bardzo różni się wybór modelu.

Domyślna konfiguracja pobiera pięć uzupełnień za pomocą jednego dodatkowego wywołania modelu na każdy krok decyzyjny. Nie powtarza zewnętrznych wywołań narzędzi ani nie uruchamia ponownie całego zadania.

Ten projekt ma znaczenie w produkcji. Pełne odtworzenie mogłoby wysłać kolejny e-mail, dwukrotnie zmodyfikować rekord, powielić zakup lub napotkać dane, które już się zmieniły.

Próbkowanie offline pozwala uniknąć tych skutków ubocznych. Eliminuje również potrzebę etykiety prawdy referencyjnej na etapie diagnostycznym.

Analizator jest czarną skrzynką, co oznacza, że nie wymaga logitów modelu ani dostępu wewnętrznego. Zespoły mogą stosować go wobec hostowanego modelu, jeśli posiadają oryginalny ślad i mogą ponownie przesłać jego konteksty decyzyjne.

Każda decyzja otrzymuje ocenę spójności. Kroki z rozbieżnymi uzupełnieniami stają się kandydatami do dodatkowych wskazówek.

ALTK-Evolve następnie przekształca tych kandydatów w zwięzłe instrukcje zachowania. Jego szerszym celem jest wydobywanie użytecznych lekcji z wcześniejszych trajektorii i odzyskiwanie ich podczas późniejszych zadań.

W przykładzie liczenia notatek wygenerowana wskazówka rekomendowała wyrażenie regularne zakotwiczone w wierszu zamiast podstawowego zliczania podciągów. Nakazywała również agentowi sprawdzenie wielu wyników wyszukiwania przed wybraniem notatki.

Te instrukcje dotyczą ogólnych wzorców błędów. Nie zapisują po prostu poprawnej odpowiedzi liczbowej z pierwotnego zadania.

Ta różnica jest kluczowa. Zapamiętanie jednej odpowiedzi poprawiłoby wynik zadania benchmarkowego bez wzmocnienia agenta. Reguła wielokrotnego użytku może pomóc w przypadku nowych notatek, innych formatów pól wyboru lub powiązanych decyzji dotyczących wyszukiwania.

Repozytorium ALTK-Evolve zawiera teraz Consistency Analyzer oraz komponenty generowania wytycznych. Projekt korzysta z licencji Apache 2.0 i wspiera integrację poprzez Model Context Protocol.

Jego warstwa odzyskiwania wprowadza odpowiednie wytyczne do kontekstu agenta w czasie inferencji. Daje to modelowi ukierunkowane przypomnienia bez konieczności utrzymywania każdego historycznego śladu w aktywnym prompcie.

Podejście to przypomina skoncentrowaną formę pamięci operacyjnej. Zamiast prosić agenta, by ponownie czytał wszystko, co zrobił, system destyluje powtarzające się lekcje i odzyskuje te związane z bieżącym zadaniem.

To rozróżnienie ma również znaczenie dla pracy z wiedzą. Większe archiwum nie prowadzi automatycznie do lepszych decyzji. Użyteczna pamięć wymaga selekcji, obsługi konfliktów i kontekstu odpowiedniego dla aktywnego żądania.

Ta sama zasada leży u podstaw dobrze zorganizowanej bazy wiedzy AI. Zapisane materiały stają się wartościowe, gdy system potrafi odzyskać właściwe dowody bez zalewania kontekstu roboczego.

Metoda ALTK-Evolve jest węższa niż ogólna platforma wiedzy. Koncentruje się na zachowaniu agentów i wykorzystuje wytyczne pochodzące z trajektorii. Mimo to oba przypadki ujawniają to samo ograniczenie: zachowywanie informacji jest łatwiejsze niż zastosowanie właściwej informacji we właściwym momencie.

Mechanizm tworzy również pętlę sprzężenia zwrotnego. Zespoły mogą gromadzić ślady wykonania, wykrywać niestabilne kroki, generować kandydatów na wytyczne i oceniać, czy te wytyczne poprawiają późniejsze uruchomienia.

System nie eliminuje jednak potrzeby testów. Wygenerowana reguła może być błędna, zbyt szeroka lub szkodliwa poza sytuacją, która doprowadziła do jej powstania.

Zespoły nadal potrzebują wersjonowania i możliwości wycofywania zmian. Muszą też śledzić, która wytyczna wpłynęła na decyzję, zwłaszcza gdy agent wykonuje pracę regulowaną lub mającą istotne konsekwencje finansowe.

Wzrost niezawodności jest duży, ale dowody są ograniczone

IBM informuje o znaczącej poprawie, choć badanie pozostaje wczesną oceną w jednej głównej konfiguracji benchmarku.

Po dodaniu wytycznych dotyczących spójności Pass^5 wzrósł z 53,0% do 69,0% w 168 zadaniach AppWorld. Oznacza to poprawę o 16 punktów w liczbie zadań zaliczonych we wszystkich pięciu uruchomieniach.

Wzrósł również Mean@5 — z 77,4% do 81,0%. Luka spójności zmniejszyła się więc z 24,4 punktu do 12,0 punktów.

Wynik ten ma znaczenie, ponieważ średnia nie spadła. Metoda, która poprawiałaby powtarzalność przez zmuszenie agenta do konsekwentnie przeciętnej strategii, nie rozwiązałaby podstawowego problemu.

IBM twierdzi, że wytyczne utrzymały lub poprawiły Mean@5 na każdym poziomie trudności. Grupa zadań średnich zyskała 22,9 punktu w Pass^5, a grupa trudnych — 14,3 punktu.

Względna poprawa wyniosła 44% dla zadań średnich i 45% dla trudnych. Zadania łatwe zyskały 12,2 punktu, przy mniejszej przestrzeni do poprawy.

IBM testował także wytyczne na innym, lecz powiązanym zadaniu w ramach tego samego scenariusza AppWorld. Pass^5 wzrósł o 13 punktów, wobec 16-punktowej poprawy dla tego samego zadania.

Wynik ten wspiera tezę, że część wytycznych przenosi się poza jedną zarejestrowaną trajektorię. Nie ustanawia jednak szerokiej generalizacji między niepowiązanymi aplikacjami, branżami czy architekturami agentów.

W drugim eksperymencie wykorzystano gpt-oss-120b. Jego Pass^5 dla tego samego zadania wzrósł z 10,1% do 16,1%, a wydajność w podobnych zadaniach zwiększyła się o 8,7 punktu.

Słabszy punkt wyjścia pokazuje, że wskazówki nie mogą w pełni zastąpić możliwości modelu. Poprawa o sześć punktów jest istotna, lecz wskaźnik sukcesu we wszystkich uruchomieniach na poziomie 16,1% nadal nie nadaje się do automatyzacji o istotnych konsekwencjach.

Pełny raport techniczny przedstawia metodologię stojącą za tymi twierdzeniami. Mimo to czytelnicy powinni traktować wyniki jako dowody z oceny przeprowadzonej przez autorów, a nie jako niezależne potwierdzenie w systemach produkcyjnych.

Główny test wykorzystuje jedną konfigurację ReAct, jeden podstawowy podział benchmarku i pięć powtórzeń na zadanie. AppWorld oferuje realistyczne scenariusze obejmujące wiele aplikacji, ale benchmark pozostaje kontrolowanym środowiskiem.

Pięć uruchomień ujawnia niestabilność, którą ukrywa pojedyncze uruchomienie. Nie pozwala jednak precyzyjnie oszacować rzadkich awarii, które mogą pojawić się w tysiącach interakcji z klientami.

Ocena rodzi również pytanie statystyczne. Pass^k naturalnie spada wraz ze wzrostem k, ponieważ każda dodatkowa próba tworzy kolejną okazję do porażki.

Zespół produktowy musi więc dobrać k do rzeczywistej skali ekspozycji. Pięć udanych uruchomień może być rozsądnym kryterium na etapie rozwoju. Nie dowodzi jednak niezawodności w skali przedsiębiorstwa.

Wytyczne mogą też się zdezaktualizować. API się zmieniają, polityki ewoluują, a wcześniejsze obejścia mogą kolidować z nowym zachowaniem systemu.

Reguła wyprowadzona z jednej niestabilnej gałęzi może w innym miejscu tłumić prawidłową alternatywę. Im więcej wytycznych gromadzi system, tym ważniejsze stają się rozwiązywanie konfliktów i jakość wyszukiwania.

Istnieje także różnica między spójnym zachowaniem a poprawnym zachowaniem. Agent, który powtarza to samo błędne działanie, ma doskonałą stabilność zachowania i zerową wartość zadaniową.

Eksperyment IBM zabezpiecza się przed tym problemem, raportując Mean@5 obok Pass^5. Zespoły produkcyjne powinny zachować to samo zestawienie i dodać środki bezpieczeństwa specyficzne dla wyników.

W przypadku wrażliwych przepływów pracy celem musi być konsekwentna poprawność. Sama stabilność nigdy nie powinna zastępować dokładności faktograficznej, zgodności z polityką, kontroli uprawnień ani nadzoru człowieka.

Większe modele mają teraz konkurenta na poziomie systemowym

Nowe dowody podważają założenie, że problemy z niezawodnością należy rozwiązywać przede wszystkim przez wymianę modelu bazowego.

Ulepszenia modeli pozostają atrakcyjne, ponieważ mogą poprawić wiele zadań naraz. Wymagają też mniej niestandardowej diagnostyki niż przebudowa pamięci agenta lub systemu oceny.

Większy model nie ujawnia jednak, gdzie istniejący agent staje się niestabilny. Może podnieść średnią wydajność, pozostawiając znaczącą lukę między okazjonalnym a powtarzalnym sukcesem.

Podejście IBM stanowi konkurencyjną drogę. Zamiast zmieniać model, zmienia informacje dostarczane w punktach decyzyjnych wysokiego ryzyka.

Porównanie nie sprowadza się ściśle do modelu kontra pamięci. Silne systemy będą łączyć zdolne modele, dobrze zaprojektowane narzędzia, ukierunkowany kontekst, deterministyczne kontrole i powtarzane oceny.

Presja spada na dostawców agentów i nabywców korporacyjnych, którzy nadal raportują pojedynczy wskaźnik sukcesu. Gdy Pass^k wejdzie do rozmów zakupowych, wysoka średnia stanie się tylko częścią dowodów.

Nabywcy mogą pytać, czy to samo zadanie było powtarzane, czy środowisko resetowano i czy każde uruchomienie osiągnęło akceptowalny wynik. Mogą też żądać wyników według poziomu trudności zamiast jednej wartości zbiorczej.

Deweloperzy stoją przed pokrewną zmianą. Zgłoszenie błędu stwierdzające, że agent zawiódł raz, może już nie dać się odtworzyć na żądanie. Zespoły potrzebują pełnych śladów wykonania, aby zlokalizować wcześniejszą decyzję, w której nastąpiło rozbieżenie.

Obserwowalność staje się częścią jakości produktu. Bez zapisanych promptów, argumentów narzędzi, wyników i pośrednich wyborów niestabilne uruchomienie może zniknąć bez wyjaśnienia.

To sprawia, że architektura oceny jest ważna przed wdrożeniem. Zespoły potrzebują reprezentatywnych zadań, kontrolowanych stanów początkowych, jawnych kryteriów sukcesu i wystarczającej liczby powtórzeń, aby ujawnić wariancję.

Muszą też oddzielić pracę, którą można ponowić, od działań jednorazowych. Wygenerowanie szkicu może tolerować wiele prób. Wysłanie płatności, usunięcie pliku lub zatwierdzenie umowy wymaga ściślejszych kontroli.

Pass@k pasuje do pierwszej grupy, gdy wyniki można automatycznie zweryfikować. Pass^k jest bardziej informacyjny dla drugiej grupy, szczególnie gdy użytkownicy oczekują, że pierwszy wynik będzie bezpieczny.

Niektóre przepływy pracy nie powinny polegać wyłącznie na żadnej z tych metryk. Agent transakcyjny potrzebuje także granic uprawnień, kontroli idempotencji, dzienników audytowych i deterministycznej walidacji przed wykonaniem nieodwracalnego działania.

Wytyczne mogą ograniczać niepewne rozumowanie, ale nie zastępują tych zabezpieczeń. Niezawodny agent jest właściwością systemu, a nie wynikiem modelu.

Wyniki wzmacniają także argument za kuratorowanym kontekstem roboczym. Zespoły już wykorzystują knowledge blending, aby łączyć zapisane dowody z aktywną pracą. Wytyczne dla agentów stosują podobną ideę do lekcji dotyczących zachowania.

Kluczowa jest powściągliwość. Większa ilość pobranego kontekstu może powodować rozproszenie, sprzeczności i dodatkowe opóźnienia. Ukierunkowana instrukcja ma wartość tylko wtedy, gdy trafia do właściwego zadania i nie wypiera kluczowych dowodów.

W tym tkwi długoterminowe wyzwanie ALTK-Evolve. Jego diagnostyka może identyfikować zmienne decyzje, lecz otaczający system musi zarządzać rosnącą kolekcją lekcji.

Udane wdrożenie będzie wymagało polityk wygasania, wykrywania konfliktów, informacji o pochodzeniu oraz ocen zmian wytycznych. W przeciwnym razie wczorajsza poprawka może stać się jutrzejszym ukrytym źródłem awarii.

Co pokaże, czy podejście IBM się sprawdzi

Trzy sygnały zdecydują, czy wytyczne dotyczące spójności staną się standardową warstwą agentów, czy pozostaną obiecującą techniką benchmarkową.

Pierwszym sygnałem będzie niezależne odtworzenie wyników w innych benchmarkach i architekturach agentów. Badacze powinni testować metodę na agentach przeglądarkowych, agentach programistycznych, systemach obsługi klienta oraz przepływach pracy z rzeczywistymi awariami API.

Powtórzenie 16-punktowej poprawy Pass^5 wzmocniłoby centralne twierdzenie IBM. Mniejsze lub niespójne zyski sugerowałyby, że AppWorld zawiera wzorce awarii szczególnie podatne na naprawę za pomocą wytycznych.

Porównania powinny obejmować kilka modeli bazowych. Powinny też raportować zużycie tokenów, opóźnienia, koszt analizatora, narzut wyszukiwania oraz liczbę wytycznych wstrzykiwanych na zadanie.

Drugim sygnałem będzie wydajność w dłuższych okresach. Użyteczny system uczenia się musi obsługiwać nowe wskazówki bez gromadzenia sprzecznych lub przestarzałych reguł.

Zespoły powinny mierzyć, czy korzyść utrzymuje się po setkach lub tysiącach trajektorii. Powinny też testować, czy wyszukiwanie wytycznych pozostaje precyzyjne wraz z rozrostem repozytorium.

Warto obserwować oceny, które zamrażają jeden zestaw wytycznych i testują go wobec późniejszych wersji aplikacji. Silna wydajność pokazałaby, że reguły opisują trwałe zachowania. Szybki spadek ujawniłby obciążenie związane z utrzymaniem.

Trzecim sygnałem będzie przyjęcie raportowania wielokrotnych uruchomień. Karty wyników dostawców powinny publikować Mean@k i Pass^k razem, z wyraźnie określonym k.

Taka zmiana pozwoliłaby nabywcom odróżniać modele, które często odnoszą sukces, od systemów, które odnoszą sukces niezawodnie. Zniechęciłaby też do demonstracji opartych na jednym korzystnym wykonaniu.

Branża powinna pójść dalej, łącząc powtórzenia z parafrazami i kontrolowanymi awariami narzędzi. Identyczne prompty reprezentują tylko jeden rodzaj presji produkcyjnej.

Praca IBM przekonująco pokazuje, że jedno udane uruchomienie jest zbyt słabym standardem. Oferuje także praktyczną metodę lokalizowania niepewności bez powtarzania każdego działania w świecie rzeczywistym.

Pozostaje pytanie, czy te zyski utrzymają się poza środowiskiem badawczym. Deweloperzy mogą na nie odpowiedzieć, ponownie uruchamiając własne ważne przepływy pracy, zachowując pełne ślady wykonania i mierząc sukces we wszystkich uruchomieniach.

Jeśli Twój agent obsługuje pracę o istotnych konsekwencjach, nie pytaj tylko, czy wykonał zadanie. Pytaj, jak często poprawnie wykonuje to samo zadanie, które decyzje się zmieniają oraz co dzieje się, gdy wczorajsze wytyczne spotykają jutrzejsze warunki.