Kehotteiden, RAG:n ja hienosäädön valinta sekä niiden yhdistäminen

Tiimi saa tehtävän: ”Saakaa tekoälymme käsittelemään käyttötapaustamme paremmin.” Toteutustapoja on muutama. Tiimi voi kirjoittaa parempia kehotteita, rakentaa mallille olennaista tietoa syöttävän RAG-järjestelmän tai hienosäätää mallin oman toimialansa esimerkeillä.

Nämä keinot eivät ole keskenään vaihdettavia. Ne ratkaisevat eri ongelmia. Väärä valinta voi tarkoittaa kolmen kuukauden ja suuren budjetin käyttämistä hienosäätöön, vaikka parempi kehote olisi riittänyt. Tai monimutkaisen RAG-infrastruktuurin rakentamista, vaikka hienosäätö olisi ollut yksinkertaisempaa. Tai kehotteiden hiomista, vaikka malli ei perustavanlaatuisesti pysty tarvittavaan tehtävään.

Tämä artikkeli tarjoaa valintakehyksen: milloin mikäkin keino on oikea, milloin niitä kannattaa yhdistää, mitkä ovat niiden realistiset kustannukset ja mikä tuotannossa yleensä onnistuu tai epäonnistuu.

Mitä kukin keino todella tekee

Selkeä erottelu:

Kehote muuttaa sitä, mitä mallilta pyydetään. Mallille annetaan paremmat ohjeet, esimerkit, muotovaatimukset ja konteksti. Itse malli ei muutu, vaan syöte muuttuu.

RAG muuttaa mallin näkemää tietoa. Olennainen tieto haetaan kyselyhetkellä ja lisätään kehotteeseen. Malli saa ajantasaista, täsmällistä ja muuttuvaa tietoa ilman, että sitä koulutetaan tällä tiedolla.

Hienosäätö muuttaa mallin osaamista tai käyttäytymistä. Mallia koulutetaan esimerkeillä ja sen painoja muutetaan. Itse malli päivittyy.

Nämä ratkaisevat eri ongelmia:

• Ohjeistuksen puute: malli osaisi tehdä tehtävän, jos sitä pyydettäisiin oikein. → Kehote.
• Tiedon puute: malli tarvitsee tietoa, jota sillä ei ole. → RAG.
• Kyvykkyyden puute: malli ei suoriudu tehtävästä luotettavasti edes hyvillä kehotteilla ja kontekstilla. → Hienosäätö.

Oikean puutteen tunnistaminen ratkaisee jo puolet ongelmasta.

Puutteen diagnosointi

Kun tekoäly ei tee tarvittavaa, kysy:

Pystyisikö älykäs ihminen tekemään tehtävän pelkän kehotteen perusteella?

Jos kyllä → kyse on ohjeistuksen puutteesta. Paremman kehotteen pitäisi korjata se.

Jos ei, pystyisikö hän tekemään tehtävän saatuaan olennaisen lähdeaineiston?

Jos kyllä → kyse on tiedon puutteesta. RAG voi korjata sen.

Jos ei, pystyisikö hän tekemään tehtävän laajan harjoittelun ja palautteen jälkeen?

Jos kyllä → kyse on kyvykkyyden puutteesta. Hienosäätö saattaa korjata sen.

Jos ei → tehtävä ei ehkä ole LLM:n ratkaistavissa. Arvioi ongelma uudelleen.

Useimmat ”tekoäly ei toimi” -ongelmat johtuvat ohjeistuksesta, ja parempi kehote ratkaisee ne. Seuraavaksi yleisimpiä ovat tiedon puutteet. Aidot kyvykkyyden puutteet ovat pienin mutta vaikeimmin ratkaistava luokka.

Kehotteet: aliarvostettu vipu

Kehotteiden parantaminen on edullisin ja nopein keino sekä useimmiten oikea vastaus. Tiimit kuitenkin ohittavat sen ja siirtyvät suoraan RAG:iin tai hienosäätöön.

Pelkällä kehotteella voi esimerkiksi:

• Muuttaa sävyä, muotoa ja pituutta.
• Soveltaa päättelymalleja, kuten ajatusketjua ja itsekritiikkiä.
• Määrittää rajoitteita: tee X, älä tee Y.
• Kuvata käytäntöjä ja suojamekanismeja.
• Mukauttaa toiminnan tiettyihin käyttötapauksiin eri ominaisuuksien omilla kehotteilla.
• Parantaa johdonmukaisuutta muutaman esimerkin avulla.

