A finomhangolás kontra RAG kérdés ritkán érkezik kérdés formájában. Rendszerint kijelentésként hangzik el: finomhangolnunk kell egy modellt a saját adatainkon. Ez a vállalati MI egyik legdrágább mondata, és többnyire téves. Nem mindig, de többnyire. A kérés mögött szinte mindig két nagyon különböző panasz egyike áll: vagy nem tud a modell semmit az üzletetekről, vagy tud, de nem úgy válaszol, ahogyan szeretnétek. A finomhangolás az elsőre gyenge megoldás, a másodikra pedig drága.

A finomhangolás, a RAG és a promptok javítása közötti választás nem ízlés kérdése, és nem is technikai divat. Mindhárom más problémakategóriát old meg, és a rossz döntés hónapok komoly munkáját eredményezi úgy, hogy közben a kifogást meg sem érinti. A valódi veszteség nem is a projekt költségvetése, hanem az az elvesztegetett negyedév, amíg valaki észreveszi, hogy a tünet változatlan maradt.

A legtöbb pénzt megtakarító szabály: ha a gond az, hogy a modell nem tud valamit, használjatok visszakeresést. Ha a gond az, hogy tudja, de rossz stílusban, formátumban vagy hosszban válaszol, előbb a promptot javítsátok, és csak akkor gondolkodjatok finomhangoláson, ha ez nem elég. A finomhangolás viselkedést tanít, nem tényeket, és azok a csapatok, amelyek tudás betöltésére használják, olyan modellt kapnak, amely ugyanolyan magabiztosan téved, csak éppen új házi stílusban.

Finomhangolás kontra RAG kontra prompt: melyik mit csinál

A megkülönböztetés egyszerűbb, mint amilyennek a szakmai vita mutatja.

A prompt azokat az utasításokat változtatja meg, amelyeket minden egyes kéréssel elküldötök. Alakítja a hangnemet, a formátumot, a szerkezetet és a gondolatmenetet, és szerény mennyiségű kontextust is magával tud vinni. Azonnal hat, a tokeneken kívül semmibe nem kerül, és éles üzemben másodpercek alatt módosítható, kódszállítás és karbantartási ablak nélkül. Ez a legolcsóbb és leggyorsabban visszavonható beavatkozás a három közül.

A visszakeresés a kérés pillanatában hozza elő a lényeges anyagot a saját tartalmatokból, és a válasz előtt beteszi a kontextusba. Olyan információhoz juttatja a modellt, amelyet a tanítás során soha nem látott, beleértve azt is, ami ma reggel változott meg. Maga a modell érintetlen marad; ti azt javítjátok, amivel dolgozhat. A visszakereséssel bővített generálásról szóló írásunk részletesen bemutatja a működést.

A finomhangolás a modell súlyait állítja át a kívánt viselkedést bemutató példák alapján. Valóban hatékony akkor, ha egységes formátumot, sajátos hangnemet vagy feladatspecifikus mintázatokat kell megtanítani, vagyis olyasmit, amit szavakkal nehéz leírni, de példával könnyű megmutatni. Tények tanítására viszont rossz, mert az így megtanult tény később nem frissíthető, nem auditálható és nem hivatkozható, a modell pedig nem tudja jelezni, ha éppen rosszul támaszkodik rá.

A zavart az okozza, hogy mindhárom megváltoztatja a kimenetet. Csak a visszakeresés változtatja meg azt, amit a modell tud.

Melyik mennyibe kerül

A számok egy közepes méretű üzleti alkalmazás jellemző brit szállítását tükrözik.

A prompt. Napok, nem hetek, jellemzően 1000 és 5000 font között, beleértve azt a kiértékelő készletet is, amelyet érdemes mellé felépíteni. Az üzemeltetési költség maga a tokenköltség; a hosszabb rendszerprompt egy kicsit megemeli, amit a promptgyorsítótár nagyrészt kiegyenlít.

A visszakeresés. Négytől tizenkét hétig, jellemzően 15 000 és 60 000 font között, attól függően, mennyire rendezetlen a forrástartalom. Az építési költség nagyobb része a betöltésben van: ki kell szedni a dokumentumokat azokból a rendszerekből, amelyek őrzik őket, értelmesen fel kell darabolni őket, kezelni kell a jogosultságokat, hogy mindenki csak azt kapja vissza, amit megnézhet, és naprakészen kell tartani az indexet. Üzemeltetéskor ehhez jön a vektortár és a kérésenként valamivel nagyobb kontextus.

