LLM w analizie obrazów dokumentów: pipeline OCR→layout→ekstrakcja→walidacja (bez chaosu)

1. Wprowadzenie: dlaczego LLM do analizy obrazów dokumentów i gdzie są granice podejścia

Analiza obrazów dokumentów (skany, zdjęcia, PDF-y) przez lata była domeną klasycznych systemów OCR oraz reguł dopasowanych do konkretnych szablonów. Działało to dobrze w stabilnych warunkach, ale szybko „pękało” przy różnorodności: inne układy faktur, różne czcionki, pieczątki, odręczne dopiski, słaba jakość zdjęć, obrócone kadry czy zagniecenia. LLM wnoszą tu nową warstwę: zdolność rozumienia treści w kontekście i elastyczne wnioskowanie, które pozwala przejść od „rozpoznaj tekst” do „zrozum, co ten tekst oznacza w dokumencie”.

W praktyce LLM nie zastępują OCR, tylko pomagają w interpretacji wyników i w ekstrakcji informacji biznesowych z dokumentu. Największa różnica polega na tym, że zamiast budować dziesiątki kruchych reguł dla każdego typu dokumentu, można opisać oczekiwany rezultat (np. zestaw pól) i poprosić model o mapowanie treści na tę strukturę, z uwzględnieniem semantyki, relacji oraz typowych wariantów zapisu.

Co daje LLM w analizie dokumentów

• Ujednolicenie danych z różnych formatów: te same informacje mogą być zapisane w innym miejscu i innymi słowami; LLM potrafi je rozpoznać jako równoważne (np. „Nabywca” vs „Odbiorca”, „Kwota brutto” vs „Razem do zapłaty”).
• Odporność na różnorodność layoutu: modele lepiej radzą sobie z dokumentami, które nie trzymają jednego szablonu, oraz z drobnymi odchyleniami w układzie.
• Ekstrakcja informacji „ukrytej” w tekście: np. identyfikacja warunków płatności, waluty, numerów identyfikacyjnych czy ról stron, nawet gdy nie są oznaczone jednoznacznymi etykietami.
• Lepsza praca na niepełnych danych: kiedy OCR popełnia błędy, LLM czasem potrafi „domyślić się” właściwej interpretacji na podstawie kontekstu (co bywa zaletą, ale też ryzykiem).
• Naturalna obsługa języka: w dokumentach po polsku często występują odmiany, skróty, dopiski i sformułowania specyficzne dla branż; LLM może traktować to jako normalny język, a nie wyjątkowy przypadek.

Dlaczego to nadal jest trudne

Dokument to nie tylko tekst, ale też struktura: kolumny, tabele, podpisy, nagłówki, stopki, pola w formularzach, przypisy. Samo „przeczytanie” znaków nie wystarcza, bo znaczenie danych wynika często z położenia i relacji między elementami. Do tego dochodzą problemy jakościowe: rozmycie, szum, niska rozdzielczość, cień, odblaski, krzywa perspektywa czy częściowe zasłonięcie. W efekcie analizę dokumentów trzeba traktować jako proces wieloetapowy, w którym każdy krok ogranicza niepewność kolejnego.

Granice podejścia opartego o LLM

• Halucynacje i nadinterpretacja: LLM potrafi „uzupełnić” brakujące informacje w sposób przekonujący, ale nieprawdziwy. W dokumentach biznesowych jest to szczególnie niebezpieczne, bo poprawnie wyglądająca wartość może przejść dalej jako błąd merytoryczny.
• Wrażliwość na jakość wejścia: jeśli OCR zwróci zniekształcony tekst lub pominie kluczowe fragmenty, model może nie mieć podstaw do poprawnej ekstrakcji albo zacznie zgadywać.
• Niepewność bez jasnych sygnałów: wiele dokumentów zawiera wartości podobne do siebie (np. różne numery, daty, kwoty). LLM może pomylić role pól, jeśli kontekst jest niejednoznaczny.
• Ograniczenia w pracy na dużych dokumentach: długie umowy czy zestawienia mogą nie mieścić się w praktycznych limitach przetwarzania; konieczne jest dzielenie i kontrola spójności.
• Ryzyka zgodności i bezpieczeństwa: dokumenty zawierają dane wrażliwe, więc trzeba kontrolować przepływ danych, logowanie, anonimizację i zasady przetwarzania.
• Brak deterministyczności: te same dane wejściowe mogą dać nieco inne odpowiedzi; w zastosowaniach finansowych i księgowych potrzebna jest powtarzalność oraz twarde reguły kontroli.

Najbardziej praktyczne podejście to traktować LLM jako komponent „rozumienia i mapowania znaczenia”, a nie jako jedyne źródło prawdy. Model świetnie nadaje się do interpretacji i normalizacji treści, ale krytyczne elementy (spójność, arytmetyka, identyfikatory, reguły formalne) wymagają dodatkowych mechanizmów, które pilnują poprawności i pozwalają bezpiecznie obsłużyć niepewność.

2. Pipeline end-to-end: OCR → analiza layoutu → ekstrakcja → walidacja

Skuteczna analiza obrazów dokumentów rzadko jest „jednym promptem do LLM”. W praktyce działa podejście etapowe: najpierw zamieniasz piksele na tekst, potem rozumiesz strukturę strony, następnie wydobywasz dane do ustalonego formatu, a na końcu sprawdzasz, czy wynik ma sens biznesowy. Taki pipeline ogranicza chaos, bo każdy krok ma jasno zdefiniowane wejście, wyjście i kryteria jakości. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Warto myśleć o tym jako o przepływie od sygnału (obraz) do znaczenia (zweryfikowane dane). LLM jest szczególnie przydatny w etapach, gdzie potrzebna jest elastyczna interpretacja treści, ale nie powinien zastępować wszystkiego: OCR i część analizy układu to zwykle domena wyspecjalizowanych narzędzi, a walidacja powinna opierać się na deterministycznych regułach.

• Wejście: skan/zdjęcie/PDF jako obraz; opcjonalnie metadane (źródło, typ dokumentu, kontekst).
• Wyjście: ustrukturyzowany rekord (np. obiekt danych) + ślad pochodzenia (dowody: fragmenty tekstu, współrzędne, pewność) + status walidacji.

Poniżej przegląd etapów i typowego przepływu danych między nimi.

OCR: od pikseli do tekstu z geometrią

OCR dostarcza „surowy” tekst oraz informacje pomocnicze: pozycje słów/wierszy na stronie, czasem także miary pewności. To ważne, bo dalsze kroki często potrzebują nie tylko treści, ale też tego, gdzie ona występuje (np. nagłówek, stopka, kolumna w tabeli). Na tym etapie nie chodzi jeszcze o zrozumienie dokumentu, tylko o możliwie wierne odczytanie zawartości.

