Valik promptingu, RAG-i ja peenhäälestuse vahel (ja millal kombineerida)

Tiim saab briifi: „tee meie AI meie konkreetse kasutusjuhtumi käsitlemises paremaks". Neil on mõned valikud, kuidas seda teha. Nad võivad kirjutada paremaid prompte. Nad võivad ehitada RAG-süsteemi, et mudelile asjakohaseid andmeid sööta. Nad võivad peenhäälestada mudelit oma valdkonna näidete põhjal.

Need ei ole vahetatavad. Nad lahendavad erinevaid probleeme. Valesti tehtuna kulutad kolm kuud ja eelarve peenhäälestusele, kui vastus oli parem prompt. Või ehitad keerukat RAG-infrastruktuuri, kui peenhäälestus oleks olnud lihtsam. Või jääd promptide juurde toppama, kui mudel fundamentaalselt ei suuda teha, mida sa vajad.

See artikkel on raamistik valimiseks — millal on igaüks õige tööriist, millal neid kombineerida, iga reaalsed kulud ja mis on toodangus läinud õigesti ja valesti.

Mida igaüks tegelikult teeb

Selge eristus:

Prompting muudab seda, mida mudelilt küsitakse. Sa annad mudelile paremaid juhiseid, näiteid, vormingunõudeid, konteksti. Mudel ise ei muutu; sisend muutub.

RAG muudab seda, milliseid andmeid mudel näeb. Sa hangid asjakohast infot päringu hetkel ja lisad selle prompti. Mudelil on värsked, spetsiifilised, dünaamilised andmed ilma neid treeningu kaudu õppimata.

Peenhäälestus muudab seda, mida mudel teab või kuidas käitub. Sa treenid mudelit näidete põhjal, muutes selle kaale. Mudel ise saab uuenduse.

Need lahendavad erinevaid probleeme:

• Juhise lõhe: mudel oskaks ülesannet teha, kui õigesti küsida. → Prompting.
• Teadmise lõhe: mudel vajab infot, mida tal pole. → RAG.
• Võimekuse lõhe: mudel ei suuda usaldusväärselt ülesannet teha isegi heade promptide ja kontekstiga. → Peenhäälestus.

Teades, milline lõhe sul on, on pool võitu.

Lõhe diagnoosimine

Kui AI ei tee seda, mida sul vaja on, küsi:

Kas tark inimene, ainult prompti põhjal, oskaks seda ülesannet teha?

Kui jah → juhise lõhe. Parem prompt peaks aitama.

Kui ei, kas ta oskaks seda teha, kui annaksid talle asjakohast viitematerjali?

Kui jah → teadmise lõhe. RAG võib aidata.

Kui ei, kas ta oskaks seda teha pärast põhjalikku praktikat ja tagasisidet?

Kui jah → võimekuse lõhe. Peenhäälestus võib aidata.

Kui ei → võib-olla pole see ülesanne LLM-i poolt lahendatav. Mõtle probleem üle.

Enamik „AI ei tööta" probleeme on juhise lõhed — parem promptimine lahendab need. Järgmised levinumad on teadmise lõhed. Päris võimekuse lõhed on väikseim kategooria, kuid kõige raskem käsitleda.

Prompting: alahinnatud hoob

Prompting on odavaim, kiireim ja kõige sagedamini õige vastus. Sellegipoolest hüppavad tiimid sellest mööda RAG-i või peenhäälestuse juurde.

Mõned asjad, mida saab promptingiga üksi teha:

• Muuta tooni, vormingut, pikkust.
• Rakendada arutluse mustreid (mõtteahel, enesekriitika).
• Kodeerida piiranguid (tee X, ära tee Y).
• Kodeerida poliitikaid ja turvapiireid.
• Kohaneda konkreetsete kasutusjuhtumitega (erinevad promptid erinevate funktsioonide jaoks).
• Parandada järjepidevust mõne näite (few-shot) abil.

Mida ei saa promptingiga üksi teha:

• Panna mudelit teadma fakte, mida ta ei tea.
• Panna väike mudel käituma nagu suur mudel.
• Fundamentaalselt muuta mudeli häält või stiili sügaval tasemel.
• Kiirendada mudeli järeldust.

