Miért kell a strukturált kimenet
Amint a modell kimenete nem egy embernek szól, hanem egy másik programnak, a folyó szöveg akadállyá válik. Ha a válaszból egy adatbázisba írandó rekordot, egy űrlap mezőit vagy egy következő lépés paramétereit kell kinyerni, akkor a kimenetnek kiszámítható, elemezhető szerkezetűnek kell lennie, tipikusan JSON formátumúnak. A naiv megoldás, hogy a promptban megkérjük a modellt, adjon JSON-t, önmagában megbízhatatlan. A modell időnként magyarázó mondatot fűz elé, elrontja a zárójelezést, kihagy egy kötelező mezőt vagy a felsorolt értékek helyett mást ír. Egy éles rendszerben az ilyen ritka, de kiszámíthatatlan hiba a legdrágább, mert a hívó kód elszáll rajta. Ezért a strukturált kimenet nem kényelmi funkció, hanem a modell és a determinista kód közötti stabil szerződés, amit garantálni kell, nem remélni.
JSON mód és sémakényszerített kimenet
Két, gyakran összekevert dolgot érdemes szétválasztani. A JSON mód (JSON mode) annyit garantál, hogy a kimenet szintaktikailag érvényes JSON lesz. Ez megvéd a magyarázó mondattól és a hibás zárójelezéstől, de nem garantálja, hogy a JSON a te szerkezetedet követi. Attól még hiányozhat egy kötelező mező vagy megjelenhet egy nem várt kulcs. A sémakényszerített kimenet (structured outputs) ennél többet ad. Itt egy előre megadott JSON séma minden elemének betartására kötelezed a modellt, tehát a kötelező mezők mindig jelen lesznek, a felsorolt értékek közül csak érvényes választhat, és a típusok illeszkednek. A gyakorlati szabály egyszerű. Ha csak érvényes JSON-ra van szükséged, a JSON mód elég, de ha a hívó kód a mezők pontos meglétére és típusára támaszkodik, sémakényszert használj, mert az emeli a formát puszta reményből garanciává.
JSON mód
- Garantál érvényes JSON szintaxist
- Nem garantálja a te sémádat
- Hiányozhat mező vagy jöhet felesleges kulcs
- A hívó kódnak még védekeznie kell
Sémakényszerített kimenet
- A megadott séma minden elemét betartja
- Kötelező mezők mindig jelen vannak
- Csak érvényes felsorolt érték jöhet
- Stabil szerződés a hívó kód felé
A kényszerített dekódolás mechanikája
A sémakényszert nem utólagos ellenőrzés adja, hanem a kényszerített dekódolás (constrained decoding). A modell minden lépésben valószínűségeket rendel a lehetséges következő tokenekhez. A kényszerített dekódolás ezt a lépést szűri. A séma alapján előáll egy szabály arról, hogy az adott ponton mely tokenek megengedettek, és a rendszer az összes szabálytalan tokent kizárja, mielőtt a modell választana. Így a modell fizikailag nem tud a sémán kívülre lépni, mert a hibás folytatás valószínűsége nullára van maszkolva. Ez az oka annak, hogy a garancia erős, nem csak statisztikai. Van egy gyakorlati mellékhatása is. Egy új, korábban nem látott séma első feldolgozása többletidőt vehet igénybe, mert a rendszernek a sémából le kell fordítania a token szintű szabályt, a további kérések viszont ezt már nem fizetik meg. Ezt a késleltetést érdemes a tervezésnél számításba venni.
Függvényhívás, ugyanaz a séma más célra
A séma másik nagy felhasználása a függvényhívás vagy eszközhívás (function calling, tool calling), amit az ötödik leckében az ügynököknél már érintettünk. A kettő rokon, de a céljuk más. A sémakényszerített válasz akkor kell, amikor magát a felhasználónak szánt kimenetet strukturálod, például egy űrlap adatait vagy egy kinyert rekordot. A függvényhívásnál a modell nem a végfelhasználónak válaszol, hanem eldönti, hogy meghív egy általad megadott függvényt, és annak paramétereit állítja elő a függvény sémája szerint. A közös elem a séma, tehát a paraméterek szerkezete és típusa itt is kényszeríthető, így a hívott függvény mindig jól formált argumentumokat kap. Éppen ezért a strukturált kimenet és az eszközhasználat ugyanannak az elvnek a két oldala. Mindkettőben a modell szabad szövegét egy szigorú, gép által ellenőrizhető szerződéssé fordítjuk.
A formai helyesség nem elég
Itt következik a lecke legfontosabb különbségtétele. A séma betartása szintaktikai és szerkezeti garancia, nem tartalmi. A modell adhat tökéletesen sémahelyes választ, amelyben az érték mégis rossz, például kitalált azonosítót, tartományon kívüli számot vagy egy tényben téves mezőt tesz a helyes formába. A megbízhatóság ezért két rétegű. Az első réteg a séma, ami a formát biztosítja. A második réteg a tartalmi validáció, amit már a te kódod végez. Ez ellenőrzi az üzleti szabályokat, hogy a szám a megengedett tartományba esik, a hivatkozott azonosító létezik, a dátum értelmes, a mezők egymással konzisztensek. Ez a validáció a determinista kód felelőssége, és semmilyen modellbeállítás nem váltja ki, mert a modell a saját kimenetét nem tudja függetlenül ellenőrizni. A sémahelyes, de tartalmilag hibás válasz a legalattomosabb hibafajta, mert a formai ellenőrzésen simán átcsúszik.
- SémakényszerA modell csak a megadott szerkezetű, jól formált kimenetet adhatja.
- Szintaktikai ellenőrzésA kód biztosra megy, hogy a válasz elemezhető és a séma teljesül.
- Tartalmi validációÜzleti szabályok, tartományok, létező azonosítók, mezők közti konzisztencia.
- Javító hurokHiba esetén a modellt a konkrét hibaüzenettel újrapróbáltatod, korlátozott alkalommal.
- Tartalék útvonalHa a javítás sem sikerül, biztonságos alapérték vagy emberi felülvizsgálat lép be.
Hibakezelés, javító hurok és guardrailek
Mivel a rendszer nem determinista, a hibakezelést a normál működés részének kell tekinteni, nem kivételnek. Három esetre mindig fel kell készülni. Az első, amikor a modell biztonsági okból megtagadja a választ, ezt programozottan felismerhető módon jelzi, és a kódnak külön kell kezelnie, nem félresikerült JSON-ként. A második, amikor a válasz a tokenhatár elérése miatt csonkán ér véget, ilyenkor a részleges kimenetet nem szabad késznek venni. A harmadik, amikor a tartalmi validáció bukik el. Erre a bevált minta a javító hurok (retry vagy repair loop), amelyben a modellt visszaküldöd a saját hibás kimenetével és a konkrét hibaüzenettel, hogy javítsa. Ezt korlátozott, előre rögzített alkalommal engeded, mert végtelen ismétlés nem lehet. Mindezt egy guardrail réteg fogja keretbe, amely a bemeneten és a kimeneten is ellenőrzéseket futtat, kiszűri a nem megengedett tartalmat, és biztosítja, hogy ha minden más elbukik, a rendszer akkor is egy biztonságos alapértékkel vagy emberi felülvizsgálattal zárjon, ne kiszámíthatatlanul.
Két külön garancia, két külön helyen. A séma a modellnél garantálja a formát, az üzleti validáció a te kódodban garantálja a tartalmat. A sémahelyes, de tartalmilag rossz válasz azért veszélyes, mert a formai ellenőrzésen átjut. Ezért soha ne bízd a helyességet egyetlen rétegre, és a hibakezelést tekintsd a rendszer normál viselkedésének, ne kivételnek.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →