W zleconym przez nas badaniu, w którym wzięło udział 500 amerykańskich profesjonalistów pracujących głównie z dokumentami, 88% stwierdziło, że ma pełną pewność co do dokładności danych zasilających ich systemy analityczne i AI. Te same 88% osób zgłosiło, że przynajmniej czasami znajduje błędy w danych pochodzących z dokumentów. Obie liczby są prawdziwe jednocześnie, a ta sprzeczność stanowi najlepsze uzasadnienie dla tworzenia ustrukturyzowanych danych dla agentów AI.
Nie jest to błąd statystyczny. To dokładny obraz tego, jak obecnie funkcjonuje większość zespołów: są bardzo pewni siebie i jednocześnie tkwią w błędzie na tyle często, że ma to realny wpływ na biznes. Twoi agenci AI działają bezpośrednio na tych danych, a żaden model nigdy nie pomyśli: "chwila, ta suma wygląda podejrzanie".
Więc kiedy jeden z nich zawiesza się, płaci niewłaściwemu dostawcy lub przypisuje roszczenie pod błędny numer polisy, instynktownie obwiniasz model i szukasz nowszego rozwiązania. Tymczasem model był zazwyczaj w porządku. Brakowało wcześniejszego kroku, tego, który zamienia nadchodzący dokument w nazwane pola, które ktoś faktycznie zweryfikował.
Sześć etapów. Zero programistów. Oto one.
Kluczowe wnioski
- Ustrukturyzowane dane dla agentów AI to nazwane pola o przewidywalnych typach, a nie dokument, który agent musi zinterpretować w czasie wykonywania zadania.
- Agenci AI zawodzą w pracy z dokumentami na cztery konkretne sposoby: brak warstwy OCR dla skanów, zmienne układy dokumentów u różnych nadawców, ciche pomijanie pól i brak wskaźnika pewności do weryfikacji.
- Gartner przewiduje, że ponad 40% projektów związanych z agentowym AI zostanie anulowanych do końca 2027 roku. Inna prognoza firmy mówi, że 60% projektów AI, które nie są wspierane przez dane gotowe na sztuczną inteligencję (AI-ready), zostanie porzuconych do 2026 roku. Obie przyczyny porażek mają swoje źródło na etapie, zanim dane w ogóle trafią do modelu.
- Potok danych składa się z sześciu etapów: przechwytywanie, klasyfikacja, schemat, ekstrakcja, walidacja i dostarczanie. Pominięcie walidacji jest tym, co zamienia udane demo w poważny incydent na produkcji.
- Bramkowanie oparte na wskaźniku pewności (confidence gating) stanowi różnicę między agentem, którego musisz stale nadzorować, a takim, któremu w pełni ufasz. Zespoły ręcznie weryfikujące tylko niewielki odsetek niepewnych danych osiągają 99,9% dokładności, przetwarzając dokumenty do pięciu razy szybciej.
- Nic z tego nie wymaga zaangażowania programistów. Narzędzia takie jak n8n, Make i Zapier zajmują się orkiestracją, a warstwa ekstrakcji bierze na siebie najtrudniejsze zadania.
Co w rzeczywistości oznaczają ustrukturyzowane dane dla agentów AI
Ustrukturyzowane dane dla agentów AI to treść dokumentu przekształcona w nazwane pola o przewidywalnych typach i znanych jednostkach, dzięki czemu agent otrzymuje zbiór taki jak invoice_number, due_date, total i line_items zamiast surowego pliku PDF, który musi sam zinterpretować. Agent odczytuje wartości. Nie odczytuje całych dokumentów.
W praktyce wygląda to tak zwięźle:
{
"invoice_number": "INV-4821",
"supplier": "Northwind Supplies",
"due_date": "2026-08-14",
"currency": "USD",
"total": 1340.0,
"source_document": "https://files.example.com/inv-4821.pdf"
}
To sześć linijek, na których może oprzeć się Twój przepływ pracy, zamiast trzystronicowego pliku PDF z promptem mówiącym "znajdź sumę". Każde pole ma własną nazwę, typ danych i prowadzi bezpośrednio do strony, z której zostało wyciągnięte.
Brzmi to jak mało istotny szczegół techniczny. W rzeczywistości to różnica między agentem, który zadziałał w wersji demonstracyjnej, a takim, który będzie niezawodnie działał na produkcji wiele miesięcy później. Model, któremu podano tę samą fakturę dwa razy, może zwrócić dwie nieco inne odpowiedzi. W oknie czatu jest to może i urocze, ale staje się katastrofalne, gdy proces działa w tle o 3 w nocy. Z kolei model, który otrzymuje rygorystycznie zweryfikowany obiekt JSON, za każdym razem zachowa się w dokładnie ten sam sposób, ponieważ nie ma już nic do samodzielnego interpretowania.
To wciąż sprawia organizacjom spore problemy, ponieważ sam materiał źródłowy nigdy nie był przeznaczony do odczytu przez maszyny. Szacuje się, że około 80 do 90% danych korporacyjnych to dane nieustrukturyzowane: e-maile, pliki PDF, skany, załączniki, formularze – wszystko to zostało stworzone po to, aby czytał to człowiek. Większość zespołów wciąż nie zasypała tej przepaści. W jednym z najnowszych badań dotyczących obsługi faktur, aż 34% firm wciąż przetwarza dane całkowicie ręcznie, a zaledwie 17% w pełni zautomatyzowało ten proces.
Surowe dane w formacie dla człowieka. Agent oczekujący formatu maszynowego. W strukturze organizacyjnej nikt nie jest odpowiedzialny za tę konwersję. Ta luka jest tematem naszego szerszego artykułu o brakującej warstwie w agentowym AI, jeśli interesuje Cię dłuższy wywód, oraz przewodnika po konwersji danych nieustrukturyzowanych na ustrukturyzowane, jeśli szukasz bardziej ogólnego podejścia. Tutaj skupiamy się stricte na perspektywie i potrzebach agenta AI.
Dlaczego agenci AI zawodzą w pracy z dokumentami
Prawie każda halucynacja agenta AI związana z przetwarzaniem dokumentu sprowadza się ostatecznie do jednego z czterech problemów. Cztery przyczyny – cztery różne rozwiązania.
Brak warstwy OCR dla skanów. Skan to de facto obraz ze słowami, a nie same słowa. Model, który otrzyma obraz bez warstwy tekstowej, przeczyta to, co zdoła, a z absolutnym przekonaniem zmyśli resztę, nigdy nie informując Cię, która połowa jest poprawna.
Zmienność układu u różnych nadawców. Czterdziestu różnych dostawców, czterdzieści różnych wzorów faktur i potok przetwarzania (pipeline) zoptymalizowany na podstawie zaledwie trzech układów, które testowałeś w zeszłym kwartale. Kiedy dwunasty dostawca niespodziewanie przeniesie sumę do innej rubryki, system nie zgłosi błędu. Proces ekstrakcji po cichu zacznie zwracać niewłaściwą wartość.
Ciche pomijanie pól. Na dokumencie brakuje numeru zamówienia (PO), więc pole zwraca pustą wartość, a agent mimo to działa dalej. Z pozoru wszystko przebiega poprawnie. Problem wypływa dwa tygodnie później podczas księgowego uzgadniania sald, czego nikt nie lubi.
Brak wskaźnika pewności. Nic w generowanych danych wyjściowych nie mówi: „jestem tylko na 60% pewien tej kwoty”, więc każda wartość jest obdarzana takim samym zaufaniem, łącznie z tymi całkowicie zmyślonymi przez model.
Koszt tych pomyłek wcale nie jest teoretyczny. Prawie siedmiu na dziesięciu ankietowanych zgłosiło, że znajduje błędy czasami, często lub bardzo często, co sprawia, że złe dane z dokumentów stają się codziennością, a nie incydentem. Jeśli chodzi o obszar zobowiązań finansowych (AP), wskaźniki błędów w płatnościach wahają się od 0,1% do 0,4% całkowitych wydatków dla dostawców. Małe procenty kryją się za ogromnymi mianownikami: przepuść przez taki system 20 milionów dolarów wydatków firmowych, a okaże się, że od 20 000 do 80 000 dolarów rocznie trafia w niewłaściwe miejsca.
Firma Gartner dochodzi zresztą do podobnych wniosków z innej perspektywy: 63% organizacji albo nie ma odpowiednich praktyk zarządzania danymi pod kątem AI, albo w ogóle nie jest pewna, czy je posiada. Co jest dyplomatycznym sposobem ujęcia, że większość projektów opartych na agentach bazuje na fundamentach, których nikt nie sprawdził. Jeśli to warstwa OCR sprawia Ci największe trudności, szerzej omówiliśmy ten temat w artykule dlaczego AI OCR zawodzi.
Dlaczego wysyłanie pliku PDF bezpośrednio do modelu przestaje działać
Wysyłanie surowego pliku bezpośrednio do GPT, Claude'a czy Gemini działa do czasu, a różnica polega na tym, czy wygenerowane dane ostatecznie weryfikuje człowiek.
Dobrze obrazują to statystyki. Na czystych, tekstowych plikach PDF ekstrakcja poszczególnych pól osiąga dokładność rzędu 96-98%. W przypadku dokumentów zeskanowanych te same modele notują spadki do poziomu około 90-94%. Ta różnica nie jest jednak problemem samym w sobie. Problemem jest to, że odpowiedź za każdym razem wygląda identycznie. Żadnej flagi ostrzegawczej, żadnego zastrzeżenia, żadnej wskazówki, że akurat ten konkretny dokument był dla AI nieco trudniejszy.
W oknie czatu można na to przymknąć oko, bo zapewne zauważyłbyś kwotę 1340$, gdy na oryginalnej fakturze widnieje 13,40$. W zautomatyzowanej pętli bez nadzoru nie ma nikogo, kto mógłby to w porę wychwycić, a rażąco błędna liczba przechodzi prosto do kolejnego etapu procesu.
Kryje się za tym kwestia architektoniczna, którą szczegółowo omawialiśmy w artykule o tym, dlaczego przetwarzanie dokumentów oparte na pojedynczym modelu jest martwe: jedno wywołanie modelu to jeszcze nie jest potok (pipeline). Potok przetwarzania ma swoje etapy, a te etapy można skrupulatnie weryfikować. Pojedyncze wywołanie to zaledwie rzut monetą, któremu po prostu postanowiłeś całkowicie zaufać.
Pipeline od dokumentu do agenta w sześciu etapach
Parsowanie dokumentów dla agentów AI to nie jeden, szybki krok, ale dokładnie sześć konkretnych etapów. Z naszego doświadczenia wynika, że każda niezawodna konfiguracja przechodzi przez wszystkie z nich, niezależnie od tego, czy zespół metodycznie zaplanował to na tablicy przed wdrożeniem, czy też doszedł do tego bolesnego wniosku po miesiącu ciągłego gaszenia pożarów.
1. Przechwyć dokument i zachowaj oryginał
Zidentyfikuj miejsca, do których faktycznie docierają Twoje dokumenty: współdzielona skrzynka odbiorcza e-mail, konkretny folder na Google Drive lub w SharePoint, przesyłanie formularzy ze strony, serwer SFTP czy też załączniki do zgłoszeń z helpdesku. Zapisz oryginalny plik w stabilnym i bezpiecznym archiwum, zanim w ogóle zaczniesz na nim operować.
Zachowanie pliku źródłowego to nie tylko utrzymanie porządku w systemie. To właśnie ten krok pozwala Ci pół roku później odpowiedzieć na pytanie "skąd u diabła wzięła się ta liczba" i jest to pierwsza rzecz, o którą zapyta każdy zewnętrzny audytor.
2. Klasyfikuj przed ekstrakcją
Zanim zdecydujesz, jakie pola wyodrębnić, sprawdź, z jakim dokumentem masz do czynienia. Czy to faktura, zamówienie zakupu, umowa prawna, dowód dostawy, wyciąg bankowy, CV, czy może coś zupełnie nieznanego.
To o wiele ważniejsze, niż mogłoby się wydawać, ponieważ chociażby faktury i zamówienia często mają te same nazwy pól, mimo że biznesowo oznaczają zupełnie co innego. Wrzuć je do jednego worka, a otrzymasz rekordy, które gładko przechodzą każdy test walidacji, mimo że są całkowicie bezużyteczne. To tutaj koncentruje się największe ryzyko błędów biznesowych: respondenci naszego badania wskazali właśnie faktury (21%), zamówienia zakupu (18%) oraz dokumenty kierowane do klientów (17%) jako typy dokumentów zdecydowanie najbardziej podatne na błędy.
Wszystko, co system ostatecznie sklasyfikuje jako "nieznane", powinno automatycznie trafić do człowieka, a nie do systemu, który będzie próbował na siłę zgadywać.
3. Zdefiniuj jeden schemat dla każdego typu dokumentu
Schemat pełni funkcję wiążącej umowy między Twoimi dokumentami a Twoim agentem AI. To on jasno nazywa każde pojedyncze pole, nadaje mu określony typ i zaznacza, które z nich są absolutnie obowiązkowe.
Definiuj pola zawsze na podstawie ich znaczenia, a nie konkretnej lokalizacji na stronie, więc total_amount to po prostu kwota końcowa na fakturze, bez względu na to, w którym rogu akurat się znajduje. Nowoczesna ekstrakcja AI potrafi świetnie poradzić sobie z układami, których nigdy wcześniej na oczy nie widziała, bez konfigurowania jakichkolwiek sztywnych szablonów, co oznacza, że jeden dobrze przemyślany schemat może z powodzeniem objąć nawet 40 różnych dostawców. Oprzyj się naturalnej pokusie tworzenia osobnego schematu dla każdego nadawcy. Taka droga do niczego nie prowadzi.
Wyraźnie oznacz te pola, bez których Twój system docelowy po prostu nie będzie w stanie dalej funkcjonować. To one staną się twardym punktem zatrzymania procesu na piątym etapie.
4. Ekstrahuj za pomocą dedykowanej warstwy, a nie zwykłego wywołania modelu
To z tego etapu bierze się wysoka dokładność. Odpowiednio wdrożona ekstrakcja danych dla agentów AI to nie tylko sprytny prompt; to kompletna usługa, a diametralna różnica doskonale widoczna jest w statystykach: starsze systemy oparte wyłącznie na OCR osiągają dokładność rzędu 85–95% i mają gigantyczne problemy z niespójnymi układami, podczas gdy ekstrakcja w pełni oparta na AI i nowoczesnym uczeniu maszynowym zbliża się do poziomu 99% i potrafi elastycznie dostosować się do nowych układów bez żadnej przebudowy szablonów.
Oto, co zyskujesz dzięki wdrożeniu dedykowanej warstwy w porównaniu do samego czystego wywołania modelu AI: zaawansowany OCR dla wymagających skanów, inteligentną ekstrakcję tabel i pojedynczych pozycji, standaryzację i weryfikację ze zdefiniowanym schematem, precyzyjne referencje do strony źródłowej, wbudowane mechanizmy obsługi ponownych prób (retry handling), opcjonalny krok z weryfikacją przez człowieka oraz wersjonowane schematy, które w przyszłości możesz dowolnie zmieniać bez obaw o naruszanie spójności starszych rekordów. Niektóre warstwy ekstrakcji dodają również przydatne oceny pewności (confidence scores) bezpośrednio do poszczególnych pól – co jest bardzo pomocne, ale z całą pewnością nie powinno stanowić jedynej podstawy dla mechanizmu decyzyjnego.
Większość potoków produkcyjnych w 2026 roku raczej umiejętnie łączy różne z tych podejść niż ślepo wybiera tylko jedno z nich, stosując tańszą, bardziej deterministyczną ekstrakcję dla prostszych dokumentów oraz tę zaawansowaną, w pełni opartą na modelach AI dla tych najbardziej skomplikowanych. Aby zagłębić się w ten temat, przeczytaj nasz przewodnik po agentowej ekstrakcji dokumentów (agentic document extraction).
5. Waliduj i bramkuj, zanim cokolwiek dotrze do agenta
Zawsze sprawdzaj wyodrębniony rekord ze swoim zdefiniowanym schematem. Sprawdź, czy wymagane pola są obecne, czy typy danych są poprawne, czy sumy się zgadzają, czy daty są prawidłowo sformatowane, a wyciągnięte wartości mieszczą się w wiarygodnych zakresach. Następnie zastosuj inteligentne reguły oparte na wskaźniku pewności (confidence rules).
Te rekordy, które bezbłędnie przejdą weryfikację, natychmiast trafiają do agenta AI. Rekordy, którym się to nie uda, wędrują prosto do człowieka. Zaprojektuj i zbuduj tę drugą ścieżkę raczej jako objazd, a nie jak ślepą uliczkę, dzięki czemu pomyślnie zweryfikowany po czasie rekord bez problemu powróci do tego samego przepływu pracy zaraz po jego autoryzacji przez pracownika, a jeden trudniejszy dokument nie zablokuje Ci nagle całej reszty kolejki.
To jedno rozgałęzienie to kluczowy mechanizm bezpieczeństwa, któremu poświęciliśmy osobną sekcję poniżej, ponieważ to właśnie ten krok zespoły wdrożeniowe najczęściej pomijają i najszybciej tego żałują.
6. Dostarcz czysty rekord agentowi
Bezpiecznie przekaż w pełni zweryfikowany obiekt w miejsce, z którego Twój agent AI podejmie dalszą zautomatyzowaną pracę: może to być wyzwalacz webhook w używanej przez Ciebie platformie automatyzacji, nowy wiersz w bazie danych, czy zaktualizowany rekord w systemie CRM lub ERP. Agent otrzymuje czysty, gotowy do pracy obiekt i już w ogóle nie musi widzieć samego dokumentu.
Jak dane w rzeczywistości docierają do agenta
Poniższe cztery mechanizmy obejmują w zasadzie każdą integrację agenta AI, jaką kiedykolwiek przyjdzie Ci zbudować. Wbrew pozorom, nie są to dla siebie alternatywy. Każdy z nich odpowiada po prostu na inne potrzeby dotyczące opóźnień (czasu) oraz właściwego właścicielstwa i przepływu danych.
| Mechanizm | Jak to działa | Kiedy najlepiej używać | Na co trzeba uważać |
|---|---|---|---|
| Webhook | Narzędzie do ekstrakcji samo wypycha rekord dokładnie w momencie, gdy jest on już gotowy | Dokumenty napływają do firmy nieustannie, a Ty chcesz, by agent AI zareagował na nie niemal natychmiast | Musisz zadbać o wdrożenie obsługi ponownych prób (retries) i przygotować bezpieczne miejsce, w którym na pewno wylądują wszystkie ewentualne nieudane dostarczenia |
| REST API pull | Twój docelowy przepływ pracy samodzielnie prosi o pakiety rekordów zgodnie z ustalonym harmonogramem | Świetne rozwiązanie przy przetwarzaniu wsadowym (batch processing) lub w sytuacji, gdy po prostu Twój system docelowy z założenia nie akceptuje połączeń przychodzących | Zdecydowanie zwiększa opóźnienie (latency) dla pojedynczych rekordów i od tej pory to Ty w pełni bierzesz na siebie logikę odpytywania systemu (polling) |
| Współdzielona baza danych | Wszystkie rekordy trafiają do dużej tabeli, z której następnie odczytuje je agent (lub wielu agentów) | Kilku różnych agentów lub kilka całkowicie niezależnych systemów potrzebuje ciągłego dostępu do tych samych danych i bezwzględnie potrzebujesz pełnej historii i logów ich operacji | Ktoś w zespole musi na bieżąco odpowiadać za regularne czyszczenie bazy i mozolne wprowadzanie ewentualnych zmian w samej architekturze schematu |
| Wywołanie narzędzia (Tool call) | Agent sam żąda dostępu do potrzebnych mu danych z dokumentów w trakcie trwania operacji, zazwyczaj z wykorzystaniem protokołu MCP | Agent w trakcie wykonywania bardziej zaawansowanego zadania samodzielnie decyduje, jakich konkretnie dokumentów z dostępnej bazy potrzebuje do jego ukończenia | To najtrudniejsze w utrzymaniu i debugowaniu rozwiązanie i stosunkowo rzadko tak naprawdę niezbędne przy standardowych, zautomatyzowanych przepływach pracy z dokumentami |
Ostatni wiersz tej tabeli zasługuje na dodatkowy przypis, ponieważ głośny ostatnio protokół MCP (Model Context Protocol) przyciągnął naprawdę ogromną uwagę całej branży. MCP to jak najbardziej realny i w pewnych przypadkach szalenie wręcz przydatny sposób eksponowania źródeł firmowych danych dla inteligentnych agentów AI jako dostępnych w locie narzędzi. Zazwyczaj nie jest to jednak optymalne podejście w przypadku dokumentów, które pojawiają się w firmie zgodnie z własnym, często losowym harmonogramem, niosąc ze sobą na dodatek z góry wiadome pola. Standardowy webhook wypychający czyste, ustrukturyzowane dane bezpośrednio do Twojego przepływu pracy jest zazwyczaj znacznie prostszy w budowie, dużo łatwiejszy do zdebugowania i na koniec dnia wykonuje dokładnie to samo zadanie.
To zresztą wspólny mianownik dla wszystkich czterech wierszy powyższej tabeli: tak naprawdę nie ma czegoś takiego jak dedykowane API dla agentów AI. Wystarczy po prostu solidne, zwykłe API, które sprawnie dostarcza nazwane pola, z którymi potem bez problemu może pracować dowolny agent. Nasz system Parseur z łatwością wysyła przetworzone dane za pośrednictwem każdego z pierwszych trzech omówionych mechanizmów, a pełna i aktualna lista obsługiwanych lokalizacji docelowych znajduje się na naszej dedykowanej stronie eksporty i integracje.
Skąd wiedzieć, że Twój agent nie zadziała na błędnej liczbie, gdy nikt nie patrzy
Wiesz to stąd, że sam całkowicie świadomie i z góry ustaliłeś, na jakich dokładnie danych agentowi w ogóle wolno jest pracować, podczas gdy cała niepewna reszta jest automatycznie zatrzymywana w kolejce w oczekiwaniu na weryfikację przez człowieka.
To jedyna w stu procentach szczera odpowiedź. Żadne, nawet najbardziej obiecujące wskaźniki dokładności AI, całkowicie nie rozwiążą tego problemu. Powód jest wręcz banalny: nawet wyśmienity proces ekstrakcji niekiedy po prostu się myli, a błędy w nim wcale nie rozkładają się równomiernie i zgrabnie. To, co zagwarantuje Ci w nocy spokojny sen, to właśnie owa "bramka", którą celowo i starannie zaprojektowałeś dla swojego procesu.
Bramka to de facto niewielki zestaw prostych, żelaznych reguł, z którymi zawsze weryfikowany jest nowy rekord tuż przed jego przekazaniem agentowi AI:
- Pewność modelu poniżej ustalonego progu w przypadku jakiegokolwiek wyodrębnionego pola – takie rekordy od razu skieruj do weryfikacji. To zależy oczywiście w głównej mierze od faktu, czy warstwa ekstrakcji w ogóle publikuje pełne informacje o wskaźnikach pewności dla każdego pola z osobna (wielu dostawców wciąż niestety tego unika, dlatego cała reszta tej listy ma tak kluczowe znaczenie).
- Zupełny brak wymaganego pola – bezwzględnie odrzucaj takie rekordy. Pod żadnym pozorem nigdy nie przesyłaj w to miejsce bezsensownego, pustego ciągu znaków (tzw. empty string) bezpośrednio do kolejnego etapu procesu, udając, że to pełnoprawna wartość.
- Odczytana wartość rażąco wykracza poza ustalony, bezpieczny limit dla danego procesu – w takich sprawach zawsze wymagaj akceptacji człowieka, bez względu na to, jak pewny swego wskaźnika jest model AI. Nawet idealnie i w stu procentach prawidłowo wyekstrahowana faktura na gigantyczną kwotę 80 tysięcy dolarów, zawsze dla zasady zasługuje na dodatkową weryfikację ze strony żywego człowieka.
- Jeżeli wykryty dostawca, nadawca albo sam typ dokumentu są zupełną nowością – dla pewności skieruj kilka pierwszych, przychodzących z tego nowego źródła dokumentów do weryfikacji manualnej, dopóki ostateczny wzorzec dla AI nie zostanie w systemie w pełni ugruntowany.
- Jeżeli wstępna klasyfikacja dla przychodzącego pliku zwraca ogólną wartość »nieznane« – natychmiast przekaż taki plik do ręcznej klasyfikacji w systemie (triage), zamiast tracić zasoby na ślepe zgadywanie schematu przez AI.
- Zsumowana kwota całkowita za nic w świecie nie chce pokryć się z wartościami zczytanymi dla poszczególnych pozycji na fakturze – po prostu odrzuć taki dokument. Podstawowa, prosta arytmetyka to w biznesie najtańszy wykrywacz wszelkich kłamstw, anomali i pomyłek, jaki posiadasz i nie warto z niego rezygnować.
A jeśli chodzi już stricte o samo mityczne pojęcie progu pewności (threshold): żadna jedna, uniwersalna wartość na rynku po prostu nie istnieje, a każdy handlowiec, który powołuje się na tego typu rzekome normy w trakcie pierwszej rozmowy, na pewno jeszcze nie miał w rękach specyficznych dokumentów, którymi operuje Twoja firma. Zawsze więc rozsądnie kalibruj swoją własną barierę, bezwzględnie opierając się na miarodajnej próbce losowych plików z firmowego środowiska produkcyjnego, i ustaw swój ostateczny próg pewności właśnie na takim etapie, by wszystkie te błędy, którym czasami uda się jakoś wymknąć i prześlizgnąć do dalszej części procesu, były jednocześnie w 100% akceptowalne dla Twojego systemu docelowego bez generowania żadnych przykrych następstw. Zupełnie inaczej bowiem podchodzi się do faktur trafiających z automatu do kolejki opłacania na poczet firmy, a jeszcze inaczej do potoku prostych dowodów dostaw tworzących analityczne wykresy panelu menedżerskiego. Z całą pewnością dokumentów tych nie powinno się zrównywać pod jeden schemat i poddawać jednakowym, rygorystycznym restrykcjom czy zasadom zatwierdzania.
Zyski ze stosowania takiego modelu w biznesie są jak najbardziej mierzalne. Zespoły aktywnie korzystające z tego rozsądnego wzorca – w którym to sztuczna inteligencja na co dzień świetnie radzi sobie z pewną większością rutynowych zadań, podczas gdy nieliczni oddelegowani ludzie po prostu szybko weryfikują jedynie drobną, niepewną resztę – w skali miesiąca z łatwością osiągają dokładność na poziomie 99,9%, przetwarzając dokumenty do 5 razy szybciej. Z kolei pewien duży, skandynawski ubezpieczyciel automatyzujący w pełni rygorystyczny na co dzień proces procesowania roszczeń bez wahania podaje, że z sukcesem obsługuje około 70% zgłoszeń bez absolutnie jakiejkolwiek ingerencji z zewnątrz, pozostawiając ręce pracowników rozwiązane i do pełnej dyspozycji w sprawach o wiele bardziej skomplikowanych w samej wycenie i obsłudze merytorycznej. Przepaść między »dobrymi« a po prostu »przeciętnymi« rzuca się również mocno w oczy, jeżeli w tym celu weźmiemy pod obiektyw statystyki samego procesu obsługi firmowych kont i spłat wszystkich zobowiązań (AP): najlepsi mogą pochwalić się wskaźnikiem wyjątków na poziomie 9%, podczas gdy dla reszty branży wynosi on aż 22%.
Zwróć na koniec uwagę, co wyżej wspomniane statystyki, badania rynkowe i case-study firm rzeczywiście z sukcesem próbują nam przekazać. Nie oznacza to, że agent AI nigdy nie trafia na skomplikowane dokumenty; oznacza to, że system potrafi rozpoznać, kiedy dany plik jest zbyt trudny do automatycznego przetworzenia. Po pełen, wyczerpujący komplet informacji, instrukcji wdrożeniowych czy też gotowych schematów projektowych dla poprawnego procesu z włączeniem tzw. pracownika (czynnika) na samej warstwie walidacyjnej AI, gorąco odsyłamy na nasz oddzielny, obszerny blog omawiający tematykę: AI z modelem human-in-the-loop (HITL), dobrych i popartych latami badań najlepszych praktyk związanych z HITL, czy stricte już samej walidacji i czyszczeniu przetwarzanych baz.
Tworzenie przepływu pracy agenta AI bez pisania kodu
Nic z tych rzeczy nie wymaga zaangażowania programisty, co potrafi zdziwić osoby, dla których słowo »pipeline« kojarzy się z kwartałami żmudnych prac wdrożeniowych z systemem.
Podział jest prosty. Warstwa ekstrakcji wykonuje najtrudniejszą część: odczytuje dokumenty, stosuje schemat, normalizuje i weryfikuje pola. Twoja platforma automatyzacji zajmuje się orkiestracją: wyzwalaniem na podstawie nowych dokumentów, wywoływaniem narzędzia do ekstrakcji, odbieraniem wyników, sprawdzaniem reguł, kierowaniem wyjątków (routing exceptions) i przekazywaniem gotowego obiektu agentowi. Taki podział pracy to rzeczywisty obraz przepływu pracy agenta AI, gdy już przetrwa wdrożenie na środowisko produkcyjne.
W n8n całość to zaledwie cztery węzły (nodes): wyzwalacz webhooka odbierający wyekstrahowany rekord, węzeł IF sprawdzający Twoje reguły, jedno odgałęzienie do agenta, jedno odgałęzienie do człowieka. Wszystko to, o czym pisaliśmy wyżej w kontekście bramkowania (gating), mieści się wewnątrz tego węzła IF, a reguły wychwytujące najwięcej problemów to te najprostsze: brak wymaganego pola lub kwota całkowita niezgodna z pozycjami.
n8n pasuje zespołom potrzebującym logiki rozgałęzień (branching logic), obsługi błędów i self-hostingu, i to właśnie tutaj odbywa się obecnie większość prac związanych z tworzeniem agentów. Make to najbardziej przyjazne narzędzie do wizualnego budowania wieloetapowego przepływu bez dotykania czegokolwiek, co przypomina kod. Zapier pozwoli Ci na uruchomienie aplikacji jeszcze dziś po południu, pod warunkiem, że przepływ będzie w miarę liniowy. Szerzej o kompromisach między tymi narzędziami piszemy w naszym porównaniu: n8n vs Zapier vs Make.
Z czym żadne z tych narzędzi nie radzi sobie dobrze samodzielnie, to odczytywanie zeskanowanych plików PDF. Ich wbudowane moduły do obsługi plików (file nodes) świetnie sprawdzają się przy czystych dokumentach tekstowych – i na tym ich możliwości się kończą. To właśnie tę lukę wypełnia warstwa ekstrakcji, sprawiając, że te dwa elementy idealnie się uzupełniają, zamiast ze sobą konkurować.
Warstwa ekstrakcji, RAG czy po prostu LLM: czego właściwie potrzebujesz?
O tych trzech podejściach dyskutuje się jako o opcjach alternatywnych, tymczasem tak naprawdę każde z nich rozwiązuje po prostu inne problemy.
| Podejście | W czym jest dobre | Kiedy używać | Gdzie zawodzi |
|---|---|---|---|
| Warstwa ekstrakcji | Wyciąganie tych samych, nazwanych pól z każdego dokumentu danego typu | Wiesz, jakich konkretnie pól potrzebujesz, a agent lub docelowy system podejmie na nich odpowiednie akcje | Zupełnie nie nadaje się do odpowiadania na otwarte pytania o znaczenie dokumentu |
| RAG | Odpowiadanie na pytania otwarte w oparciu o szerszy obszar tekstu (body of text) | "Co na temat wypowiedzenia mówi umowa ramowa z naszym klientem?" | Spore problemy z walidacją, jakość odzyskiwania danych (retrieval quality) decyduje o wszystkim |
| Wyłącznie wywołanie modelu LLM | Prototypy, jednorazowe eksperymenty, zupełnie nietypowe dokumenty | Zaledwie eksplorujesz temat, a człowiek samodzielnie odczytuje wszystkie wyniki modelu | Brak wskaźnika pewności (confidence signal), żadnej ścieżki audytu, totalny brak możliwości ustawiania jakichkolwiek bram (gatingu) |
Najczęstszym błędem jest sięganie po architekturę RAG (Retrieval-Augmented Generation), gdy wystarczyłby zwykły schemat (schema). Jeżeli możesz zapisać nazwy pól w pierwszej kolejności, rozwiązanie takie jak ekstrakcja staje się od razu opcją szybszą, dużo tańszą i przy tym wszystkim o wiele łatwiejszą do weryfikacji. Zachowaj RAG na te pytania, których nie można po prostu jednoznacznie wyliczyć.
To jest również miejsce, w którym pojęcie gotowości danych na AI (AI data readiness) przestaje być tylko slajdem z prezentacji, a staje się listą kontrolną. Większość tekstów na ten temat nawiązuje do tabel w hurtowniach danych oraz całej ogólnej polityki zarządzania informacjami. W przypadku przepływu dokumentów (document workflows) pojęcie to sprowadza się do czterech konkretnych rzeczy: po pierwsze: jasno nazwanych pól; po drugie: zdefiniowanych typów danych; po trzecie: wartości zweryfikowanych ze schematem przed przekazaniem ich dalej; i po czwarte: linków prowadzących bezpośrednio do dokumentu źródłowego. Aby uzyskać szerszą perspektywę tej kategorii, zobacz inteligentne przetwarzanie dokumentów (IDP).
Jak zbudować to przy pomocy Parseur
Parseur stanowi warstwę ekstrakcji w opisanym wyżej potoku (pipeline). Został on stworzony, ponieważ dwóch inżynierów znudziło się patrzeniem na ludzi nieustannie przepisujących rzeczy, z których odczytaniem komputer od dawna świetnie potrafi sobie sam poradzić.
Konfiguracja zamyka się w czterech krokach:
- Utwórz skrzynkę pocztową (mailbox) i skieruj do niej swoje dokumenty. Przekazuj maile od dostawców, wrzucaj do niej odpowiednie pliki (np. poprzez przeciągnij i upuść) lub połącz skrzynkę bezpośrednio z folderem, w którym takowe lądują.
- Sztuczna inteligencja Parseur wyodrębnia pola w pełni automatycznie. Silnik AI typu Text radzi sobie doskonale z wszelkiej maści mailami oraz tekstowymi dokumentami, a z drugiej strony mamy do czynienia z AI typu Vision, dedykowanym do rozwiązywania problemów ze skanami, obrazkami oraz plikami o rozszerzeniu PDF. Nie wymaga to tworzenia szablonów ani ciągłego dostosowywania ustawień w sytuacji, gdy dostawca postanowi zmienić układ swojej faktury.
- Weryfikuj (waliduj) dane, by sprawdzać to, na sprawdzeniu czego Ci zależy. Każde pole w dokumencie podlega normalizacji oraz jest walidowane (sprawdzane) w oparciu o schemat Twojej skrzynki (mailbox schema), dzięki czemu liczby, daty oraz konkretne wybory przyjmują niemal natychmiast taką docelową formę, jakiej Twoje narzędzia będą oczekiwać na dalszym etapie. Uruchom opcjonalny krok ręcznej weryfikacji, żeby upoważniona do tego osoba mogła okiem rzucić na dokument jeszcze przed ostatecznym jego wyeksportowaniem dalej do systemu. Parseur celowo nie przypisuje polom ukrytych współczynników pewności i nie podejmuje w tle decyzji na podstawie z góry określonych progów – pozwala natomiast łatwo skierować wątpliwe przypadki do weryfikacji przez człowieka.
- Wyeksportuj ustrukturyzowany wynik (strukturyzowane dane) do własnego agenta, połączonej platformy automatyzacji, posiadanej bazy danych, przypiętego CRM, lub po prostu z wykorzystaniem bezpośredniego użycia funkcji dedykowanego w tym celu API.
Parseur potrafi odczytywać pliki PDF, e-maile, skany, arkusze kalkulacyjne oraz załączniki i robi to od 2016 roku. Przetworzył już ponad 100 milionów dokumentów, i to bez ani jednego centa inwestycji z zewnątrz – a to dokładnie ten pożądany i nudny rodzaj stabilności, którego oczekujesz pod spodem zautomatyzowanego potoku danych (pipeline), który ma działać bez przerwy w tle.
Dwa pytania padają, zanim to wszystko w ogóle dotknie Waszego systemu ERP – i zazwyczaj pochodzą one z działów IT i finansów w tym samym tygodniu. Gdzie trafiają dane: dokumenty nigdy nie są wykorzystywane do trenowania modeli, przetwarzanie jest zgodne z RODO (GDPR), a resztę informacji znajdziesz na stronie bezpieczeństwo. Ile to kosztuje: dostępny jest darmowy plan, co sprawia, że jedynym rozsądnym sposobem na ocenę tego rozwiązania jest przepuszczenie przez system pięciu Twoich najbardziej skomplikowanych dokumentów i sprawdzenie pól, które zostaną zwrócone.
Powód, dla którego warto się tym zainteresować, to czysta matematyka. Ręczne wprowadzanie danych kosztuje amerykańskie firmy około 28 500 dolarów rocznie w przeliczeniu na pracownika. To właśnie z tą pozycją w budżecie w rzeczywistości konkuruje Twój projekt agenta AI. To również to, co po cichu wraca w tygodniu, w którym Twój zespół stwierdza, że nie można ufać zautomatyzowanemu potokowi (pipeline) i zaczyna weryfikować każdy rekord ręcznie.
Czy ta warstwa zniknie w miarę udoskonalania modeli?
Jakość ekstrakcji poprawia się z każdym rokiem. Potrzeba sprawdzonej granicy między dokumentem a systemem dysponującym pieniędzmi – nie.
Oto bezlitosna matematyka. Przy dokładności ekstrakcji pól na poziomie 99%, jeden dokument na sto zawiera błędną wartość. Przetwórz dziesięć tysięcy dokumentów w miesiącu, a otrzymasz sto błędnych wartości, z których każda z osobna wygląda zupełnie tak samo, jak ta poprawna. Zwiększ dokładność do 99,5%, a będziesz miał ich pięćdziesiąt. To lepszy wynik, ale nadal nie wynosi zero, a dokładnie zero to to, czego po cichu wymaga sformułowanie »agent może działać bez nadzoru«.
Tym, co naprawdę ulega zmianie, są proporcje (ratio). Mniej dokumentów wymaga uwagi człowieka, a te, które wciąż jej potrzebują, są znacznie precyzyjniej oflagowane. Dzięki temu kolejka do ręcznej weryfikacji kurczy się z objętości pracy dla całego działu do poziomu jednego spokojnego popołudnia. To ogromna poprawa i z pewnością jest warta wysiłku. Niemniej jednak to wciąż nie to samo, co całkowite i bezpowrotne zniknięcie samej warstwy.
Zespoły, które z powodzeniem będą korzystać z agentów w 2028 roku, to nie będą te, które rzekomo znalazły model na tyle dobry, by móc całkowicie zrezygnować z procesu walidacji. Będą to te zespoły, które wcześnie zbudowały własną »bramkę«, obserwowały, jak wychwytuje ona błędy, i powoli zapracowały na prawo do stopniowego jej poszerzania.
Ostatnia aktualizacja