Mõistlik reegel: proovi enne RAG-i või peenhäälestuse poole pöördumist promptingit kõigepealt, itereeri vähemalt nädala. Enamasti leiad, et prompting lahendab probleemi.

Prompti inseneri tööpanus

Nädal intensiivset prompti iteratsiooni võib toota dramaatilisi parandusi. Tüüpiline kõver:

• Päev 1: põhitase. Keskpärased tulemused.
• Päev 2–3: struktuurimuudatused. Parem vorming, selgemad juhised. Suured parandused.
• Päev 4–5: näited ja piirjuhud. Püüab ebaõnnestumise režiimid kinni.
• Päev 6–7: toon, piirangud, viimistlus. Viimane 10% paranemist.

Pärast nädalat oled välja tõmmanud enamiku sellest, mida prompting saab anda. Kui sa pole endiselt rahul, on lõhe ilmselt teadmistes või võimekuses.

Millised head promptid välja näevad

Viiteks, tugeval promptil on tavaliselt:

• Selge roll ja ülesanne.
• Konkreetsed vormingunõuded.
• 1–5 esinduslikku näidet (kui vaja).
• Selgesõnalised piirangud (mida teha, mida mitte).
• Piirjuhtude käsitlemine.
• Väljundi skeem.

Tavaliselt 5–10 lõiku. Mitte liiga lühike (alaspetsifitseeritud), mitte liiga pikk (mudel kaotab fookuse).

RAG: teadmise lahendus

RAG on õige tööriist, kui:

• Mudel vajab faktiteavet, mida tal pole.
• Info muutub (live-andmed, hiljutised sündmused, kontospetsiifilised andmed).
• Info on sinu valdkonnale või organisatsioonile spetsiifiline.
• Sul on vaja tsitaate / tõestatavat maandust.

See on vale tööriist, kui:

• Probleem on juhise, mitte teadmise oma.
• Andmed on piisavalt väikesed, et need otse prompti mahuvad.
• Sul on vaja, et mudel teeks midagi teisiti, mitte ainult teaks midagi teist.

Reaalne kulu

RAG-süsteem on päris inseneritöö:

• Ehitamine: 4–12 nädalat tõsisemale (sisseviimine, tükeldamine, embedding, otsimine, ümbersorteerimine, hindamine).
• Tööshoidmine: pidev — indeksi värskendamine, kvaliteedi seire, probleemide parandamine.
• Infrastruktuur: vektorandmebaas, embedding API kulud, ümbersorteerimise kulud. Tüüpiliselt 200–2000 €/kuus mõõdukamast mastaabist süsteemide jaoks.
• Päringukulu: kõrgem kui ainult promptingul (täiendav embedding + otsimine + suurema konteksti kulu). Tavaliselt 2–5x klassikalise API-kõne kulu.

See on õigete probleemide jaoks väga seda väärt. Aga see on prompting-iga võrreldes märkimisväärne investeering.

RAG-i kvaliteet on teekond

Töötav RAG-süsteem 1. nädalal on tavaliselt 60–70% kvaliteediga. Toodangukvaliteedini jõudmine (85%+) võtab veel 1–2 kuud tööd: tükeldamise parandamine, ümbersorteerimise lisamine, ebaõnnestumise režiimide parandamine, hindamiste ehitamine.

Planeeri seda. Ära saada välja 1. nädalal; sul on vihased kasutajad.

Peenhäälestus: kui promptingust ja RAG-ist ei piisa

Peenhäälestus on õige tööriist, kui:

• Sul on selge võimekuse lõhe — mudel ei suuda usaldusväärselt ülesannet teha isegi heade promptide ja kontekstiga.
• Sul on hea partii kõrgekvaliteedilisi treeningnäiteid — minimaalselt mõnisada väga kitsa LoRA jaoks, tüüpilisemalt 1000+ usaldusväärse üldise käitumise jaoks. Vaata peenhäälestuse artiklit täpsete tehnika-põhiste lävede jaoks.
• Sul on vaja järjepidevat, kitsast käitumist (konkreetne stiil, konkreetne väljundvorming, konkreetne valdkond).
• Järelduse kulu/latentsus loeb (peenhäälestatud väiksem mudel võib olla odavam kui üldine suurem).

