Fine-tuning aastal 2026: millal LoRA võidab RAG-i ja kuidas seda teha ilma klastrita

Aastaid oli fine-tuning AI-võimekus, mis enamikule meeskondadele jäi käeulatusest välja. Vaja oli GPU-klastreid, ML-inseneri, nädalaid tööd. Rakendusmeeskondade jaoks ei õigustanud majandus seda peaaegu kunagi.

1. aastal see enam ei kehti. LoRA, QLoRA ja hallatud fine-tuning teenused on inseneritöö muutnud taskukohaseks igale mõistliku inseneripagasiga meeskonnale. Päris LoRA fine-tune'i saad jooksutada ühel tarbija-GPU-l. Saad seda teha hostitud teenuse kaudu vähem kui 100 € arvutusvõimsuse eest. Produktsiooni-valmis fine-tune'itud mudeli saad kahe nädala fokuseeritud tööga.

See nihutab arvestust. Juhtumid, kus fine-tuning 2024. aastal mõtet ei andnud (liiga kallis, liiga keeruline), annavad sageli 2026. aastal. Ja juhtumid, kus meeskonnad vaikimisi valivad RAG-i, peaksid mõnikord hoopis fine-tuning'ut kasutama.

See artikkel käsitleb, millal fine-tuning teisi lähenemisi võidab, mis on väikese meeskonna praktiline töövoog ning millised mustrid eristavad fine-tune'e, mis lähevad tootmisse, neist, mis valmistavad pettumuse.

Millal fine-tuning võidab

Eelmises artiklis puudutasime seda lühidalt; siin on pikem versioon.

1. Vormingu ja struktuuri järjepidevus

Kui vajad väljundeid väga kindlas vormingus, järjepidevalt, võidab fine-tuning promptimise.

Näide: iga väljund peab olema täpselt 5 punkti, igaüks algab tegusõnaga, kindlas toonis. Promptimisega saad 95% kohale. Fine-tuning'uga 99%+.

Fine-tune õpib struktuuri ära kui vaikeoleku; mudel "lihtsalt teeb seda" ilma, et peaksid seda igas promptis uuesti välja ütlema.

2. Stiili/hääle järjepidevus

Tugevate hääle-juhistega ettevõtted leiavad sageli, et ainult promptimine toodab triivi. Tuhandete interaktsioonide jooksul hääl libiseb.

Fine-tuning 1000+ näitel "see on meie hääl" toodab mudeli, mis selle endasse kaasab. Hääl on järjepidev, sest see on osa mudelist, mitte promptijuhis, mida mudel peab meeles pidama.

3. Spetsialiseeritud valdkond või DSL

Kui sinu valdkonnas on ebatavaline terminoloogia, kohandatud DSL või spetsiifilised mustrid, mida baasmudel hästi ei tunne:

Näide: ettevõttel on oma sisemine andmepäringukeel. Baasmudel pole seda kunagi näinud. Promptimisega ja näidetega aitab, aga ei piisa — mudel teeb pidevalt süntaksi vigu.

Fine-tuning 5000 näitel korrektsest koodist selles DSL-is toodab mudeli, mis kirjutab DSL-i sujuvalt. Mudel "oskab" DSL-i samamoodi nagu ta oskab Pythonit.

4. Väiksem mudel, võrreldav kvaliteet

Fine-tune'itud 8B mudel võib mõnikord ühe konkreetse ülesande peal jõuda järele üldisele 70B mudelile. Kasud:

• Odavam inferents (10–50x).
• Kiirem inferents (3–10x).
• Iseseisvalt hostitav tagasihoidlikul riistvaral.
• Etteennustatavam käitumine kitsa ülesande peal.

Kui sul on suuremahulisi kitsaid töökoormusi, võib see märkimisväärselt raha säästa.

5. Käitumuslik turvalisus

Mudeli fine-tuning'ust nii, et see järjepidevalt teatud asjadest keeldub või lisab kindlaid kaitsemehhanisme, on sageli vastupidavam kui prompti-põhised piirded.

Näide: kliendisuunaline AI, mis ei tohi kunagi hindu nimetada (kuna hinnastamine on dünaamiline). Promptimine aitab, aga sellest saab mööda; fine-tuning teeb keeldumise vastupidavaks.

6. Few-shot mustrid skaalal

Kui kasutad igas promptis 10-shot näiteid ja need näited võtavad arvestatava tokenieelarve, on fine-tuning efektiivsem. "Näited" on mudelisse sisse küpsetatud; prompt on lühike.

