AI-interviewspørgsmål 2: Hvordan sikrer man, at Large Language Model (LLM) pålideligt kalder værktøjer?

Hvordan sikrer man, at Large Language Model (LLM) pålideligt og kontrolleret fungerer under værktøjskald, i stedet for blot at stole på prompt-tekster for at "overtale" modellen? Der er behov for systematisk at give en flerlags begrænsningsramme.

Tag eksemplet med at slå vejret op. Modellen har tre almindelige "opdigtede" adfærd under værktøjskald:
1. Kald ikke værktøjet, opfind svar direkte.
2. Overfør parametre med forkert format ved kald af værktøj (f.eks. værktøjet understøtter ikke "i overmorgen", men sender parameter date="i overmorgen").
3. Konverter parametre på egen hånd (f.eks. konverter "i overmorgen" til en specifik dato), selvom værktøjet ikke kræver det.

Rodårsagen er, at modeloutput i sagens natur er probabilistisk. Prompt-tekster pålægger kun en "blød begrænsning" på sandsynlighedsfordelingen, ikke en tvungen mekanisme, der sikrer, at modellen overholder strengt. I komplekse scenarier svigter denne "bløde begrænsning" let.

For at løse dette problem er der brug for en flerlags teknisk løsning:

1. Første lag: Optimering af prompt-tekster (blød begrænsning)

   • Placering er udgangspunktet for begrænsningssystemet, men absolut ikke slutpunktet.
   • Prompt-tekster bør betragtes som en "operationskontrakt", der tydeligt forklarer værktøjets formål, typen af hver parameter, grænser, og giver eksempler på ugyldige værdier.
   • Few-shot-eksempler bør inkluderes, ved at vise eksempler på "korrekt input → korrekt kald" for at forankre modellens adfærdsmønster gennem kontekstlæring.

2. Andet lag: Introduktion af JSON Schema (hård begrænsning)

   • Dette er et afgørende skridt fra "at argumentere" til "at sætte rækværk".
   • Erstat naturlig sprogbeskrivelse af parametre med maskinlæsbare, verificerbare strukturerede definitioner (JSON Schema). Det kan strengt definere felttyper, om de er påkrævede, enumerationsværdier, og ved at sætte additionalProperties: false forhindre modellen i at udsende udefinerede felter.
   • De fleste API-platforme understøtter denne strukturerede output-begrænsning allerede i model-dekodningsfasen, hvilket undgår formatfejl fra kilden.

3. Tredje lag: Etablering af validerings-reparations-genforsøgsløkke (eksekveringssikkerhed)

   • Selv med Schema er det stadig nødvendigt at udføre syntaks- og Schema-validering efter at have modtaget modeloutput.
   • Ved valideringsfejl bør der designes en automatisk rensnings- og genforsøgsmekanisme (med en øvre grænse), der sender fejlmeddelelsen tilbage til modellen for at korrigere output. Efter overskridelse af genforsøgsgrænsen skal der være en nedgraderings- eller manuel behandlingsplan.

4. Arkitekturniveau: Adskillelse af ansvar

   • Beslutning og eksekvering bør adskilles, hvilket danner en trelagsarkitektur:
     • Modellag: Kun ansvarlig for beslutning (afgøre hvilket værktøj der kaldes, hvilke parametre der genereres).
     • Rammeværklag: Ansvarlig for eksekveringsrammen, inklusive Schema-validering, kald af værktøj, håndtering af genforsøg og integration af resultater. Dette sikrer, at modelfejl ikke direkte påvirker værktøjssikkerheden, og værktøjsændringer kræver ikke hyppig justering af prompt-tekster.
     • Værktøjslag: Specifik forretningskapacitetsimplementering.
   • Rammer som LangChain, LlamaIndex gør netop dette arbejde.

Begrænsninger ved nuværende løsning: Den håndterer parameterformat godt, men dækker stadig ikke tilstrækkeligt validering af parametersemantik (f.eks. ækvivalens mellem "Shanghai" og "Hu"). Dette vil være en fremtidig teknisk udfordring.

Kernekonklusion: At få LLM til pålideligt at kalde værktøjer er i bund og grund et softwareingeniørproblem, der kræver et systematisk ingeniørprojekt fra blød begrænsning, hård begrænsning, eksekveringssikkerhed til arkitekturdesign, snarere end blot at stole på optimering af prompt-tekster.