Kontekst i historia przetwarzania dokumentów
Andrzej Kinastowski (AK): Konnichiwa, witajcie w podcaście Office Samurai, gdzie uderzamy w nieefektywność z precyzją łucznika z epoki Edo. Tym razem będziemy rozmawiać o Inteligentnym Przetwarzaniu Dokumentów (IDP), czyli o cyfrowym przetwarzaniu faktur, zamówień, wyciągów bankowych, dokumentów tożsamości, celnych – całej tej papierowej i bezpapierowej papierologii, którą możecie mieć. Nazywam się Andrzej Kinastowski, jestem jednym z założycieli Office Samurai – firmy, która wierzy, że Wasz biznes nie powinien być zakładnikiem źle zeskanowanego dokumentu. A teraz chwyćcie swoją ulubioną katanę albo ten zaskakująco ostry nożyk do listów, który „pożyczyliście” z działu księgowości, i zaczynajmy.
Prawie 20 lat temu, kiedy zaczynałem swoją karierę korporacyjną, zostałem zatrudniony w firmie BPO, a moim pierwszym zadaniem było księgowanie faktur — typowa praca na poziomie początkowym w tamtym czasie. Każdego dnia dostawałem paczkę prawdziwych papierowych faktur i przepisywałem je do komputera. Pamiętam, że wtedy myślałem, iż to dość szalone, że żyjemy w XXI wieku, a duże międzynarodowe firmy wciąż wysyłają sobie nawzajem kawałki papieru — kawałki papieru, które potem człowiek musi ręcznie wprowadzać do komputera. To było osobliwe. Niektórzy inni klienci tej firmy BPO używali technologii OCR (Optical Character Recognition) i byłem im tego całkiem zazdrosny.
Kilka lat później, kiedy zająłem się doskonaleniem procesów i realizowałem projekty z zakresu zarządzania Lean, zauważyłem, że niektóre z tych zespołów poświęcały więcej czasu na poprawianie błędów, które popełnił OCR, niż zajęłoby im ręczne zaksięgowanie tych faktur. To były takie „stare szkoły” OCR-y, w których dla każdej nowej faktury trzeba było stworzyć tzw. maskę. Jeśli zmienił się szablon faktury, należało zmienić maskę. Maska informowała narzędzie, że w przypadku tego rodzaju faktury można spodziewać się numeru konta bankowego w tej części strony, a kwoty brutto w tamtej. Wymagało to więc dużo pracy utrzymaniowej i wcale nie było takie świetne. Dziś porozmawiamy o tym, jak te rzeczy są robione teraz.
Dziś moim gościem jest Tomasz Wierzbicki. Jest jednym z konsultantów w Office Samurai. To ekspert w wielu dziedzinach — pracuje m.in. nad Intelligent Document Processing, Communication Mining, GenAI Agents i wieloma innymi tematami. Tomaszu, witaj w podcaście.
Tomasz Wierzbicki (TW): Cześć, bardzo się cieszę, że tu jestem.
AK: Powiedz mi, dlaczego to właśnie ty tu jesteś (to znaczy, dlaczego rozmawiam właśnie z tobą o Intelligent Document Processing)?
TW: Zajmuję się Intelligent Document Processing, a ostatnio coraz bardziej klasycznym machine learningiem oraz Communication Mining (czyli głównie NLP – Natural Language Processing). Historia zaczęła się około dwóch lat temu. Pamiętam, jak nasz tech lead, Konrad, robił pewne eksperymenty z Document Understanding, i kiedy sam tego spróbowałem, bardzo szybko mnie to wciągnęło. To niesamowicie ciekawe móc łączyć rzeczy, które robimy na co dzień (RPA czy automatyzację), z odrobiną Artificial Intelligence. Dziś, przy tak szybkim rozwoju technologii, to bardzo interesujący czas i obszar, w którym warto być. Mam wrażenie, że uczę się czegoś nowego każdego dnia, a jednocześnie wiele rzeczy bardzo szybko się dezaktualizuje.
Ewolucja: od klasycznego OCR do niezależnego od układu IDP
AK: Jeśli chodzi o te stare OCR-y, których używaliśmy 20 lat temu w firmie BPO — czym dzisiejsze narzędzia się od nich różnią? Bo to, co widziałem 20 lat temu, nie robiło zbyt dużego wrażenia.
TW: Krótkie zastrzeżenie: dla mnie to raczej było 10–15 lat temu (20 lat temu byłem raczej uczniem szkoły średniej). Miałem jednak do czynienia z tymi klasycznymi rozwiązaniami. Z tego, co pamiętam, wtedy pojawiało się pytanie, czy to się w ogóle opłaca, bo korzystanie z takich OCR-ów było koszmarnie drogie, a sama technologia nie była jeszcze tak dojrzała jak dziś. Nasz tech lead, Konrad, powiedział kiedyś, że obecnie OCR-y właściwie osiągnęły górny pułap swojej efektywności — technologia jest naprawdę dojrzała i obecnie jest rozwijana poprzez wykorzystanie deep learningu, a prawdopodobnie także dużych modeli językowych.
Wciąż było tam mnóstwo błędów, więc wolumeny, które chciało się przetwarzać za pomocą OCR, musiały być naprawdę ogromne, żeby rozwiązanie opłacało się w dłuższej perspektywie. I tak trzeba było poprawiać literówki — typowym przypadkiem było mylenie „1” z „L” albo „0” z „O” i tym podobne rzeczy. Tekst uzyskany z OCR wymagał więc sporo postprocessingu.
Klasyczne podejście polegało na tym, że mimo istnienia OCR, technologia ta nie potrafiła zrobić wiele więcej poza samym odczytaniem i rozpoznaniem tekstu. Obecnie, dzięki IDP (Intelligent Document Processing), stosujemy także rozpoznawanie wzorców, dzięki czemu narzędzie jest niezależne od układu dokumentu.
Kategoryzacja struktury dokumentu
TW: Kiedy masz dokument, prawdopodobnie będzie on miał pewną strukturę. Możemy podzielić takie dokumenty na kategorie:
- Brak jakiejkolwiek struktury: jeśli weźmiesz jeden kontrakt lub jakiś certyfikat, może on wyglądać zupełnie inaczej niż inny.
- Półustrukturyzowane: Typowe dokumenty, takie jak faktury czy zamówienia, w których można się spodziewać określonych elementów. W polskim prawodawstwie jesteś prawnie zobowiązany do umieszczenia na fakturze określonych informacji. Można więc oczekiwać nie tylko obecności konkretnych danych, ale też pewnej struktury (na przykład nagłówka powtarzającego się na kilku stronach).
- Pełna struktura: Nasz słynny formularz podatkowy PIT albo dawny sposób realizacji przelewów bankowych na poczcie.
Obecnie skupiamy się nie tylko na samym pozyskaniu tekstu, ale także na określeniu położenia elementów, prawdopodobnie kąta, pod jakim dokument jest przekrzywiony, oraz wielu innych parametrów. Krótko mówiąc — nie chodzi już tylko o odczyt tekstu, lecz także o rozpoznanie struktury, czyli bardziej sytuację przypominającą rozpoznawanie obrazu, a nie wyłącznie tekst.
AK: To jest coś, co dla człowieka jest bardzo proste. Pamiętam, jak uczono mnie odczytywać faktury — pokazano mi kilka przykładów, wyjaśniono, jakich informacji mam szukać — i dla człowieka rozpoznawanie takich wzorców jest naprawdę łatwe. Ale dla komputera zawsze było to bardzo trudne zadanie.
Przepływ pracy IDP: klasyfikacja, ekstrakcja cech i eksport danych
AK: Jak to działa, że wrzucamy zeskanowaną fakturę, a na wyjściu dostajemy wszystkie informacje ładnie uporządkowane w tabeli Excela?
TW: Na podstawie projektów, które realizowałem, typowy proces obejmuje kilka kluczowych kroków, które zawsze się wykonuje.
Krok 1: Digitalizacja i ekstrakcja cech
TW: Nie każdy dokument, który masz, będzie natywny (czyli w formacie PDF, w którym można zaznaczyć tekst). Czasami jest to plik płaski albo nawet zeskanowany, więc wtedy narzędzia muszą użyć OCR lub w inny sposób wyodrębnić tekst. Pierwszym krokiem jest więc digitalizacja — i tutaj otwiera się cały obszar badań związany z technologiami OCR.
Zasadniczo musimy pozyskać tekst, ale oprócz samego tekstu wyodrębniamy również cechy. Przyjmuje to formę dużego obiektu (w sensie programistycznym, w kodzie), który zawiera różnego rodzaju parametry. Mogą to być słowa, ich położenie, najbliższe otoczenie, informacje o nachyleniu dokumentu oraz różne wagi i współczynniki, które można uwzględnić. Ten model obiektu dokumentu jest następnie przekazywany do algorytmu uczenia maszynowego.
W bardziej klasycznym podejściu byłoby to prawdopodobnie połączenie głębokich sieci neuronowych do analizy obrazu (czyli części strukturalnej) oraz konwolucyjnych sieci neuronowych. Dla części tekstowej stosuje się zazwyczaj embeddingi. Modele te mogą być wstępnie wytrenowane (dostawca może oferować gotowe modele przeznaczone np. do faktur lub innych typów dokumentów) albo trzeba je wytrenować samodzielnie.
Krok 2: Klasyfikacja dokumentu
TW: Pierwszą rzeczą, którą chcesz zrobić, jest klasyfikacja. Jeśli nie masz pewności, że otrzymujesz tylko jeden konkretny typ dokumentu, musisz przeprowadzić klasyfikację. Algorytm określa, jaki to typ dokumentu (np. faktura albo nota kredytowa) — bez udziału człowieka. Nie jest to prosta klasyfikacja oparta na słowach kluczowych, lecz ponownie podejście oparte na uczeniu maszynowym.
AK: Czyli jeśli algorytm nie jest pewien, że ma do czynienia z danym typem dokumentu, to zwraca się o pomoc do człowieka, a następnie te dane możemy wykorzystać do ponownego trenowania modelu, żeby go wzmocnić i sprawić, by był bardziej pewny swoich decyzji?
TW: Tak, dokładnie. Można zbudować taką pętlę zwrotną — skoro i tak trzeba zaangażować człowieka do walidacji, to czemu tego nie wykorzystać i nie wzmocnić modelu, dostarczając mu dodatkowych przykładów treningowych. Kiedy już wiemy, z jakim typem dokumentu mamy do czynienia, możemy przekazać go do wyspecjalizowanych modeli (np. jednego tylko do faktur, innego do zamówień), czyli kierować dokument dokładnie do odpowiedniego modelu.
Krok 3: Ekstrakcja danych
TW: Druga część, która jest częściej oczekiwana, to ekstrakcja — czyli wyciągnięcie z dokumentu najważniejszych informacji. Na fakturach będą to na przykład numer faktury, data oraz produkty lub usługi, za które płacisz. Celem jest, aby algorytm potrafił samodzielnie wychwycić te konkretne wartości, dzięki czemu uzyskujemy ustrukturyzowany format danych, z którym można dalej pracować. W ten sposób nie ma potrzeby, by człowiek przepisywał te dane ręcznie albo nawet kopiował i wklejał — co również jest żmudnym i powtarzalnym zajęciem.
Wdrożenie i konieczność udziału człowieka w procesie (Human in the Loop, HITL)
AK: Czyli narzędzie rozumie, jaki to typ dokumentu, wie, jakie dane musi z niego pobrać, i faktycznie je pozyskuje. Co dzieje się dalej? W jaki sposób to łączy się z naszymi procesami biznesowymi?
TW: Skoro mamy już dane w formacie ustrukturyzowanym, to zasadniczo można z nimi zrobić wszystko, co da się zaprogramować lub zautomatyzować za pomocą RPA. To, w jaki sposób następuje połączenie z procesami, zależy od dostawcy rozwiązania IDP.
🔸 Może to być cokolwiek — od podstawowego API (działającego w dowolnym języku programowania).
🔸 W przypadku bardziej zaawansowanych platform (takich jak UiPath) dostępne są gotowe interfejsy, a czasem także biblioteki RPA, które zawierają gotowe aktywności — wystarczy wybrać model i ścieżkę do dokumentu.
Jeśli nie masz zasobów do twardego kodowania (nie w stylu RPA ani low-code, lecz klasycznego programowania), musisz zbadać dostępne integracje, ponieważ może to znacząco podnieść próg wejścia. Rozwiązania takie jak Document Understanding oferują wszystko w pakiecie, a doświadczenie użytkownika jest naprawdę bardzo przyjemne, nawet dla osób nietechnicznych. Często nazywam interfejs treningowy „kolorowanką”, ponieważ użytkownik biznesowy po prostu zaznacza fragmenty tekstu i dane w przyjaznym graficznym interfejsie.
Rola HITL i wskaźnika pewności (confidence score)
AK: W przypadku tych starych OCR-ów wyglądało to tak, że jeśli model nie potrafił obsłużyć danego dokumentu, przekazywał go do ręcznego przetworzenia przez człowieka. A jeśli nie poświęcało się wystarczająco dużo uwagi utrzymaniu systemu, model rozumiał coraz mniej faktur. Jak to działa w przypadku Intelligent Document Processing?
TW: Warto szukać rozwiązania, które uwzględnia tzw. Human in the Loop (HITL). W takim podejściu nie przerywasz całego procesu, ale wprowadzasz człowieka w jego środek (zamiast robota czy AI), aby zweryfikował, czy dane są poprawne. Można też uruchamiać poszczególne elementy równolegle, dzięki czemu nie zatrzymujesz całego procesu tylko po to, by zwalidować jeden dokument.
Stacja walidacyjna to graficzny interfejs użytkownika, w którym wyświetlany jest dokument oraz wartości rozpoznane dla danego typu dokumentu i poszczególnych pól. W tym miejscu można sprawdzić, czy model poradził sobie poprawnie, czy nie. I tu pojawia się kluczowy element — wskaźnik pewności (confidence score). Trzeba zaakceptować, że to nie jest klasyczne RPA. Sieć neuronowa zwraca pewne wartości (zazwyczaj w zakresie od 0 do 100%), które reprezentują stopień pewności modelu, że dana wartość faktycznie jest tą, której szukamy. Następnie decydujemy, czy jesteśmy gotowi zaakceptować (na przykład) 85% pewności, by uruchomić kolejną automatyzację. Nasze typowe podejście polega na tym, by nie bać się heurystyk. AI jest świetne, ale nie należy obawiać się uzupełniania danych czy budowania tabel mapujących (na przykład najpierw odszukania numeru faktury gdzieś w systemie), a dopiero potem zdecydowania o wyświetleniu stacji walidacyjnej użytkownikowi.
Paradoks dokładności człowieka i maszyny
TW: Narzędzie prawdopodobnie wykona około 80% pracy, ale jeszcze nie jesteśmy na etapie (może poza bardzo prostymi przypadkami), gdzie można by osiągnąć 100% przetwarzania bez udziału człowieka. Nadal mało kto w przypadku istotnych procesów pozostawia wszystko w rękach AI.
AK: Musimy też pamiętać, że AI nie ma być doskonała — ale ludzie również nie są. Nasze wskaźniki poprawności (KPI) przy księgowaniu faktur wynosiły zwykle około 96%. Oznacza to, że w 4% faktur można było znaleźć jakiś błąd, jeśli były przetwarzane przez człowieka. To zadanie jest bardzo powtarzalne, więc łatwo się rozproszyć, coś przeoczyć. Rozumiem, dlaczego firmy podchodzą ostrożnie do modeli niedeterministycznych, ale to nie jest tak, że ludzie radzą sobie w tym dużo lepiej.
TW: Ludzie nie weryfikują tak dokładnie. Pokaż mi osobę, która miałaby na tyle cierpliwości, żeby sprawdzać linijka po linijce 30-stronicowy plik PDF i porównywać go z systemem MRP. Jeśli jesteś dużą firmą, otrzymujesz codziennie tysiące, a nawet dziesiątki tysięcy faktur. To po prostu nieludzkie wymagać od kogoś, żeby porównywał 10 000 stron z jakąś bazą danych. Trzeba zrozumieć, że zarówno ludzie, jak i maszyny będą popełniać błędy — i dlatego procesy muszą być zaprojektowane tak, aby potrafiły sobie z tym poradzić.
Przypadki użycia: poza fakturami i dokumentami o dużych wolumenach
AK: Zaczęliśmy od faktur — to coś, od czego większość firm rozpoczyna swoją przygodę z Intelligent Document Processing, bo faktury dostaje każdy, a im większa firma, tym więcej ich otrzymuje. Ale jakie inne typy dokumentów można przetwarzać za pomocą IDP, gdzie zastosowanie tej technologii nadal ma sens?
TW: Sugerowałbym, żeby wziąć te dwie podstawowe funkcjonalności — klasyfikację i ekstrakcję (czyli rozpoznanie typu dokumentu oraz wyciągnięcie z niego danych) — a następnie zastanowić się, co można z nimi zrobić w różnych procesach. Inne, ciekawsze przykłady, które realizowaliśmy (bo sama klasyfikacja, ekstrakcja i wprowadzanie danych gdzieś dalej to najbardziej typowy przypadek), to na przykład rozpoznawanie, czy na dokumencie znajduje się podpis.
Przypadek użycia 1: Rozpoznawanie obecności podpisu
TW: Jeden z naszych klientów w ogóle nie był zainteresowany żadnym tekstem ani danymi — chodziło tylko o to, że na pewnych dokumentach dostawy znajdowały się trzy pola i zależało im wyłącznie na tym, żeby określić, czy w każdym z nich jest „tak”. Były tam pieczątki i odręczne podpisy. W takich przypadkach warto raczej skłaniać się ku systemom rozpoznawania obrazu, bo są do tego lepiej przystosowane. Na szczęście rozwiązanie, którego używamy, obsługuje specjalne pole przeznaczone do wykrywania podpisów i może ono przyjmować wartości logiczne (tak/nie). Wykorzystaliśmy tę funkcję — i działało to całkiem dobrze, bo około 80–90% przypadków było rozpoznawanych poprawnie.
Przypadek użycia 2: Maskowanie danych (Anonimizacja)
TW: Innym przykładem była współpraca z litewską firmą, gdzie niektóre organy państwowe zażądały od firmy pewnych dokumentów i miały do tego prawo. Z drugiej strony należało być zgodnym z RODO, więc nie mogli po prostu przekazać tych dokumentów. Musieli zaciemnić (anonimizować) dane osobowe pracowników, ponieważ prawdopodobnie były to dokumenty HR lub jakieś umowy. Rozwiązaniem było użycie ekstrakcji, ale nie po to, by rzeczywiście wyciągać dane, lecz by ustalić, gdzie te dane osobowe się znajdują, a następnie wykorzystanie bibliotek third-party (użyliśmy Pythona), które po prostu rysowały czarne prostokąty na tych miejscach i następnie spłaszczały cały dokument do pliku, którego nie da się odtworzyć.
Przypadek użycia 3: Zarządzanie i rozdzielanie dokumentów HR
TW: I jeszcze jeden ciekawy przypadek — znów duże wolumeny i spore wyzwanie: dokumenty HR. Firma miała ogromną liczbę dokumentów kadrowych (umowy, karty członkowskie siłowni, umowy dotyczące opieki zdrowotnej). Chcieli je zdigitalizować, ale wrzucili całe stosy papierów prosto do skanera, w wyniku czego powstały połączone pliki PDF liczące po 100 lub 150 stron. A skoro dokumenty zostały scalone, pojawił się problem — gdzie kończy się dokument A, a zaczyna dokument B. Te narzędzia mogą również w tym pomóc, analizując, że dany dokument obejmuje strony od tego do tego miejsca i automatycznie dzieląc je na części. Ogólnym celem było późniejsze sprawdzenie, czy dany pracownik (np. John Smith) posiada podpisane określone dokumenty (np. tę umowę i tę, ale być może nie ma jeszcze podpisanej umowy o opiekę medyczną).
AK: Czyli rozumiem, że chodzi o to, że czasami zaczynamy od prostych dokumentów — bardziej ustrukturyzowanych, w dużych wolumenach, takich jak faktury, zamówienia czy wyciągi bankowe. Następnie, w przypadku administracji HR, pojawia się dużo papieru. Wiele firm wciąż jest w trakcie digitalizacji całych archiwów. A potem mamy tę kategorię bardziej nietypowych rzeczy — tak jak wspomniałeś: wyszukiwanie podpisów czy maskowanie danych. To już bardziej kreatywny sposób wykorzystania narzędzia do obsługi wszelkich dokumentów, jakie możemy mieć.
Wyzwania techniczne i paradoks „cyfrowego papieru”
AK: Jedna rzecz, która mnie zadziwia, to fakt, że używamy plików PDF, mimo że PDF wcale nie jest dobrym formatem do przetwarzania danych. PDF to wciąż dane nieustrukturyzowane (chyba że mają jakieś ukryte warstwy ze strukturą). Przez te 20 lat (odkąd zaczynałem ręczne księgowanie faktur) przeszliśmy z papieru na coś, co właściwie jest cyfrowym papierem — ale to wciąż papier, bo to nadal nie są dane ustrukturyzowane. Nie przeszliśmy na pliki CSV czy tabele SQL, tylko z jednego rodzaju papieru na inny.
TW: Ludzie często zapominają, że PDF został pierwotnie zaprojektowany do druku (na potrzeby marketingu, ulotek cyfrowych i tym podobnych), ale bardzo szybko stał się najpopularniejszym formatem praktycznie do wszystkiego. To był trochę strzał w kolano, że nie poszliśmy o krok dalej, żeby opracować lepiej ustandaryzowane formaty. Obecnie te narzędzia w gruncie rzeczy pomagają nam rozwiązywać problem, który sami stworzyliśmy w przeszłości. Gdyby wszystko działało przez API albo w jakimś systemie EDI, nie potrzebowalibyśmy już narzędzi AI do rozpoznawania danych.
Centralne e-fakturowanie i przyszłość IDP
AK: I to właśnie prowadzi mnie do kolejnego pytania, ponieważ są już kraje w Europie, które wprowadziły scentralizowany system fakturowania. W Polsce wciąż z tym walczymy — wdrożenie było już kilkukrotnie odkładane, ale może kiedyś w końcu nastąpi. Jak myślisz, jaki wpływ będzie to miało na potrzebę stosowania technologii IDP?
TW: Trudno jednoznacznie powiedzieć, patrząc na obecną sytuację. Ponieważ faktury są najpopularniejszym typem dokumentów, przynajmniej rozważyłbym temat i zrobił rozeznanie w inicjatywach Unii Europejskiej lub lokalnych działań rządowych. Widać postęp w cyfryzacji administracji publicznej, więc warto się temu przyjrzeć — żeby nie okazało się, że wdrożyłeś rozwiązanie w pół roku, a po kolejnych sześciu miesiącach wszyscy przechodzą na e-fakturowanie i są do tego prawnie zobowiązani.
AK: Ale badania muszą być dokładne, bo z tego, co rozumiem, wiele z tych systemów fakturowania zawiera tylko podstawowe dane z faktury i nie mają tabel ze szczegółami. Więc nadal trzeba znaleźć sposób, żeby je odczytać, a poza tym to wciąż tylko faktury — a my nadal przetwarzamy wiele innych typów dokumentów.
TW: Tempo rozwoju technologii a tempo jej wdrażania to zupełnie dwie różne rzeczy. Obserwujemy, że rozwiązania IDP pojawiły się 3–4 lata temu, a mimo to wciąż zgłaszają się do nas firmy z tymi samymi problemami, z tymi samymi starymi rozwiązaniami, z tymi samymi plikami PDF. Myślę więc, że ta technologia z nami zostanie. Coś, co już działa i przynosi realne korzyści, zawsze będzie lepsze niż gonienie za ideałem, który nigdy nie zostanie zrealizowany.
Wybór dostawcy: dlaczego UiPath Document Understanding
AK: Na rynku jest kilku głównych graczy, a w Office Samurai najczęściej korzystamy z Document Understanding od UiPath. Czy możesz powiedzieć, dlaczego właśnie to rozwiązanie, a nie większość innych dostępnych na rynku?
TW: Myślę, że dużą rolę odgrywają tu nasze przyzwyczajenia — dobrze znamy tę technologię. Dostawca słynie z tego, że potrafi świetnie integrować swoje rozwiązania z resztą swojego portfolio produktów. Kolejną zaletą jest sposób wdrożenia dla użytkowników biznesowych. Często nazywam proces treningowy „kolorowanką” — użytkownik biznesowy po prostu zaznacza fragmenty tekstu i dane. UiPath oferuje też modele wstępnie wytrenowane, które już na starcie mają pewien poziom skuteczności. W przypadku najczęściej występujących pól na fakturach można oczekiwać średniego wskaźnika pewności na poziomie 60–70%. Jeśli już korzystasz z tego oprogramowania do RPA, wdrożenie kolejnego narzędzia w ramach tej samej platformy jest bardzo proste. Poza tym UiPath jest często wskazywany jako lider tej technologii.
Podejście hybrydowe: IDP i duże modele językowe (LLM)
AK: Często dostajemy pytania o duże modele językowe (LLM). Wiele firm myśli w ten sposób: „Dlaczego zamiast korzystać z Intelligent Document Processing, po prostu nie wrzucimy tego do ChatGPT?”. Jakie jest twoje zdanie na ten temat?
TW: Pierwszą rzeczą, o której zawsze wspominam, jest powtarzalność. Przetwarzanie dużych wolumenów wymaga zbudowania odpowiedniego przepływu pracy. Po drugie, dokumenty o charakterze transakcyjnym, takie jak faktury, same w sobie nie zawierają zbyt dużo tekstu. LLM-y służą do rozumienia języka, a nie do rozumienia struktur — i właśnie dlatego dedykowane rozwiązania IDP wciąż sprawdzają się w tym lepiej.
Bardzo ciekawym obszarem jest budowanie rozwiązań hybrydowych. Można wziąć dane wyjściowe z rozwiązania IDP i poprosić LLM o ich walidację. Można też stworzyć agenta, który ma dostęp do systemu ERP i potrafi sprawdzać oraz weryfikować dane. Dużym obszarem zastosowań jest tzw. fuzzy matching — można poprosić agenta, by sprawdził, czy różne sformułowania nazwy produktu faktycznie oznaczają to samo, tylko są zapisane w inny sposób. Innym obszarem, w którym można wykorzystać LLM, jest rozpoznawanie pisma odręcznego. Conrad, nasz tech lead, przekazał LLM-owi tekst z OCR wraz z obrazem, na którym było dużo pisma odręcznego, prosząc o poprawienie błędów wynikających z trudności w odczycie. Dzięki temu udało się połączyć najlepsze cechy obu światów.
Trzecim czynnikiem jest poziom pewności. LLM-y nie zwracają żadnego wskaźnika prawdopodobieństwa. Korzystając z nich, każdy słyszał o tzw. halucynacjach — gdy model się myli, potrafi podać błędną odpowiedź z absolutnym przekonaniem, jakby był pewien na 100%. Trudno sobie wyobrazić, by jakikolwiek menedżer zdecydował się obecnie powierzyć wszystko AI bez nadzoru człowieka. Dlatego na razie działamy w modelu hybrydowym.
Gdy automatyzacja napotyka mur: problematyczne dokumenty
AK: Czy spotkałeś się z projektami lub typami dokumentów, w których ta technologia zawiodła albo nie działała tak, jak tego oczekiwaliśmy?
TW: Pismo odręczne wciąż stanowi problem, więc lepiej go unikać. Trzeba się liczyć z tym, że technologia zadziała dobrze tylko wtedy, gdy pismo odręczne jest naprawdę czytelne. Słabej jakości skany zdarzają się dziś rzadko — w takim przypadku zastanowiłbym się raczej, czy nie taniej byłoby po prostu wymienić sprzęt. Podpisy też bywają problematyczne, zwłaszcza jeśli są nieczytelne. W naszym przypadku chodziło tylko o sprawdzenie, czy podpis w ogóle jest, czy go nie ma.
Ale tym, co faktycznie sprawiało najwięcej problemów, były zagnieżdżone tabele. Narzędzie potrafi definiować dwuwymiarowe struktury w osiach X i Y, ale dokumenty często mają tendencję do tworzenia jednej dużej tabeli, wewnątrz której w kolumnach znajdują się kolejne tabele. Nauczenie modelu poprawnego rozpoznawania takich przypadków jest trudne. Trzeba było stosować obejścia i dodatkowo przetwarzać dane po rozpoznaniu.
AK: To nasz apel do wszystkich osób projektujących faktury i inne typy dokumentów: jeśli naprawdę chcemy zastąpić ludzi, którzy tylko przepisują i kopiują dane z tych dokumentów…
TW: przestańmy tworzyć te wymyślne układy graficzne. Naprawdę — z punktu widzenia automatyzacji zwykły plik tekstowy, w którym wszystko jest po prostu wypisane, sprawdzi się znacznie lepiej.
AK: Prosimy — żadnych zagnieżdżonych tabel.
Ostatnie refleksje: IDP albo apokalipsa
AK: Być może kiedyś dojdziemy do momentu, w którym inteligentne przetwarzanie dokumentów nie będzie już potrzebne, bo zaczniemy wymieniać się danymi w sposób odpowiedni dla XXI wieku, a nie dla XX. Ale minie jeszcze dużo czasu, zanim to nastąpi.
TW: Jeśli zaczynasz od zera — jako nowa firma czy startup — już teraz pomyśl o tym, jak dobrze poradzisz sobie z tym obszarem. Jeśli uda ci się wdrożyć jakiś zdigitalizowany proces, w którym komputery komunikują się ze sobą przez API lub w ustandaryzowanych formatach, takich jak XML czy JSON, to i tak będzie to lepsze rozwiązanie niż po prostu zastępowanie papieru jego cyfrową wersją w formacie PDF.
AK: Myślę, że wyraźnie widać, że istnieje mnóstwo możliwości wykorzystania inteligentnego przetwarzania dokumentów. I nie chodzi tu tylko o oszczędności.
TW: Chodzi też o to, że coraz trudniej znaleźć ludzi, którzy będą chcieli wykonywać tego typu pracę. Znalezienie osób, które będą robiły to wystarczająco długo, żeby miało sens ich tego nauczyć, staje się naprawdę trudne. Te wolumeny nie będą maleć; każda firma musi rosnąć. Dlatego widzimy dwie opcje: albo wdrażamy inteligentne przetwarzanie dokumentów, albo po prostu czekamy na apokalipsę.
AK: Na tej optymistycznej nucie, Tomaszu, bardzo dziękuję za podzielenie się swoim doświadczeniem.
TW: Najpierw zobaczmy, dokąd zaprowadzi nas ten apel o niewymyślne pliki PDF. Do wszystkich, którzy je projektują — pamiętajcie, za pięć lat sprawdzimy, jak wam poszło. Prostota jest piękna. Dziękuję wszystkim.
AK: Dobrze, moi drodzy, to by było na tyle — kolejny odcinek podcastu Office Samurai został posiekany, pokrojony i podany niczym wasz ulubiony talerz sashimi. Ten odcinek przygotowaliśmy we współpracy z UiPath — naszym pierwszym wyborem wśród platform do automatyzacji procesów. Ogromne podziękowania dla was, naszych słuchaczy, że jesteście z nami — niezależnie od tego, czy słuchacie w drodze do pracy, siedzicie na spotkaniu udając, że robicie notatki, czy po prostu ukrywacie się przed swoją skrzynką mailową. Doceniamy was i obiecujemy, że jeszcze was nie zautomatyzujemy. Wielkie podziękowania dla naszego gościa, Tomasza Wierzbickiego, za pokazanie nam drogi do zwycięstwa nad papierologią. I jak zawsze, brawa dla Anny Cubal, naszej producentki, która ogarnia te odcinki z większą precyzją niż model IDP odczytujący idealnie sformatowaną fakturę. Całość została nagrana w legendarnym Wodzu Beats Studio, gdzie kawa jest mocna, ale nasza niechęć do ręcznego wprowadzania danych — jeszcze mocniejsza. Jeśli spodobało wam się to, co usłyszeliście — powiedzcie o tym znajomym. A jeśli wam się nie podobało — koniecznie powiedzcie o tym swoim wrogom. Pamiętajcie, żeby zasubskrybować nas tam, gdzie aktualnie odkładacie obowiązki — na Spotify, Apple albo w tej dziwnej aplikacji podcastowej, którą polecił wam kuzyn. A jeśli wam się podobało, nie podobało, macie pomysły na przyszłe odcinki albo po prostu chcecie podyskutować o skrótach, śmiało się odezwijcie. Przysyłajcie swoje opinie, pytania, a nawet haiku o automatyzacji. W Samurai jesteśmy otwarci na wszystko. Do następnego razu — niech wasze katany będą ostre, a wasze procesy jeszcze ostrzejsze.
