LLM-First vai Code-First? Missä älykkyys kuuluu tuotantotason AI:ssa

Miten päätetään, mitä mallin tulisi hoitaa, mitä koodisi tulisi hoitaa ja miten ne kaksi yhdistetään.

Muutama vuosi sitten AI-sovelluksen arkkitehtuuri näytti tältä: lähettää kehotus suurelle kielimallille → saada vastaus → näyttää se käyttäjälle. Tämä ei enää ole koko tarina nykypäivänä. Mallien pyydetään tulkitsemaan tarkoitus, hakemaan tietoa, valitsemaan työkaluja, kutsumaan API-rajapintoja, laatimaan suunnitelmia ja suorittamaan monivaiheisia työnkulkuja.

Tuo muutos on jakanut kentän kahteen – LLM-First tai Code-First

LLM-first-arkkitehtuurissa malli on keskeinen ja päättää, mitä seuraavaksi tapahtuu. Se lukee pyynnön, valitsee työkalun, päättää toimintojen järjestyksen, tarkistaa väli­tulokset ja muuttaa suuntaa tarvittaessa.

Code-first-arkkitehtuurissa ohjelmisto/koodi hallitsee edelleen sekvensointia, liiketoimintasääntöjä, validointia, käyttöoikeuksia ja suoritusta. LLM toimii tässä erikoisasiantuntijana, jonka koodi kutsuu, kun tarvitaan kielen ymmärtämistä tai tuottamista.

Ihmiset rakastavat väitellä, kumpi on parempi. Mielestäni se on väärä argumentti. Parempi kysymys on, missä kukin älykkyyden muoto kuuluu. Vahvimmat tuotantojärjestelmät, joita olen nähnyt, harvoin ovat puhtaasti toinen tai toinen. Ne sekoittavat todennäköisyyspohjaista päättelyä deterministiseen hallintaan, ja tekevät sen tahallisesti.

Miksi LLM-First on niin houkutteleva

Perinteinen ohjelmisto toimii erinomaisesti, kun vaatimukset voidaan määritellä tarkasti. Esimerkiksi käyttäjä valitsee tuotteen, syöttää summan ja lähettää maksun. Määrittelet sallitut tilat, validointisäännöt, virhetilanteet ja tapahtumien järjestyksen koodissa. Valmista.

Luonnollinen kieli ei toimi niin. Kuvittele käyttäjän kirjoittavan: “Etsi tapahtumat, jotka vaikuttavat epätavallisilta, selitä mitä tapahtui ja kerro, mitä minun pitäisi tutkia ensin.”

Tälle pyynnölle ei ole kiinteää polkua. Järjestelmän täytyy päättää, mitä “epätavallinen” tarkoittaa, selvittää, mikä data on merkityksellistä, mahdollisesti kutsua useita työkaluja, arvioida vastausta ja kirjoittaa selitys, jota henkilö voi käyttää. Mikään insinööri‑tiimi tai kooditon ratkaisu ei pysty ennakoimaan jokaista ilmaisutapaa ja jokaisen pyynnön yhdistelmää etukäteen.

Tässä LLM:llä on keskeinen rooli, toimien joustavana päättelykerroksena ihmiskielen ja determinististen palveluidesi välillä. Tämä on myös syy siihen, miksi agentteihin kiinnitetään niin paljon huomiota. Google Cloudin agenttinen AI-arkkitehtuuriohjeistus kuvaa agenttia sovelluksena, jossa AI-malli toimii päättelymoottorina, kun taas työkalut antavat sille pääsyn ulkoisiin järjestelmiin ja tietoihin.

Anthropicin Tehokkaiden AI-agenttien rakentaminen ohjeistus tekee erottelun, johon palaan yhä uudelleen. Tässä työnkulku, mallit ja työkalut noudattavat polkuja, jotka koodisi määrittelee. Agentissa agentti, LLM ohjaa omaa prosessiaan ja päättää, miten käyttää työkalujaan. Sama ohjeistus suosittelee aloittamaan yksinkertaisimmalla arkkitehtuurilla, joka ratkaisee ongelman, sen sijaan että lisättäisiin agenttinen monimutkaisuus reaktiivisesti. Korostaisin tätä neuvoa kahdesti.

