RAG ir 'fine-tuning' palyginimas: kurį metodą pasirinkti

RAG – Retrieval-Augmented Generation – yra architektūra, kurioje kalbinis modelis, prieš generuodamas atsakymą, ieško aktualios informacijos išorinėje duomenų bazėje ar dokumentų saugykloje. Modelis pats „nežino" atsakymo iš anksto – jis gauna kontekstą realiuoju laiku ir tik tada generuoja atsakymą.

Supaprastintai: vartotojas užduoda klausimą → sistema suranda susijusius dokumentus → modelis juos nuskaito ir atsakinėja remdamasis tuo, ką rado.

Šį metodą aprašė Meta AI tyrinėtojai 2020 m. darbe „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", pristatytame NeurIPS 2020 konferencijoje. Pagrindinis teiginys – parametrinių modelių žinios yra statiškos ir sunkiai atnaujinamos, o retrieval komponentai leidžia lengvai valdyti naujausią informaciją ir teikia labiau faktiškai pagrįstus, įvairesnius atsakymus.

• Jūsų duomenys nuolat keičiasi – nauji produktai, kainų sąrašai, teisiniai dokumentai, vidaus procedūros
• Svarbu žinoti, iš kur atėjo atsakymas – audito takas, citatos, šaltinių nuorodos
• Modelis neturi „žinoti" visko iš anksto – jis turi rasti ir perskaityti
• Konfidencialūs dokumentai negali būti naudojami modelio mokymui

Fine-tuning – tai procesas, kai jau apmokytas didelės apimties kalbinis modelis papildomai mokinamas ant specializuoto duomenų rinkinio. Modelis „įsisavina" naują elgseną, stilių, terminologiją ar žinias – jos tampa jo parametrų dalimi.

Google Vertex AI dokumentacijos teigimu, fine-tuning veikia pateikiant modeliui mokymo duomenų rinkinį su konkrečių užduočių pavyzdžiais. Modelis ne tik nuskaito informaciją – jis keičia savo vidinę struktūrą.

• Reikia pastovaus tono, stiliaus, formalios kalbos – pavyzdžiui, juridiniuose ar medicininiuose atsakymuose
• Verslas turi nišinę terminiją, kurią modelis turi vartoti tiksliai ir nuosekliai
• Žinių bazė stabili ir keičiasi retai
• Norima sumažinti inferencijos kaštus: trumpesni prompt'ai mažina API sąnaudas

Aspektas	RAG	Fine-tuning
Žinių atnaujinimas	Lengvas – tiesiog papildai dokumentus	Reikia pakartotinai mokyti
Skaidrumas	Aukštas – matomi šaltiniai	Žemas – sprendimai nepaaiškinami
Duomenų saugumas	Duomenys naudojami tik paieškai	Mokymo duomenys patenka pas tiekėją
Kaštų struktūra	Nuolatiniai API ir retrieval kaštai	Vienkartinis mokymo kaštas
Elgsenos kontrolė	Ribota	Aukšta
Diegimo greitis	Greitas	Reikia laiko ir duomenų ruošimo

Čia svarbu nesupaprastinti. Nėra vieno teisingo atsakymo – abu modeliai gali būti pigesni ar brangesni priklausomai nuo naudojimo apimčių ir duomenų struktūros.

• Nuolatiniai API kaštai (kiekvienai užklausai tenka tokenų sąnaudos)

• Vektorizacijos ir indeksavimo kaštas (pirminis ir periodinis)

• Infrastruktūros kaštas (vektorinė duomenų bazė – pgvector, Pinecone, Weaviate ir kt.)

• Kuo daugiau užklausų ir kuo didesnė konteksto apimtis – tuo didesni mėnesiniai kaštai

• Vienkartinis mokymo kaštas (tikslus skaičius priklauso nuo modelio dydžio, duomenų kiekio ir pasirinkto tiekėjo)

• Reguliarūs pakartotiniai mokymų kaštai, jei duomenys keičiasi

• Paprastesnė inferencija: trumpesni prompt'ai sumažina kasdienes API sąnaudas

Praktinė logika: jei turite stabilias žinias ir didelį užklausų kiekį – fine-tuning ilgainiui gali atsipirkti. Jei duomenys dažnai keičiasi arba naudojimas neregularus – RAG dažniausiai ekonomiškesnis be didelių pradinių investicijų.

Tikslios sumos skiriasi priklausomai nuo modelio (GPT-4o, Claude, Gemini ar atvirojo kodo alternatyvų), duomenų kiekio ir naudojimo intensyvumo. Kiekvienam konkrečiam atvejui verta atlikti atskirą kaštų analizę.

Advokatų kontora arba apskaitos įmonė. Darbuotojai kasdien ieško atsakymų vidaus dokumentuose, procedūrų aprašuose, sutarčių šablonuose. Dokumentai nuolat atnaujinami – nauja teisės aktų redakcija, naujos instrukcijos. RAG čia tinka geriau: kiekvienas atsakymas remiasi konkrečiu dokumentu, galima nurodyti šaltinį, o dokumento pakeitimas nedidina mokymo kaštų.

E. komercijos platforma. Pokalbių robotas turi atsakinėti klientams apie produktus, kainas, pristatymo sąlygas – informacija keičiasi dažnai. RAG leidžia sinchronizuoti su produktų katalogu realiuoju laiku ir išvengti pasenusių atsakymų.

Klientų aptarnavimo komanda su nišine terminija. Jei bendravimas turi atitikti konkrečią įmonės stilistiką, vartoti specifinius terminus ir laikytis tam tikro tono – fine-tuning gali padėti. Ypač jei turimi keli tūkstančiai pokalbių istorijų duomenų mokymo tikslams.

