Zmiana podstawowego modelu AI bez spadku jakości: Evals, Canary i Rollback

Nowy model podstawowy AI często obiecuje lepsze odpowiedzi, niższe koszty lub krótszy czas reakcji. W przypadku produkcyjnego chatbota na stronie internetowej zmiana ta nie jest jednak zwykłą wymianą dowolnego pakietu oprogramowania. Już nowa wersja modelu może inaczej ważyć instrukcje, formułować bardziej szczegółowe odpowiedzi, generować odmienne dane strukturalne czy wywoływać narzędzia w innej kolejności. Dlatego migracja kończy się sukcesem dopiero wtedy, gdy chatbot realizuje swoje zadania co najmniej tak niezawodnie jak dotychczas – a zespół w razie problemów potrafi przywrócić poprzednią wersję w kilka minut.

Dostawcy regularnie wycofują starsze modele. Dokumentacja OpenAI dotycząca wycofywanych modeli zawiera daty wyłączenia oraz zalecane zamienniki; z kolei Anthropic w opisie cyklu życia modeli rozróżnia statusy „Active”, „Legacy”, „Deprecated” i „Retired”. Tego typu terminy są powodem do migracji, ale nie stanowią dowodu jej jakości. Dowód ten dostarcza jedynie proces testowania i wdrażania dostosowany do specyfiki własnego chatbota.

Co tak naprawdę zmienia się przy zmianie modelu podstawowego

Proces ten należy wyraźnie odróżnić od migracji modelu embeddingów. W przypadku zmiany modeli embeddingów konieczne jest ponowne zwektoryzowanie dokumentów i zadbanie o kompatybilność indeksów wyszukiwania. Podczas zmiany modelu podstawowego indeks wyszukiwania (retrieval) zazwyczaj pozostaje bez zmian; zmienia się natomiast model, który na podstawie instrukcji systemowej, przebiegu rozmowy, znalezionych źródeł i wyników narzędzi generuje odpowiedź. Testom podlega więc zachowanie podczas odpowiadania, spójność ze źródłami, format danych, wykorzystanie narzędzi, bezpieczeństwo, opóźnienia (latency) oraz koszty.

Również ogólny test w trybie Shadow przed uruchomieniem na stronie rozwiązuje tylko część zadania. Ruch typu Shadow może zasilać dwa modele tymi samymi danymi wejściowymi bez dostarczania nowej odpowiedzi do użytkownika. Opisana tutaj zmiana modelu podstawowego idzie o krok dalej: definiuje z góry macierz odbioru, kieruje niewielką część prawdziwego ruchu do kandydata, monitoruje sygnały użytkowników oraz systemu i posiada przetestowany mechanizm szybkiego wycofania zmian.

Przed testem: ustal jednoznaczną umowę migracyjną

Porównania są bezwartościowe, jeśli w międzyczasie zmienia się wiele czynników jednocześnie. W pierwszej rundzie zachowaj zatem spójne i niezmienne: prompt systemowy, konfigurację wyszukiwania (retrieval), schematy narzędzi, temperaturę, maksymalną długość odpowiedzi oraz reguły bezpieczeństwa, a nieuniknione zmiany parametrów (np. nieobsługiwane opcje samplingu) dokładnie udokumentuj. Udokumentuj dotychczasowy model jako bazę, a nowy model jako kandydata. W miarę możliwości używaj jawnych i jednoznacznych wersji modeli zamiast zmiennych aliasów. Alias może w przyszłości wskazywać na inny migawkowy stan (snapshot), zaburzając odtwarzalność porównania.

Umowa migracyjna określa również grupy użytkowników i funkcje, które na początku zostają wyłączone z testów. Na przykład chatbot FAQ może wcześnie trafić do wdrożenia typu Canary, podczas gdy operacje zapisu zamówień, zapytania o umowy czy szczególnie wrażliwe zgłoszenia wsparcia pozostają dłużej na modelu bazowym. W ten sposób ogranicza się ryzyko w oparciu o wpływ biznesowy, a nie tylko złożoność techniczną.

Zestaw testowy musi odzwierciedlać realny ruch

Zestaw referencyjny (Golden Set) nie powinien zawierać wyłącznie idealnych pytań standardowych. Zbierz zanonimizowane lub syntetycznie odwzorowane przypadki z najważniejszych intencji: jednoznaczne pytania, wieloznaczne sformułowania, pytania pogłębiające, brakujące dokumenty, sprzeczne źródła, błędy narzędzi oraz zapytania, które wymagają przekazania do konsultanta. Podziel przypadki według języka, urządzenia, typu klienta i klasy ryzyka. Dzięki temu zobaczysz, czy wysoka ocena ogólna nie przysłania problemów w małych, ale krytycznych dla biznesu podgrupach.

