W podglądzie wszystko jest dobrze. W eksporcie „Zażółć gęślą jaźń” zamienia się w krzaki, „Łódź” w „Lodz”, a nazwisko klienta w inną osobę. Model nie musi zgadywać źle; czasem wystarczy zły OCR, parser albo kodowanie CSV. Test polskiego tekstu powinien obejmować całą ścieżkę.
Diakrytyka to nie kosmetyka. Wpływa na wyszukiwanie, identyfikatory, nazwy i znaczenie. Odmiana dodatkowo zmienia formę słów bez zmiany intencji, więc proste porównanie słowo w słowo nie wystarcza.
Zbuduj zestaw znaków i pól krytycznych
Przygotuj przykłady z ą, ć, ę, ł, ń, ó, ś, ź, ż w różnych pozycjach i wielkościach liter. Dodaj „Zażółć gęślą jaźń”, ale także rzeczywiste nazwy miejscowości, firm i pojęć procesu. Zdanie testowe nie wystarcza przy danych biznesowych.
Rozdziel pola opisowe od identyfikatorów. Błąd w komentarzu może być kosmetyczny, w nazwie firmy lub kodzie krytyczny. Zapisz skutek dla każdego typu. Nie wymagaj jednakowego progu przy każdym tekście.
Zachowaj oryginał i oczekiwany wynik. Test powinien porównywać pola, a nie tylko oceniać, czy tekst wygląda „mniej więcej polsko”.
Testuj całą ścieżkę kodowania
Sprawdź wejście, OCR, JSON, bazę, eksport CSV, arkusz i publiczną stronę. Błąd może powstać po poprawnym odczycie. Nie wystarczy podgląd w edytorze modelu.
Otwórz eksport w docelowym narzędziu. Excel może wymagać właściwego kodowania i formatu. Nie akceptuj samego faktu, że plik ma rozszerzenie CSV. Zawartość musi zachować znaki i strukturę.
Przy API sprawdź deklarację kodowania i przetwarzanie. Nie poprawiaj krzaków po fakcie bez źródła. Napraw etap, który je tworzy, i powtórz przypadek zależny.
OCR i diakrytyka
Przygotuj dobry skan, zdjęcie i dokument z mniejszym fontem. Dodaj ł, ó, ż, ś, ć w nazwach i kwotach z polskimi komentarzami. Model może mylić znaki podobne wizualnie. Oceń pola osobno.
Nie poprawiaj automatycznie według słownika prawdopodobnych słów. Może zmieniać właściwą nazwę w inną. Przy identyfikatorze zachowaj oryginalny odczyt i oznacz niepewność do odbioru.
Przewodnik o OCR polskich dokumentów opisuje testy warstw. Diakrytyka jest jedną z nich, nie osobnym światem.
Odmiana i wyszukiwanie
Przygotuj formy tego samego pojęcia w różnych przypadkach i liczbach. „Dokument”, „dokumentu”, „dokumentowi”, „dokumenty” mogą dotyczyć tego samego źródła. Wyszukiwanie powinno to obsłużyć zgodnie z celem.
Nie normalizuj tekstu na podstawie prostego usuwania końcówek. Polska odmiana jest zbyt złożona dla uniwersalnej reguły. Możesz użyć odpowiedniej analizy językowej lub słownika procesu, ale testuj błędy.
Przy nazwach własnych zachowaj formę źródłową. Nie zmieniaj nazwiska dla łatwiejszego grupowania bez potwierdzenia. Model może zaproponować relację, ale nie powinien scalać osób po podobnej formie.
Normalizacja bez utraty oryginału
Zapisz wersję roboczą do porównań i oryginał do wyświetlenia. Możesz zmieniać wielkość liter i spacje według reguły, ale zachowuj źródło. Usuwanie diakrytyki do wyszukiwania nie powinno nadpisywać pola oficjalnego.
Oceń, czy normalizacja nie tworzy fałszywych duplikatów. „Łukasz” i „Lukasz” mogą być wariantami, ale nie zawsze dowodzą tej samej osoby. Decyzja o tożsamości wymaga innych pól.
Przy deduplikacji stosuj zasady z artykułu o kontaktach CRM z AI. Normalizacja jest pomocą, nie dowodem.
Testy odpowiedzi generatywnej
Sprawdź, czy model zachowuje polskie znaki przy skracaniu, tłumaczeniu i formacie. Może je zastępować wariantami uproszczonymi bez potrzeby. Wynik powinien odpowiadać źródłu i kanałowi.
Dodaj tekst z cudzysłowami, myślnikami i znakami specjalnymi. Model może zmieniać typografię przy przepisywaniu. Nie każda zmiana jest błędem, ale przy kodzie i identyfikatorach ma skutek.
Przy odpowiedzi strukturalnej sprawdź JSON i escapowanie. Poprawny format nie oznacza poprawnej treści. Porównaj zdekodowane pole z oryginałem.
Tłumaczenie i wersje językowe
Nie usuwaj diakrytyki z polskiej wersji tylko dlatego, że angielska jej nie ma. Zachowaj właściwe formy nazw i pojęć. Przy tłumaczeniu zapisz słownik i źródło terminu.
Sprawdź, czy model nie tłumaczy nazwisk i firm na zasadzie kreatywności. Może zachować oryginał lub zatwierdzony wariant. Nie zgaduj transliteracji.
Przy wersji roboczej oznacz tłumaczenie i właściciela. Przewodnik o tłumaczeniach AI i słowniku opisuje odbiór terminologii.
Test publicznego renderowania
Otwórz stronę z polskimi znakami w różnych fontach i urządzeniach. Sprawdź brak podmiany glifów, poprawne linie i czytelność. Sam plik fontu może być poprawny, ale brakować znaku w konkretnym wariancie.
Nie zastępuj tekstu obrazkiem dla ukrycia problemu. To pogarsza dostępność i wyszukiwanie. Napraw kodowanie i font. Tekst alternatywny powinien zachować polskie znaki.
Przy danych strukturalnych sprawdź JSON-LD i metadane. Poprawny HTML nie oznacza poprawnych danych w innych częściach strony.
Przykład: nazwa firmy w trzech systemach
Źródło zawiera „Żagiel sp. z o.o.”. OCR zwraca „Zagiel”, CRM zachowuje wariant bez diakrytyki, a eksport tworzy trzecią formę. Model proponuje trzy nowe firmy. Proces powinien porównać źródło i identyfikatory, nie tylko tekst.
Zachowaj warianty i zasady mapowania. Jeżeli istnieje NIP lub inny identyfikator, użyj go zgodnie z procesem. Nie przypisuj firmy na podstawie podobieństwa nazwy.
Po poprawce powtórz pełną ścieżkę eksportu. Wynik ma być poprawny w źródle i na końcu, a nie tylko w tabeli roboczej.
Diagnoza błędów według warstwy przetwarzania
Zły znak w OCR to inna poprawka niż usunięcie diakrytyki przez normalizację, błędne kodowanie CSV albo model zmieniający tekst. Zapisz warstwę przed zmianą narzędzia. Nie przenoś problemu do nowego modelu bez diagnozy.
Dodaj przypadki naprawione do regresji. Po aktualizacji biblioteki lub fontu powtórz zależne testy. Poprawa jednego formatu może pogorszyć inny.
Raport powinien pokazywać oryginał, wynik i etap błędu. Bez tego zespół widzi tylko krzaki i zgaduje odpowiedzialnego.
Automatyczne reguły z wyjątkami
Sprawdzaj obecność znaków zastępczych, utratę diakrytyki i niezgodność kodowania automatycznie. Nie blokuj każdego braku diakrytyki, bo źródło może jej nie zawierać. Test ma wykrywać zmianę, nie obecność polszczyzny.
Dodaj listę pól i wartości krytycznych do kontroli. Przy identyfikatorach porównuj dokładnie, przy opisach oceń skutek. Nie zgłaszaj każdej zmiany stylu jako błędu krytycznego.
Po naprawie uruchom tylko zależne przypadki i kontrolny poprawny. Audyt ma ograniczać regresję bez zatrzymywania całej publikacji przy każdej literówce.
Kiedy człowiek musi odebrać
Eskaluj identyfikatory, nazwy prawne, dane klientów i niepewne odczyty. Człowiek powinien zobaczyć oryginał i skutek. Nie przypisuj poprawki na podstawie najbardziej prawdopodobnej formy.
Przy tłumaczeniach i dokumentach prawnych wymagaj właściwej kompetencji. Model może przygotować wariant, ale nie zatwierdzać znaczenia.
Dane wejściowe do testów bez prawdziwych nazwisk
Przygotuj fikcyjne nazwy zawierające wszystkie potrzebne znaki i formy. Nie używaj rzeczywistych klientów do sprawdzenia każdej diakrytyki. Ważne jest zachowanie struktury i ryzyka, a nie konkretna osoba. Zapisz oczekiwane wartości ręcznie przed uruchomieniem.
Dodaj nazwy podobne wizualnie i fonetycznie. Test powinien wykazać, czy proces oznacza niepewność zamiast wybierać automatycznie. Fikcyjne pary pozwalają sprawdzić błędne scalenia bez ujawniania historii.
Przy udostępnianiu zestawu oceń, czy przypadki nie przypominają rzeczywistych osób przez inne szczegóły. Syntetyczny tekst również wymaga ograniczenia kontekstu.
Odbiór przez polskiego recenzenta
Poproś osobę pracującą natywnie z językiem procesu o sprawdzenie krytycznych pól i tekstu. Nie chodzi tylko o poprawność gramatyki. Chodzi o to, czy nazwa i znaczenie zgadzają się z kontekstem. Model może być formalnie poprawny i przypisywać złą osobę.
Recenzent powinien widzieć oryginał, odczyt i wynik końcowy. Bez pełnej ścieżki może poprawić tylko objaw. Zapisz etap, który zmienił znak, i test powtórny.
Przy tłumaczeniu dodaj właściciela terminologii. Polski zespół może używać innego wariantu niż model ogólny. Nie przepisuj wszystkiego na zasadzie statystycznej popularności.
Minimalna regresja dla każdej publikacji
Przy zmianie treści sprawdź krytyczne nazwy i kodowanie wyjścia. Nie musisz uruchamiać pełnego zestawu przy każdej literówce. Wybierz pola zależne i jeden przypadek kontrolny z pełnym zestawem diakrytyki.
Przy zmianie fontu, parsera lub eksportu zwiększ zakres do pełnej ścieżki. To są typowe miejsca regresji bez zmiany samej treści. Wynik powinien być porównany z oryginałem i publicznym renderem.
Zapisz wersję narzędzia i datę testu. Przy błędzie wiesz, czy problem pojawił się po zmianie kodu, źródła czy formatu.
Przy raporcie porównawczym zaznacz, czy błąd jest zmianą znaku, jego usunięciem, podmianą czy problemem renderowania. Różne typy mają różne poprawki. Nie zapisuj wszystkiego jako „problem z polskim”, bo to nie prowadzi do rozwiązania.
Przy nazwach własnych zachowaj wersję źródłową i wariant roboczy obok siebie. Czytelnik powinien widzieć, co zostało zmienione przez proces. Nie poprawiaj oryginału bez decyzji właściciela.
Jeżeli błąd występuje w konkretnym kanale, zacznij tam diagnozę, ale sprawdź także inne kanały korzystające z tej samej konwersji lub kodowania. Nie zmieniaj całego modelu lub procesu, jeżeli problem dotyczy kodowania jednego eksportu.
Przy zakończeniu przetwarzania sprawdź archiwum i linki publiczne. Tekst może być poprawny w edytorze, ale stara wersja nadal widoczna. Odbiór kończy się na wyniku dla użytkownika.
Przy zmianie właściciela źródła przekaż warianty zapisu i zasady normalizacji. Nowa osoba powinna wiedzieć, które formy są oficjalne, a które tylko robocze. Nie przenoś jednej wersji tekstu bez kontekstu.
Przy kolejnych eksportach zachowaj przypadki naprawione. Biblioteka lub konfiguracja może zmienić kodowanie bez edycji treści. Test powinien je wychwycić przed publikacją.
Jeżeli nazwa jest niejednoznaczna, zapisz źródło i niepewność. Nie wybieraj wersji uproszczonej dla wygody raportu. Właściciel potwierdza oficjalną formę i skutek.
Przy odbiorze nowego kanału przygotuj jeden dokument z pełnym zestawem znaków i wykonaj eksport. Nie przenoś wyniku z innego formatu bez sprawdzenia. Kodowanie może się różnić mimo tego samego modelu.
Zapisz, które pola mogą być normalizowane i które wymagają oryginału. To ogranicza automatyczne poprawki nazw i identyfikatorów.
Przy odbiorze końcowym sprawdź również tekst alternatywny i metadane. One mogą zawierać stare znaki lub uproszczenia niezgodne z dokumentem. Nie poprawiaj tylko głównego widoku.
Zachowaj wersję zestawu i właściciela decyzji. Przy kolejnych zmianach procesu nowa osoba powinna umieć odtworzyć błąd zamiast zgadywać poprawki.
Aeneia Audit pomaga zmapować przepływ danych i odbiór. Przy źródłach pomocna jest architektura wiedzy Aeneia Signal.
Przed oddaniem dokumentu otwórz końcowy plik na urządzeniu odbiorcy i porównaj zapis nazw, znaków oraz numerów z materiałem wejściowym. Zachowaj przypadek, który ujawnił błąd, w zestawie regresyjnym. Dzięki temu następna zmiana eksportu będzie sprawdzana na rzeczywistym problemie, a nie tylko na przykładowym zdaniu z polskimi znakami.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
