Claude Fable 5 już jest. Ale do mojego pipeline’u jeszcze nie trafia

Claude Fable 5 pojawił się w tym tygodniu. Rekordowe benchmarki, 10 dolarów za milion tokenów wejściowych i 50 dolarów za milion tokenów wyjściowych — mniej więcej dwa razy więcej niż Opus 4.8 — a feed szybko zapełnił się postami o tym, że to game changer.

A co wydarzyło się tego dnia w konfiguracji mojego pipeline’u do code review?

Nic.

Ani jednego commita. Ostatnie trzy zmiany w tym pliku to korekta progu false positive, kalibracja promptu do triage’u i zaostrzenie reguły eskalacji. Żadnych podmian modeli.

To nie jest zaniedbanie. I nie chodzi o to, że jestem „do tyłu”. To jedna z najbardziej świadomych decyzji w całym systemie. I warto wyjaśnić dlaczego — bo powód nie ma wiele wspólnego z samym Fable 5, a bardzo dużo z tym, czym tak naprawdę jest produkcyjny pipeline.

Benchmarki mierzą surowe modele. Pipeline’y uruchamiają modele skalibrowane.

Kiedy benchmark mówi, że model osiąga wynik o 12% lepszy, mierzy model w takiej formie, w jakiej jest dostarczany: pusty kontekst, ogólny prompt, jedno podejście do zadania.

Taki model w moim pipeline’ie nie istnieje.

W moim pipeline’ie istnieje model opakowany w około 2 500 linii skalibrowanych instrukcji. Progi czułości dostrajane miesiącami, tak żeby agenci zgłaszali to, co ważne, i nie robili hałasu tam, gdzie nie trzeba. Format wyjścia, który reszta systemu potrafi parsować. Reguły eskalacji, które decydują, kiedy tani model przekazuje zadanie droższemu. I false-positive rate, któremu mój zespół nauczył się ufać — a to najbardziej kruche aktywo całego systemu, bo w dniu, w którym reviewerzy przestają ufać flagom, przestają je czytać.

Żadna z tych kalibracji nie należy do modelu. Wszystko jest dostrojone pod konkretne zachowanie konkretnego modelu: jak interpretuje próg, gdzie robi się zbyt wyrywny, jakie sformułowania utrzymują go w wymaganym formacie odpowiedzi.

Podmiana modelu oznacza, że zysk z benchmarków może być realny — ale dług kalibracyjny też jest realny. Nie upgrade’ujesz po prostu jednego komponentu. Unieważniasz wcześniejsze strojenie i zakładasz, że odbudujesz je na lepszej bazie. Czasem to świetny zakład. Ale to nie jest darmowy zakład — a launch-day posty prawie nigdy tego kosztu nie uwzględniają.

Jedno pytanie, które naprawdę ma znaczenie

Przed każdą podmianą modelu zadaję sobie jedno pytanie:

Gdzie obecny model mierzalnie zawodzi?

Nie: „czy nowy model mógłby być lepszy” — prawie na pewno gdzieś mógłby być. Nie: „czy benchmarki wyglądają imponująco” — zawsze wyglądają, od tego są premiery.

Pytanie brzmi: gdzie dokładnie, w moim workloadzie, obecny model daje wyniki na tyle słabe, że ktoś to zauważył? Który agent przepuszcza błędy, które powinien złapać? Który tier produkuje flagi, które zespół ignoruje? Gdzie musieliśmy napisać workaround, bo model nie radził sobie z realnym przypadkiem?

Jeśli potrafię wskazać takie miejsce, mam kandydata do upgrade’u i sposób, żeby sprawdzić, czy upgrade zadziałał. Jeśli nie potrafię — a w tej chwili, dla tego pipeline’u, nie potrafię — to nie mam problemu z modelem.

Mam FOMO.

A FOMO nie jest pozycją w budżecie, za którą chcę płacić 2x więcej.

Checklista przed podmianą modelu