Mallin päätöksen rajoitukset

Malli voi päättää, mitä pitäisi tapahtua. Päättely ei ole sama kuin säännön täytäntöönpano.

Esimerkiksi otetaan taloudellinen työnkulku. LLM voi olla erinomainen ymmärtämään “lähetä sama summa, jonka lähetin viime kuussa samalle toimittajalle.” Mutta pitäisikö sen myös päättää, onko siirto valtuutettu, laskea sääntelyrajat, tarkistaa tilin omistajuus, ohittaa turvallisuuspolitiikka ja suorittaa tapahtuma?

Todennäköisesti ei. Nämä tehtävät ovat deterministisiä, testattavia, auditoitavia ja toteutettavissa, ja juuri siinä perinteinen ohjelmisto on hyvä. Riski kasvaa, kun malleilla on pääsy työkaluihin. OWASPin generatiivisen AI:n turvallisuusohjeistus merkitsee liiallista toimivaltaa merkittävänä riskinä: LLM-pohjaiselle järjestelmälle annetaan enemmän toiminnallisuutta, käyttöoikeuksia tai autonomiaa kuin sen tehtävä vaatii. Outo tai manipuloitu mallin tuotos on yksi asia, kun se tuottaa tekstiä. Se on paljon suurempi asia, kun malli voi toimia todellisessa maailmassa.

Tämä ei tarkoita, että mallien ei pitäisi koskaan tehdä toimia. Se tarkoittaa, että mallin autonomia tulisi rajoittaa deterministiseen valtaan.

Code-First on edelleen tärkeä

Kun AI kehittyy niin nopeasti, on helppoa tuntea, että perinteinen tekniikka on menettänyt merkityksensä. Väittäisin päinvastoin. AI tekee hyvistä deterministisista järjestelmistä tärkeämpiä, ei vähemmän.

Koodi on edelleen oikea valinta aina kun tehtävä vaatii täsmällistä toistettavuutta. Todennus on yksinkertaisin esimerkki. Mallin ei tulisi “päättää” siitä, onko jollakulla ylläpitäjän oikeudet. Sovelluksesi tulisi kysyä valtuutetulta identiteetti‑ ja pääsynhallintajärjestelmältä. Sama pätee rahalaskelmiin, oikeuksien tarkistuksiin, datan validointiin, sääntelyrajoituksiin, transaktiorajoihin, skeeman validointiin ja kaikkiin peruuttamattomiin toimiin. Näihin tarvitaan eksplisiittisiä sopimuksia, ei arvailuja.

Tämä sopii laajempaan hallintojen ajatteluun. NIST AI Risk Management Framework pyytää organisaatioita hallitsemaan AI‑riskiä suunnittelun, kehittämisen, käyttöönoton ja käytön aikana. Sen kumppani Generative AI Profile lisää, että generatiiviset järjestelmät saattavat tarvita lisävalvontaa, dokumentaatiota, tarkastelua ja kontrollia riippuen riskin tasosta.

Siksi pidän hyödyllisenä jakaa jokainen suunnittelupäätös kahteen kysymykseen:

Mitä pitäisi tapahtua?

ja

Mitä saa tapahtua?

LLM voi usein auttaa ensimmäisessä. Determinististen järjestelmien tulisi yleensä hoitaa toinen.

Hybridimalli: Perustele todennäköisesti, toteuta deterministisesti

Useimmissa yrityssovelluksissa käytännöllinen vastaus on hybridi. LLM toimii tulkinta‑ ja päättelykerroksena. Deterministiset palvelut toimivat toteutus‑ ja valvontakerroksena.

Tässä esimerkki. Kuvitellaan, että AI‑avustaja auttaa kehittäjiä luomaan tilapäisiä API‑testausympäristöjä, ja kehittäjä kirjoittaa: “Anna minulle hiekkalaatikko asiakasrekisteröintityönkululle.”