Oficjalne wytyczne Anthropic dotyczące kryteriów sukcesu i Evals zalecają stosowanie specyficznych, mierzalnych i dostosowanych do konkretnego zastosowania kryteriów oraz realistycznych przypadków brzegowych. Również przewodnik OpenAI po Evals opisuje testy – szczególnie podczas aktualizacji lub próbowania nowych modeli – jako kluczowy element niezawodnych aplikacji. Ponieważ OpenAI na tej samej stronie ogłasza wycofanie swojej dotychczasowej platformy Evals, własny zestaw Golden Set warto przechowywać w przenośnym formacie, niezależnym od pojedynczego panelu czy narzędzia.

Macierz ocen zamiast pojedynczej średniej

Poniższe wartości progowe stanowią jedynie przykład, a nie uniwersalną normę. Ustal je na podstawie dotychczasowej wydajności w środowisku produkcyjnym oraz kosztów potencjalnego błędu. Kandydat nie może rekompensować niższej ceny tokenów słabszym zakotwiczeniem w źródłach.

Automatyczne testy doskonale sprawdzają się w przypadku schematów JSON, wymaganych sformułowań, docelowych adresów URL, argumentów narzędzi i deterministycznych reguł biznesowych. Do oceny tonu, kompletności i użyteczności wyjaśnień potrzebna jest dodatkowo jasna rubryka oceniania; wyrywkowe kontrole przeprowadzane przez ekspertów pozwalają skalibrować ewaluator oparty na LLM. Wyniki należy zapisywać w rozbiciu na intencje i klasy ryzyka, a nie tylko w postaci pojedynczego ogólnego wyniku. Jak w praktyce zbudować taki zestaw, wyjaśnia również nasz przewodnik po jakości odpowiedzi z Golden Set.

Konkretny przykład: Zmiana modelu we wsparciu B2B

Załóżmy, że dostawca oprogramowania B2B obsługuje chatbota do pytań o produkty, zarządzania kontem i przygotowywania zgłoszeń do działu wsparcia. Zespół tworzy 240 przypadków testowych: 120 częstych pytań o wiedzę, 40 wieloznacznych pytań pogłębiających, 30 przypadków z brakiem źródła, 25 symulacji narzędzi oraz 25 przypadków dotyczących bezpieczeństwa i przekazania do konsultanta. Oba modele otrzymują dokładnie te same prompty, trafienia z dokumentów oraz symulowane wyniki narzędzi.

Kandydat odpowiada na standardowe pytania szybciej i taniej, ale w pięciu pytaniach pogłębiających traci kontekst poprzedniej wiadomości. Mimo to ogólna ocena byłaby wyższa. Jednak analiza segmentowa ujawnia wyraźny spadek jakości. Zespół nie tworzy sztucznych wyjątków, lecz precyzuje regułę konwersacyjną, rozbudowuje zestaw testowy o podobne przypadki i ponownie testuje oba modele. Dopiero gdy kandydat spełni wszystkie twarde wymagania (gates), rozpoczyna się produkcyjne wdrożenie Canary.

Na początku dwa procent odpowiednich nowych rozmów trafia do kandydata. Przypisanie następuje na początku konwersacji, na przykład na podstawie hasha Conversation ID, i jest utrwalane na cały czas trwania dialogu; wyższe poziomy Canary dotyczą wyłącznie nowych rozmów. Wywołania narzędzi wykonujących zapis oraz intencje wysokiego ryzyka pozostają początkowo na modelu bazowym. Po odpowiednio długim oknie obserwacji udział wzrasta do 10, 25, 50 i ostatecznie 100 procent – ale tylko wtedy, gdy każda bramka jakościowa pozostaje zielona. Poziomy i minimalne wielkości prób ustalane są z góry, aby presja czasu nie osłabiła przyjętych reguł.

Sygnały online, które naprawdę się liczą

