GPT-6.1 Sol na COBOL: 86,6% wobec 5,4%, a tylko jeden z dwóch testów można powtórzyć

Dnia 19 października 2026 OpenAI opublikowało dwie ewaluacje kodowania dla języków o niskich zasobach, a najważniejsza liczba należy do GPT-6.1 Sol: 86,6% zadań migracji COBOL zakończyło się powodzeniem przy niskim nakładzie rozumowania, wobec 5,4% dla GPT-5.6 Sol przy tym samym ustawieniu; przy wyższym nakładzie odsetek rośnie do 97,9%. Druga ewaluacja, MultiLangBench, to historia innego modelu — GPT-6 Astra uzyskał średnio 87,4% w dwudziestu językach przy maksymalnym nakładzie — ale to bardziej użyteczna połowa publikacji, ponieważ O​penAI udostępniło swoje środowisko testowe na GitHubie na licencji Apache-2.0 i możesz uruchomić je samodzielnie jeszcze dziś po południu. Ewaluacja migracji COBOL — ta, która odpowiada za 86,6% — to inna sprawa: jej testy są ukryte, kryterium zaliczenia stanowi zgodność wyjścia co do bajtu z przypadkami, których nikt poza O​penAI nie widział, a żadna strona trzecia jej nie odtworzyła. Ta asymetria to cała historia i warto ją jasno przedstawić, zanim którakolwiek z tych liczb zostanie przytoczona w biznesowym uzasadnieniu migracji. Udokumentowane awarie AI i incydenty z agentami, które stoją za takimi publikacjami jak ta, są zbierane w OrcaRouter AI Incident Archive, gdzie każdy wpis zawiera własne źródła, wagę, stopień pewności i flagę sporu.

Jedna data, którą trzeba dobrze zapamiętać. Sam GPT-6.1 Sol pochodzi z 29 września 2026 — to nie jest premiera i nic tutaj nie zmienia wag, ceny ani cennika modelu. 19 października O​penAI opublikowało dowody na to, co model potrafi w kategorii, której wcześniej nie dokumentowano, i udostępniło benchmark, który każdy może ponownie uruchomić. To jest wydarzenie, o którym jest ten tekst.

Co faktycznie opublikowano i do czego służy każda z połówek

Te dwie ewaluacje odpowiadają na różne pytania, a samo ujęcie OpenAI je rozdziela. MultiLangBench pyta, czy model potrafi zbudować coś w języku, na którym nikt go nie trenuje: zaimplementować SQLite 3.40.1 od zera w jednym z dwudziestu języków programowania, a następnie przejść zestaw testów zgodności bazy danych. Ewaluacja migracji z COBOL-a pyta, czy model potrafi przenieść coś: przetłumaczyć programy w COBOL-u na C++, Java, Kotlin, Python lub Rust, zachowując dokładnie obserwowalne zachowanie.

Pierwszy to test dolnego progu możliwości. Drugi jest tym, na którym przedsiębiorstwom faktycznie zależy, ponieważ COBOL nie jest ciekawostką benchmarkową — według długoletnich szacunków IBM COBOL stoi za ponad 40% systemów bankowości internetowej i około 95% transakcji bankomatowych, a kod ten jest utrzymywany przez kadrę, która nie jest zastępowana.

• MultiLangBench, maksymalny wysiłek — GPT-6 Astra 87,4%, GPT-6 Luna 40,3%, GPT-5.6 Sol 26,8%. Astra przekroczyła 83% w 19 z 20 języków; najsłabszym punktem był COBOL z 72,1% wobec 10,9% GPT-5.6 Sol, co pokazuje, że najtrudniejszym językiem w zestawie pozostaje ten z najstarszymi narzędziami.

• Migracja COBOL, niski nakład pracy — GPT-6.1 Sol 86,6%, GPT-5.6 Sol 5,4%, przy szacunkowo 61% kosztu API starszego modelu za przebieg ewaluacji, czyli o 39% mniej.

• migracja COBOL, większy nakład pracy — GPT-6.1 Sol 97.9%, co O​penAI opisuje jako bliskie nasyceniu.

• Szczegółowe dane dla poszczególnych języków, które OpenAI faktycznie opublikowało — Fortran 83,5% dla Astra w porównaniu z 21,4% dla GPT-5.6 Sol; Visual Basic 89,4% wobec 27,5%; OCaml 85,8% wobec 25,6%; GPT-6 Luna na poziomie 17,1% w COBOL, 31,4% w Fortranie, 34,1% w OCaml i 41,6% w Visual Basic.