Kiedy odpowiedź brzmi: „tak, tutaj obecny model zawodzi”, przed wpuszczeniem nowego modelu na produkcję uruchamiam ten proces. Nic egzotycznego. I właśnie dlatego tak często jest pomijany.

1. Odtwarzaj realne zadania, nie benchmarki. Trzymam zestaw historycznych pull requestów ze znanymi wynikami — realne bugi, które system złapał, i realne false positive’y, które wygenerował. Kandydat na nowy model przechodzi przez ten zestaw offline. Benchmarki mówią mi, jak model radzi sobie z cudzymi problemami. Replay set mówi mi, jak radzi sobie z moimi.

2. Zakładaj rekalibrację i zaplanuj na nią czas. Prompty dostrojone do zachowania jednego modelu nie przenoszą się czysto na inny. Nowszy, mocniejszy model może być bardziej wyrywny przy progu, który starszy model traktował konserwatywnie. Lepszy raw judgment, gorszy skalibrowany output — dopóki nie dostroisz systemu od nowa. To są dni pracy, nie godziny. Jeśli zysk nie przetrwa tego kosztu, to nie jest zysk.

3. Licz realny koszt, nie cenę z cennika. Cena za token razy faktyczny wolumen tokenów razy częstotliwość wywołań — plus dni strojenia z punktu drugiego. Cena z tabelki rzadko jest realną ceną dla workloadów pipeline’owych. Batch processing w Fable 5 działa za połowę ceny, czyli 5/25 dolarów za milion tokenów, a prompt caching obniża koszt wejścia o około 90% — co ma ogromne znaczenie, jeśli każde wywołanie review niesie ze sobą te same 2 500 linii instrukcji. Licz na własnym wolumenie, nie na przykładzie z launch posta.

4. Podmień jeden tier, nie cały stack. Mój pipeline routuje zadania według złożoności — Haiku do triage’u i klasyfikacji, Sonnet do większości review, Opus tam, gdzie jakość oceny naprawdę robi różnicę. Fable 5 konkuruje dokładnie o jedno miejsce: slot judgment, który dziś zajmuje Opus. Wrzucanie flagowego modelu do triage’u to płacenie za sportowy samochód po to, żeby pojechać po zakupy. Zmieniasz jeden tier, reszta systemu zostaje nieruchoma, a różnicę da się faktycznie przypisać do tej zmiany.

5. Trzymaj rollback o jedną linijkę dalej. Nazwa modelu mieszka w konfiguracji, nie w kodzie. Jeśli podmiana wypada słabo, revert to commit, nie projekt. Brzmi oczywiście — dopóki nie zobaczysz pipeline’u, w którym wybór modelu przeciekł do promptów w czterdziestu plikach.

Lepszy model to opcja, nie obowiązek

I tu launch-week discourse zwykle stawia sprawę odwrotnie, niż powinien. Fable 5 nie „unieważnia” działającego pipeline’u. Dodaje jeszcze jedną opcję do decyzji routingowej.

Tylko tyle.

Może kiedyś zdobędzie miejsce w moim stacku jako model do zadań judgment. Może stanie się to za trzy miesiące, kiedy cena spadnie albo pojawi się workload, z którym Opus mierzalnie sobie nie radzi. A może nigdy, bo do tego czasu pojawi się kolejna premiera i kolejny zestaw rekordowych benchmarków.

Pipeline’u nie obchodzą launch daye. Obchodzi go jedno: czy każdy tier robi swoją robotę przy koszcie, który ma sens. W dniu, w którym któryś tier przestanie to robić, będę miał konkretny failure point, replay set i checklistę — a decyzja o podmianie zajmie popołudnie, zaś sama zmiana kilka dni porządnej pracy.

Do tego czasu najbardziej zaawansowaną rzeczą w moim pipeline’ie nie jest model, który siedzi w środku.

Tylko to, że dokładnie wiem, dlaczego właśnie on tam jest.