See on eriti oluline suuremahuliste kasutuste puhul, kus promptitokenid kuhjuvad.

Millal fine-tuning kaotab

Vähemalt sama oluline: millal mitte fine-tune'ida.

1. Teadmised, mis muutuvad

Fine-tune'itud mudelid on hetkepildid. Uus info nõuab ümbertreenimist. Dünaamiliste teadmiste jaoks (jooksvad sündmused, konto-spetsiifilised andmed, uusimad reeglid) tegeleb sellega RAG; fine-tuning mitte.

Kui sinu "mul on fine-tuning'ut vaja" on "mudel peaks meie toote kohta teadma", on see vale. RAG on õige tööriist.

2. Sul pole piisavalt andmeid

Efektiivseks fine-tuning'uks läheb vaja arvestatavat hulka treeningandmeid. Miinimum varieerub:

• LoRA kitsa ülesande jaoks: 500–1000 näidet.
• LoRA mõõduka keerukuse jaoks: 1000–5000.
• Üldisem käitumine: 5000+.

Alla 500 näite ei saa enamasti tähendusrikkalt fine-tune'ida. Few-shot promptimine või RAG töötab tihti paremini.

3. Baasmudel paraneb kiiremini, kui sa järele jõuad

Esirinna mudelid arenevad kiiresti. Aastatagune fine-tune jääb tihti praegusele esirinna mudelile alla, ilma et viimasel oleks üldse fine-tune'i. Fine-tune'ide hoidmine liikuva võrdlusaluse vastu on omaette jooksulint.

Kui sul puudub selge hoolduskava, muutub fine-tuning tehniliseks võlaks.

4. Sa pole prompti/RAG tööd ära teinud

Üllatavalt levinud muster: meeskonnad hüppavad fine-tuning'usse, ilma et oleks tõsiselt promptimist või RAG-i proovinud. Fine-tune läheb välja; kvaliteet on okei; aga nädalane prompti-iteratsioon oleks andnud sama tulemuse 1% hinna eest.

Proovi enne fine-tuning'ut esmalt tõsiselt promptimist ja RAG-i.

5. Sul pole eval'eid

Fine-tuning ilma eval'iteta on hasartmäng. Sa ei tea, kas fine-tune aitas, tegi halvemaks või ei teinud midagi. Paljud "õnnestunud" fine-tune'id on platseebovõidud või isegi tagasiminekud.

Ehita esmalt eval'id. Siis fine-tune.

2026. aasta fine-tuning'u maastik

Lühike ülevaade, mis on saadaval:

Hostitud teenused

Lihtsaim tee. Lae andmed üles, treeni, saa fine-tune'itud API-otspunkt.

• OpenAI fine-tuning. Toetab GPT-4o, GPT-4o-mini ja üha rohkem väiksemaid mudeleid. Töökindel, küps.
• Anthropic fine-tuning. Toetab Claude Haiku perekonda. Saadaval pilvepartnerite kaudu (AWS Bedrock, Google Cloud).
• Google Vertex AI tuning. Toetab Gemini perekonda.
• Together AI, Fireworks, Anyscale. Tune'i avatud lähtekoodiga mudeleid nende taristul.
• Cohere. Tune'i Cohere mudeleid.

Kulud: tüüpiliselt 10–200 € mõõduka fine-tune'i eest (5K–50K näidet) pluss inferents-juurdehindlus baasmudeli kohta.

Millal valida: enamik meeskondi. Mugavus kaalub (mõõduka) hinnapreemia üle.

Iseseisvalt hostitud fine-tuning

Sina paned GPU-d, koodi, taristu.

• Avatud lähtekoodiga mudelid: Llama 4, Qwen 3, Mistral, DeepSeek, Phi, Gemma. Kõik avaldatud piisavalt lubavate litsentsidega fine-tuning'u jaoks.
• Tööriistad: Hugging Face TRL, Axolotl, Unsloth, LLaMA-Factory. Kõik küpsed.
• Arvutusvõimsus: mõõdukate mudelite jaoks tehtav ühel H100-l. Või renditav RunPodist, Lambdast, Vast.ai-st, Modalist hinnaga 1–3 $/tund.

Kulud: 50–500 € arvutusvõimsust tüüpilise LoRA fine-tune'i kohta. Pluss sinu inseneritöö.

Millal valida: kui vajad täielikku kontrolli (kindlad mudelid, kohandatud andmete käsitlus, on-premises juurutus) või kui teed palju fine-tune'e (hostitud teenuste fine-tune'i-põhine kulu kuhjub).

