Poprawny JSON, błędne dane: czego nie sprawdzi za ciebie schemat odpowiedzi AI

Wynik jest zielony. Parser przyjął JSON, wszystkie pola mają właściwe typy, aplikacja dostała odpowiedź bez błędu. W rekordzie długość panelu wynosi jednak 240 metrów zamiast 240 centymetrów. Formalnie wszystko się zgadza. Magazyn potrzebowałby tylko nieco większych drzwi.

Dane strukturalne pomagają przekazywać wyniki AI do aplikacji, bo ograniczają swobodę formatu. Nie zastępują sprawdzenia, czy wartości znaczą to, co powinny. Audyt takiego procesu powinien rozdzielić poprawność zapisu, zgodność ze schematem oraz zgodność z dokumentem i zasadami zadania. Zielony wynik jednego etapu nie powinien nadawać koloru pozostałym.

Prześledźmy fikcyjny proces, w którym model odczytuje kartę wyposażenia i przygotowuje rekord do systemu zamówień. Potrzebne są identyfikator produktu, długość, jednostka, liczba sztuk i data dostępności. To wystarczająco mały przykład, by sprawdzić każdy krok, a jednocześnie pozwala zobaczyć kilka różnych klas błędu.

Co właściwie obiecuje schemat

JSON to sposób zapisu danych w rozpoznawalnej strukturze: obiekt zawiera nazwane pola, a te przechowują wartości. Schemat określa wymagania wobec takiego zapisu, na przykład typ liczby lub obecność identyfikatora. Osoba nietechniczna nie musi znać całej składni, żeby zapytać, co dokładnie jest sprawdzane i czego wynik walidacji nie obejmuje.

Dokumentacja JSON Schema dotycząca obiektów wyjaśnia, że samo wymienienie pól w properties nie czyni ich obowiązkowymi. Służy do tego required, a dopuszczanie dodatkowych pól ma osobne reguły. Dlatego oceniaj faktycznie używany schemat, zamiast ogólnej deklaracji „odpowiedź jest w JSON”.

W naszym procesie pole długości może wymagać liczby. Liczby 2,4 i 240 nadal są liczbami, choć opisują różne wartości. Schemat może ograniczyć część dozwolonych danych, jeśli zapisano odpowiednie warunki i mechanizm je obsługuje. Nie ustali jednak sam, który fragment karty źródłowej dotyczy długości wybranego wariantu.

Anthropic opisuje structured outputs jako ograniczanie odpowiedzi do obsługiwanego schematu i wymienia granice tej obsługi, między innymi dotyczące ograniczeń liczbowych. Nie zakładaj więc, że każda reguła zapisana w dowolnym schemacie jest automatycznie egzekwowana przez każde narzędzie. Sprawdź konkretny kontrakt użytej konfiguracji.

Przygotuj zapis używanego schematu i jego wersji. Jeżeli instrukcja mówi o centymetrach, schemat o metrach, a ekran o milimetrach, model nie jest jedynym miejscem powstawania pomyłki. Przejrzyj te trzy opisy razem z osobą znającą proces. Różnice usuń przed porównywaniem odpowiedzi, aby próba miała jedno uzgodnione oczekiwanie.

Dla odbioru przygotuj krótką mapę: co odrzuca parser, co sprawdza walidacja struktury, co porównuje się ze źródłem i co wymaga reguły procesu. Przy każdym polu wskaż odpowiedzialny etap. Taką mapę łatwiej przejrzeć z zespołem niż komunikat „model ma zwracać poprawne dane”, który brzmi rozsądnie, ale nie mówi, gdzie wykryjemy pomyłkę.

Liczba potrzebuje znaczenia

W karcie produktu długość zapisano jako 240 cm. Uzgodniony system oczekuje metrów. Poprawny wynik to 2,4 m, ale model może przepisać 240 i dołączyć jednostkę oczekiwaną przez aplikację. Pola osobno wyglądają poprawnie. Błędna jest relacja wartości, jednostki i źródła.

W próbie zachowaj zarówno wartość źródłową, jak i wynik przeliczenia. Zapisz regułę, której oczekujesz, oraz osobno oceń poprawność wyboru pola i przeliczenia. Jeżeli odczytano szerokość zamiast długości, prawidłowa konwersja nie naprawi rekordu. W raporcie nie wrzucaj obu pomyłek do ogólnej kategorii „problem z liczbami”.

Dodaj do materiału dwa warianty i podobne wartości. Karta może pokazywać wymiar produktu oraz wymiar opakowania. System powinien zwrócić dane właściwe dla zleconego zadania. Sama obecność poprawnej liczby w dokumencie nie dowodzi jeszcze, że odpowiedź używa jej w dobrym miejscu.

