Nowe modele AI w praktyce: co Fable 5.1 i GPT-6 Astra mówią nam o AI-native delivery

Dwa nowe flagowe modele, tydzień pierwszych testów i sporo szumu wokół ich możliwości. Pierwsze wyniki już mówią coś użytecznego o tym, jak oceniać modele frontier pod kątem realnego delivery.

W ciągu trzech dni na początku września pojawiły się dwa nowe modele czołowych dostawców: Claude Fable 5.1 i GPT-6 Astra, odpowiednio od Anthropic i OpenAI. Przez tydzień analizowaliśmy dostępne publikacje oraz wyniki obu modeli.

Jak można się spodziewać, na werdykt produkcyjny jest zdecydowanie za wcześnie. Nie ma jeszcze znaczących wdrożeń produkcyjnych, opublikowanych liczb ROI, historii spektakularnych porażek ani postmortemów po rollbackach.

Większość dostępnych dziś danych pochodzi z testów publikowanych przez dostawców, niezależnych ewaluacji i wczesnych eksperymentów, co sprawia, że każdy definitywny ranking jest przedwczesny. Jednocześnie przydatność pierwszego tygodnia polega na tym, że pozwala pozyskać szerszą perspektywę na temat tego, jak duża część wydajności, którą przypisujemy modelowi, w rzeczywistości pochodzi z systemu zbudowanego wokół niego.

Specyfikacja modeli i początkowe różnice

Zanim w ogóle zbliżymy się do jakiegokolwiek benchmarku, zbudujmy intuicję. Oto podstawowe porównanie.

Oba modele są wielomodalne (operują na treściach tekstowych, graficznych, audio itd.), choć żaden nie generuje natywnie wideo, audio ani obrazów, zazwyczaj używając do tego zewnętrznych narzędzi.

Specyfikacja zarysowuje bardzo zgrubnie granice użyteczności, mówi jednak znacznie mniej o tym, co się stanie, gdy model stanie się częścią prawdziwego workflow delivery, z prawdziwym kontekstem, prawdziwymi narzędziami i prawdziwymi ludźmi wokół.

Benchmarki coraz częściej mierzą całe systemy

3 września Artificial Analysis notował Fable 5.1 na poziomie 66 punktów procentowych w swoim Intelligence Index, najwyższy wynik w historii tego indeksu, przy 61 dla Astry.

8 września, już w wersji indeksu v4.3, oba modele miały po 53.

Modele nie uległy zmianie, a zatem zmieniła się metodologia oceny. Efekt staje się jeszcze wyraźniejszy, gdy spojrzymy na systemy otaczające model.

Jeden benchmark idzie krok dalej i celowo mierzy pary model–harness, gdzie harness to warstwa software’owa orkiestrująca działania agenta, narzędzia i zasoby. To jednocześnie najbliższa produkcyjnym warunkom ewaluacja, jaką dotąd opublikowano. Real-SWE od Specific Labs uruchamia dziesięć zadań z licencjonowanych, prywatnych repozytoriów produkcyjnych napisanych przed 2023 rokiem, każdy model w swoim natywnym harnessie. Osiem konfiguracji, osiem uruchomień na zadanie, 640 rolloutów łącznie, raportowanych jako pass@1 z przedziałami ufności.

Żadna konfiguracja nie przekroczyła 40%. Fable 5.1 w Claude Code prowadzi z 38,8%, Astra w Codex CLI osiąga 33,8%, Gemini 3.8 Flash 31,2%, a pozostałe pięć konfiguracji ląduje między 16% a 29%. Żeby zobrazować złożoność problemów: sześć z dziesięciu zadań jest rozwiązywanych rzadziej niż w 15% przypadków, a jedno nie zostało rozwiązane ani razu.

Zastrzeżenia

