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ässä on kehys valintaan ja ennen kaikkea reilun vertailun tekemiseen. Se ei julkaise yleispäteviä hankekustannuksia tai tarkkuusparannuksia. Ensisijaisia lähteitä ovat alkuperäinen RAG-artikkeli, OpenAI:n nykyinen hienosäätöopas ja Hugging Facen PEFT-dokumentaatio.

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 painoja mukauttaakseen käyttäytymistä mitatussa tehtävässä. Se voi vaikuttaa tyyliin, muotoon, tehtäväsuoritukseen ja muistiin painuneisiin yhteyksiin. Se ei ole luotettava tai ylläpidettävä tapa asentaa ajantasaista tosiasiatietokantaa.

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.

Älä oleta, kuinka yleinen kukin puute on. Luokittele virheet edustavasta arviointiaineistosta: ohjeiden noudattaminen, puuttuva tai virheellinen konteksti, haun epäonnistuminen, kyvykkyyden puute, käytännön rikkominen tai integraation virhe. Tämä jakauma kertoo, mihin kannattaa investoida.

Kehotteet: aliarvostettu vipu

Kehotteiden parantaminen on usein edullisin ja nopein ensimmäinen koe. Sen riittävyys on silti osoitettava tehtäväkohtaisella arvioinnilla ennen kuin RAG tai hienosäätö rajataan pois.

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ä ensimmäinen koe on halvin mahdollinen kehotteiden lähtötaso. Rajaa se arvioitujen muunnelmien määrällä ja etukäteen sovitulla lopetussäännöllä, ei mielivaltaisella viikolla. Siirry eteenpäin, kun uudet kehotemuutokset eivät enää paranna erillistä arviointimittaria tai rikkovat jotakin muuta vaatimusta.

Kehotesuunnittelun työmäärä

Aja kehotemuunnelmat samaa opetus- ja kehitysjakoa vasten ja säilytä erillinen testijoukko koskemattomana. Muuta yhtä suunnitteluulottuvuutta kerrallaan – tehtävän määrittely, esimerkit, konteksti, tuotoksen skeema tai työkalujoukko – ja kirjaa laatu, viive ja kustannus. Lopeta, kun ennalta ilmoitettu hyväksymisraja täyttyy tai seuraava muutos ei enää paranna kehitysjoukon tulosta. Kalenteriaika ei voi todistaa, että kehotteiden mahdollisuudet on käytetty loppuun.

Millainen on hyvä kehote

Testattavia kehotteen osia ovat:

• Selkeä rooli ja tehtävä.
• Täsmälliset muotovaatimukset.
• Edustavia esimerkkejä, kun arviointi osoittaa niiden auttavan.
• Selväsanaiset rajoitteet siitä, mitä tehdään ja mitä ei.
• Reunatapausten käsittely.
• Tulosteen skeema.

Käytä lyhintä kehotetta, joka säilyttää mitatun käyttäytymisen ja tarvittavat rajoitteet. Kappaleiden määrä ei ole laatumittari.

RAG: ratkaisu tiedon puutteeseen

RAG on harkinnan arvoinen, 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: ingestointi, käyttöoikeudet, pilkkominen, indeksointi, haku, arviointi ja operointi; arvioi työmäärä omista lähteistäsi ja hyväksymiskriteereistäsi.
• Operointi: jatkuvaa työtä indeksin päivittämiseksi, laadun valvomiseksi ja ongelmien korjaamiseksi.
• Infrastruktuuri: jäsennys ja OCR, tallennus, upottaminen, haku, uudelleenjärjestely, generointi, varmuuskopiot ja telemetria; hinnoittele ne päivätyistä tarjouksista ja mitatuista volyymeistä.
• Kyselykohtainen kustannus: voi lisätä kyselyn upottamisen, haun, uudelleenjärjestelyn ja kontekstitokenit, mutta se voi myös vähentää hukkakontekstia tai mahdollistaa edullisemman generoivan mallin. Mittaa koko polku.

Hyväksy investointi vasta, kun arvioitu hakupolku parantaa määriteltyä lopputulosta riittävästi perustellakseen ingestoinnin, käyttöoikeuksien, tuoreuden, viiveen, kustannuksen ja operoinnin työn.

RAG-laatu kehittyy vaiheittain