See on vale tööriist, kui:

• Sinu andmed muutuvad (peenhäälestatud mudel vananeb kiiresti).
• Sa pole esmalt promptingit ja RAG-i ammendanud.
• Sul pole häid hindamisi (sa ei oska öelda, kas peenhäälestus aitas).
• Ülesanne vajab väga ajakohast infot (peenhäälestus on hetktõmmis).
• Sa proovid fakte õpetada (RAG teeb seda paremini, usaldusväärsemalt, tsitaatidega).

Peenhäälestuse tüübid

Täielik peenhäälestus: kõik mudeli kaalud uuenevad. Kõige võimsam, kõige kallim. Vajab märkimisväärset arvutusvõimsust. Tavaliselt reserveeritud alusmudelite laboritele.

LoRA (Low-Rank Adaptation): treenitakse ainult väikest alamhulka kaaludest. Palju odavam. Toodab kitsaste ülesannete jaoks sageli tulemusi, mis konkureerivad täieliku peenhäälestusega.

QLoRA: kvantiseeritud LoRA. Veelgi odavam. Mastaabis madalama kvaliteediga, kuid mõistlik paljude ülesannete jaoks.

Prompt tuning / prefix tuning: veelgi väiksem; ainult pehmed promptid treenitakse. Odavaim. Piiratud võimekus.

Juhise häälestus: mudeli treenimine juhiste järgimiseks. Tehakse tavaliselt alustasandil; lõpukasutajatele harva kasulik.

RLHF / DPO / KTO: mudeli treenimine eelistustega andmete (vastused A vs B) järgi joondumiseks. Käitumismuutusteks võimas; hästi tegemiseks keeruline.

1. aastal kasutab enamik peenhäälestust tegevaid tiime LoRA-d tugeva baasmudeli peal. See on enamiku kasutusjuhtumite jaoks õige tasakaal kulu ja võimekuse vahel.

Reaalne kulu

Peenhäälestuse kulud sõltuvad lähenemisest ja mastaabist, kuid tüüpiline keskmise suurusega avatud mudeli LoRA peenhäälestuse jaoks 5K–10K näite peal:

• Andmete ettevalmistamine: 1–4 nädalat. Sageli põhitöö. Näidete kureerimine, puhastamine, vormistamine.
• Treening: tunde kuni päevi, sõltuvalt andmestiku suurusest ja infrastruktuurist. 100–2000 € arvutusvõimsuses.
• Hindamine: 1–2 nädalat. Hindamiskomplektide ehitamine, peenhäälestatud vs baasi võrdlemine.
• Iteratsioon: 1–3 tsüklit enne, kui midagi on toodanguks valmis.
• Juurutamine: kui kasutad hallatud API-d (OpenAI peenhäälestus, Anthropic, Vertex), siis sirgjooneline. Kui ise hostid, siis rohkem tööd.
• Hooldus: ümbertreeninud, kui andmed uuenevad, kui baasmudel uueneb, kui kasutusjuhtum muutub.

Kokku: 6–12 nädalat tööd, 1K–20K € arvutusvõimsuses (sõltuvalt mastaabist), pidev hooldus.

Märkimisväärne investeering. Veendu, et see on seda väärt.

Kus peenhäälestus hiilgab

Konkreetsed stsenaariumid, kus peenhäälestus selgelt võidab:

Ranged vormingunõuded. Väljundid peavad järgima konkreetset skeemi või stiili järjepidevalt. Prompting viib su 95%-ni; peenhäälestus 99%-ni.

Spetsialiseeritud valdkonnad. Meditsiiniline terminoloogia, õiguslik sõnastus, kood sisemises DSL-is. Peenhäälestus õpetab mudelile sinu konkreetset dialekti.

Isikupärasus/hääl. Järjepidev hääl üle tuhandete interaktsioonide. Promptid võivad triivida; peenhäälestus küpsetab selle sisse.

