AI interviu klausimas #2: Kaip užtikrinti, kad didelio kalbos modelio (LLM) įrankių iškvietimas būtų patikimas

Kaip užtikrinti, kad didelis kalbos modelis (LLM) įrankių iškvietimo metu veiktų patikimai ir kontroliuojamai, o ne tik pasikliautų raginimais, kad „įtikintų“ modelį? Reikia sistemingai pateikti kelių lygių apribojimų sistemą.

Pavyzdžiui, orų paieškos atveju modelis dažnai atlieka tris „prasimanymo“ veiksmus:
1. Neiškviečia įrankio, o tiesiog sugalvoja atsakymą.
2. Iškviečia įrankį su neteisingo formato parametrais (pvz., įrankis nepalaiko „poryt“, bet perduodamas parametras date="poryt").
3. Savavališkai konvertuoja parametrų formatą (pvz., savavališkai paverčia „poryt“ į konkrečią datą), net jei įrankis to nereikalauja.

Problemos šaknis yra ta, kad modelio išvestis iš esmės yra tikimybinė, o raginimai tik taiko „minkštus apribojimus“ tikimybių skirstiniui, o ne užtikrina, kad modelis griežtai jų laikytųsi. Sudėtingose situacijose šie „minkšti apribojimai“ lengvai sugenda.

Siekiant išspręsti šią problemą, reikia kelių lygių inžinerinio sprendimo:

1. Pirmas lygis: raginimų optimizavimas (minkšti apribojimai)

   • Tai yra apribojimų sistemos pradžios taškas, bet jokiu būdu ne pabaiga.
   • Raginimai turėtų būti traktuojami kaip „operacijų sutartis“, aiškiai nurodanti įrankio paskirtį, kiekvieno parametro tipą, ribas ir pateikianti neteisingų reikšmių pavyzdžius.
   • Reikėtų įtraukti „Few-shot“ pavyzdžius, rodančius „teisingas įvestis → teisingas iškvietimas“ pavyzdžius, naudojant kontekstinį mokymąsi modelio elgsenai užfiksuoti.

2. Antras lygis: JSON Schema įvedimas (kieti apribojimai)

   • Tai yra esminis žingsnis nuo „įtikinėjimo“ prie „užtvarų statymo“.
   • Natūralios kalbos parametrų aprašymus pakeiskite mašininio skaitymo, patikrinamais struktūriniais apibrėžimais (JSON Schema). Galima griežtai apibrėžti laukų tipus, ar jie privalomi, leistinų reikšmių diapazoną, ir nustatyti additionalProperties: false, kad modelis neišvestų jokių neapibrėžtų laukų.
   • Pagrindinės API platformos palaiko tokius struktūrinius išvesties apribojimus modelio dekodavimo etape, taip išvengiant formato pažeidimų jau generavimo šaltinyje.

3. Trečias lygis: patikros, taisymo ir bandymo iš naujo ciklo sukūrimas (vykdymo apsauga)

   • Net ir turint Schema, vis tiek reikia atlikti sintaksės ir Schema patikrą gavus modelio išvestį.
   • Jei patikra nepavyksta, reikia suprojektuoti automatinį valymo ir bandymo iš naujo mechanizmą (su viršutine riba), pateikiant klaidos informaciją modeliui, kad jis pataisytų išvestį. Viršijus bandymų skaičių, reikia numatyti sumažintą veikimo lygį arba žmogaus įsikišimą.

4. Architektūros lygis: atsakomybių atskyrimas

   • Reikėtų atskirti sprendimų priėmimą nuo vykdymo, sukuriant trijų lygių architektūrą:
     • Modelio lygis: atsakingas tik už sprendimų priėmimą (nusprendžia, kurį įrankį iškviesti, kokius parametrus sugeneruoti).
     • Sistemos lygis: atsakingas už vykdymo sistemą, įskaitant Schema patikrą, įrankio iškvietimą, bandymų iš naujo tvarkymą ir rezultatų integravimą. Tai užtikrina, kad modelio klaidos tiesiogiai nepaveiktų įrankio saugumo, o įrankio pakeitimams nereikėtų dažnai koreguoti raginimų.
     • Įrankio lygis: konkreti verslo logikos realizacija.
   • LangChain, LlamaIndex ir kitos sistemos būtent tai ir daro.

Dabartinio sprendimo ribotumas: jis gerai tvarko parametrų formato problemas, tačiau parametrų semantikos (pvz., „Šanchajus“ ir „Hu“ atitikmuo) patikra vis dar nepakankama. Tai bus ateities inžinerinis iššūkis.

Pagrindinė išvada: užtikrinti, kad LLM patikimai iškviestų įrankius, iš esmės yra programinės įrangos inžinerijos problema, reikalaujanti sukurti sistemingą inžinerinį sprendimą nuo minkštų apribojimų, kietų apribojimų, vykdymo apsaugos iki architektūros dizaino, o ne tik pasikliauti raginimų optimizavimu.