Dane między etapami: tekst + bounding boxy (i/lub hierarchia: strona → blok → linia → słowo) + ewentualne prawdopodobieństwa.

Analiza layoutu: „co jest czym” na stronie

Analiza layoutu porządkuje wynik OCR w elementy logiczne: bloki tekstu, nagłówki, sekcje, pola, listy, tabele i ich komórki. Ten krok odpowiada na pytania typu: czy liczby należą do tabeli, czy do stopki; gdzie zaczyna się sekcja podsumowania; które linie tworzą adres, a które warunki płatności. Dzięki temu ekstrakcja nie opiera się wyłącznie na ciągu znaków, tylko na strukturze dokumentu.

Dane między etapami: reprezentacja dokumentu z relacjami (np. elementy i ich role, kolejność czytania, grupowanie w wiersze/kolumny, przypisanie tekstu do regionów).

Ekstrakcja: mapowanie treści do pól danych

Ekstrakcja polega na przełożeniu treści dokumentu na ustalony model danych: np. identyfikatory, daty, kwoty, pozycje, dane stron transakcji. Tu często pojawia się LLM, bo potrafi elastycznie dopasować różne warianty zapisu do tych samych pól i poradzić sobie z niejednolitymi formatami. Kluczowe jest jednak to, by ekstrakcja była ukierunkowana: zdefiniowane pola, jasne granice tego, co wolno wywnioskować, i zachowanie odnośników do źródeł w dokumencie.

Dane między etapami: ustrukturyzowane pola + opcjonalnie dowody (cytaty/fragmenty, współrzędne) + ocena pewności lub oznaczenie braków.

Walidacja: spójność, kompletność i decyzja operacyjna

Walidacja odpowiada na pytanie, czy wynik ekstrakcji jest użyteczny i bezpieczny do dalszego przetwarzania. Obejmuje kontrolę spójności (np. sumy, formaty identyfikatorów, zależności między polami) oraz decyzję, co zrobić w przypadku niepewności: zaakceptować, odesłać do poprawy, ponowić przetwarzanie lub skierować do ręcznej weryfikacji. Ten etap jest zwykle deterministyczny i audytowalny, co stabilizuje pipeline oraz ogranicza ryzyko wynikające z probabilistycznych modeli.

Dane wyjściowe: rekord danych z flagami walidacji, listą wykrytych problemów, ewentualnie wymaganymi akcjami (np. retry, eskalacja) oraz śladem pochodzenia.

Jak te etapy łączą się w spójny przepływ

Najważniejsza zasada brzmi: każdy krok powinien zmniejszać niepewność i zwiększać uporządkowanie informacji. OCR zwiększa dostępność (tekst zamiast obrazu), layout zwiększa kontekst (struktura zamiast luźnych tokenów), ekstrakcja zwiększa użyteczność (pola zamiast narracji), a walidacja zwiększa zaufanie (decyzja zamiast domysłu).

• Separacja odpowiedzialności: narzędzia OCR/vision robią rozpoznanie, warstwa layoutu porządkuje, LLM pomaga z interpretacją, a reguły domykają jakość.
• Ślad pochodzenia: od początku warto przenosić informację „skąd to się wzięło” (fragment tekstu, region na stronie), bo ułatwia to debugowanie i obsługę wyjątków.
• Obsługa błędów i niekompletności: pipeline powinien tolerować braki (np. nieczytelny fragment) i umieć je oznaczyć, zamiast „wypełniać” je na siłę.
• Decyzje bramkujące: po wybranych krokach opłaca się wprowadzać proste progi jakości (np. czy OCR ma wystarczającą pewność), aby nie karmić kolejnych etapów danymi, które tylko wygenerują koszt i szum.

Tak złożony, ale klarowny pipeline pozwala wykorzystać moc LLM tam, gdzie ma największy sens, a jednocześnie utrzymać przewidywalność działania, audytowalność i kontrolę ryzyka.

3. OCR w praktyce: wybór narzędzi, preprocessing obrazu, język PL, jakość i typowe błędy

OCR to etap, który zamienia obraz (skan, zdjęcie, PDF) na tekst wraz z podstawowymi metadanymi (np. pozycja słów na stronie). W praktyce warto traktować go jak usługę pomiarową: dostarcza danych wejściowych do dalszych kroków, ale zawsze z pewnym poziomem szumu. Dobra konfiguracja OCR i prosty preprocessing często dają większy efekt niż „sprytniejsze” modele później.

Wybór narzędzi OCR: na co patrzeć

Narzędzia OCR różnią się podejściem (klasyczne vs. deep learning), zakresem zwracanych danych i zachowaniem na dokumentach o trudnym layoucie. Wybierając OCR do dokumentów biznesowych, oceniaj przede wszystkim:

• Jakość rozpoznania w PL (polskie znaki, fleksja, nazwy własne, skróty).
• Obsługę PDF: czy potrafi wykryć, że PDF ma warstwę tekstową (i ją wydobyć), czy zawsze robi OCR z rasteru.
• Zwracane metadane: bounding boxy dla słów/wierszy, kolejność czytania, poziomy pewności (confidence).
• Wydajność i koszt: przetwarzanie wsadowe, równoległość, limity, czas na stronę.
• Odporność na zdjęcia: perspektywa, cień, kompresja, szum.
• Możliwość strojenia: słowniki, whitelist/blacklist znaków, tryby segmentacji, detekcja orientacji.

Preprocessing obrazu: małe kroki, duży wpływ

Preprocessing powinien być minimalny i deterministyczny: poprawić czytelność bez „przerysowania” znaków. Najczęściej sprawdzają się proste operacje uruchamiane warunkowo (po ocenie jakości wejścia):

• Detekcja i korekcja orientacji (0/90/180/270) oraz ewentualnie delikatne prostowanie (deskew).
• Normalizacja kontrastu i redukcja tła (szczególnie dla zdjęć: cienie, gradienty).
• Odszumianie (lekka redukcja szumu kompresji) i wyostrzenie z umiarem.
• Dobór rozdzielczości: zbyt niska = utrata detali, zbyt wysoka = wolniej i czasem więcej artefaktów; praktycznie często celuje się w 200–300 DPI dla tekstu drukowanego.
• Kadrowanie do obszaru dokumentu (usunięcie tła stołu) oraz korekcja perspektywy przy zdjęciach.

Antywzorzec: agresywne progowanie/binaryzacja „na sztywno”, które świetnie działa na jednych skanach, a na innych „zjada” cienkie fonty, przecinki i ogonki polskich znaków.

Język polski: diakrytyki, fleksja i „specyficzne” ciągi

Dla PL największe różnice jakościowe wynikają z poprawnego ustawienia języka/modelu oraz świadomości, że w dokumentach występują obok siebie: polszczyzna, liczby, skróty, kody i nazwy własne.