Kerged variandid

Väga väikeste fine-tune'ide jaoks:

• Unsloth tarbija-GPU peal. Tune'i väikseid mudeleid (7B) RTX 4090 peal ühe pärastlõunaga.
• MLX Apple Siliconil. Tune'i väikseid mudeleid Mac Studio peal.
• LoRA Google Colabis. Tasuta või Colab Pro 10–50 €/kuus.

Need sobivad eksperimenteerimiseks, väikeste mudelite ja kontseptsiooni tõestuse fine-tune'ide jaoks.

Praktiline töövoog

Produktsiooni fine-tune'i ehitavale meeskonnale on töövoog järgmine:

Samm 1: Vajaduse valideerimine (1–2 päeva)

Enne mis tahes andmetööd valideeri:

• Kas oled tõsiselt promptimist nädala või rohkem proovinud?
• Kas oled RAG-i proovinud, kui teadmised on mängus?
• Kas sul on eval'id, mis näitavad, et praegune lähenemine ei piisa?
• Kas oskad sõnastada, mida konkreetselt fine-tune peaks paremini tegema?

Kui sa ei vasta neile kõigile jaa, siis ära veel fine-tune.

Samm 2: Eval'ide ehitamine (1 nädal)

Ilma eval'iteta on fine-tuning hasartmäng.

• Koosta eval-komplekt (100–500 näidet), mis katab sihtkäitumist.
• Defineeri mõõdikud: kuidas õnnestumine välja näeb? Vormingule vastavus, hääle sobivus, täpsus jne.
• Lähtejoon: jooksuta eval baasmudeli peal. Pane praegune skoor kirja.

Seda vajad selleks, et teada saada, kas fine-tune aitas.

Samm 3: Andmete ettevalmistus (1–3 nädalat)

Suurim osa tööst. Treeningandmete kvaliteet määrab fine-tune'i kvaliteedi.

Allikad:

• Olemasolevad kõrge kvaliteediga väljundid sinu meeskonnalt.
• Kureeritud varasemad kliendisuhtlused.
• Genereeritud näited (kasuta tugevat mudelit + hoolikat promptimist).
• Kliendi-spetsiifilised andmed (kui kohane; arvesta lubasid ja PII-d).

Vorming:

Tüüpiline vorming jututoa fine-tuning'u jaoks:

{
  "messages": [
    {"role": "system", "content": "..."},
    {"role": "user", "content": "..."},
    {"role": "assistant", "content": "..."}
  ]
}

Üks näide rea kohta JSONL-is.

Maht:

• LoRA kitsas ülesanne: 500–2000 näidet.
• LoRA mõõdukas ülesanne: 2000–10000.
• Üldine käitumine: 10000+.

Rohkem on tavaliselt parem, kuid teatud piirini. Pärast ~50K näidet kahanev tulu.

Kvaliteet > kogus.

500 kõrge kvaliteediga järjepidevat näidet võidab 5000 keskpärast. Parem kulutada rohkem aega väiksemate näidete kureerimisele, kui visata sisse hulk keskpäraseid.

Mitmekesisus.

Andmestik peab katma kogu sisendite ringi, millega kokku puutud. Kui treenid ainult lihtsate juhtumite peal, kukub mudel raskete peal läbi. Kui treenid ainult servajuhtumite peal, ülekorrigeerid.

Turvalisuse/keeldumise andmed.

Lisa näiteid kohastest keeldumistest. Muidu muutuvad fine-tune'itud mudelid sageli järelandlikumaks (teevad kõike) — turvalisuse tagasiminek.

Treeni/eval jaotus.

Hoia 5–10% evalueerimiseks kõrvale. Ära kunagi treeni selle peal; kasuta ainult kvaliteedi mõõtmiseks.

Samm 4: Treeningu jooksutamine (1 päev kuni 1 nädal)

Hostitud teenuste jaoks:

# OpenAI näide. Esmalt lae failid üles; API ootab faili-ID-sid,
# mitte kohalikke teid, training_file / validation_file jaoks.
train = client.files.create(file=open("training.jsonl", "rb"), purpose="fine-tune")
val   = client.files.create(file=open("validation.jsonl", "rb"), purpose="fine-tune")

client.fine_tuning.jobs.create(
    training_file=train.id,
    validation_file=val.id,
    model="gpt-4o-mini",
    hyperparameters={
        "n_epochs": 3,
        "batch_size": 8,
        "learning_rate_multiplier": 1.0,
    },
)

