Ocena jakości asystenta AI po wdrożeniu: jak rozpoznać pogorszenie?

Asystent AI przez kilka miesięcy pomagał pracownikom znaleźć odpowiedzi w firmowej dokumentacji. Potem pojawiły się sygnały, że częściej pomija ważne warunki albo powołuje się na starszą wersję instrukcji. Model mógł się zmienić, ale przyczyna może też leżeć w dokumentach, wyszukiwaniu lub uprawnieniach. Bez wcześniejszych przykładów i sposobu oceny trudno ustalić, co właściwie się pogorszyło.

Ocena jakości po wdrożeniu polega na regularnym sprawdzaniu, czy asystent nadal pomaga wykonać uzgodnione zadania. Potrzebuje pytań kontrolnych, wiarygodnych źródeł, kryteriów oceny i osoby odpowiedzialnej za reakcję. Liczba rozmów ani brak zgłoszonych błędów nie wystarczą, by stwierdzić, że odpowiedzi są poprawne.

Jeśli planujesz taki system lub chcesz uporządkować jego ocenę, wyślij brief z opisem odbiorców, zadań asystenta i przykładami odpowiedzi, które wymagają kontroli. Przed wysłaniem usuń hasła oraz dane klientów. Możesz opisać sytuację na wymyślonym przykładzie, zachowując rodzaj problemu i oczekiwane zachowanie.

Ustal, co znaczy dobra odpowiedź

Wyobraźmy sobie asystenta, który pomaga pracownikom działu obsługi znaleźć zasady przyjmowania zwrotów. Dobra odpowiedź powinna odnosić się do właściwej wersji instrukcji, wyjaśnić warunki i wskazać źródło. Jeżeli brakuje informacji potrzebnej do decyzji, powinna o tym powiedzieć. To przykład projektowy, nie opis zrealizowanego wdrożenia ani uniwersalnej polityki zwrotów.

Dla innego asystenta kryteria będą inne. Narzędzie przygotowujące roboczą notatkę ze spotkania może wymagać oddzielenia ustaleń od pytań otwartych. System wspierający serwis powinien poprawnie wskazać urządzenie i nie wymyślać brakującej instrukcji. Zanim zaczniecie liczyć wyniki, zapiszcie kilka zadań i oczekiwany rezultat dla każdego z nich.

Nie każda dobra odpowiedź musi mieć identyczne brzmienie. Warto oceniać, czy zawiera istotne informacje, nie dopisuje niepotwierdzonych warunków i prowadzi do właściwego źródła. Jeśli tekst dotyczy decyzji pracownika, sprawdźcie również, czy pozwala mu zauważyć ograniczenia. Kryteria powinny być na tyle konkretne, aby dwie osoby mogły omówić przyczynę różnej oceny.

O projektowaniu asystenta, który pokazuje pochodzenie odpowiedzi, piszemy w artykule o asystencie AI do firmowej wiedzy. Po uruchomieniu trzeba dodatkowo sprawdzać, czy wskazane źródło nadal jest właściwe, a użytkownik ma prawo z niego korzystać.

Zbuduj zestaw pytań, który przypomina prawdziwą pracę

Zestaw kontrolny powinien obejmować pytania częste, trudniejsze i takie, przy których wcześniejsza wersja systemu się myliła. Możecie zacząć od spraw zgłaszanych przez pracowników, pod warunkiem odpowiedniego ograniczenia dostępu i usunięcia zbędnych danych. Przy każdym pytaniu zapiszcie, czego oczekujecie, z jakiego źródła wynika odpowiedź oraz kto potwierdził wzorzec.

Uwzględnijcie również pytania bez odpowiedzi w dostępnych materiałach. Asystent powinien wtedy wskazać brak informacji, poprosić o doprecyzowanie albo skierować sprawę do właściwej osoby, zależnie od procesu. Ocena powinna sprawdzić także odmowy: czy system słusznie odmawia dostępu do cudzego dokumentu i czy nie odrzuca bez powodu zadania, które użytkownik ma prawo wykonać.

Dodajcie przypadki niejednoznaczne. Pytanie o „termin realizacji” może dotyczyć obietnicy dla klienta, planu wewnętrznego albo faktycznej daty wykonania. Jeżeli źródła różnią się zakresem lub aktualnością, wynik powinien uwzględnić tę różnicę. Zadaniem zestawu nie jest wyłącznie sprawdzenie, czy model pamięta odpowiedź na znane pytanie, lecz wykrycie sytuacji, w których proces wymaga rozpoznania kontekstu.

Dokumentacja OpenAI dotycząca dobrych praktyk oceny zaleca budowanie ocen związanych z konkretnym zadaniem oraz ich ciągłe rozwijanie. To wskazówka dotycząca projektowania testów, a nie gwarancja jakości dowolnego asystenta. Zestaw trzeba dopasować do źródeł, użytkowników i skutków błędu w danej organizacji.

