Lokalne AI do sprawdzania treści formularza

Odbiór osobisty i prośba o kuriera

Załóżmy, że klient w formularzu zamówienia firmowego wybiera „odbiór osobisty”, a w uwagach pisze „proszę wysłać kurierem”. Obie części są czytelne i kompletne. Osoba obsługująca zamówienie potrzebuje jednak ustalić, którą instrukcję klient chce zachować.

Asystent może pokazać wybór oraz zdanie z uwag obok siebie i przygotować szkic pytania: „W formularzu zaznaczono odbiór osobisty, a w uwagach jest prośba o wysyłkę kurierem. Który sposób realizacji wybierają Państwo?”. Pracownik sprawdza tekst przed przekazaniem klientowi. Aplikacja nie zmienia zamówienia ani nie wybiera sposobu realizacji.

O znaczeniu decyduje całe zdanie. Uwaga „proszę nie wysyłać kurierem” przy odbiorze osobistym nie zawiera tej samej sprzeczności. Samo znalezienie słowa „kurier” dawałoby tu niepotrzebny alarm i dodatkowe pytanie do klienta.

Najpierw usunąć niejasność z formularza

Jeśli podobne sprawy wracają często, warto zobaczyć formularz oczami klienta. Czy wybór odbioru jest wyraźny? Czy pole uwag wygląda jak miejsce, w którym można go zmienić? Doprecyzowanie opisu lub pokazanie wybranego sposobu realizacji przy podsumowaniu może być lepszym początkiem niż dodanie modelu.

Zwykłe sprawdzanie formularza pozostaje potrzebne. MDN opisuje wbudowane kontrole pól wymaganych i formatu, które pozwalają egzekwować jawne ograniczenia. Takie mechanizmy nadają się do pustego pola lub niewłaściwego zapisu. Nie ustalają znaczenia dowolnego zdania w uwagach.

Gdy zależność da się opisać na podstawie jednoznacznych wyborów, reguła w obecnym systemie może wystarczyć. Model warto porównać dopiero tam, gdzie pracownicy czytają różne sformułowania tej samej intencji. Jego zadaniem jest zwrócić uwagę na fragment wymagający rozmowy, bez dodawania kolejnej przeszkody do poprawnie wypełnionych zamówień.

Co można zamówić od Syntalith

Syntalith proponuje aplikację AI do sprawdzania zgodności treści formularza, połączoną z obecnym miejscem obsługi zamówień. Widok pracownika pokazuje pola, między którymi znaleziono rozbieżność, oraz szkic pytania do sprawdzenia. Pracownik może poprawić tekst, wyjaśnić sprawę lub uznać wskazanie za nietrafne. Oryginalna treść klienta pozostaje przy zamówieniu.

Początkowy zakres może objąć jeden formularz i wybraną zależność między polami. Osoba z obsługi wskazuje sprawy, które wracają do wyjaśnienia, a właściciel formularza ocenia możliwość poprawy jego układu. Porównujemy istniejące kontrole z pomocą modelu. Dopiero wtedy warto ustalać szersze połączenie z systemem zamówień i sposób przekazywania spraw do pracowników.

Stały układ odpowiedzi może ułatwić takie połączenie. Ollama opisuje odpowiedzi o narzuconej strukturze. Aplikacja może dzięki temu oczekiwać tych samych części wyniku, na przykład wskazanych pól i wyjaśnienia. Zgodny układ nie potwierdza jednak poprawnego odczytania intencji klienta.

Czy mały model sprawdzi się lokalnie

Mniejszy model warto sprawdzić na sprzęcie firmy i w języku używanym przez klientów. Oprócz trafnych wskazań policzmy też niepotrzebne pytania: każde z nich oznacza dodatkową pracę obsługi.

Próba powinna uwzględnić również oczekiwanie na wynik. Gdy wynik jest niedostępny, formularz pozostaje widoczny dla pracownika i może przejść zwykłą drogę przeglądu.

Przy lokalnym przetwarzaniu administrator ustala, jaka część zamówienia trafia do aplikacji, gdzie zostają kopie i co zapisują dzienniki. Dostęp do uwag klienta oraz późniejsza obsługa i aktualizacje dotyczą całego narzędzia. Samo uruchomienie modelu na firmowym komputerze nie określa tego obiegu.

Opowiedz nam o formularzu, który regularnie wraca do klienta z pytaniem o sprzeczne informacje. W pierwszej rozmowie ustalimy, czy warto poprawić sam formularz, dołożyć regułę czy porównać lokalny model z obecną pracą obsługi. Informacje o wycenie znajdują się w cenniku.