Model obiecał JSON, parser zwrócił null. Pięć przebiegów i trzy przyczyny

👁 149 przeczytań

Prosisz model o JSON, model obiecuje JSON, a `json_decode` zwraca `null`. Trafiłem na to w tym tygodniu przy automacie, który pisze teksty - i przy okazji zrozumiałem, dlaczego cała kategoria nowych narzędzi powstaje właśnie wokół tego problemu. Jak wymusić poprawny JSON schematem, krok po kroku z działającym kodem, pokazuję w tekście Structured output. Innym wyjściem są modele decyzyjne, które zwracają prawdopodobieństwa zamiast tekstu do parsowania.

Co dokładnie się psuje

Mój przypadek: automat prosi o obiekt z czterema polami, gdzie ostatnie zawiera artykuł na 1200 słów w HTML. Model zwracał odpowiedź, która zaczynała się poprawnie - w logu widziałem czysty początek JSON-a z tytułem i opisem. A parser zwracał pustkę.

Przyczyny są trzy i występują razem:

1. Ucięcie na limicie tokenów. Długi artykuł nie mieści się w limicie, odpowiedź kończy się w połowie łańcucha, JSON nie ma domknięcia. Treść jest kompletna, struktura nie.
2. Surowe znaki nowej linii w łańcuchu. W poprawnym JSON-ie muszą być zapisane jako n. Model wstawia prawdziwe.
3. Cudzysłowy w HTML. class="pw-lead" w środku łańcucha zamyka go przedwcześnie, jeśli nie zostanie poprawnie zabezpieczone.

Ślepy zaułek, w który wszedłem

Skoro JSON się łamie, pomyślałem, żeby go porzucić i poprosić o format ze znacznikami: ===TYTUL===, ===HTML=== i tak dalej. Napisałem parser, wdrożyłem, uruchomiłem. Model dalej zwracał JSON.

Powód okazał się banalny i wart zapamiętania: funkcja, przez którą szło zapytanie, wymuszała tryb JSON na poziomie API. Model nie miał wyboru - moja instrukcja o znacznikach była ignorowana, bo format narzucała warstwa niżej. Straciłem na tym trzy przebiegi, zanim sprawdziłem, co robi sama funkcja, zamiast poprawiać prompt.

Wniosek: gdy model uporczywie ignoruje instrukcję formatu, sprawdź najpierw, czy coś w warstwie transportowej nie narzuca mu innego.

Co zadziałało

Parser dwustopniowy. Najpierw zwykły json_decode. Gdy ten padnie - wyciąganie pól znak po znaku, z obsługą sekwencji n, t i uXXXX, kończone na pierwszym niezabezpieczonym cudzysłowie.

Kluczowa właściwość: taki parser odzyskuje treść z odpowiedzi uciętej. Jeśli JSON urwał się po polu z artykułem, wszystkie wcześniejsze pola są kompletne i da się je odczytać. Zwykły dekoder odrzuca całość.

Po tej zmianie ten sam automat przeszedł za pierwszym podejściem i wyprodukował tekst na 1228 słów.

Cztery rzeczy, które robię teraz zawsze

1. Loguję koniec odpowiedzi, nie początek. Początek zawsze wygląda dobrze. Dopiero ostatnie 100 znaków mówi, czy odpowiedź jest ucięta.
2. Długa treść nie jedzie w JSON-ie. Jeśli pole ma mieć więcej niż kilkaset słów, lepiej osobne wywołanie albo format bez ucieczek.
3. Waliduję zawartość, nie tylko format. Że JSON się sparsował, nie znaczy, że treść ma sens - u mnie osobny test sprawdza, czy w tekście są wszystkie liczby, które miały być.
4. Trzy próby, potem wpis do logu. Po trzech nieudanych model nie „naprawi się” za czwartym razem. Lepiej odnotować porażkę niż opublikować śmieć.

Dlaczego powstaje osobna kategoria narzędzi

Ten problem jest na tyle powszechny, że zaczęły powstawać modele, które w ogóle nie generują tekstu. Zamiast prosić model o JSON i go parsować, zadajesz typowane pytanie i dostajesz wartość z rozkładem prawdopodobieństwa - bez etapu tekstowego, więc bez etapu parsowania.

Opisałem jeden taki przypadek osobno: TypeSafe i model Jev, gdzie API ma trzy typy pytań i zwraca decyzje zamiast łańcuchów. To jest opinia, nie rekomendacja - nie testowałem tego jeszcze na własnym zadaniu. Ale kierunek jest logiczny: jeśli wynik ma konsumować kod, etap pośredni w postaci tekstu jest kosztem, nie funkcją.

Kiedy który sposób

Najczęstsze pytania

Dlaczego model zwraca niepoprawny JSON, skoro prosiłem o poprawny?

Bo pod spodem generuje kolejne tokeny, a nie strukturę. Tryb JSON podnosi skuteczność, ale nie daje gwarancji - zwłaszcza gdy odpowiedź zostanie ucięta na limicie.

Czy structured outputs rozwiązują problem?

Bardzo pomagają przy krótkich i średnich odpowiedziach. Przy długiej treści w jednym polu nadal zostaje ryzyko ucięcia.

Jak sprawdzić, czy odpowiedź była ucięta?

Zaloguj jej ostatnie 100 znaków i długość. Ucięta kończy się w środku zdania albo łańcucha, bez domknięcia.

Model ignoruje mój format. Co robić?

Sprawdź, czy warstwa transportowa nie wymusza innego. U mnie funkcja opakowująca narzucała tryb JSON na poziomie API - instrukcja w promptcie nie miała szans.

// czytaj dalejStrona przez chwilę pokazuje się bez stylów. Znalazłem przyczynę w hookach czyszczenia cacheWarsztatGrok 4.7 w Cursorze: jak włączyć i kiedy przełączyć na droższy modelWarsztatJev od TypeSafe: model decyzyjny, wynik w rankingu AA i mój testWarsztat