Yritysten LLM-käyttötapauksissa kolme arkkitehtuurivaihtoehtoa toistuvat: retrieval-augmented generation (RAG), fine-tuning ja autonomiset agentit. Suurin osa virheellisistä päätöksistä syntyy siitä, että nämä kolme yritetään valita teknologiasyistä eikä käyttötapauksen vaatimuksista käsin.
RAG sopii käyttötapauksiin, joissa tieto muuttuu jatkuvasti ja sen täytyy olla aina tuore: tuotedokumentaatio, asiakasohjeet, sopimustiedot, sisäinen knowledge base. Mallia ei kouluteta tiedolla — se hakee sen runtimessa. RAG:n edut ovat ilmeisiä: matala marginaalikustannus per päivitys, hyvä jäljitettävyys (voidaan kertoa lähde), ei vaatimuksia mallin omistajuudelle. Heikkoudet liittyvät hakuvaiheen laatuun: jos retrieval on huono, generaatio on huono.
Fine-tuning sopii käyttötapauksiin, joissa malli tarvitsee syvää erikoistumista: yrityskohtainen kirjoitustyyli, harvinaiset domain-termit, hyvin spesifit luokittelutehtävät tai output-rakenne, jota prompttaaminen ei pysty luotettavasti tuottamaan. Fine-tuningin heikkoudet ovat operatiiviset: vaatii koulutusdataa (usein satoja tai tuhansia esimerkkejä), mallin uudelleenkoulutuksen syklin, monitoroinnin ja governance-päätöksen siitä, mihin koulutusdataa saa käyttää.
Agentit ovat oikea valinta, kun tehtävä vaatii useita peräkkäisiä päätöksiä, ulkoisia työkalukutsuja ja mukautumista välituloksiin. Esimerkkejä: monivaiheinen asiakaspyynnön käsittely, jossa luetaan tilatieto, päivitetään se ja kirjataan tapahtuma; tai tutkimusagentti, joka iteroi kyselyitä. Agentit ovat myös vaarallisin valinta: huonosti suunniteltu agentti voi tehdä peruuttamattomia ulkoisia toimia (lähettää sähköposteja, päivittää järjestelmiä, hyväksyä maksuja). Hyvä agenttialusta vaatii guardrails-konfiguraation, HITL-ohjauksen ja audit-jäljen jokaisesta päätöksestä.
Yritystason ratkaisu on usein hybridi. Esimerkki: asiakaspalvelun copilot käyttää RAG:ia tietopohjan hakuun, fine-tuned mallia yrityksen sävyn säilyttämiseen vastauksissa, ja agenttirunkoa toimintojen suorittamiseen järjestelmissä. Tämä on syy, miksi LLM-arkkitehtuuria ei voi valita yhdellä päätöksellä. Käyttötapauskohtainen analyysi on tehtävä jokaiselle.
AI-Koutsi käyttää neliosaista valintamallia per käyttötapaus: (1) tarvitseeko ratkaisu tuoreinta tietoa runtimessa? (RAG), (2) tarvitseeko se erityistä tyyliä tai rakennetta? (fine-tuning), (3) tarvitseeko se tehdä peräkkäisiä päätöksiä? (agentti), (4) onko siinä peruuttamattomia ulkoisia toimia? (vaaditaan kova guardrail). Nämä neljä kysymystä leikkaavat 95 % vääristä arkkitehtuurivalinnoista pois.