Gamybos įmonė su techniniais vadovais. Ilgi, kintantys techniniai dokumentai – tai RAG scenarijus. Nuoseklus techninių terminų vartojimas – tai fine-tuning papildymas. Abi priemonės gali veikti kartu.

Sveikatos priežiūros sektorius. Čia abiem metodams keliami griežtesni reikalavimai dėl duomenų jautrumo – daugiau apie tai skyriuje žemiau.

Tai dažnai aplenkiama dalis – ir tai yra klaida, kuri gali kainuoti brangiai.

RAG architektūroje asmens duomenys į modelio parametrus nepatenka. Jei retrieval sistemoje saugomi dokumentai su asmens duomenimis (pvz., klientų susirašinėjimo istorija, medicininiai įrašai), galioja standartinės BDAR taisyklės. Europos Sąjungos Bendrasis duomenų apsaugos reglamentas (BDAR), 5 straipsnis, reikalauja, kad duomenys būtų renkami ir naudojami tik konkretiems, aiškiai apibrėžtiems tikslams – vadinasi, naudoti klientų duomenis, surinktus vienu tikslu, kitai sistemai maitinti gali reikėti atskiro teisinio pagrindo.

Čia rizika didesnė. Jei mokymo duomenyse yra asmens duomenų, jie tampa modelio parametrų dalimi. Tai sukuria kelias konkrečias problemas:

• Asmens duomenys gali „nutekėti" atsakymuose – modelis gali atkurti fragmentus iš mokymo duomenų
• Duomenų subjekto teisė į ištrynimą (BDAR 17 str., vadinamoji „teisė būti pamirštam") praktiškai neįgyvendinama: modelio parametrų „valymas" nuo konkrečių duomenų yra techniškai itin sudėtingas arba neįmanomas
• Jei mokymas atliekamas pas išorinį tiekėją (pvz., per OpenAI, Azure, Google platformas), duomenys fiziškai patenka į jų infrastruktūrą – gali kilti duomenų perkėlimo už ES ribų klausimai

Europos Parlamento 2024 m. patvirtintas Europos Sąjungos dirbtinio intelekto aktas (AI Act) papildomai reikalauja, kad bendrosios paskirties AI modelių kūrėjai atskleistų mokymo duomenų suvestinę informaciją, ypač autorių teisių atžvilgiu.

Praktinė rekomendacija: prieš pasirenkant fine-tuning su turimais klientų ar darbuotojų duomenimis, verta konsultuotis su duomenų apsaugos pareigūnu (DAP) arba teisininku, gerai išmanančiu BDAR taikymą AI sistemoms.

Optimalioje architektūroje abu metodai gali papildyti vienas kitą. Logika paprasta:

• Fine-tuning – modeliui suteikiamas verslo stilius, tonas, terminų vartojimas, elgsenos taisyklės
• RAG – modeliui suteikiamos konkrečios, aktualios žinios realiuoju laiku

Tai reiškia, kad modelis kalba taip, kaip tikisi verslas, bet atsakinėja remdamasis naujausiais dokumentais – ne tik tuo, ko buvo išmokytas.

IBM technologijų analizės teigimu, organizacijos gali derinti abu metodus: fine-tuning naudoti domeninei ekspertizei sukurti, o RAG – realaus laiko organizacinėms žinioms integruoti. Hibridinis kelias reikalauja daugiau techninės kompetencijos ir pradinių investicijų, bet gali duoti geriausią rezultatą ten, kur svarbus ir elgsenos nuoseklumas, ir informacijos tikslumas.

• Jūsų dokumentai ar duomenys keičiasi dažniau nei kas kelis mėnesius

• Svarbu, kad kiekvienas atsakymas turėtų aiškų šaltinį

• Turite konfidencialius duomenis, kurių negalite siųsti mokymo tikslais

• Norite greitai pradėti – be ilgų duomenų ruošimo procesų

• Žinių bazė stabili ir keičiasi retai

• Svarbus pastovus tonas, stilius ar specializuotas žodynas

• Turite pakankamai mokymo pavyzdžių (bent keli šimtai, idealiai – tūkstančiai)

• Galite įvertinti ir priimti duomenų apsaugos rizikas

• Reikia ir tono bei stiliaus kontrolės, ir dinamiškų žinių iš dokumentų

• Verslas pakankamai techniškai subrendęs diegti sudėtingesnę architektūrą

RAG ir fine-tuning nėra konkurentai – tai skirtingų problemų sprendimai. RAG gerai veikia ten, kur svarbios aktualios, kintančios žinios ir skaidrumas. Fine-tuning – ten, kur svarbesnis elgsenos nuoseklumas ir specializuota kalba.

Daugumai Lietuvos verslo projektų, ypač žengiant pirmuosius AI žingsnius, RAG yra logiškesnis pradžios taškas: greitesnis diegimas, žemesnė pradinė investicija, suprantamesnė logika ir mažesnė BDAR rizika.

Jei nesate tikri, kuris metodas tinka jūsų situacijai – WebEdge padeda įvertinti konkrečius verslo poreikius ir parinkti tinkamą AI architektūrą.

RAG – nes nereikia didelio duomenų rinkinio, greičiau diegiamas ir lengviau atnaujinamas. Fine-tuning reikia tik tada, kai RAG nepakanka.

Paprastas RAG su dokumentų baze – nuo €799. Sudėtingesni sprendimai su dideliu duomenų kiekiu – individualiai.

Taip – RAG metodas veikia su bet kokia kalba. Svarbu, kad paieška ir atsakymų generavimas būtų konfigūruoti lietuvių kalbai.

Tai priklauso nuo verslo – kai kurioms įmonėms pakanka kartą per mėnesį, kitoms – realiu laiku sinchronizuoti su CRM ar dokumentų sistema.