Pelkällä kehotteella ei voi:

• Saada mallia tietämään tosiasioita, joita sillä ei ole.
• Saada pientä mallia toimimaan suuren mallin tavoin.
• Muuttaa mallin ääntä tai tyyliä perustavanlaatuisesti.
• Nopeuttaa mallin inferenssiä.

Järkevä sääntö on kokeilla ensin kehotteita ja kehittää niitä vähintään viikon ajan ennen RAG:n tai hienosäädön valitsemista. Useimmiten kehote ratkaisee ongelman.

Kehotesuunnittelun työmäärä

Viikon intensiivinen kehoteiterointi voi tuottaa huomattavia parannuksia. Tyypillinen kehitys:

• Päivä 1: lähtötaso. Keskinkertaiset tulokset.
• Päivät 2-3: rakenteelliset muutokset. Parempi muoto ja selkeämmät ohjeet. Suuria parannuksia.
• Päivät 4-5: esimerkit ja reunatapaukset. Virhetilat löytyvät.
• Päivät 6-7: sävy, rajoitteet ja viimeistely. Viimeinen 10% parannus.

Viikon jälkeen olet saanut esiin suurimman osan kehotteiden potentiaalista. Jos tulos ei vieläkään tyydytä, puute liittyy todennäköisesti tietoon tai kyvykkyyteen.

Millainen on hyvä kehote

Vahvassa kehotteessa on yleensä:

• Selkeä rooli ja tehtävä.
• Täsmälliset muotovaatimukset.
• 1-5 edustavaa esimerkkiä tarvittaessa.
• Selväsanaiset rajoitteet siitä, mitä tehdään ja mitä ei.
• Reunatapausten käsittely.
• Tulosteen skeema.

Sopiva pituus on yleensä 5-10 kappaletta. Kehote ei saa olla liian lyhyt ja alimääritelty eikä niin pitkä, että mallin huomio hajaantuu.

RAG: ratkaisu tiedon puutteeseen

RAG on oikea työkalu, kun:

• Malli tarvitsee tosiasiatietoa, jota sillä ei ole.
• Tieto muuttuu, kuten reaaliaikainen tieto, viimeaikaiset tapahtumat tai tilikohtainen tieto.
• Tieto on toimiala- tai organisaatiokohtaista.
• Tarvitset viittauksia tai todennettavaa lähteisiin perustamista.

Se on väärä työkalu, kun:

• Ongelma liittyy ohjeistukseen eikä tietoon.
• Tietoa on niin vähän, että sen voi lisätä suoraan kehotteeseen.
• Mallin pitää toimia eri tavalla, ei vain tietää eri asioita.

Realistinen kustannus

RAG-järjestelmä vaatii todellista ohjelmistokehitystä:

• Rakentaminen: vakavasti otettava järjestelmä vaatii 4-12 viikkoa ingestointiin, pilkkomiseen, upottamiseen, hakuun, uudelleenjärjestelyyn ja arviointiin.
• Operointi: jatkuvaa työtä indeksin päivittämiseksi, laadun valvomiseksi ja ongelmien korjaamiseksi.
• Infrastruktuuri: vektoritietokanta sekä upotus- ja uudelleenjärjestelyrajapintojen kustannukset. Keskikokoisissa järjestelmissä tyypillisesti €200-2000 kuukaudessa.
• Kyselykohtainen kustannus: suurempi kuin pelkällä kehotteella, koska mukaan tulevat upotus, haku ja laajempi konteksti. Yleensä 2-5x tavallisen API-kutsun kustannus.

Oikeassa ongelmassa investointi kannattaa hyvin. Kehotteisiin verrattuna se on kuitenkin huomattava.

RAG-laatu kehittyy vaiheittain

Viikolla 1 toimivan RAG-järjestelmän laatu on yleensä tasolla 60-70% ja tuotantotason laatuun (85%+) pääseminen vaatii vielä 1-2 kuukautta työtä: pilkkomisen parantamista, uudelleenjärjestelyn lisäämistä, virhetilojen korjaamista ja arviointien rakentamista.

Varaudu tähän. Viikolla 1 julkaiseminen tuottaa pettyneitä käyttäjiä.

Hienosäätö: kun kehotteet ja RAG eivät riitä

Hienosäätö on oikea työkalu, kun:

• Kyvykkyyden puute on selvä: malli ei suoriudu tehtävästä luotettavasti edes hyvillä kehotteilla ja kontekstilla.
• Sinulla on hyvä erä laadukkaita koulutusesimerkkejä: erittäin kapeaan LoRA-hienosäätöön vähintään muutama sata, mutta luotettava yleinen käyttäytyminen vaatii tavallisemmin 1,000+ laadukasta esimerkkiä. Katso hienosäätöartikkelista tekniikkakohtaiset tarkat rajat.
• Tarvitset johdonmukaista ja tarkasti rajattua käyttäytymistä, kuten tietyn tyylin, tulostemuodon tai toimialan.
• Inferenssin kustannuksella tai viiveellä on merkitystä, sillä hienosäädetty pieni malli voi olla yleiskäyttöistä suurta mallia edullisempi.

Se on väärä työkalu, kun:

• Tietosi muuttuvat jatkuvasti, jolloin hienosäädetty malli vanhenee nopeasti.
• Et ole vielä käyttänyt kehotteiden ja RAG:n mahdollisuuksia loppuun.
• Sinulla ei ole hyviä arviointeja, joten et pysty toteamaan hienosäädön hyötyä.
• Tehtävä edellyttää hyvin ajantasaista tietoa, sillä hienosäätö on tilannekuva.
• Yrität opettaa tosiasioita. RAG tekee sen paremmin, luotettavammin ja viittausten kanssa.

Hienosäädön tyypit

Täysi hienosäätö: kaikki mallin painot päivitetään. Tehokkain ja kallein vaihtoehto, joka vaatii paljon laskentaa. Yleensä vain perustamalleja kehittävien laboratorioiden käytössä.

LoRA (Low-Rank Adaptation): vain pientä osaa painoista koulutetaan. Paljon edullisempi vaihtoehto, jonka tulokset ovat kapeissa tehtävissä usein kilpailukykyisiä täyden hienosäädön kanssa.

QLoRA: kvantisoitu LoRA. Vielä edullisempi. Laatu on mittakaavassa heikompi mutta riittävä moniin tehtäviin.

Kehotehienosäätö ja etuliitehienosäätö: vielä pienempi menetelmä, jossa koulutetaan vain pehmeitä kehotteita. Edullisin mutta kyvykkyydeltään rajallinen.

Ohjehienosäätö: malli koulutetaan noudattamaan ohjeita. Tämä tehdään yleensä perustamallitasolla, joten loppukäyttäjät hyötyvät siitä harvoin.

RLHF / DPO / KTO: malli sovitetaan preferenssidataan, kuten vastausten A ja B välisiin valintoihin. Tehokas käyttäytymisen muuttamiseen mutta vaikea tehdä hyvin.

Vuonna 2026, jolloin vahvoja perustamalleja on saatavilla, useimmat hienosäätöä tekevät tiimit käyttävät LoRA:a vahvan perustamallin päällä. Useimmissa käyttötapauksissa se tasapainottaa kustannuksen ja kyvykkyyden oikein.

Realistinen kustannus

Hienosäädön kustannukset riippuvat menetelmästä ja mittakaavasta. Keskikokoisen avoimen mallin LoRA-hienosäädössä 5K-10K esimerkillä tyypilliset kustannukset ovat:

• Aineiston valmistelu: 1-4 viikkoa. Usein suurin osa työstä kuluu esimerkkien kuratointiin, puhdistamiseen ja muotoiluun.
• Koulutus: tunneista päiviin aineiston koon ja infrastruktuurin mukaan. Laskentaan kuluu €100-2000 infrastruktuurin mukaan.
• Arviointi: 1-2 viikkoa arviointikokonaisuuksien rakentamiseen ja hienosäädetyn mallin vertaamiseen perustasoon.
• Iterointi: 1-3 kierrosta ennen tuotantovalmiutta.
• Käyttöönotto: hallitulla API:lla, kuten OpenAI-hienosäädöllä, Anthropicilla tai Vertexillä, suoraviivaista. Itse ylläpidettynä työläämpää.
• Ylläpito: uudelleenkoulutus tiedon, perustamallin tai käyttötapauksen muuttuessa.

Yhteensä: 6-12 viikkoa työtä, €1K-€20K laskentaan mittakaavan mukaan sekä jatkuva ylläpito.

Investointi on huomattava. Varmista, että se kannattaa.