A finomhangolás. Kettőtől nyolc hétig tartó mérnöki munka, plusz az adatkészlet, jellemzően 20 000 és 80 000 font között. A tanítás számítási igénye rendszerint a legkisebb tétel; a költség a több száztól több ezerig terjedő, jó minőségű példa előállítása, ami emberi munka, méghozzá olyan embereké, akik ismerik a szakterületet. Az üzemeltetés is drágább lehet, mert a finomhangolt modell gyakran felárral jár, vagy dedikált kiszolgálást igényel.

Az aszimmetria a lényeg. A prompt elég olcsó ahhoz, hogy elsőként próbáljátok ki akkor is, ha eléggé biztosak vagytok benne, hogy nem lesz elég: a kiértékelő készletre amúgy is szükségetek lesz, és közben derül ki, mi a tényleges hibamód.

Milyen sorrendben érdemes próbálkozni

Sorban végigmenni rajtuk olcsóbb, mint egyből a végére ugrani, még akkor is, ha végül úgyis a végén kötötök ki.

Kezdjétek a kiértékelő készlettel. Harminctól száz valódi bemenet, ismert jó kimenetekkel. Enélkül nem tudjátok megállapítani, hogy bármelyik változtatás segített-e, és minden további döntés puszta találgatás lesz. Ez a projekt legolcsóbb befektetése, és az egyetlen olyan darabja, amely a választott úttól függetlenül megmarad. Ez ugyanaz a kiértékelő rendszer, amelyet az OpenAI API-integrációról szóló útmutatónk ír le.

Utána javítsátok a promptot. Legyetek pontosak a formátummal kapcsolatban, adjatok néhány példát a jó válaszra magában az utasításban, és mondjátok meg, mit tegyen a modell, ha nem ismeri a választ. A modell nem elég jó típusú panaszok meglepően nagy hányada itt megoldódik, különösen a terjengősség és a szerkezet körüli kifogások.

Utána próbáljatok nagyobb vagy egyszerűen másik modellt. Ez gyakran olcsóbb bármilyen testreszabásnál, és egy délután alatt kiértékelhető. Az OpenAI elhagyásáról szóló útmutatónk bemutatja, hogyan kell ezt az összehasonlítást rendesen elvégezni.

Utána jöhet a visszakeresés, ha a hiba a tudásban van. Ha a modell a termékeitekről, a szabályzataitokról vagy a dokumentumaitokról kérdezve téved, vagy egyszerűen megtagadja a választ, ez a lépés oldja meg.

Utána jöhet a finomhangolás, ha a hiba a viselkedésben van. Ekkorra már van kiértékelő készletetek, kicsiszolt promptotok és adott esetben visszakereső folyamatotok is. Ha a kimenet stílusban vagy szerkezetben még mindig nem az, amire szükségetek van, és a kívánt viselkedést könnyebb több száz példával megmutatni, mint szavakkal leírni, akkor a finomhangolás a helyes eszköz.

A projektek többsége a harmadik vagy a negyedik lépésnél megáll. A megtakarítás pontosan ott keletkezik.

Mikor nyer valóban a finomhangolás

Vannak valódi esetek, és a teljes elutasításuk ugyanakkora hiba lenne, mint elsőként nyúlni hozzájuk.

Egységes, szerkezetes kimenet nagy mennyiségben. Ha minden válasznak merev formátumot kell követnie, amelyet fárasztó promptban leírni, a finomhangolt modell megbízhatóbban és jóval kevesebb bemeneti tokennel állítja elő, és nagy mennyiségnél ez már kitermeli önmagát.

Szakosodott hangnem vagy szakmai regiszter. Jogi szövegezés, klinikai feljegyzések, szabályozott pénzügyi kommunikáció: erős konvenciókkal bíró stílusok, amelyeket a szakemberek azonnal felismernek, és amelyeket utasításokban nehéz megragadni.

Osztályozás finom, nehezen megfogalmazható határokkal. Amikor a csapatotok következetesen tud címkézni, de a szabályt nem tudja kimondani, pontosan erre való a példákon való tanítás.

Költségcsökkentés nagy forgalomnál. Egy kisebb, finomhangolt modell, amely egyetlen szűk feladaton felér egy nagyobb általános modellel, jelentősen csökkentheti a kérésenkénti költséget. Ennek csak akkora mennyiség felett van értelme, ahol a megtakarítás meghaladja az építés és a karbantartás költségét.

A közös szál a viselkedés, nem a tudás. Ha egy bekezdésben el tudjátok mondani, mit akartok, kérjétek promptban. Ha csak megmutatni tudjátok, tanítsátok meg.

Amit senki nem árazik be

Három folyamatos teher szinte mindig kimarad a finomhangolás üzleti számításából.

