Odczytywanie dokumentów przez AI: kiedy przekazać wynik do sprawdzenia?

System odczytał numer faktury, kwotę i termin płatności. Wszystko wygląda wiarygodnie, ale przy jednej cyfrze obraz jest nieczytelny. Czy aplikacja powinna przepisać wynik do księgowości, czy zatrzymać sprawę do sprawdzenia? Odpowiedź zależy od konsekwencji błędu, jakości dokumentu i możliwości weryfikacji. Sama obecność liczby na ekranie nie dowodzi, że została prawidłowo odczytana.

Odczytywanie dokumentów przez AI może ograniczyć ręczne przepisywanie. Żeby proces był użyteczny, trzeba jednak przewidzieć brakujące strony, kilka podobnych wartości i sytuacje, których system nie potrafi rozstrzygnąć. Równie ważne jest to, co stanie się po skierowaniu dokumentu do człowieka: kto go zobaczy, co może poprawić i jak sprawdzi, z którego miejsca pochodzi propozycja.

Jeśli rozważasz taki proces, wyślij brief z opisem typów dokumentów, potrzebnych pól i decyzji, które dziś podejmują pracownicy. Nie przesyłaj prawdziwych danych klientów ani dokumentów poufnych na etapie pierwszej rozmowy. Wymyślony przykład nieczytelnego lub niekompletnego dokumentu wystarczy, aby zacząć rozmowę o wyjątkach.

Najpierw ustal, co ma zostać odczytane

Wyobraźmy sobie firmę, która otrzymuje faktury od wielu dostawców. Jedne są wyraźnymi plikami, inne zdjęciami papierowych dokumentów. Zespół chce przenieść numer, datę i kwotę do systemu finansowego. To przykład projektowy, nie opis wdrożenia. Jeszcze przed wyborem narzędzia trzeba ustalić, co każda wartość oznacza oraz w jakiej sytuacji można jej użyć.

Na dokumencie może występować kilka dat: wystawienia, sprzedaży, terminu płatności i poprzedniej korekty. Może też pojawić się kwota netto, podatek i kwota do zapłaty. Poprawnie odczytane cyfry będą bezużyteczne, jeśli trafią do niewłaściwego pola. Warto zebrać zespół, który zna dokumenty, oraz zapisać przykłady podobnych wartości i reguły ich rozróżniania.

Ustalcie również, co się dzieje z dokumentem bez wymaganej informacji. Brak terminu płatności nie zawsze jest błędem odczytu: czasem dokument go nie zawiera albo znajduje się on w umowie. System powinien odróżnić brak widocznej wartości od własnej niepewności i nie tworzyć daty na podstawie zgadywania. Kontekst obiegu faktur opisujemy szerzej w artykule o AI w obiegu faktur.

Dla innych procesów lista pól będzie inna. W logistyce liczy się na przykład zgodność dokumentu z konkretnym przewozem, a w serwisie identyfikator urządzenia i opis usterki. Nie należy zakładać, że jedna reguła oceny pasuje do każdej branży. Zmiana pojedynczej cyfry w numerze przesyłki i drobna literówka w polu opisu mogą mieć zupełnie inne skutki.

Niepewność to sygnał, nie dowód

Niektóre narzędzia zwracają ocenę pewności dla odczytanej wartości. Może ona pomóc wybrać sprawy do weryfikacji, lecz sposób obliczania i interpretacji zależy od produktu oraz rodzaju pola. Nie każda usługa zwraca taką ocenę dla każdej informacji. Nawet wysoki wynik nie zastępuje sprawdzenia, czy odczyt dotyczy właściwego fragmentu i czy wartość ma sens w danym procesie.

Dokumentacja Microsoft dotycząca oceny pewności w Document Intelligence opisuje różne oceny związane z rozpoznawaniem tekstu i pól oraz możliwość kierowania wyników do kontroli. To opis konkretnego produktu, a nie obietnica, że taki sam wynik liczbowy będzie oznaczał to samo w innym narzędziu. Zanim ustalicie próg, sprawdźcie jego znaczenie w dokumentacji wybranej usługi i na własnych przykładach.

Wynik odczytu warto zestawić z innymi kontrolami. Numer zamówienia może mieć poprawną liczbę znaków, ale należeć do innego klienta. Suma pozycji może nie zgadzać się z kwotą końcową, bo na dokumencie uwzględniono rabat albo koszt dostawy. Reguła wykrywająca rozbieżność powinna wskazać ją pracownikowi, a nie automatycznie uznać dokument za błędny bez uwzględnienia kontekstu.

