AI, które nie ma prawa zmyślać - jak przepisać dokument 1:1

Firma rekrutacyjna dostaje CV kandydata w PDF i przepisuje je do własnego szablonu. Wymóg brzmi prosto: 1:1. Żadnego poprawiania, żadnego skracania, żadnego „ładniejszego" sformułowania. Nazwa firmy ma zostać dokładnie taka, jaką wpisał kandydat - również wtedy, gdy jest w niej literówka.

Wygląda na zadanie idealne dla modelu językowego. Jest dokładnie odwrotnie. To zadanie, w którym LLM zawodzi ze swojej natury, bo został wytrenowany po to, żeby pisać poprawnie, a nie po to, żeby pisać wiernie.

Ten wpis opisuje architekturę, którą zbudowaliśmy, żeby to obejść. Przykładem są CV, ale ten sam wzorzec dotyczy każdego dokumentu, w którym treść jest źródłem prawdy: umów, protokołów, polis, decyzji administracyjnych, faktur.

Dlaczego „wrzuć PDF i poproś o przepisanie" nie działa

Przepuściliśmy korpus 31 CV przez model multimodalny i porównaliśmy wynik z warstwą tekstową PDF-a - czyli ze znakami, które w pliku faktycznie są. Zgodność wyszła 0,991. Średnio 1,4 słowa na CV różniło się od źródła.

Brzmi jak wynik zamykający temat, dopóki nie zajrzy się w te 1,4 słowa. Rozbiły się na trzy kategorie:

1. Model naprawia defekt pliku. W PDF-ach z rozstrzelonym trackingiem nagłówek zapisany jest jako J A N U A R Y. Model zwraca January - i ma rację, bo w dokumencie widać jedno słowo.
2. Model wprowadza własny błąd. hereby zamiast thereby, nazwa narzędzia przekręcona o jedną literę, polskie nazwisko pozbawione diakrytyku.
3. Model poprawia literówkę oryginału. W CV było githab, w wyniku jest github.

Kategoria trzecia jest najgroźniejsza, bo wygląda na przysługę. W dokumencie, który ma być wierny, jest błędem dokładnie tej samej wagi co kategoria druga. Rekruter nie ma prawa poprawić nazwy firmy w CV kandydata, tak jak księgowa nie ma prawa poprawić nazwy kontrahenta na fakturze.

Dwie rzeczy czynią to realnym ryzykiem operacyjnym. Po pierwsze, błąd jest systematyczny, a nie losowy - model konsekwentnie optymalizuje „poprawne słowo", nie „to, co jest na kartce". Po drugie, jest niewidoczny przy odbiorze: tekst czyta się dobrze, więc nikt go nie kwestionuje. Halucynacja, którą widać, jest problemem technicznym. Halucynacja, której nie widać, jest problemem prawnym.

Żadne źródło nie jest czystym autorytetem

Naturalny odruch brzmi: skoro model zmyśla, weźmy tekst prosto z pliku. Nie działa, bo każde źródło jest wiarygodne w innym wymiarze.

• Warstwa tekstowa PDF jest wierna znakowo - to dokładnie te znaki, które wstawił autor. Ale gubi kolejność. Przy dwóch kolumnach, rynnie dat czy pasku nagłówka dostajemy właściwe znaki poskładane w bezużyteczną kolejność, w której data jednej roli ląduje przy innym pracodawcy.
• Model multimodalny, który widzi obraz strony, świetnie odtwarza kolejność i parowanie etykiety z wartością. Ale nie jest wierny znakowo (patrz wyżej).
• OCR czyta to, co widać, niezależnie od struktury pliku. Przy czym dla polskiego wybór silnika jest rozstrzygający: w naszych testach Tesseract z modelem pol osiągał 0,93-0,96 zgodności, a popularny lekki silnik oparty na ONNX - 0,44-0,52, bo gubił ogonki i sklejał wyrazy. Przy okazji był trzykrotnie wolniejszy.

Stąd zasada, która okazała się sednem całej architektury: rozdziel role. Znaki bierzemy z warstwy tekstowej. Kolejność - z modelu. OCR jest świadkiem, który rozstrzyga spory.