Siirrettävissä olevaa ”ensimmäisen viikon laatuprosenttia” ei ole. Muodosta perustaso leksikaalisella, vektori- ja hybridihaulla merkityllä aineistolla, raportoi recall ja lopullisen vastauksen mittarit osituksittain ja muuta sitten yhtä vaihetta kerrallaan. Julkaise vasta, kun liiketoimintakohtaiset virhe- ja käyttöoikeustarkistukset menevät läpi.

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

Hienosäätö on harkinnan arvoinen, kun:

• Kyvykkyyden puute on selvä: malli ei suoriudu tehtävästä luotettavasti edes hyvillä kehotteilla ja kontekstilla.
• Sinulla on riittävästi edustavaa, lisensoitua ja tietosuojatarkastettua koulutusaineistoa parantamaan erillisen testijoukon tulosta. Määritä riittävyys oppimiskäyrällä, ei yleispätevällä esimerkkimäärällä.
• 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 rakentanut vertailua varten kehotteiden, rajoitetun tuotoksen, haun tai työkalujen perustasoa.
• 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.
• Tehtävä tarvitsee ensisijaisesti ajantasaisia, lähteisiin jäljitettäviä tosiasioita; haku tai auktoritatiiviset työkalut ovat helpompia päivittää ja siteerata kuin painojen muutokset, vaikka nekin vaativat arviointia.

Hienosäädön tyypit

Täysi hienosäätö: kaikki mallin painot ovat päivitettävissä. Sillä on suurin koulutettava pinta sekä laskenta- ja tallennuskuorma, mutta se ei automaattisesti tuota parasta tulosta erillisellä testijoukolla.

LoRA (Low-Rank Adaptation): kouluttaa matalan asteen adaptereita perusmallin painojen pysyessä jäädytettyinä, mikä vähentää koulutettavia parametreja ja yleensä myös optimoijan muistintarvetta. Vertaa laatua ja tarjoilun tukea täyteen hienosäätöön todellisessa tehtävässä.

QLoRA: vie gradientit jäädytetyn kvantisoidun perusmallin läpi LoRA-adaptereihin. Se voi pienentää muistintarvetta; laatu on empiirinen kysymys, ei kiinteä ”mittakaavassa heikompi” -sääntö.

Kehotehienosäätö ja etuliitehienosäätö: kouluttaa jatkuvia kehote- tai etuliiteparametreja. Laitteisto, palveluntarjoajan tuki, tehtävän laatu ja tarjoiluintegraatio ratkaisevat, onko pienempi koulutettava pinta hyödyllinen.

Ohjehienosäätö: ohjattua mukauttamista ohje-vastausesimerkeillä. Se on tavallista mallikehityksessä ja voi olla myös sovellustiimin koe, kun mallin lisenssi, aineisto, infrastruktuuri ja arvioinnit tukevat sitä.

RLHF / DPO / KTO: eri preferenssioptimoinnin perheitä; ne eivät ole keskenään vaihdettavia eivätkä käytä samaa aineistoa. Käytä kiinnitetyn toteutuksen alkuperäisartikkelia ja dokumentaatiota ja testaa sitten palkkio- ja preferenssilaatu sekä turvallisuusregressiot.

Parametritehokas viritys on harkinnan arvoinen vaihtoehto, kun täysi hienosäätö ei mahdu laitteisto- tai iterointibudjettiin. Tässä artikkelissa ei ole edustavaa kartoitusta siitä, mitä useimmat tiimit käyttävät, eikä yleispätevää parasta tasapainoa.

Realistinen kustannus

Hienosäädön kustannus ja kesto riippuvat perusmallista, sekvenssipituuksista, tokeneista, epookeista, laitteistosta, hajautusstrategiasta, epäonnistumisista ja arvioinnista. Rakenna arvio pienestä instrumentoidusta ajosta:

• Aineiston valmistelu: alkuperä, käyttöoikeudet, duplikaattien poisto, tietosuojatarkastus, muotoilu ja laadun merkitseminen.
• Koulutus: mitatut tokenit sekunnissa × suunnitellut tokenit, sekä tarkistuspisteet, epäonnistuneet ajot ja tallennus.
• Arviointi: perusmalli verrattuna viritettyyn malliin erillisellä kohde-, turvallisuus- ja yleiskyvykkyysaineistolla.
• Iterointi: budjetoi vasta, kun on määritelty, millainen tulos perustelisi uuden ajon.
• Käyttöönotto: palveluntarjoajan saatavuus, adapterien tarjoilu, palautus, valvonta ja säilytysvelvoitteet.
• Ylläpito: uudelleenkoulutus, kun aineisto päivittyy, kun perusmalli päivittyy tai kun käyttötapaus muuttuu.

