Valik promptimise, RAG-i ja peenhäälestuse vahel ning nende kombineerimine

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.

Siin on raamistik valimiseks — millal on igaüks õige tööriist, millal neid kombineerida, iga reaalsed kulud ja mis kipub toodangus õigesti või valesti minema.

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

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 (liiga vähe määratletud) ega 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 nõuab päris inseneritööd:

• Ehitamine: dokumentide ettevalmistus, õigused, tükeldamine, indekseerimine, otsing, hindamine ja käitus. Hinda töömahtu oma allikate ning vastuvõtukriteeriumide põhjal.
• Käitamine: indeksi värskendamine, kvaliteedi seire ja probleemide parandamine on pidev töö.
• Taristu: arvuta eraldi parsimise ja OCR-i, salvestuse, vektoresituste, otsingu, ümberreastamise, genereerimise, varunduse ja telemeetria kulu kehtivate hindade ning mõõdetud mahu järgi.
• Päringukulu: lisanduda võivad päringu vektoresitus, otsing, ümberreastamine ja kontekstitokenid, kuid parem otsing võib vähendada tarbetut konteksti või võimaldada odavamat genereerivat mudelit. Mõõda kogu teekonda.

Kiida investeering heaks ainult siis, kui hinnatud otsinguteekond parandab määratletud tulemust piisavalt, et õigustada dokumentide ettevalmistuse, õiguste, värskuse, latentsuse, kulu ja käituse koormust.

RAG-i kvaliteet on teekond

Esimese nädala kvaliteedi kohta ei ole olemas ülekantavat protsenti. Mõõda märgendatud kogumil leksikaalse, vektor- ja hübriidotsingu lähteversioone, raporteeri otsingu kaetust ning lõppvastuse kvaliteeti oluliste alamrühmade kaupa ja muuda korraga üht etappi. Võta lahendus kasutusele alles siis, kui valdkonnaspetsiifilised vea- ja juurdepääsukontrollid läbivad.

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 piisavalt esinduslikke, litsentsiga lubatud ja privaatsuse seisukohalt üle vaadatud treeningandmeid, et parandada eraldiseisval kontrollkogumil mõõdetud tulemust. Andmete piisavus määratakse õppimiskõvera, mitte universaalse näidete arvu järgi.
• 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.

LoRA on üks praktiline katseviis, kuid see ei ole kõigi meeskondade ega kasutusjuhtude tõendatud vaikevalik. Vali meetod mudeli toe, andmeõiguste, mõõdetud lähteolukorra, juurutusviisi ja hoolduskoormuse põhjal.

Reaalne kulu

Peenhäälestuse kulu sõltub meetodist, mudelist, andmestikust, hindamisest ja mudeliserverist. Koosta hinnang mõõdetavatest osadest:

• Andmete ettevalmistamine: õigused, dubleerimise eemaldamine, puhastamine, märgendamine, jaotus treeningu-, valideerimis- ja kontrollkogumiks ning inimese ülevaatus.
• Treening: mõõdetud tokenid sekundis × kavandatud tokenite arv, millele lisanduvad kontrollpunktid, nurjunud jooksud ja salvestus.
• Hindamine: baasmudeli ja häälestatud mudeli võrdlus eraldi siht-, ohutus- ja üldvõimekuse kontrollkogumitel.
• Iteratsioon: määra järgmise jooksu eelarve alles pärast seda, kui oled sõnastanud tulemuse, mis uue katse õigustaks.
• Juurutamine: teenusepakkuja saadavus, adapteri teenindamine, tagasipööramine, seire ja säilituskohustused.
• Hooldus: ümbertreenimine andmete, baasmudeli või kasutusjuhu muutumisel.

Arvesta ka arendajate ja ülevaatajate aega; arvutusvõimsus ei ole kogukulu. Jätka ainult siis, kui mõõdetud paranemine õigustab jätkuvat teenindus- ja ümbertreenimiskoormust.

Kus peenhäälestus hiilgab

Stsenaariumid, kus peenhäälestuskatse võib olla põhjendatud:

Stabiilne ülesandekäitumine. Peenhäälestus võib konkreetsel jaotusel parandada vormingut või stiili, kuid toetatud skeemikuju saab juba tagada piiratud dekodeerimisega. Võrdle promptimise, piiratud väljundi ja peenhäälestatud mudeli lähteversioone, selle asemel et lubada 95% ja 99% tulemust.

Spetsialiseeritud keel või süntaks. Meditsiiniterminoloogia, õiguslik sõnastus või sisemine DSL võivad kontrollkogumil paraneda, kuid suure kaaluga juhtumite õigsus vajab endiselt välist valideerimist, ajakohaseid tõendeid ja pädevat ülevaatust.

Stiil ja hääletoon. Häälestatud mudel võib sihtjaotuse hindamisrubriigis parema tulemuse saada. See ei taga täiuslikku järjepidevust; mõõda lisaks hääletoonile ka sisu kvaliteeti, ohutust ja triivi.

Latentsuse või kulu katse. Väiksem häälestatud mudel võib sama vastuvõtuläve saavutada väiksema mõõdetud teeninduskulu või latentsusega. Enne tasuvuse väitmist arvesta treeningut, hindamist, võimsust, töökindlust ja hooldust.

