OpenAI twierdzi, że dwa ustawienia API potroiły wynik GPT-5.6 Sol w ARC-AGI-3

OpenAI zmieniło dwa ustawienia API i niemal potroiło publiczny wynik GPT-5.6 Sol w ARC-AGI-3 — z 13,3% do 38,3%. Opis OpenAI koncentruje się na zachowanym rozumowaniu i kompakcji, czyli dwóch wyborach dotyczących zarządzania kontekstem dostępnych w Responses API. Według OpenAI łącznie zmniejszyły one również liczbę tokenów wyjściowych sześciokrotnie.

Wynik ten komplikuje zwyczajową interpretację benchmarku AI. Testowany model nie otrzymał nowego treningu, większego budżetu rozumowania ani narzędzia przeznaczonego do konkretnej gry. Zamiast tego OpenAI zmieniło harness, czyli warstwę oprogramowania przekazującą między modelem a benchmarkiem obserwacje, działania i historię rozmowy.

Główny konflikt nie dotyczy więc GPT-5.6 Sol w porównaniu z innym modelem. Chodzi o uniwersalny, ustandaryzowany harness kontra harness produkcyjny świadomy specyfiki modelu. Pierwszy sprzyja porównywalności i udostępnia agentom ten sam podstawowy interfejs. Drugi zachowuje stan, którego — jak twierdzi OpenAI — jego modele rozumujące potrzebują do długiej, interaktywnej pracy.

To rozróżnienie ma znaczenie, ponieważ ARC-AGI-3 nie wymaga udzielenia jednej końcowej odpowiedzi. Prezentuje nieznane gry bez instrukcji w języku naturalnym. Agenci muszą wywnioskować reguły każdej gry, odkryć jej cel, testować hipotezy, pamiętać porażki i dostosowywać się w toku wielu działań.

System, który zapomina swoje rozumowanie po każdym ruchu, stoi przed innym zadaniem niż system zdolny zachować ewoluujący plan. Podobnie agent, który traci najstarsze obserwacje po zapełnieniu kontekstu, nie doświadcza tej samej gry co agent otrzymujący zwięzłe podsumowanie.

Wynik OpenAI nie rozstrzyga, który harness zapewnia najuczciwszy ranking. Pokazuje jednak, że projekt harnessu może zmienić mierzone możliwości bardziej niż wiele aktualizacji modeli. Wywiera to presję na operatorów benchmarków, twórców modeli i zespoły oceny w przedsiębiorstwach, aby dokumentowali cały testowany system.

Jak OpenAI osiągnęło skok wyniku

Model pozostał ten sam, ale zmieniła się ścieżka jego pamięci.

OpenAI opublikowało analizę 29 lipca 2026 roku po zbadaniu zaskakująco słabych wyników GPT-5.6 Sol. Początkowa obawa była prosta. Model, który radził sobie z trudną matematyką i długimi sesjami gier, wydawał się nieskuteczny w pozornie prostych środowiskach dwuwymiarowych.

Pierwotna rozbieżność obejmowała kilka wartości wyniku. OpenAI zauważyło, że GPT-5.6 Sol uzyskał ogólny wynik ARC-AGI-3 na poziomie 7,8%, podczas gdy GPT-5.5 osiągnął 0,4%. W publicznym zestawie zadań użytym do kontrolowanego porównania GPT-5.6 Sol uzyskał 13,3% z oficjalnym harnessem.

Następnie OpenAI przebudowało ewaluację za pomocą Responses API. Zmieniony harness zachowywał rozumowanie między działaniami i zastępował kroczące obcinanie kompakcją. Według analizy benchmarku firmy taka konfiguracja zwiększyła wynik na publicznym zestawie do 38,3%.

Wynik korzysta z miary Relative Human Action Efficiency, czyli RHAE. Metryka porównuje skuteczny postęp z liczbą działań potrzebnych ludziom. Agent otrzymuje mniej punktów, gdy rozwiązuje zadanie nieefektywnie, więc ślepa eksploracja i powtarzane błędy wiążą się z wymiernym kosztem.

OpenAI oszacowało, że przeciętny ludzki tester uzyskał 48% według tej samej metody. Szacunek oparto na oficjalnych logach rozgrywek, a nie na twierdzeniu, że każdy człowiek osiąga 48%. ARC Prize oddzielnie opisuje 100% jako wynik za pokonanie każdej gry równie efektywnie jak ludzka wartość bazowa.

