Tryb JSON nadal zwraca tekst, którego nie da się sparsować

Zwykły tryb JSON obiecuje poprawny składniowo JSON tylko wtedy, gdy model dojdzie do końca. Nie obiecuje twojego schematu i nie może obiecać niczego, jeśli generowanie zatrzyma się wcześniej na max_tokens.

Co widzisz

JSONDecodeError on output that looks almost right
The object is cut off mid-string
Markdown fences around the JSON
Valid JSON that is missing fields your code requires

Dlaczego tak się dzieje

Osiągnięcie limitu wyjścia ucina obiekt w połowie tokenu. Wynik nie daje się sparsować bez żadnej winy promptu – sprawdź finish_reason, zanim zaczniesz sprawdzać parser.

Podstawowy tryb JSON nie ma schematu. Model może zwrócić poprawny JSON z innymi kluczami albo o zagnieżdżonym kształcie, którego się nie spodziewałeś – sparsuje się bez problemu, a i tak zepsuje twój kod.

Niektóre modele opakowują wyjście w bloki kodu markdown, gdy prompt zawiera tak sformatowane przykłady. Treść jest w porządku; zawodzi opakowanie.

Jak to naprawić

Sprawdź finish_reason przed parsowaniemfinish_reason równe length oznacza ucięcie. Podnieś max_tokens albo poproś o mniejszy obiekt, zamiast debugować parser.
Używaj wyjścia ze schematem, jeśli model je obsługujeTo przekazanie schematu JSON, a nie prośba o JSON w treści promptu, naprawdę ogranicza klucze. I tak waliduj wynik.
Usuwaj obramowania profilaktycznieTrzylinijkowe wstępne przetwarzanie, które usuwa początkowe i końcowe znaczniki bloku kodu, nic nie kosztuje i eliminuje całą klasę błędów.

Ucięte wyjście to nadal wygenerowane wyjście, więc w APICLAN nadal jest naliczane. Czytanie finish_reason i właściwe ustawienie max_tokens oszczędza ponowienie, a to jest prawdziwy koszt.

Powiązane

Unexpected token '<' przy wywołaniu API zgodnego z OpenAI 401 invalid API key – gdy klucz wygląda dobrze, a i tak nie działa

Ostatnio sprawdzono 2026-10-01. Napisane na podstawie problemów zdiagnozowanych na działającej bramce zgodnej z OpenAI, a nie zebrane z innych stron.