LLM voi tulkita sen, selvittää, mikä työnkulku todennäköisesti on tarkoitettu, lukea dokumentaation ja ehdottaa, mitkä API:t todennäköisesti ovat relevantteja. Mutta itse ympäristön luomisen ei pitäisi perustua vapaamuotoiseen generoituihin tekstiin. Koodi voi vahvistaa, että pyydetyt API:t ovat olemassa, tarkistaa niiden sopimukset, tarkistaa valtuutuksen, valvoa resurssirajoja, luoda hyväksytyn konfiguraation ja suorittaa käyttöönoton.

Karkeasti jako näyttää tältä:

• LLM: ymmärtää, päättää, luokittelee, ehdottaa, tiivistää.
• Koodi: validoi, valtuuttaa, laskee, tallentaa, valvoo, suorittaa.

Kumpikin puoli tekee sitä työtä, jossa se on paras, eikä kumpaankaan pyydetä jäljittelemään toisen vahvuuksia.

Rajojen merkitys kasvaa, kun agentit vahvistuvat

Tämä erottelu korostuu siirryttäessä avustajista agenteihin. Avustaja, joka antaa huonon vastauksen, aiheuttaa vain häiriötä. Agentti, jolla on kirjoitusoikeus tuotantoon, voi aiheuttaa paljon suuremman sotkun.

Korjaus ei välttämättä ole poistaa autonomiaa. Se on lisätä autonomiaa vähitellen pitäen eksplisiittiset ohjauspisteet paikallaan. Googlein ohjeistus moniajajärjestelmiin suositellaan yhdistämään dynaaminen AI-toiminta deterministisiin turvallisuusohjaimiin, havaittavuuteen, selkeästi määriteltyyn autonomiaan ja ihmisen valvontaan liiketoimintakriittisissä tilanteissa.

Ihmisen hyväksyntä voidaan myös sisällyttää itse työnkulkuun sen sijaan, että se olisi epävirallinen turvaverkko. Microsoft’s agent framework documentation esimerkiksi tukee työkalukutsuja, jotka pysähtyvät, kunnes henkilö hyväksyy pyydetyn toiminnon nimenomaisesti.

Periaate on yksinkertainen: mitä suuremmat toimenpiteen seuraukset, sitä vahvempia determinististen kontrollien tulisi olla.

Viisi kysymystä ennen tehtävän antamista LLM:lle

Kun päätän, pitäisikö komponentin olla LLM‑ensimmäinen vai koodi‑ensimmäinen, käyn läpi nämä:

1. Onko tehtävällä yksi objektiivisesti oikea vastaus? Jos on, suosi determinististä koodia. Verolaskelmat, oikeudet ja skeeman validointi eivät saisi muuttua, koska malli lukee ne tänään eri tavalla.
2. Sisältääkö se epäselvää kieltä tai jäsentämätöntä tietoa? Jos on, LLM voi tuoda todellista lisäarvoa.
3. Mitä tapahtuu, jos malli tekee virheen? Oikea arkkitehtuuri kokouksen yhteenvedolle on hyvin erilainen kuin oikea arkkitehtuuri maksun käynnistämiselle.
4. Voiko tuloksen validoida itsenäisesti? LLM:n tuottamat suunnitelmat ovat paljon turvallisempia, kun deterministiset säännöt voivat tarkistaa tuloksena olevan toiminnon ennen sen suorittamista.
5. Tarvitseeko tämä todella agenttia? Jos tiedät jo vaiheet, tavallinen työnkulku muutamalla kohdennetulla LLM‑kutsulla on yleensä yksinkertaisempi, halvempi, helpompi testata ja helpompi ylläpitää.

Viimeinen kysymys ansaitsee erityishuomiota. Agentit ovat voimakkaita juuri siksi, että ne voivat käsitellä tilanteita, joissa et voi ennustaa jokaista askelta. Mutta jos voit ennustaa askeleet, niiden muuttaminen avoimeksi päättelyongelmaksi lisää usein vaihtelua ilman että se lisää älykkyyttä.

