AI intervjuu küsimus 2: Kuidas tagada suure keelemudeli (LLM) tööriistade väljakutsumise usaldusväärsus

Kuidas tagada, et suur keelemudel (LLM) tööriistade väljakutsumisel töötaks usaldusväärselt ja kontrollitavalt, mitte ainult ei tugineks mudeli "veenmiseks" viipadele. Vaja on süsteemselt anda mitmetasandiline piirangute raamistik.

Nagu ilma näitel, on mudeli tööriistade väljakutsumisel kolm levinud "väljamõeldud" käitumist:
1. Ära kutsu tööriista, vaid mõtle vastus otse välja.
2. Kutsu tööriist välja vales formaadis parameetritega (nt tööriist ei toeta "ülehomme", kuid edastab parameetri date="ülehomme").
3. Muuda parameetrite formaati omavoliliselt (nt teisenda "ülehomme" ise konkreetseks kuupäevaks), isegi kui tööriist seda ei nõua.

Probleemi juur on selles, et mudeli väljund on olemuselt tõenäosuslik; viipad rakendavad tõenäosusjaotusele ainult "pehmeid piiranguid", mitte ei taga, et mudel neid rangelt järgiks. Keerulistes stsenaariumides võivad need "pehmed piirangud" kergesti ebaõnnestuda.

Selle probleemi lahendamiseks on vaja mitmetasandilist insenerilahendust:

1. Esimene kiht: optimeeri viipad (pehmed piirangud)

   • Positsioon on piirangute süsteemi lähtepunkt, kuid mitte lõpp-punkt.
   • Viipasid tuleks käsitleda kui "töölepingut", mis selgitab tööriista eesmärki, iga parameetri tüüpi, piire ja loetleb kehtetute väärtuste näiteid.
   • Lisada tuleks Few-shot näited, näidates "õige sisend → õige väljakutse" näiteid, kasutades kontekstiõpet mudeli käitumismustrite ankurdamiseks.

2. Teine kiht: võta kasutusele JSON Schema (kõvad piirangud)

   • See on võtmesamm "loogikast" "piirete seadmiseni".
   • Asenda loomuliku keele parameetrite kirjeldused masinloetava ja kontrollitava struktureeritud määratlusega (JSON Schema). See võimaldab rangelt määratleda väljade tüübid, kohustuslikkuse, loendiväärtuste vahemikud ja keelata mudelil väljastada määratlemata välju, seades additionalProperties: false.
   • Peamised API platvormid toetavad sellist struktureeritud väljundi piirangut juba mudeli dekodeerimise etapis, vältides formaadivigu juba tekkekohas.

3. Kolmas kiht: loo kontrolli-paranda-proovi uuesti tsükkel (täitmise tagamine)

   • Isegi Schema olemasolul tuleb pärast mudeli väljundi saamist teostada süntaksi ja Schema kontroll.
   • Kui kontroll ebaõnnestub, tuleb kavandada automaatne puhastus- ja uuesti proovimise mehhanism (piiratud arv kordi), mis tagastab veateate mudelile väljundi parandamiseks. Pärast uuesti proovimise piirangu ületamist peab olema langetatud või käsitsi töötlemise plaan.

4. Arhitektuuri tasand: kohustuste eraldamine

   • Tuleks eraldada otsustamine ja täitmine, moodustades kolmekihilise arhitektuuri:
     • Mudeli kiht: vastutab ainult otsustamise eest (otsustab, millist tööriista kutsuda, milliseid parameetreid genereerida).
     • Raamistiku kiht: vastutab täitmise raamistiku eest, sealhulgas Schema kontroll, tööriista väljakutsumine, uuesti proovimise haldamine ja tulemuste integreerimine. See tagab, et mudeli vead ei mõjuta otseselt tööriista ohutust ja tööriista muudatused ei nõua viipade sagedast kohandamist.
     • Tööriista kiht: konkreetse äri loogika teostus.
   • LangChain, LlamaIndex jt raamistikud teevad just seda.

Praeguse lahenduse piirangud: suudab hästi käsitleda parameetrite formaadi probleeme, kuid parameetrite semantika (nt "Shanghai" ja "沪" samaväärsus) kontrolli katvus on endiselt ebapiisav. See on tulevane inseneriprobleem, millega tuleb tegeleda.

Põhijäreldus: LLM-i usaldusväärne tööriistade väljakutsumine on olemuselt tarkvaratehnika probleem, mis nõuab süsteemset insenerilahendust, mis hõlmab pehmeid piiranguid, kõvasid piiranguid, täitmise tagamist ja arhitektuuri kavandamist, mitte ainult viipade optimeerimisele tuginemist.