• Polskie znaki: błędy w „ą/ę/ł/ń/ś/ź/ż/ó” potrafią psuć dopasowania słownikowe i reguły (np. adresy, nazwy ulic).
• Fleksja i odmiany: OCR nie „rozumie” języka, więc warto unikać nadmiernych korekt słownikowych, jeśli dokument zawiera wiele nazw własnych.
• Ciągi formalne (NIP, REGON, IBAN, numery faktur): tu bardziej liczy się poprawność znaków i separacji niż „ładny” tekst.
• Waluta i formaty: „1 234,56” vs „1,234.56”, „zł” vs „PLN” – OCR często myli separator tysięcy i przecinek/kropkę.

Praktyczna wskazówka: jeżeli przetwarzasz dokumenty z mieszanką PL/EN (np. nazwy towarów, warunki dostaw), rozważ tryb wielojęzyczny lub osobne profile OCR zależnie od typu dokumentu.

Jak mierzyć jakość OCR (bez wchodzenia w akademickie metryki)

Zamiast polegać na „subiektywnie wygląda OK”, ustal prosty zestaw wskaźników, które korelują z tym, czy downstream zadziała:

• Coverage pól krytycznych: czy da się odzyskać datę, kwoty, identyfikatory, nazwy kontrahentów.
• Stabilność na źródłach: skany z systemów, zdjęcia z telefonu, PDF-y generowane, kopie kser.
• Poziomy pewności (jeśli dostępne): średnia i rozkład confidence dla tokenów/liczb.
• Wskaźnik błędów w liczbach: procent dokumentów, gdzie zmienia się wartość liczbowa (to zwykle najbardziej kosztowne pomyłki).

W praktyce najważniejsze jest odróżnienie: „tekst jest czytelny dla człowieka” od „tekst jest jednoznaczny dla maszyn”. OCR może dać wynik „sensowny”, ale z pojedynczą pomyłką w cyfrze, która psuje cały rekord.

Typowe błędy OCR na dokumentach i jak je ograniczać

• Mylenie podobnych znaków: 0/O, 1/I/l, 5/S, 8/B, „rn” vs „m”, „-” vs „–”. Ograniczanie: lepsza rozdzielczość, ostrożne wyostrzenie, profile dla pól numerycznych.
• Separatory i interpunkcja: przecinek jako kropka, gubienie przecinków w kwotach, sklejanie „12,34zł”. Ograniczanie: preprocessing kontrastu, późniejsza normalizacja formatów liczbowych.
• Łamanie wierszy i kolejność czytania: tekst z kolumn miesza się, nagłówki wpadają w środek zdań. Ograniczanie: poprawna segmentacja/tryb strony, zachowanie współrzędnych i niepoleganie wyłącznie na „plain text”.
• Tabele: przesunięcia kolumn, gubienie linii, scalanie komórek. Ograniczanie: OCR z metadanymi pozycji, unikanie rekonstrukcji tabel z samego tekstu.
• Stemple, podpisy, pieczątki: wchodzą w tekst, powodują „śmieciowe” tokeny. Ograniczanie: detekcja i maskowanie elementów graficznych, łagodniejsze odszumianie.
• Artefakty skanera: ciemne krawędzie, ukośne skany, moiré. Ograniczanie: deskew, przycięcie marginesów, filtry redukujące wzór tła.

Minimalny przykład: OCR jako krok w pipeline

Poniższy przykład pokazuje ideę: najpierw starasz się wydobyć tekst z PDF (jeśli istnieje warstwa tekstowa), a dopiero w razie potrzeby robisz OCR na obrazie. To zwykle skraca czas i redukuje błędy.

# Pseudokod
if pdf_has_text_layer(file):
    text, boxes = extract_text_layer(file)
else:
    images = render_pdf_to_images(file, dpi=300)
    images = preprocess(images)  # deskew, contrast, crop
    text, boxes, conf = run_ocr(images, lang="pol")

# dalej: zapis wyników OCR + metadanych (np. boxy, confidence) do wspólnego formatu
store_ocr_result(text=text, boxes=boxes, confidence=conf)

Kluczowe jest przechowanie nie tylko „gołego” tekstu, ale też informacji o położeniu i (o ile się da) pewności rozpoznania. To pozwala później podejmować decyzje: co traktować jako wiarygodne, a co wymaga ostrożności.

4. Analiza layoutu i reprezentacja dokumentu: segmentacja, tabele, pola, relacje i formaty

Samo OCR daje ciąg znaków, ale w dokumentach biznesowych kluczowy jest układ: gdzie jest nagłówek, gdzie dane kontrahenta, które liczby należą do tabeli pozycji, a które do podsumowania. Analiza layoutu to etap, który zamienia „tekst na stronie” w strukturę (bloki, wiersze, kolumny, pola) oraz w relacje między elementami. Bez tego ekstrakcja bywa krucha: model lub reguły „łapią” poprawne słowa, ale przypisują je do złych pól.

W Cognity omawiamy to zagadnienie zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

4.1 Segmentacja: od strony do bloków semantycznych

Segmentacja odpowiada na pytanie: jakie obszary istnieją na stronie i jaką pełnią rolę? Typowe segmenty to m.in. nagłówek dokumentu, sekcja danych sprzedawcy/nabywcy, tabela pozycji, stopka, adnotacje/uwagi, pieczęcie/podpisy. W praktyce segmentacja opiera się na:

• geometrii (ramki/bounding boxy, odstępy, wyrównania, kolumny),
• wzorcach typograficznych (rozmiar czcionki, pogrubienia, linie, separatory),
• sygnałach językowych (np. etykiety typu „NIP”, „Razem”, „Termin płatności”),
• kontekście stron (pierwsza strona vs kolejne; ciągłość tabeli w multi-page).

Ważne jest rozróżnienie: segmentacja fizyczna (bloki na obrazie) vs segmentacja semantyczna (co ten blok znaczy). Często najpierw buduje się segmenty fizyczne, a dopiero potem przypisuje im role.

4.2 Tabele: dlaczego są osobnym problemem

Tabele to najczęstsze źródło błędów w ekstrakcji, bo wymagają odczytu struktury siatki (wiersze/kolumny) i mapowania komórek do nagłówków. W dokumentach spotyka się różne odmiany:

• tabele z liniami (łatwiejsze do wykrycia),
• tabele bez linii (oparte na wyrównaniu i odstępach),
• tabele mieszane (część kolumn ma separatory, część nie),
• tabele „łamane” (nagłówki na końcu strony, kontynuacja na następnej),
• tabele z kolumnami opcjonalnymi (np. rabat, PKWiU, GTU) i z wieloliniowymi opisami pozycji.

Na tym etapie nie chodzi jeszcze o interpretację biznesową (to będzie dalej), tylko o uzyskanie stabilnej reprezentacji: komórka → tekst + współrzędne + (wiersz, kolumna) + nagłówek. Dzięki temu ekstrakcja nie musi „zgadywać”, czy liczba 23,00 to cena jednostkowa czy wartość netto.

