„Skill został utworzony” nie znaczy „działa”

Podczas ćwiczenia z tworzenia skilli prosiłem uczestników o jedną konkretną rzecz: „uruchomcie przygotowaną umiejętność w nowej rozmowie”. Koniecznie w nowej.

Utworzenie skilla to nie to samo co potwierdzenie jego działania.

Powód jest prosty: w czacie, w którym tworzymy instrukcję, model zna już nasze wymagania. Ma je w historii rozmowy. Jeśli wykona zadanie dobrze, nie wiemy jeszcze, czy korzysta z zapisanej procedury, czy po prostu z tego, co przed chwilą mu powiedzieliśmy.

To problem z testem. Wynik może wyglądać poprawnie, mimo że nie sprawdziliśmy najważniejszego: czy rozwiązanie działa także po wyjściu z kontekstu, w którym powstało.

Nowa rozmowa to jeszcze nie laboratorium

Nowa rozmowa ogranicza ten konkretny problem, ale nie jest absolutnie czystym laboratorium. Narzędzie może nadal korzystać z pamięci, instrukcji konta lub ustawień projektu. Dlatego warto zapisać, co miało być dostępne i na jakich materiałach miał opierać się wynik. Przy wdrożeniu zespołowym trzeba jeszcze sprawdzić działanie w warunkach użytkownika docelowego.

Drugi krok, który pokazywałem na szkoleniu, był jeszcze prostszy: wejść w zapisane instrukcje i zobaczyć, co faktycznie powstało. Opis skilla może brzmieć świetnie. Treść procedury może jednak pomijać ograniczenie, błędnie rozumieć zadanie albo zawierać założenie, którego nigdy nie chcieliśmy przyjąć.

Trzy przypadki testowe

Do testowania przygotowałbym trzy przypadki. Pierwszy zwykły, z kompletnymi danymi. Drugi z ważną informacją, której brakuje. Trzeci z sytuacją, w której procedura powinna odmówić rozstrzygnięcia albo skierować pytanie do człowieka.

Jeśli skill ma odpowiadać na pytania o regulamin, łatwo sprawdzić odpowiedź na punkt, który jest w dokumencie. Równie ważne jest pytanie o coś, czego dokument nie określa. Czy narzędzie rozpozna brak, czy dopisze wiarygodnie brzmiącą zasadę?

Zapis „utworzono” potwierdza wykonanie pewnej operacji w aplikacji. Dopiero próby na znanych przypadkach pokazują, czy mamy użyteczną procedurę. Warto zakończyć tworzenie skilla właśnie takim sprawdzeniem, zanim zaczniemy polegać na nim przy kolejnych zadaniach.

Co z tego wynika dla firmy

Najprostszy odbiór takiej procedury to test w nowej rozmowie na dwóch lub trzech przypadkach: typowym, niepełnym i celowo problematycznym. Zespół powinien wiedzieć, co uznaje za poprawną odpowiedź i w jakich sytuacjach ma przerwać automatyczne działanie.