Wynik 38,3% nie zlikwidował zatem luki wobec ludzi. Znacząco zbliżył jednak GPT-5.6 Sol do szacowanego przez OpenAI przeciętnego testera. Co ważniejsze, stało się to bez aktualizacji modelu.

Wniosek dotyczący tokenów wyjściowych wnosi kolejne odwrócenie intuicji. Dłuższa pamięć może wydawać się droższa, ponieważ agent przenosi więcej kontekstu. OpenAI informuje jednak, że zmieniona konfiguracja wykorzystywała sześciokrotnie mniej tokenów wyjściowych. Model generował mniej wyjścia na wielokrotne odtwarzanie reguł i planów, które już wcześniej opracował.

Powtórka rozgrywki oferuje konkretny przykład. OpenAI pokazało środowisko, w którym żaden model z czołówki odpowiedniego rankingu nie ukończył więcej niż pierwszego poziomu. Zmieniony harness Responses API miał podobno umożliwić GPT-5.6 Sol ukończenie wszystkich sześciu poziomów.

Zweryfikowane wyniki ARC Prize dostarczają użytecznego kontekstu. Jego karta wyników GPT-5.6 wymienia Sol z maksymalnym poziomem rozumowania i półprywatnym wynikiem ARC-AGI-3 na poziomie 7,78%. Odnotowuje także wynik 87% w publicznej grze FT09 — pierwszej publicznej grze ARC-AGI-3 wygranej przez model.

Liczby te opisują różne zestawy i perspektywy ewaluacji, dlatego czytelnicy nie powinni łączyć ich w jedną wartość wydajności. Kontrolowane porównanie od 13,3% do 38,3% stanowi istotny dowód dla twierdzenia OpenAI dotyczącego dwóch ustawień.

To rozróżnienie łatwo przeoczyć w relacjach o benchmarkach. Eksperyment na zestawie publicznym, zweryfikowany półprywatny wynik i rezultat w jednej grze odpowiadają na różne pytania. Eksperyment OpenAI pyta konkretnie, jak jeden model zachowuje się, gdy harness zachowuje większą część jego stanu roboczego.

Odpowiedź jest uderzająca, ale ograniczona. Zachowane rozumowanie i kompakcja poprawiły wyniki tego modelu w tym publicznym zestawie zadań, przy implementacji OpenAI. Rezultat nie dowodzi identycznej poprawy dla każdego modelu, agenta, długości kontekstu ani produkcyjnego obciążenia roboczego.

Oficjalny harness testował również zapominanie

ARC-AGI-3 mierzył agenta oraz otaczającą go architekturę informacji.

ARC-AGI-3 różni się od statycznych benchmarków, w których model otrzymuje pytanie i zwraca jedną odpowiedź. Składa się z interaktywnych środowisk wymagających powtarzanej percepcji, planowania, działania i korekty. Jego przegląd benchmarku podkreśla przyswajanie celów, adaptowalne modele świata, planowanie długoterminowe i uczenie się oparte na doświadczeniu.

Benchmark nie zawiera instrukcji w języku naturalnym wyjaśniających każdą grę. Agent otrzymuje reprezentację bieżącej klatki i zestaw możliwych działań. Musi określić, które obiekty są istotne, jak działania zmieniają środowisko i co stanowi postęp.

Taka konfiguracja sprawia, że pamięć staje się częścią ocenianej zdolności. Użyteczna hipoteza może pojawić się po kilku nieudanych działaniach. Późniejsza obserwacja może ją potwierdzić lub odrzucić. Jeśli harness usuwa rozumowanie łączące te zdarzenia, agent musi odtworzyć swoją interpretację z uboższego zapisu.

OpenAI stwierdziło, że oficjalny harness odrzucał prywatne rozumowanie po każdym działaniu w grze. Model nadal widział wcześniejsze ruchy i krótkie notatki. Nie miał jednak dostępu do planów, odkryć ani założeń, które doprowadziły do tych ruchów.