4.3 Pola (key-value): etykieta, wartość i ich powiązanie

W wielu dokumentach dominują pola typu key-value (np. „NIP: …”, „Data wystawienia: …”). Wyzwanie polega na przypisaniu wartości do właściwej etykiety, zwłaszcza gdy:

• etykieta i wartość są w różnych wierszach lub kolumnach,
• wartość jest wieloelementowa (np. adres, nazwa firmy),
• na stronie występują powtórzenia tej samej etykiety (np. NIP sprzedawcy i NIP nabywcy),
• etykiety są skrótowe lub niejednoznaczne („Nr”, „Data”, „Suma”).

Dlatego reprezentacja layoutu powinna przechowywać nie tylko tekst, ale też relacje przestrzenne: „wartość na prawo od etykiety”, „wartość poniżej”, „wartość w tej samej kolumnie”. To jest fundament do późniejszej ekstrakcji odpornej na warianty szablonów.

4.4 Relacje i kolejność czytania: nie tylko „od góry do dołu”

Dokumenty często mają układ wielokolumnowy, bloki boczne, stopki z drobnym drukiem czy wstawki (np. adnotacje). Sam porządek OCR bywa przypadkowy, więc etap layoutu powinien ustalić:

• kolejność czytania (reading order) dla bloków i linii,
• hierarchię (sekcja → blok → linia → token),
• powiązania (etykieta ↔ wartość, nagłówek tabeli ↔ kolumny, suma ↔ pozycje),
• przynależność do strony i ciągłość w dokumentach wielostronicowych.

To, jak zdefiniujesz relacje, wpływa na resztę pipeline’u: im lepiej odtworzona struktura, tym mniej „magii” musi wykonywać później model językowy.

4.5 Format reprezentacji: blok/JSON/HTML/PDF coords — co i po co

Reprezentacja dokumentu to kontrakt między etapami: OCR → layout → ekstrakcja → walidacja. W praktyce spotyka się kilka formatów (często łączonych), różniących się wiernością względem źródła i łatwością użycia.

W praktyce dobrze działa podejście hybrydowe: JSON jako format „prawdy”, a obok niego renderowalny widok (np. HTML) oraz kotwice geometryczne (bbox/coords) do audytu i korekt.

4.6 Minimalny, użyteczny schemat (przykład)

Poniższy przykład pokazuje minimalną reprezentację łączącą tekst, geometrię i strukturę — bez wchodzenia w logikę ekstrakcji:

{
  "document_id": "...",
  "pages": [
    {
      "page": 1,
      "size": {"w": 2480, "h": 3508},
      "blocks": [
        {
          "id": "b1",
          "type": "key_value",
          "bbox": [120, 220, 980, 420],
          "key": {"text": "NIP", "bbox": [130, 240, 210, 280]},
          "value": {"text": "123-456-78-90", "bbox": [260, 240, 520, 280]}
        },
        {
          "id": "t1",
          "type": "table",
          "bbox": [120, 900, 2360, 2600],
          "header": ["Nazwa", "Ilość", "Cena", "Wartość"],
          "cells": [
            {"r": 0, "c": 0, "text": "Usługa ...", "bbox": [140, 1020, 1400, 1100]},
            {"r": 0, "c": 1, "text": "1", "bbox": [1420, 1020, 1600, 1100]}
          ]
        }
      ],
      "reading_order": ["b1", "t1"]
    }
  ]
}

Najważniejsze jest, aby taki schemat umożliwiał: (1) jednoznaczne wskazanie źródła (bbox), (2) stabilne grupowanie (blok/tabela), (3) podstawowe relacje (key↔value, komórka↔nagłówek, kolejność czytania). Reszta może być iteracyjnie rozwijana wraz z wymaganiami.

5. Ekstrakcja danych z pomocą LLM: promptowanie, function calling, JSON Schema, odporność na halucynacje i niepewność

LLM sprawdzają się w ekstrakcji danych z dokumentów wtedy, gdy sam tekst z OCR i struktura layoutu nie wystarczają do prostej, deterministycznej reguły. Model potrafi zrozumieć kontekst (np. że „Do zapłaty” to suma końcowa, a „Razem” w tabeli to suma pozycji), poradzić sobie z wariantami językowymi i formatami, a także mapować treść na ustandaryzowane pola. Jednocześnie to podejście ma granice: LLM potrafi „dopowiedzieć” brakujące dane, mylić się w liczbach, albo zbyt pewnie interpretować nieczytelne fragmenty. Dlatego ekstrakcję z LLM warto projektować jako proces kontraktowy (jasny format wyjścia) i kontrolowany (jawne sygnalizowanie niepewności).

LLM jako „mapper” i „normalizer”, nie jako źródło prawdy

W praktyce LLM pełni rolę warstwy interpretacji: bierze wejście (tekst OCR + sygnały layoutu + metadane) i mapuje je do pól biznesowych. Kluczowe jest rozdzielenie dwóch zadań:

• Ekstrakcja: znalezienie wartości w materiale wejściowym (np. numer faktury, data, kwoty, NIP).
• Normalizacja: ujednolicenie formatu (np. daty do ISO, kwoty do liczby, waluta do kodu, separatory tysięcy).

LLM jest dobre w obu, ale normalizacja powinna być ograniczona do przewidywalnych transformacji (formatowanie, usuwanie spacji, standardowe skróty). Jeśli model nie ma pewności, powinien zwrócić brak lub kandydata z niską pewnością, a nie „najbardziej prawdopodobną” wartość.

Promptowanie: instrukcje, kontekst i zasada „nie zgaduj”

Skuteczne promptowanie w ekstrakcji to nie „ładne polecenie”, tylko zestaw twardych reguł, które minimalizują kreatywność:

• Jawnie zdefiniuj pola i dozwolone wartości (np. waluta: PLN/EUR/USD; typ dokumentu: faktura/paragon/umowa).
• Ogranicz źródła: model ma opierać się wyłącznie na dostarczonym tekście i/lub strukturze, bez wiedzy zewnętrznej.
• Zabroń zgadywania: jeśli brakuje danych lub tekst jest niejednoznaczny, model zwraca null/"unknown" oraz opis powodu.
• Wymuś cytowanie dowodu: dla kluczowych pól zwróć fragment źródłowy (np. linia OCR lub wycinek tekstu) jako „evidence”.
• Oddziel ekstrakcję od wnioskowania: jeśli potrzebne są wyliczenia, traktuj je jako osobny krok (najlepiej poza modelem lub z dodatkową walidacją).

Warto też podawać modelowi „kontekst strukturalny” (np. bloki tekstu z nagłówków, stopki, tabel), bo sama surowa lista linii OCR utrudnia rozróżnienie sekcji dokumentu.

Function calling vs. „czysty JSON” w odpowiedzi

Są dwa popularne sposoby wymuszenia struktury wyniku:

