Bezpieczna wymiana modeli LLM: etykiety ludzkie, metryki krok po kroku, ustawienia wysiłku
Jak przenieść wieloetapową architekturę LLM na nowsze modele bez walki z wyimaginowanymi regresjami: ludzka informacja punktowa, metryki dla każdego etapu, przestarzałe prompty oraz wysiłek analityczny.
Źródła: Migrating off gpt-5: the models were fine, my measurements were not
Zmiana nazwy modelu w pliku konfiguracyjnym wydaje się zadaniem trwającym pięć minut. W wieloetapowym procesie LLM rzadko tak jest, a przyczyną zazwyczaj nie jest sam nowy model – lecz metryka, której używa się do jego oceny. Dzięki realistycznej migracji procesu filtrowania z starszej rodziny modeli zobaczysz, jak stworzyć wiarygodne dane odniesienia, przypisać straty poszczególnym etapom, odróżnić przestarzałe polecenia od modeli słabszych oraz traktować wysiłek analityczny jako ustawienie specyficzne dla danej zadania, a nie ogólną wartość regulowaną globalnie.
Kluczowym czynnikiem wyzwalającym w tym scenariuszu jest wycofanie modeli. OpenAI ogłosiło, że datą wycofania czterech modeli – gpt-5, jego wariantów mini i nano oraz gpt-5-pro – będzie 11 grudnia 2026 roku. To jest aktualny harmonogram w momencie pisania tego tekstu, dlatego prosimy o potwierdzenie informacji na oficjalnej stronie dotyczącej wycofywanych modeli. Wspomniany proces wymagał korzystania z dwóch najmniejszych z tych modeli, więc ich wymiana była konieczna. Rozważano dwie opcje zastąpienia: gpt-5.4 w różnych rozmiarach oraz gpt-5.6-luna. Nazwy modeli, ustawienia domyślne i cenniki zmieniają się szybko, więc prosimy traktować poniższe informacje jako chwilowy obraz sytuacji, a metodę jako element trwały.
Proces, który jest przenoszony
System przetwarza około 2600 artykułów miesięcznie i redukuje je do około 120 kandydatów, które następnie są ręcznie sprawdzane przez człowieka. Ta redukcja nie jest wynikiem jednego polecenia – jest to agent stworzony przy użyciu LangGraph, składający się z około tuzina węzłów w grafie, z których dziesięć to różne wywołania modelu. Trzy z tych wywołań zawierają najważniejsze informacje: brama relewności na wejściu, a następnie dwa klasyfikatory – jeden do określenia typu treści, a drugi tematu. Za nimi znajdują się sprawdzenie nowości, krok oceny i krok streszczania.
Jedna z cech tego projektu wpływa na każdą późniejszą decyzję. Pierwszy węzeł służy do usuwania szumów, a nie oceny jakości, a jego dwa typy błędów mają zupełnie różne konsekwencje:
- Błędne zachowanie polegające na zachowaniu artykułu jest mało kosztowne – silniejszy model później w łańcuchu lub człowiek sprawdzający na końcu to wykryją.
Każda ocena, która traktuje te dwa błędy symetrycznie, wprowadzi cię w błąd co do funkcjonowania procesu przetwarzania.
Konfiguracja, która trafiła do użytkowników
Stan końcowy został celowo nierównowagowy. Dziewięć z dziesięciu wywołań przeniesiono na gpt-5.6-luna, który dotychczas zachowywał się dobrze. Filtr relewantności pozostał przy gpt-5.4-nano; uzasadnienie tej wyjątkowości zajęło większość czasu na badania. Każde wywołanie teraz wyraźnie określa wysiłek potrzebny do rozumowania, zamiast używać domyślnych ustawień modelu, a ta decyzja okazała się ważniejsza niż sama selekcja modelu.
Koszt ograniczył listę kandydatów jeszcze przed oceną jakości, ale nie na podstawie cen katalogowych. Prawie cały ruch jest rozliczany w ramach programu dzielenia się danymi OpenAI, a luna korzysta z tej samej, większej dziennego limitu co najtańsze modele już używane. Rachunek miesięczny pozostaje zatem na poziomie kilku centów w obu przypadkach. Silniejsze modele z tej samej generacji należą do znacznie mniejszego limitu, który zostałby wyczerpany już do południa przy takim obciążeniu, co wykluczało je niezależnie od jakości.
Poniżej przedstawiono cztery niespodzianki, w kolejności ich pojawienia się. Ta sama kolejność jest również przydatną listą kontrolną dla własnej migracji.
Lekcja 1: nie używaj starego modelu jako punktu odniesienia
Pierwsza ocena polegała na porównaniu każdej kandydującej konfiguracji z wynikiem modelu wycofanego z użycia: w jakim stopniu nowe rozwiązanie odtwarza poprzedni rezultat? To porównanie wykazało regresję na poziomie 31 artykułów i doprowadziło do poszukiwań wad modelu, której w rzeczywistości nie było.
W perspektywie czasu problem jest oczywisty. Pierwsza faza procesu generuje kandydatów, z których 40 do 60 procent jest później usuwanych przez ludzkiego recenzenta. Pomiar zgodności z tym wynikiem oznacza pomiar zgodności z filtrem, o którym już wiadomo, że ma średnią jakość. Kandydat jest nagradzany za powtarzanie błędów starego modelu, a karany za ich naprawianie.
Ludzkie decyzje są już zapisanymi prawdami podstawowymi
Znacznie lepszy zestaw etykiet znajdował się w systemie kontroli wersji. Krok przeglądu przez człowieka usuwa pozycje z listy kandydatów, a każde takie usunięcie zostaje zapisane jako komit. W miesiącu przeznaczonym na testy pierwszy przegląd zmniejszył liczbę kandydatów z 122 do 72, a kolejne przeglądy usunęły jeszcze więcej. Porównanie tego komitu z jego poprzednikiem pokazuje dwie oznaczone grupy: artykuły, które dana osoba zachowała, oraz artykuły, które odrzuciła.
Ponowna ocena 31 „utraconych” artykułów w kontekście tych etykiet całkowicie zmieniła obraz sytuacji. Czterdzieści trzy procent z nich to artykuły, które recenzent i tak odrzucił. Według ludzkiego osądu rzeczywista strata wyniosła 15 dobrych artykułów, co stanowi mniej więcej połowę wydawałej się regresji. Co jeszcze lepsze, ponieważ etykiety można powiązać z decyzjami podejmowanymi krok po kroku, pokazują one, który węzeł odpowiada za utratę każdego z tych 15 artykułów. (Te oznaczone dane pochodzą z konfiguracji z gpt-5.4-mini, a nie z wersji Luna, ponieważ eksperyment z Luną został przerwany wcześniej.) Ruch ten był spowodowany jednym węzłem; żaden inny krok nie zmienił liczby artykułów o więcej niż jeden. Lokalizowany problem dotyczący 15 artykułów w jednym zapytaniu jest o wiele łatwiejszy do rozwiązania niż niewyjaśniona utrata 31 artykułów.
Ogólna lekcja: za każdym razem, gdy ktoś wykona ostateczny telefon w twoim systemie, jego połączenie stanowi prawdziwą wartość odniesienia, a zazwyczaj istnieje już jego zapis. Sprawdź kolejki zatwierdzania, wyjątki w moderacji, przeklasyfikowane zgłoszenia obsługi klienta lub zmiany, które ludzie wprowadzają do wygenerowanych szkiców. Istniejący artykuł na temat oceny systemów RAG według etapu awarii przedstawia podobny przykład przypisywania błędów komponentowi, który je spowodował.
Pomiar krok po kroku ujawnia również błędy niespowiązane z migracją. W tym przypadku okazało się, że mechanizm sprawdzania nowości wymyśla nazwy tematów, które nie pojawiają się nigdzie na liście, którą otrzymuje, przy czym dla każdej z 24 odrzuceń używa innej sfabrykowanej nazwy, i robi to zarówno z starymi, jak i nowymi modelami.
Lekcja 2: bardziej rygorystyczny model może poprawnie interpretować twoje polecenie
Gdy straty przypisano filtrowi tematycznemu, kuszącym rozwiązaniem było dostosowanie jego instrukcji, aż nowy model będzie zachowywać się prawidłowo. W tym przypadku takie działanie spowodowałoby poważne szkody, ponieważ silniejszy model znajdujący się niżej w łańcuchu wykorzystuje właśnie te pliki z instrukcjami. Luźniejsze stosowanie reguł, dzięki którym model pierwszego etapu może bez problemów przetwarzać więcej artykułów, osłabia etap odpowiedzialny za dokładną ocenę, a nic z pomiarów przeprowadzonych na pierwszym etapie nie mogłoby tego ujawnić.
Zamiast więc edytować instrukcje, badanie poprosiło model o uzasadnienie swoich decyzji. Dla każdego artykułu odrzuconego przez filtr tematyczny zapisano podany przez gpt-5.4-mini powód – łącznie około dwudziestu takich prób.
Wyjaśnienia były spójne. Wymieniono konkretne zasady i wiernie przytoczono treść promptu. W jednym przypadku model powtórzył niemal słowo w słowo zasadę wykluczającą optymalizację kosztów AI „nawet gdy jest wdrażana przy bramce API” i użył jej do odrzucenia artykułu, który recenzent faktycznie zachował.
Stary gpt-5-mini po prostu nigdy nie egzekwował tej zasady. Po sprawdzeniu okazało się, że dwie z zasad, których ignorował, rzeczywiście były przestarzałe. Jedna nie zawierała wyjątku dla wzorców komunikacji tworzonych wewnątrz aplikacji; druga została napisana przed tym, jak bramki AI stały się infrastrukturą wymagającą opisania. Te dwie zasady zostały poprawione, pozostałe pozostawiono bez zmian, a naprawa trafiła do osobnego commitu, oddzielonego od zmiany modelu, aby można było je ocenić niezależnie.
Tani test, który odróżnia dwa przeciwstawne rozwiązania
To jest test, który należy przeprowadzić najpierw przy każdej migracji. Gdy nowszy model odrzuca więcej elementów na etapie oceny, przyczyną jest często lepsze przestrzeganie instrukcji w konflikcie z promptem, który nie był aktualizowany od roku. Przeczytaj przykłady podanych powodów:
- Gdy wyjaśnienia poprawnie cytują twoje rzeczywiste zasady, oznacza to, że prompt stał się przestarzały, a jego korekta pomaga na każdym etapie, który go używa.
- Gdy model stosuje zasady, które wyraźnie nie pasują do danego elementu, twoje prompt jest poprawne, a winny jest model.
Takie wnioski wskazują w przeciwnych kierunkach, a sama liczba odrzuceń nie pozwala je rozróżnić.
Lekcja 3: surowsza ocena nie oznacza automatycznie gorszej
Brama relewantności przedstawiła podobną historię, ale z innej perspektywy. W tym węźle Luna odrzuciła dwa razy więcej artykułów niż GPT-5.4-Nano. Oczywistym wnioskiem było to, że Luna po prostu gorzej radzi sobie z tym zadaniem, i niemal taką decyzję podjęto.
Jednak brama w rzeczywistości odpowiada na trzy oddzielne pytania: czy materiał jest wystarczająco nowy, czy językiem jest angielski oraz czy temat mieści się w zakresie? Badało się tylko łączną ocenę.
Rozdzielenie oceny na poszczególne elementy okazało się pouczające. Jeśli chodzi o pytanie dotyczące języka, modele dały identyczne wyniki, zaznaczając te same cztery artykuły. Cała różnica pojawiła się przy pytaniu o temat – Luna odrzuciła 64 artykuły, natomiast GPT-5.4-Nano odrzuciło 32.
Czytając uzasadnienia Luny, można dostrzec spójne, w większości uzasadnione oceny: wśród odrzuconych propozycji była biblioteka do zarządzania grupami pracowników w języku Go, platforma do tworzenia agentów głosowych oraz artykuł o migracji baz danych do chmury. Nic nie było uszkodzone. Luna interpretuje pojęcie „głównego priorytetu” w szerszym sensie, niż zamierzał autor zapytania.
To wymaga innego rozwiązania. Uszkodzony mechanizm powinien zostać naprawiony. Lepiej unikać zbyt ścisłej, choć uzasadnionej interpretacji niejasnego zapytania, umieszczonego w jedynym punkcie wejścia, który kieruje wszystko dalej – tam błędy stają się trwałe. Dlatego to konkretne zapytanie pozostało w modelu gpt-5.4-nano. Ogólnie rzecz biorąc, ogólna ocena pokazuje jedynie, że coś się zmieniło. Jeśli jeden krok odpowiada na kilka pytań, należy zapisywać każdą odpowiedź oddzielnie, zanim sformułuje się jakąkolwiek teorię na temat modelu.
Lekcja 4: wysiłek analityczny nie przenosi się między modelami ani zadaniami
Gdy gpt-5.4-nano został wybrany do bramy filtrowej, pozostało pytanie, jak długo powinien się zastanawiać. Modele analityczne posiadają parametr wysiłku, który w przybliżeniu kontroluje stopień wewnętrznych rozważań przed podaniem odpowiedzi. Założeniem było, że ten parametr funkcjonuje jak pokrętło jakości, które zawsze obraca się w taki sam sposób, a każdy model reaguje na nie w swoisty sposób.
Pomiary wykazały dwa zupełnie różne wzorce:
- W bramie filtrowej relewantności zwiększenie poziomu wysiłku niemal podwoiło liczbę odrzuceń przez gpt-5.4-nano, podczas gdy luna w ogóle nie zareagowała na tę ustawienie.
- W filtrze tematycznym ten sam model luna zmienił się o 49 artykułów w zależności od poziomu wysiłku, ale nadal odrzucał artykuły przy najwyższym ustawieniu.
- Gpt-5-nano, który przestał być używany, był najbardziej pobłażliwą konfiguracją ze wszystkich.
Zatem stwierdzenie takie jak „Luna wymaga dużego wysiłku” nie jest faktem, który można wykorzystać wielokrotnie. Dotyczyło ono Luny przy jednym zadaniu i nie miało żadnego znaczenia przy innym. Wysiłek jest właściwością konkretnego modelu w ramach konkretnego zadania, a każda taka para wymaga własnej pomiaru.
Większy model nie zastępuje tego pomiaru. Odrębne testy obejmujące 80 artykułów w celu sprawdzenia bramy relewantności, przy użyciu każdego modelu z umiarkowanym wysiłkiem, przyniosły 31 odrzuceń od GPT-5.4-mini, 34 od Luny oraz 30 od GPT-5.4-nano. Większy model ledwo wpłynął na wynik; całkowite wyłączenie mechanizmu rozumowania w GPT-5.4-nano spowodowało znaczne zmiany.
Wysiłek ma również profil kosztów odmienny od wszystkich innych elementów rachunku, ponieważ może rosnąć bez żadnego sztywnego ograniczenia. Podniesienie filtra tematycznego o jeden poziom wysiłku zaoszczędziło 10 odrzuceń przy mniej więcej trzykrotnie większym zużyciu tokenów – oferta ta została odrzucona.
Czego nie zmierzono
Jasne wskazanie braków jest częścią tej metody.
- Konfiguracja luna wysłana do użycia nigdy nie była oceniana w porównaniu z ludzkimi etykietami; ten proces został przerwany wcześnie. Funkcjonuje ona w środowisku produkcyjnym bez żadnego nieudanego wywołania modelu, co nic nie mówi o utracie jakości.
- Jeden punkt danych wskazuje, że luna radzi sobie gorzej niż gpt-5.4-mini w klasyfikacji typu treści – odrzuca 9 dobrych artykułów, podczas gdy gpt-5.4-mini odrzuciło 5, przy poziomie wysiłku, który nie został zarejestrowany. Jeśli ilość wyjść zmniejszy się, to właśnie ten element należy najpierw sprawdzić.
Szczegóły pomiarów
Zostały użyte dwa zestawy próbek. W eksperymentach typu „effort” wszystkie 198 artykułów z pamięci podręcznej zostało wysłanych bezpośrednio do jednego węzła, więc nic w górnej części łańcucha nie mogło się zmienić. W eksperymentach typu „end-to-end” próbka składająca się z 200 wierszy przeszła przez każdy węzeł; obejmowała ona 72 artykuły zatwierdzone przez ludzi oraz 49 odrzuconych przez nich.
Ocena na podstawie tych ludzkich etykiet:
- Ustawienie „Retired” (gpt-5-mini plus gpt-5-nano): z 72 artykułów zachowano 48 dobrych; 27 z 49 złych przeszło dalej.
- gpt-5.4-mini obsługujący węzły oceny, z zastosowanymi poprawkami do promptu: z 72 zachowano 33; 18 z 49 przeszło dalej.
- Konfiguracja „Shipped” (luna w dziewięciu z dziesięciu prób): jeszcze nie oceniona względem żadnego z zestawów.
Ostatnia pozycja pozostaje pusta do czasu miesięcznej oceny, ponieważ etykiety powstają dopiero po zatwierdzeniu zmiany „prune”, a we wrześniu nie dokonano żadnych usunięć w momencie analizy.
Wczesny sygnał produkcji
Dane dotyczące produkcji stanowią częściowe zamiennik. Luna została uruchomiona 30 sierpnia. Stosunki włączeń w porównywalnych oknach czasowych wyglądają następująco:
- Poprzednie modele w okresie od 1 do 29 sierpnia: 4,55 procenta (121 włączonych na 2 658).
- Poprzednie modele w ostatnich ośmiu dniach przed zmianą: 4,86 procenta (32 na 658).
- Luna od 30 sierpnia do 6 września: 4,08 procenta (26 na 638).
Porównanie dwóch dopasowanych okien o długości osiem dni za pomocą testu z dwiema proporcjami daje wynik 0,69, który znajduje się w pełni w granicach normalnych fluktuacji. Dla porównania, poprzednia konfiguracja wykazywała wartość 3,98 procenta w pierwszych ośmiu dniach sierpnia – co stanowi większą zmienność w jej własnej historii niż ta spowodowana wprowadzeniem luna. Tydzień i jeden dzień to krótki okres, a wskaźnik zaangażowania nie mierzy jakości, ale najbardziej obawiany scenariusz, w którym luna po cichu powoduje problemy w procesie, nie wystąpił.
W okresie działania systemu Luna powstał również pierwszy szczegółowy podział odrzuceń według poszczególnych węzłów. W tym czasie Luna odrzuciła 603 artykuły. Z tego 42 procent stanowił filtr relewantności, 38 procent filtr typu treści, 16 procent filtr tematyczny, a 3 procent sprawdzanie nowości. Natomiast w poprzednim ustawieniu w okresie od 1 do 29 sierpnia odrzucono 2 526 artykułów, nie zapisując przy tym żadnego powodu, więc odtworzenie danych z sierpnia wymagało ponownego przetworzenia artykułów, zamiast prostego zapytania do danych produkcyjnych. Jeśli waszy proces nie rejestruje dziś powodów odrzuceń na poziomie poszczególnych kroków, ich dodanie to najtańsza poprawka, jaką możecie wprowadzić przed migracją.
Ograniczenia danych rzeczywistych i pojedynczego przebiegu
Etykiety ludzkie mają dwa wbudowane ograniczenia. Obejmują one jedynie artykuły, które przeszły przez stary proces, więc nowa konfiguracja nigdy nie może otrzymać uznania za uratowanie czegoś, co stara błędnie odrzuciła. Ponadto w próbie składającej się z 200 wierszy około 79 nie ma żadnego werdyktu ludzkiego.
Różnica pomiędzy kolejnymi wykonyaniami jest duża. Trzy powtórzone próby przy niezmienionej konfiguracji na identycznych 200 wierszach dały wskaźniki odrzucenia wynoszące 37, 48 i 55 procent w jednym węźle, co stanowi znacznie większą rozbieżność, niż mogłaby wyjaśnić szum próbkowania. Powtórzenie pełnego procesu od początku do końca przy tej samej konfiguracji doprowadziło do powstania czterech nowych pozycji oraz utraty czterech innych. Ponowne uruchomienie tej konfiguracji na podstawie produktów, które sama wytworzyła w produkcji, pozwoliło odzyskać jedynie 75 z 121 oznaczonych artykułów, więc zgadzała się ze swoją własną historią tylko w około 62 procentach przypadków. W praktyce jeden proces może rozróżnić różnice na poziomie około 20 punktów w jednym węźle lub około ośmiu pozycji w całym łańcuchu przetwarzania.
Lepszym podejściem do weryfikacji poszczególnych zmian jest sprawdzanie każdej z nich dokładnie w tych elementach, które ma naprawić, a także w małej, niezmiennej grupie elementów, które powinna pozostawić nietkniętymi, polegając jednocześnie na szerokim testowaniu wyłącznie jako ogólnej sygnalizacji dużych skutków ubocznych. Jeden przykład szybkiej korekty pokazał dlaczego – przesunął cztery docelowe artykuły poza węzeł, który naprawił, ale prawie nie zmienił ostatecznego wyniku, ponieważ trzy z tych czterech zostały później odrzucone z powodów niezwiązanych z tą korektą.
Gdzie faktycznie trafiają tokeny
Rozumowanie zużywa tokeny przeznaczone na wynik, ale to nie wynik jest tym, co zużywa cały limit. Wcześniejsze modele generowały 13 procent wszystkich tokenów w postaci wyniku, podczas gdy nowe modele – mniej niż 3 procent; ponieważ prompty są długie, dominuje treść wejściowa.
W momencie pisania tego tekstu program wymiany danych oferuje dwa dziienne limity. Większy, wynoszący 2,5 miliona tokenów dziennie, dotyczy modelu Luna oraz wersji nano i mini modelu GPT-5.4. Mniejszy, wynoszący 250 tysięcy tokenów dziennie, odnosi się do modeli średniej i większej wielkości. W zwykły dzień roboczy system zużywał około 1,95 miliona tokenów przy użyciu poprzednich modeli oraz około 1,15 miliona tokenów przy użyciu nowych modeli. Eksportowany miesiąc danych, składający się głównie ze starych ustawień plus ośmiu dni nowych, kosztowałby około 4 dolarów według elastycznych stawek, bez żadnych ulg.
W przypadku tysiąca zapytań różnice pomiędzy modelami są znaczne:
- gpt-5-nano: 0,32 dolara
- gpt-5.4-nano: 0,52 dolara
- gpt-5.6-luna: 0,65 dolara
- gpt-5-mini: 1,49 dolara
- gpt-5.4-mini: 3,29 dolara (mała próbka)
Luna nie wygrywa pod względem ceny za zapytanie, a to jest do przyjęcia. Kosztuje znacznie mniej za zapytanie niż żaden z modeli mini i korzysta z tego samego źródła co modele nano.
Dodatkowa opłata za zapisy do pamięci cache
Lista cen ukrywa jeden szczegół, który warto uważnie przeczytać. Wśród rozpatrywanych modeli tylko Luna nalicza opłatę za zapisy do pamięci cache, przy czym cena jest o 25 procent wyższa niż za zwykły, niezapisany wprowadzony tekst. Ponieważ zapytania przychodzą tu stopniowo w ciągu całego dnia, a nie skupiają się w określonych momentach, wpisy do pamięci cache wygasają między zapytaniami: 57 procent wprowadzonych tekstów przez Lunę zostało opłaconych jako zapisy do pamięci cache, a tylko 41 procent jako odczyty z niej. Wykorzystanie pamięci cache nadal przynosi korzyści, zmniejszając koszt wprowadzanych tekstów o 23 procent w porównaniu z sytuacją bez jej wykorzystania, ale to daleko od 90 procent oszczędności, które sugeruje zniżka za odczyty. Jeśli Twoja praca jest nieregularna, zobaczysz większą zniżkę; jeśli natomiast przychodzi stopniowo, musisz uwzględnić dodatkową opłatę za zapisy.
Pułapki API, które powodują niepowodzenie każdej żądania
Pewne zachowania parametrów mogą przekształcić proste przemianowanie modelu w awarię. Jak donoszono w momencie pisania tego tekstu (sprawdź aktualną dokumentację):
- Standardowy poziom wysiłku obliczeniowego nie jest spójny pomiędzy różnymi wersjami modeli: średni dla gpt-5, brak takiego poziomu w rodzinie 5.4, a ponownie średni dla 5.6. Dlatego samo przemianowanie modelu w tajemnicy zmienia sposób, w jaki każde żądanie przeprowadza obliczenia.
- Najwyższy poziom wysiłku jest dostępny tylko w modelach 5.6; próba użycia go w modelu 5.4 powoduje niepowodzenie każdego żądania.
- W punkcie końcowym do uzupełniania wiadomości w czacie każdy poziom wysiłku wyższy niż brak jest odrzucany, jeśli używane są narzędzia funkcjonalne; takie żądania muszą być kierowane do punktu końcowego odpowiedzi. Ponieważ domyślnym ustawieniem LUNY jest poziom średni, korzystanie z narzędzi w kontekście uzupełniania wiadomości jest niemożliwe, chyba że poziom wysiłku zostanie wyraźnie obniżony.
Żadne z nich nie może zostać odzyskane w czasie wykonywania. Typowa logika ponawiania prób radzi sobie z błędami serwera, przekroczeniami czasowymi i ograniczeniami szybkości, a nie z nieważnymi żądaniami, dlatego nieodpowiednia kombinacja modelu i wysiłku powoduje awarię przy każdym wierszu procesu zamiast tylko raz. Sprawdź kombinację modelu i wysiłku podczas uruchamiania procesu, zanim zostanie obsłużony pierwszy wiersz. Aby dowiedzieć się więcej na temat tych dwóch punktów końcowych, przeczytaj istniejący artykuł na temat przedmiotów w porównaniu z wiadomościami w API odpowiedzi OpenAI.
Główne wnioski
- Nigdy nie oceniaj modelu zastępczego na podstawie jego zgodności z modelem, który zastępuje; używaj udokumentowanych decyzji ludzkich jako prawdy obiektywnej.
- Przypisz każdą stratę do konkretnego kroku w procesie i podziel kroki zawierające wiele pytań na oddzielne, zapisane werdykty.
Literatura pokrewna
- Doskonałe dostosowanie LLM: routowanie, pobieranie i ocena bez uwzględniania wielkości surowego modelu — Dowiedz się, jak wybierać między małymi a dużymi modelami językowymi w zależności od obciążenia pracy, mierzyć koszt za pomyślnie wykonane zadanie oraz najpierw wykorzystywać routowanie, RAG, cache i walidację.
- Ocena LLM bez zależności z sędzią, któremu naprawdę można ufać — Stwórz prostą metodę oceny LLM na podstawie rzeczywistych logów, sprawdzeń kodu oraz sędziego opartego na jednym kryterium, a następnie dostosuj tego sędziego do ludzkich ocen, aby jego wyniki miały znaczenie.