Strukturirani izhodi: pridobivanje zanesljivega JSON iz jezikovnega modela

Prva različica vsake LLM integracije analizira prozo. Zahtevate "tri glavna tveganja, eno na vrstico", razdeljeno na nove vrstice, in deluje do dneva, ko model najprej napiše uvodni stavek. Obstajajo strukturirani izhodi, ki končajo to zanko: modelu predate shemo JSON, dekoder je omejen, tako da ne more oddati ničesar, kar bi ga kršilo, in nazaj dobite koristni tovor s polji, ki ste jih zahtevali. Ta garancija je resnična, vendar manjša, kot se sliši, in razlika je v tem, kje hrošči živijo.

Kaj garancija dejansko pokriva

Zagotovljeno omejeno dekodiranje oblika. Odgovor bo razčlenjen kot JSON, imel bo vaše ključe, tipi se bodo ujemali, polja enum pa bodo vsebovala eno od vaših navedenih vrednosti. To je velik napredek v primerjavi s prompt-and-hope.

Ne zagotavlja ničesar o vsebino. Polje, vneseno kot niz, bo vsebovalo niz; ali je ta niz točen ali izumljen, da zadosti shemi, je nespremenjeno od prej. Pravzaprav je zaradi stroge sheme izum malo bolj verjeten, ker je treba zahtevano polje z nečim izpolniti, model pa ne more reči, da "ni prisoten v viru". To je najpogostejša napaka v proizvodnji: zahtevana invoice_number v dokumentu, ki ga nima.

Oblikovanje okoli tega. Dovolite ničelno vrednost, kjer je možna odsotnost, dodajte eksplicitno found: boolean ali a "unknown" enum in nikoli ne naredite polja za obvezno, razen če odgovor resnično obstaja v vsakem vnosu.

Oblikovanje sheme, ki jo lahko zapolni model

Sheme, napisane za validacijo, in sheme, napisane za generiranje, so videti drugače. Nekaj pravil, ki veljajo za vse ponudnike:

• Ravni udarci vgnezdeni. Vsaka raven gnezdenja je kraj, kjer se model izgubi. Trije plitki predmeti, izvlečeni v treh klicih, premagajo eno globoko ugnezdeno drevo.
• Enumi premagajo proste nize. Če ima polje pet zakonitih vrednosti, jih navedite. Odstranite celoten razred normalizacijske kode in omejeni dekoder jo uveljavi namesto vas.
• Imena polj so navodila. due_date_iso8601 proizvede boljši rezultat kot date z obliko, ki je razložena v ločenem pozivu. Imena so v kontekstu; jih uporabite.
• Uporaba description na poljih. Večina ponudnikov modelu posreduje opise shem. Ena klavzula na dvoumno polje je cenejša in bolj zanesljiva kot zgornji odstavek proznih navodil.
• Set additionalProperties: false. Več ponudnikov ga tako ali tako zahteva za strogi način in prepreči modelu, da bi si uslužno izmislil dodaten ključ, ki ga vaš razčlenjevalnik tiho ignorira.
• Dajte prednost nizom ravnih predmetov kot zemljevidom. Dinamični ključi – objekt, katerega imena lastnosti so vnaprej neznana – so slabo podprti s strogimi načini in jih je na prejemnem koncu nerodno tipkati.

Ponudniki tudi omejujejo, katere ključne besede sheme JSON podpirajo v strogem načinu: oneOf, so omejitve vzorcev, številske meje in rekurzija običajno omejene ali prezrte. Predpostavimo, da shema omejuje samo strukturo in po razčlenjevanju sami uveljavite svoja poslovna pravila.

Vseeno potrdi

Tudi s strogim načinom preverite vsak odgovor, preden se dotakne vaše zbirke podatkov. Strogi način je lahko onemogočen s spremembo konfiguracije, nadomestna pot lahko zadene model, ki je ne podpira, ponovni poskus omrežja lahko vrne objekt napake, odgovor pa je lahko okrnjen z omejitvijo žetona sredi objekta – kar ustvari neveljaven JSON, ki ga noben način sheme ne prepreči.