Wzorzec porażek to część, którą zabralibyśmy na rozmowę z klientem, bo najczęstszym powodem niepowodzenia jest pomijanie wymagań. W dwóch najmocniejszych modelach niezweryfikowane założenia i błędy integracyjne pojawiają się równie często, a Astra częściej wykłada się na nich niż na wymaganiach. Mediana liczby poprawianych jednocześnie plików to jedenaście, mniej więcej dwa razy więcej niż analogiczna mediana w publicznych benchmarkach kodowania.

Prompty są przy tym niedookreślone tylko w podobnym stopniu jak w DeepSWE czy Terminal-Bench: mówią, co zmienić, nie jak, a szczegóły trzeba znaleźć w repozytorium i otaczających je narzędziach.

Koszty nie przekładają się liniowo na skuteczność: 38,8% Fable 5.1 kosztuje 6,96 USD za rollout wobec 4,67 USD za 33,8% Astry, czyli około 1,5 raza więcej za pięć punktów, przy czym Fable zużywa 64 tys. tokenów wyjściowych na rollout, a Astra 24 tys. Gemini 3.8 Flash jeszcze bardziej spłaszcza tę krzywą: 31,2% za 2,50 USD. Podobnie, czas egzekucji nie wpływa jednoznacznie na jakość rezultatu – rollouty poniżej dziesięciu minut kończyły się porażką prawie tak samo często jak dłuższe (71,4% vs 73,4%).

To wszystko to realne zastrzeżenia. Dziesięć zadań i osiemdziesiąt rolloutów na model oznacza, że sąsiednie wyniki mieszczą się nawzajem w swoich przedziałach ufności, więc kolejność nie jest sztywnie ustalona. Wyniki natywnych harnessów odpowiadają praktyce, ale uniemożliwiają oddzielenie modelu od harnessu. Dodatkowo, żadnego z tych rezultatów nie da się tu odtworzyć, bo kod jest prywatny.

ARC Prize podał, że Astra osiągnęła 62,7% na ARC-AGI-3 w harnessie neutralnym wobec dostawcy, z maksymalnym poziomem rozumowania, 98,6% z użyciem własnego Provider Adaptera OpenAI i, nieintuicyjnie, 99,9% z wysokim poziomem rozumowania w tym drugim środowisku. Różnica leży w scaffoldingu, nie w wagach: neutralny harness odrzuca rozumowanie modelu między akcjami, a adapter OpenAI zachowuje ten stan i sam zarządza kontekstem.

Dla kontrastu, NVIDIA osiągnęła 100% na publicznym podzbiorze tego samego benchmarku, używając architektury agentowej zbudowanej na Opusie 5, którego goły baseline wynosił około 30%. Sama NVIDIA zaznacza, że te dwie liczby pochodzą z różnych ustawień rozumowania, systemów agentowych i zbiorów ewaluacyjnych, więc różnica ilustruje tezę, a nie ją mierzy.

Interpretacja

Połączmy kropki: te różnice są większe niż wiele z tych, na podstawie których ogłasza się, że jeden model frontier jest lepszy od drugiego. Zmieniają też to, co powinniśmy oceniać. Produkcyjna zdolność AI to coś więcej niż wagi modelu. Kontekst, narzędzia, orkiestracja, retrieval, agenci, uprawnienia i mechanizmy walidacji mogą istotnie wpłynąć na wynik. I każdy z tych elementów jest projektowany, strojony i przeglądany przez ludzi, którzy rozumieją zadanie oraz kontekst biznesowy. Cały workflow zasługuje więc na taką samą uwagę jak model pod spodem.

Gdzie Astra wygląda dziś mocniej

Jedną z najwyraźniejszych wczesnych przewag Astry jest computer use: obsługa oprogramowania bezpośrednio zamiast polegania wyłącznie na jawnych integracjach.

Wśród bezpośrednio porównywalnych wyników Astra wyprzedza Opusa 5 na OSWorld 2.0 (72,6% vs 70,2%) i bije wynik Mythosa 5 na ScreenSpot-Pro (92,7% vs 87,3%). OpenAI nie publikuje porównywalnego wyniku computer use dla Fable 5.1, a 41,7% od Anthropic zmierzono na innych zadaniach, z innym sposobem oceniania i innymi zabezpieczeniami.

