Strukturált kimenetek: megbízható JSON kinyerése a nyelvi modellből

Minden LLM-integráció első verziója a prózát elemzi. Kéred a "három fő kockázatot, soronként egyet", újsorokra osztva, és addig működik, amíg a modell először meg nem ír egy bevezető mondatot. Strukturált kimenetek léteznek, hogy befejezzék ezt a hurkot: átad a modellnek egy JSON-sémát, a dekóder korlátozva van, így nem tud kibocsátani semmit, ami sérti azt, és visszakapod a hasznos terhet a kért mezőkkel. Ez a garancia valódi, de szűkebb, mint amilyennek hangzik, és a különbség az, hogy hol élnek a hibák.

Mit takar valójában a garancia

Korlátozott dekódolási garanciák alak. A válasz JSON-ként lesz értelmezve, benne lesznek a kulcsai, a típusok egyeznek, és az enum mezők tartalmazzák a felsorolt értékek egyikét. Ez nagy előrelépés a gyors és reménykedéshez képest.

Semmit sem garantál kb tartalom. A karakterláncként beírt mező tartalmazni fog egy karakterláncot; Az, hogy ez a karakterlánc pontos-e, vagy a séma kielégítésére lett kitalálva, változatlan a korábbihoz képest. Valójában egy szigorú séma valamivel valószínűbbé teszi a találmányt, mivel egy kötelező mezőt ki kell tölteni valamivel, és a modell nem mondhatja, hogy "nincs jelen a forrásban". Ez az egyetlen leggyakoribb hiba a gyártásban: kötelező invoice_number olyan dokumentumban, amelyben nincs.

Tervezz körülötte. Engedélyezze a nullát, ahol lehetséges a távollét, adjon hozzá egy explicit found: boolean vagy a "unknown" enum tag, és soha ne tegyen kötelezővé egy mezőt, hacsak a válasz valóban nem szerepel minden bemenetben.

Egy modell által kitölthető séma tervezése

Az érvényesítésre írt sémák és a generálásra írt sémák eltérően néznek ki. Néhány szolgáltatóra érvényes szabály:

• Lapos ütemek fészkeltek. A beágyazás minden szintje egy olyan hely, ahol a modell elveszíti a nyomát. Három hívás során kinyert három sekély objektum ver egy mélyen beágyazott fát.
• Az enumok szabad húrokat vernek. Ha egy mezőnek öt legitim értéke van, sorolja fel őket. Eltávolít egy egész normalizációs kód osztályt, és a korlátozott dekódoló kényszeríti azt Ön helyett.
• A mezőnevek utasítások. due_date_iso8601 jobb teljesítményt produkál, mint date a formátumot külön promptban ismertetjük. A nevek a szövegkörnyezetben vannak; használja őket.
• Használat description mezőkön. A legtöbb szolgáltató sémaleírásokat ad át a modellnek. Kétértelmű mezőnként egy záradék olcsóbb és megbízhatóbb, mint a fenti prózai utasítások egy bekezdése.
• Készlet additionalProperties: false. Számos szolgáltató egyébként is megköveteli a szigorú módhoz, és megakadályozza, hogy a modell segítőkészen találjon ki egy extra kulcsot, amelyet az elemző csendben figyelmen kívül hagy.
• A lapos objektumok tömbjeit részesítse előnyben a térképekkel szemben. A dinamikus kulcsokat – olyan objektumokat, amelyek tulajdonságainak neve előre ismeretlen – a szigorú módok gyengén támogatják, és kényelmetlen a fogadó oldalon begépelni.

A szolgáltatók azt is korlátozzák, hogy szigorú módban mely JSON-séma kulcsszavakat támogatják: oneOf, a minta megszorításait, a numerikus korlátokat és a rekurziót általában korlátozzák vagy figyelmen kívül hagyják. Tegyük fel, hogy a séma csak a struktúrát korlátozza, és az elemzést követően saját maga érvényesítse üzleti szabályait.

Mindenképpen érvényesítsd

Még szigorú mód esetén is érvényesítsen minden választ, mielőtt az adatbázist érintene. A szigorú módot letilthatja a konfiguráció módosítása, a tartalék elérési út elérheti azt a modellt, amely nem támogatja azt, a hálózati újrapróbálkozás hibaobjektumot ad vissza, és a választ egy token limit mid-object csonkolhatja – ami érvénytelen JSON-t állít elő, a sémamód nem akadályozza meg.