Milloin hienosäätö toimii erityisen hyvin

Tilanteita, joissa hienosäätö voittaa selvästi:

Tiukat muotovaatimukset. Tulosten pitää noudattaa tiettyä skeemaa tai tyyliä johdonmukaisesti. Kehotteilla pääsee 95% tasolle, hienosäädöllä 99%.

Erikoisalat. Lääketieteen terminologia, oikeudellinen ilmaisu tai sisäisen DSL:n koodi. Hienosäätö opettaa mallille oman erityiskielesi.

Persoona ja ääni. Johdonmukainen ääni tuhansissa vuorovaikutuksissa. Kehotteet voivat ajautua, mutta hienosäätö kiinnittää äänen malliin.

Viiveen ja kustannuksen optimointi. Tietyn tehtäväsi hallitseva hienosäädetty 7B-malli voi olla yleiskäyttöistä 70B-mallia edullisempi ja nopeampi. Suurella käyttömäärällä tämä kannattaa.

Käyttäytymisen turvallisuus. Tiettyihin asioihin kieltäytymään tai erityisiä turvatoimia lisäämään hienosäädetty malli voi olla kehoteperusteisia suojamekanismeja kestävämpi.

Milloin hienosäätö epäonnistuu

Yleisiä pettymyksen syitä:

Riittämätön aineisto. Hienosäätö 100 esimerkillä auttaa yleensä vain vähän. Erittäin kapea LoRA voi joskus toimia muutamalla sadalla esimerkillä, mutta luotettavaan yleiseen käyttäytymiseen kannattaa varata 1,000+ laadukasta esimerkkiä.

Huono aineisto. Roskaa sisään, roskaa ulos. Epäjohdonmukaiset ja heikkolaatuiset esimerkit tuottavat epäjohdonmukaisen ja heikkolaatuisen mallin.

Katastrofaalinen unohtaminen. Voimakas hienosäätö kapeisiin tehtäviin voi heikentää yleisiä kyvykkyyksiä. Malli paranee omassa tehtävässäsi mutta huononee kaikessa muussa.

Vanhentunut tieto. Hienosäädetty malli on tilannekuva. Uusi tieto edellyttää uudelleenkoulutusta, mikä on muuttuvilla aloilla jatkuva kustannus.

Perustamallien kehitys ohittaa hienosäädön. Perustamalli kehittyy niin paljon, ettei hienosäädetty versio ole enää parempi. Ylläpidät nyt vanhentuneen perustamallin hienosäätöä.

Arviointiongelmat. Ilman kunnollisia arviointeja et tiedä, auttoiko tai haittasiko hienosäätö vai jäikö vaikutus olemattomaksi. Monet ”onnistuneet” hienosäädöt ovat lumevaikutuksia.

Yhdistelmämallit

Parhaat tuotantojärjestelmät yhdistävät kaikki kolme.

Yhdistelmä 1: kehotteilla ohjattu RAG (yleisin)

Tietopainotteisten sovellusten oletusmalli.

• Huolellisesti suunnitellut kehotteet määrittävät ohjeet, muodon ja rajoitteet.
• RAG antaa ajantasaisen ja täsmällisen tiedon.
• Ei hienosäätöä, vaan käytetään vahvaa perustamallia.

Tämä on yleisin tuotantomalli vuonna 2026. Se toimii useimmissa käyttötapauksissa.

Yhdistelmä 2: hienosäädetty malli + RAG

Kun tarvitset sekä käyttäytymisen erikoistamista että muuttuvaa tietoa.

• Hienosäädä ääni, muoto ja toimiala.
• Käytä RAG:a ajantasaiseen tietoon.
• Orkestroi kehotteilla.

Esimerkkinä on tietyn yrityksen asiakaspalveluäänelle hienosäädetty malli, joka käyttää RAG:a ajantasaisiin käytäntöihin ja ohjeisiin. Hienosäätö pitää äänen johdonmukaisena, ja RAG käsittelee muuttuvan tiedon.

Yhdistelmä 3: tehtäväkohtaiset hienosäädöt

Järjestelmän eri osissa käytetään eri hienosäätöjä.

• Luokittelun hienosäätö reititykseen.
• Yhteenvedon hienosäätö koosteisiin.
• Generoinnin hienosäätö asiakasvastauksiin.
• Kukin on pienempi, nopeampi ja erikoistunut.