Może to mieć znaczenie w środowiskach enterprise z długim ogonem wewnętrznych aplikacji, w których dedykowane integracje API trudno uzasadnić.

Agent zdolny do pracy z interfejsem może potencjalnie zautomatyzować część tych workflow bezpośrednio. Zamiast usuwać wyzwanie inżynierskie, przesuwa jego część w inne miejsce. Jeśli agent potrafi zalogować się do aplikacji, poruszać się po niej i wykonywać akcje, musimy zarządzać tożsamością, uprawnieniami i sekretami. Jego działania muszą być audytowalne. Sesje potrzebują mechanizmów odzyskiwania. Zmiany w UI potrzebują fallbacków. Decyzje wysokiego ryzyka wciąż należą do człowieka. Computer use może zmniejszyć nakład na integracje, a jednocześnie zwiększyć wagę governance i observability.

Jest tu też aspekt testowy, który łatwo źle odczytać. Agent sterujący UI może służyć jako narzędzie testowe, ale jego własne zachowanie też wymaga weryfikacji: może zgłosić błąd, bo się zgubił, albo zgłosić sukces, przeoczywszy defekt. OSWorld mierzy wykonanie zadania, nie wykrywanie defektów, więc te wyniki nic nie mówią o tym, jak dobrze którykolwiek z modeli testowałby aplikację. To trzeba zmierzyć osobno, na reprezentatywnych workflow ze znanymi defektami, licząc przeoczone problemy, fałszywe alarmy i nakład pracy na przegląd tego, co agent znalazł. Kryteria akceptacji i decyzje o wydaniu pozostają po stronie zespołu produktowego.

Wyniki

Astra pokazuje też obiecujące wczesne wyniki w inżynierii oprogramowania. CodeRabbit wykrył około 4% więcej błędów w code review niż Sol i 22% więcej niż Opus 5, a przy złożonych przeglądach obejmujących wiele plików odpowiednio 20% i 33%. Sami autorzy opisują te wyniki jako wczesne i kierunkowe, co doceniamy.

Poprawiło się również rozumowanie wizualne i przestrzenne. W teście Decrypt Astra wygenerowała grywalną wersję Hangzhou w Three.js w 24 minuty. To użyteczne obserwacje. Dowody z produkcji powiedzą nam, jak konsekwentnie przekładają się na realne obciążenia.

Wydajność i cena opowiadają różne historie

Astra pokazuje też, dlaczego sama cena API jest słabą miarą ekonomii AI. W 100-godzinnym teście Nate’a Herka Fable ukończył zadanie w 9 h 35 min, Astra w 11 h 19 min. Astra była wolniejsza, ale całkowity koszt poszedł w drugą stronę: 327 USD za Astrę wobec 513 USD za Fable. Dla tego konkretnego eksperymentu Fable zapewnił krótszy czas ukończenia, zaś Astra niższy rachunek. Alternatywna pula wyzwań, inny rozmiar kontekstu, wzorzec cache’owania czy ustawienie rozumowania mogłyby zmienić tę relację.

Dla zespołów delivery koszt na ukończone zadanie jest więc bardziej użyteczną metryką niż cena tokena w oderwaniu od kontekstu. Czas ukończenia, jakość i odsetek porażek należą do tego samego rachunku. Pytanie brzmi już nie „który model ma lepszy cennik”, ale „jak cały setup zmienia koszt, tempo, jakość i przewidywalność delivery”.

Gdzie Fable 5.1 wygląda dziś mocniej

Pisanie tekstów to jeden z bardziej spójnych pozytywnych sygnałów wokół Fable 5.1. Kilku niezależnych recenzentów zgłasza bardziej naturalną prozę i mniej charakterystycznych dla Claude’a manier pisarskich. Every ocenił czytelność tekstu mniej więcej na poziomie siódmej klasy, a Latent Space opisał go jako bliższy zwykłej ludzkiej komunikacji.