Harness stosował także kroczące obcinanie. Gdy rozmowa przekraczała 175 000 znaków, usuwał najstarsze wiadomości. Długie przebiegi mogły więc kasować wczesne obserwacje i działania, nawet jeśli zdarzenia te pozostawały istotne dla bieżącego poziomu.

Zachowania te były zamierzonymi konsekwencjami uniwersalnego projektu, a nie dowodem wadliwości benchmarku. ARC Prize preferuje stosunkowo prosty harness, ponieważ ujawnia on ograniczenia modeli i wspiera porównania między dostawcami. Wdrożenia komercyjne często wykorzystują funkcje specyficzne dla dostawcy, które nie przekładają się bezpośrednio między API.

To tworzy główną oś sporu w artykule: ustandaryzowana ewaluacja kontra ewaluacja zgodna z warunkami produkcyjnymi.

Ustandaryzowany harness pyta, który model działa najlepiej przez wspólny interfejs. Podejście to ogranicza specjalne traktowanie i zmniejsza ryzyko, że prywatna optymalizacja jednego dostawcy zdominuje porównanie.

Harness zgodny z warunkami produkcyjnymi pyta, jak dobrze model działa, gdy jest wdrażany zgodnie z zaleceniami jego twórcy. Takie podejście przypomina rzeczywiste aplikacje, ale może zacierać granicę między możliwościami modelu a inżynierią systemu.

Żadne z tych pytań nie jest pozbawione sensu. Po prostu prowadzą do różnych pomiarów.

Problem pojawia się, gdy wynik z rankingu przedstawia się jako właściwość samego modelu. Jeśli jeden harness wielokrotnie usuwa stan, który inny model oczekuje zachować, test mierzy również zgodność między treningiem modelu a infrastrukturą ewaluacyjną.

ARC Prize przyznało, jak trudne pozostają te środowiska. Jego raport techniczny stwierdza, że ludzie rozwiązali 100% testowanych środowisk, podczas gdy systemy z czołówki uzyskały mniej niż 1% według stanu na marzec 2026 roku. Benchmark zaprojektowano tak, aby ujawniał dużą lukę w adaptacyjnej efektywności.

Późniejsze wyniki GPT-5.6 Sol pokazują postęp, zwłaszcza w pojedynczych publicznych grach. Wynik 38,3% na zestawie publicznym nadal pozostawia jednak znaczną przestrzeń do osiągnięcia efektywności na poziomie człowieka. Pochodzi też z własnego harnessu i analizy twórcy modelu.

Wniosek nie jest taki, że ARC-AGI-3 stał się łatwy. Chodzi o to, że interaktywny benchmark może przypadkowo testować sztuczną amnezję obok planowania i eksploracji.

Problem wykracza poza gry. Agenci programistyczni muszą pamiętać decyzje architektoniczne między wywołaniami narzędzi. Agenci badawczy muszą zachowywać informacje o tym, które źródła potwierdzają lub podważają dane twierdzenie. Systemy obsługi klienta muszą zachowywać ograniczenia wprowadzone na wczesnym etapie rozmowy.

Zespół w przedsiębiorstwie, który ocenia takie systemy przez wielokrotne odrzucanie ich wewnętrznego stanu, może zaniżać ocenę ich użytecznej wydajności. Zespół dopuszczający nieograniczoną, specyficzną dla dostawcy optymalizację może uzyskać wyniki trudne do porównania lub odtworzenia.

Lepszą odpowiedzią jest pełniejsze ujawnianie informacji. Raport benchmarkowy powinien wskazywać wersję modelu, wysiłek rozumowania, politykę kontekstu, zachowane elementy odpowiedzi, zachowanie kompakcji, prompt, narzędzia, budżet działań i metodę punktacji. Bez tych informacji wynikowi brakuje istotnego kontekstu operacyjnego.

Zachowane rozumowanie powstrzymuje agenta przed zaczynaniem od nowa

Zachowanie rozumowania zapewniło GPT-5.6 Sol ciągłość między działaniami, ograniczając potrzebę powtarzanej pracy interpretacyjnej.

Modele rozumujące generują wewnętrzne elementy rozumowania, zanim utworzą widoczny tekst lub wywołania narzędzi. Elementy te nie są tym samym co wyjaśnienie skierowane do użytkownika. Stanowią część stanu roboczego modelu podczas wieloetapowej interakcji.