Przy OCR poprzedzającym pracę AI sprawdź także odczyt przecinka, znaku minus i oznaczenia jednostki. Błąd może powstać wcześniej niż odpowiedź modelu. Zachowanie fragmentu źródłowego pozwala odróżnić wadliwy odczyt od złej interpretacji poprawnie odczytanej wartości.

Sprawdź zaokrąglenie na granicy dopuszczalnego zakresu. Przyjmij w fikcyjnym zadaniu regułę wymaganą przez proces i przygotuj wartość tuż poniżej oraz tuż powyżej granicy. Zobacz, czy model, aplikacja i ekran pokazują ten sam wynik. Jeżeli dalsza operacja używa pełnej wartości, a człowiek zatwierdza zaokrągloną, zapisz tę różnicę jako część odbioru.

Liczba sztuk potrzebuje osobnej oceny. „Dwa zestawy po trzy elementy” może oznaczać dwa opakowania albo sześć elementów, zależnie od tego, co przechowuje pole. Nie rozstrzygaj tego intuicyjnie po zobaczeniu wyniku. Definicja jednostki zamówienia powinna istnieć przed uruchomieniem procesu i być zrozumiała dla osób korzystających z rekordu.

W arkuszu wykorzystywanym w procesie AI ta różnica może potem zasilić kolejne obliczenia. Test powinien przejść do miejsca użycia danych. Prawidłowe sumowanie błędnie zdefiniowanej liczby sztuk stworzy równie błędny wynik, tyle że z bardzo starannie policzonym podsumowaniem.

Brak wartości nie powinien udawać informacji

Dokument nie zawiera daty dostępności. Model zwraca pusty tekst, zero albo dzisiejszą datę. Każde rozwiązanie może przejść przez część pobieżnych kontroli, a każde oznacza coś innego dla dalszej aplikacji. Potrzebujesz uzgodnionej reprezentacji braku i działania, które z niej wynika.

Rozdziel brak pola, pusty tekst i wartość null, jeśli występują w kontrakcie. Następnie sprawdź, jak system docelowy je interpretuje. Przejdź całą drogę wartości: aplikacja może zamienić pusty tekst na wartość domyślną, nawet gdy model niczego nie dopowiedział. Raport powinien wskazać etap takiej zamiany.

Dla dat dodaj przypadek niejednoznaczny. Zapis z samymi cyframi może dawać różne interpretacje, jeżeli nie ustalono formatu wejścia. Osobno przygotuj datę poprawną składniowo, ale niepasującą do zadania: na przykład dzień zakończenia promocji wpisany jako dostępność. Kontrola samego kształtu daty nie odróżni tych znaczeń.

W planowaniu kalendarza przez AI dochodzą strefy i zakres konkretnego zdarzenia. Ten przykład pokazuje, dlaczego nazwa pola date bywa zbyt skromnym opisem kontraktu. Trzeba wiedzieć, czy chodzi o dzień, moment, termin graniczny czy początek zadania.

Dodaj sprzeczne źródła: tabelę z jedną datą i dopisek z inną. W oczekiwanym wyniku określ, czy proces ma zastosować jawną regułę pierwszeństwa, czy zgłosić konflikt. Nie oceniaj jako poprawnej dowolnej daty znalezionej w materiale. Ten przypadek odróżnia odczyt wartości od rozstrzygnięcia, której wolno użyć.

Nie zmuszaj modelu do wypełnienia obowiązkowego pola na podstawie domysłu, jeśli materiał go nie zawiera. Można wymagać jawnego statusu braku albo zatrzymać rekord przed użyciem. Wybór zależy od procesu, ale powinien być przewidziany w próbie. Uzupełniona tabelka nie jest celem, gdy jej kompletność powstała kosztem prawdziwości danych.

Identyfikator może wyglądać idealnie i wskazywać nic

Wynik zawiera kod produktu w oczekiwanym formacie. Trzeba jeszcze ustalić, czy taki produkt istnieje i czy odpowiada właściwemu wariantowi. Przygotuj trzy przypadki: znany identyfikator, nieistniejący kod o poprawnej budowie i istniejący kod innego wariantu. Tylko pierwszy spełnia zadanie, choć wszystkie mogą wyglądać wiarygodnie.

Oceń normalizację zapisu oddzielnie od poprawiania treści. Usunięcie odstępów z identyfikatora może być uzgodnioną operacją, lecz zamiana podobnej litery na cyfrę wymaga podstawy. Zachowaj wejściową wartość i regułę przekształcenia. Bez nich trudno później ustalić, czy błędny kod powstał podczas odczytu, odpowiedzi modelu czy automatycznej korekty aplikacji.