Luotettavuus on arkkitehtoninen ominaisuus, ei kehotus

Monet tiimit alkavat pyrkimään parantamaan luotettavuutta lähes kokonaan kehotteiden suunnittelun avulla. Kehotteet ovat tärkeitä, mutta ne eivät voi kantaa koko kuormaa.

Tuotantojärjestelmän tulisi olettaa, että mallin tuloste on joskus puutteellinen, virheellinen, odottamaton tai vain väärä. OWASP Top 10 LLM-sovelluksille luettelee riskejä kuten prompt injection ja improper output handling, mikä vahvistaa keskeisen tavan: käsitellä mallin tuloste luottamattomana syötteenä alijärjestelmiin, ei automaattisesti suoritettavina ohjeina.

Tämä muuttaa esittämääsi kysymystä. Sen sijaan, että kysyisit “Kuinka kirjoitan kehotteen, joka aina saa mallin noudattamaan sääntöä?”, kysy “Kuinka suunnittelen järjestelmän niin, että sääntöä ei voida rikkoa, vaikka malli tekisi virheen?”

Tämä on ohjelmistoarkkitehtuuriongelma, ei kehotteiden ongelma. Kehote voi kertoa agentille, ettei suorita valtuuttamatonta toimintaa. Valtuutuspalvelu voi itse estää sen. Nämä kaksi hallintaa eivät ole ekvivalentteja.

Keskustelun Ylittäen: Intent-First-järjestelmät

Kun mietin tätä kaikkea, olen tullut siihen uskoon, että LLM-first- ja code-first-keskustelu osoittaa kolmannen ajatuksen suuntaan: intent-first arkkitehtuuri.

Intent-first-järjestelmässä sovellus alkaa ymmärtämällä, mitä käyttäjä yrittää saavuttaa. Siellä LLM on arvokkainta, koska ihmiset harvoin ilmaisevat tarkasti, mitä he haluavat. Sieltä järjestelmä muuntaa vähitellen tämän epätarkkuuden strukturoituiksi, deterministisiksi toiminnoiksi.

Pyyntö kuten “Auta minua ratkaisemaan asiakkaan maksuprobleema” voi muuttua putkeksi: ymmärrä intentio, hae tapahtuma, tunnista vian syy, suosittele korjausta, pyydä hyväksyntä, suorita hyväksytty toimenpide.

Jotkut näistä vaiheista hyötyvät kielimallin päättelystä. Toisten tulisi olla kiinteitä palveluita. Arkkitehtuuri ei määrittynyt sen perusteella, kumpi – tekoäly vai koodi – “voittaa”. Se määrittyy sen perusteella, missä epävarmuus on hyväksyttävää.

Yhteenveto

Kun mallit kehittyvät, houkutus antaa niille hallinta yhä suuremmista osista järjestelmää kasvaa. Joskus se on oikea valinta. Toisissa järjestelmissä kaikkein hienostunein suunnittelu on se, joka tarkoituksellisesti antaa mallille vähemmän valtuuksia.

Tuotannon AI-tekniikka lopulta tarkoittaa älyn sijoittamista oikeaan rajapintaan. Käytä kielimalleja siellä, missä tulkinta, päättely, synteesi ja mukautuminen tuottavat arvoa. Käytä determinististä ohjelmistoa siellä, missä johdonmukaisuus, valtuutus, tarkkuus ja täytäntöönpano ovat tärkeitä. Yhdistä sitten kaksi kapeiden, havaittavien ja hyvin testattujen rajapintojen kautta.

Yritysten AI:n tulevaisuus ei todennäköisesti ole puhtaasti LLM-first tai puhtaasti code-first. Se on LLM, jossa epävarmuus vaatii älyä, ja koodi, jossa varmuus vaatii hallintaa.

Tämä ero voi olla merkittävämpi kuin se, mitä mallia valitset.