W oficjalnym harnesie badanym przez OpenAI każde działanie w grze skutecznie kończyło ten stan. Kolejne żądanie zawierało poprzednie ruchy i krótkie notatki, ale odrzucało rozumowanie, które je łączyło. GPT-5.6 Sol wielokrotnie stawał przed tym samym obciążeniem interpretacyjnym.

Wyobraźmy sobie agenta badającego siatkę z kolorowymi obiektami. Sprawdza, czy jeden kolor oznacza przeszkody, a następnie odkrywa, że ten sam kolor zmienia się po udanym ruchu. Obserwacja ta może obalić pierwszą teorię i ustanowić nową regułę.

Dziennik ruchów zapisuje, co agent kliknął. Niekoniecznie zachowuje jednak, dlaczego agent kliknął, jakie alternatywy odrzucił ani co wynikało z otrzymanej klatki. Te szczegóły mogą decydować o tym, czy kolejne działanie rozwija strategię, czy powtarza wcześniejszy błąd.

OpenAI użyło Responses API i przekazywało identyfikator poprzedniej odpowiedzi między turami. Jego aktualne wskazówki dotyczące modelu wyjaśniają, że GPT-5.6 może ponownie wykorzystywać dostępne elementy rozumowania między turami. Deweloperzy mogą również kontrolować, jaka część wcześniejszego rozumowania pozostaje istotna, za pomocą ustawień kontekstu rozumowania.

Według OpenAI zachowane rozumowanie zmieniło zachowanie GPT-5.6 Sol na dwa sposoby. Model spędzał mniej czasu na rozumowaniu przed każdym działaniem i stosował bardziej spójne strategie podczas dłuższych przebiegów. Nie musiał już od początku interpretować gry po każdym ruchu.

To wyjaśnia, jak wykorzystanie tokenów mogło spaść, podczas gdy zachowany stan się powiększał. Tokeny wyjściowe obejmują nowo generowane przez model rozumowanie i odpowiedzi. Jeśli wcześniejsze ustalenia pozostają dostępne, model może uniknąć tworzenia kolejnej długiej rekonstrukcji.

To rozróżnienie przypomina różnicę między zespołem projektowym, który zachowuje rejestry decyzji, a zespołem otrzymującym jedynie listę ukończonych zadań. Lista zadań pokazuje, co się wydarzyło. Nie zachowuje odrzuconych opcji, ograniczeń ani dowodów, które ukształtowały obecny plan.

W przypadku pracowników wiedzy ten sam problem pojawia się, gdy asystent AI prowadzi długie badanie. Każdy pobrany dokument zmienia roboczą hipotezę. Jeśli system zachowuje wyłącznie linki i krótkie odpowiedzi, późniejsze wnioski mogą utracić rozumowanie, które wyjaśniało znaczenie tych źródeł.

W tym miejscu zewnętrzna przeszukiwalna baza wiedzy może uzupełniać kontekst modelu. Trwałe zapisy źródeł powinny pozostać możliwe do przeanalizowania nawet wtedy, gdy agent kompresuje swój tymczasowy stan roboczy.

Zachowywanie rozumowania nadal wiąże się z kompromisami. Stare rozumowanie może się zdezaktualizować po zmianie zadania. Błędna wczesna hipoteza może wpływać na późniejsze kroki, jeśli system nigdy nie oznaczy jej jako odrzuconej. Więcej pamięci nie oznacza automatycznie lepszej pamięci.

Wskazówki OpenAI dotyczące API odzwierciedlają ten problem. Pozwalają programistom zachowywać rozumowanie we wszystkich turach, gdy cele pozostają stabilne, albo skupiać się na bieżącej turze, gdy wcześniejsze rozumowanie straciło znaczenie. Ten wybór powinien wynikać z charakteru procesu, a nie z uniwersalnej reguły.

Gry ARC-AGI-3 zapewniają sprzyjające warunki dla ciągłości. Cel i środowisko pozostają powiązane między kolejnymi działaniami, więc wcześniejsze hipotezy zwykle mają znaczenie. Rozmowa z pomocą techniczną, która nagle zmienia temat, stwarza inny problem zarządzania kontekstem.

