Asystent odpowiedział dobrze na pytanie podczas prezentacji. To dobry sygnał, ale jeszcze nie odbiór rozwiązania. Użytkownicy zapytają inaczej, użyją skrótu i wrócą do sprawy z brakującym dokumentem. Testowanie ma pokazać, kiedy wynik nadaje się do użycia, kiedy potrzebuje kontroli, a kiedy system powinien się zatrzymać.
Przy wdrożeniu firmowego asystenta AI kryteria warto ustalić przed wyborem najlepiej wyglądającej demonstracji. Oceniany powinien być wynik zadania, a nie wrażenie po rozmowie. Dokumentacja OpenAI dotycząca ocen systemów AI zaleca próby odpowiadające rzeczywistemu zastosowaniu i prowadzenie ich również po zmianach.
Zbierz pytania z pracy, razem z oczekiwaniem
Poproś przyszłych użytkowników o sprawy, które dziś rozwiązują ręcznie. Do każdej dopisz podstawę odpowiedzi albo warunek poprawnego działania. Pytanie „czy to jest dobra odpowiedź?” jest zbyt ogólne. Lepiej określić, czy wynik wskazuje właściwy dokument, zachowuje wyjątek i prowadzi do następnego kroku.
Przy asystencie firmowej wiedzy kontroluj wyszukanie źródła i przygotowanie odpowiedzi oddzielnie. Błąd na pierwszym etapie wymaga innej poprawki niż pominięcie warunku z dobrze dobranego dokumentu. Takie rozdzielenie skraca dyskusję o tym, czy problemem jest „model”, którym często nazywa się cały system.
W próbie zostaw również niepełne pytania i niejednoznaczne nazwy. Użytkownik nie będzie codziennie odtwarzał polecenia z dokumentacji wdrożeniowej. Jeżeli potrzebne jest doprecyzowanie, sprawdź, czy asystent pyta o właściwą informację zamiast proponować losową interpretację.
Przy pytaniach otwartych zapisz kilka dopuszczalnych sposobów odpowiedzi. Dwa różnie sformułowane wyniki mogą zachować ten sam sens. Nie oceniaj ich wyłącznie przez zgodność słów z jednym wzorcem. Osobno wskaż informację, której nie wolno pominąć, i twierdzenie, którego źródło nie potwierdza. Taki opis pozwala zachować swobodny język bez rozmywania kryterium poprawności potrzebnego w codziennej pracy.
Wybierz błędy, których nie wolno uśrednić
Nie wszystkie pomyłki mają podobny skutek. Niezręczna redakcja i ujawnienie dokumentu innego klienta nie powinny trafiać do wspólnej oceny bez rozróżnienia. Przygotuj kategorie błędów i kryteria zatrzymujące wdrożenie. Próg wynika z zastosowania oraz konsekwencji, a nie z potrzeby uzyskania okrągłego wyniku w raporcie.
Testuj uprawnienia do źródeł na różnych rolach. Dodaj pytanie o dokument niedostępny oraz dalsze pytanie w tej samej rozmowie. Samo logowanie na konto administratora nie pozwoli stwierdzić, jak narzędzie zachowa się wobec zwykłego użytkownika.
Jeśli agent wykonuje działania, obejmij próbą moment zatwierdzania i rzeczywisty skutek operacji. Dobrze napisana odpowiedź „wysłałem” nie potwierdza wysyłki. Sprawdź wynik w systemie docelowym i zachowanie po przerwanym połączeniu. W przeciwnym razie test oceni sprawność opowiadania o pracy.
Zachowaj niezależną próbę
Przykłady użyte do poprawiania instrukcji są potrzebne, ale nie powinny być jedynym materiałem odbiorczym. Zachowaj oddzielne sprawy, których nie dopasowujesz do kolejnych zmian. Inaczej system może wyglądać coraz lepiej na znanej liście, bez podobnej poprawy w codziennej pracy.
To powód, dla którego wybór modelu AI powinien korzystać z porównywalnych warunków. Nie oceniaj jednego wariantu na łatwych pytaniach, a drugiego na wyjątkach. Zapisz użyte materiały, konfigurację i warunki próby. Bez tego trudno powtórzyć wynik lub wyjaśnić różnicę po aktualizacji.
Część ocen można zautomatyzować, na przykład sprawdzenie identyfikatora źródła lub wymaganych pól. Ocena znaczenia i użyteczności często potrzebuje udziału osoby znającej zadanie. Model oceniający inny model również wymaga sprawdzenia. Techniczne narzędzie do ocen nie daje automatycznie niezależnego osądu.
Włącz wyniki prób do codziennego utrzymania
Zgłoszenia z pracy powinny prowadzić do nowych przypadków kontrolnych. Zanim jednak poprawisz instrukcję, ustal źródło błędu: dane, wyszukiwanie, uprawnienie, odpowiedź czy integrację. Dodawanie kolejnych zakazów do polecenia nie rozwiąże brakującego dokumentu. Czasem wystarczy poprawić źródło albo widok przekazania sprawy.
Przygotuj monitorowanie działania po starcie i wracaj do testów po istotnej zmianie. W Archifutura można powiązać taki odbiór z etapami projektowania i wdrażania oprogramowania. Po przejściu od pilota do systemu produkcyjnego zestaw prób powinien zostać z firmą razem z rozwiązaniem, aby kolejna poprawka była sprawdzalną zmianą, a nie nowym pokazem pewności siebie.
Dla zgłoszonej pomyłki zachowaj warunki umożliwiające jej odtworzenie w bezpiecznym zakresie danych. Sam zrzut końca rozmowy może nie pokazywać źródła i poprzedniego pytania. Ustal, które elementy kontekstu były potrzebne do wyniku, a które można zastąpić materiałem testowym. Dzięki temu przypadek kontrolny pozostanie użyteczny również wtedy, gdy oryginalna sprawa zostanie zamknięta lub dostęp do niej się zmieni.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.