Latentsuse/kulu optimeerimine. Peenhäälestatud 7B mudel, mis käsitleb sinu konkreetset ülesannet, võib olla odavam ja kiirem kui üldine 70B mudel. Suure mahu juures tasub see ära.

Käitumisturvalisus. Mudeli peenhäälestamine teatud asjade keeldumiseks või konkreetsete turvameetmete lisamiseks võib olla robustsem kui promptipõhised turvapiired.

Kui peenhäälestus ebaõnnestub

Tavalised viisid, kuidas peenhäälestus pettumust valmistab:

Ebapiisav andmestik. Peenhäälestus 100 näite peal ei aita tavaliselt eriti. Väga kitsas LoRA võib mõnikord töötada mõnesaja näitega; usaldusväärse üldise käitumise jaoks planeeri 1000+ kõrgekvaliteedilist näidet.

Halb andmestik. Praht sisse, praht välja. Ebajärjekindlad, madala kvaliteediga näited toodavad ebajärjekindlaid, madala kvaliteediga mudeleid.

Katastroofiline unustamine. Tugev peenhäälestus kitsastel ülesannetel võib kahjustada üldist võimekust. Mudel läheb sinu ülesande juures heaks, kuid kõige muu juures halvemaks.

Vananenud teadmised. Peenhäälestatud mudel on hetktõmmis. Uus info nõuab ümbertreeninud. Dünaamilistele valdkondadele on see igavene kulu.

Baasmudeli paranemised edestavad peenhäälestust. Baasmudel paranes piisavalt, et peenhäälestatud variant pole enam parem. Sa hooldad nüüd vananenud baasi peenhäälestust.

Hindamise probleemid. Ilma tugevate hindamisteta sa ei tea, kas peenhäälestus aitas, kahjustas või ei mõjutanud. Paljud „edukad" peenhäälestused on platseebovõidud.

Kombinatsioonimustrid

Toodangus kombineerivad parimad süsteemid kõik kolm.

Kombinatsioon 1: prompditud RAG (kõige tavalisem)

Vaikevalik teadmise-rohketele rakendustele.

• Hoolikalt disainitud promptid kodeerivad juhiseid, vorminguid, piiranguid.
• RAG pakub praegust, konkreetset infot.
• Peenhäälestust pole; toetume tugevale baasmudelile.

See on kõige tavalisem toodangumuster 2026. aastal. See töötab enamiku kasutusjuhtumite jaoks.

Kombinatsioon 2: peenhäälestatud mudel + RAG

Kui sul on vaja nii käitumuslikku spetsialiseerumist kui dünaamilisi teadmisi.

• Peenhäälesta hääle, vormingu, valdkonna jaoks.
• RAG praeguse info jaoks.
• Promptid orkestreerivad.

Näide: peenhäälestatud mudel konkreetse ettevõtte klienditoe hääle jaoks, RAG-iga praeguste poliitikate ja dokumentatsiooni üle. Peenhäälestus käsitleb järjepidevat häält; RAG käsitleb muutuvaid teadmisi.

Kombinatsioon 3: spetsialiseeritud peenhäälestused konkreetsete ülesannete jaoks

Erinevad peenhäälestused süsteemi erinevate osade jaoks.

• Klassifikatsiooni peenhäälestus suunamiseks.
• Kokkuvõtte peenhäälestus kokkuvõtete jaoks.
• Genereerimise peenhäälestus klientide vastuste jaoks.
• Iga väiksem, kiirem, spetsialiseeritum.

Kasutatakse, kui mastaap ja kulu optimeerimine loevad. Iga peenhäälestus teeb oma kitsast tööd hästi; orkestreerimine kutsub neid.

Kombinatsioon 4: peenhäälestatud suunaja + üldised mudelid

Suunaja on peenhäälestatud, et päringuid usaldusväärselt klassifitseerida. Kui klassifitseeritud, lähevad päringud tegelikuks tööks üldistele mudelitele.

Peenhäälestus on väike, kiire, kitsas. Kallis üldine töö tehakse üldiste mudelitega, hoitakse värskena.

See ühendab säästlikkuse (peenhäälestus on väike) võimekusega (üldised mudelid raske töö jaoks).

