Strukturované výstupy: získání spolehlivého JSON z jazykového modelu

První verze každé integrace LLM analyzuje prózu. Požádáte o „tři hlavní rizika, jedno na řádek“, rozdělená na nové řádky a funguje to až do dne, kdy model napíše úvodní větu jako první. K ukončení této smyčky existují strukturované výstupy: předáte modelu schéma JSON, dekodér je omezen, takže nemůže vysílat nic, co by jej porušovalo, a dostanete zpět užitečné zatížení s poli, o která jste požádali. Tato záruka je skutečná, ale užší, než se zdá, a rozdíl je v tom, kde brouci žijí.

Na co se záruka vlastně vztahuje

Omezené záruky dekódování tvar. Odpověď bude analyzována jako JSON, bude mít vaše klíče, typy se budou shodovat a pole výčtu bude obsahovat jednu z vašich uvedených hodnot. To je velké zlepšení oproti promptu a naději.

Nezaručuje nic o obsah. Pole zadané jako řetězec bude obsahovat řetězec; zda je tento řetězec přesný nebo vynalezený tak, aby vyhovoval schématu, se oproti předchozímu nemění. Ve skutečnosti přísné schéma činí vynález o něco pravděpodobnější, protože povinné pole musí být něčím vyplněno a model nemá žádný způsob, jak říci „není přítomen ve zdroji“. Toto je jediná nejčastější porucha ve výrobě: nutnost invoice_number v dokumentu, který žádné nemá.

Design kolem toho. Povolit hodnotu null tam, kde je nepřítomnost možná, přidat explicitní found: boolean nebo a "unknown" enum člen a nikdy nevyžadujte pole, pokud odpověď skutečně neexistuje v každém vstupu.

Návrh schématu, které může model vyplnit

Schémata napsaná pro ověření a schémata napsaná pro generování vypadají odlišně. Několik pravidel, která platí napříč poskytovateli:

• Ploché beaty vnořené. Každá úroveň vnoření je místem, kde model ztrácí přehled. Tři mělké objekty extrahované ve třech voláních porazí jeden hluboce vnořený strom.
• Enumy porazí volné struny. Pokud má pole pět legitimních hodnot, uveďte je. Odeberete celou třídu normalizačního kódu a omezený dekodér to za vás vynutí.
• Názvy polí jsou instrukce. due_date_iso8601 produkuje lepší výstup než date s formátem vysvětleným v samostatné výzvě. Jména jsou v kontextu; používat je.
• Použití description na polích. Většina poskytovatelů předává modelu popisy schémat. Jedna klauzule na nejednoznačné pole je levnější a spolehlivější než odstavec výše uvedených prozaických pokynů.
• Soubor additionalProperties: false. Několik poskytovatelů to stejně vyžaduje pro přísný režim a model to zastaví užitečně ve vymýšlení dalšího klíče, který váš analyzátor tiše ignoruje.
• Upřednostňujte pole plochých objektů před mapami. Dynamické klíče — objekt, jehož názvy vlastností jsou předem neznámé — jsou špatně podporovány přísnými režimy a je obtížné je psát na přijímací straně.

Poskytovatelé také omezují, která klíčová slova schématu JSON podporují v přísném režimu: oneOf, omezení vzoru, numerické hranice a rekurze jsou běžně omezeny nebo ignorovány. Předpokládejme, že schéma omezuje pouze strukturu a po analýze vynucujte svá obchodní pravidla sami.

Každopádně potvrdit

I v přísném režimu ověřte každou odpověď dříve, než se dotkne vaší databáze. Přísný režim může být deaktivován změnou konfigurace, záložní cesta může zasáhnout model, který ji nepodporuje, opakování sítě může vrátit chybový objekt a odpověď může být zkrácena limitem tokenu uprostřed objektu – což vytváří neplatný JSON, kterému žádný režim schématu nebrání.

