AI otázka na pohovor č. 2: Ako zabezpečiť spoľahlivé volanie nástrojov veľkým jazykovým modelom (LLM)

Ako zabezpečiť, aby veľký jazykový model (LLM) pri volaní nástrojov fungoval spoľahlivo a kontrolovateľne, a nie len spoliehať na výzvy na „presvedčenie“ modelu. Je potrebné systematicky poskytnúť viacúrovňový rámec obmedzení.

Ako príklad uvedieme vyhľadávanie počasia, kde model pri volaní nástrojov často vykazuje tri typy „vymýšľania“:
1. Nevolať nástroj a priamo vymyslieť odpoveď.
2. Pri volaní nástroja odovzdať parametre v nesprávnom formáte (napr. nástroj nepodporuje „pozajtra“, ale parameter je date="pozajtra").
3. Svojvoľne konvertovať formát parametrov (napr. svojvoľne previesť „pozajtra“ na konkrétny dátum), aj keď to nástroj nevyžaduje.

Koreň problému spočíva v tom, že výstup modelu je v podstate pravdepodobnostný a výzvy sú len „mäkké obmedzenia“ na rozdelenie pravdepodobnosti, nie mechanizmus, ktorý by zabezpečil prísne dodržiavanie modelu. V zložitých scenároch tieto „mäkké obmedzenia“ ľahko zlyhávajú.

Na vyriešenie tohto problému je potrebné viacúrovňové inžinierske riešenie:

1. Prvá vrstva: Optimalizácia výziev (mäkké obmedzenia)

   • Je to východiskový bod systému obmedzení, ale rozhodne nie koniec.
   • Výzvy by sa mali považovať za „operačnú zmluvu“, ktorá jasne vysvetľuje účel nástroja, typ každého parametra, hranice a uvádza príklady neplatných hodnôt.
   • Mali by sa pridať príklady s niekoľkými ukážkami (Few-shot), ktoré ukazujú príklady „správny vstup → správne volanie“, čím sa pomocou kontextového učenia ukotví správanie modelu.

2. Druhá vrstva: Zavedenie JSON Schema (tvrdé obmedzenia)

   • Toto je kľúčový krok od „presviedčania“ k „nastaveniu zábradlí“.
   • Nahraďte prirodzený jazyk na opis parametrov strojovo čitateľnou a overiteľnou štruktúrovanou definíciou (JSON Schema). Môže prísne definovať typy polí, povinnosť, rozsah hodnôt výpočtu a zakázať modelu výstup akýchkoľvek nedefinovaných polí nastavením additionalProperties: false.
   • Hlavné API platformy podporujú takéto štruktúrované obmedzenia výstupu už počas dekódovania modelu, čím sa predchádza porušeniu formátu pri zdroji generovania.

3. Tretia vrstva: Vytvorenie slučky overenia, opravy a opakovania (záchranná sieť)

   • Aj so Schema je potrebné po získaní výstupu modelu vykonať syntaktické overenie a overenie Schema.
   • Pri zlyhaní overenia by sa mal navrhnúť automatický mechanizmus čistenia a opakovania (s horným limitom), ktorý vráti chybové informácie modelu na opravu výstupu. Po prekročení počtu opakovaní je potrebný plán zníženia úrovne alebo manuálneho spracovania.

4. Architektonická úroveň: Oddelenie zodpovedností

   • Malo by sa oddeliť rozhodovanie od vykonávania, čím vznikne trojvrstvová architektúra:
     • Vrstva modelu: Zodpovedá len za rozhodovanie (posúdenie, ktorý nástroj volať, aké parametre generovať).
     • Vrstva rámca: Zodpovedá za vykonávací rámec vrátane overenia Schema, volania nástrojov, spracovania opakovaní a integrácie výsledkov. To zaisťuje, že chyby modelu priamo neovplyvnia bezpečnosť nástrojov a zmeny nástrojov nevyžadujú časté úpravy výziev.
     • Vrstva nástrojov: Konkrétna implementácia obchodných schopností.
   • Rámce ako LangChain, LlamaIndex robia presne túto prácu.

Obmedzenia súčasného riešenia: Dobre zvláda formát parametrov, ale pokrytie overenia sémantiky parametrov (napr. ekvivalencia „Šanghaj“ a „Hu“) je stále nedostatočné. To bude inžinierska výzva do budúcnosti.

Hlavný záver: Zabezpečiť, aby LLM spoľahlivo volal nástroje, je v podstate softvérovo-inžiniersky problém, ktorý si vyžaduje systematické inžinierske riešenie od mäkkých obmedzení, tvrdých obmedzení, záchrannej siete až po architektonický návrh, a nie len spoliehanie sa na optimalizáciu výziev.