AI vprašanje 2: Kako zagotoviti zanesljivost klicanja orodij velikih jezikovnih modelov (LLM)

Kako zagotoviti, da veliki jezikovni modeli (LLM) pri klicanju orodij delujejo zanesljivo in nadzorovano, ne le z uporabo pozivov za "prepričevanje" modela. Potreben je sistematičen večnivojski okvir omejitev.

Na primeru poizvedbe o vremenu so pogoste tri vrste "izmišljanja" modela pri klicanju orodij:
1. Ne kliče orodja, ampak neposredno izmisli odgovor.
2. Pri klicanju orodja posreduje parametre z napačno obliko (npr. orodje ne podpira "pojutrišnjem", vendar posreduje parameter date="pojutrišnjem").
3. Samovoljno pretvori obliko parametrov (npr. samovoljno pretvori "pojutrišnjem" v točen datum), čeprav orodje tega ne zahteva.

Koren problema je v tem, da je izhod modela v osnovi verjetnosten, pozivi pa le uvajajo "mehke omejitve" na verjetnostno porazdelitev, ne pa mehanizma, ki bi zagotavljal strogo upoštevanje. V kompleksnih scenarijih te "mehke omejitve" hitro odpovedo.

Za rešitev tega problema je potrebna večnivojska inženirska rešitev:

1. Prva raven: Optimizacija pozivov (mehke omejitve)

   • To je izhodišče sistema omejitev, nikakor pa ne končna točka.
   • Poziv je treba obravnavati kot "operativno pogodbo", ki jasno opisuje namen orodja, vrsto vsakega parametra, meje in navaja primere neveljavnih vrednosti.
   • Dodati je treba Few-shot primere, ki s prikazom "pravilen vnos → pravilen klic" s pomočjo učenja v kontekstu usidrajo vedenjski vzorec modela.

2. Druga raven: Uvedba JSON Sheme (trde omejitve)

   • To je ključen korak od "prepričevanja" do "postavljanja ograj".
   • Namesto naravnega jezika za opis parametrov uporabimo strojno berljivo, preverljivo strukturirano definicijo (JSON Shemo). Natančno lahko določimo vrsto polja, obveznost, obseg dovoljenih vrednosti in z nastavitvijo additionalProperties: false prepovemo modelu izpis kakršnih koli nedefiniranih polj.
   • Večina glavnih API platform podpira takšno strukturirano omejevanje izhoda že v fazi dekodiranja modela, s čimer se izognemo kršitvam oblike že pri izvoru.

3. Tretja raven: Vzpostavitev zanke preverjanje-popravek-ponovni poskus (izvedbeni varnostni ukrep)

   • Tudi ob shemi je treba po prejemu izhoda modela izvesti sintaktično in shematsko preverjanje.
   • Ob neuspešnem preverjanju je treba zasnovati mehanizem samodejnega čiščenja in ponovnega poskusa (z omejitvijo), ki modelu posreduje informacijo o napaki za popravek izhoda. Po preseženem številu ponovnih poskusov je potreben načrt za degradacijo ali ročno obravnavo.

4. Arhitekturna raven: Ločitev odgovornosti

   • Odločanje je treba ločiti od izvajanja v trinivojski arhitekturi:
     • Plast modela: Odgovorna le za odločanje (katero orodje poklicati, katere parametre ustvariti).
     • Plast ogrodja: Odgovorna za izvedbeni okvir, vključno s preverjanjem sheme, klicanjem orodij, obravnavo ponovnih poskusov in združevanjem rezultatov. To zagotavlja, da napake modela ne vplivajo neposredno na varnost orodij in da spremembe orodij ne zahtevajo pogostega prilagajanja pozivov.
     • Plast orodij: Konkretna implementacija poslovnih zmogljivosti.
   • Ogrodja, kot sta LangChain in LlamaIndex, prav to počnejo.

Omejitve trenutne rešitve: Dobro obravnava obliko parametrov, vendar še vedno ne pokriva dovolj semantike parametrov (npr. enakovrednost "Šanghaj" in "沪"). To bo inženirski izziv v prihodnosti.

Ključni zaključek: Zanesljivo klicanje orodij s strani LLM je v bistvu problem programskega inženirstva, ki zahteva sistematično inženirsko rešitev od mehkih omejitev, trdih omejitev, izvedbenih varnostnih ukrepov do arhitekturne zasnove, ne pa le optimizacijo pozivov.