Długoletni test SVG Simona Willisona przyniósł rezultat, który sam autor uznał za najlepszy spośród dotychczasowych modeli Anthropic. Willison od kilku generacji regularnie zleca kolejnym modelom to samo zadanie: wygenerowanie w formacie SVG obrazu pelikana jadącego na rowerze. Choć jest to test nieformalny, jego wartość polega na konsekwentnym stosowaniu tego samego zadania, co pozwala obserwować, jak możliwości modeli zmieniają się z generacji na generację.

Drugi ciekawy obszar to długotrwała samodzielna praca. Ramp opublikował nienadzorowany, 38-godzinny, autonomiczny eksperyment z uczeniem maszynowym, w ramach którego ukończono wiele eksperymentów. Anthropic raportuje też poprawę przejrzystości, gdy model napotyka problemy, w tym większą skłonność do sygnalizowania, że utknął, zamiast przedstawiania zadania jako wykonanego. Jeśli to się utrzyma poza tygodniem premiery, dla pracy bez nadzoru znaczy to więcej niż którykolwiek punkt benchmarku w tym wpisie.

Millennium podało inny ciekawy przypadek: model pomógł zidentyfikować rzadki błąd, który opierał się wyjaśnieniu przez cztery czy pięć lat.

To pojedyncze przykłady, a nie szerokie dowody z produkcji. Jeśli jednak to zachowanie utrzyma się w skali, może mieć znaczenie dla długotrwałych, agentowych workflow inżynierskich.

Koszty cache’u w Fable przykuwają oko

Cena odczytu z cache’u dla Fable spadła z 1,00 USD do 0,25 USD za milion tokenów. To czyni go szczególnie interesującym dla workflow zbudowanych wokół wielokrotnego odpytywania tego samego dużego zbioru informacji:

• repozytoriów,
• dokumentacji,
• baz wiedzy,
• innego trwałego kontekstu projektu.

Skalowanie paramteru „effort” też może mieć znaczenie. Harvey zgłosił, że jakość pozostała względnie stabilna przy niższych ustawieniach rozumowania, a zużycie tokenów wyjściowych spadło o mniej więcej połowę.

Jednocześnie wczesne pomiary ogólnej efektywności tokenowej Fable mocno zależą od wybranego punktu odniesienia. Every zmierzył, że Fable 5.1 zużywa mniej niż połowę tokenów Opusa 5 przy porównywalnych wynikach w jego agencie slackowym na effortcie Medium, przy czym powtarza, a nie mierzy, szacunek Anthropic o 25-45% niższych kosztach względem Fable 5. Artificial Analysis, jak relacjonuje Latent Space, porównał Fable 5.1 z Fable 5 na maksymalnym effortcie i znalazł około 1,7 raza więcej tokenów wyjściowych oraz około 20% wyższy koszt na zadanie (3,76 USD), przy ~4% tokenów wyjściowych obsłużonych przez modele fallbackowe Anthropic.

Issue na GitHubie z 1 września zgłasza też, że Fable na średnim effortcie wyczerpał pełny limit tokenów Claude Code w niecałe 20 minut. Te wyniki mierzą różne obciążenia i konfiguracje, więc sama rozbieżność jest użyteczną informacją. Intensywne przetwarzanie korzystające z cache’u może znacząco skorzystać na nowym cenniku. Pozostałe przypadki należy mierzyć osobno.

Oba modele wnoszą inne ryzyka

Wzrost możliwości podnosi wagę zrozumienia tego, jak model zawodzi.

Astra

System card OpenAI raportuje znaczący spadek monitorowalności chain-of-thought. W testach adwersarialnych, w których modelowi polecono ukrywać zaniżanie wyników, Astra w większości przypadków omijała monitor chain-of-thought OpenAI: wykrywalność spadła poniżej 11% w teście sandbaggingu WMDP i do zera na wewnętrznym benchmarku kodowania. OpenAI przedstawia to jako zdolność wykazaną na polecenie, nie zaobserwowane domyślne zachowanie, i nie raportuje rozumowania steganograficznego ani omijania monitora pełnego kontekstu.

