Dlaczego małe modele lokalne częściej halucynują podczas generowania danych JSON?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Do Small Local Models Hallucinate More During JSON Output? - Zima Store Online

Małe modele lokalne częściej halucynują podczas generowania JSON, ponieważ muszą jednocześnie rozwiązać zadanie, zachować sztywny schemat i utrzymać poprawną składnię.

Lokalny proces AI może wymagać od kompaktowego modelu wyodrębnienia nazw plików, dat, tagów, stanów urządzeń lub argumentów automatyzacji i zwrócenia ich w postaci przeznaczonego dla maszyn formatu JSON. Model nie wykonuje jednego zadania. Musi zidentyfikować właściwe fakty, przypisać je do odpowiednich pól, respektować wymagane typy i wartości wyliczeniowe, pamiętać o interpunkcji i zagnieżdżeniu oraz zakończyć odpowiedź bez dodawania komentarza. Gdy możliwości modelu są ograniczone, te wymagania konkurują z rozumowaniem potrzebnym do zachowania zgodności wartości ze źródłem.

JSON sprawia, że poprawność staje się problemem dwuwarstwowym

Odpowiedź musi być jednocześnie poprawna semantycznie i prawidłowa strukturalnie. Odpowiedź w formie swobodnego tekstu może wyrażać niepewność lub wyjaśniać brak wartości, podczas gdy kontrakt JSON często wymaga od modelu wybrania wartości pola nawet wtedy, gdy dowody są słabe.

Badania dotyczące kompromisu między poprawnością a trafnością pokazują, dlaczego te pomiary należy rozdzielać: silniejsze ograniczenia wyjścia mogą zwiększać poprawność względem schematu, podczas gdy wybrane wartości stają się mniej trafne.

W przypadku małego modelu lokalnego presja ta jest bardziej widoczna, ponieważ ma on mniej wolnych zasobów na śledzenie instrukcji, ekstrakcję i serializację. Większy model również może wymyślić wartość pola, ale kompaktowy model szybciej osiąga punkt, w którym zgodność z formatem wypiera jakość odpowiedzi.

Poprawny obiekt może nadal zawierać zhalucynowaną odpowiedź

Dekodowanie z ograniczeniami może uniemożliwić wygenerowanie nieprawidłowego nawiasu klamrowego, nieznanego klucza lub niedozwolonej wartości wyliczeniowej. Nie może jednak dowieść, że wybrany identyfikator klienta, data, ścieżka lub status występuje w materiale źródłowym.

vLLM opisuje ograniczenia schematu JSON jako sposób ograniczania formy generowanych danych wyjściowych. Dekoder zawęża zbiór dozwolonych kolejnych tokenów, ale znaczenie tych tokenów nadal dostarcza model.

Tworzy to niebezpieczny tryb awarii w automatyzacji: obiekt zostaje poprawnie sparsowany, więc kod działający dalej mu ufa, mimo że jedno z pól jest zmyślone. Po walidacji schematu sprawdzaj reguły biznesowe i dowody w źródle, zamiast uznawać poprawne sparsowanie za potwierdzenie poprawności faktów.

Zagnieżdżone schematy zwiększają liczbę rozgałęzień i obciążenie śledzenia stanu

Każda wymagana właściwość, opcjonalna gałąź, zagnieżdżona tablica, pole dopuszczające wartość null i wartość wyliczeniowa dodają stan, który model musi śledzić podczas generowania. Podobne nazwy kluczy lub powtarzające się struktury obiektów ułatwiają umieszczenie prawidłowej wartości w niewłaściwym miejscu.

Przewodnik llama.cpp dotyczący JSON z ograniczeniami gramatycznymi rozróżnia dozwoloną gramatykę danych wyjściowych od promptu wyjaśniającego znaczenie pól. Gramatyka może wymuszać strukturę, ale schemat nadal wymaga jasnych instrukcji semantycznych.

Ogranicz liczbę jednoczesnych decyzji. Spłaszczaj głęboko zagnieżdżone obiekty, usuwaj nieużywane pola opcjonalne, stosuj różniące się nazwy kluczy i dziel dużą ekstrakcję na mniejsze obiekty, jeśli lokalny model wielokrotnie zamienia pola miejscami lub wypełnia pola niezwiązanymi wartościami.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Prompty wymagające wyłącznie JSON mogą tłumić użyteczne rozumowanie

Ścisła instrukcja „zwróć wyłącznie JSON” skłania model do natychmiastowego zapakowania odpowiedzi. W przypadku trudnej ekstrakcji może to spowodować przedwczesny wybór wartości pola, zanim model porówna konkurencyjne fragmenty lub rozstrzygnie niejednoznaczną datę.

Ewaluacje Hugging Face pokazują wrażliwość na format promptu: zmiana oczekiwanej struktury i dostępnego miejsca na rozumowanie może zmienić wyniki zadania, nawet gdy samo pytanie pozostaje takie samo.

Nie ujawniaj prywatnego toku rozumowania, ale oddziel wewnętrzne rozwiązywanie zadania od końcowej serializacji. Proces może najpierw wyodrębnić zwięzły rekord dowodowy lub wykonać deterministyczne wyszukiwanie, a następnie poprosić model wyłącznie o wyrenderowanie zweryfikowanych pól.

JSON generowany na podstawie promptu i dekodowanie z ograniczeniami zawodzą w różny sposób

JSON generowany wyłącznie na podstawie promptu może zawierać bloki kodu, komentarze, zduplikowane klucze, końcowe przecinki lub niedokończony obiekt. Dekodowanie z ograniczeniami eliminuje wiele błędów składni, ale może zmusić model do wyboru jednej z poprawnych wartości, gdy wartość „nieznana” nie była dozwolona.

Fireworks wyjaśnia, jak wybór tokenów ograniczony schematem utrzymuje generowanie w ramach kontraktu danych wyjściowych, jednocześnie nadal wymagając od promptu dokładnego opisu zamierzonych danych.

Śledź oba rodzaje awarii. Mierz błędy parsowania dla danych generowanych wyłącznie na podstawie promptu, a następnie po włączeniu dekodowania z ograniczeniami mierz niepoprawne, lecz prawidłowe względem schematu pola, niepożądane wartości domyślne i fałszywą pewność.

Próbkowanie i obcinanie wzmacniają małe błędy

Wyższa temperatura może zmieniać wybór kluczy i wartości pól, a niewystarczający budżet tokenów może uciąć tablice lub zamykające nawiasy klamrowe. Niższa temperatura zmniejsza zmienność, ale nie sprawia, że wartość bez potwierdzenia staje się prawdziwa.

Praktyczny przegląd lokalnego procesu ustrukturyzowanych danych wyjściowych pokazuje, dlaczego walidacja i generowanie z ograniczeniami są odrębnymi komponentami, a nie jednym sposobem opartym na promptach.

Zarezerwuj wystarczającą liczbę tokenów wyjściowych dla największego dozwolonego obiektu, ogranicz długość tablicy i ponawiaj próbę tylko dla nieudanego fragmentu. Ponowne generowanie całego obiektu może zastąpić pola, które były już poprawne, nowymi halucynacjami.

Używaj lokalnego, dwuetapowego procesu JSON

Najpierw rozwiąż zadanie do postaci minimalnego rekordu typowanego: dokładnego fragmentu źródłowego, znormalizowanej daty, wybranego identyfikatora, stanu pewności i każdej jawnie wskazanej brakującej wartości. Ten etap powinien móc odrzucić żądanie zamiast wymyślać wymagane dane.

Następnie wyrenderuj ten rekord za pomocą dekodera ograniczonego schematem, sparsuj go i przeprowadź kontrole semantyczne, takie jak istnienie pliku, zakres daty, zgodność wartości wyliczeniowej i spójność między polami. Walidator powinien zwracać precyzyjne błędy wskazujące pole wymagające poprawy.

Wyjaśnienie ZimaSpace dotyczące tego, dlaczego mniejszy model może być bardziej niezawodny, wyznacza właściwą granicę: kompaktowe modele działają najlepiej, gdy zadanie, kontekst, zestaw narzędzi i kontrakt danych wyjściowych są wystarczająco wąskie, aby można je było zweryfikować.

FAQ

Czy poprawny JSON oznacza, że model nie halucynował?

Nie. Poprawny JSON potwierdza, że obiekt jest zgodny z zasadami składni lub schematu. Nie dowodzi, że wartości pól pochodzą ze źródła ani że odpowiadają rzeczywistemu stanowi systemu.

Czy ustawienie temperatury na zero rozwiąże halucynacje w JSON?

Nie. Może sprawić, że dane wyjściowe będą bardziej powtarzalne, ale konsekwentnie wybierana wartość bez potwierdzenia nadal jest halucynacją.

Czy dekodowanie z ograniczeniami wystarczy do automatyzacji?

Nie. Używaj go wraz z ekstrakcją opartą na źródle, parsowaniem schematu, walidacją semantyczną i bezpieczną ścieżką odrzucenia dla brakujących lub niejednoznacznych danych.