Prośba „wyciągnij wszystkie dane” zwraca piękny obiekt z kilkudziesięcioma polami. Połowa nie jest potrzebna, część zgadnięta, a nazwy zmieniają się między dokumentami. Model jest pomocny. Proces nadal nie wie, co ma zapisać.
Ekstrakcja zaczyna się od konsumenta i małego schematu. Każde pole ma źródło, typ, brak i regułę odbioru. Nie musisz opisywać całego dokumentu, tylko dane wymagane przez decyzję.
Zdefiniuj konsumenta i skutek
Zapisz, czy dane trafiają do arkusza, CRM, płatności, raportu czy odbioru człowieka. Każdy konsument ma inne wymagania i koszt błędu. Nie używaj jednego schematu dla wszystkiego.
Wybierz minimalne pola dla decyzji. Numer dokumentu, data, kwota, waluta i źródło mogą wystarczyć. Adres, historia i uwagi dodawaj tylko przy rzeczywistym użyciu. Więcej pól oznacza więcej możliwych błędów.
Opisz skutek błędnego pola. Niedokładny opis może być akceptowalny przy wyszukiwaniu, ale błędna kwota przy płatności nie. To ustala walidację i odbiór.
Zbuduj słownik pól
Nadaj nazwy jednoznaczne dla procesu: data_dokumentu, termin_platnosci, kwota_brutto, waluta. Nie używaj „data”, „wartość”, „typ”. Model i integracja nie powinny zgadywać znaczenia.
Zapisz definicję i przykład dla każdego pola. Podaj, czy źródłem jest nagłówek, tabela, stopka czy obliczenie. Obliczenia oznaczaj jako osobne i zachowaj formułę.
Nie zmieniaj znaczenia pola między typami dokumentów. Jeżeli data w jednym przypadku oznacza wystawienie, a w innym dostawę, użyj osobnych nazw. Ujednolicenie bez semantyki tworzy nowe błędy.
Źródło przy wartości
Zachowaj stronę, sekcję, fragment lub współrzędne. Człowiek powinien móc sprawdzić pole bez szukania całego dokumentu. Model nie powinien zwracać wartości bez dowodu, jeżeli proces wymaga faktu.
Przy wielu źródłach zapisz wybór i konflikt. Nie wybieraj najnowszego automatycznie. Może tabela zawiera szczegóły, a nagłówek skrót. Właściciel decyduje o regule.
Przy polu obliczonym zachowaj składniki. Suma może być poprawna matematycznie i błędna przy złym odczycie jednej wartości. Odbiór powinien pokazać obie warstwy.
Braki mają typy
Rozróżnij brak w dokumencie, nieczytelne pole, nie dotyczy i nieznane. Nie używaj jednego pustego tekstu dla wszystkiego. Null z powodem jest często lepsze niż magiczne zero lub „BRAK”.
Nie zgaduj braków z podobnych dokumentów. Model może zaproponować pole do uzupełnienia, ale propozycja nie powinna trafić do zatwierdzonego zapisu bez sprawdzenia. Proces powinien zatrzymać lub eskalować.
Przy polu wymaganym zdefiniuj skutek braku: odbiór, odrzucenie, brak publikacji. Przy opcjonalnym zachowaj brak bez blokowania całości, jeżeli nie wpływa na decyzję.
Typy i jednostki
Zapisz daty, kwoty, liczby, identyfikatory i tekst zgodnie z formatem. Nie zmieniaj identyfikatora w liczbę, bo zera wiodące mają znaczenie. Przy dacie zachowaj strefę i kontekst.
Oddziel wartość od jednostki i waluty. „1 234,56” wymaga reguły formatu. Przy wymiarach nie zgaduj centymetrów ani cali. Model powinien zwracać oryginał i znormalizowaną wartość z regułą.
Przy polskich znakach sprawdź eksport i kodowanie. OCR może być poprawny, ale kolejny format może go zniszczyć. Przewodnik o OCR dokumentów AI opisuje testy.
Schema opisuje strukturę, nie prawdę
Zdefiniuj wymagane pola, typy, enumy i relacje. JSON Schema pomaga walidować kształt, ale nie potwierdza faktów. Model może zwrócić poprawną strukturę z błędną kwotą.
Dodaj reguły biznesowe w aplikacji: data mieści się w dopuszczalnym dla danego dokumentu okresie albo wymaga wyjaśnienia, waluta należy do listy, suma zgodna przy kompletnych danych, identyfikator istnieje w źródle. Nie próbuj opisywać wszystkiego w prompcie.
Przy kontrakcie pomocny jest przewodnik o JSON Schema AI. Struktura i znaczenie są osobnymi testami.
Warianty dokumentów wymagają mapowania
Zapisz typ dokumentu przed ekstrakcją. Faktura, umowa i formularz mają inne pola. Nie twórz jednego wielkiego schematu z dziesiątkami pustych wartości dla każdego.
Przy wariantach tego samego typu zachowaj wspólne źródło i mapę różnic. Jeżeli dostawca zmienia nazwę pola, mapa powinna być wersjonowana. Nie przepisuj całego procesu dla nowego układu.
Przy nieznanym typie zatrzymaj automatyczne mapowanie. Model może zaproponować kategorię, ale właściciel potwierdza. Błędna klasyfikacja przypisuje złe reguły do dalszych pól.
Tabele i relacje
Zachowaj nagłówki, wiersze, jednostki i powiązania. Nie wyciągaj wartości jako luźnej listy. Przy pozycjach faktury relacja opis-ilość-cena-VAT jest ważna dla skutku.
Przy pustych komórkach nie przesuwaj wartości. Model powinien zachować puste miejsce i źródło. Przy scalonych nagłówkach zapisz grupę zgodnie z układem.
Nie obliczaj sumy bez sprawdzenia kompletności. Jeżeli strona jest niepełna, raport powinien oznaczać zakres. Dokument Intelligence oferuje ekstrakcję struktur, ale proces musi ocenić ich sens.
Walidacja przed zapisem
Najpierw struktura, potem typy, potem reguły i źródło. Na końcu skutek w docelowym systemie. Każdy etap powinien zatrzymywać niezgodność z jasnym komunikatem.
Nie poprawiaj danych automatycznie na podstawie podobnych rekordów. Przy konflikcie przypisz właściciela. Zapisz wersję schematu i źródła, żeby odtworzyć decyzję.
Przy płatności i publikacji dodaj odbiór człowieka. Przy wyszukiwaniu możesz zaakceptować mniej pewne wartości z oznaczeniem. Zakres zależy od skutku.
Przykład: pole „data” z trzema znaczeniami
Dokument zawiera datę wystawienia, dostawy i płatności. Model zwraca jedną najbardziej widoczną. Raport pokazuje nieterminowość, bo używa złej daty. Struktura jest poprawna, znaczenie błędne.
Słownik rozdziela pola i źródła. Reguła wybiera wymaganą datę zgodnie z typem dokumentu, a nie z kolejności na stronie. Test obejmuje wszystkie trzy i brak jednej.
Po odbiorze zapisujesz oryginalny fragment przy każdej. Czytelnik może sprawdzić decyzję bez zgadywania intencji autora.
Test na małym zestawie
Przygotuj typowy dokument, wariant, brak pola, konflikt i nieczytelny skan. Zapisz oczekiwane wartości przed modelem. Dodaj polskie znaki, różne formaty dat i puste komórki.
Porównaj każde pole z oryginałem, nie tylko ogólny wynik. Klasyfikuj błędy: OCR, układ, mapowanie, typ, reguła. Każdy wymaga innej poprawki.
Po zmianie schematu lub modelu powtórz zależne przypadki. Zachowaj kilka kontrolnych. Nowa wersja może poprawiać tekst i pogarszać relacje.
Odbiór przez osobę procesu
Pokaż pola i źródła przy krytycznych przypadkach. Właściciel powinien zobaczyć, skąd pochodzi wartość i jaki jest skutek błędu. Zakres kontroli dobierz do ryzyka: przy wysokim skutku błędu może być potrzebny odbiór każdego dokumentu lub każdej krytycznej wartości.
Zapisz poprawki i powtarzające się braki. Jeżeli model zgaduje to samo pole, zmień regułę lub źródło. Nie przenoś odpowiedzialności na człowieka bez zmiany procesu.
Po wdrożeniu porównaj czas odbioru z procesem ręcznym. Automatyzacja ma zmniejszać pracę, a nie tylko przyspieszać produkcję pól do sprawdzenia.
Kiedy zatrzymać ekstrakcję automatyczną
Zatrzymaj przy nieznanym typie, braku stron, konflikcie wersji, nieczytelnych polach i dużym skutku błędu. Nie pozwól modelowi uzupełniać źródła z podobnych dokumentów.
Przy poufnych danych oceń kanał i retencję przed przetwarzaniem. Schemat nie chroni informacji. Wynik powinien zawierać minimalny zakres.
Migracja schema bez zgubienia historii
Przy zmianie pola zapisz starą i nową wersję oraz mapę. Nie zmieniaj znaczenia pod tą samą nazwą bez informacji. Konsument powinien wiedzieć, czy dane historyczne wymagają przeliczenia czy tylko nowego odczytu.
Najpierw przygotuj czytnik obu wersji i porównaj przypadki. Potem włącz nowy zapis. Przy błędzie przywróć poprzednią wersję konfiguracji, ale oceń wyniki zapisane w nowym formacie. Sam rollback schema nie przepisuje historii.
Zachowaj datę i właściciela zmiany. Nowa wersja może wymagać nowych źródeł lub odbioru. Test powinien obejmować stare dokumenty i nowe typy.
Kiedy ekstrakcja nie jest potrzebna
Jeżeli źródło ma dobry eksport strukturalny, użyj go zamiast modelu. Nie odtwarzaj danych z PDF-a tylko dla obecności AI. Prosty eksport zmniejsza błędy i koszt.
Przy jednorazowym dokumencie ręczny odczyt kilku pól może być szybszy niż przygotowanie procesu. Oceń wolumen i ryzyko. Automatyzacja nie jest celem sama w sobie.
Jeżeli pytanie dotyczy opisu dokumentu, może streszczenie wystarczyć bez ekstrakcji pól. Nie przenoś wszystkiego do danych strukturalnych bez konsumenta.
Karta jakości przy każdym polu
Zapisz wymagane, źródło, typ, brak, regułę i właściciela. Dodaj liczbę błędów i czas odbioru. To pozwala poprawiać konkretne pola zamiast oceniać cały model ogólnie.
Przy zmianie źródła lub typu dokumentu powtórz zależne pola i jeden kontrolny. Nie przepisuj całego schematu dla każdej nowej wersji. Właściciel powinien widzieć zakres zmiany.
Przy ocenie jakości oddziel poprawność odczytu od użyteczności pola. Model może poprawnie przepisać tekst, którego proces nie potrzebuje. Usuń zbędne pola zamiast optymalizować ich odbiór. Każde powinno prowadzić do decyzji lub wyszukiwania.
Przy nowym źródle zachowaj próbkę oczekiwanych wartości i porównaj typy. Nie mapuj nowych pól tylko przez podobieństwo nazw. Właściciel potwierdza znaczenie i regułę.
Jeżeli wynik jest używany przez kolejny model, ogranicz przekazywanie błędów. Walidacja przed zapisem nie wystarcza przy późniejszej analizie. Zapisz niepewność i źródło przy każdej wartości.
Przy zakończeniu procesu usuń pliki robocze i potwierdź eksport. Wynik nie powinien zostawiać nowych kopii poufnych dokumentów w narzędziu analitycznym.
Przy zmianie właściciela przekaż słownik pól, wersje schema i przypadki. Nowa osoba powinna umieć ocenić jedno źródło i wynik bez zgadywania definicji. Nie przenoś tylko kodu ekstrakcji.
Jeżeli nowe pole nie ma właściciela ani konsumenta, nie dodawaj go produkcyjnie. Może zostać w analizie roboczej. Ogranicza to zbędne dane i koszt odbioru.
Przy kolejnych dokumentach porównaj czas poprawek z procesem ręcznym. Automatyzacja ma dawać wynik, a nie zwiększać liczbę pól do ręcznego sprawdzania.
Przy odbiorze nowego schematu wykonaj jeden pełny zapis testowy. Sprawdź typy, źródło i skutek w docelowym systemie. Sam obiekt w podglądzie nie wystarcza przy relacjach i kodowaniu.
Zapisz błędy jako pola i wersje, nie tylko ogólny wynik modelu. Właściciel powinien wiedzieć, które reguły poprawić i których przypadków nie wolno publikować.
Przy odbiorze końcowym porównaj liczbę pól oczekiwanych i zwróconych. Brak lub nowe pole powinno mieć powód, a nie być uznane za poprawę. To ogranicza niekontrolowane wzbogacanie.
Zachowaj wersję mapy i datę odbioru. Przy kolejnym dokumencie wiesz, które reguły zostały sprawdzone i gdzie wymagana jest nowa decyzja.
Aeneia Audit pomaga zmapować pola i proces. Przy większej ekstrakcji pomocny jest przewodnik Aeneia Signal o workflow.
Zmiana dokumentu wymaga porównania znaczenia pól, a nie tylko ich nazw. Wartość bez źródła lub właściciela odbioru zostaw do wyjaśnienia przed przekazaniem jej dalej.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