Na implementację wpływają również polityki bezpieczeństwa i prywatności. Niektóre organizacje nie mogą przechowywać historii odpowiedzi bezterminowo. Inne korzystają z konfiguracji bezstanowych lub z zerową retencją danych. Zespoły te muszą starannie zarządzać zaszyfrowanymi elementami rozumowania i innymi obiektami odpowiedzi potrzebnymi do kontynuacji.

Zachowywanie rozumowania opisuje więc zachowanie systemu, a nie zgodę na ujawnianie prywatnej zawartości łańcucha myśli. Aplikacje powinny zachowywać obsługiwane elementy odpowiedzi za pośrednictwem API, jednocześnie prezentując użytkownikom zwięzłe i odpowiednie wyjaśnienia.

Eksperyment OpenAI sugeruje również praktyczne pytanie ewaluacyjne. Jeśli agent zawodzi po trzydziestu krokach, recenzenci powinni sprawdzić, czy jego plan był błędny, czy też środowisko testowe usunęło stan potrzebny do kontynuowania tego planu.

Te tryby awarii wymagają różnych rozwiązań. Awaria rozumowania wymaga lepszego modelu, promptu lub strategii. Awaria zarządzania stanem wymaga innej infrastruktury. Traktowanie obu jako kwestii inteligencji modelu zaciera miejsce, w którym powinien trafić wysiłek inżynieryjny.

Kompresja zachowuje przeszłość bez przenoszenia wszystkiego

Kompresja zastąpiła bezrefleksyjne usuwanie krótszą reprezentacją historii, która nadal zachowywała to, co istotne.

Każdy długo działający agent w końcu napotyka limit kontekstu albo ograniczenie ekonomiczne. Zachowywanie każdej obserwacji, wyniku narzędzia i pośredniej myśli może sprawić, że późniejsze żądania będą wolniejsze i mniej skoncentrowane. Samo zachowywanie rozumowania nie rozwiązuje problemu nieograniczonego wzrostu kontekstu.

Oficjalny harness ARC-AGI-3 obsługiwał wzrost za pomocą kroczącego obcinania. Gdy historia przekraczała próg, usuwał najstarszą zawartość. Ta polityka jest przewidywalna i niezależna od dostawcy, lecz zakłada, że stare informacje są mniej istotne tylko dlatego, że są stare.

Interaktywne gry podważają to założenie. Wczesne działanie może ujawnić cel. Wskazówka zauważona na początku może wyjaśnić symbol napotkany znacznie później. Usuwanie chronologiczne może wymazać podstawową wiedzę, jednocześnie zachowując niedawne, lecz powtarzalne klatki.

Kompresja wykorzystuje inną politykę. Kondensuje wcześniejszy kontekst do mniejszej reprezentacji, która zachowuje istotny stan. Agent może kontynuować pracę z kontekstem o rozsądnej wielkości bez przenoszenia każdego pierwotnego tokenu.

OpenAI twierdzi, że jego implementacja ARC używała limitu 175 000 tokenów dla kompresji. Oficjalny harness używał 175 000 znaków dla obcinania. OpenAI argumentuje, że progi te były zasadniczo porównywalne, ponieważ siatki działań były tokenizowane w przybliżeniu jako jeden znak na token.

Ten szczegół implementacyjny ma znaczenie. Gdyby limity znacznie się różniły, poprawa wyniku mogłaby odzwierciedlać większy efektywny kontekst, a nie lepszą strategię pamięci. Porównanie OpenAI próbuje utrzymać zbliżony próg, jednocześnie zmieniając sposób przetrwania starszych informacji.

Dokumentacja OpenAI dotycząca kompresji opisuje ją jako sposób zmniejszania rozmiaru kontekstu podczas długich procesów Responses API. Powstały skompaktowany stan może wspierać kontynuację bez konieczności ponownego wysyłania przez aplikacje nieograniczonego transkryptu.

Kompresja nie jest bezstratnym przechowywaniem danych. Podsumowanie może pominąć szczegóły, spłaszczyć niepewność albo zachować błędną interpretację. Jej wartość zależy od wyboru informacji, których będą wymagać przyszłe działania.

ARC-AGI-3 stanowi wymagający test tego wyboru. Agent musi zachować odkryte reguły, cele, znaczenie obiektów, nieudane hipotezy, postęp poziomu i planowane działania. Powtarzające się siatki oraz redundantne rozumowanie mogą otrzymać mniej uwagi.