Ha egy rakomány meghibásodik, a hasznos kérdés az, hogy melyik mező és miért. A JSON-séma érvényesítő veszi a dokumentumot és a sémát, és problémánként egy sort jelent a JSON-mutató elérési útjával, a sikertelen kulcsszóval és a ténylegesen talált értékkel. Pontosan ez az az űrlap, amelyet két célból szeretne: a séma javítása a fejlesztés során, és az újrapróbálkozáshoz való visszacsatolás – a sikertelen érvényesítési jelentés egy nyomon követési üzenetbe illesztve rendkívül hatékony javítási felszólítás, mivel a modell pontosan látja, hogy mi hibázott.

Korlátozza az újrapróbálkozásokat egy vagy kettőre. Egy sémát kétszer meghibásodó modellt általában olyasmire kérdeznek, amit a bemenet nem tartalmaz, és a harmadik kísérlet kitalálja.

A hasznos adatmintától a kódig

A legtöbb séma a csevegésbe beillesztett mintaválaszként indul. Ennek kézzel történő begépelt, hitelesített kódká alakítása fárasztó és hibás, ezért ne tegye.

Illessze be a mintát JSON–Zod séma és kapsz egy Zod sémát plusz a kikövetkeztetett TypeScript típust. Mezőnként következtet ahelyett, hogy mindent karakterláncként írna be: az e-maileknek, URL-eknek, UUID-knek vagy ISO-dátumoknak tűnő értékeket kapja .email(), .url(), .uuid() és .datetime() csupasz helyett z.string(), a tömbök hordozzák elemtípusukat, és egy mező, amelynek típusa előfordulásonként változik, unióvá válik, ahelyett, hogy csendben választaná ki az elsőt, amelyet látott. Ez utóbbi viselkedést érdemes tudatosan betáplálni: három vagy négy valódi választ illesszen be összefűzve, ne egyet, így az opcionális és polimorf mezők uniókként jelennek meg, ahelyett, hogy az első minta véletlenül tartalmazott tartalmához zárnák őket.

Ha csak típusokra van szüksége, és nem futásidejű érvényesítésre – mert a hasznos adat olyan forrásból származik, amelyben már megbízik – JSON-ból TypeScriptre közvetlenül hozza létre az interfészeket, a beágyazott objektumokat névtelen blobok helyett elnevezett alinterfészekként tagolja.

Tartsa egyenesen az igazság irányát: egy sémadefiníció, abból generálva minden mást. A külön karbantartott Zod-séma és a JSON-séma egy hónapon belül nézeteltérésbe kerül, és a nézeteltérés termelési elemzési hibaként jelenik meg, nem pedig teszthibaként.

Olvasni, mi jött vissza

A modellválaszok egy sorban kicsinyítve érkeznek, ami nyomorúságossá teszi a szemrevételezést. A JSON formázó behúzza, és valami olvashatóba rendezi őket, az érvényesítés pedig azonnal felfogja a csonkítási esetet – a karakterlánc közepén végződő hasznos adat a találati token limit aláírása, a javítás pedig magasabb kimeneti korlát vagy kisebb séma, nem pedig azonnali változtatás.

Ha összehasonlítja, hogy melyik két modellt állítottak elő ugyanabból a bemenetből, vagy azt ellenőrizzük, hogy egy azonnali változtatás nem változtatta-e meg a kimenetet olyan módon, ahogyan Ön nem akarta, akkor a formázott hasznos terhelések különbségét ahelyett, hogy mindkettőt elolvasná. A JSON falában láthatatlan szerkezeti különbségek – egy olyan mező, amely csendesen számok helyett számsorrá vált – azonnal kitűnnek a különbségben.

Verziószámítás

A sémák változnak, és velük együtt a modell kimenete is. Tegyen egy verziómezőt a hasznos adatba az első naptól kezdve, így a tárolt rekordok azt az alakot hordozzák, amely alá írták őket. Az utólagos illesztés, hogy egy millió sor címkézetlen JSON után az a fajta migráció, amelyre senki sem ütemez időt.

Mindezek az eszközök helyileg futnak a böngészőben, ami ennél a munkafolyamatnál a szokásosnál is fontosabb: a sémákká alakított mintaadatok általában valós API-válaszok, valódi ügyféladatokkal, és nem szabad őket feltölteni formázási szolgáltatásba, hogy szépítsék őket.