Mały lokalny model do przypisywania zgłoszeń

Załóżmy, że w firmie konfiguracją drukarek zajmuje się zespół wsparcia stanowisk, a dostępem do aplikacji biznesowej jej zespół administracyjny. Pracownicy wysyłają takie prośby własnymi słowami, bez wyboru kategorii w formularzu. Osoba dyżurująca w helpdesku musi rozpoznać, komu przekazać każdą z nich.

Model mógłby pokazać przy zgłoszeniu krótką sugestię zespołu. Przy prośbie o skonfigurowanie drukarki byłoby to wsparcie stanowisk; przy prośbie o dostęp do wskazanej aplikacji jej administratorzy. Dyżurny widzi treść i propozycję obok siebie, sprawdza je i zatwierdza przypisanie. Do tej pracy wystarczy nazwa właściwego zespołu. Długa odpowiedź o możliwych sposobach rozwiązania problemu nie pomaga podjąć tej decyzji.

Poranek pokazuje, czy sprzęt wystarczy

Pojedyncza podpowiedź uzyskana na spokojnym komputerze pokazuje tylko część pracy. Kiedy wiele osób zaczyna dzień i wysyła zgłoszenia w krótkim odstępie, kolejne sprawy mogą czekać na model. Dyżurny potrzebuje wiedzieć, czy propozycja pojawi się, zanim sam przeczyta i przypisze zgłoszenie.

Dlatego próba ma sens na komputerze lub serwerze przewidzianym do późniejszego użycia, z napływem spraw podobnym do porannego. Ważny jest czas od pojawienia się zgłoszenia do otrzymania podpowiedzi, którą można wykorzystać. Sam czas generowania nazwy zespołu pomija oczekiwanie przed rozpoczęciem analizy. Osobno warto zobaczyć początek pracy, gdy model dopiero ładuje się do pamięci.

Dokumentacja Ollama opisuje zależność równoczesnego przetwarzania od dostępnej pamięci. Obsługa kilku zapytań naraz wymaga dodatkowej pamięci, a przeciążona kolejka może odrzucić kolejne żądanie. To powód, by sprawdzić konkretny model na rzeczywistym sprzęcie i obciążeniu firmy. Określenie „mały” nie mówi jeszcze, jak szybko helpdesk otrzyma ostatnią podpowiedź z porannej partii.

Kierownik helpdesku może wtedy porównać, ile spraw dostało właściwą propozycję na czas, a ile dyżurny musiał przypisać sam. Poprawna odpowiedź otrzymana dopiero po ręcznym rozdzieleniu spraw przychodzi za późno, żeby odciążyć dyżurnego. Jeżeli odpowiada szybko, lecz myli zespoły, pracownicy muszą poprawiać przekazania. Oba wyniki mają znaczenie przy decyzji o wdrożeniu.

Część zgłoszeń może ominąć model

Gdy formularz zawiera jednoznacznie wybraną usługę, odpowiedni zespół da się wskazać istniejącą regułą. Na przykład GLPI opisuje reguły zgłoszeń z warunkami i działaniami wykonywanymi przy utworzeniu lub zmianie zgłoszenia. Reguły mają ustaloną kolejność wykonania.

W takim przypadku warto najpierw wykorzystać informację, którą pracownik już podał. Model może pozostać przy sprawach opisanych swobodnym tekstem, dla których reguły nie wskazały adresata. Pozwala to ocenić, czy firma w ogóle potrzebuje dodatkowego narzędzia do całej kolejki, czy tylko do jej fragmentu.

Jeśli lokalna próba pokaże powtarzalne pomyłki mimo jasnego podziału odpowiedzialności, osobnym pytaniem będzie sens fine-tuningu do klasyfikacji zgłoszeń. Najpierw potrzebna jest odpowiedź, czy proponowany model i sprzęt nadają się do codziennego tempa pracy.

Dyżurny widzi również sprawy bez podpowiedzi

W opisie „nie mogę pracować w aplikacji” może brakować informacji, czy chodzi o dostęp, czy o inny problem. Taka sprawa pozostaje do przeczytania przez dyżurnego. Powinien móc ją przypisać albo dopytać autora, bez czekania na rozstrzygnięcie modelu.

Podobnie wygląda zgłoszenie, dla którego podpowiedź spóźnia się lub nie powstała z powodu przeciążenia. Pracownik widzi je w helpdesku i może przejąć ręcznie. Jeśli później pojawi się sugestia, aplikacja musi uwzględnić fakt, że dyżurny już wykonał przypisanie.

Dla kierownika ważna jest także ilość tej pozostałej pracy. Próba, po której większość porannych spraw nadal wymaga ręcznego czytania, może uzasadniać węższy zakres albo pozostanie przy obecnym sposobie obsługi. Zespół powinien móc prowadzić zwykły dyżur również wtedy, gdy lokalny model jest niedostępny.

Co pozostaje lokalnie

Model lokalny wykonuje obliczenia na wskazanym urządzeniu firmy. Ollama opisuje tryb lokalny, który wyłącza modele chmurowe i wyszukiwanie w sieci. To ustawienie programu uruchamiającego model. Nie określa miejsca przechowywania wszystkich kopii zgłoszenia w systemie helpdesk ani sposobu działania jego integracji.

W tej pracy warto ustalić konkretnie, jaka treść trafia do modelu i gdzie zachowywane są podpowiedzi. Jeśli firma wybiera lokalne przetwarzanie z powodu zasad dotyczących danych, osoba odpowiedzialna za helpdesk i administrator środowiska muszą uzgodnić także ten obieg.

Syntalith może pomóc przygotować aplikację AI do przypisywania zgłoszeń oraz próbę lokalnego modelu na sprzęcie firmy. Proponowany zakres może objąć wąską grupę rutynowych spraw, podpowiedzi dla dyżurnego i porównanie z dostępnymi regułami. Zespół helpdesku wnosi znajomość właściwych adresatów i godzin największego napływu. Wynik pozwoli zdecydować, czy rozwijać połączenie z używanym systemem. Informacje o wycenie znajdują się w cenniku.

Pierwszą rozmowę można zacząć od opisu poranka: co trafia do kolejki i przy których sprawach pracownik najdłużej zastanawia się nad adresatem. Informacja o dostępnym sprzęcie pomoże określić zakres próby.