W produkcji najczęściej wygrywa function calling (lub analogiczny mechanizm), bo ogranicza klasę błędów do „wartość może być zła”, zamiast „nie da się sparsować odpowiedzi”.

JSON Schema jako kontrakt: typy, ograniczenia i kompletność

JSON Schema działa jak umowa pomiędzy modelem a systemem: definiuje, jakie pola mają się pojawić, jakie mają typy, które są wymagane, jakie mają dopuszczalne zakresy i formaty. To jest szczególnie ważne dla danych liczbowych i dat, gdzie „prawie dobrze” oznacza w praktyce błąd.

• Typy: liczby jako number (nie string), daty jako string w formacie ISO, identyfikatory jako string.
• Wymagalność: rozdziel pola „must-have” od „nice-to-have”, żeby model nie uzupełniał braków fikcją.
• Enumeracje: waluta, typ dokumentu, kraj, status — ograniczają warianty i ułatwiają downstream.
• Struktury złożone: pozycje w tabeli jako lista obiektów, a nie jeden tekstowy blok.

Nawet przy schemacie konieczne jest podejście „trust but verify”: walidacja schematu sprawdza formę, nie prawdziwość. Dlatego do wyniku warto dodawać metadane o jakości.

Odporność na halucynacje: techniki, które ograniczają „dopowiadanie”

Halucynacje w ekstrakcji dokumentów najczęściej mają postać: (1) uzupełnienia brakującego numeru/daty, (2) poprawienia kwoty „na oko”, (3) pomylenia pól o podobnych etykietach. Żeby to ograniczyć, stosuje się kilka prostych, ale skutecznych zasad:

• Evidence-first: wymagaj dla kluczowych pól wskazania fragmentu źródła (tekst) oraz opcjonalnie lokalizacji (np. identyfikator bloku). Brak evidence → pole powinno być null.
• Konserwatywne domyślne wartości: zamiast domyślać się waluty czy kraju, zwracaj „unknown” lub null.
• Rozdzielenie ról: jeden krok/wywołanie do ekstrakcji, osobny do sanity-check i wykrycia sprzeczności (model jako „audytor” własnego wyniku).
• Ograniczenie kontekstu: podawaj modelowi tylko te fragmenty OCR, które należą do analizowanego dokumentu/strony; mniej szumu → mniej błędnych skojarzeń.
• Wymuszenie spójności typów: jeśli kwota ma być liczbą, nie akceptuj tekstu z walutą; waluta jako osobne pole.

Niepewność jako element wyniku: confidence, status i alternatywy

W ekstrakcji dokumentów niepewność jest normalna (słaba jakość skanu, ucięte strony, błędy OCR, nietypowy układ). Zamiast udawać pewność, warto modelowi pozwolić (i wymusić), by zwracał sygnały jakości. Minimalny zestaw praktycznych pól:

• confidence per pole (np. 0–1 lub low/medium/high) — subiektywna ocena modelu, ale użyteczna do progów.
• extraction_status: extracted / missing / ambiguous / illegible.
• candidates (opcjonalnie): lista 2–3 możliwych wartości, jeśli występuje konflikt (np. dwie daty w pobliżu nagłówka).
• reason: krótki opis, dlaczego pole jest niepewne (np. „dwa podobne numery obok siebie”).

Taki model wyniku pozwala później podejmować decyzje: automatycznie akceptować pewne przypadki, kierować niepewne do weryfikacji, albo uruchamiać dodatkowy krok odzyskania danych.

Minimalny przykład kontraktu (schemat + function calling)

{
  "name": "extract_document_fields",
  "description": "Extract key fields from OCR text and layout blocks. Do not guess; return null when missing.",
  "parameters": {
    "type": "object",
    "properties": {
      "document_type": {"type": "string", "enum": ["invoice", "receipt", "contract", "unknown"]},
      "invoice_number": {"type": ["string", "null"]},
      "issue_date": {"type": ["string", "null"], "description": "ISO-8601 date: YYYY-MM-DD"},
      "total_gross": {"type": ["number", "null"]},
      "currency": {"type": ["string", "null"], "enum": ["PLN", "EUR", "USD", null]},
      "evidence": {
        "type": "object",
        "properties": {
          "invoice_number": {"type": ["string", "null"]},
          "total_gross": {"type": ["string", "null"]}
        }
      },
      "quality": {
        "type": "object",
        "properties": {
          "confidence": {"type": "number", "minimum": 0, "maximum": 1},
          "notes": {"type": "string"}
        },
        "required": ["confidence"]
      }
    },
    "required": ["document_type", "quality"]
  }
}

To nie jest „kompletna recepta”, ale pokazuje kierunek: twardy format, null zamiast zgadywania, oraz evidence + quality jako podstawowe bezpieczniki.

6. Walidacja biznesowa i reguły spójności: sumy/VAT, NIP/REGON, daty, waluta, kontrole krzyżowe i wyjątki

Po etapie ekstrakcji (niezależnie czy wykonanej klasycznie, czy z pomocą LLM) dane z dokumentu są wciąż hipotezą: mogą zawierać błędy OCR, pomyłki w interpretacji pól, brakujące wartości lub niespójności. Walidacja biznesowa ma dwa cele: (1) wykryć niespójności zanim trafią do systemów księgowych/ERP, oraz (2) zamienić „niepewne” na „kontrolowane” — poprzez reguły, tolerancje i obsługę wyjątków.

W praktyce warto rozdzielić dwie warstwy:

• Walidacja techniczna — czy wartości mają poprawny typ/format (np. data, liczba, waluta, checksum NIP), czy pole nie jest puste.
• Walidacja biznesowa — czy wartości mają sens w kontekście dokumentu i siebie nawzajem (np. sumy VAT, zgodność waluty, relacje między datami, zgodność stawki VAT z kwotami).

Najczęstsze obszary walidacji

Sumy, VAT i arytmetyka: waliduj relacje, nie tylko pola

Najbardziej „opłacalna” walidacja to sprawdzanie relacji arytmetycznych, bo błędy zwykle ujawniają się jako niespójność. Warto myśleć o tym jak o zestawie równań, które mogą być spełnione na kilka sposobów (np. dokument może mieć stawki mieszane albo rabaty).

• Pozycje → podsumowanie: suma netto pozycji ≈ netto w podsumowaniu, analogicznie VAT i brutto.
• Netto + VAT = brutto: z uwzględnieniem zaokrągleń (tolerancja na grosze).
• Stawka VAT: jeśli jest podana, kwota VAT powinna wynikać z netto i stawki w granicach tolerancji.
• Wiele stawek: walidacja per stawka (np. 8% i 23%) oraz łącznie.

Praktyczna wskazówka: walidacja powinna operować na liczbach znormalizowanych (separator tysięcy, przecinek/kropka), a tolerancje definiować jawnie (np. 0.01–0.05 w zależności od złożoności dokumentu i sposobu zaokrągleń).