Głosowanie zamiast zaufania

Mechanizm jest deterministyczny i mieści się w kilkudziesięciu linijkach kodu. Bazą jest tekst od modelu, bo on ma dobrą kolejność. Znaki korygujemy tam, gdzie warstwa tekstowa i OCR zgodnie mówią co innego niż model - dwa głosy przeciw jednemu. Tam, gdzie OCR nie potwierdza warstwy, nie poprawiamy niczego, tylko podnosimy flagę do przeglądu przez człowieka.

Ta druga reguła jest ważniejsza, niż wygląda. Bez niej algorytm „poprawiał" dobry tekst modelu na podstawie zniekształconej warstwy - lekarstwo szkodliwsze od choroby.

Wynik na korpusie 31 CV: 36 korekt, około 7 flag, zero przypadków zepsucia poprawnego tekstu. Ponieważ spornych miejsc jest średnio 1,4 na dokument, człowiek ogląda jedno-dwa miejsca, a nie cały dokument. To jest cała różnica między „AI przepisało, sprawdź całość" a „AI przepisało, sprawdź te dwa słowa".

Czy nie prościej użyć lepszego modelu

Sprawdziliśmy i to. Mały model lokalny w roli arbitra 40 spornych miejsc: 23 razy zgodził się z głosowaniem, 4 razy „poprawił" oryginał (czyli złamał wymóg 1:1), 13 razy nie umiał zdecydować. Jako narzędzie wierności - nieprzydatny.

Duży model chmurowy dostał 7 flag razem z kontekstem i poradził sobie zdecydowanie lepiej: 6 rozstrzygnął sensownie, a przy jednej uczciwie napisał, że nie wie. Tyle że w dwóch przypadkach dołożył wiedzę spoza dokumentu - rozwinął skrót do pełnej nazwy narzędzia i uzupełnił człon nazwy firmy. Trafnie. Tylko nie z tekstu, który miał przed sobą.

Wniosek jest niewygodny dla sprzedawców modeli: lepszy model nie jest lekarstwem na wierność, bo problem nie leży w jakości modelu, tylko w tym, do czego się go używa. Do kolejności i struktury - tak. Do decydowania, jaki znak jest na kartce - nie. Werdykty dużego modelu traktujemy jako sugestie do przeglądu, nigdy jako automatyczną podmianę.

Strażnik verbatim: model przypisuje, nie przepisuje

Drugi etap to zamiana wiernego tekstu na strukturę - pola szablonu. Tu również kluczowe jest sformułowanie zadania. Model nie dostaje polecenia „napisz sekcję doświadczenie". Dostaje wierny tekst i ma przypisać istniejące fragmenty do pól. To ekstrakcja, nie generowanie.

Po modelu uruchamia się deterministyczny strażnik: sprawdza, czy każdy fragment wyjścia występuje dosłownie w zamrożonym źródle. Co nie przechodzi, trafia do przeglądu. To kontrola bardzo tania - porównanie łańcuchów znaków - a odcina całą klasę halucynacji, zanim ktokolwiek zobaczy dokument.

Testy dały przy okazji lekcję projektową, która wygląda na drobiazg, a przesądza o wyniku: pola muszą być atomowe. Dopóki schemat miał jedno pole łączące pracodawcę z rolą, model musiał te dwie rzeczy skleić - a samo sklejenie łamie wierność, bo powstaje ciąg znaków, którego w źródle nie ma. Strażnik wyłapał to trzykrotnie. Rozbicie na osobne pola i sklejanie dopiero na etapie renderu rozwiązało problem całkowicie.

Zgoda na przetwarzanie to nie zgoda na chmurę

CV to dane osobowe, a duża część opisanego pipeline’u działa na surowym dokumencie. Dlatego anonimizacja odbywa się lokalnie, zanim cokolwiek pojedzie do chmury, a dane wracają na miejsce po przetworzeniu.

Skuteczność na tym samym korpusie: imię i nazwisko, e-mail i telefon - 31 na 31. Adresy okazały się trudniejsze: sam regex wyłapał 4, hybryda regexu z małym modelem lokalnym - 16, przy zerowej liczbie przecieków. Dwie próby zmyślenia przez model odrzuciła weryfikacja verbatim, bo detektor ma prawo wskazać wyłącznie wartość obecną w tekście. Model jest tu detektorem, nie edytorem - podmiany robi kod.