• Koszt na próbkę w MultiLangBench — szacunkowo 0,77 USD dla GPT-6 Luna wobec 3,48 USD dla GPT-5.6 Sol, około 78% mniej, i to właśnie ta liczba czyni najsłabszy model w zestawieniu tym interesującym dla potoku generowania buildów.

Ewaluacja, którą możesz uruchomić ponownie: o co tak naprawdę prosi MultiLangBench

Repozytorium to github.com/openai/MultiLangBench, Apache-2.0, a czytanie infrastruktury testowej daje więcej informacji niż czytanie tabeli liderów. Zadanie jest wystarczająco konkretne, że model nie jest w stanie go zblefować: stworzyć plik wykonywalny, który przyjmuje ścieżkę do bazy danych jako argument wiersza poleceń, odczytuje zapytanie SQL ze standardowego wejścia i zachowuje się jak SQLite 3.40.1. Testy pochodzą z własnego zestawu testów TCL SQLite — łącznie około 51 000 testów, z których około 24 000 przekonwertowano na trójki, których używa harness: początkową bazę danych, zapytanie użytkownika i zapytanie walidacyjne. Nazwy testów to skróty SHA-256 tych komponentów, więc zestawu nie da się zapamiętać po nazwach.

Trudność tkwi w zasadach, a każda z nich zamyka pewną drogę na skróty:

• Brak internetu i nigdzie w środowisku nie ma SQLite. Harness mówi, aby najpierw usunąć wszelkie ślady SQLite. Model nie może wywołać prawdziwego silnika przez powłokę ani pobrać implementacji.

• Walidacja odbywa się na prawdziwym SQLite 3.40.1. Twoja implementacja modyfikuje bazę danych; harness wyodrębnia ją i sprawdza przy użyciu oryginału. Przybliżone zachowanie nie przechodzi testu.

• Sześćdziesiąt sekund na test, a odpowiedź w złym języku daje zero punktów. Mieszanie języków kończy się niepowodzeniem, a system testowy zauważa, że do sprawdzenia, w jakim języku faktycznie napisałeś, może zostać użyty inny model. Ta ostatnia zasada istnieje, ponieważ oczywiste oszustwo — napisać w Pythonie i opakować — jest pierwszą rzeczą, której próbuje zdolny model.

• Szybkie uruchomienie to 272 testy, a nie 24 000. README zaleca uruchamianie tylko testów, których nazwy zaczynają się od 00, 01 lub 02 jeśli chcesz uzyskać porównywalną liczbę. To szczegół, o którym warto pamiętać, zanim porównasz swój wynik z wynikiem OpenAI: uruchomienie pełnego zestawu i szybkie uruchomienie to nie ten sam pomiar, a README tak podaje.

To prawdziwy, weryfikowalny benchmark. Mówi ci też coś, czego nie przekazały relacje prasowe: wynik 87,4% z nagłówków zmierzono na zestawie, który możesz wskazać własnemu modelowi, a to jest wystarczająco rzadkie, by było warte pobrania.

Ewaluacja, której nie można powtórzyć — i dlaczego to nie jest automatycznie skandal

Ewaluacja migracji COBOL została zaprojektowana, przeprowadzona i oceniona przez O​penAI, a jej przypadki testowe nie są publikowane. Próg zaliczenia określono precyzyjnie — migracja liczy się tylko wtedy, gdy każdy ukryty test daje identyczny co do bajtu obserwowalny wynik — i właśnie ta precyzja sprawia, że wyniku nie da się zweryfikować z zewnątrz: 86,6% to pomiar O​penAI na własnych ukrytych przypadkach O​penAI. Tylko jedną z dwóch ewaluacji w wydaniu czytelnik może odtworzyć samodzielnie.

Wstrzymywanie testów migracji nie jest pozbawione podstaw. Korpus jest przypuszczalnie zaczerpnięty z prawdziwych programów dziedziczonych, a jego publikacja może ujawnić kod klienta lub dostarczyć przyszłym modelom zbiór treningowy. Zgodność co do bajtu jest również naprawdę konserwatywnym kryterium, surowszym niż większość ewaluacji dostawców: nie nagradza tłumaczenia, które jest jedynie bliskie.

