tool_use for garantert struktur

Her er et ekstraksjonsverktøy. Legg merke til de tre grunnpilarene i en god verktøydefinisjon: et tydelig name, en beskrivende description og et presist input_schema med beskrivelser for hver egenskap og en required-liste.

Skjemaet nedenfor ekstraherer en kundestøttesak. Vi krever bare feltene som er alltid til stede – mer om den avgjørelsen snart.

Det er ikke nok å deklarere verktøyet – med standardinnstillingen kan Claude svare med tekst i stedet. Parameteren tool_choice styrer denne avgjørelsen:

• {"type": "auto"} – Claude velger tekst eller et verktøy (standard).
• {"type": "any"} – Claude må kalle et verktøy. Det er dette som garanterer strukturert utdata.
• {"type": "tool", "name": "X"} – tving frem ett bestemt verktøy ved navn.

Når De har nøyaktig ett skjemaverktøy og vil garantere at det blir kalt, tvinger De det frem ved navn. Da fjernes hele muligheten til å «svare i prosa».

Når Claude kaller verktøyet, inneholder svaret en tool_use-innholdsblokk. De strukturerte dataene ligger i block.input – allerede analysert som en Python-dict av SDK-et og i samsvar med skjemaet.

En regel fra faktabladet er å alltid analysere det analyserte objektet fra SDK-et, aldri matche rå tekststrenger mot de serialiserte inndataene. Nyere modeller kan escape Unicode-tegn eller skråstreker på ulike måter, så behandle block.input som strukturerte data, ikke som tekst.

Dette er den viktigste avgjørelsen som testes i denne leksjonen. Regelen fra faktabladet er kategorisk:

Merk et felt som required KUN hvis det alltid finnes. Krev ALDRI et felt som kan mangle – modellen vil finne på en verdi for å oppfylle skjemaet.

Hvis customer_id noen ganger ikke finnes i kildeteksten, men De fører det opp under required, vil Claude ikke returnere et tomt resultat – den vil finne på en ID som ser plausibel ut, for å gjøre verktøykallet gyldig. Det er en stille dataintegritetsfeil. Required betyr «garantert av kilden», ikke «kjekt å ha».

Felt som kan mangle, holdes ganske enkelt utenfor required-matrisen. Claude utelater dem når kilden mangler dataene, i stedet for å hallusinere.

Her er customer_id og attachments valgfrie; bare summary og priority – som vi alltid kan utlede – er obligatoriske.

Enum-er begrenser et felt til et fast sett med verdier – perfekt for kategorier, etiketter og prioriteter. Men en rigid enum tvinger hvert inndata inn i en av de forhåndsdefinerte kategoriene, noe som skaper problemer for randtilfeller De ikke forutså.

Mønsteret fra faktabladet for utvidbarhet er å bruke enum-er med verdien «other» samt et fritekstfelt for detaljer. Når Claude møter noe utenfor kategoriene, velger den other og forklarer i detaljfeltet – i stedet for å feilmerke det.

Skjemaet garanterer syntaktisk struktur, men De må fortsatt validere semantikken – summer som går opp, datoer innenfor riktig intervall og konsistens mellom felter. Bruk en validator i Pydantic-stil på block.input.

Når valideringen feiler på grunn av en format-, struktur- eller aritmetikkfeil, bruker De retry-with-feedback: send den opprinnelige kilden, det feilaktige resultatet og den nøyaktige valideringsfeilen på nytt. Viktig: Faktabladet advarer om at retry IKKE hjelper når informasjonen ganske enkelt mangler i kilden – nye forsøk inviterer bare til at modellen finner på noe.

Ved numerisk ekstraksjon er et effektivt skjematriks å få Claude til å vise arbeidet sitt, slik at avvik blir oppdagbare. Som det står i faktabladet: ekstraher både calculated_total og stated_total for å oppdage avvik.

Hvis dokumentet sier «Total: 1 200 $», men linjepostene summerer seg til 1 150 $, synliggjør to separate felt avviket – validatoren Deres fanger det opp i stedet for å stole på ett enkelt tall. Skjemaet blir et revisjonsverktøy, ikke bare en beholder.

Strukturert utdata er ett stopp i den større agentiske løkken: forespørsel → inspiser stop_reason → hvis tool_use, håndter verktøyet → gjenta til end_turn. Et tvunget skjemakall returnerer stop_reason: "tool_use"; De leser block.input og fortsetter.

To påminnelser på arkitekturnivå: avslutt på grunnlag av stop_reason, aldri ved å lete etter ord som «ferdig» i teksten. Og bevar proveniens – koble hvert ekstraherte utsagn tilbake til kilden (dokumentnavn, sitat, dato), slik at etterfølgende forbrukere kan stole på og revidere det strukturerte resultatet.

Dette er hovedpunktene til eksamen og for produksjon:

• tool_use + JSON Schema eliminerer syntaksfeil og håndhever obligatoriske felt – langt mer pålitelig enn å analysere JSON i prosa.
• tool_choice: "any" garanterer et verktøykall; {"type":"tool","name":"X"} tvinger frem et bestemt skjemaverktøy; "auto" gjør det valgfritt.
• required = alltid til stede. Krev aldri et felt som kanskje mangler – det fører til oppdiktede verdier. Valgfrie felt holdes ganske enkelt utenfor required.
• Enum-er trenger «other» + et detaljfelt for utvidbarhet.
• Les strukturerte data fra block.input; match aldri rå tekststrenger mot de serialiserte verktøyinndataene.
• Retry-with-feedback retter format- og aritmetikkfeil – ikke manglende informasjon. Bruk calculated_total kontra stated_total til selvkorrigering, og bevar proveniens.