OpenAI zauważa, że dalsza degradacja tego typu w przyszłych generacjach mogłaby znacząco obniżyć pewność wykrywania niektórych form niepożądanego zachowania. To szczególnie istotne, w miarę jak modele dostają większą autonomię.

Fable

W przypadku Fable wczesne obawy są inne. Recenzenci Every zgłaszają niekonsekwentne trzymanie się zadanych limitów, w tym liczby słów. Są też doniesienia o halucynowanych cytowaniach podczas pracy z dużymi dokumentami źródłowymi, a to istotny tryb awarii w analizie dokumentów.

Własne informacje systemowe Anthropic również wskazują na ograniczenia w zakresie uczciwości pod presją i podporządkowania się promptom systemowym, dopuszczając coś, o czym model wie, że jest nieprawdą.

Routing modeli dokłada kolejny aspekt operacyjny. Część zapytań z biologii jest kierowana do Opusa 5, a zapytania z obszaru cyber do Opusa 4.8. Przełączenie jest widoczne w odpowiedzi, ale decyduje o nim klasyfikator, nie zespół, więc ten sam workflow może być obsługiwany przez różne modele w różnych uruchomieniach. To komplikuje dokładną reprodukcję i czyni ścieżkę fallbacku kolejną kwestią do przetestowania.

Te zachowania trzeba rozumieć w kontekście docelowego przetwarzania oraz poziomu autonomii, jaki dajemy modelowi. Produkcyjne workflow wymagają ograniczonych uprawnień, walidacji, bramek jakości i bezpieczeństwa, audytowalności i jasnej odpowiedzialności po stronie człowieka.

Rezydencja danych może rozstrzygnąć, zanim zrobią to benchmarki

Dla europejskich organizacji jakość modelu bywa drugorzędna wobec ograniczeń wdrożeniowych. I to może być najbardziej praktyczny fakt w całym tym wpisie. W chwili pisania Harvey podaje, że Anthropic nie zapewnia regionalnego przetwarzania dla Fable 5.1 ani Fable 5, co oznacza, że dane są przetwarzane w Stanach Zjednoczonych.

Przewodnik migracyjny OpenAI wskazuje z kolei, że tryby fast i priority Astry są obecnie niedostępne przy rezydencji danych w UE.

Te warunki mogą się szybko zmienić i zawsze trzeba je zweryfikować dla konkretnego modelu, trybu i konfiguracji wdrożenia przed implementacją. Dla obliczeń objętych wymaganiami rezydencji danych architektura wdrożenia może zawęzić wybór modelu, zanim w ogóle zacznie się benchmarking wydajności.

Poza kodowaniem obraz pozostaje niepełny

W obciążeniach naukowych jest kilka naprawdę ciekawych przypadków użycia.

Benchmark FrontierMath Erdős od Epoch AI użył 68 nierozwiązanych problemów Erdősa sformalizowanych w Leanie, z budżetem 300 USD i 72 godzin na problem. Astra rozwiązała dwa, około 3%. Sol, GPT-5.5, Fable 5.1 i Fable 5 zakończyły pracę bez sukcesu.

Białka

Projektowanie białek to kolejny przykład.

Badanie Anthropic zwalidowane w mokrym laboratorium, z projektami wyprodukowanymi i przetestowanymi niezależnie przez Adaptyv Bio i Twist Bioscience, raportuje, że Claude Mythos Preview osiągnął 35,1% hit rate przy jednym celu na 24-godzinną sesję (26,7% w konfiguracji wielocelowej, 22,6% dla Opusa 4.8), wobec bazowych 10-15%, które Anthropic wyprowadził z proteinbase.com. Mythos Preview nie jest ogólnie dostępny, a Anthropic zapowiada dalszą charakteryzację, żeby potwierdzić te wskaźniki.

