RAG vai hienosäätö? Mitä todelliset asiakasprojektit opettivat meille valinnasta

Lähes jokaisessa yritysten tekoälystä käymässäni keskustelussa päädytään ensimmäisen tunnin aikana samaan valintatilanteeseen. Asiakkaalla on suuri kielimalli, joka tekee vaikutuksen demossa mutta ei tunne heidän tuotteitaan, käytäntöjään eikä kirjoitustapaansa. Joku paikallaolijoista kysyy: pitäisikö mallia hienosäätää omalla datallamme vai rakentaa sen ympärille tiedonhakuun perustuva generointiratkaisu (RAG)?

Rehellinen vastaus on, että kysymys esitetään yleensä väärin. RAG ja hienosäätö ratkaisevat eri ongelmia. Tiimit, jotka pitävät niitä kilpailevina vaihtoehtoina, käyttävät usein kuukausia ja suuren summan GPU-resursseihin väärän ongelman korjaamiseksi. Näin teemme valinnan käytännössä ja näin olemme nähneet sen onnistuvan ja epäonnistuvan.

Aloita selvittämällä, mitä mallilta puuttuu

Kun malli antaa liiketoimintatehtävässä huonon vastauksen, siltä puuttuu toinen kahdesta asiasta.

Siltä puuttuu tietoa. Se ei tunne uusinta hinnastoasi, vuoden 2025 toimittajasopimuksesi sopimuskohtaa eikä viime kuussa lanseeratun tuotteen vianmääritysohjeita. Kyse on faktatiedon puutteesta.

Siltä puuttuu oikeanlainen toimintatapa. Se tietää tarpeeksi, mutta ei vastaa tarvitsemallasi tavalla. Se sivuuttaa tulostemuotosi, kirjoittaa väärällä sävyllä, tulkitsee sisäiset koodisi väärin tai ei pysty suorittamaan tarkasti rajattua, toistuvaa tehtävää, kuten tikettien luokittelua 40 kategoriaasi. Kyse on taitojen puutteesta.

RAG on ratkaisu ensimmäiseen ongelmaan. Hienosäätö on ratkaisu toiseen. Suurin osa näkemästäni sekaannuksesta johtuu yrityksistä opettaa mallille faktatietoa hienosäädön avulla.

Miksi hienosäätö on huono tapa lisätä tietoa

On houkuttelevaa ajatella, että jos mallia koulutetaan omilla dokumenteillasi, se ”tuntee” ne. Käytännössä se oppii dokumenttien tyylin paljon luotettavammin kuin niiden sisältämät faktat. Microsoftin tutkijat vertasivat kahta menetelmää suoraan tietopainotteisissa kysymyksissä ja havaitsivat, että RAG tuotti johdonmukaisesti parempia tuloksia kuin valvomaton hienosäätö sekä mallin koulutuksessa näkemien faktojen että täysin uusien faktojen kohdalla.

Myös käytännön ongelmia on. Faktat muuttuvat. Aina kun käytäntösi tai luettelosi muuttuu, hienosäädetty malli on vanhentunut, kunnes koulutat sen uudelleen. Lisäksi jäljitettävyys katoaa: kun hienosäädetty malli ilmoittaa jonkin luvun, et voi osoittaa, mistä dokumentista se on peräisin. Säännellyillä vakuutus- ja terveydenhuoltoalan asiakkailla tämä yleensä päättää keskustelun jo yksinään.

RAG, joka kuvattiin ensimmäisen kerran Lewisin ym. vuoden 2020 artikkelissa, pitää tiedon mallin ulkopuolella. Haet asiaankuuluvat tekstikatkelmat kysymyshetkellä ja välität ne mallille kontekstiksi. Tiedon päivittäminen tarkoittaa indeksin päivittämistä, ei mallin uudelleenkouluttamista. Lisäksi jokaisessa vastauksessa voidaan viitata lähteeseen.

Eräs logistiikka-alan asiakkaamme on hyvä esimerkki. Sen asiakkaat halusivat saada heti vastauksia siihen, missä heidän lähetyksensä olivat ja mitkä asiakirjat puuttuivat. Nämä tiedot muuttuvat muutaman minuutin välein. Mikään koulutusmäärä ei olisi pitänyt mallia ajan tasalla, joten rakentamamme avustaja hakee vastaushetkellä tiedot reaaliaikaisesta seurannasta ja esineiden internetin (IoT) datasta sen sijaan, että vastaisi muistinsa varassa. Vain tiedonhakuun perustuva ratkaisu olisi voinut toimia.

Milloin hienosäädöstä on hyötyä

Hienosäätö ei ole kuollut. Sen käyttöala on vain kapeampi kuin moni odottaa. Hyödynnämme sitä kolmessa tilanteessa:

