Myślałem, że jestem sprytny. Napisałem funkcję pomocniczą, która rezerwowała dokładnie trzydzieści procent okna kontekstowego jako budżet na myślenie dla naszego potoku AI. Było to czyste, przewidywalne i działało wspaniale na modelu Opus 4.5. Potem przeszedłem na Opus 4.8 i każde pojedyncze zapytanie kończyło się błędem 400. Moja starannie opracowana matematyka tokenów z dnia na dzień stała się bezużyteczna.

Stary wzorzec był prosty. Ustawiałeś wartość budget_tokens, a model racjonował swój proces myślowy, aby zmieścić się w tym limicie. Gdy przekazywałem 128K kontekstu, mój kod rezerwował około 38 000 tokenów na rozumowanie, zostawiając resztę na odpowiedź. Wydawało się to odpowiedzialne. Jak trzymanie samochodu poniżej limitu prędkości.

Ten model odszedł do lamusa. Nowsze wersje, takie jak Opus 4.7 i 4.8, wykorzystują adaptacyjne myślenie. Nie wybierasz już konkretnej liczby. Zamiast tego przekazujesz „pokrętło wysiłku” (effort knob). Brzmi to jak zwykła zmiana nazwy, ale te dwa parametry nie mogłyby być bardziej różne. budget_tokens wyznaczało sztywny sufit tego, jak dużo model mógł myśleć. Effort kontroluje to, jak model myśli i działa w pierwszej kolejności. Jednym jest licznik na dystrybutorze paliwa. Drugim jest mapa silnika.

Przypisywanie wysiłku do realnych zadań

Kiedy zmienił się sposób sterowania, moja stara intuicja przestała działać. Musiałem na nowo nauczyć się, co tak naprawdę daje każde ustawienie. Przeprowadziłem testy na naszym wewnętrznym ruchu, aby sprawdzić, gdzie w praktyce plasuje się każdy poziom wysiłku.

Klasyfikacja i routing powinny prawie zawsze używać poziomu low effort. Te zadania to szybkie decyzje. Czy to prośba o zwrot, czy pytanie sprzedażowe? Czy ten wpis w logu wymaga eskalacji? Nie potrzebujesz do tego monologu. Niski poziom wysiłku pozwala utrzymać niskie opóźnienia, a koszty są wręcz znikome.

Większość ruchu w aplikacji – codzienna praca polegająca na podsumowaniach, przeredagowaniach, odpowiedziach wsparcia i ekstrakcji treści – mieści się w przedziale medium do high effort. To punkt równowagi. Model otrzymuje wystarczająco dużo przestrzeni, aby rozwiązać rzeczywistą dwuznaczność, nie marnując tokenów na zadanie, które nie wymaga rozbudowanego łańcucha myśli.

Kodowanie i pętle agentowe wymagają poziomu xhigh effort. To tutaj błędy kumulują się najszybciej. Jeśli model przygotuje zły plan w pierwszej turze pętli wywoływania narzędzi, spędzi kolejne trzy kroki na naprawianiu szkód. Co gorsza, może wywołać niewłaściwe narzędzia, wyhalucynować parametry i zostawić użytkownika z niedziałającym przepływem pracy. Lepsze rozumowanie na starcie zapobiega takiej spirali.

Zadania krytyczne powinny otrzymywać poziom max effort. Nie używaj tego do wszystkiego. Zarezerwuj to na momenty, w których błędna odpowiedź kosztuje więcej niż jakikolwiek rachunek za tokeny. Rozliczenia finansowe, kontrole bezpieczeństwa, decyzje architektoniczne i triage medyczny to odpowiednie zastosowania. Jeśli błąd oznacza, że człowiek musi przez godziny prostować ten bałagan, zapłać za dodatkowe myślenie.

Zaskoczenie kosztowe

Oto część, która zburzyła mój model mentalny. Założyłem, że maksymalny wysiłek zawsze spowoduje gwałtowny wzrost kosztów. Przy pojedynczym kroku – tak jest. Ślad rozumowania jest dłuższy. Ale w przypadku wielokrokowych zadań agentowych całkowity rachunek często spadał.