OpenAI informuje, że skompaktowany harness zachowywał wiedzę między dłuższymi przebiegami i generował mniej tokenów wyjściowych. Animacja porównawcza firmy pokazała, że zmodyfikowany agent mniej rozumował na działanie i szybciej przechodził przez gry.

Sześciokrotne zmniejszenie liczby tokenów wyjściowych ma znaczenie operacyjne nawet bez omawiania cen. Mniejsza liczba tokenów wyjściowych może redukować opóźnienia i uwalniać zasoby dla większej liczby ewaluacji. Może również ułatwić analizę śladów działania agenta, pod warunkiem że skompaktowany stan pozostaje wystarczająco informacyjny.

Czytelnicy powinni jednak traktować tę wartość jako specyficzną dla danego obciążenia. ARC-AGI-3 generuje powtarzalne tekstowe siatki i wiele sekwencyjnych działań. Przegląd prawny, proces medyczny lub analiza finansowa mogą zawierać szczegóły opierające się agresywnemu streszczaniu.

Zespoły ewaluacyjne powinny testować jakość kompresji niezależnie od ostatecznego sukcesu zadania. Mogą porównywać zachowane ograniczenia, spójność faktograficzną, odzyskiwanie sprawności po przerwaniach oraz zdolność agenta do wyjaśnienia, które dowody wpłynęły na decyzję.

Przydatny test wprowadza krytyczny fakt na początku, wypełnia kontekst późniejszą aktywnością, a następnie sprawdza, czy agent prawidłowo stosuje ten fakt. Inny test zmienia wymaganie w połowie procesu i weryfikuje, czy kompresja zachowuje poprawkę zamiast pierwotnej instrukcji.

Testy te ujawniają kluczowy kompromis. Kroczące obcinanie oferuje przejrzystą utratę informacji, ponieważ recenzenci dokładnie wiedzą, które wiadomości zniknęły. Kompresja oferuje selektywną ciągłość, ale jej pominięcia mogą być trudniejsze do wykrycia.

W przypadku agentów produkcyjnych selektywna ciągłość często lepiej odpowiada zadaniu. Ludzie nie pamiętają każdej klatki obrazu ani każdego zdania. Utrzymują model roboczy, który priorytetyzuje cele, ograniczenia, odkrycia i nierozstrzygnięte pytania.

Ta analogia nie powinna usprawiedliwiać ukrytych awarii. Programiści potrzebują śladów, narzędzi do odtwarzania przebiegów i kontrolowanych ewaluacji, aby sprawdzić, czy kompresja zachowała właściwy stan. W przeciwnym razie pewna siebie końcowa odpowiedź może ukrywać brakujący wczesny warunek.

Wynik OpenAI dotyczy więc mniej powiększania okna kontekstu. Chodzi raczej o zmianę tego, co przetrwa, gdy okno nie może pomieścić wszystkiego.

Czego potrojony wynik nie dowodzi

Eksperyment prowadzony przez dewelopera na publicznym zestawie nie może określić najbardziej sprawiedliwej uniwersalnej konfiguracji benchmarku.

Dowody OpenAI wspierają wąski, ale wartościowy wniosek. GPT-5.6 Sol osiągał lepsze wyniki w implementacji ARC-AGI-3 OpenAI, gdy zachowywano rozumowanie, a kroczące obcinanie zastąpiono kompresją.

Nie dowodzi to, że oficjalny harness jest nieważny. Oficjalna konfiguracja służy innemu celowi: ujawnianiu zachowania modeli przez ogólny interfejs, który uczestnicy benchmarku mogą odtworzyć u różnych dostawców.

Funkcje specyficzne dla dostawcy komplikują równe porównania. OpenAI może zachowywać swoje natywne elementy rozumowania przez Responses API. Inny dostawca może inaczej reprezentować stan wewnętrzny, udostępniać inne mechanizmy kontynuacji albo opierać się na innej architekturze pamięci.

Zezwolenie każdej firmie na optymalizację prywatnego harnessu może przekształcić benchmark modeli w rywalizację systemów. Taki format nadal może mierzyć coś użytecznego, zwłaszcza dla nabywców wybierających kompletne systemy agentowe. Nie izoluje już jednak zachowania modelu równie czysto.