Sposób przygotowania przykładów przed startem opisujemy w artykule jak testować asystenta AI. Po wdrożeniu warto zachować część tych samych pytań do porównań, a jednocześnie dopisywać nowe sytuacje napotykane przez zespół. Stary zestaw daje punkt odniesienia; nowe przykłady pokazują, jak zmienia się rzeczywista praca.

Sprawdzaj źródło, nie tylko brzmienie

Odpowiedź może brzmieć przekonująco i jednocześnie opierać się na nieaktualnym dokumencie. Dla każdego pytania kontrolnego ustalcie, która wersja materiału jest źródłem prawdy, kto ją utrzymuje i kiedy należy zweryfikować zapisany wzorzec. Jeżeli firma zmieniła procedurę, dawniej poprawna odpowiedź może stać się błędna bez żadnej zmiany modelu.

Przy ocenie źródła przyjrzyjcie się całej drodze informacji. Czy dokument został poprawnie pobrany? Czy wyszukiwarka wybrała właściwy fragment? Czy użytkownik ma do niego dostęp? Czy asystent wiernie oddał jego znaczenie? Rozdzielenie etapów pomaga uniknąć sytuacji, w której zespół zmienia model, choć problemem jest nieodświeżona baza dokumentów.

W przypadku odpowiedzi z kilku źródeł sprawdźcie, czy system nie łączy zasad obowiązujących różne grupy klientów lub różne okresy. Jeśli instrukcje są sprzeczne, potrzebna może być decyzja właściciela procesu, a nie wybór bardziej przekonująco brzmiącego zdania. O ustalaniu odpowiedzialności za informacje piszemy w tekście o porządku w danych przed wdrożeniem AI.

Uprawnienia również mogą się zmienić po uruchomieniu. Testujcie dostęp jako osoby o różnych rolach, a nie wyłącznie jako administrator. Jeżeli pracownik stracił dostęp do dokumentu, odpowiedź asystenta nie powinna nadal ujawniać jego treści. Szczegóły tego problemu opisujemy w artykule o uprawnieniach do dokumentów w systemie RAG.

Porównuj wyniki po zmianach

Wynik testu powinien być powiązany z wersją konfiguracji: modelem, instrukcjami, sposobem wyszukiwania, źródłami i narzędziami użytymi podczas próby. Dzięki temu po zmianie jednego z elementów możecie porównać odpowiedzi dla tego samego zestawu. Nie trzeba zakładać, że każda różnica oznacza pogorszenie. Ważne jest, czy zmiana wpływa na kryteria przyjęte dla danego zadania.

Warto zaplanować sprawdzenie przed zmianą i po niej. Jeżeli nowa wersja odpowiada lepiej na pytania ogólne, ale pomija ograniczenie ważne w sprawach reklamacyjnych, średni wynik może ukryć problem. Dlatego obok wyniku zbiorczego oglądajcie osobno istotne grupy przypadków oraz pojedyncze błędy o dużych konsekwencjach. Wybór miar zależy od sposobu użycia systemu.

Nie wszystkie odpowiedzi da się ocenić jedną automatyczną regułą. Sprawdzenie, czy wskazano istniejący dokument, jest innym zadaniem niż ocena, czy odpowiedź poprawnie wyjaśnia wyjątek od procedury. Można łączyć kontrole techniczne z przeglądem przez osobę znającą temat. Ważne, aby oceniający wiedzieli, na jakiej podstawie podejmują decyzję i jak zapisywać rozbieżności.

Jeśli do oceny wykorzystujecie kolejny model, potraktujcie jego wynik jako element procesu, który także wymaga sprawdzenia. Przetestujcie go na przykładach ocenionych przez ludzi i obejrzyjcie przypadki, w których opinie się różnią. Automatyczna ocena może przyspieszyć przegląd, lecz nie powinna sama ustanawiać prawdy o procedurze obowiązującej w firmie.

Zbieraj sygnały z codziennej pracy

Pracownicy mogą zauważyć problem wcześniej niż okresowy test, pod warunkiem że wiedzą, jak go zgłosić. Prosty sygnał „ta odpowiedź wymaga poprawy” powinien prowadzić do miejsca, w którym osoba odpowiedzialna potrafi odtworzyć sprawę. Przydatne są identyfikator rozmowy, rodzaj problemu i możliwość opisania oczekiwanego wyniku. Zakres zapisu trzeba dopasować do zasad ochrony danych oraz uprawnień.

Nie każda negatywna ocena oznacza ten sam problem. Użytkownik może nie zgadzać się z odpowiedzią, nie rozumieć komunikatu albo oczekiwać czynności, do której asystent nie ma uprawnień. Przegląd powinien rozróżniać błąd informacji, brak źródła, niewłaściwą odmowę i kłopot z interfejsem. Dopiero wtedy zespół może wybrać poprawkę, która odpowiada na rzeczywistą przyczynę.

