Štruktúrované výstupy: získanie spoľahlivého JSON z jazykového modelu

Prvá verzia každej integrácie LLM analyzuje prózu. Požiadate o „tri hlavné riziká, jedno na riadok“, rozdelené na nové riadky a funguje to až do dňa, keď model napíše úvodnú vetu ako prvý. Na ukončenie tejto slučky existujú štruktúrované výstupy: dáte modelu schému JSON, dekodér je obmedzený, takže nemôže vysielať nič, čo by ho porušovalo, a dostanete späť užitočné zaťaženie s poľami, ktoré ste požadovali. Táto záruka je skutočná, ale užšia, ako sa zdá, a rozdiel je v tom, kde chyby žijú.

Na čo sa záruka v skutočnosti vzťahuje

Obmedzené záruky dekódovania tvar. Odpoveď bude analyzovať ako JSON, bude mať vaše kľúče, typy sa budú zhodovať a polia enum budú obsahovať jednu z vašich uvedených hodnôt. To je veľké zlepšenie oproti promptu a nádeji.

Nezaručuje nič o obsahu. Pole zadané ako reťazec bude obsahovať reťazec; či je tento reťazec presný alebo vynájdený tak, aby vyhovoval schéme, sa od predchádzajúceho nemení. V skutočnosti striktná schéma robí vynález o niečo pravdepodobnejším, pretože povinné pole musí byť niečím vyplnené a model nemôže povedať „neprítomný v zdroji“. Toto je jediná najčastejšia porucha vo výrobe: povinná invoice_number v dokumente, ktorý nemá žiadne.

Dizajn okolo toho. Ak je neprítomnosť možná, povoľte hodnotu null, pridajte explicitnú hodnotu found: boolean alebo a "unknown" enum člen a nikdy nevyžadujte pole, pokiaľ odpoveď skutočne neexistuje v každom vstupe.

Navrhovanie schémy, ktorú môže model vyplniť

Schémy napísané na overenie a schémy napísané na generovanie vyzerajú odlišne. Niekoľko pravidiel, ktoré platia pre všetkých poskytovateľov:

• Ploché beaty vnorené. Každá úroveň hniezdenia je miestom, kde model stráca prehľad. Tri plytké objekty extrahované v troch hovoroch porazili jeden hlboko vnorený strom.
• Enumy porazia voľné struny. Ak má pole päť legitímnych hodnôt, uveďte ich. Odstránite celú triedu normalizačného kódu a obmedzený dekodér to za vás vynúti.
• Názvy polí sú pokyny. due_date_iso8601 produkuje lepší výstup ako date s formátom vysvetleným v samostatnej výzve. Mená sú v kontexte; použiť ich.
• Použite description na poliach. Väčšina poskytovateľov odovzdáva popisy schém modelu. Jedna klauzula na nejednoznačné pole je lacnejšia a spoľahlivejšia ako odsek vyššie uvedených pokynov v próze.
• Set additionalProperties: false. Viacerí poskytovatelia to aj tak vyžadujú pre prísny režim a model bráni užitočne vymýšľať ďalší kľúč, ktorý váš syntaktický analyzátor ticho ignoruje.
• Uprednostňujte polia plochých objektov pred mapami. Dynamické kľúče – objekt, ktorého názvy vlastností sú vopred neznáme – sú nedostatočne podporované prísnymi režimami a ťažko sa píšu na prijímacej strane.

Poskytovatelia tiež obmedzujú, ktoré kľúčové slová schémy JSON podporujú v prísnom režime: oneOfObmedzenia vzorov, numerické hranice a rekurzia sú bežne obmedzené alebo ignorované. Predpokladajme, že schéma obmedzuje iba štruktúru a po analýze presadzujte svoje obchodné pravidlá sami.

Napriek tomu overiť

Dokonca aj v prísnom režime overte každú odpoveď skôr, ako sa dotkne vašej databázy. Prísny režim môže byť deaktivovaný zmenou konfigurácie, záložná cesta môže zasiahnuť model, ktorý ju nepodporuje, opakovaný pokus siete môže vrátiť chybový objekt a odpoveď môže byť skrátená limitom tokenu v strede objektu – čo vytvára neplatný JSON, ktorému nebráni žiadny režim schémy.

