LLM-pohjaiset ratkaisut: RAG vs. fine-tuning vs. agentit

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 — retrieval-augmented generation

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 — mallin hienosäätö

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 — autonomia ja toimintakyky

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ä.

Päätöstaulukko: kehotteet, RAG, fine-tuning vai agentti?

Neljä vaihtoehtoa kannattaa asettaa rinnakkain samoilla kriteereillä. Aloita aina kevyimmästä: hyvin suunniteltu kehote (prompt engineering) ratkaisee yllättävän suuren osan käyttötapauksista ilman uutta infrastruktuuria. Kriteeri | Kehote | RAG | Fine-tuning | Agentti. Käyttöönoton kesto | Päiviä | 2–6 viikkoa | 4–12 viikkoa | 6–16 viikkoa. Datavaatimus | Ei mitään | Dokumentit ja hakemisto | Sadat–tuhannet esimerkit | Työkalut ja rajapinnat. Tuore tieto runtimessa | Ei | Kyllä | Ei | Kyllä haun kautta. Lähteiden jäljitettävyys | Heikko | Vahva | Heikko | Riippuu suunnittelusta. Tyylin ja rakenteen hallinta | Kohtalainen | Kohtalainen | Vahva | Peritään pohjamallista. Monivaiheinen päättely ja toiminta | Ei | Ei | Ei | Kyllä. Ylläpitokuorma | Matala | Keskitaso (hakulaatu) | Korkea (uudelleenkoulutus) | Korkein (valvonta ja rajat). Governance-vaatimus | Kehoteversiointi | Käyttöoikeudet ja lähteet | Koulutusdatan käyttöoikeus | Rajoitteet, HITL, audit. Tyypillinen käyttötapaus | Tiivistelmät, luonnokset | Tukikeskus, sopimushaku | Luokittelu, yrityssävy | Prosessin läpivienti.

Kustannus- ja riskinäkökulma

Kokonaiskustannus ei synny mallikutsuista vaan ylläpidosta. RAG:n kustannus on hakuindeksin laadunvalvonta, fine-tuningin uudelleenkoulutuksen sykli ja agentin operatiivinen valvonta. Arvioi jokainen vaihtoehto kolmen vuoden ylläpidolla, ei ensimmäisen kuukauden pilotilla. Riskiprofiili kääntyy samaan suuntaan: mitä enemmän autonomiaa annat, sitä enemmän tarvitset rajoitteita, ihmisen hyväksyntää kriittisissä kohdissa ja auditoitavaa jälkeä. Tämä on suunnittelupäätös, ei jälkikäteen lisättävä ominaisuus.