Ale to kryterium jest także miejscem, w którym zaczynają się praktyczne kłopoty, i wskazują na to własne zastrzeżenia OpenAI. Wynik migracji nadal wymaga eksperckiego przeglądu oraz testów pod kątem reguł biznesowych i zależności systemowych przed wdrożeniem produkcyjnym. A zgodność bajtowa jest trudna dokładnie tam, gdzie trudny jest COBOL: język ten obcina i zaokrągla arytmetykę stałoprzecinkową w sposób, którego większość języków docelowych nie stosuje, więc tłumaczenie może wyglądać poprawnie, przejść zestaw testów sprawdzający „wystarczająco blisko”, a mimo to przesunąć saldo o cent. Ukryty zestaw testów wymagający dokładnej równości sobie z tym radzi; twój własny proces przeglądu również musi sobie z tym radzić, ponieważ wynik modelu nie jest stwierdzeniem o twoich programach.

Liczba dotycząca kosztów wymaga takiej samej staranności. Oszczędność 39% to szacunek dla przebiegu ewaluacji — tokenów wchodzących do benchmarku i z niego wychodzących — a nie koszt zastąpienia systemu produkcyjnego, który zdominowany jest przez odkrywanie, przegląd ekspercki, testy integracyjne i lata nieudokumentowanego zachowania, którego nie próbkuje żadna ewaluacja.

Co powinny zmienić 86,6% i 97,9% w decyzji?

Uczciwa interpretacja jest węższa niż nagłówki i bardziej użyteczna niż one. Model bazowy na poziomie 5,4% nie jest modelem, który działa połowicznie; to model, który niemal nigdy nie tworzy tłumaczenia zachowującego dotychczasowe działanie, więc starsza generacja nigdy nie była kandydatem do tej pracy. GPT-6.1 Sol z wynikiem 86,6% znajduje się w zakresie, w którym rachunek ekonomiczny się odwraca: narzędzie, które tworzy szkic większej części tłumaczenia i pozostawia jego sprawdzenie recenzentowi, to inny produkt niż takie, które nie daje niczego użytecznego.

97,9% przy wyższym wysiłku to liczba, do której należy podchodzić sceptycznie — nie dlatego, że jest błędna, lecz dlatego, że jest nasycona. Gdy benchmark zbliża się do swojego sufitu, przestaje rozróżniać modele i zaczyna mierzyć sam zestaw testów, a O​penAI mówi to wprost. Na potrzeby planowania traktuj 86,6% przy niskim wysiłku jako tani punkt operacyjny, a 97,9% jako sufit tego, co może pokazać ewaluacja — nie jako obietnicę dokładności dla twojej bazy kodu.

Warto też przeprowadzić kontrolę krzyżową, która przeczy hype'owi. W teście budowania COBOL pozostał najsłabszym językiem GPT-6 Astra z wynikiem 72,1%, mimo że Astra jest ogólnie mocniejszym modelem ze średnią 87,4%. Ten język jest trudny w obu kierunkach. Model, który dobrze migruje COBOL w ukrytej ewaluacji, nie jest przez to dobry w COBOL-u; jest dobry w schemacie, który pojawia się w próbkach ewaluacji.

Druga rzecz, która wydarzyła się w tym tygodniu: twierdzenie o śladzie rozumowania

Szeroko udostępniany post z 21 października twierdził, że ślady rozumowania GPT-6.1 Sol są „całkowicie czytelne, nie ma się czym martwić”. Nic w publikacji O​penAI z 19 października ani na własnej stronie dokumentacji modelu nie potwierdza, że stanowi to zmianę w tym, co zwraca API. Przewodnik O​penAI dotyczący rozumowania wyraźnie mówi, że surowe tokeny rozumowania nie są ujawniane — elementy rozumowania pozostają nieprzejrzyste — a to, o co można poprosić, to podsumowanie rozumowania poprzez parametr summary, przy czym zaszyfrowana treść rozumowania jest odtwarzana w kolejnych turach. GPT-6.1 Sol obsługuje formę all_turns tego odtwarzania. Kanał podsumowań nie jest czytelnym śladem, a utożsamianie obu tych rzeczy to sposób, w jaki formułuje się twierdzenie o bezpieczeństwie na podstawie zrzutu ekranu.

To, co mierzalne, jest pokrewne i ciekawsze dla każdego, kto audytuje agenta. Ewaluacja GPT-6.1 Sol przeprowadzona przez Sonar 9 października, uruchomiona względem GPT-6 Sol przy średnim wysiłku na 4 444 zadaniach Java, wykazała, że liczba tokenów rozumowania spadła o 51,4% — z 2,64 mln do 1,28 mln — podczas gdy udział rozumowania w wyjściu spadł z 41,8% do 19,5%, objętość wyjścia wzrosła, a wskaźnik zaliczeń funkcjonalnych poprawił się z 83,09% do 85,29%. Ten sam przebieg wykazał spadek gęstości podatności o 32,4%, ale wzrost liczby ustaleń dotyczących niezawodności o krytycznej ważności z 21 do 46, przy czym błędy współbieżności były największą kategorią z 196 ustaleniami. To kompromis, na podstawie którego recenzent może podjąć działania. „Ślady są czytelne” takie nie jest, ponieważ ślady nie są tym, co jest zwracane.