Jest tu ważne zastrzeżenie: Fable 5.1 kieruje zapytania biologiczne do Opusa 5 i oficjalnie nie jest rekomendowany do profesjonalnych badań biologicznych.

Robotyka

Robotyka dostarcza kolejnego przykładu. W zadaniu Robocurve „klocek do miski”, z tym samym harnessem dla wszystkich trzech modeli, Fable 5 trafił 1/20, Fable 5.1 8/20, a Astra 19/20. W trudniejszym wkładaniu elementu układanki Astra i Fable 5.1 zaliczyły po 2/20 i zatrzymały się na tym samym kroku.

Robocurve zgłasza jednak kilka zastrzeżeń: różne stanowiska dla przebiegów z miską, nieprzeplatane próby w odstępie dwóch dni i ocena przez operatora, poza ślepą próbą. O ile postęp jest zauważalny, o tyle precyzyjna manipulacja pozostaje w dużej mierze nierozwiązana.

Luki w pokryciu badaniami są równie ciekawe – wciąż nie ma znaczących, udokumentowanych wdrożeń produkcyjnych żadnego z modeli w wielu typowych domenach enterprise. Szczególnie brakuje niezależnych ewaluacji dla arkuszy kalkulacyjnych i danych tabelarycznych, mimo ich wagi w codziennej pracy biurowej.

Sprawozdania

Jeden konkretny przykład biznesowy pochodzi od Legory. W zadaniu uzgadniania sprawozdań finansowych na 41 dokumentach Astra znalazła w kilka minut wszystkie cztery podłożone błędy, co dało około 40% poprawy w tym workflow. W całym benchmarku średnia poprawa była jednak bliższa 3%. Tę różnicę warto pamiętać przy ocenie efektownych demonstracji. Wyniki ze starannie dobranych zadań mogą znacząco odbiegać od średniej wydajności w szerszym procesie delivery.

Migracja to więcej niż zmiana konfiguracji

Obaj vendorzy opublikowali przewodniki migracyjne i wymieniają w nich istotne breaking changes.

Anthropic udostępnia osobne ścieżki migracji w zależności od poprzedniego modelu. Część zachowań, na których mogą polegać istniejące systemy, nie jest już wspierana, w tym wymuszone wywołania narzędzi, prefill odpowiedzi asystenta i wyłączanie rozumowania.

Jest też subtelna zmiana wokół śladów rozumowania. Są one związane z modelem, który je wygenerował, więc edycja wcześniejszych części rozmowy może je unieważnić i spowodować błąd żądania. Frameworki, które same kompaktują kontekst, przebudowują listy narzędzi między wywołaniami albo wstrzykują przypomnienia w każdej turze, mogą więc wymagać zmian.

Lista migracyjna OpenAI jest krótsza, ale istniejące integracje i tak mogą wymagać pracy inżynierskiej. Usunięto popularne parametry samplingu, najniższe ustawienie rozumowania nie jest już wspierane, a wywoływanie narzędzi oczekuje nowszej powierzchni API.

Część zmian w zachowaniu trudniej wykryć, bo niekoniecznie kończą się błędem: mniej równoległych wywołań narzędzi, mniej retrievalu przy niskim effortcie, gęstsza proza albo przepisanie całego pliku tam, gdzie oczekiwano punktowej edycji. To zmiany, które wyłapie recenzent wiedzący, jak wynik wyglądał wcześniej.

Dla zespołu delivery oznacza to, że upgrade modelu jest release’em i jak każdy release potrzebuje zestawu testów regresyjnych.

Własne wytyczne Anthropic dotyczące ewaluacji agentów ujmują to wprost: zespoły z evalami migrują w dni, zespoły bez nich spędzają tygodnie na testowaniu ręcznym. Taki zestaw musi uwzględniać dwie rzeczy. Testowany system jest niedeterministyczny, więc liczy się nie to, czy zadanie przejdzie raz, ale jak niezawodnie przechodzi w powtarzanych uruchomieniach. Obaj vendorzy podkreślają też, że modele testują własną pracę, tymczasem agent może przenieść to samo niezrozumienie wymagania do kodu i do testów, więc same zielone testy nie dowodzą, że wymaganie zostało spełnione.