Mallia käytetään, kun mittakaavalla ja kustannusoptimoinnilla on merkitystä. Jokainen hienosäätö hoitaa oman kapean tehtävänsä, ja orkestrointi kutsuu niitä.

Yhdistelmä 4: hienosäädetty reititin + yleismallit

Reititin hienosäädetään luokittelemaan kyselyt luotettavasti. Luokittelun jälkeen kyselyt siirtyvät yleismalleille varsinaista työtä varten.

Hienosäätö on pieni, nopea ja kapea. Kallis yleinen työ tehdään ajantasaisina pidettävillä yleismalleilla.

Näin yhdistyvät taloudellisuus eli pieni hienosäätö ja kyvykkyys eli yleismallit vaikeaan työhön.

Päätösmalli

Käytännöllinen päätöskulku:

Kysymys 1: Voiko nykyinen malli ratkaista ongelman hyvällä kehotteella?

Jos kyllä: kirjoita kehote, kehitä sitä viikon ajan ja julkaise.

Jos ei, siirry kysymykseen 2.

Kysymys 2: Edellyttääkö ongelma tietoa, jota mallilla ei ole?

Jos kyllä: rakenna RAG. Käytä siihen tarvittavat kuukaudet, nosta se tuotantolaatuun ja yhdistä vahvoihin kehotteisiin.

Jos ei, siirry kysymykseen 3.

Kysymys 3: Liittyykö ongelma johdonmukaiseen muotoon, kapeaan toimialaan tai tiettyyn käyttäytymiseen?

Jos kyllä JA sinulla on vähintään useita satoja laadukkaita esimerkkejä, ihannetapauksessa 1,000+ laadukasta esimerkkiä: hienosäädä. Yhdistä kehotteisiin ja mahdollisesti RAG:iin.

Jos esimerkkejä ei ole, investoi niiden keräämiseen TAI kokeile parempia kehotteita tai RAG:a perusteellisemmin ennen hienosäätöä.

Kysymys 4: Oletko tehnyt arviointityön, jolla tiedät todella auttavan lähestymistavan?

Kysymys koskee jokaista vaihetta. Ilman arviointeja arvaat.

Tuotantoesimerkkejä

Muutamia todellisia yhdistelmiä:

Esimerkki 1: tekoäly asiakaspalvelussa

Toteutus: SaaS-yrityksen asiakaspalvelutekoäly käsittelee tason 1 yhteydenotot.

Osat:

• Vahvat kehotteet sävylle, muodolle ja eskalointikäytännöille.
• RAG ajantasaisten ohjeiden, käytäntöjen ja tukipyyntöhistorian päällä.
• Kevyt hienosäätö yrityksen omalle äänelle ja eskalointimalleille (1,500 aiemmista tukipyynnöistä kuratoitua esimerkkiä).

Tulos: Käsittelee 65% tukipyynnöistä itsenäisesti. Hienosäätö vastaa johdonmukaisesta äänestä, RAG tiedon paikkansapitävyydestä ja kehotteet käytännöistä.

Esimerkki 2: oikeudellisten asiakirjojen tarkastus

Toteutus: Oikeusteknologiatuote tarkastaa sopimusten riskejä.

Osat:

• Yksityiskohtaiset kehotteet etsittäville asioille, kuten oikeudellisille luokille ja vakavuusasteikolle.
• RAG olennaisen oikeuskäytännön ja ennakkotapausten päällä.
• Ei hienosäätöä, sillä päättelymallit tekevät vaativan työn.

Tulos: Pelkkä kehote + RAG toimii hyvin, koska mallilla on jo oikeudellista koulutusta. Hienosäätö auttaisi vain hieman, eikä investointi ollut perusteltu.

Esimerkki 3: koodin täydennys omassa DSL:ssä

Toteutus: Erikoistunut datatyökalu, jolla on oma DSL.

Osat:

• Esimerkkejä sisältävät kehotteet.
• Ei RAG:a, sillä DSL on niin pieni, että se mahtuu kontekstiin.
• LoRA-hienosäätö 10K DSL-esimerkillä.

Tulos: Hienosäätö oli välttämätön. Ilman sitä malli ei tuottanut luotettavasti kelvollista DSL:ää. Kehotteet ja konteksti eivät yksin riittäneet.

Esimerkki 4: yrityksen sisäinen avustaja

Toteutus: Yleinen avustaja yrityksen työntekijöille.

Osat:

