AI pitanje za intervju 2: Kako osigurati pouzdano pozivanje alata od strane velikog jezičnog modela (LLM)

Kako osigurati da veliki jezični model (LLM) pri pozivanju alata radi pouzdano i kontrolirano, a ne samo oslanjajući se na upute (prompts) da "uvjeri" model. Potrebno je sustavno dati višerazinski okvir ograničenja.

Primjer s provjerom vremena, tri uobičajene "izmišljene" radnje modela pri pozivanju alata:
1. Ne poziva alat, izravno izmišlja odgovor.
2. Pri pozivanju alata prosljeđuje parametre u pogrešnom formatu (npr. alat ne podržava "prekosutra", ali prosljeđuje parametar date="prekosutra").
3. Samovoljno pretvara format parametara (npr. samovoljno pretvara "prekosutra" u konkretan datum), iako alat to ne zahtijeva.

Korijen problema je u tome što je izlaz modela u osnovi probabilistički, a upute samo nameću "meko ograničenje" na distribuciju vjerojatnosti, a ne prisilni mehanizam koji osigurava strogo poštivanje modela. U složenim scenarijima, ovo "meko ograničenje" lako može zakazati.

Kako bi se riješio ovaj problem, potrebno je višerazinsko inženjersko rješenje:

1. Prva razina: Optimizacija uputa (meko ograničenje)

   • Pozicioniranje je početna točka sustava ograničenja, ali nikako krajnja.
   • Upute treba tretirati kao "operativni ugovor", jasno objašnjavajući svrhu alata, tip svakog parametra, granice, te navodeći primjere nevažećih vrijednosti.
   • Treba dodati Few-shot primjere, prikazujući primjere "ispravan unos → ispravan poziv", koristeći kontekstualno učenje za učvršćivanje obrasca ponašanja modela.

2. Druga razina: Uvođenje JSON Sheme (čvrsto ograničenje)

   • Ovo je ključni korak od "objašnjavanja" do "postavljanja ograda".
   • Zamijeniti prirodnojezične opise parametara strojno čitljivom, provjerljivom strukturiranom definicijom (JSON Schema). Može se strogo definirati tip polja, obveznost, raspon dopuštenih vrijednosti, te postavljanjem additionalProperties: false zabraniti modelu ispis bilo kojeg nedefiniranog polja.
   • Glavne API platforme podržavaju ovakvo strukturirano ograničenje izlaza već u fazi dekodiranja modela, čime se izbjegavaju povrede formata na samom izvoru generiranja.

3. Treća razina: Uspostava petlje provjere-popravka-ponovnog pokušaja (izvršna sigurnosna mreža)

   • Čak i uz Shemu, potrebno je nakon dobivanja izlaza modela provesti sintaksnu i Schema provjeru.
   • Kada provjera ne uspije, treba dizajnirati automatsko čišćenje i mehanizam ponovnog pokušaja (s gornjom granicom), vraćajući informaciju o pogrešci modelu kako bi ispravio izlaz. Nakon prekoračenja broja ponovnih pokušaja, potrebno je imati plan degradacije ili ručne obrade.

4. Arhitektonska razina: Razdvajanje odgovornosti

   • Potrebno je razdvojiti odlučivanje i izvršavanje, formirajući troslojnu arhitekturu:
     • Sloj modela: Odgovoran samo za odlučivanje (odlučivanje koji alat pozvati, koje parametre generirati).
     • Okvirni sloj: Odgovoran za izvršni okvir, uključujući Schema provjeru, pozivanje alata, obradu ponovnih pokušaja i integraciju rezultata. Ovo osigurava da pogreške modela ne utječu izravno na sigurnost alata, a promjene alata ne zahtijevaju često prilagođavanje uputa.
     • Sloj alata: Implementacija specifičnih poslovnih mogućnosti.
   • Okviri poput LangChain, LlamaIndex upravo rade takav posao.

Ograničenja trenutnog rješenja: Dobro obrađuje format parametara, ali pokrivenost provjere semantike parametara (npr. ekvivalentnost "Šangaj" i "沪") još uvijek je nedovoljna. Ovo će biti inženjerski izazov u budućnosti.

Ključni zaključak: Pouzdano pozivanje alata od strane LLM-a u osnovi je problem softverskog inženjerstva, koji zahtijeva uspostavu sustavnog inženjerskog rješenja od mekih ograničenja, čvrstih ograničenja, izvršne sigurnosne mreže do arhitektonskog dizajna, a ne samo oslanjanje na optimizaciju uputa.