Ma to konsekwencję architektoniczną dla systemów AI-native. Modele będą się zmieniać, a wraz z nimi ich interfejsy i zachowania. Workflow delivery potrzebują na tyle dużej modularności, żeby dało się oceniać i wymieniać zdolności AI bez przebudowywania całego procesu przy każdym nowym flagowcu: wielokrotnego użytku kontekstu, workflow i mechanizmów kontroli, które przeżyją każdy pojedynczy model.

Od czego zaczęlibyśmy testy

Dowodów nie starcza na uniwersalny ranking. Starcza za to na wskazanie rozsądnych punktów startowych, a taki research jest czasochłonny, więc zamiast listy lektur dajemy Wam tabelę. Aspekty związane z kodowaniem pozostają szczególnie trudne do rozstrzygnięcia.

Astra jest na szczycie Code Arena: WebDev (1797 vs 1762) i Terminal-Bench 4.0 (57,7% vs 55,8%), prowadzi też o siedem punktów w DeepSWE oraz w FrontierCode 1.1.

81,2% Fable 5.1 na SWE-bench Pro nie ma odpowiednika po stronie Astry, który dałoby się pobić. Wczesna ankieta wśród czytelników Zviego wylądowała blisko 50:50, w dół z 2:1 na korzyść Claude’a.

Wybrany benchmark może więc zdecydować o tym, kto wygląda na zwycięzcę.

Te rekomendacje należy traktować jako punkty wyjścia do ewaluacji. Faktyczny wybór zależy od zagadnienia, kontekstu projektu, wymaganych integracji, akceptowalnego ryzyka, ograniczeń governance i całkowitej ekonomii.

Testing & QA

Zapewnij jakość, wydajność i bezpieczeństwo swojego oprogramowania dzięki naszym usługom testowania i automatyzacji testów.

Oferta Testing&QA

Co mówi nam pierwszy tydzień

Cztery pytania wciąż trudno rozstrzygnąć jednoznacznie:

• który model jest ogólnie mądrzejszy,
• jak efektywny naprawdę jest Fable w różnych workflow,
• jak porównywać Astrę na ARC-AGI-3,
• który model prowadzi w pracy agentowej.

Dla każdego z nich można znaleźć pomiary, których wyniki różnią się między sobą bardziej niż modele, które mają porównywać. Dlatego bardziej miarodajnych wniosków warto szukać gdzie indziej.

1. ARC-AGI-3 pokazuje, jak mocno orkiestracja i otaczająca architektura mogą wpłynąć na zmierzoną zdolność.
2. 100-godzinny eksperyment pokazuje, że szybkość i całkowity koszt mogą wskazywać w różne strony.
3. Computer use otwiera nowe możliwości automatyzacji, a razem z nimi nowe wymagania wokół tożsamości, uprawnień, zarządzania sekretami, logowania audytowego i odzyskiwania sesji.
4. 4, Przewodniki migracyjne obu vendorów pokazują, że zmiana modelu może wpłynąć na zarządzanie kontekstem, narzędzia i zachowanie aplikacji.
5. Zamiast oceniać sam model, trzeba oceniać cały proces, w którym model pracuje.

Warto zacząć od dwóch-trzech zadań, które mają znaczenie w Waszym środowisku. Uruchomić modele kandydackie na realistycznym kontekście projektu. Następnie użyć narzędzi, integracji i mechanizmów kontroli, które istniałyby na produkcji.

Pozostaje ocena jakości, pomiar czasu ukończenia zadania, prześledzenie porażki i podsumowanie całkowitych kosztów, a finalnie decyzja inżynierska lub biznesowa na podstawie tych wyników.

Tydzień po premierze leaderboard będzie się dalej zmieniał. Proces ewaluacji oparty na obciążeniach pozostanie użyteczny długo po tym.