Keď užitočné zaťaženie zlyhá, užitočná otázka je, ktoré pole a prečo. The Validátor schémy JSON vezme dokument a schému a nahlási jeden riadok pre každý problém s cestou ukazovateľa JSON, kľúčovým slovom, ktoré zlyhalo, a skutočne nájdenou hodnotou. To je presne ten formulár, ktorý chcete na dva účely: oprava schémy počas vývoja a spätné zaslanie do opätovného pokusu – správa o zlyhaní overenia prilepená do následnej správy je mimoriadne efektívna výzva na opravu, pretože model presne vidí, čo sa pokazilo.

Uzáver opakovania na jeden alebo dva. Model, ktorý dvakrát zlyhá v schéme, je zvyčajne požiadaný o niečo, čo vstup neobsahuje, a tretí pokus to vymyslí.

Od ukážkového užitočného zaťaženia až po kód

Väčšina schém začína život ako vzorová odpoveď, ktorú niekto vložil do chatu. Ručná premena na napísaný a overený kód je únavná a náchylná na chyby, takže to nerobte.

Vložte vzorku do JSON do schémy Zod a získate schému Zod plus odvodený typ TypeScript. Odvodzuje podľa poľa namiesto paušálneho zadávania všetkého ako reťazca: hodnoty, ktoré vyzerajú ako e-maily, adresy URL, UUID alebo dátumy ISO, získajú .email(), .url(), .uuid() a .datetime() namiesto holého z.string(), polia nesú svoj typ prvku a pole, ktorého typ sa mení v rôznych výskytoch, sa stáva zjednotením, namiesto toho, aby si ticho vybralo prvé, ktoré videlo. Toto posledné správanie sa oplatí zámerne doplniť: vložte tri alebo štyri zreťazené skutočné odpovede, nie jednu, takže voliteľné a polymorfné polia sa zobrazia ako spojenia namiesto toho, aby boli uzamknuté na čokoľvek, čo prvá vzorka obsahovala.

Ak potrebujete iba typy a nie validáciu runtime – pretože užitočné zaťaženie pochádza zo zdroja, ktorému už dôverujete – JSON na TypeScript vytvára rozhrania priamo, pričom vnorené objekty sú rozdelené ako pomenované podrozhrania a nie ako vnorené anonymné bloby.

Udržujte smer pravdy rovný: jedna definícia schémy so všetkým ostatným, čo je z nej vygenerované. Schéma Zod a schéma JSON udržiavané oddelene sa do mesiaca nezhodnú a nezhoda sa prejaví ako chyba produkčnej analýzy a nie ako zlyhanie testu.

Čítanie toho, čo sa vrátilo

Odpovede modelov prichádzajú zmenšené na jednom riadku, čo spôsobuje, že ich sledovanie je nešťastné. The formátovač JSON odsadí a roztriedi ich do niečoho čitateľného a jeho validácia okamžite zachytí prípad skrátenia – užitočné zaťaženie, ktoré končí v strede reťazca, je podpisom limitu prístupových tokenov a opravou je vyšší výstupný limit alebo menšia schéma, nie rýchla zmena.

Keď porovnávate dva modely vyrobené z rovnakého vstupu alebo kontrolujete, či rýchla zmena zmenila výstup spôsobom, ktorý ste nezamýšľali, namiesto čítania oboch porovnávajte naformátované užitočné zaťaženia. Štrukturálne rozdiely, ktoré sú neviditeľné v stene JSON – poľa, ktoré sa potichu zmenilo na reťazec číslic namiesto čísla – okamžite vyniknú v rozdiele.

Verzia

Schémy sa menia a s nimi sa mení aj výstup modelu. Vložte pole verzie do užitočného obsahu od prvého dňa, aby uložené záznamy mali tvar, pod ktorým boli napísané. Retro-montáž, že keď máte milión riadkov neoznačeného JSON, je druh migrácie, na ktorý si nikto neplánuje čas.

Všetky tieto nástroje bežia lokálne vo vašom prehliadači, čo je pre tento pracovný postup dôležitejšie ako zvyčajne: vzorové užitočné zaťaženia, ktoré meníte na schémy, sú zvyčajne skutočné odpovede rozhrania API so skutočnými údajmi o zákazníkoch a nemali by sa nahrávať do formátovacej služby, aby boli vopred upravené.