Strukturirani izlazi: dobivanje pouzdanog JSON-a iz jezičnog modela

Prva verzija svake LLM integracije analizira prozu. Tražite "tri glavna rizika, jedan po retku", podijeljen na nove retke, i to radi do dana kada model prvi napiše uvodnu rečenicu. Strukturirani izlazi postoje kako bi se završila ta petlja: predate modelu JSON shemu, dekoder je ograničen tako da ne može emitirati ništa što ga krši, a vi dobivate natrag korisni teret s poljima koja ste tražili. To je jamstvo stvarno, ali manje nego što zvuči, a razlika je u tome gdje bube žive.

Što jamstvo zapravo pokriva

Jamstva ograničenog dekodiranja oblik. Odgovor će se analizirati kao JSON, imat će vaše ključeve, tipovi će se podudarati, a enum polja sadržavat će jednu od vaših navedenih vrijednosti. To je veliki napredak u odnosu na prompt-and-hope.

Ne jamči ništa o sadržaj. Polje upisano kao niz sadržavat će niz; je li taj niz točan, ili je izmišljen da zadovolji shemu, nepromijenjen je od prije. U stvari, stroga shema čini izum malo vjerojatnijim, jer potrebno polje mora biti ispunjeno nečim, a model nema načina da kaže "nije prisutan u izvoru". Ovo je najčešći pojedinačni kvar u proizvodnji: potreban invoice_number u dokumentu koji nema.

Dizajn oko toga. Dopusti null gdje je moguća odsutnost, dodaj eksplicitno found: boolean ili a "unknown" član enum, i nikada ne učinite polje obaveznim osim ako odgovor stvarno postoji u svakom unosu.

Dizajniranje sheme koju model može ispuniti

Sheme napisane za provjeru valjanosti i sheme napisane za generiranje izgledaju drugačije. Nekoliko pravila koja vrijede za sve pružatelje usluga:

• Ravni ritmovi ugniježđeni. Svaka razina ugniježđenja je mjesto gdje se modelu gubi trag. Tri plitka objekta izvađena u tri puta pobijedila su jedno duboko ugniježđeno stablo.
• Enumi pobjeđuju slobodne nizove. Ako polje ima pet legitimnih vrijednosti, navedite ih. Uklonite cijelu klasu normalizacijskog koda i ograničeni dekoder to provodi umjesto vas.
• Nazivi polja su upute. due_date_iso8601 proizvodi bolji učinak od date s formatom objašnjenim u zasebnom upitu. Imena su u kontekstu; koristiti ih.
• Koristiti description na poljima. Većina pružatelja prosljeđuje opise shema modelu. Jedna klauzula po dvosmislenom polju jeftinija je i pouzdanija od gornjeg paragrafa proznih uputa.
• set additionalProperties: false. Nekoliko ga pružatelja ionako zahtijeva za strogi način rada i sprječava model da korisno izmisli dodatni ključ koji vaš parser tiho ignorira.
• Dajte prednost nizovima ravnih objekata nego kartama. Dinamičke ključeve — objekte čija su imena svojstava unaprijed nepoznata — striktni načini rada slabo podržavaju i neugodni su za upisivanje na primateljskoj strani.

Pružatelji također ograničavaju koje ključne riječi JSON sheme podržavaju u strogom načinu rada: oneOf, ograničenja uzorka, numeričke granice i rekurzija obično se ograničavaju ili zanemaruju. Pretpostavite da shema ograničava samo strukturu i sami nametnite svoja poslovna pravila nakon analize.

Svejedno potvrdite

Čak i sa strogim načinom rada, potvrdite svaki odgovor prije nego dotakne vašu bazu podataka. Strogi način rada može biti onemogućen promjenom konfiguracije, zamjenski put može pogoditi model koji ga ne podržava, ponovni mrežni pokušaj može vratiti objekt pogreške, a odgovor može biti skraćen objektom ograničenja tokena u sredini — što proizvodi nevažeći JSON koji način sheme ne sprječava.