Otsustusraamistik

Praktiline otsustusvoog:

Küsimus 1: Kas probleem on lahendatav praeguse mudeli ja hea promptiga?

Kui jah: kirjuta prompt. Itereeri nädala. Saada välja.

Kui ei, mine küsimuse 2 juurde.

Küsimus 2: Kas probleem hõlmab teadmisi, mida mudelil pole?

Kui jah: ehita RAG. Kuluta kuid. Vii see toodangukvaliteedini. Paari tugevate promptidega.

Kui ei, mine küsimuse 3 juurde.

Küsimus 3: Kas probleem on järjepideva vormingu, kitsa valdkonna või konkreetse käitumise kohta?

Kui jah, JA sul on vähemalt mõnisada (ideaalis 1000+) kõrgekvaliteedilist näidet: peenhäälesta. Kombineeri promptingu ja võimalik et RAG-iga.

Kui sul pole näiteid: investeeri nende kogumisse VÕI proovi enne peenhäälestust kaugemale paremat promptingit / RAG-i.

Küsimus 4: Kas oled teinud hindamistöö, et teada, milline lähenemine tegelikult aitab?

See küsimus kehtib igal sammul. Ilma hindamisteta sa arvad.

Toodangunäited

Mõned reaalsed kombinatsioonid:

Näide 1: AI klienditugi

Seadistus: SaaS-i ettevõtte klienditoe AI käsitleb tier 1 päringuid.

Komponendid:

• Tugevad promptid tooni, vormingu, eskaleerimise poliitikate jaoks.
• RAG praeguste dokumentide, poliitikate, piletite ajaloo üle.
• Kerge peenhäälestus ettevõtte konkreetsele häälele ja eskaleerimise mustritele (1500 kureeritud näidet varasemate piletite hulgast).

Tulemus: Käsitleb 65% piletitest autonoomselt. Peenhäälestus vastutab järjepideva hääle eest; RAG hoiab täpsust; promptid käsitlevad poliitikaid.

Näide 2: õigusdokumendi ülevaatus

Seadistus: Õigus-tehnoloogia toode vaatab lepinguid riskide suhtes üle.

Komponendid:

• Detailsed promptid, mis kodeerivad, mida otsida (õiguskategooriad, raskusastme rubriik).
• RAG asjakohase kohtupraktika ja pretsedendi üle.
• Peenhäälestust pole; arutlusmudelid käsitlevad raskemat tööd.

Tulemus: Puhas prompt + RAG töötab hästi, sest mudelil on juba õigusalane treening. Peenhäälestus aitaks marginaalselt; investeering ei õigustanud end.

Näide 3: koodi täiendamine kohandatud DSL-is

Seadistus: Spetsialiseeritud andmetööriist oma DSL-iga.

Komponendid:

• Promptid näidetega.
• RAG-i pole (DSL on piisavalt väike, et kontekstis mahuda).
• LoRA peenhäälestus DSL-i 10K näite peal.

Tulemus: Peenhäälestus oli hädavajalik. Ilma selleta ei suutnud mudel kehtivat DSL-i usaldusväärselt toota. Promptidest ja kontekstist üksi ei piisanud.

Näide 4: sisemine ettevõtte assistent

Seadistus: Üldine assistent ettevõtte töötajatele.

Komponendid:

• Tugevad süsteemipromptid (hääl, käitumine, keeldumised).
• RAG ettevõtte wiki, Slacki, dokumentide üle.
• Peenhäälestust pole; ettevõtte „hääl" on püütud promptidesse.

Tulemus: RAG + promptid käsitlevad enamikku kasutusjuhtumeid. Ettevõte pole hääle pärast piisavalt veidrik, et vajada peenhäälestust.

Vead, mida me näeme

Mõned mustrid valesti eraldamisest:

Viga 1: peenhäälestuse poole esmalt küünitamine. Tiimid kuulevad „peaksime peenhäälestama oma mudelit" ja alustavad sealt. 90% ajast oleks prompting + RAG olnud kiirem, odavam ja sama hea.

