Fine-tuning (peenhäälestus) vs prompt engineering: mis vahe on ja kuidas valida?
Kui tahad, et suur keelemudel (LLM) annaks stabiilseid, õige vorminguga ja ärile sobivaid vastuseid, on sul tavaliselt kolm hooba: prompt engineering, RAG ja fine-tuning. See leht aitab sul kiiresti otsustada, milline lähenemine (või kombinatsioon) on sinu kasutusjuhtumi jaoks mõistlik.
- prompt engineering
- fine-tuning / peenhäälestus
- RAG (teadmisteotsing)
- kvaliteet + kulud + kontroll
- Selge võrdlus (eelised, piirangud, riskid) ilma “hype’ita”.
- Otsustusraamistik, mis vähendab katsetamise aega ja kulusid.
- Praktilised näited (mida teha promptides, millal treenida, millal otsida dokumentidest).
Kiireim kontakt: info@bastelia.com (saada 2–3 näidet: sisend + soovitud väljund + piirangud).
Kiire vastus: mida valida, kui sul on kiire?
- Alusta prompt engineering’uga (kiire, odav, pööratav).
- Lisa RAG, kui pead vastama ettevõtte dokumentidest / teadmistebaasist (ja tahad vähendada “väljamõeldud” vastuseid).
- Tee fine-tuning, kui vajad väga stabiilset käitumist (vorm, toon, reeglid, klassifikatsioon) ja prompt + RAG ei anna enam piisavalt kvaliteeti või kulu/latentsus läheb suureks.
Kiire start Madalam risk
Kujundad sisendi (prompti) nii, et mudel käituks õigesti: roll, eesmärk, kontekst, piirangud, näited ja väljundi vorming.
Parim siis, kui: tahad kiiresti prototüüpi, reeglid muutuvad tihti või vajad paindlikkust.
Teadmistega vastused Audititavus
Mudel ei “arva”, vaid otsib enne vastamist sinu kontrollitud allikatest (wiki, PDF-id, protseduurid, lepingud, helpdeski artiklid).
Parim siis, kui: ettevõtte teadmised on killustunud ja vaja on allikapõhist täpsust.
Nõuab andmeid Rohkem kontrolli
Treenid (peenhäälestad) mudeli käitumist näidete abil, et ta oleks konkreetse ülesande/stiili jaoks “spetsialist”.
Parim siis, kui: vajad väga ühtlast vormingut, järjepidevat toon/stiili või erialast “käitumist”, mida promptiga on raske lukustada.
Mõisted: mida need tegelikult tähendavad?
Mis on prompt engineering (promptide inseneeria)?
Prompt engineering tähendab sisendi disainimist nii, et mudel annaks võimalikult õige vastuse ilma mudelit ümber treenimata. Praktikas on see kombinatsioon:
- eesmärgi ja rolli selgitamisest (mida mudel teeb ja kelle “rollis”);
- konteksti lisamisest (andmed, reeglid, definitsioonid);
- piirangutest (mida ta ei tohi teha, millal peab “ei tea” ütlema);
- näidetest (few-shot) ja väljundi vormingust (nt JSON, tabel, sammud).
Mis on fine-tuning (peenhäälestus)?
Fine-tuning tähendab mudeli kohandamist näidete abil, et ta käituks kindlal moel. Oluline nüanss: peenhäälestus on tavaliselt käitumise treenimine (stiil, struktuur, klassid, reeglipõhine otsus), mitte “lõputu faktibaasi õpetamine”.
Kui sinu probleem on “mudel peab teadma meie sisemisi protseduure, hindu, lepingupunkte”, siis on enamasti mõistlik alustada RAG-ist (allikapõhine otsing) – see on kiirem uuendada ja kontrollitavam.
Mis on RAG (Retrieval‑Augmented Generation)?
RAG ühendab LLM-i sinu andmetega: enne vastamist otsib süsteem relevantse info dokumentidest, lisab selle konteksti ja palub mudelil vastata ainult leitud materjalile tuginedes. Nii saad:
- vähem “hallutsinatsioone” (väljamõeldud fakte),
- parema jälgitavuse (millisele allikale vastus tugines),
- lihtsama uuendamise (muudad dokumenti, mitte mudeli kaalu).
Võrdlustabel: prompt engineering vs fine-tuning vs RAG
| Aspekt | Prompt engineering | RAG | Fine-tuning / peenhäälestus |
|---|---|---|---|
| Eesmärk | Suuna mudelit paremini vastama ilma treenimiseta. | Pane mudel vastama sinu dokumentidest/andmetest. | Kohanda mudeli käitumist (stiil, klassid, vorming, reeglid). |
| Kiirus | Väga kiire (tunnid/päevad iteratsiooni). | Kiire (päevad/nädalad, sõltub andmetest ja integratsioonist). | Aeglasem (andmekogu + treening + testimine). |
| Vajab andmeid? | Vähe: reeglid, näited, juhised. | Jah: dokumendid/teadmistebaas + otsingu struktuur. | Jah: kvaliteetsed sisend–väljund näited, märgistus, QA. |
| Kontroll ja stabiilsus | Hea, aga sõltub promptist ja kontekstist. | Hea, kui retrieval on tugev ja allikad korras. | Väga hea vormingu/stiili ja ülesande stabiilsuseks. |
| Uuendatavus | Lihtne: muudad prompti. | Väga lihtne: muudad dokumente/indeksit. | Keskmine: tihti vaja uut treeningut või uusi näiteid. |
| Kulud | Madalamad (peamiselt iteratsioon + testimine). | Keskmised (otsing, indeks, monitooring). | Keskmised–kõrgemad (treening, andmestik, hooldus). |
| Millal eelistada? | Kui tahad kiiresti “tööle saada” ja reeglid muutuvad tihti. | Kui täpsus sõltub ettevõtte teadmistest (protseduurid, poliitikad, tooted, lepingud). | Kui vajad ühtlast käitumist suurel mahul (klassifikatsioon, ekstraktsioon, toon, formaadid, reeglipõhine stiil). |
Märkus: praktikas kasutatakse sageli kombinatsiooni. Näiteks RAG + prompt engineering (kõige levinum) või RAG + fine-tuning (kui lisaks teadmistele on vaja väga kindlat väljundistruktuuri).
Prompt engineering: parimad praktikad, mis annavad päriselt tulemuse
1) Kirjelda roll, eesmärk ja “edu”
Paljud promptid ebaõnnestuvad, sest eesmärk on udune: “tee parem vastus” ei ole mõõdetav. Kirjelda, mis on edukas väljund (nt “tagasta JSON väljad A/B/C”, “anna 3 varianti”, “ära tee oletusi”).
2) Loo piirangud ja “stop-reeglid”
Kui kasutusjuhtum nõuab täpsust, lisa reegel: kui info puudub, ütle “ei tea” ja küsi täpsustust. See on lihtne, aga vähendab riski, et mudel hakkab “täitma tühimikku”.
3) Lukusta väljundi vorming
Kui väljund peab minema süsteemi (CRM, helpdesk, BI), määra formaat konkreetselt. Näiteks: “tagasta ainult JSON, ilma lisakommentaarideta”.
Prompti “skeem”, mis sobib enamikule B2B kasutusjuhtumitele
ROLL: Sa oled [roll], eesmärk on [äriline tulemus].
KONTEKST: Siin on vajalik info / definitsioonid / reeglid: [...]
ÜLESANNE: Tee [konkreetne tegevus].
PIIRANGUD:
- Ära kasuta teadmisi väljaspool antud konteksti.
- Kui info puudub, ütle "EI TEA" ja küsi 1 täpsustav küsimus.
VÄLJUND:
- Vorming: [JSON/tabel/sammud]
- Väljad: [A, B, C]
NÄITED:
- Sisend: ...
Väljund: ...Kui sul on mitu tiimi, siis standardiseeri promptide struktuur (mall) ja hoia versioonihaldust. Nii väldid olukorda, kus “kõigil on oma prompt” ja kvaliteet kõigub.
Fine-tuning (peenhäälestus): millal see päriselt tasub?
Millal peenhäälestus annab kõige rohkem väärtust?
Fine-tuning on mõistlik siis, kui probleem ei ole ainult “õige info leidmine”, vaid õige käitumine: sama vorming iga kord, kindel toon, stabiilne klassifikatsioon, järjepidev otsustus loogika.
- Struktureeritud ekstraktsioon (dokumendist väljad, reeglid, tüübid) suurel mahul.
- Klassifikatsioon ja routing (piletite kategooriad, prioriteet, SLA, “mis tiimile”).
- Toon ja stiil (brändikeel, terminoloogia, lühidus/pikkus) väga järjepidevalt.
- Domain-spetsiifiline “käitumine” (nt kindel otsustuspuu, ettevõtte standardid).
Millal peenhäälestus EI ole esimene valik?
- Kui vajad värsket või muutuvat infot (siis RAG on tavaliselt parem).
- Kui sul pole veel kvaliteetseid näiteid (andmestik on “mürane”).
- Kui probleem lahendub juba hästi prompt + RAG kombinatsiooniga.
Mida on vaja heaks fine-tuning’uks?
Sisend–väljund paarid peavad olema ühes stiilis ja “õiged”. Kui näidetes on vastuolud, “õpib” mudel vastuolusid.
Enne/peale võrdlus: samad ülesanded, samad mõõdikud. Ilma testita ei tea sa, kas kvaliteet päriselt paranes või lihtsalt “tundub parem”.
Kui reeglid või andmed muutuvad, pead teadma, kas piisab prompti muutmisest, RAG-ist või vajad uut treeningut.
Kui sinu soov on lisada ettevõtte teadmised (protseduurid, poliitikad), on RAG tavaliselt esimene samm. Kui sinu soov on, et vastus oleks alati kindlas struktuuris ja stiilis, siis fine-tuning on tugev kandidaat.
RAG: kui sul on oma dokumendid, siis alusta siit
Miks RAG on paljudele ettevõtetele “kõige mõistlikum” järgmine samm?
Enamik B2B kasutusjuhtumeid vajab sisemisi teadmisi: protseduurid, tooted, SLA-d, lepingud, hinnastamine, poliitikad. Kui mudel peab seda kõike “mäletama”, muutub peenhäälestus raskeks ja aeglaseks – ning iga muudatus nõuab uut ringi.
RAG-i puhul uuendad teadmisi nagu teadmistebaasi: muudad dokumenti või lisad uue, indeks ajakohastub ja vastused lähevad paremaks.
Mida hea RAG-lahendus sisaldab?
- õiged allikad (ainult need, mida tohib kasutada);
- õigused ja ligipääsud (kõik ei näe kõike);
- kvaliteetne retrieval (mudel saab ette “õige lõigu”);
- vastuse reeglid (“ütle ei tea”, kui katvus puudub);
- logid ja monitooring (mida küsitakse, mis töötab, mis mitte).
Otsustusraamistik: samm‑sammult (et mitte raisata aega ja eelarvet)
- Defineeri ülesanne: mis on sisend, mis on “õige” väljund, mis on KPI.
- Prompt engineering baseline: mall, näited, vorming, stop‑reeglid.
- Kui info on ettevõtte dokumentides → lisa RAG (allikad + õigused + retrieval).
- Kui vaja on stabiilset vormi/klassifikatsiooni → kaalu fine-tuning’ut (kvaliteetsed näited + test).
- Industrialiseeri: logid, testid, kulude kontroll, monitooring, tagasisidering.
Mini‑otsustuspuu (lihtsalt loetav)
| Küsimus | Kui vastus on “jah” | Soovitus |
|---|---|---|
| Kas mudel peab vastama sinu sisemistest dokumentidest? | Vastus sõltub otseselt allikatest. | RAG + tugev prompt (allikapõhine reegel). |
| Kas väljund peab olema alati sama struktuuriga (nt JSON väljad)? | Väikesed variatsioonid tekitavad süsteemis vigu. | Alusta prompt + testid; kui kõigub, kaalu fine-tuning’ut. |
| Kas ülesanne on klassifikatsioon / routing suurel mahul? | Vaja on stabiilsust ja madalat latentsust. | Fine-tuning (või väiksem kohandus) + lihtne prompt. |
| Kas reeglid/stiil muutuvad tihti? | Vaja kiiret kohandust. | Prompt engineering + mall + versioonihaldus. |
| Kas risk (GDPR, compliance) on kõrge? | Vaja audititavust ja kontrolli. | RAG (õigused) + logid + “ei tea” reeglid + human‑in‑the‑loop. |
Kui tahad, saadame sulle e‑posti teel kiire “sobivuse hinnangu” (mida teha 1. sammuna ja mida mitte). Kirjuta: info@bastelia.com.
Kvaliteet, testimine ja kontroll: kuidas vältida “demo töötab, tootmises laguneb” olukorda
1) Loo testikomplekt enne, kui “optimeerima” hakkad
Võta 30–100 tüüpilist juhtumit (sisend + oodatud väljund). See on sinu “kuldstandard”. Ilma selleta on lihtne kulutada nädalaid promptide kohendamisele, teadmata, kas tulemus päriselt paraneb.
2) Mõõda, mitte ära “tunne”
- Struktuuri kvaliteet: kas JSON väljad on täidetud ja korrektsed?
- Täpsus: kas vastus tugineb lubatud allikale (RAG) ja on sisuliselt õige?
- Stabiilsus: kas sama sisend annab sarnase väljundi?
- Kulu ja latentsus: kui palju “maksab” üks päring ja kui kiire on vastus?
3) Pane paika guardrail’id
- “Ei tea” reegel (kui allikas puudub või confidence madal).
- Õigused (kes tohib näha millist dokumenti / andmevälja).
- Logimine (milline prompt, milline allikas, milline tulemus).
- Eskalatsioon inimesele (erandid, riskijuhtumid, compliance).
Kui keegi vahetub tiimis, peab lahendus jääma tööle: olemas on prompti versioonid, testid, logid, monitooring ja selge omanik. Vastasel juhul on see “käsitöö”, mis varem või hiljem kukub läbi.
Levinud vead (ja kuidas neid vältida)
Kui sul pole veel testikomplekti ja prompt baseline’i, on peenhäälestus sageli kallis “pimedas jooksmine”. Tee enne: selge ülesanne + prompt mall + mõõdikud.
Kui dokumendid on vanad, dubleeritud või vastuolulised, toob RAG välja “halva tõe” kiiremini. Tee enne: allikate korrastus + ligipääsud + versioonid.
Kui väljund peab minema süsteemi, peab formaat olema range. Tee: vormingureegel + valideerimine + fallback (“küsi täpsustust”).
Veel 5 kiiret “kontrollküsimust”
- Kas sul on üks standardne prompti mall (mitte 10 erinevat)?
- Kas sul on “ei tea” ja eskalatsiooni loogika?
- Kas sa saad hiljem aru, miks mudel nii vastas (logid + allikad)?
- Kas sa mõõdad kulusid ja kvaliteeti samas kohas?
- Kas sa tead, millal reeglimuudatus nõuab prompti, RAG-i või treeningut?
Kuidas Bastelia saab aidata (ilma vormideta, otse ja selgelt)
Kui soovid, et LLM töötaks ettevõttes mõõdetava tulemusega (kvaliteet, aeg, kulud, risk), aitame valida õige kombinatsiooni: prompt engineering + RAG + (vajadusel) fine-tuning.
Kirjuta info@bastelia.com ja lisa 2–3 näidet (sisend + soovitud väljund). Vastame lühikese plaaniga: mis on kõige kiirem “time‑to‑value” samm ja millised on riskid/alternatiivid.
Kui soovid minna teooriast teostuseni, vaata neid lehti: