Kiedy warto douczyć AI do grupowania reklamacji?

Trzy opisy szuflady

Załóżmy, że producent mebli otrzymuje takie wiadomości od trzech klientów: „Szuflada nie zamyka się do końca”, „Po wsunięciu szuflada zostaje trochę otwarta” oraz „Nie mogę zamknąć szuflady, a uchwyt się rusza”. Zespół jakości uzgodnił na potrzeby swojego zestawienia kategorie „problem z zamykaniem szuflady” i „luźny uchwyt”.

Pierwsze dwa opisy trafiłyby do tej samej grupy, choć klienci użyli innych słów. Trzeci zawiera oba zgłoszone objawy. Gdy pracownik musi wybrać tylko jedną kategorię, w zestawieniu zginie problem z uchwytem albo z zamykaniem. Model pomagający w tej pracy powinien umieć przypisać więcej niż jedną kategorię do reklamacji.

Przy takim sposobie liczenia trzy reklamacje zawierają trzy zgłoszenia problemu z zamykaniem i jedno zgłoszenie luźnego uchwytu. Suma wystąpień objawów wynosi cztery, choć klientów było trzech. Osoba czytająca raport musi wiedzieć, co oznaczają liczby. Inaczej lepiej uporządkowane opisy mogą prowadzić do błędnego wniosku o liczbie reklamacji.

Z tych wiadomości nie wynika jeszcze, dlaczego szuflada się nie zamyka. Przyczynę może ustalić późniejsze sprawdzenie produktu. Warto zachować pierwotny opis klienta obok przypisanych kategorii, a ustalenia z oględzin zapisać oddzielnie. Dzięki temu analityk może wrócić do tego, co rzeczywiście zgłoszono, i porównać to z późniejszym rozpoznaniem.

Najpierw wspólne znaczenie kategorii

Użyteczne grupowanie wymaga dość prostego porozumienia w zespole: co chcemy razem policzyć? Jeżeli jedna osoba oznacza wszystkie problemy z szufladą jako „mechanizm”, a druga rozdziela trudność w otwieraniu i zamykaniu, ich zestawienia nie będą porównywalne. Sama wymiana modelu tego nie wyjaśni.

Nie trzeba od razu tworzyć szczegółowego podziału wszystkich możliwych problemów. Lepiej zacząć od tych, które zespół już omawia na spotkaniach i potrafi rozpoznać w wiadomościach. Przy opisach takich jak „szuflada jest zepsuta” można pozostawić ogólne oznaczenie lub skierować sprawę do uzupełnienia zgodnie z przyjętym sposobem pracy. Dokładniejsza kategoria wymaga dokładniejszej informacji.

Stare przypisania bywają przydatne, ale wymagają przeglądu. Mogły powstać według wcześniejszego podziału albo uwzględniać wiedzę serwisanta, której nie było w wiadomości klienta. Jeżeli model ma grupować same opisy zgłoszeń, należy ocenić przykłady właśnie z tej perspektywy. W przeciwnym razie oczekujemy od niego rozpoznania informacji, której nie dostał.

Czy potrzebny jest fine-tuning?

Przy niewielkiej liczbie reklamacji wspólna lista kategorii i ręczne oznaczanie w obecnym narzędziu mogą wystarczyć. Jeżeli klienci wybierają problem w formularzu, warto sprawdzić, czy te odpowiedzi już dają potrzebny podział. Reguły wyszukujące charakterystyczne frazy także mogą pomóc, choć w przykładzie z szufladą trzeba uwzględnić różne sposoby opisania tego samego objawu.

Kolejną możliwością jest gotowy model, któremu wyjaśniono znaczenie kategorii. Próba na rzeczywistych zgłoszeniach pokaże, czy rozpoznaje inne sformułowania i zachowuje oba problemy z trzeciej wiadomości. Jeśli pracownik ma niewiele poprawek, dodatkowe uczenie może nie przynieść korzyści uzasadniającej jego utrzymanie.

Fine-tuning oznacza dalsze uczenie istniejącego modelu na przykładach z pokazanymi poprawnymi odpowiedziami. W tym przypadku zespół uczyłby go przypisywania swoich kategorii do sposobu, w jaki klienci opisują problemy. Google wymienia klasyfikację wśród zastosowań takiej adaptacji. Zaleca najpierw dopracować instrukcje dla modelu, sprawdzić powtarzające się błędy i zadbać o jakość oznaczeń przykładów.

Adaptację warto więc rozważyć, gdy zespół ma spójne kategorie, a gotowy model nadal regularnie myli określone opisy lub pomija drugi objaw. Potrzebne są przykłady, w których pracownicy potrafią wyjaśnić poprawne przypisanie.

Co pokaże, że raport jest lepszy

Porównanie powinno objąć późniejsze reklamacje, których nie używano do dostosowania modelu. Pracownik jakości sprawdza wtedy, czy propozycje odpowiadają opisom klientów i ile musi poprawić przed przygotowaniem zestawienia. Warto zestawić ten wynik z gotowym modelem oraz prostszą metodą, z której zespół korzysta dziś.

Model może pomijać luźne uchwyty, mimo że dobrze rozpoznaje częste kłopoty z zamykaniem, zwłaszcza gdy klient opisuje uchwyt jako drugą usterkę. Dlatego osoba zamawiająca rozwiązanie powinna zobaczyć, co dzieje się z poszczególnymi grupami i wiadomościami zawierającymi kilka problemów. W naszym przykładzie pominięcie uchwytu usuwałoby ten objaw z całego zestawienia.

Nowy produkt albo zmiana podziału reklamacji będzie wymagać ponownego sprawdzenia działania. Przy zakupie warto uzgodnić, kto ocenia nowe pomyłki i decyduje o zmianach kategorii. Grupowanie do analizy jakości pozostaje osobnym zadaniem od wskazywania zespołu, który ma obsłużyć sprawę. Ten drugi temat opisujemy w artykule o fine-tuningu do kierowania zgłoszeń serwisowych.

Jak Syntalith może pomóc w przygotowaniu zestawienia

Syntalith tworzy aplikacje i dostosowuje modele AI. Dla zespołu jakości proponujemy zacząć od raportu, który dziś wymaga ponownego czytania reklamacji. Sprawdzamy sposób grupowania i porównujemy prostsze metody z gotowym modelem. Jeżeli pozostają powtarzalne błędy, próba adaptacji pozwala ocenić, czy dalsza praca nad modelem jest uzasadniona.

Wybrane rozwiązanie powinno pokazywać pracownikowi proponowane kategorie wraz z oryginalną wiadomością, tak aby mógł poprawić przypisanie przed wykorzystaniem go w zestawieniu. Na pierwszą rozmowę wystarczy opisać raport i przykład problemu, który trudno dziś policzyć. Nie trzeba przygotowywać specyfikacji ani przesyłać danych klientów. Sposób pracy z przykładami można uzgodnić później; informacje o ofercie są w cenniku Syntalith.