• Tarkat, toistuvat tulostemuodot. Kun mallin on tuotettava sama rakenteinen tulos tuhansia kertoja päivässä, esimerkiksi poimittava laskuista kenttiä kiinteän JSON-skeeman mukaisesti, hienosäädetty pieni malli on usein luotettavampi ja paljon edullisempi kuin suuren mallin ohjeistaminen kehotteilla.
• Toimialan kieli. Joillakin aloilla käytetään lyhenteitä, jotka perusmalli tulkitsee väärin. Yleisiä esimerkkejä ovat logistiikan tilakoodit, kliiniset lyhenteet ja yrityksen sisäiset tuotekoodit. Kohtuullinen hienosäätö voi korjata ongelman.
• Kustannukset ja viive suuressa mittakaavassa. Kun tehtävä on määritelty tarkasti, hienosäädetty pieni malli voi korvata suuren yleiskäyttöisen mallin. LoRA-menetelmien kaltaiset tekniikat tekevät tästä edullista, sillä niiden avulla koulutetaan koko mallin sijaan pieni joukko lisäpainoja.

Huomaa, ettei mikään näistä liity faktatietoon. Kyse on siitä, että mallille opetetaan, miten sen tulee toimia tehtävässä, jonka jo itse tunnemme hyvin.

Useimmat RAG-ongelmat johtuvat tiedonhausta

Kun tiimi kertoo minulle: ”Kokeilimme RAGia, eikä se toiminut”, ongelma on harvoin mallissa. Se on tiedonhakuvaiheessa. Malli voi olla vain niin hyvä kuin sille annetut tekstikatkelmat.

Korjauskeinot eivät ole näyttäviä, mutta ne toimivat:

• Jaa sisältö merkityksen, älä merkkimäärän mukaan. Sopimuksen pilkkominen 500 merkin välein katkaisee sopimuskohtia keskeltä. Osioiden ja otsikoiden mukaan jakaminen säilyttää kontekstin.
• Lisää jokaiseen tekstikatkelmaan kontekstia. Tekstikatkelmasta, jossa lukee ”raja on 30 päivää”, ei ole hyötyä, ellei tiedetä, mihin käytäntöön se liittyy. Anthropic raportoi, että lyhyen dokumenttikontekstin lisääminen jokaiseen tekstikatkelmaan ennen indeksointia – lähestymistapa, jota se kutsuu kontekstuaaliseksi tiedonhaunmenetelmäksi – vähensi epäonnistuneita hakuja 49 prosenttia ja uudelleenjärjestelyn kanssa yhdistettynä 67 prosenttia.
• Yhdistä avainsana- ja vektorihaku. Vektorihaku tunnistaa hyvin merkityksiä, mutta löytää heikommin täsmällisiä ilmauksia, kuten osanumeroita. Yhdistelmähaku kattaa molemmat.
• Testaa hakua erikseen. Kokoa joukko todellisia kysymyksiä, joihin liittyvät oikeat lähdekatkelmat tunnetaan, ja mittaa, löytyykö oikea katkelma hakutulosten kärjestä, ennen kuin arvioit lopullisia vastauksia.

Milloin molempia kannattaa käyttää

Tuotantokäytössä parhaat järjestelmät yhdistävät usein molemmat. RAG tuo vastauksiin faktat. Kevyesti hienosäädetty malli huolehtii vastausten muodosta, sävystä ja alakohtaisesta kielestä. Tutkimus etenee samaan suuntaan: UC Berkeleyn RAFT-menetelmässä mallia hienosäädetään nimenomaan niin, että se osaa hyödyntää haettuja asiakirjoja paremmin ja sivuuttaa epäolennaiset asiakirjat.

Järjestyksellä on kuitenkin väliä. Rakennamme lähes aina ensin RAG-järjestelmän, mittaamme sen puutteet ja päätämme vasta sitten, kannattaako mallia hienosäätää. Jos aloitat hienosäädöstä, maksat mallin koulutuksesta ennen kuin tiedät, mikä todellinen puute on.

Yksinkertainen päätöksenteon tarkistuslista

1. Perustuuko tehtävä tietoihin, jotka muuttuvat useammin kuin kerran vuosineljänneksessä? Käytä RAG-menetelmää.
2. Tarvitsevatko käyttäjät tai tarkastajat tiedon siitä, mistä vastaus on peräisin? Käytä RAG-menetelmää.
3. Onko ongelma vastausten muodossa, sävyssä tai sanastossa eikä niiden faktoissa? Harkitse hienosäätöä.
4. Onko kyse tarkasti rajatusta tehtävästä, jota suoritetaan paljon ja jossa kustannuksilla tai nopeudella on merkitystä? Harkitse pienemmän mallin hienosäätöä.
5. Oletko mitannut haun laatua erikseen? Jos et, tee se ennen mitään muuta.

Yhteenveto

RAG ja hienosäätö eivät ole kilpailijoita. Toinen antaa mallille oikeat tiedot, toinen muokkaa sen toimintaa. Selvitä, mikä ongelma sinulla todella on, korjaa haku ennen kuin syytät mallia ja suhtaudu hienosäätöön toimenpiteenä, johon kannattaa ryhtyä vasta, kun järjestelmä toimii – ei oikotienä sen saamiseksi toimimaan.