AI Otázka č. 2: Jak zajistit spolehlivé volání nástrojů velkým jazykovým modelem (LLM)

Jak zajistit, aby velký jazykový model (LLM) při volání nástrojů pracoval spolehlivě a kontrolovatelně, nejen spoléhat na prompt, který model „přesvědčuje“. Je třeba systematicky poskytnout víceúrovňový rámec omezení.

Například příklad dotazu na počasí, tři běžné „vymyšlené“ chování modelu při volání nástrojů:
1. Nevolat nástroj a rovnou vymyslet odpověď.
2. Při volání nástroje předat parametry s chybným formátem (např. nástroj nepodporuje „pozítří“, ale předá se parametr date="pozítří").
3. Svévolně převádět formát parametrů (např. neoprávněně převést „pozítří“ na konkrétní datum), i když to nástroj nevyžaduje.

Kořen problému spočívá v tom, že výstup modelu je v podstatě pravděpodobnostní, prompt pouze ukládá „měkké omezení“ na rozdělení pravděpodobnosti, nikoli vynucovací mechanismus, který by model přísně dodržoval. Ve složitých scénářích toto „měkké omezení“ snadno selže.

K vyřešení tohoto problému je zapotřebí víceúrovňové inženýrské řešení:

1. První vrstva: Optimalizace promptu (měkké omezení)

   • Je to výchozí bod systému omezení, ale rozhodně ne konečný.
   • Prompt by měl být považován za „operační smlouvu“, jasně popisující účel nástroje, typ každého parametru, hranice a uvádějící příklady neplatných hodnot.
   • Měly by být přidány Few-shot příklady, které ukazují příklady „správný vstup → správné volání“, čímž se pomocí učení z kontextu ukotví vzorce chování modelu.

2. Druhá vrstva: Zavedení JSON Schema (tvrdé omezení)

   • To je klíčový krok od „přesvědčování“ k „nastavení zábradlí“.
   • Použijte strojově čitelnou, ověřitelnou strukturovanou definici (JSON Schema) místo přirozeného jazyka pro popis parametrů. Lze striktně definovat typy polí, povinnost, rozsah výčtových hodnot a pomocí nastavení additionalProperties: false zakázat modelu výstup jakýchkoli nedefinovaných polí.
   • Hlavní API platformy podporují toto strukturované omezení výstupu již ve fázi dekódování modelu, čímž se zabrání porušení formátu u zdroje.

3. Třetí vrstva: Vytvoření smyčky ověření-oprava-opakování (záchranná síť)

   • I se Schema je stále nutné po získání výstupu modelu provést syntaktické a Schema ověření.
   • Při selhání ověření by měl být navržen mechanismus automatického čištění a opakování (s omezením), který modelu poskytne chybovou zprávu k opravě výstupu. Po překročení počtu opakování je třeba mít plán degradace nebo ručního zpracování.

4. Architektonická úroveň: Oddělení odpovědností

   • Mělo by dojít k oddělení rozhodování a provádění, čímž vznikne třívrstvá architektura:
     • Vrstva modelu: Pouze rozhoduje (určuje, který nástroj zavolat, jaké parametry generovat).
     • Vrstva frameworku: Zajišťuje prováděcí rámec, včetně ověření Schema, volání nástroje, zpracování opakování a integrace výsledků. Tím se zajistí, že chyby modelu přímo neovlivní bezpečnost nástroje a změny nástroje nevyžadují časté úpravy promptu.
     • Vrstva nástroje: Konkrétní implementace obchodní logiky.
   • Frameworky jako LangChain, LlamaIndex právě tuto práci vykonávají.

Omezení současného řešení: Dobře řeší problémy s formátem parametrů, ale pokrytí ověření sémantiky parametrů (např. ekvivalence „Šanghaj“ a „Hu“) je stále nedostatečné. To bude inženýrská výzva, které bude třeba čelit v budoucnu.

Hlavní závěr: Zajistit spolehlivé volání nástrojů LLM je v podstatě softwarově-inženýrský problém, který vyžaduje systematické inženýrské řešení od měkkých omezení, tvrdých omezení, záchranné sítě až po architektonický návrh, nikoli pouze spoléhat na optimalizaci promptu.