Podczas Canary błędy HTTP i średnie opóźnienie nie wystarczą. Monitoruj wskaźnik braku odpowiedzi (No-Answer), porzucenia po pierwszej odpowiedzi, ponowne pytania, wskaźnik przekazania do człowieka (Handoff), kliknięcia w źródła, błędy schematów oraz przerwane wywołania narzędzi – oddzielnie dla modelu bazowego i kandydata. Wspólne śledzenie (trace) łączy wersję modelu, wersję promptu, trafienia w wyszukiwaniu oraz kroki narzędzi, bez zbędnego zapisywania danych osobowych. Nasz artykuł na temat observability chatbotów szczegółowo wyjaśnia tę ścieżkę audytu.

Porównuj również koszt na pomyślnie rozwiązany przypadek, a nie tylko koszt miliona tokenów. Tańszy model, który częściej wymaga dopytywania lub pracy człowieka, w ostatecznym rozrachunku operacyjnym może okazać się droższy. I odwrotnie: niewielki wzrost opóźnienia może być akceptowalny, jeśli w ważnej klasie ryzyka przynosi odczuwalnie dokładniejsze odpowiedzi.

Rollback to funkcja, a nie dokument

Ścieżka powrotu musi zostać przetestowana technicznie przed uruchomieniem pierwszego etapu Canary. ID modelu i powiązane parametry powinny znajdować się w wersjonowanej konfiguracji lub być kontrolowane przez Feature Flag. Dopóki dostawca wspiera dotychczasową wersję, pozostaje ona dostępna jako cel powrotny podczas wdrożenia Canary; przed datą jej wyłączenia wymagany jest dodatkowo obsługiwany cel awaryjny (fallback). Istniejące rozmowy powinny spójnie pozostawać na swoim pierwotnym modelu lub przełączać się według wyraźnie przetestowanej reguły.

Zdefiniuj twarde wyzwalacze rollbacku: na przykład błąd schematu przy akcji zapisu, pogorszenie jakości w intencji związanej z bezpieczeństwem, gwałtowny skok wskaźnika błędów lub przekroczenie budżetu opóźnienia. W przypadku wystąpienia takiego sygnału przełączenie następuje automatycznie lub przez wyznaczoną osobę na dyżurze. Po przełączeniu logi, wersja kandydata oraz dotknięta próbka pozostają zachowane w celu analizy przyczyny. Przygotowany i przetestowany proces jest znacznie bardziej niezawodny niż spontaniczne wdrażanie kodu na produkcji; dodatkowo pomaga pełny Incident Response Playbook.

Lista kontrolna do zatwierdzenia wdrożenia

• Zapisz datę wyłączenia, model zamienny i dotknięte punkty końcowe z oficjalnej dokumentacji dostawcy.
• Zamroź model bazowy i kandydata z niezmienioną konfiguracją promptów, wyszukiwania i narzędzi.
• Podziel Golden Set według intencji, języka i klasy ryzyka; dodaj przypadki brzegowe i autentyczne błędy.
• Zdefiniuj twarde bramki dla zakotwiczenia w źródłach, struktury odpowiedzi, narzędzi, bezpieczeństwa i przekazania do człowieka.
• Zmierz opóźnienie, wskaźnik błędów, tokeny i koszt na rozwiązany przypadek.
• Zapewnij stabilne przypisanie Canary dla całych rozmów i wyklucz na początku funkcje wrażliwe.
• Udokumentuj etapy, minimalną próbkę, czas obserwacji i progi przerwania przed rozpoczęciem wdrażania.
• Przetestuj technicznie wycofanie zmian (rollback), wyznacz osoby odpowiedzialne i utrzymuj wspierany cel awaryjny.
• Po osiągnięciu 100% kontynuuj obserwację i rozbudowuj Golden Set o nowe przypadki produkcyjne.

Podsumowanie: Nazwa modelu to dopiero początek

Kontrolowana zmiana modelu podstawowego łączy jakość produktu z bezpieczeństwem operacyjnym. Oficjalne informacje o cyklu życia wyznaczają terminy, testy Evals dostarczają dowodów przydatności, ruch Canary ogranicza wpływ nieznanych błędów, a przetestowany Rollback skraca czas reakcji. Każdy, kto wdroży te cztery elementy jako powtarzalny proces, może korzystać z nowych modeli bez zamieniania swojego chatbota w poligon doświadczalny dla wszystkich użytkowników.

Chcesz ustrukturyzować planowanie wersji modeli, bramek jakościowych i wdrożeń dla swojego chatbota? ChatReact pomaga skonfigurować bazę wiedzy, zachowanie odpowiedzi oraz przekazywanie zadań tak, aby wszelkie zmiany pozostały mierzalne i w pełni kontrolowane.