Ko koristni tovor ne uspe, je koristno vprašanje, katero polje in zakaj. The Validator sheme JSON vzame dokument in shemo ter poroča o eni vrstici na težavo, s potjo kazalca JSON, ključno besedo, ki ni uspela, in dejansko najdeno vrednostjo. To je natanko oblika, ki jo želite za dva namena: popravljanje vaše sheme med razvojem in vrnitev v ponovni poskus – poročilo o neuspešni potrditvi, prilepljeno v nadaljnje sporočilo, je izjemno učinkovit poziv za popravilo, saj lahko model natančno vidi, kaj je naredil narobe.

Omejite število ponovnih poskusov na enega ali dva. Model, ki dvakrat ne uspe s shemo, se običajno zahteva nekaj, kar vnos ne vsebuje, tretji poskus pa bo to izumil.

Od vzorčnega tovora do kode

Večina shem se začne kot vzorec odgovora, ki ga je nekdo prilepil v klepet. Ročno spreminjanje tega v tipkano potrjeno kodo je dolgočasno in nagnjeno k napakam, zato tega ne storite.

Prilepite vzorec v Shema JSON v Zod in dobite shemo Zod plus izpeljano vrsto TypeScript. Sklepa na polje, namesto da vse vnese kot niz: dobijo se vrednosti, ki so videti kot e-poštna sporočila, URL-ji, UUID-ji ali datumi ISO .email(), .url(), .uuid() in .datetime() namesto golega z.string(), matrike nosijo svoj tip elementa in polje, katerega tip se spreminja med pojavitvami, postane unija, namesto da tiho izbere prvo, ki ga vidi. To zadnje vedenje je vredno namenoma hraniti: prilepite tri ali štiri prave odgovore povezane, ne enega, tako da se neobvezna in polimorfna polja prikažejo kot unije, namesto da bi bila zaklenjena na tisto, kar je vseboval prvi vzorec.

Če potrebujete samo tipe in ne preverjanja med izvajanjem – ker koristni tovor prihaja iz vira, ki mu že zaupate – JSON v TypeScript izdela vmesnike neposredno, z ugnezdenimi objekti, razdeljenimi kot poimenovani podvmesniki, namesto vstavljenih anonimnih blobov.

Držite smer resnice naravnost: ena definicija sheme, z vsem ostalim, ki je ustvarjeno iz nje. Shema Zod in shema JSON, ki se vzdržujeta ločeno, se ne bosta ujemali v enem mesecu, nesoglasje pa bo prikazano kot napaka pri razčlenjevanju proizvodnje in ne kot napaka pri preizkusu.

Branje, kar se je vrnilo

Odgovori modela pridejo pomanjšani v eni vrstici, zaradi česar jih je težko opazovati. The Oblikovalnik JSON zamika in jih razvrsti v nekaj berljivega, njegova validacija pa takoj zajame prirezovanje – koristni tovor, ki se konča na sredini niza, je podpis omejitve žetona zadetka, popravek pa je višja izhodna omejitev ali manjša shema, ne takojšnja sprememba.

Ko primerjate, kaj sta dva modela ustvarila iz istega vnosa, ali preverjate, ali je hitra sprememba spremenila izhod na načine, ki jih niste nameravali, raje razlikujete oblikovane koristne obremenitve, kot da berete oboje. Strukturne razlike, ki so nevidne v steni JSON – polju, ki je tiho postalo niz števk namesto številke – takoj izstopajo v razliki.

Versioning

Sheme se spreminjajo in izhod modela se spreminja z njimi. Polje različice vstavite v koristni tovor od prvega dne, tako da bodo shranjeni zapisi nosili obliko, v kateri so bili zapisani. Naknadno prilagajanje, potem ko imate milijon vrstic neoznačenega JSON, je vrsta selitve, za katero nihče ne načrtuje časa.

Vsa ta orodja se izvajajo lokalno v vašem brskalniku, kar je za ta delovni tok pomembnejše kot običajno: vzorčni tovori, ki jih pretvarjate v sheme, so običajno resnični odgovori API-ja z resničnimi podatki o strankah v njih in jih ne bi smeli naložiti v storitev oblikovanja, da bi jih polepšali.