Zmiana modelu w agencie: od rankingu do własnego testu

Wymiana modelu w działającym agencie wygląda czasem jak zmiana jednego ustawienia. Dla użytkownika skutki mogą być znacznie większe: inny sposób zadawania pytań, więcej wywołań narzędzi albo zmieniona decyzja o przekazaniu sprawy człowiekowi. Porównanie samej końcowej odpowiedzi nie pokaże wszystkich tych różnic.

Ranking modeli AI pomaga wybrać kandydatów, ale nie zastępuje testu na zadaniach i narzędziach naszego agenta. Gdy system już działa, najważniejsze pytanie brzmi: czy nowy model zachowuje potrzebne właściwości obecnej wersji i daje konkretną korzyść? Poniższa procedura dotyczy właśnie takiej zmiany, nie ogólnego wyboru narzędzia na podstawie zestawienia.

Zachowajcie działający punkt odniesienia

Przed porównaniem zapiszcie identyfikator obecnego modelu, instrukcje, definicje narzędzi, ustawienia i wersję dokumentów. Zanotujcie też ograniczenia usługi: dostępny budżet czasu, liczbę kroków oraz zakres działań. Jeżeli równocześnie zmienicie sposób wyszukiwania i treść poleceń, trudniej będzie ustalić, skąd bierze się różnica.

Nie wystarczy zachować kilka poprawnych odpowiedzi. Potrzebny jest zestaw zadań z oczekiwanymi skutkami, dostępny obu wersjom. Wybierzcie zwykłe sprawy oraz sytuacje, które już kiedyś wymagały ręcznej korekty. Zamiast przenosić pełne rozmowy klientów, przygotujcie przykłady zachowujące istotne warunki bez zbędnych danych.

Ustalcie kryteria przed obejrzeniem rezultatów kandydata. Korzyścią może być skrócenie czasu przy niepogorszonej poprawności, a nie dowolna efektowna odpowiedź. Zasady definiowania kryteriów rozwija materiał o mierzeniu jakości agenta AI. Podczas zmiany wersji najważniejsze jest utrzymanie tej samej definicji sukcesu po obu stronach porównania.

Przykład: agent uzgadniający termin odbioru

Rozważmy autorski przykład testowy. Agent odbiera prośbę o zmianę terminu odbioru przesyłki, sprawdza dostępne okna i przygotowuje propozycję. Rezerwacja wymaga potwierdzenia użytkownika. Nie opisujemy rzeczywistego wdrożenia ani zmierzonej poprawy; przykład pokazuje, jak rozpisać próbę porównawczą.

Pierwsze zadanie zawiera kompletną informację i dostępny termin. Drugie nie podaje dnia. W trzecim użytkownik zmienia zdanie po otrzymaniu propozycji. Czwarte symuluje brak odpowiedzi narzędzia po próbie rezerwacji. Każde wymaga innej reakcji, choć wszystkie dotyczą tej samej usługi.

Dla każdego zadania przygotujcie kontrolowany stan narzędzi. Obie wersje powinny widzieć te same dostępne okna, a zapis testowy nie może zmieniać kalendarza prawdziwych klientów. Jeżeli używacie odtworzonych odpowiedzi integracji, zaznaczcie ograniczenie: sprawdzacie zachowanie agenta wobec tych odpowiedzi, a nie niezawodność całej infrastruktury.

Porównujcie ślad wykonania, nie tylko wypowiedź

Odpowiedź „Termin został zmieniony” jest poprawna dopiero wtedy, gdy potwierdza ją stan narzędzia. Oceniający powinien zobaczyć, jak agent doszedł do komunikatu. Nie potrzebuje prywatnego toku rozumowania modelu, lecz zapisu obserwowalnych zdarzeń i danych niezbędnych do ich sprawdzenia.

• Czy agent pobrał aktualne możliwości przed przedstawieniem terminu?
• Czy użył właściwego identyfikatora przesyłki i parametrów okna?
• Czy zaczekał na zgodę dotyczącą tej konkretnej propozycji?
• Czy po niejednoznacznym wyniku sprawdził stan zamiast ponawiać zapis w ciemno?
• Czy zakończył pracę lub przekazał sprawę, gdy brakowało warunków do kontynuacji?

Dopuszczajcie równoważne przebiegi. Dwa odczyty wykonane w innej kolejności nie muszą oznaczać regresji, jeżeli pozostają bezpieczne i prowadzą do tego samego skutku. Jednocześnie dodatkowa operacja zapisująca nie jest tylko różnicą stylu. Musi mieć uzasadnienie w kontrakcie zadania.

Wyniki oznaczajcie według kategorii: poprawne zakończenie, poprawne pytanie, poprawne przekazanie albo błąd. Dzięki temu model, który częściej rezygnuje, nie zostanie automatycznie uznany za lepszy tylko dlatego, że wykonuje mniej ryzykownych działań.

Policzcie czas, koszt i ręczne poprawki

Porównanie kosztu powinno obejmować całe zakończone zadanie. Zapiszcie liczbę wywołań modelu, ponowień i narzędzi oraz czas pracy osoby poprawiającej wynik. Niższa cena pojedynczego wywołania nie musi oznaczać oszczędności, jeżeli agent potrzebuje więcej kroków albo częściej kieruje proste sprawy do operatora.

Czas także warto rozbić na części. Oczekiwanie na integrację jest innym problemem niż długa odpowiedź modelu. Obok typowego przebiegu pokażcie zadania wyraźnie wolniejsze i wskażcie ich przyczynę. Nie ukrywajcie ich w jednej średniej, ale też nie wyciągajcie wniosku o całej usłudze z pojedynczego opóźnienia.

Część prób należy powtórzyć, ponieważ wynik może się zmieniać mimo podobnych warunków. Raport powinien podawać liczbę spraw i powtórzeń oraz sposób oceny. Jeśli próbka jest mała, nazwijcie ją próbą wstępną. Brak wykrytego błędu w kilku zadaniach nie jest dowodem, że ryzyko zniknęło.

Zapiszcie decyzję i warunki powrotu

Na końcu przeglądu odpowiedzcie oddzielnie na trzy pytania: czy zachowano wymagane granice działania, czy poprawiono wybrany miernik i czy nie pojawił się nowy koszt operacyjny. Dobra ocena stylistyczna nie kompensuje rezerwacji bez potwierdzenia. Jeżeli kryteria nie są spełnione, pozostawienie obecnej wersji jest poprawnym wynikiem testu.

W planie zmiany wskażcie osobę podejmującą decyzję, zakres pierwszego uruchomienia i warunek zatrzymania. Zachowajcie poprzednią konfigurację w kontrolowanym źródle wersji. Powrót wymaga jednak również sprawdzenia zgodności narzędzi i obsługi zadań rozpoczętych przez nową wersję; samo przełączenie nazwy modelu może nie wystarczyć.

Praktyczne mechanizmy kontroli opisuje poradnik bezpiecznego wdrożenia agenta. Do dokumentacji zmiany dołączcie krótki zapis: co porównano, które przypadki nie przeszły i kto zaakceptował ograniczenia. Taki ślad przyda się przy kolejnej wymianie znacznie bardziej niż ogólne stwierdzenie, że nowy model wydaje się lepszy.