Równie istotna jest informacja o pochodzeniu. Osoba sprawdzająca powinna móc zobaczyć proponowaną wartość obok właściwej strony lub fragmentu dokumentu. To skraca drogę od pytania „dlaczego system tak uznał?” do własnej oceny. Jeśli narzędzie nie potrafi wskazać źródła, trzeba zdecydować, czy pracownik jest w stanie sprawdzić wynik w inny sposób i ile czasu to zajmie.

Próg dobierz do skutku błędu

Jedna granica dla całego dokumentu bywa zbyt uproszczona. Pole wykorzystywane tylko do wyszukania sprawy może wymagać innej kontroli niż numer konta przeznaczony do płatności. Podział powinien uwzględniać skutek pomyłki, możliwość jej wykrycia oraz to, czy kolejny etap zatwierdza człowiek. Dla szczególnie istotnych pól możecie wymagać sprawdzenia niezależnie od oceny zwróconej przez narzędzie.

Przygotujcie zestaw rzeczywistych typów sytuacji na odpowiednio zabezpieczonych albo zastępczych danych. Uwzględnijcie czytelne pliki, skany o słabszej jakości, różne układy, brakujące strony i wartości występujące kilka razy. Następnie porównajcie propozycje systemu z wynikiem ustalonym przez osoby znające proces. Osobno policzcie przypadki, które słusznie trafiły do kontroli, oraz błędy, których reguła nie zatrzymała.

Próg oznacza również decyzję o obciążeniu zespołu. Jeśli wszystkie dokumenty trafiają do pracownika, może być potrzebny prostszy sposób przeglądu. Jeśli trafia ich bardzo mało, trzeba sprawdzić, czy nie przechodzą niewykryte błędy. Nie ma uniwersalnej liczby odpowiedniej dla każdej firmy. Warunki należy uzgodnić przed uruchomieniem oraz ponownie ocenić, gdy zmieni się rodzaj dokumentów lub model.

Dobre kryterium odbioru opisuje zachowanie w konkretnej sytuacji. Zamiast zapisu „system dobrze odczytuje faktury” można uzgodnić zestaw dokumentów testowych, sposób sprawdzania pól i wymagane postępowanie przy braku wartości. Więcej o formułowaniu takich warunków piszemy w artykule o odbiorze aplikacji i kryteriach testu.

Zaprojektuj kolejkę dla osoby sprawdzającej

Dokument przekazany do weryfikacji nie powinien znikać w skrzynce bez właściciela. Kolejka może pokazywać dokument, wskazane pola, przyczynę zatrzymania, czas oczekiwania i odpowiedzialny zespół. Pracownik powinien mieć możliwość poprawienia wartości, oznaczenia braku oraz zapisania decyzji. Warto odróżnić sprawę oczekującą na uzupełnienie przez klienta od sprawy, którą można rozstrzygnąć wewnętrznie.

Dostęp do dokumentu powinien wynikać z roli osoby sprawdzającej. Jeżeli w treści znajdują się dane dotyczące kilku klientów, system musi zachować właściwe granice także w kolejce wyjątków. O tym, dlaczego uprawnienia trzeba uwzględnić już przy pobieraniu materiału, przeczytasz w tekście o dostępie do dokumentów w systemie RAG.

Przy poprawce zachowajcie informację, co zaproponował system, co zatwierdzono i kto podjął decyzję, o ile taki zapis jest potrzebny w danym procesie. Nie oznacza to przechowywania dowolnej liczby kopii dokumentu. Zakres historii i czas jej przechowywania należy ustalić z osobami odpowiedzialnymi za dane. Istotne jest, aby później dało się wyjaśnić, jak powstała wartość przekazana do kolejnego systemu.

Jeżeli dokument jest niekompletny, pracownik może potrzebować prośby o brakującą stronę zamiast pola do ręcznej korekty. Wtedy system powinien zachować informację o oczekiwaniu i ponownie przypomnieć o sprawie według uzgodnionych zasad. Kontakt z klientem, termin odpowiedzi i wznowienie procesu są częścią projektu. Bez nich nawet dokładny odczyt zostawia zespół z porzuconą sprawą.

Po poprawce sprawdź przekazanie wyniku

Zatwierdzenie pola w jednym systemie nie oznacza jeszcze, że drugi system zapisał właściwą wartość. Integracja powinna przekazać wynik do odpowiedniego rekordu oraz pokazać, czy operacja się powiodła. Gdy nie ma potwierdzenia, pracownik musi wiedzieć, czy sprawdzić stan w systemie docelowym, ponowić zadanie czy poczekać na reakcję techniczną. Opisujemy to w artykule o integracjach API i webhookach.

