Przepisywanie danych z dokumentu do systemu to jedna z najbardziej jałowych czynności, jakie ludzie robią w firmach. Ktoś bierze fakturę albo umowę, patrzy na numer, kwotę, datę, i przeklepuje to do programu. Godzinami, dzień w dzień. To jest dokładnie ten rodzaj roboty, który powinien robić komputer.
Budowałem narzędzia tego typu dla różnych typów dokumentów i dziś technologia jest na etapie, w którym to realnie działa, a nie tylko ładnie wygląda na demie. Poniżej jak to poskładać i gdzie są pułapki, bo jest ich kilka.
OCR czyta, AI rozumie
Trzeba rozdzielić dwie rzeczy, które często wrzuca się do jednego worka.
OCR, czyli optyczne rozpoznawanie znaków, zamienia obraz w tekst. Bierze skan albo zdjęcie i zwraca ciąg liter i cyfr, które na nim widać. Silniki jak Tesseract robią to od lat i robią to dobrze przy czytelnych dokumentach. Ale OCR daje Ci surowy tekst, bez wiedzy co znaczy. Nie wie, że ten konkretny ciąg cyfr to NIP, a tamta liczba to kwota brutto.
Tu wchodzi warstwa AI. Model językowy dostaje odczytany tekst i wyciąga z niego konkretne, uporządkowane dane. Rozpoznaje, że "5252219143" to numer NIP, że "1 230,00 zł" przy słowie "razem" to suma do zapłaty, że data przy słowie "termin" to termin płatności. OCR czyta, AI interpretuje. Dopiero połączenie obu daje coś użytecznego.
Przy dokumentach natywnie cyfrowych, czyli PDF-ach z tekstem, a nie skanem, krok OCR często odpada, bo tekst da się wyciągnąć wprost. Ale logika jest ta sama: najpierw tekst, potem interpretacja.
Dlaczego sztywny parser to ślepa uliczka
Klasyczne podejście bez AI to napisanie parsera pod konkretny szablon. Wiesz, że na fakturze od tego dostawcy NIP jest w prawym górnym rogu, a kwota w trzeciej linii od dołu, więc wycinasz te miejsca. Działa. Do momentu, gdy dostawca zmieni układ faktury albo dojdzie drugi dostawca z innym szablonem.
Wtedy zaczyna się koszmar utrzymania. Każdy nowy wariant dokumentu to nowy zestaw reguł, a każda zmiana układu to naprawianie tego, co działało. Widziałem procesy, gdzie połowa czasu szła na łatanie parserów pod kolejne warianty tego samego typu dokumentu.
Model językowy zmienia zasady gry, bo szuka danych po znaczeniu, a nie po pozycji. Nie obchodzi go, gdzie na stronie jest NIP, tylko rozpoznaje, że dany ciąg cyfr to NIP po jego formacie i kontekście. Ten sam mechanizm obsługuje fakturę w trzech różnych układach bez pisania trzech parserów. To jest realna przewaga, nie marketing.
Skąd się biorą błędy i jak je łapać
Żadne z tych narzędzi nie jest nieomylne i budowanie na założeniu, że jest, kończy się źle. Błędy wchodzą na dwóch etapach.
Na etapie OCR problem to jakość obrazu. Krzywy skan, blady wydruk, niska rozdzielczość, pieczątka na numerze - to wszystko obniża skuteczność rozpoznawania. Część da się nadrobić wstępną obróbką obrazu w Pythonie: prostowaniem, poprawą kontrastu, skalowaniem. Ale przy naprawdę kiepskich skanach lepiej poprawić sam proces skanowania niż liczyć, że algorytm zgadnie.
Na etapie interpretacji problem to pewność siebie modelu. Model potrafi podać błędną wartość w sposób, który wygląda na całkowicie pewny. Dlatego nigdy nie buduję tego jako czarnej skrzynki, która wrzuca dane wprost do systemu bez kontroli. Kluczowe pola i przypadki niepewne trafiają do szybkiej weryfikacji przez człowieka. Cel to zdjąć zdecydowaną większość żmudnej roboty, a nie ślepo ufać maszynie tam, gdzie błąd trafia prosto do księgowości.
W praktyce dobry setup pokazuje operatorowi odczytane dane obok skanu i pozwala poprawić jednym kliknięciem to, co się nie zgadza. To wciąż kilka sekund na dokument zamiast minuty przepisywania od zera.
RODO ustalasz na początku, nie na końcu
Dokumenty firmowe to bardzo często dane osobowe - imiona, nazwiska, adresy, numery. To znaczy, że sposób ich przetwarzania trzeba przemyśleć pod kątem RODO od pierwszego dnia projektu, a nie doklejać zgodność na końcu.
Praktycznie sprowadza się to do decyzji, gdzie dokumenty są przetwarzane. Można trzymać wszystko lokalnie, bez wysyłania czegokolwiek na zewnątrz. Można korzystać z API z jasnymi zapisami o nieprzechowywaniu i niewykorzystywaniu danych do trenowania. Wybór zależy od wrażliwości dokumentów i od tego, na co pozwala Twoja firma. To jeden z pierwszych tematów, które ustalam przy takim projekcie, bo determinuje całą architekturę.
Kiedy warto się w to bawić
Prosta miara: policz, ile dokumentów jednego typu przechodzi przez firmę w miesiącu i ile czasu zjada ich ręczne wprowadzanie. Jeśli to dziesiątki albo setki dokumentów i realne godziny pracy, automatyzacja zwraca się szybko. Jeśli to kilka dokumentów miesięcznie, koszt budowy i utrzymania narzędzia przewyższy oszczędność i lepiej zostać przy ręcznej robocie.
Dobry pierwszy kandydat to typ dokumentu, który przychodzi regularnie, ma powtarzalny zestaw danych do wyciągnięcia i dziś zajmuje kogoś na tyle, że to widać w grafiku. Faktury zakupowe, zamówienia, formularze, polisy - wszędzie tam, gdzie ktoś czyta i przeklepuje.
Masz taki proces i chcesz wiedzieć, czy da się go sensownie zautomatyzować? Podeślij kilka przykładowych dokumentów, obejrzę je i powiem wprost, co jest realne, a gdzie zaczną się schody.