Sprawdzenie istnienia powinno korzystać z właściwego katalogu lub innego uzgodnionego źródła. Nie proś tego samego modelu wyłącznie o potwierdzenie, że jego własna propozycja jest poprawna. W raporcie pokaż podstawę sprawdzenia i wersję źródła. Istnienie rekordu w starej kopii katalogu może nie wystarczać do bieżącego zastosowania.

Podobna pułapka występuje przy zależnościach proponowanych w kodzie AI. Nazwa biblioteki może przypominać prawdziwe nazwy, a mimo to nie opisywać właściwego pakietu. Poprawny ciąg znaków jest dopiero wejściem do kontroli tożsamości obiektu.

Gdy dane mają uruchomić działanie, powiąż walidację z uprawnieniami integracji AI. Sam fakt otrzymania poprawnego rekordu nie nadaje zgody na zamówienie ani zmianę katalogu. W kontrolowanym środowisku sprawdź, co aplikacja robi z rekordem odrzuconym i czy nie przekazuje go dalej inną ścieżką.

Przegląd w Aeneia Audit można rozpocząć od jednego przykładowego wejścia, schematu odpowiedzi i opisu następnej operacji. Dzięki temu wynik oceny odnosi się do rzeczywistego zastosowania, zamiast kończyć na sprawdzeniu nawiasów.

Odbierz trzy osobne wyniki

W zapisie próby pokaż poprawność struktury, zgodność wartości ze źródłem oraz zgodność z regułami procesu. Jeśli rekord przechodzi pierwszy etap i odpada na drugim, zachowaj tę informację. Pozwala ona naprawić odpowiedni fragment rozwiązania bez osłabiania działającej kontroli formatu.

Dodaj rekord z poprawnymi wartościami, ale przypisany do innego dokumentu. Jeżeli przygotowujesz do tego sztuczny zbiór próbny, sprawdź spójność relacji i zdarzeń w danych syntetycznych, aby wzór kontrolny sam nie zawierał przypadkowego błędu. Proces powinien sprawdzać również związek odpowiedzi z wejściem. W przeciwnym razie wszystkie pola mogą przejść lokalne kontrole, a dane wylądują przy niewłaściwej sprawie. Przygotuj dwa podobne dokumenty i celowo zamień odpowiedzi w kontrolowanej próbie, bez zapisywania ich do właściwego systemu.

Do zapisu odbioru dodaj wersję instrukcji, schematu i reguł sprawdzających. Gdy rekord zostanie później poprawiony, oznacz, czy zmieniono wejście, interpretację czy tylko sposób zapisu. To pozwala powtórzyć przypadek i sprawdzić przyczynę poprawy. Sama nowa poprawna odpowiedź nie mówi jeszcze, który etap zadziałał inaczej ani czy poprzednia pomyłka nie wróci.

Przetestuj też reakcję na odrzucenie. Czy osoba obsługująca widzi pole, przyczynę i fragment potrzebny do korekty? Czy poprawka zachowuje związek ze źródłem? Ogólny komunikat „błąd danych” przerzuca na człowieka ponowne czytanie całego dokumentu i ukrywa koszt korzystania z automatyzacji.

W kontrolowanej próbie podaj także odpowiedź pustą, przerwaną i zawierającą sam komunikat o braku możliwości wykonania zadania. Sprawdź, czy aplikacja odróżnia te stany od gotowego rekordu i nie uzupełnia wymaganych pól przypadkowymi wartościami. Proces potrzebuje osobnego zakończenia dla niewykonanego zadania, zamiast za wszelką cenę tworzyć obiekt, który da się zaimportować. W raporcie pokaż, co zobaczy osoba oczekująca wyniku i jak może wznowić pracę.

Sprawdź częściowo poprawny rekord. Jeżeli błąd dotyczy jednego pola, ustal, czy reszta może być użyta, czy cały obiekt ma zostać zatrzymany. Odpowiedź zależy od zadania: szkic opisu i automatyczne zamówienie wymagają innego sposobu postępowania. Zapisz decyzję w regułach procesu, aby przypadkowa łatwość technicznego importu nie stała się zasadą biznesową.

Zachowaj trudne przypadki do kolejnego sprawdzenia po zmianie instrukcji, schematu lub sposobu odczytu dokumentu. Wystarczy mały zestaw, jeśli odpowiada rzeczywistym rozróżnieniom: długość i opakowanie, brak i zero, właściwy kod i jego przekonujący sąsiad. Zielony parser pozostaje przydatny. Po prostu nie musi już samotnie udawać całego działu kontroli jakości.