NIP/REGON: szybkie testy, które ratują jakość

Identyfikatory są podatne na błędy OCR (O/0, I/1, B/8). Zamiast odrzucać od razu, walidacja może rozróżnić: „na pewno błędne” vs „podejrzane” i uruchomić korekty/eskalację.

• NIP: 10 cyfr + weryfikacja sumy kontrolnej (po usunięciu separatorów).
• REGON: 9 lub 14 cyfr + suma kontrolna.
• VAT UE: prefiks kraju + format krajowy (często wymaga innej walidacji niż „czysty” NIP).

// Szkic: walidacja formatu i podstawowych checksum (bez szczegółów implementacyjnych)
function validateNIP(nipRaw) {
  const nip = nipRaw.replace(/[^0-9]/g, "");
  if (nip.length !== 10) return { ok: false, reason: "length" };
  // ... checksum ...
  return { ok: true };
}

Daty: porządek zdarzeń i tolerancje

Dokumenty często zawierają kilka dat (wystawienia, sprzedaży/wykonania, terminu płatności). Sama poprawność formatu nie wystarcza — kluczowa jest logika kolejności i reguły specyficzne dla organizacji.

• Poprawność kalendarzowa: 2025-02-30 jest błędne niezależnie od kontekstu.
• Relacje: termin płatności zwykle ≥ data wystawienia; data sprzedaży zwykle ≤ data wystawienia (ale nie zawsze).
• Brak roku: częsty przypadek w skanach; walidacja powinna oznaczyć niepewność, a nie „zgadywać w ciemno”.

Waluta i liczby: normalizacja zanim ocenisz

W walidacji finansowej krytyczne jest rozdzielenie dwóch rzeczy: jak zapisano (np. „1 234,56”, „1,234.56”, „1234,56 PLN”) oraz co to znaczy. Najpierw normalizacja, potem reguły.

• Spójność waluty: jedna waluta dla całego dokumentu albo jawne sekcje (np. kwoty w EUR, przeliczenie w PLN).
• Separator dziesiętny: częste źródło błędów — waliduj, czy kwoty nie są „nielogicznie” duże/małe.
• Kursy: jeśli występują, kontroluj sensowny zakres i spójność przeliczeń (z tolerancją).

Kontrole krzyżowe: wykrywanie „przypięcia” pól do złej strony

W dokumentach (np. fakturach) dane sprzedawcy i nabywcy bywają w podobnych blokach. Błąd ekstrakcji często nie psuje formatu, tylko przypisanie. Kontrole krzyżowe pomagają to wykryć:

• Kraj ↔ identyfikator: prefiks VAT UE/kod kraju powinien pasować do formatu identyfikatora.
• Kod pocztowy ↔ miejscowość: przynajmniej kontrola formatu i obecności, a niekoniecznie pełna zgodność słownikowa.
• Numer rachunku: kontrola długości/formatu (np. IBAN), a także spójność z walutą/typem płatności, jeśli jest podany.

Obsługa wyjątków: nie wszystko da się „wcisnąć” w jedną regułę

Walidacje muszą przewidywać dokumenty, które są poprawne, ale nietypowe: korekty (wartości ujemne), rabaty, zaliczki, odwrotne obciążenie, zwolnienia z VAT, split payment, faktury pro-forma itp. Zamiast rozbudowywać jedną „mega-regułę”, lepiej stosować:

• Profile walidacji zależne od typu dokumentu (inny zestaw reguł i progów).
• Poziomy ważności: błąd krytyczny (blokuje) vs ostrzeżenie (wymaga akceptacji).
• Wyjaśnialne rezultaty: każda reguła powinna zwracać „co nie gra” i „które pola” — to przyspiesza poprawki.

Jak „dogadać” walidację z LLM

LLM jest świetny w ekstrakcji i interpretacji, ale walidacja powinna być w dużej mierze deterministyczna. Najpraktyczniejszy podział ról:

• Reguły deterministyczne liczą i sprawdzają spójność (sumy, checksumy, formaty, relacje dat).
• LLM może pomóc w diagnozie: gdy reguła nie przechodzi, zasugerować które pole najpewniej jest błędnie odczytane, albo wskazać alternatywną interpretację (np. rozróżnić netto/brutto w nietypowym układzie).

Efektem sekcji walidacji nie powinno być wyłącznie „OK/FAIL”, lecz raport spójności: lista reguł, statusów, pól powiązanych, tolerancji oraz rekomendacji (automatyczna korekta, ponowna ekstrakcja, eskalacja do człowieka). Taka warstwa domyka pipeline i znacząco ogranicza ryzyko, że LLM (lub OCR) wprowadzi błąd, który wygląda wiarygodnie, ale nie przechodzi podstawowej logiki księgowej.

7. Przykładowy pipeline produkcyjny: architektura, orkiestracja, retry, human-in-the-loop, bezpieczeństwo i zgodność

W produkcji analiza obrazów dokumentów to nie pojedyncze wywołanie modelu, tylko łańcuch usług, które muszą być odporne na zmienność jakości skanów, różnorodność formatów i realia operacyjne (SLA, koszty, audyt, prywatność). Kluczowe jest zaprojektowanie pipeline’u tak, aby minimalizować ryzyko błędów (zwłaszcza cichych), umożliwiać szybkie poprawki oraz zapewniać ścieżkę eskalacji tam, gdzie automatyzacja nie ma wystarczającej pewności.

Architektura: rozdzielenie etapów i odpowiedzialności

Typowy pipeline produkcyjny opiera się na modularności: każdy etap (wejście pliku, obróbka obrazu, rozpoznanie tekstu, analiza struktury, ekstrakcja, walidacja, zapis wyników) działa jako osobny komponent z jasnym kontraktem wejście/wyjście. To pozwala wymieniać narzędzia bez przebudowy całości oraz łatwiej diagnozować, gdzie powstaje błąd (np. czy wynika z jakości skanu, czy z interpretacji treści).

• Warstwa ingestu: odbiera dokumenty z różnych kanałów (API, e-mail, SFTP, folder), nadaje identyfikator, zapisuje surowy plik i metadane.
• Warstwa przetwarzania: wykonuje kroki transformacji i analizy, utrzymując spójne reprezentacje pośrednie (np. tekst, bloki, współrzędne, wykryte pola).
• Warstwa domenowa: stosuje reguły biznesowe, kontrolę spójności i buduje finalny rekord do systemu docelowego (ERP, księgowość, CRM).
• Warstwa obserwowalności: metryki, logi, ślady, raporty jakości, dashboardy operacyjne.

W praktyce ważne jest rozdzielenie przetwarzania wsadowego (np. archiwa) od trybu online (np. faktury przychodzące w ciągu dnia). Online preferuje krótsze ścieżki i limity czasowe; wsad pozwala na cięższe kroki, większą równoległość i dogłębne raportowanie.