Wynik pochodzi również z eksperymentu OpenAI na publicznym zestawie zadań. Publiczne gry są dostępne do analizy i prac rozwojowych, co stwarza więcej możliwości dostrajania harnessu. Wyniki półprywatne zapewniają silniejszą kontrolę przed bezpośrednim dostosowaniem do konkretnych zadań.

Zweryfikowany ranking ARC Prize nadal umieszcza GPT-5.6 Sol na poziomie 7,78% w zestawie półprywatnym przy maksymalnym poziomie rozumowania. Wynik ten wyprzedza inne wymienione tam warianty rodziny GPT-5.6, ale nadal pozostaje daleko od ludzkiej skuteczności i efektywności.

Różnica między 38,3% w publicznym porównaniu OpenAI a 7,78% w zweryfikowanej półprywatnej ewaluacji wymaga ostrożnej interpretacji. Nie zaprzecza automatycznie ustaleniom dotyczącym harnessu, ponieważ zestawy zadań się różnią. Pokazuje jednak, dlaczego pojedyncza poprawa w zestawie publicznym nie powinna stawać się ogólnym twierdzeniem o uczeniu się gier na poziomie człowieka.

Szacunek OpenAI wynoszący 48% dla przeciętnego ludzkiego testera dodaje kontekst, ale nie ustanawia równoważności. Ludzie i modele mogą zawodzić w odmienny sposób, używać różnych wzorców działań i inaczej reagować na nieznane interfejsy. RHAE kompresuje te zachowania do wyniku.

Eksperyment łączy również dwie zmiany. W porównaniu przedstawianym jako główne aktywne były zarówno zachowywanie rozumowania, jak i kompresja. OpenAI opisuje efekt behawioralny każdego z nich, lecz opublikowane główne wartości nie izolują w pełni wkładu każdego ustawienia.

Pełniejsza analiza ablacjowa raportowałaby cztery konfiguracje: żadnego ustawienia, samo zachowywanie rozumowania, samą kompresję oraz oba ustawienia razem. Powtórzone przebiegi pomogłyby określić wariancję, szczególnie gdy eksploracja agenta może przebiegać różnymi ścieżkami.

Porównanie tokenów wyjściowych zasługuje na taką samą analizę. Mniejsza liczba tokenów wskazuje na lepszą efektywność w ramach tego harnessu. Nie ujawnia całkowitego opóźnienia, przetwarzania tokenów wejściowych, narzutu kompresji ani prac inżynieryjnych potrzebnych do utrzymania stanu.

Operatorzy benchmarków stoją dziś pod presją z obu stron. Jeśli utrzymują ogólne harnessy, powinni wyjaśniać, że wyniki w rankingach mogą zaniżać możliwości konfiguracji produkcyjnych. Jeśli dopuszczają zoptymalizowane harnessy, powinni ujawniać, które możliwości pochodziły z modelu, a które z otaczającego kodu.

Dostawcy modeli mają równoległą odpowiedzialność. Powinni publikować odtwarzalne konfiguracje, prompty, progi kontekstu, budżety działań i karty wyników. Twierdzenie o ustawieniach staje się bardziej użyteczne, gdy niezależne zespoły mogą je powtórzyć.

Nabywcy korporacyjni nie powinni wybierać między testami ogólnymi a zoptymalizowanymi. Potrzebują obu.

Test ogólny pokazuje, jak modele kandydackie zachowują się przy typowych ograniczeniach. Test reprezentatywny dla środowiska produkcyjnego pokazuje, czy kompletny system odnosi sukces w rzeczywistym procesie nabywcy. Różnica między tymi wynikami mierzy wrażliwość na integrację.

Ta wrażliwość sama w sobie stanowi ryzyko biznesowe. Model, który działa dobrze wyłącznie dzięki jednemu wyspecjalizowanemu stosowi zarządzania stanem, może być trudniejszy do migracji. Ogólny harness, który usuwa kluczowe możliwości, może skłonić zespoły do wyboru słabszego modelu z niewłaściwego powodu.

Istotne pytanie nie brzmi, czy benchmark czy OpenAI ma rację. Chodzi o to, jaką granicę systemu opisuje każdy wynik.