Käitumise kohandamine. Ohutushäälestus võib mõõdetud keeldumiskäitumist parandada, kuid võib põhjustada ka liiga palju või liiga vähe keeldumisi ning halvendada muid võimeid. See peab jääma üheks kihiks deterministliku volitamise, poliitikate jõustamise, seire ja inimese otsustusväravate kõrval.

Kui peenhäälestus ebaõnnestub

Tavalised viisid, kuidas peenhäälestus pettumust valmistab:

Ebapiisav või ebaesinduslik andmestik. Väike ja kitsas andmestik võib mõnikord aidata, samas kui suur mürane andmestik võib tulemust halvendada. Mõõda eraldiseisval kontrollkogumil, kuidas tulemus andmemahu kasvades muutub, ning kontrolli oluliste alamrühmade kaetust enne uue treeningu tellimist.

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 ümbertreenimist. 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: ehita promptimise lähteversioon ja hinda seda. Võta lahendus kasutusele ainult siis, kui vastuvõtu- ja ohutuskriteeriumid läbivad.

Kui ei, mine küsimuse 2 juurde.

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

Kui jah: võrdle vajaduse järgi otsese konteksti, leksikaalse otsingu, vektorotsingu ja hübriidotsingu lähteversioone. Hinda teostust alles pärast allikate ja juurdepääsuõiguste kaardistamist.

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 vajalike õiguste ning privaatsuskontrollidega esinduslik andmestik, tee väike peenhäälestuskatse ja võrdle seda muutmata lähteversiooniga.

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.

Näitlikud tootmisstsenaariumid

Järgmised kombinatsioonid on illustratsioonid, mitte mõõdetud kliendijuhtumid.

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

Näitlik tulemus: Lahendus võib selle meeskonna hindamiskomplektil iseseisvalt käsitleda märkimisväärse osa esimese taseme piletitest. Peenhäälestus toetab järjepidevat hääletooni, RAG ajakohaseid teadmisi ja promptid eskaleerimisreegleid; tegelik osakaal tuleb mõõta.

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.

Otsustuskriteerium: võrdle klauslitaseme kaetust, ekslikult rahustavaid vastuseid, viidete õigsust, jurisdiktsioonide kaetust ja kvalifitseeritud juristi ülevaatust. Ükski meetod ei sobi õiguslikuks aluseks pelgalt seetõttu, et baasmudel on näinud õigustekste.

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).
• Õigustega kaetud treeningandmestik, mille suurus valitakse kaetuse ja õppimiskõvera, mitte kopeeritud näidete arvu järgi.

Otsustuskriteerium: võrdle promptimise ja häälestamise puhul eraldiseisvatel programmidel süntaktilist kehtivust, semantilist õigsust ja käitamise ohutust. Näitlik seadistus ei tõenda, et päris DSL vajab tingimata peenhäälestust.

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.

Otsustuskriteerium: võrdle ainult prompti kasutavat ja otsinguga varianti ajakohaste vastuste õigsuse, viidete, õiguste, vastamisest hoidumise, latentsuse, kulu ja üle vaadatud stiili põhjal. Peenhäälesta ainult siis, kui alles jääb väärtuslik ja mõõdetud käitumispuudujääk.

Vead, mida me näeme

Mõned mustrid valesti eraldamisest:

Viga 1: peenhäälestuse poole esmalt küünitamine. Tiimid kuulevad „peaksime oma mudelit peenhäälestama” ja alustavad sealt. Testi esmalt promptimise ning otsingu lähteversioone: paljud näilised peenhäälestusprobleemid tulenevad ebaselgest juhisest või puuduvast kontekstist.

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. Väidet „peenhäälestus tegi paremaks” ei saa ilma eraldiseisva lähteversiooni ja alamrühmade tulemusteta põhjendada ning regressioonid jäävad peitu.

Viga 4: vananenud peenhäälestused. Baasmudelid, mudeliserverid, andmed ja tootenõuded muutuvad. Enne adapteri ümbertreenimist või jätkuvat kasutamist käivita muutmata praegune lähteversioon ja vastuvõtukomplekt uuesti.

Viga 5: mudelikaalude kasutamine ajakohase andmebaasina. Treening võib luua meelde jäetud seoseid, kuid ei taga uuendamist, päritolu ega kustutamist. Hoia usaldusväärsed faktid hallatud allikates või tööriistades ning kasuta häälestamist tõendatud käitumisvajaduse, mitte tõeallika jaoks.

Viga 6: promptimise lõpetamisreegel puudub. Ilma eraldiseisva kontrollkogumita võib variante lõputult näidete järgi üle sobitada. Peatu või eskaleeri, kui eelnevalt määratud mõõdikud enam ei parane.

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

Võrdle lähenemisi mõõdetavate kulukomponentide järgi:

Õige valik sõltub mõõdetud puudujäägist ja terviklikust käitusmudelist. Promptimise ja otsingu kombinatsioon on dünaamiliste teadmiste puhul levinud, kuid see ei ole universaalne parim lahendus.

Tuvasta puudujääk, siis vali abinõu

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.