Orkiestracja: kolejki, idempotencja i kontrola przepływu

Orkiestracja powinna wspierać asynchroniczność i odporność na awarie. Dokument nie może „zniknąć” w połowie procesu; powinien zawsze kończyć w stanie: przetworzony, odrzucony z powodem albo skierowany do weryfikacji.

• Kolejkowanie zadań: każdy etap publikuje wynik do kolejki/tematu, a następny etap subskrybuje; ułatwia skalowanie i izoluje awarie.
• Idempotencja: powtórne uruchomienie tego samego kroku nie może tworzyć duplikatów ani nadpisywać danych w niekontrolowany sposób.
• Stan przetwarzania: przechowywany centralnie (np. statusy, timestampy, wersje wyników), aby wznowienia i audyt były proste.
• Limitowanie kosztów: sterowanie równoległością oraz budżetami (np. maksymalna liczba prób na dokument, maksymalny czas na etap).

Dobrą praktyką jest traktowanie reprezentacji pośrednich jako artefaktów: zachowujesz je (przynajmniej przez pewien czas), by móc odtworzyć wynik, porównać wersje i regresyjnie testować zmiany.

Retry i odporność: kiedy ponawiać, a kiedy eskalować

W pipeline’ach dokumentowych retry jest nieunikniony, ale musi być kontrolowany. Inny rodzaj retry stosuje się przy chwilowych problemach infrastruktury, a inny przy niskiej jakości danych wejściowych.

• Retry techniczny: na błędy sieci, limity API, timeouty; zwykle z backoffem i ograniczeniem liczby prób.
• Retry jakościowy: przy słabym skanie można ponowić analizę z innymi parametrami (np. alternatywny preprocessing, inny wariant OCR), ale tylko jeśli to ma sens kosztowo.
• Fallback: jeśli narzędzie A zawodzi (np. w tabelach), przełączasz się na narzędzie B lub na prostszą ścieżkę o mniejszej dokładności, ale większej stabilności.
• Stop conditions: jasno zdefiniowane kryteria, kiedy kończysz automatyzację i przekazujesz dokument do człowieka.

Największym ryzykiem są błędy „ciche” (system zwraca wynik, ale błędny). Dlatego retry nie powinno polegać wyłącznie na „spróbuj jeszcze raz”, tylko na świadomych regułach, które reagują na sygnały jakości i spójności.

Human-in-the-loop: minimalna interwencja, maksymalna pewność

Weryfikacja manualna w produkcji nie oznacza porażki automatyzacji — to element kontroli ryzyka. Kluczem jest zaprojektowanie jej tak, by człowiek dostawał konkretne decyzje do podjęcia, a nie cały dokument do przepisania.

• Routing na podstawie pewności: dokumenty o niskiej pewności lub z naruszeniami reguł trafiają do kolejki weryfikacyjnej.
• Widok z kontekstem: operator powinien widzieć fragment obrazu powiązany z polem oraz ślad, skąd pochodzi wartość.
• Walidacja punktowa: zamiast sprawdzać wszystko, operator zatwierdza tylko pola „sporne” (np. kwoty, NIP, numer faktury).
• Uczenie procesowe: poprawki człowieka wracają do systemu jako dane do analizy jakości, reguł i testów regresyjnych.

Ważne jest też mierzenie operacyjne: ile dokumentów wymagało interwencji, jakie były typowe przyczyny i które typy dokumentów generują najwięcej pracy. To bezpośrednio przekłada się na priorytety usprawnień.

Bezpieczeństwo: dane wrażliwe, kontrola dostępu i izolacja

Dokumenty (faktury, umowy, wnioski) często zawierają dane wrażliwe, więc pipeline musi być zaprojektowany z myślą o bezpieczeństwie od początku. Minimalizujesz ekspozycję danych, ograniczasz dostęp i utrzymujesz spójny ślad audytowy.

• Segmentacja dostępu: role i uprawnienia do dokumentów, wyników oraz logów (zasada najmniejszych uprawnień).
• Szyfrowanie: w tranzycie i w spoczynku; szczególnie dla magazynu plików i baz wyników.
• Redakcja/anonimizacja: ograniczanie danych w logach i telemetryce; unikanie zapisywania pełnych treści, jeśli nie jest to konieczne.
• Izolacja środowisk: oddzielenie dev/test/prod oraz kontrola, jakie dane mogą trafić do testów.
• Zarządzanie kluczami i sekretami: rotacja, audyt użycia, brak sekretów w konfiguracjach aplikacji.

Jeśli korzystasz z modeli zewnętrznych, musisz jasno określić, jakie dane mogą być wysyłane poza organizację oraz jakie są zasady retencji i dalszego przetwarzania.

Zgodność i audyt: ślad decyzji i reprodukowalność

W procesach księgowych i administracyjnych liczy się możliwość wyjaśnienia „dlaczego system tak zdecydował”. Pipeline powinien wspierać audyt zarówno techniczny, jak i biznesowy.

• Provenance danych: skąd pochodzi każda wartość (źródłowy dokument, strona, obszar, etap przetwarzania).
• Wersjonowanie: wersje konfiguracji, modeli i reguł, aby móc odtworzyć wynik historyczny.
• Retencja: polityki przechowywania surowych plików i artefaktów pośrednich zgodnie z wymaganiami prawnymi i wewnętrznymi.
• Rejestrowanie zdarzeń: kto i kiedy zatwierdził/zmienił dane (także w HITL), oraz dlaczego dokument został odrzucony.

Z perspektywy organizacji ważne jest także zarządzanie ryzykiem: klasyfikacja dokumentów według krytyczności, różne poziomy wymagań jakości i różne ścieżki akceptacji.

Co sprawia, że pipeline działa „bez chaosu”

• Jasne kontrakty między etapami i stabilne formaty wyników.
• Wbudowana kontrola jakości oraz reguły stop/eskalacja zamiast bezrefleksyjnych ponowień.
• Obserwowalność: metryki kosztu, czasu, skuteczności i przyczyn błędów.
• Kontrolowana interwencja człowieka z minimalnym wysiłkiem i maksymalnym kontekstem.
• Bezpieczeństwo i audyt jako element projektu, a nie dodatek na końcu.

8. Metryki jakości i monitoring: OCR CER/WER, dokładność pól, kompletność, walidowalność, latency, koszt i drift

Pipeline OCR→layout→ekstrakcja→walidacja jest tak dobry, jak jego mierzalność. Bez spójnych metryk łatwo pomylić „ładnie wyglądający wynik” z wynikiem, który da się bezpiecznie automatyzować. Monitoring powinien obejmować zarówno jakość merytoryczną (czy dane są poprawne), jak i operacyjną (czy system działa stabilnie, szybko i przewidywalnie kosztowo), a także perspektywę ryzyka (czy model i dane nie „odpływają” w czasie).