Warto obserwować również opóźnienia, błędy integracji i sprawy przekazane do człowieka. Te sygnały nie mówią bezpośrednio, czy odpowiedź jest prawdziwa, ale mogą wskazywać problem w drodze do źródła. O wyborze sygnałów i reakcji na zatrzymany proces piszemy w artykule o monitorowaniu automatyzacji.

Ustalcie, kto przegląda zgłoszenia i jak często. Kolejka uwag bez właściciela szybko staje się archiwum dobrych intencji. Osoba odpowiedzialna powinna móc połączyć powtarzające się sygnały, zapytać właściciela dokumentu o aktualną zasadę i dodać potwierdzony przypadek do zestawu testowego. Przy większym zespole warto określić również zastępstwo na czas nieobecności.

Co zrobić, gdy jakość spada

Najpierw ograniczcie skutki. W zależności od procesu można oznaczyć odpowiedzi jako wymagające sprawdzenia, wyłączyć jedną funkcję albo czasowo skierować sprawy do pracowników. Decyzja powinna wynikać z wcześniej ustalonych konsekwencji błędu i możliwości obsługi ręcznej. Jeśli asystent podaje nieaktualną instrukcję dotyczącą konkretnego procesu, nie zawsze trzeba wyłączać wszystkie pozostałe zadania. Sposób przekazania spraw i przywrócenia procesu opisujemy w tekście o planie awaryjnym automatyzacji AI.

Następnie odtwórzcie przypadek i sprawdźcie ostatnie zmiany w źródłach, wyszukiwaniu, konfiguracji oraz uprawnieniach. Porównajcie wynik z wcześniejszymi próbami, jeśli zostały zapisane w odpowiedni sposób. Po poprawce uruchomcie zarówno test problematycznej sytuacji, jak i powiązane przypadki. Jedna naprawiona odpowiedź nie dowodzi jeszcze, że zmiana nie pogorszyła pozostałych.

Dobrze zaplanować również przegląd pytań, które przez długi czas nie wykrywały żadnych problemów. Część z nich nadal jest potrzebna jako punkt odniesienia, lecz inne mogły stracić związek z aktualną pracą. Nie usuwajcie ich automatycznie tylko dlatego, że system dobrze sobie radzi. Najpierw ustalcie, czy dotyczą ważnego ryzyka i czy nie sprawdzają jedynego przykładu szczególnej sytuacji.

Gdy zespół zmienia wzorzec odpowiedzi, zachowajcie informację o powodzie tej zmiany. Nowa procedura, sprostowanie dokumentu i poprawienie błędnej wcześniejszej oceny to różne zdarzenia. Bez ich rozróżnienia porównanie wyników może sugerować pogorszenie systemu, choć zmieniły się oczekiwania. Przy każdej istotnej zmianie warto zapisać datę, właściciela źródła oraz powiązane pytania kontrolne.

Użytkownik zgłaszający błąd powinien otrzymać informację zwrotną, kiedy sprawa została rozpoznana i jak może postąpić do czasu poprawki. Nie zawsze potrzebne są szczegóły techniczne. Przydatna jest natomiast jasna wskazówka, czy może nadal korzystać z asystenta w danym zadaniu oraz gdzie znaleźć aktualną instrukcję. Dzięki temu zgłoszenie prowadzi do zmiany sposobu pracy, a nie kończy się w formularzu.

Przy wdrożeniu kolejnej funkcji rozszerzcie zestaw oceny o jej rzeczywiste konsekwencje. Asystent, który wcześniej wyłącznie wyszukiwał dokumenty, po uzyskaniu możliwości wysyłki wiadomości potrzebuje dodatkowych testów adresata, treści i zatwierdzenia. Zakres oceny powinien rosnąć razem z zakresem działania. W artykule o zatwierdzaniu działań agenta AI opisujemy, jak przygotować człowiekowi czytelną propozycję decyzji.

Wreszcie zaplanujcie przegląd kosztu samej oceny: czasu specjalistów, liczby ręcznie sprawdzanych przypadków oraz częstotliwości prób. Nie chodzi o zastąpienie kontroli najtańszym testem. Chodzi o wybranie takiego rytmu, który firma potrafi utrzymać i który uwzględnia sprawy o największych skutkach. Jeśli zasoby są ograniczone, wyraźnie zapiszcie zakres sprawdzenia zamiast sugerować, że zespół ocenił każdą odpowiedź.

Zapiszcie przyczynę w zakresie, w jakim udało się ją potwierdzić, oraz osobę odpowiedzialną za dalszą obserwację. Jeśli przyczyna pozostaje nieznana, nie trzeba dopisywać pewnej diagnozy na siłę. Ważniejsze jest ustalenie bezpiecznego sposobu pracy i terminu kolejnego sprawdzenia. W projektach AI dla firm ocena po starcie powinna mieć właściciela i miejsce w codziennej pracy zespołu.