Jedna pułapka warta zapamiętania: gdy w tekście pojawiły się nieprzezroczyste tokeny zastępujące dane osobowe, model uznał je za „brak danych" i zaczął gubić całe pola. Trzeba mu wprost powiedzieć, czym te tokeny są i że mają trafić do właściwych pól.

I rzecz, którą warto mówić klientom głośno: zgoda kandydata na przetwarzanie danych przez firmę nie jest zgodą na wysłanie tych danych do dostawcy modelu poza UE. Dlatego etapy dotykające surowego dokumentu projektujemy pod model uruchamiany lokalnie, na sprzęcie klienta. W testach porównawczych modele lokalne wypadły zresztą nie gorzej niż chmurowe, o czym pisaliśmy szerzej przy okazji raportu o RAG na danych firmowych.

Gdzie kończy się AI, a zaczyna człowiek

Wyjściem pipeline’u nie jest gotowy dokument, tylko ścisły format pośredni - Markdown z jasno określoną gramatyką. Treść siedzi w polach, układ jest w rendererze. Człowiek poprawia treść i regeneruje dokument w kilka sekund, zamiast walczyć z formatowaniem w edytorze. Parser jest przy tym celowo nietolerancyjny: przy dwuznaczności rzuca błąd, zamiast się domyślać.

Jest też rzecz, której narzędzie nie robi w ogóle - i to świadomie. W docelowym profilu jest panel ocen kompetencji w skali 1-5. Analiza gotowych profili pokazała, że to subiektywna decyzja rekrutera, a nie ekstrakcja: w jednym z nich pojawia się kompetencja, która nie pada w źródłowym CV ani razu. Automat, który zgadywałby takie oceny, produkowałby dokładnie te halucynacje, których cały pipeline unika. Pole zostaje puste, wypełnia je człowiek.

Siedem zasad przenośnych na inne dokumenty

1. Rozdziel role. Znaki z tego źródła, które jest wierne znakowo. Kolejność i struktura z modelu. Nigdy odwrotnie.
2. Zamroź źródło. Cokolwiek wychodzi z modelu, musi dać się porównać z niezmienionym oryginałem.
3. Weryfikuj deterministycznie. Porównanie łańcuchów kosztuje ułamek grosza, drugi model kosztuje pieniądze i wnosi nową klasę błędów.
4. Trzeci głos tam, gdzie źródła się kłócą. Dwa na trzy głosy rozstrzygają, jedno źródło nie wystarcza.
5. Flaga zamiast zgadywania. Gdy nie ma większości, dokument idzie do człowieka - z zaznaczonym miejscem, a nie w całości.
6. Anonimizuj przed chmurą, a detektor danych osobowych niech wskazuje, nie przepisuje.
7. Zostaw człowiekowi to, co jest oceną, a nie odczytem. Automatyzacja oceny wygląda jak oszczędność, a jest generatorem ryzyka.

Co z tego wychodzi w praktyce

Praca, która polegała na ręcznym przepisywaniu całego dokumentu, zmienia się w przegląd jednego-dwóch zaznaczonych miejsc i ewentualną korektę treści w formularzu. Nie dlatego, że model stał się nieomylny, tylko dlatego, że w architekturze nie ma miejsca, w którym mógłby coś dopisać niezauważenie.

To jest w ogóle sedno sensownych wdrożeń AI przy dokumentach: system wyciąga dane, człowiek zatwierdza. Zysk czasowy jest niemal taki sam jak przy pełnej automatyzacji, a ryzyko - nieporównywalnie mniejsze.

Jeśli macie proces, w którym ktoś przepisuje treść z jednego dokumentu do drugiego i nie wolno mu przy tym niczego zmienić, to jest dokładnie ten przypadek. Zaczynamy zwykle od audytu jednego procesu - żeby najpierw sprawdzić, czy w ogóle warto. Napiszcie do nas, pierwsza analiza jest bezpłatna.