Viga 2: RAG-i vahelejätmine, kui see on vastus. Tiimid ehitavad keerukaid prompte, et mudelile „meelde tuletada" ettevõtte infot, mis tuleks ilmselgelt päringuhetkel hankida. Parem lihtsalt hangi.

Viga 3: peenhäälestus ilma hindamisteta. „Me peenhäälestasime ja nüüd on parem." Mõõdikuid pole. Sageli ei teinud peenhäälestus midagi või isegi kahjustas. Ilma hindamisteta sa ei tea.

Viga 4: vananenud peenhäälestused. Peenhäälestus 6 kuu tagant, kui GPT-4 oli parim. Tänase eesliini mudelid ilma peenhäälestuseta edestavad peenhäälestatud vanemat mudelit. Peenhäälestused vajavad ümberhindamist, kui valdkond liigub.

Viga 5: fakte peenhäälestada üritada. Tiimid üritavad mudelit peenhäälestada „teadma meie ettevõtte kohta". Ei tööta hästi — mudel jätab mõned faktid meelde, hallutsineerib teised. RAG käsitleb fakte; peenhäälestus käsitleb käitumist.

Viga 6: promptidel mitte piisavalt kaua itereerimine. Kaks päeva prompti iteratsiooni on alguspunkt. Kaks nädalat annab sulle reaalse vastuse.

Viga 7: RAG-i üleinseneerimine, kui prompting saaks hakkama. 50K-tokeniline ettevõtte dokument prompti tõstetuna on mõnikord lihtsam kui RAG. Eriti väikeste korpuste jaoks.

Kulu ja tööpanuse võrdlus

Umbkaudne võrdlus tüüpilise keskmise suurusega projekti jaoks:

| Lähenemine | Tööpanus | Kulu (ühekordne) | Kulu (päringu kohta) | Hooldus | |----------|--------|----------------|------------------|-------------| | Prompting | 1–2 nädalat | minimaalne | API põhikulu | madal | | RAG | 6–12 nädalat | infrastruktuuri seadistus (~1K–5K €) | 2–5x baas | mõõdukas (sisseviimine, hindamine) | | Peenhäälestus (LoRA) | 6–12 nädalat | treeningu arvutusvõimsus (~500–5K €) | baas (sageli odavam, kui väiksem mudel) | kõrge (andmed, ümbertreeninud, hindamine) | | Prompting + RAG | 8–14 nädalat | infrastruktuur | 2–5x baas | mõõdukas | | Kõik kolm | 12–20 nädalat | kombineeritud | varieerub | kõrge |

Õige valik sõltub sinu probleemist ja ressurssidest. Enamikule tiimidele on prompting + RAG maitsekoht — tähendusrikas võimekuse võit ilma täie peenhäälestuse investeeringuta.

Kokkuvõte

Prompting, RAG ja peenhäälestus lahendavad erinevaid probleeme. Õigesti valimine nõuab ausat diagnoosi: kas see on juhise lõhe, teadmise lõhe või võimekuse lõhe?

Aus järjekord nende proovimiseks:

1. Prompting (1–2 nädalat iteratsiooni). Odavaim, kiireim, kõige sagedamini piisav.
2. RAG, kui on selge teadmise lõhe. Märkimisväärne investeering, kuid hästi piiritletud.
3. Peenhäälestus, kui on selge võimekuse lõhe, mida prompting + RAG ei suuda sulgeda. Kõige kallim; tee viimasena.
4. Kombinatsioonid küpsetele toodangusüsteemidele.

Tiimid, kes õnnestuvad, on ausad selle suhtes, milline lõhe neil on, ja distsiplineeritud hindamiste osas. Ilma hindamisteta sa ei oska öelda, milline lähenemine aitas. Nendega on tee tavaliselt selge.

Enamik „peame peenhäälestama oma mudelit" projekte on lähemalt vaadates tegelikult „peame kirjutama paremaid prompte ja lisama RAG-i". Salvesta peenhäälestus juhtudeks, mis seda tõesti vajavad.

Tulemus: paremad süsteemid, kiiremini, madalama kuluga. Mis ongi see, millest toodangu AI väljasaatmine peaks olema.