AI-haastattelukysymys 2: Kuinka varmistaa, että suuri kielimalli (LLM) kutsuu työkaluja luotettavasti

Kuinka varmistaa, että suuri kielimalli (LLM) toimii luotettavasti ja hallitusti työkaluja kutsuttaessa, eikä pelkästään luota kehotteisiin mallin "suostuttelemiseksi". Tarvitaan systemaattinen monitasoinen rajoituskehys.

Esimerkkinä sään kysely: mallin kolme yleistä "keksimiskäyttäytymistä" työkalujen kutsussa:
1. Ei kutsu työkalua, vaan keksii vastauksen suoraan.
2. Kutsuu työkalua väärän muotoisilla parametreilla (esim. työkalu ei tue "ylihuomista", mutta välittää parametrin date="ylihuominen").
3. Muuntaa parametrien muotoa omavaltaisesti (esim. muuntaa "ylihuominen" tarkaksi päivämääräksi), vaikka työkalu ei sitä vaadi.

Ongelman juuri on, että mallin tuotos on luonteeltaan todennäköisyyspohjaista, ja kehotteet asettavat vain "pehmeitä rajoitteita" todennäköisyysjakaumaan, eivät pakottavia mekanismeja, jotka varmistaisivat mallin tiukan noudattamisen. Monimutkaisissa skenaarioissa nämä "pehmeät rajoitteet" pettävät helposti.

Tämän ratkaisemiseksi tarvitaan monitasoinen tekninen ratkaisu:

1. Ensimmäinen taso: Kehotteiden optimointi (pehmeät rajoitteet)

   • Sijoitetaan rajoituskehyksen lähtöpisteeksi, mutta ei suinkaan päätepisteeksi.
   • Kehotetta tulisi käsitellä "toimintasopimuksena", jossa selkeästi kuvataan työkalun käyttötarkoitus, kunkin parametrin tyyppi, rajat ja luetellaan esimerkkejä virheellisistä arvoista.
   • Tulisi lisätä Few-shot-esimerkkejä, jotka näyttämällä "oikea syöte → oikea kutsu" -esimerkkejä ankkuroivat mallin käyttäytymismallin kontekstioppimisen avulla.

2. Toinen taso: JSON Schema -käyttöönotto (kovat rajoitteet)

   • Tämä on keskeinen askel "järkeilystä" "kaiteiden asettamiseen".
   • Korvataan luonnollisen kielen parametrikuvaukset koneellisesti luettavalla ja todennettavalla rakenteellisella määritelmällä (JSON Schema). Voidaan tiukasti määritellä kenttien tyypit, pakollisuus, sallitut arvot, ja estää mallia tuottamasta mitään määrittelemättömiä kenttiä asettamalla additionalProperties: false.
   • Suositut API-alustat tukevat tällaista rakenteellista tuotosrajoitusta jo mallin dekoodausvaiheessa, estäen muotovirheet jo syntyvaiheessa.

3. Kolmas taso: Tarkistus-korjaus-uudelleenyritys-silmukka (suorituksen varasuunnitelma)

   • Vaikka Schema olisi käytössä, on silti suoritettava syntaksi- ja Schema-tarkistus mallin tuotoksen saamisen jälkeen.
   • Jos tarkistus epäonnistuu, tulisi suunnitella automaattinen puhdistus- ja uudelleenyritysmekanismi (ylärajalla), joka palauttaa virheinformation mallille tuotoksen korjaamiseksi. Jos uudelleenyritysten määrä ylittyy, tarvitaan alasajo- tai manuaalinen käsittelysuunnitelma.

4. Arkkitehtuuritaso: Vastuiden erottelu

   • Päätöksenteko ja suoritus tulisi erottaa, muodostaen kolmitasoisen arkkitehtuurin:
     • Mallitaso: Vastaa vain päätöksenteosta (päättää, mitä työkalua kutsua ja mitkä parametrit luoda).
     • Kehystaso: Vastaa suorituskehyksestä, mukaan lukien Schema-tarkistus, työkalun kutsuminen, uudelleenyritysten käsittely ja tulosten yhdistäminen. Tämä varmistaa, että mallin virheet eivät suoraan vaikuta työkalun turvallisuuteen, eikä työkalun muutokset vaadi kehotteiden toistuvaa säätämistä.
     • Työkalutaso: Konkreettinen liiketoimintakyvykkyyden toteutus.
   • LangChain, LlamaIndex jne. -kehykset tekevät juuri tällaista työtä.

Nykyisen ratkaisun rajoitukset: Se käsittelee hyvin parametrien muotoa koskevia ongelmia, mutta parametrien semantiikan (esim. "Shanghai" ja "Hu" -vastaavuus) tarkistus on edelleen riittämätöntä. Tämä on tulevaisuuden tekninen haaste.

Keskeinen johtopäätös: LLM:n luotettava työkalujen kutsuminen on pohjimmiltaan ohjelmistotekninen ongelma, joka vaatii systemaattisen teknisen ratkaisun, joka ulottuu pehmeistä rajoitteista, koviin rajoitteisiin, suorituksen varasuunnitelmaan ja arkkitehtuurisuunnitteluun, eikä pelkästään kehotteiden optimointiin.