AI intervju pitanje 2: Kako osigurati pouzdanost pozivanja alata od strane velikog jezičkog modela (LLM)

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

Na primjeru provjere vremena, tri uobičajena "izmišljanja" modela pri pozivanju alata:
1. Ne poziva alat, direktno izmišlja odgovor.
2. Pri pozivanju alata prosljeđuje parametre s pogrešnim formatom (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 leži u činjenici da je izlaz modela suštinski probabilistički, a upute su samo "meko ograničenje" na distribuciji vjerovatnoće, a ne mehanizam koji osigurava striktno poštivanje modela. U složenim scenarijima, ovo "meko ograničenje" lako može zakazati.

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

1. Prvi sloj: Optimizacija uputa (meko ograničenje)

   • Pozicioniranje je početna tačka sistema ograničenja, ali nikako krajnja.
   • Upute treba tretirati kao "operativni ugovor", jasno navodeći svrhu alata, tip svakog parametra, granice, te navesti primjere nevažećih vrijednosti.
   • Treba dodati Few-shot primjere, prikazujući primjere "ispravan unos → ispravan poziv", koristeći kontekstualno učenje da se usidri obrazac ponašanja modela.

2. Drugi sloj: Uvođenje JSON Sheme (čvrsto ograničenje)

   • Ovo je ključni korak od "objašnjavanja" do "postavljanja ograda".
   • Zamijeniti opis parametara prirodnim jezikom sa strojno čitljivom, provjerljivom strukturiranom definicijom (JSON Schema). Može se striktno definirati tip polja, obaveznost, raspon enumeracija, te postavljanjem additionalProperties: false zabraniti modelu da izbacuje bilo koja nedefinirana polja.
   • Glavne API platforme podržavaju ovakva strukturirana ograničenja izlaza u fazi dekodiranja modela, izbjegavajući kršenje formata na izvoru generisanja.

3. Treći sloj: Uspostavljanje petlje validacije-popravke-pokušaja (izvršna sigurnosna mreža)

   • Čak i sa Shemom, potrebno je nakon dobijanja izlaza modela izvršiti sintaksnu i Schema validaciju.
   • Kada validacija ne uspije, treba dizajnirati automatsko čišćenje i mehanizam ponovnog pokušaja (sa gornjom granicom), vraćajući informaciju o grešci modelu da ispravi izlaz. Nakon prekoračenja broja pokušaja, potrebno je imati plan degradacije ili ručne obrade.

4. Arhitektonski nivo: Razdvajanje odgovornosti

   • Treba razdvojiti odlučivanje i izvršenje, formirajući troslojnu arhitekturu:
     • Sloj modela: Odgovoran samo za odlučivanje (prosuditi koji alat pozvati, koje parametre generisati).
     • Okvirni sloj: Odgovoran za izvršni okvir, uključujući Schema validaciju, pozivanje alata, rukovanje ponovnim pokušajima i integraciju rezultata. Ovo osigurava da greške modela ne utiču direktno na sigurnost alata, a promjene alata ne zahtijevaju često prilagođavanje uputa.
     • Sloj alata: Implementacija specifičnih poslovnih mogućnosti.
   • Okviri poput LangChain, LlamaIndex rade upravo ovaj posao.

Ograničenja trenutnog rješenja: Dobro rješava problem formata parametara, ali pokrivenost validacije semantike parametara (npr. ekvivalentnost "Šangaj" i "Hu") je još uvijek nedovoljna. Ovo će biti inženjerski izazov u budućnosti.

Ključni zaključak: Pouzdano pozivanje alata od strane LLM-a suštinski je softversko-inženjerski problem, koji zahtijeva uspostavljanje sistematskog 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.