Oota lõpetamiseni. Tundidest päevadeni sõltuvalt andmestiku suurusest ja teenuse koormusest.

Iseseisvalt hostituks (Axolotliga):

base_model: meta-llama/Llama-3.1-8B
load_in_4bit: true

adapter: lora
lora_r: 16
lora_alpha: 32
lora_dropout: 0.05
lora_target_modules:
  - q_proj
  - v_proj
  - k_proj
  - o_proj

datasets:
  - path: ./data/train.jsonl
    type: chat_template

num_epochs: 3
micro_batch_size: 2
gradient_accumulation_steps: 4
learning_rate: 0.0002
warmup_steps: 100

output_dir: ./output

Käivita: accelerate launch -m axolotl.cli.train config.yaml

Tundide jagu treeningut ühel GPU-l.

Hüperparameetrid, mis on olulised:

• Epohhid: tüüpiliselt 1–5. Rohkem võib üle-fittida. Jälgi valideerimiskadu.
• Õppimismäär: 1e-5 kuni 5e-4 sõltuvalt lähenemisest. LoRA talub kõrgemaid määrasid kui täielik fine-tuning.
• LoRA aste (r): 8–64. Kõrgem = rohkem mahtu, suurem üle-fittimise risk.
• Partii suurus: nii suur, kui mälu lubab.

Esimese fine-tune'i jaoks kasuta tuntud retsepti vaikeväärtusi. Optimeeri hüperparameetreid ainult siis, kui sul on eval'id, mis seda juhivad.

Samm 5: Hindamine (3–5 päeva)

Jooksuta eval-komplekt fine-tune'itud mudeli peal.

• Kas skoor paranes baasi suhtes?
• Kui palju?
• Kas miski läks tagasi (üldised võimed, turvalisus, servajuhtumid)?

Levinud mustrid:

• Tugev paranemine sihtülesandel, väike tagasiminek mujal: kitsa kasutuse jaoks vastuvõetav.
• Tugev paranemine sihtülesandel, suur tagasiminek mujal: üle-treenitud. Vähenda epohhe või LoRA astet.
• Marginaalne paranemine: andmeid võib olla vähe või on need madala kvaliteediga. Itereeri andmete, mitte hüperparameetrite peal.
• Pole paranemist: midagi on valesti. Kontrolli andmete vormingut, treeningu logisid, eval-metoodikat.

Samm 6: Produktsioonis testimine (1–2 nädalat)

Enne täielikku juurutust tee A/B test:

• 5–10% produktsiooni liiklusest kasutab fine-tune'i.
• 90–95% kasutab baasi.
• Võrdle mõõdikuid: kvaliteediskoorid, kasutajate tagasiside, allavoolu signaalid.

Pärast 1–2 nädalat andmeid otsusta: täielik kasutuselevõtt, rohkem iteratsiooni või tagasipööre.

Samm 7: Juurutamine (1–2 päeva)

Hostitud teenuste jaoks: lihtsalt suuna fine-tune'itud mudeli ID peale. Triviaalne.

Iseseisvalt hostitu jaoks: püsti inferentsserver (vLLM on standard). Lae LoRA adapter sisse. Suuna liiklus.

Samm 8: Monitoorimine (pidev)

Fine-tune on tootmises. Jälgi:

