Rozumowanie kierowane schematem a ustrukturyzowane dane wyjściowe dla LLMs
Tłumaczenie automatyczne
Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.
Używaj ustrukturyzowanych danych wyjściowych, gdy program potrzebuje pól o określonej strukturze. Dodaj rozumowanie kierowane schematem (SGR), gdy program lub osoba dokonująca przeglądu potrzebuje również rekordów pośrednich, takich jak dowody ze źródeł i proponowana decyzja. SGR używa ustrukturyzowanych danych wyjściowych do przedstawienia tych kroków; nie jest dodatkową gwarancją poprawności odpowiedzi.
Jeśli odbiorca potrzebuje wyłącznie kategorii i identyfikatora źródła, pozostaw tylko te pola. Dodawaj pola analityczne wyłącznie wtedy, gdy potrafisz wyjaśnić, jak będą sprawdzane lub wykorzystywane.
Ostatni przegląd: 2026-09-08.
Rola poszczególnych warstw
| Warstwa | Co zapewnia | Czego nie może ustalić |
|---|---|---|
| Prompt określający format JSON | Instrukcje zwracania JSON | Że odpowiedź jest zgodna ze schematem |
| Dane wyjściowe ograniczone schematem | Odpowiedź zgodną z obsługiwanym schematem, gdy generowanie zakończy się pomyślnie | Że wartości są prawdziwe |
| Schemat SGR | Nazwane pola pośrednie i proponowaną decyzję | Że jedno pole zostało poprawnie wyprowadzone z innego |
| Kontrole aplikacji | Testy dowodów ze źródeł, obliczeń i dozwolonych działań | Faktów, których aplikacja nigdy nie weryfikuje |
Opis SGR autorstwa Rinata Abdullina wykorzystuje schematy jako listę kontrolną pracy zwracanej przez model. W środowisku utrzymywanym we własnej infrastrukturze ustrukturyzowane dane wyjściowe vLLM mogą wymuszać JSON Schema za pomocą backendu dekodowania, takiego jak XGrammar. Samo zdefiniowanie modelu Pydantic w Pythonie nie włącza constrained decoding na serwerze.
Sprawdź, jaki podzbiór schematu obsługuje wybrany dostawca i jaki jest status zakończenia generowania. Odmowa, obcięta odpowiedź lub nieudane żądanie wymagają osobnej ścieżki obsługi błędów. Przewodnik Gemini po ustrukturyzowanych danych wyjściowych również wskazuje kluczowe ograniczenie: poprawna struktura JSON nie gwarantuje poprawności wartości pól.
Propozycja rabatu pokazuje różnicę
Załóżmy, że narzędzie wsparcia może zaoferować rabat w wysokości najwyżej 10%. Minimalna ustrukturyzowana odpowiedź mogłaby zawierać discount_percent i customer_message. Jeśli osoba prowadząca wewnętrzny przegląd potrzebuje dowodów, odpowiedź SGR mogłaby dodatkowo zawierać policy_source_id i eligibility_evidence.
Te dodatkowe pola dają osobie prowadzącej przegląd materiał do sprawdzenia. Nie sprawiają jednak, że proponowany rabat w wysokości 15% staje się prawidłowy. Nawet schemat ograniczający procent do 10 nie może dowieść, że dany klient spełnia warunki.
Przed użyciem oferty kod aplikacji musi załadować obowiązującą politykę i rekord klienta, sprawdzić, czy klient spełnia warunki, oraz obliczyć dozwoloną kwotę. Wyjaśnienie modelu traktuj jako twierdzenie wymagające weryfikacji. Jeśli kolejny krok modelu potrzebuje zatwierdzonych faktów, zweryfikuj je przed wykonaniem tego wywołania. Kolejność pól w jednym obiekcie JSON nie tworzy etapu walidacji.
Kiedy pola pośrednie pomagają
SGR jest przydatne, gdy błędna odpowiedź wymaga dokładniejszej diagnozy. Na przykład klasyfikator dokumentów może zwrócić fragment źródłowy i kategorię. Osoby prowadzące przegląd mogą wtedy rozróżnić zły wybór fragmentu od błędnej kategorii przy poprawnych dowodach.
Jest mniej przydatne, gdy każdy wynik zyskuje długie wyjaśnienie, którego nikt nie czyta ani nie ocenia. Dodatkowe dane wyjściowe zużywają tokeny, a przekonujące wyjaśnienie nadal może być fałszywe.
Porównaj mały schemat ze schematem SGR na tych samych przypadkach z przypisanymi etykietami i dla tego samego modelu. Oceniaj decyzję końcową oddzielnie od potwierdzenia w źródłach i poprawności pól. Zachowaj pola pośrednie, jeśli poprawiają decyzję lub sprawiają, że przegląd jest na tyle użyteczny, by uzasadnić dodatkowe dane wyjściowe. Nie zakładaj wzrostu trafności na podstawie samej nazwy schematu.
Dalsza lektura
- Rozumowanie kierowane schematem z vLLM wyjaśnia schematy, XGrammar i kontrole polityki po stronie aplikacji.
- Pamięć agenta kierowana schematem wykorzystuje typowane rekordy i historię źródeł w stanie trwałym.
- Wybór modeli NER rozdziela dosłowne fragmenty tekstu od ekstrakcji wymagającej inferencji.