Laske mukaan insinöörien ja katselmoijien työaika; pelkkä laskenta ei ole kokonaiskustannus. Etene vain, kun mitattu parannus on jatkuvan tarjoilu- ja uudelleenkoulutuskuorman arvoinen.

Milloin hienosäätö toimii erityisen hyvin

Tilanteita, joissa hienosäätökoe voi olla perusteltu:

Vakaa tehtäväkäyttäytyminen. Hienosäätö voi parantaa muotoa tai tyyliä tietyssä jakaumassa, mutta rajoitettu dekoodaus takaa jo tuetut skeemamuodot. Vertaa pelkkää kehotetta, rajoitettua tuotosta ja viritettyä perustasoa sen sijaan, että lupaisit 95 % vastaan 99 %.

Erikoiskieli tai -syntaksi. Lääketieteen terminologia, oikeudellinen ilmaisu tai sisäinen DSL voivat parantua erillisillä esimerkeillä, mutta korkean panoksen oikeellisuus vaatii silti ulkoisen validoinnin, ajantasaisen näytön ja pätevän katselmoinnin.

Tyyli ja ääni. Viritetty malli voi parantaa pisteytettyä tyyliarviointia kohdejakaumassa. Se ei ”leivo sisään” täydellistä johdonmukaisuutta; mittaa äänen lisäksi sisällön laatu, turvallisuus ja ajautuminen.

Viive- ja kustannuskoe. Pienempi viritetty malli voi läpäistä saman hyväksymisrajan pienemmällä mitatulla tarjoilukustannuksella tai viiveellä. Ota koulutus, arviointi, kapasiteetti, luotettavuus ja ylläpito mukaan ennen kuin väität hyötyä.

Käyttäytymisen mukauttaminen. Turvallisuusviritys voi parantaa mitattua kieltäytymiskäyttäytymistä, mutta se voi myös kieltäytyä liikaa tai liian vähän tai heikentää muita kyvykkyyksiä. Sen on pysyttävä yhtenä kerroksena deterministisen valtuutuksen, käytäntöjen valvonnan, seurannan ja ihmisportin rinnalla.

Milloin hienosäätö epäonnistuu

Yleisiä tapoja, joilla hienosäätö tuottaa pettymyksen:

Riittämätön tai epäedustava aineisto. Pienet ja kapeat aineistot joskus auttavat ja suuret kohinaiset aineistot joskus haittaavat. Piirrä erillisen testijoukon tulos koulutusaineiston kasvaessa ja tarkasta ositusten kattavuus ennen kuin ostat lisää laskentaa.

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

Osa tuotantojärjestelmistä yhdistää näitä menetelmiä, mutta jokainen lisätty menetelmä kasvattaa arviointi- ja operointipintaa.

Yhdistelmä 1: kehotteilla ohjattu RAG

Harkinnan arvoinen sovelluksissa, jotka tarvitsevat muuttuvaa ja lähteisiin jäljitettävää tietoa.

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

Hyväksy se vain, jos haku parantaa määriteltyä tehtävää ja käyttöoikeus-, tuoreus-, viittaus-, viive-, kustannus- ja virhetestit menevät läpi.

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ä: rakenna ja arvioi kehotteiden perustaso. Julkaise vain, jos hyväksymis- ja turvallisuuskriteerit täyttyvät.

Jos ei, siirry kysymykseen 2.

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

Jos kyllä: vertaa suoraa kontekstia, leksikaalista hakua, vektorihakua ja hybridihakua tilanteen mukaan. Arvioi toteutus vasta lähteiden ja käyttöoikeuksien kartoituksen jälkeen.

Jos ei, siirry kysymykseen 3.

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

Jos kyllä JA sinulla on edustavaa aineistoa tarvittavin oikeuksin ja tietosuojakontrollein: aja pieni hienosäätökoe ja vertaa sitä muuttumattomaan perustasoon.

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ä

Havainnollistavia yhdistelmiä (eivät mitattuja tapaustutkimuksia):

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

Lopputulos (havainnollistava skenaario): Käsittelee suuren osan tason 1 tukipyynnöistä itsenäisesti, kun mittarina on kyseisen tiimin arviointiaineisto. 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.