Metryki jakości OCR: CER i WER

Na wejściu całego procesu stoi OCR, więc warto mieć metryki, które opisują ile i jakiego rodzaju błędów w tekście powstaje już na starcie. Dwie najczęściej stosowane miary to:

• CER (Character Error Rate) — odsetek błędów na poziomie znaków. Dobrze wychwytuje problemy z pojedynczymi znakami (np. O/0, l/1, polskie znaki), które potrafią „zepsuć” NIP, kwotę czy numer konta.
• WER (Word Error Rate) — odsetek błędów na poziomie słów. Lepiej oddaje problemy z segmentacją i tokenizacją, np. łączenie/rozrywanie wyrazów, gubienie spacji, błędy w nazwach własnych.

W praktyce CER/WER są najbardziej użyteczne, gdy są raportowane per typ dokumentu, per źródło skanu (np. skan vs zdjęcie), oraz per klasa jakości obrazu (np. rozmycie, przekoszenie). Same wartości globalne często maskują regresje w konkretnej niszy.

Dokładność pól: metryki „prawdy biznesowej”

Docelowo interesuje Cię nie to, czy OCR dobrze rozpoznał cały tekst, tylko czy system poprawnie wyciągnął konkretne pola. Dlatego kluczowe są metryki na poziomie atrybutów (np. numer faktury, data, NIP, kwoty, waluta, IBAN):

• Accuracy / exact match — czy pole jest identyczne jak w danych referencyjnych (przydatne dla identyfikatorów, numerów, kodów).
• Miary tolerancyjne — dopuszczają kontrolowane różnice (np. normalizacja spacji, format daty, zaokrąglenia). Istotne, by jasno zdefiniować, co jest „akceptowalną różnicą”, a co błędem.
• Precision/recall dla pól opcjonalnych lub wielowartościowych (np. pozycje na fakturze), gdzie istotne jest zarówno niegubienie elementów, jak i niedodawanie fałszywych.

Warto rozdzielać błędy na kategorie: brak pola, pole wypełnione, ale błędne, pole nadmiarowe. Te kategorie mają inną przyczynę i inny koszt naprawy.

Kompletność i pokrycie: czy pipeline „domyka” przypadki

Nawet wysoka dokładność dla części dokumentów nie wystarczy, jeśli system często kończy bez wyniku. Dlatego monitoruje się:

• Kompletność — odsetek dokumentów, dla których zwracany jest zestaw wymaganych pól (w rozumieniu wymagań biznesowych).
• Coverage/pokrycie — w ilu przypadkach pipeline w ogóle podjął sensowną próbę (np. dokument nieodczytywalny, zły format, brak stron).
• Odsetek przypadków wymagających eskalacji — ile trafia do ręcznej weryfikacji lub kolejki wyjątków.

Kompletność bywa ważniejsza niż „kosmetyczny” wzrost accuracy, bo bez niej automatyzacja zatrzymuje się na wąskich gardłach.

Walidowalność: miernik „zaufania do wyniku”

Walidacja to nie tylko etap logiczny, ale też metryka: czy wynik daje się zweryfikować regułami. Przydatne wskaźniki to m.in. odsetek rekordów, które:

• przechodzą walidacje formalne (formaty, checksumy, zakresy),
• przechodzą kontrole spójności (np. zgodność sum),
• są oznaczone jako „pewne” vs „niepewne” (jeśli system rozróżnia pewność wyniku).

Walidowalność jest praktycznym „bezpiecznikiem”: nawet jeśli model się myli, to dobrze zaprojektowane pomiary pokażą, czy błędy są wyłapywane, czy przeciekają do systemów downstream.

Latency i stabilność czasowa: odczucie użytkownika i SLA

W dokumentach liczy się przewidywalność. Monitoruj nie tylko średnie czasy, ale rozkład, zwłaszcza:

• p50/p95/p99 latency dla całego pipeline’u oraz per etap (OCR, layout, ekstrakcja, walidacja),
• timeouts i odsetek ponowień,
• kolejki i backlog (czy system nadąża z obciążeniem).

Regresje często zaczynają się od ogona rozkładu (p95/p99), a dopiero potem „psują” średnią.

Koszt: per dokument, per pole i per „udany wynik”

W pipeline z LLM koszt nie jest stały — zależy od długości treści, liczby prób, a czasem od jakości dokumentu. Warto mierzyć:

• koszt per dokument (łącznie: OCR, inferencja, ewentualne ponowienia),
• koszt per poprawnie przetworzony dokument (uwzględniając porażki i eskalacje),
• koszt per pole krytyczne, jeśli tylko część pól jest naprawdę biznesowo ważna.

Takie metryki pozwalają odróżnić optymalizacje „na papierze” od realnej poprawy ekonomiki systemu.

Drift i zmienność danych: kiedy model przestaje pasować do świata

Dokumenty „żyją”: zmieniają się szablony, jakość skanów, język opisów, pojawiają się nowe pola albo nowe warianty tabel. Drift nie zawsze objawia się spadkiem CER/WER — może pojawić się jako spadek kompletności, wzrost błędów w jednym krytycznym polu albo większa liczba wyjątków.

W monitoringu driftu przydatne są:

• zmiany dystrybucji cech wejściowych (np. długość tekstu, liczba bloków, udział cyfr, rozdzielczość),
• zmiany w miksie typów dokumentów i źródeł,
• trend metryk jakości w czasie dla kluczowych segmentów (typ dokumentu, kanał pozyskania, język).

Najbardziej praktyczne podejście to łączenie sygnałów: jeśli rośnie liczba wyjątków, spada walidowalność i zmieniają się cechy wejściowe, to masz wyraźną przesłankę do inspekcji próbek i aktualizacji konfiguracji lub komponentów.

Minimalny zestaw „dashboardu” dla analizy dokumentów

Jeśli trzeba zacząć od małej liczby wskaźników, sensowny zestaw podstawowy to:

• CER/WER dla reprezentatywnych segmentów,
• dokładność pól krytycznych oraz odsetek „brak/błędne”,
• kompletność zestawu wymaganych pól,
• walidowalność (pass rate) i odsetek eskalacji,
• p95/p99 end-to-end latency,
• koszt per poprawnie przetworzony dokument,
• trend metryk w czasie z podziałem na typ dokumentu i źródło.

Taki monitoring daje szybkie odpowiedzi na najważniejsze pytania: czy wynik jest poprawny, czy jest kompletny, czy da się go zaufać, czy działa wystarczająco szybko i ile naprawdę kosztuje — oraz czy te odpowiedzi są stabilne w czasie.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

RStudio: reproducible reports — Quarto vs R Markdown w zespołach analitycznych 16 kwietnia 2026

Jak dobrać typ wykresu do pytania biznesowego: mapa decyzji (z przykładami ‘z życia’) 14 kwietnia 2026