• Vahvat järjestelmäkehotteet äänelle, käyttäytymiselle ja kieltäytymisille.
• RAG yrityksen wikin, Slackin ja asiakirjojen päällä.
• Ei hienosäätöä, sillä yrityksen ääni voidaan kuvata kehotteilla.

Tulos: RAG + kehotteet käsittelevät useimmat käyttötapaukset. Yrityksen ääni ei ole niin omaleimainen, että se vaatisi hienosäätöä.

Havaitsemiamme virheitä

Muutamia resurssien väärän kohdentamisen malleja:

Virhe 1: hienosäätö valitaan ensin. Tiimit kuulevat ajatuksen ”meidän pitäisi hienosäätää oma mallimme” ja aloittavat siitä. 90% tapauksista kehotteet + RAG olisivat olleet nopeampia ja edullisempia sekä yhtä hyviä.

Virhe 2: RAG ohitetaan, vaikka se on vastaus. Tiimit rakentavat monimutkaisia kehotteita ”muistuttamaan” mallia yrityksen tiedoista, vaikka ne pitäisi selvästi hakea kyselyhetkellä. Hae tieto suoraan.

Virhe 3: hienosäätö ilman arviointeja. ”Hienosäädimme mallin, ja nyt se on parempi.” Mittareita ei ole. Usein hienosäätö ei tehnyt mitään tai jopa heikensi mallia. Ilman arviointeja et tiedä.

Virhe 4: vanhentuneet hienosäädöt. Hienosäätö tehtiin 6 kuukautta sitten, jolloin GPT-4 oli paras. Nykyiset kärkimallit voittavat vanhan hienosäädetyn mallin ilman hienosäätöä. Hienosäädöt pitää arvioida uudelleen alan kehittyessä.

Virhe 5: tosiasioiden opettaminen hienosäädöllä. Tiimit yrittävät hienosäätää mallin ”tuntemaan yrityksemme”. Se toimii huonosti: malli muistaa joitakin tosiasioita ja hallusinoi toisia. RAG käsittelee tosiasiat, hienosäätö käyttäytymisen.

Virhe 6: kehotteita ei kehitetä tarpeeksi pitkään. Kahden päivän kehoteiterointi on lähtökohta. Kahdessa viikossa saat todellisen vastauksen.

Virhe 7: RAG suunnitellaan liian monimutkaiseksi, vaikka kehote riittäisi. Joskus 50K tokenin yritysasiakirjan lisääminen kehotteeseen on RAG:a yksinkertaisempaa, etenkin pienillä aineistoilla.

Kustannusten ja työmäärän vertailu

Karkea vertailu tyypilliselle keskikokoiselle hankkeelle:

Oikea valinta riippuu ongelmastasi ja resursseistasi. Useimmille tiimeille kehotteet + RAG on tasapainoinen ratkaisu: merkittävä kyvykkyyden parannus ilman täyttä hienosäätöinvestointia.

Johtopäätös

Kehotteet, RAG ja hienosäätö ratkaisevat eri ongelmia. Oikea valinta edellyttää rehellistä diagnoosia: onko kyse ohjeistuksen, tiedon vai kyvykkyyden puutteesta?

Rehellinen kokeilujärjestys:

1. Kehotteet (1-2 viikkoa iterointia). Edullisin ja nopein sekä useimmiten riittävä.
2. RAG, jos tiedon puute on selvä. Merkittävä mutta tarkasti rajattava investointi.
3. Hienosäätö, jos kehotteet + RAG eivät korjaa selvää kyvykkyyden puutetta. Kallein vaihtoehto, joten tee se viimeisenä.
4. Yhdistelmät kypsiin tuotantojärjestelmiin.

Onnistuvat tiimit tunnistavat rehellisesti puutteensa ja tekevät arviointeja kurinalaisesti. Ilman arviointeja et voi tietää, mikä lähestymistapa auttoi. Niiden avulla polku on yleensä selvä.

Useimpien ”meidän pitää hienosäätää oma mallimme” -hankkeiden pitäisi lähemmässä tarkastelussa olla ”meidän pitää kirjoittaa paremmat kehotteet ja lisätä RAG”. Säästä hienosäätö tapauksiin, jotka todella tarvitsevat sitä.

Tuloksena ovat paremmat järjestelmät nopeammin ja pienemmillä kustannuksilla. Siitähän tuotantotekoälyn julkaisemisessa on kyse.