Päätöskriteeri: vertaa ehtokohtaista recallia, väärää turvallisuudentunnetta, viittausten oikeellisuutta, lainkäyttöalueiden kattavuutta ja pätevän juristin katselmointia. Mitään menetelmää ei hyväksytä oikeudellisen luottamuksen perustaksi vain siksi, että perusmalli on nähnyt oikeudellista tekstiä.

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.
• Oikeuksiltaan selvitetty koulutusaineisto, jonka koko valitaan kattavuuden ja oppimiskäyrän perusteella eikä kopioidusta esimerkkimäärästä.

Päätöskriteeri: vertaa jäsennyksen onnistumista, semanttista oikeellisuutta ja suorituksen turvallisuutta kehotepohjaisen ja viritetyn version välillä erillisillä ohjelmilla. Havainnollistava asetelma ei osoita, että hienosäätö olisi välttämätön todellisessa DSL:ssä.

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.

Päätöskriteeri: vertaa pelkkää kehotetta ja hakuvariantteja ajantasaisten vastausten oikeellisuudessa, viittauksissa, käyttöoikeuksissa, pidättyvyydessä, viiveessä, kustannuksessa ja katselmoidussa tyylissä. Hienosäädä vain, jos jäljelle jäävä ja arvokas käyttäytymisen puute osoitetaan.

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ä. Testaa ensin kehotteiden ja haun perustasot; moni näennäinen hienosäätöongelma on ohje- tai puuttuvan kontekstin ongelma, ja perustaso antaa päätökselle näytön.

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.” Ilman erillistä perustasoa ja osituskohtaisia tuloksia muutosta ei voi kohdistaa, ja regressiot jäävät piiloon.

Virhe 4: vanhentuneet hienosäädöt. Perusmallit, tarjoilupinot, aineistot ja tuotevaatimukset muuttuvat. Aja muuttumaton perustaso ja hyväksymiskokonaisuus uudelleen ennen uudelleenkoulutusta tai adapterin tarjoilun jatkamista.

Virhe 5: painojen käsittely ajantasaisena tietokantana. Koulutus voi luoda muistiin painuneita yhteyksiä ilman päivitys-, alkuperä- tai poistotakeita. Pidä auktoritatiiviset tosiasiat hallituissa lähteissä tai työkaluissa ja testaa haku; käytä viritystä osoitettuun tehtäväkäyttäytymiseen, älä tiedon virallisena lähteenä.

Virhe 6: kehotteille ei ole lopetussääntöä. Iterointi ilman erillistä testijoukkoa voi ylisovittaa esimerkkeihin loputtomiin. Lopeta tai eskaloi, kun ennalta ilmoitetut mittarit tasaantuvat.

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

Vertailutyökirja – täytä se mitatuilla tai tarjotuilla arvoilla samaa hyväksymisrajaa vasten:

Oikea valinta riippuu mitatusta puutteesta ja koko toimintamallista. Kehotteet ja haku ovat yleinen yhdistelmä muuttuvalle tiedolle, mutta se ei ole yleispätevä optimikohta.

Tunnista aukko, valitse sitten vipu

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

Järjestys, jossa niitä kannattaa kokeilla:

1. Rakenna yksinkertaisin olennainen perustaso. Usein se on kehote tai rajoitettu tuotos, mutta haku- tai työkaluperustaso voi olla yksinkertaisempi, kun tosiasiat ovat jo auktoritatiivisessa järjestelmässä.
2. Lisää haku osoitettuun näyttö- tai tuoreuspuutteeseen ja arvioi sitten koko ingestointi-, käyttöoikeus-, haku- ja generointipolku.
3. Aja hienosäätökoe osoitettuun käyttäytymisen tai tehtäväsuorituksen puutteeseen, kun oikeuksiltaan selvitettyä edustavaa aineistoa ja tarjoilun tukea on saatavilla.
4. Yhdistä menetelmiä vain, kun jokainen osa tuottaa mitatun lisähyödyn, joka on operatiivisen pintansa arvoinen.

Ilman erillisiä arviointeja et voi kohdistaa, mikä lähestymistapa auttoi. Kirjaa puute, perustaso, hyväksymiskriteerit, haitalliset ositukset, kokonaiskustannus ja palautussuunnitelma ennen vivun valintaa.