• Kvaliteedimõõdikuid (online eval'id, kasutajate tagasiside).
• Triivi ajas.
• Kas baasmudeli paranemised on lõhe sulgenud (regulaarselt hinda uuesti uusima baasi vastu).

Samm 9: Hooldus (iga 3–6 kuu tagant)

Fine-tune pole "tee korra ja unusta".

• Baasmudel uueneb: fine-tune'i uue baasi peal perioodiliselt.
• Andmed triivivad: värskenda treeningandmeid, et need peegeldaksid praeguseid mustreid.
• Eval-komplekt laieneb: valideeri uuesti, kui uued testjuhtumid tekivad.

Levinud muster: kvartaalne ümbertreenimise tsükkel. Värskenda andmed, jooksuta treening, hinda, juuruta, kui parem.

Läbi tehtud näide

Reaalse maailma juhtum: fine-tuning klienditoe hääle jaoks.

Probleem: SaaS-ettevõttel on tugev, sõbralik, lihtsa keelega hääl klienditoe suhtluses. Promptid suutsid seda ligilähedaselt jäljendada, aga ebajärjepidevalt. Meeskond tahtis usaldusväärset hääle sobivust kõigis AI-abilistes suhtlustes.

Andmed: 3500 ajaloolist klienditoe tiketit, kus vastus oli kõrge kvaliteediga (hinnatud vanem-tugiteenuste personali poolt). Iga kureeritud PII eemaldamiseks ja standardiseeritud järjepidevale vormile.

Lähenemine: LoRA fine-tune Claude 3.5 Haiku peal AWS Bedrocki kaudu.

Hüperparameetrid: rank=16, 3 epohhi, vaikeväärtus õppimismääral.

Kulu: ~80 € arvutusvõimsuse eest, pluss 2 nädalat inseneritööd (peamiselt andmete ettevalmistus).

Tulemus: hääle järjepidevus kõrvale jäetud eval-komplekti peal paranes 72%-lt 94%-le (kohtunik: vanem-tugiteenuste juhi hinnang). Kasutajale nähtavad suhtlused "tundusid rohkem meie omadena" kvalitatiivses ülevaates.

Hooldus: kvartaalne ümbertreenimine, kui uusi kõrge kvaliteediga tikette kogunevad. Iga ümbertreenimine võtab päeva tööd.

ROI: meeskond hindab ~15% kliendirahulolu paranemist AI-abistatud tikettidel. Raske täpselt omistada, aga hääle järjepidevus oli märgatav täiendus.

Nii näeb välja edukas produktsioonifine-tune. Mitte maagia; lihtsalt distsiplineeritud andmetöö, tagasihoidlik arvutusvõimsus ja hea hindamine.

Levinud läbikukkumise režiimid

Mõned mustrid:

Läbikukkumine 1: Üle-fitt väikestel andmetel. 500 näidet, 10 epohhi. Mudel jätab treeningkomplekti pähe ja kukub päris sisendite peal läbi. Lahendus: rohkem andmeid või vähem epohhe.

Läbikukkumine 2: Katastroofiline unustamine. Raske treening kitsastel ülesannetel halvendab üldisi võimeid. Mudelist saab hea sinu asjas ja halvem teistes asjades. Lahendus: madalam õppimismäär, vähem epohhe või kaasa mitmekesiseid mitte-ülesande andmeid.

Läbikukkumine 3: Andmevormingu mittevastavus. Treeningandmed vormindatud erinevalt sellest, kuidas mudelit produktsioonis kasutatakse. Fine-tune õpib vale jaotuse. Lahendus: tagada, et treeningu ja inferentsi vormingud täpselt ühtiksid.

Läbikukkumine 4: Eval'i ebapiisav kate. Eval-komplekt on lihtne; produktsioon raske. Fine-tune skooreerib eval'idel hästi; kukub päris kasutajate peal läbi. Lahendus: kaasa raskeid juhtumeid eval'idesse.

Läbikukkumine 5: Hüperparameetrite kaos. Hüperparameetrite näpistamine ilma metoodikata. Vahel parem, vahel halvem, õppimist pole. Lahendus: muuda ühte asja korraga, hinda, õpi.

Läbikukkumine 6: Hoolduse väljakukkumine. Fine-tune läheb välja, meeskond liigub edasi, mudel muutub seisma jäänuks. Kuus kuud hiljem on baasmudeli paranemised selle iganenuks muutnud. Lahendus: planeeri ümbertreenimine.

Läbikukkumine 7: Ebapiisav tähelepanu turvalisusele. Fine-tuning sageli nõrgendab vaikimisi keeldumisi. Ilma turvalisuse näidete kaasamiseta võib fine-tune'itud mudel järele anda asjades, milles baas ei annaks. Lahendus: kaasa treeningandmetesse keeldumise näiteid.

Läbikukkumine 8: Valele mõõdikule tune'imine. Treening surub mudeli kindla mõõdiku poole, aga tegelik kasutajaväärtus on midagi muud. Lahendus: vali mõõdikud, mis sobivad kasutajaväärtusega, mitte lihtsalt kergesti mõõdetavad asendid.

Konkreetsed retseptid, mis töötavad

Mõned arvamuslikud retseptid:

Retsept 1: Vormingu-range struktureeritud väljund

Eesmärk: Usaldusväärne JSON väljund kindlas skeemis.

Andmed: 2000 näidet (sisend, kehtiv JSON-väljund).

Retsept: LoRA, rank=8, 3 epohhi, väikese mudeli peal (8B). Kombineeri inferentsi ajal piiratud genereerimisega.

Tulemus: 99%+ skeemile vastavus, väga kiire.

Retsept 2: Hääle sobivus

Eesmärk: Järjepidev brändihääl kliendisuunalises sisus.

Andmed: 3000+ näidet (prompti-kontekst, hääles olev väljund). Kureeritud inimeste poolt, kes oskavad hääle sobivust hinnata.

Retsept: LoRA, rank=16, 2–3 epohhi, keskmise mudeli peal (8–70B). Madalam õppimismäär (1e-4) stabiilsuse jaoks.

Tulemus: Hääle järjepidevus, mida ainult promptid ei suudaks ühilduda.

Retsept 3: Spetsialiseeritud DSL või valdkond

Eesmärk: Koodi genereerimine kohandatud DSL-is.

Andmed: 5000–20000 näidet (kirjeldus, kehtiv kood).

Retsept: LoRA koodile spetsialiseeritud mudeli peal (Code Llama, DeepSeek Coder), rank=32, 3–5 epohhi. Kõrgem õppimismäär (2e-4) on koodi jaoks tihti okei.

Tulemus: Sujuv DSL-i genereerimine.

Retsept 4: Väiksem mudel, võrreldav kvaliteet

Eesmärk: Asenda suurem mudel väiksema fine-tune'itud variandiga kulu/latentsuse jaoks.

Andmed: 10K–50K näidet, mille suurem mudel genereeris päris sisendite peal (sünteetilised andmed).

Retsept: LoRA väikese mudeli peal (8B), rank=16, 2–3 epohhi. Inferents vLLM-iga läbilaskvuse jaoks.

Tulemus: 5–10x kulu vähendamine, võrreldav kvaliteet kitsa ülesande peal.

Retsept 5: Turvalisuse/keeldumise fine-tune

Eesmärk: Vastupidav keeldumine kindlate problemaatiliste kategooriate puhul.

Andmed: 1000–3000 näidet (probleemne taotlus, kohane keeldumine) pluss 1000+ näidet tavalistest interaktsioonidest (et mudel ei keelduks liialt).

Retsept: LoRA, rank=8, 2 epohhi, madal õppimismäär (5e-5) peenete käitumismuutuste jaoks.

Tulemus: Usaldusväärne sihtkategooriate keeldumine, säilitades samal ajal abivalmiduse legitiimsete taotluste puhul.

Strateegiline küsimus

Mehaanikast väljaspool on fine-tuning strateegiline küsimus:

• Kas tahame sellesse võimekusse pikas plaanis investeerida või kasutada kõige jaoks esirinna mudeleid?
• Kas oleme valmis fine-tune'i määramatult hooldama?
• Kas kvaliteedi võit on jätkuva keerukuse väärt?

Enamikule meeskondadele on vastus: fine-tune'i valikuliselt konkreetsete suuremahuliste või kõrge strateegilise väärtusega kasutuste jaoks; kasuta esirinna mudeleid kõige muu jaoks. Paljude fine-tune'ide hooldamine on operatsiooniliselt kallis.

Meeskonnad, kes fine-tuning'ust kõige rohkem välja võtavad, on need, kes oma lahingud valivad. Üks-kaks fine-tune'i, hästi hooldatud, selge ROI-ga. Mitte poole-hooldatud fine-tune'ide laevastik.

Kokkuvõte

Fine-tuning 2026. aastal on kättesaadav viisil, milles ta hiljuti polnud. LoRA, hostitud teenused ja odav arvutusvõimsus tähendavad, et väike meeskond saab produktsioonifine-tune'i välja saata 2–4 nädalaga alla 500 € arvutusvõimsuse eest.

Sellega öeldes on fine-tuning enamiku "AI pole piisavalt hea" probleemide juures ikkagi vale vastus. Proovi tugevalt promptida. Proovi RAG-i. Pane eval'id paika. Alles siis võta fine-tuning ette, ja ainult siis, kui suudad selgelt sõnastada, millist lõhet see peaks sulgema.

Kui lõhe on õige — range vorming, järjepidev hääl, spetsialiseeritud valdkond, kulu optimeerimine suuremahuliste ülesannete jaoks — toodab fine-tuning päris, kestva võidu. Lihtsalt ole distsiplineeritud andmetes, eval'ides ja hoolduses.

Õigete probleemide jaoks on fine-tuning vahe "AI, mis enamasti töötab" ja "AI, mis lihtsalt töötab" vahel. Seda tasub korralikult teha.