Kada korisni teret ne uspije, korisno je pitanje koje polje i zašto. The Validator JSON sheme uzima dokument i shemu i izvješćuje o jednom retku po problemu, s putanjom JSON pokazivača, ključnom riječi koja nije uspjela i stvarno pronađenom vrijednošću. To je upravo onaj oblik koji želite za dvije svrhe: popravljanje vaše sheme tijekom razvoja i vraćanje u ponovni pokušaj - izvješće o neuspješnoj provjeri valjanosti zalijepljeno u naknadnu poruku iznimno je učinkovit upit za popravak, budući da model može točno vidjeti u čemu je pogriješio.

Ograničite ponovni pokušaj na jedan ili dva. Model koji dvaput ne uspije sa shemom obično se traži nešto što ulaz ne sadrži, a treći pokušaj će to izmisliti.

Od uzorka nosivosti do koda

Većina shema započinje život kao primjer odgovora koji je netko zalijepio u chat. Ručno pretvaranje toga u upisani, potvrđeni kod je zamorno i podložno pogreškama, stoga nemojte.

Zalijepite uzorak u JSON u Zod shemu i dobivate Zod shemu plus pretpostavljeni TypeScript tip. Zaključuje po polju umjesto da sve upisuje kao niz: dobivaju se vrijednosti koje izgledaju kao e-poruke, URL-ovi, UUID-ovi ili ISO datumi .email(), .url(), .uuid() i .datetime() umjesto golog z.string(), nizovi nose svoj tip elementa, a polje čiji se tip razlikuje od pojavljivanja postaje unija umjesto tihog odabira prvog koje je vidjelo. To posljednje ponašanje vrijedi namjerno hraniti: zalijepite tri ili četiri stvarna odgovora spojena, a ne jedan, tako da se izborna i polimorfna polja prikazuju kao unije umjesto da budu zaključana za ono što prvi uzorak sadrži.

Ako su vam potrebni samo tipovi, a ne provjera valjanosti tijekom izvođenja — jer korisni teret dolazi iz izvora kojem već vjerujete — JSON u TypeScript proizvodi sučelja izravno, s ugniježđenim objektima razdvojenim kao imenovana pod-sučelja umjesto umetnutih anonimnih mrlja.

Držite smjer istine ravnim: jedna definicija sheme, sa svim ostalim generiranim iz nje. Zod shema i JSON shema koje se održavaju zasebno neće se slagati u roku od mjesec dana, a neslaganje će se pojaviti kao pogreška raščlambe proizvodnje, a ne neuspjeh testa.

Čitajući ono što se vratilo

Odgovori modela stižu umanjeni u jednom retku, što ih čini jadnim. The JSON formater uvlači i razvrstava ih u nešto čitljivo, a njegova provjera valjanosti odmah hvata slučaj skraćivanja — korisni teret koji završava na sredini niza potpis je ograničenja tokena pogodaka, a popravak je veće ograničenje izlaza ili manja shema, a ne brza promjena.

Kada uspoređujete ono što su dva modela proizvela iz istog ulaza ili provjeravate je li brza promjena izmijenila izlaz na načine koje niste namjeravali, napravite razliku između formatiranih korisnih podataka umjesto da čitate oba. Strukturne razlike koje su nevidljive u zidu JSON-a — polje koje je tiho postalo niz znamenki umjesto broja — odmah se ističu u razlici.

Verzija

Sheme se mijenjaju, a s njima se mijenja i izlaz modela. Stavite polje verzije u korisni teret od prvog dana, tako da pohranjeni zapisi imaju oblik u kojem su napisani. Retro opremanje nakon što imate milijun redaka neoznačenog JSON-a je vrsta migracije za koju nitko ne planira vrijeme.

Svi ovi alati pokreću se lokalno u vašem pregledniku, što je važnije od uobičajenog za ovaj tijek rada: uzorci nosivosti koje pretvarate u sheme obično su stvarni odgovori API-ja sa stvarnim korisničkim podacima u njima i ne bi se trebali učitavati u uslugu formatiranja kako bi bili uljepšani.