Trzy sygnały, które warto obserwować po wyniku OpenAI w ARC-AGI-3

Niezależna replikacja, testy półprywatne i lepsze raportowanie harnessów zdecydują o tym, czy wynik zmieni praktykę ewaluacji.

Pierwszym sygnałem jest niezależne odtworzenie wzrostu o 13,3% do 38,3%. Wiarygodna replikacja powinna wykorzystywać te same publiczne gry, poziom nakładu rozumowania, limity działań, progi kontekstu oraz metodę punktacji. Powinna też raportować zmienność między uruchomieniami.

Replikacja wzmocniłaby twierdzenie OpenAI, że obsługa stanu wyjaśnia znaczną część zaobserwowanej różnicy w wydajności. Wyraźnie mniejszy wzrost sugerowałby, że większy wpływ niż dwa wskazane ustawienia miały nieudokumentowane szczegóły implementacji, prompty lub wybory ewaluatora.

Drugim sygnałem jest półprywatna ewaluacja wykorzystująca zachowane rozumowanie i kompakcję. Publiczne zadania pomagają deweloperom diagnozować zachowanie, lecz niewidoczne lub ograniczone środowiska stanowią mocniejszy test uogólniania. Podobne wzrosty w takich warunkach pokazałyby, że usprawnienie infrastruktury testowej przenosi się poza znane publiczne gry.

Niewielki wzrost w półprywatnej ewaluacji osłabiłby szeroką interpretację. Mógłby wskazywać, że lepsza pamięć pomaga modelowi realizować znane strategie, nie rozwiązując głębszego problemu zdobywania nowych celów i reguł.

Trzecim sygnałem jest zmiana standardów ujawniania informacji o benchmarkach. Przyszłe rankingi powinny publikować zasady zarządzania kontekstem obok wyników. Raporty powinny określać, czy elementy rozumowania przetrwały między działaniami, w jaki sposób usuwano lub kompresowano starszą historię oraz które funkcje specyficzne dla dostawcy były włączone.

Takie raportowanie pozwoliłoby czytelnikom porównać dwa użyteczne ujęcia. Jedno mierzy modele za pośrednictwem ustandaryzowanego interfejsu. Drugie mierzy kompletne systemy skonfigurowane zgodnie z wytycznymi dostawcy.

Deweloperzy powinni stosować tę samą dyscyplinę we własnych ewaluacjach. Zachowajcie punkt odniesienia przed zmianą ustawień. Następnie osobno testujcie zachowane rozumowanie, kompakcję i ich połączenie na reprezentatywnych obciążeniach.

Mierzcie więcej niż końcowy sukces. Śledźcie tokeny wyjściowe, wzrost danych wejściowych, opóźnienia, powtarzane działania, zachowanie ograniczeń, odzyskiwanie po błędnych hipotezach oraz błędy wywołane przez nieaktualną pamięć. Wyższy wynik może ukrywać nowe tryby awarii, jeśli ewaluacja obserwuje wyłącznie punkt końcowy.

Zespoły powinny też sprawdzać, gdzie ciągłość pomaga. Długie zadania programistyczne, interaktywne badania, agenci przeglądarkowi i wieloetapowa analiza często zależą od zgromadzonych odkryć. Krótkie żądania klasyfikacji lub ekstrakcji mogą niewiele zyskać na trwałym rozumowaniu.

Ustalenie OpenAI stanowi wyraźne ostrzeżenie: ewaluacja agenta może karać model za polityki pamięci narzucone przez ewaluatora. Może też przedstawiać model w zbyt korzystnym świetle dzięki infrastrukturze, której konkurenci nie są w stanie odtworzyć.

Kolejnym użytecznym krokiem nie jest uznanie którejkolwiek infrastruktury testowej za poprawną. Należy uruchomić obie, dokładnie je opisać i opublikować wystarczająco dużo szczegółów, aby inni mogli zrozumieć różnicę.

Dla każdego, kto buduje długo działającego agenta, bezpośrednie pytanie jest praktyczne: czy wasz system zachowuje cele, dowody i odrzucone hipotezy potrzebne do następnego działania? Przetestujcie tę ciągłość, zanim obwinicie model, a następnie testujcie ją ponownie po każdej zmianie kompakcji lub polityki kontekstu.