W projekcie migracyjnym ma to znaczenie w jeden konkretny sposób: Twoją ścieżką audytu są diff i wyniki testów, a nie narracja modelu. Zaplanuj odpowiednio zasoby na przegląd — ustalenie Sonara, że o 39,4% więcej wygenerowanego kodu dało łącznie 12 982 zgłoszenia wobec 9 859, pokazuje kształt kosztu, który kryje się za wynikiem benchmarku.

Samodzielne prowadzenie obu ramion

Praktyczny problem z takim porównaniem polega na tym, że wariant bazowy i nowy wariant to zwykle dwa kontrakty, dwa klucze i dwie relacje rozliczeniowe, co stanowi wystarczająco dużo tarcia, że nikt nie uruchamia wariantu bazowego. Oba modele są w naszym katalogu pod jednym kluczem: openai/gpt-6.1-sol i openai/gpt-5.6-sol, w cenach katalogowych OpenAI z 0% marży, czyli te same 2,00 USD za wejście i 10,00 USD za wyjście za milion tokenów, które zapłaciłbyś dostawcy, z wejściem z pamięci podręcznej po 0,10 USD i zapisami do pamięci podręcznej po 2,50 USD, a poziom powyżej 272K przekazywany po 4,00 USD, 0,20 USD, 5,00 USD i 15,00 USD. Zmiana stawek dostawcy jest tu aktywna w dniu publikacji, a nie dopiero przy następnym przeglądzie umowy.

To właśnie ten pass-through sprawia, że benchmark „same-day” jest tani w uruchomieniu: uruchom szybki zestaw MultiLangBench na obu modelach, zapłać cenę katalogową za każdy z nich, a otrzymasz liczbę dotyczącą własnego łańcucha narzędzi, a nie OpenAI. Automatyczne przełączanie awaryjne to druga połowa argumentu — jeśli nowszy model pogorszy się w trakcie działania lub trasa zostanie objęta limitem szybkości, żądanie nie zakończy się niepowodzeniem razem z nim, co pozwala postawić nieprzetestowany model przed potokiem migracji, zanim będziesz mieć własne dowody.

Harness MultiLangBench jest publiczny, a przypadki migracji COBOL nie są, więc jedynym uczciwym testem tych 86,6% jest ten, który zbudujesz sam: wylosuj kilkaset własnych programów COBOL, przetłumacz je i porównaj wynik bajt po bajcie z oryginalnym zachowaniem. To tydzień pracy i jest warte więcej niż tabela dostawcy.

Co obejrzeć dalej

Trzy rzeczy zmieniłyby ten obraz, a żadna z nich jeszcze nie nastąpiła. Gdyby OpenAI opublikowało przypadki migracji COBOL albo niezależne laboratorium ponownie je wykonało, liczba podana przez dostawcę stałaby się pomiarem. Gdyby strona trzecia odtworzyła tabelę MultiLangBench dla poszczególnych języków, dowiedzielibyśmy się, czy 72,1% dla COBOL to właściwość języka, czy zestawu testowego. A niezależny wynik modelu w benchmarkach — Artificial Analysis obecnie plasuje GPT-6.1 Sol z wynikiem 52 w Intelligence Index, na dwunastym miejscu spośród 214 modeli, przy 55,2 tokenu wyjściowego na sekundę i 0,72 USD za zadanie indeksowe — to kontrola, która w ogóle nie zależy od własnych ewaluacji OpenAI.

Do tego czasu przydatne podsumowanie jest krótkie. GPT-6.1 Sol to model z 29 września, którego zdolność do pracy ze starym kodem udokumentowano 19 października — w jednej ewaluacji, którą można uruchomić, i jednej, której nie można. Ta, którą można uruchomić, mówi, że nowa generacja jest w innej klasie w przypadku języków niskozasobowych. Ta, której nie można uruchomić, mówi, że migracja COBOL-a jest teraz warta pilotażu. Tylko Twoja własna baza kodu może zamienić którąkolwiek z nich w decyzję.