Ponowienie wymaga szczególnej uwagi przy tworzeniu dokumentów lub zleceń. Jeśli pierwsze żądanie zostało wykonane, lecz odpowiedź nie dotarła, druga próba może utworzyć duplikat. Identyfikator sprawy, sprawdzenie istniejącego rekordu i uzgodnione zasady ponawiania pomagają uniknąć podwójnego skutku. Dostępne zabezpieczenia zależą od konkretnej integracji, więc należy je przetestować przed uruchomieniem.

Kiedy korekta zostanie przyjęta, warto przekazać pracownikowi czytelne potwierdzenie. Jeśli system nie mógł zapisać wyniku, nie powinien pokazywać sprawy jako zakończonej tylko dlatego, że formularz został wysłany. O tym, jakie sygnały pomagają rozpoznać zatrzymanie procesu, przeczytasz w tekście o monitorowaniu automatyzacji.

Weryfikuj jakość także po starcie

Dokumenty zmieniają się razem z dostawcami, formularzami i sposobem ich przesyłania. Nowy układ tabeli albo zdjęcia wykonywane w słabszym świetle mogą ujawnić przypadki, których nie było w pierwszym zestawie testowym. Warto regularnie przeglądać poprawki, sprawy zatrzymane do kontroli oraz przykłady błędów wykrytych później przez pracowników. Podobną kontrolę jakości po starcie warto zaplanować dla asystenta odpowiadającego na pytania pracowników.

Sama liczba dokumentów przekazanych do sprawdzenia nie mówi jeszcze, czy proces jest dobry. Trzeba wiedzieć, z jakiego powodu je zatrzymano i czy pracownik rzeczywiście poprawił wynik. Przydatne są też kontrolne próbki spraw, które przeszły automatycznie, ponieważ błędu niewskazanego przez system nie widać w kolejce wyjątków. Sposób doboru próbek i odpowiedzialność za ocenę należy ustalić dla konkretnej organizacji.

Zmiana modelu, konfiguracji albo sposobu pozyskiwania dokumentów powinna uruchomić ponowne testy na uzgodnionym zestawie. Zachowajcie także przykłady wcześniejszych pomyłek, przygotowane z poszanowaniem zasad dostępu i przechowywania danych. Porównywanie wyników pomoże rozpoznać pogorszenie, zanim zostanie pomylone z pojedynczym przypadkiem. Wskazówki dotyczące projektowania scenariuszy znajdziesz w artykule o testowaniu asystenta AI.

W ocenie dokumentów pomaga osobna lista przyczyn korekty. Błąd może dotyczyć samego odczytu znaków, wybrania niewłaściwej daty albo połączenia dokumentu z inną sprawą. Te problemy wymagają różnych zmian. Poprawa jakości zdjęcia pomoże w pierwszej sytuacji, ale niekoniecznie rozstrzygnie, która z dwóch prawidłowo odczytanych dat jest terminem płatności. Pracownik powinien móc wskazać przyczynę bez wypełniania długiego formularza przy każdej poprawce.

Przed rozszerzeniem zakresu sprawdźcie również wydajność kolejki. Jeśli nowy rodzaj dokumentu wymaga częstej oceny człowieka, ustalcie, kto przejmie dodatkowe zadania i jak szybko będzie w stanie je wykonać. Warto porozmawiać z zespołem o wygodzie ekranu, możliwości powrotu do wcześniej sprawdzonego pola i sposobie przekazania sprawy przy nieobecności pracownika. Dzięki temu ocena jakości obejmie zarówno trafność odczytu, jak i to, czy cały proces da się utrzymać w codziennej pracy.

Dla każdej kolejnej grupy dokumentów ustalcie osobę, która potrafi ocenić wyjątki i wyjaśnić znaczenie pól. Podczas przeglądu błędów porównajcie jej ocenę z decyzjami innych pracowników. Rozbieżność może wskazywać niejasną regułę biznesową, a nie problem modelu. Najpierw trzeba ją uzgodnić, aby było wiadomo, jaki wynik uznać za poprawny w następnej próbie.

Pierwsza wersja może obejmować jeden typ dokumentu i kilka pól, dla których istnieje jasny sposób sprawdzenia. Tak ograniczony zakres pozwala poznać wyjątki i rzeczywiste obciążenie zespołu. Planując automatyzację obiegu pracy, uwzględnijcie czas na poprawki, obsługę braków i ustalenie odpowiedzialności. Dokument nadal wymaga decyzji, nawet gdy przepisywanie części danych przejmie system.