Az adatkészlet öregszik. A finomhangolt modell azt tükrözi, amit a példákban látott. Amikor a termékek, a szabályzatok vagy a házi stílus megváltozik, a példák elavulnak, a modell pedig ugyanolyan magabiztosan gyártja tovább a régi viselkedést. Az időszakos újratanítást állandó költségként tervezzétek, ne egyszeri tételként.

Egy alapmodellhez vagytok kötve. A finomhangolás egy konkrét verzióhoz tapad. Ha azt kivezetik, vagy megjelenik egy jobb modell, az átállás újratanítást jelent, ami valódi váltási költség, és egy promptnak ilyenje egyáltalán nincs.

A kiértékelés kötelezővé válik, nem marad opcionális. Prompttal egy visszaesést szemre is észre lehet venni. Finomhangolt modellnél nem tudjátok megvizsgálni, miért változott meg a viselkedés, így a kiértékelő készlet marad az egyetlen műszeretek.

A visszakeresésnek van ezekből egy kisebb megfelelője: az indexet naprakészen kell tartani, a jogosultságoknak helyesnek kell maradniuk akkor is, ahogy az emberek szerepet váltanak, és valakinek észre kell vennie, ha a betöltés csendben leáll. Olcsóbb, mint az újratanítás, de nem ingyenes.

Előbb a diagnózis, aztán az építés

A Mecanik visszakereső rendszereket, kiértékelő készleteket és finomhangolási folyamatokat épít az MI integrációs szolgáltatások részeként, és azzal kezdjük, hogy megállapítjuk, a három probléma közül valójában melyik a tiétek.

Ez a diagnózis rendszerint rövid együttműködés, és elég gyakran olyan javaslattal zárul, amely sokkal kevesebbe kerül, mint a tervezett projekt. Ahol a finomhangolás tényleg a helyes válasz, ott ezt kimondjuk, és őszintén méretezzük az adatkészlettel járó munkát, mert éppen ez dönti el, hogy sikerül-e. A tágabb költségképhez az MI integráció költségeiről szóló útmutatónk külön mutatja be az építési és az üzemeltetési tételeket.

Mondjátok el, mit ront el a modell, azokkal a szavakkal, ahogyan a felhasználóitok mondanák, és megmondjuk, a három közül melyikről van szó.

Kapcsolódó bejegyzések: MI-alapú szoftverfejlesztés - Útmutató brit vállalkozásoknak , Kimi K3 saját üzemeltetés: hardver, költség, szuverenitás , Drupal migráció 2026: költségek, utak, határidők , OpenAI API chatbot építése: 2026-os útmutató .

Gyakran ismételt kérdések

Finomhangoljak egy modellt a céges adatainkon? Rendszerint nem. A finomhangolás viselkedést tanít, nem tényeket, és az így megszerzett tudás nem frissíthető, nem hivatkozható és nem auditálható. Ha a gond az, hogy a modell nem ismeri a termékeiteket, a szabályzataitokat vagy a dokumentumaitokat, akkor a visszakeresés a helyes megközelítés, és olcsóbb is felépíteni és karbantartani.

Mi a különbség a finomhangolás és a RAG között? A visszakeresés a kérés pillanatában hozza elő a lényeges anyagot a tartalmatokból, és beteszi a kontextusba, így a modell olyan információból is tud válaszolni, amelyet a tanítás során soha nem látott. A finomhangolás példák alapján állítja át a modell súlyait, vagyis azt változtatja meg, ahogyan viselkedik, nem azt, amit tud.

Mennyibe kerül a finomhangolás? Közepes méretű üzleti alkalmazásnál jellemzően 20 000 és 80 000 font között, kettőtől nyolc hétig tartó mérnöki munkával. A tanítás számítási igénye rendszerint a legkisebb tétel; a költség nagy része a több száztól több ezerig terjedő, jó minőségű példa előállítása, amihez a szakterületet ismerő emberek kellenek.

Mennyibe kerül egy RAG rendszer felépítése? Jellemzően 15 000 és 60 000 font között, négytől tizenkét hétig, és az árat főleg az mozgatja, mennyire rendezetlen a forrástartalom. A munka nagyobb része a betöltésre, a darabolásra és a jogosultságok kezelésére megy el, hogy mindenki csak azt kapja vissza, amit megnézhet, valamint az index naprakészen tartására.

Milyen sorrendben próbáljam ki ezeket a megközelítéseket? Először építsetek kiértékelő készletet, utána javítsátok a promptot, utána próbáljatok nagyobb vagy másik modellt, utána jöhet a visszakeresés, ha a hiba a tudásban van, és csak a legvégén a finomhangolás, ha a hiba a viselkedésben van. A projektek többsége az utolsó lépés előtt megoldódik.