Model lepiej planuje za pierwszym razem. Wykonuje mniej wywołań narzędzi. Sam powstrzymuje się przed błądzeniem w ślepych zaułkach. Obserwowałem agenta do ekstrakcji danych, który normalnie potrzebował pięciu tur wymiany informacji, a skończył w dwóch, ponieważ model miał wystarczająco dużo przestrzeni na rozumowanie, aby poprawnie sparsować schemat na samym początku. Mierząc koszty, patrz na ukończenie zadania, a nie na pojedyncze zapytanie. Większy budżet myślowy na krok może oznaczać mniej kroków w sumie.

Jak przeprowadzić migrację, nie psując wszystkiego innego

Jeśli w Twoim kodzie wciąż krążą budget_tokens, oto dokładna ścieżka wyjścia. Nie pomijaj kroków trzeciego i piątego. Ja to zrobiłem i kosztowało mnie to całe popołudnie debugowania.

Przeszukaj kod w poszukiwaniu budget_tokens. Każdy przypadek musi zostać usunięty. Ten parametr nie istnieje w nowszych modelach i będzie powodował błąd 400.

Zastąp obiekt budżetu blokiem adaptacyjnego myślenia. Użyj thinking: { type: "adaptive" }.

Dodaj output_config z wyraźnym poziomem wysiłku dla każdego wywołania. Nie zostawiaj tego globalnej wartości domyślnej, jeśli Twój ruch jest mieszany. Twój lekki punkt końcowy do klasyfikacji nie powinien przypadkowo dziedziczyć tego samego poziomu wysiłku, co Twój agent do kodowania. Bądź precyzyjny w miejscu wywołania.

Usuń swoją funkcję pomocniczą obliczającą budżet. Wiem. Prawdopodobnie ma testy jednostkowe. Moja też miała. Ale teraz to tylko zbędny balast. Platforma nie potrzebuje Twojej matematyki tokenów. Model sam zarządza swoim tempem.

Usuń temperature, top_p oraz top_k. W modelach Opus 4.7 i 4.8 te parametry próbkowania spowodują błędy 400. Platforma usunęła je w tej generacji. Twoje stare triki związane z dostrajaniem temperatury tutaj nie zadziałają, a pozostawienie ich po cichu zepsuje Twoją migrację.

Testuj każdy model indywidualnie. Opus 4.5 i 4.8 to zupełnie inne byty. Konfiguracja, która działa na jednym, niekoniecznie zadziała na drugim. Jeśli obsługujesz wiele wersji, rozdziel logikę lub traktuj je jako oddzielne backendy.

Naprawa zawieszania się interfejsu (UI)

Istnieje jedno zachowanie strumieniowania, które może zdezorientować użytkowników, jeśli go nie obsłużysz. W nowych modelach bloki myślenia (thinking blocks) są przesyłane strumieniowo, ale tekst domyślnie jest pusty. W Twoim interfejsie wygląda to jak długa, niezręczna przerwa bez widocznego postępu. Użytkownicy uznają, że aplikacja się zawiesiła.

Aby to naprawić, przekaż thinking: { type: "adaptive", display: "summarized" }. Dzięki temu otrzymasz widoczny wskaźnik postępu bez wyrzucania surowego strumienia myśli do okna czatu. Twój frontend pozostanie responsywny, a użytkownicy będą wiedzieć, że „pod maską” coś się dzieje.

Prawdziwa lekcja

Zbudowałem całą warstwę abstrakcji w oparciu o parametr, którego dostawca nigdy nie planował utrzymać na stałe. Obudowałem ich ustawienia własną logiką, ponieważ myślałem, że rozumiem kompromisy lepiej niż platforma. Myliłem się. Adaptive thinking to lepsze rozwiązanie, ponieważ model sam decyduje, kiedy musi intensywnie myśleć, a kiedy może działać bez większego wysiłku. Mój kod źródłowy jest teraz mniejszy. Wyniki stały się trafniejsze. Czasami właściwym ruchem inżynieryjnym jest usunięcie „sprytnego” kodu i pozwolenie platformie na wykonywanie jej pracy.

Jeśli chcesz przeczytać oryginalne notatki dotyczące migracji, znajdziesz je tutaj. Aby wziąć udział w większej liczbie praktycznych dyskusji, dołącz do społeczności GyaanSetu AI na Telegramie.