AI-intervjuspørsmål 2: Hvordan sikre pålitelig verktøykalling for store språkmodeller (LLM)

Hvordan sikre at store språkmodeller (LLM) fungerer pålitelig og kontrollert ved verktøykalling, og ikke bare er avhengig av prompt-tekster for å "overtale" modellen. Det krever en systematisk flernivåramme for begrensninger.

Ta eksempelet med værsøk. Modellen har tre vanlige "fantasi"-atferder ved verktøykalling:
1. Kaller ikke verktøyet, men finner opp svar direkte.
2. Sender parametere med feil format ved verktøykalling (f.eks. verktøyet støtter ikke "i overmorgen", men sender date="i overmorgen").
3. Konverterer parameterformat på egen hånd (f.eks. konverterer "i overmorgen" til en spesifikk dato uten at verktøyet krever det).

Roten til problemet er at modellens utdata i hovedsak er sannsynlighetsbasert, og prompt-tekster påfører bare en "myk begrensning" på sannsynlighetsfordelingen, ikke en tvangsmekanisme som sikrer at modellen følger reglene strengt. I komplekse scenarier svikter disse "myke begrensningene" lett.

For å løse dette trengs en flernivås ingeniørløsning:

1. Første nivå: Optimaliser prompt-tekster (myke begrensninger)

   • Dette er startpunktet for begrensningssystemet, men absolutt ikke slutten.
   • Prompt-tekster bør betraktes som en "operasjonskontrakt" som tydelig forklarer verktøyets formål, hver parameters type og grenser, og gir eksempler på ugyldige verdier.
   • Inkluder Few-shot-eksempler som viser "riktig input → riktig kall" for å forankre modellens atferdsmønster gjennom kontekstlæring.

2. Andre nivå: Innfør JSON Schema (harde begrensninger)

   • Dette er et kritisk steg fra "å resonnere" til "å sette opp rekkverk".
   • Erstatt naturlig språkbeskrivelse av parametere med maskinlesbare, verifiserbare strukturerte definisjoner (JSON Schema). Dette kan strengt definere felttyper, om de er påkrevde, tillatte verdier, og ved å sette additionalProperties: false kan man forhindre modellen i å sende udefinerte felt.
   • De fleste API-plattformer støtter slik strukturert utdatabegrensning under dekoding, og unngår formatbrudd ved kilden.

3. Tredje nivå: Etabler en validering-reparasjon-gjentak-syklus (utførelsesgaranti)

   • Selv med Schema må man etter å ha mottatt modellens utdata utføre syntaks- og Schema-validering.
   • Ved valideringsfeil bør det designes en automatisk rensing og gjentaksmekanisme (med øvre grense) som sender feilinformasjon tilbake til modellen for å korrigere utdata. Etter maksimalt antall gjentak må det finnes en nedgraderings- eller manuell behandlingsplan.

4. Arkitekturnivå: Ansvarsseparasjon

   • Beslutning og utførelse bør separeres i en trelagsarkitektur:
     • Modellag: Kun ansvarlig for beslutning (bestemme hvilket verktøy som skal kalles, hvilke parametere som skal genereres).
     • Rammeverklag: Ansvarlig for utførelsesrammeverket, inkludert Schema-validering, verktøykalling, håndtering av gjentak og integrering av resultater. Dette sikrer at modellfeil ikke direkte påvirker verktøysikkerheten, og at verktøyendringer ikke krever hyppige prompt-justeringer.
     • Verktøylag: Spesifikk forretningslogikkimplementering.
   • Rammeverk som LangChain og LlamaIndex gjør nettopp dette.

Begrensninger ved dagens løsning: Den håndterer parameterformat godt, men dekker ikke tilstrekkelig validering av parametersemantikk (f.eks. ekvivalensen mellom "Shanghai" og "Hu"). Dette vil være en fremtidig ingeniørutfordring.

Kjernekonklusjon: Å få LLM til å kalle verktøy pålitelig er i bunn og grunn et programvareingeniørproblem som krever et systematisk ingeniørprosjekt fra myke begrensninger, harde begrensninger, utførelsesgaranti til arkitekturdesign, ikke bare avhengig av optimaliserte prompt-tekster.