Když užitečné zatížení selže, je užitečná otázka, které pole a proč. The Validátor schématu JSON vezme dokument a schéma a nahlásí jeden řádek pro každý problém s cestou ukazatele JSON, klíčovým slovem, které selhalo, a skutečně nalezenou hodnotou. To je přesně ten formulář, který chcete pro dva účely: oprava schématu během vývoje a odeslání zpět do nového pokusu – zpráva o neúspěšném ověření vložená do následné zprávy je pozoruhodně efektivní výzvou k opravě, protože model přesně vidí, co se pokazilo.

Uzavřete počet opakování na jeden nebo dva. Model, který dvakrát selže ve schématu, je obvykle požádán o něco, co vstup neobsahuje, a třetí pokus to vymyslí.

Od ukázkové užitečné zátěže po kód

Většina schémat začíná život jako vzorová odpověď, kterou někdo vložil do chatu. Ruční přeměna na psaný a ověřený kód je únavná a náchylná k chybám, takže to nedělejte.

Vložte vzorek do Schéma JSON na Zod a získáte schéma Zod plus odvozený typ TypeScript. Odvozuje podle pole, místo aby vše zadával jako řetězec: hodnoty, které vypadají jako e-maily, adresy URL, UUID nebo data ISO, získají .email(), .url(), .uuid() a .datetime() místo holého z.string()pole nesou svůj typ prvku a pole, jehož typ se v různých výskytech liší, se stane sjednocením, místo aby si tiše vybralo první, které vidělo. Toto poslední chování stojí za to záměrně krmit: vložte tři nebo čtyři reálné odpovědi zřetězené, ne jednu, takže volitelná a polymorfní pole se zobrazí jako sjednocení, místo aby byla uzamčena na cokoliv, co první vzorek náhodou obsahoval.

Pokud potřebujete pouze typy a ne ověření za běhu – protože užitečné zatížení pochází ze zdroje, kterému již důvěřujete – JSON na TypeScript vytváří rozhraní přímo, s vnořenými objekty rozdělenými jako pojmenovaná dílčí rozhraní spíše než vložené anonymní bloby.

Udržujte směr pravdy přímo: jedna definice schématu se vším ostatním, co je z ní vygenerováno. Schéma Zod a schéma JSON udržované odděleně se do měsíce neshodnou a neshoda se objeví jako chyba produkční analýzy, nikoli jako selhání testu.

Číst, co se vrátilo

Odpovědi modelu přicházejí zmenšené na jednom řádku, takže je mizerně sledovat. The formátovač JSON odsadí je a seřadí je do něčeho čitelného a jeho ověření okamžitě zachytí případ zkrácení – užitečné zatížení, které končí uprostřed řetězce, je podpisem limitu tokenů a opravou je vyšší omezení výstupu nebo menší schéma, nikoli rychlá změna.

Když porovnáváte, jaké dva modely vyprodukovaly ze stejného vstupu, nebo kontrolujete, zda rychlá změna nezměnila výstup způsobem, který jste nezamýšleli, porovnejte naformátované užitečné zatížení spíše než čtěte oba. Strukturální rozdíly, které jsou neviditelné ve stěně JSON – pole, které se tiše stalo řetězcem číslic místo čísla – okamžitě vyniknou v rozdílu.

Verzování

Schémata se mění a s nimi se mění i výstup modelu. Vložte pole verze do užitečného obsahu od prvního dne, aby uložené záznamy měly tvar, pod kterým byly zapsány. Dodatečné přizpůsobení, že poté, co máte milion řádků neoznačeného JSON, je druh migrace, na který si nikdo neplánuje čas.

Všechny tyto nástroje běží lokálně ve vašem prohlížeči, což je pro tento pracovní postup důležitější než obvykle: ukázkové datové zátěže, které měníte na schémata, jsou obvykle skutečné odpovědi rozhraní API se skutečnými daty zákazníků a neměly by být nahrány do formátovací služby, aby byly upraveny.