> Fine-tuning vs RAG vs prompting: mit változtat meg mindegyik (tudás, viselkedés, formátum), mennyibe kerül, ki kínál 2026-ban SFT-t, DPO-t és RFT-t, plusz döntési fa. > > Web page: https://balazscsorba.com/hu/blog/fine-tuning-vs-rag-vs-prompting · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/fine-tuning-vs-rag-vs-prompting.md) · [Deutsch](https://balazscsorba.com/de/blog/fine-tuning-vs-rag-vs-prompting.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: fine-tuning vs RAG, prompting vs RAG vs fine-tuning, when to fine-tune an LLM, RAG or fine-tuning, SFT vs DPO vs RFT, reinforcement fine-tuning, LLM distillation, OpenAI fine-tuning shutdown, fine-tuning decision tree, fine-tune for knowledge [Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés # Prompting vs RAG vs fine-tuning vs distillation: döntési útmutató 2026-ra Fine-tuning vs RAG vs prompting: mit változtat meg mindegyik (tudás, viselkedés, formátum), mennyibe kerül, ki kínál 2026-ban SFT-t, DPO-t és RFT-t, plusz döntési fa. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 2.·12 perc olvasás - Fine-tuning - RAG - Prompting - Distillation ![Ábra: döntési folyamat a letesztelt promptól a hiányzó tényekhez használt retrievalig, a viselkedést javító felügyelt fine-tuningig és a költségcsökkentő, kisebb modellbe történő distillationig.](https://balazscsorba.com/images/blog/fine-tuning-vs-rag-vs-prompting/cover.webp?v=5d127b6a8d) ## A lényeg röviden - Minden eszköz mást változtat: a prompting az utasításokat, a RAG azt, amit a modell lát, a fine-tuning a viselkedést és a formátumot, a distillation a költséget és a sebességet. - A klasszikus hiba a tudás fine-tuningolása. A kutatások szerint új tényeknél a RAG jobb, az új tudást tartalmazó példák pedig növelhetik a hallucinációt. - 2026-ban átrendeződött a szolgáltatói térkép: az OpenAI leépíti a fine-tuning platformját (új jobok 2027. január 6-ig), a Google és az AWS továbbra is kínál menedzselt SFT-t és RFT-t. - A preference tuning és az RFT csak akkor térül meg, ha tudsz kimeneteket rangsorolni vagy gradert írni, vagyis az értékelésnek a tanítás előtt léteznie kell. - Indulj mért prompttal, add hozzá a retrievalt a tényekhez, csak stabil, értékelhető viselkedést finomhangolj, és csak akkor desztillálj, ha a forgalom láthatóvá teszi a költséget. Ezen az oldalon 1. [Mit változtat meg valójában az egyes eszköz](https://balazscsorba.com/#what-each-changes) 2. [Ki mit kínál 2026-ban](https://balazscsorba.com/#what-is-offered-in-2026) 3. [Kezdd promptinggal, de mérd](https://balazscsorba.com/#prompting-first) 4. [RAG a tudáshoz, nem fine-tuning](https://balazscsorba.com/#rag-for-knowledge) 5. [Supervised fine-tuning viselkedésre és formátumra](https://balazscsorba.com/#sft-for-behaviour) 6. [Preference tuning és RFT: csak jelzéssel](https://balazscsorba.com/#preference-and-rft) 7. [Distillation: költség és késleltetés visszavásárlása](https://balazscsorba.com/#distillation) 8. [Döntési fa](https://balazscsorba.com/#decision-tree) 9. [A leggyakoribb hibák](https://balazscsorba.com/#common-mistakes) 10. [Értékelési és karbantartási ellenőrzőlista](https://balazscsorba.com/#evaluation-and-maintenance) 11. [Mit tennék én](https://balazscsorba.com/#what-i-would-do) 12. [Források](https://balazscsorba.com/#sources) Minden LLM-ekre építő csapat ugyanahhoz az útelágazáshoz ér: a válaszok nem elég jók, és négy eszköz van az asztalon. Jobb promptot írni, retrievalt hozzáadni, finomhangolni a modellt, vagy egy kisebbet desztillálni. Gyakran a divat dönt. A fine-tuning komoly opciónak tűnik, ezért olyan problémákra is ezt választják, amelyeket nem tud megoldani. A térkép ráadásul elmozdult. 2026 májusában az OpenAI bejelentette, hogy leépíti az önkiszolgáló fine-tuning platformját, azzal az indoklással, hogy az újabb alapmodellek annyira jól követik az utasításokat és a formátumokat, hogy a prompting mostanra olcsóbb és gyorsabb. A Google és az AWS továbbra is kínál menedzselt tuningot, nyílt modelleket pedig bárhol hangolhatsz. Ha utoljára egy éve hasonlítottad össze ezeket a lehetőségeket, a képed egy része elavult. Ezt a keretrendszert használom az ügyfeleimnél. Az eszközöket aszerint választja szét, mit változtatnak, összeveti a költséget, az adatigényt és a karbantartást, felsorolja, ki mit kínál 2026. október 2-án, megnevezi a leggyakoribb hibákat, és döntési fával meg ellenőrzőlistával zár. ## Mit változtat meg valójában az egyes eszköz A legegyszerűbb, ha azt kérdezed, mi a baj a kimenettel. Háromféle hiba van. A modell **nem tud** valamit (tudás). **Rosszat csinál** abból, amit tud (viselkedés). Vagy a helyes tartalmat **rossz formában** adja (formátum). Egy negyedik szempont, a költség és a késleltetés, külön áll: a kimenet jó, csak túl drága. Eszköz Mit változtat Szükséges adat Működési költség és karbantartás Tipikus hiba **Prompting** Utasítások, példák, kimeneti struktúra egy híváshoz Néhány példa és egy eval-halmaz A hosszabb promptok minden híváskor tokent esznek; a [prompt caching](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing) enyhít ezen Prompt-drift, törékeny szélső esetek **RAG** Amit a modell lát: privát, friss vagy nagy tudás Dokumentumkorpusz, és a retrieval teszteléséhez kérdések Az indexet és a pipeline-t üzemeltetni kell; hívásonként extra kontextus-token Rossz chunk jön elő, így magabiztos téves válasz születik **SFT** Viselkedés, hangnem, formátum, feladatkészség Több száz tiszta bemenet és ideális kimenet pár Újratanítás, ha változik a követelmény vagy az alapmodell Túltanulás, szűk általánosítás, elavult viselkedés **Preference tuning (DPO)** Szubjektív stílus és hangsúly Ezernyi preferált és elutasított pár Mint az SFT, és a címkézés a költség A zajos preferenciák rossz ízlést tanítanak **RFT** Következtetés ellenőrizhető válaszú feladatoknál Tucatnyi-több száz prompt és egy grader A grader karbantartása; a tanítást idő alapján számlázzák Reward hacking: a modell kijátssza a gyenge gradert **Distillation** Költség és késleltetés: a tudás kisebb modellbe kerül Tanár kimenetek a valódi forgalmadon Újradesztillálás, ha változik a feladat vagy a tanár A diák csak a könnyű eseteknél éri el a tanárt ## Ki mit kínál 2026-ban Módszer választása előtt nézd meg, hogy a szolgáltatód még árulja-e. Ez az az állapot, amelyet 2026. október 2-án a szolgáltatók dokumentációjából és bejelentéseiből ellenőrizni tudtam. **Az OpenAI leépíti a fine-tuningot** Az OpenAI 2026 májusában jelezte a fejlesztőknek, hogy azok a szervezetek, amelyek még sosem finomhangoltak, nem hozhatnak létre új jobokat, a közösségi fórumon közzétett bejelentés pedig **2027\. január 6-át** nevezi meg dátumként, ami után egyáltalán nem lehet új jobot indítani. A meglévő finomhangolt modellek inferenciája addig működik, amíg az alapjukul szolgáló modellt ki nem vezetik. A dokumentált indok: az újabb alapmodellek sokkal jobban követik az utasításokat és a formátumokat, a prompt-alapú megoldások olcsóbbak és gyorsabbak, és kevesebb olyan eset van, amelyhez fine-tuning kell. Ha függsz egy OpenAI-os fine-tune-tól, tervezd meg a migrációt most. Szolgáltató Felügyelt (SFT) Preferencia Reinforcement (RFT) Distillation **OpenAI API** GPT-4.1, 4.1-mini, 4.1-nano (leépítés alatt) DPO ugyanezen három modellen (leépítés alatt) Csak o4-mini (leépítés alatt) Nem ellenőrzött **Microsoft Foundry** GPT-4.1-család és Llama 4 Scout bejelentve Nem ellenőrzött o4-mini, modell-graderekkel (GPT-4.1-család) Nem ellenőrzött **Google, Gemini** Gemini 3.5 Flash, 3.1 Flash-Lite, 2.5 Pro, 2.5 Flash és Flash-Lite Gemini 2.5 Flash és Flash-Lite Pre-GA előzetes ugyanezeken a Gemini modelleken Nyílt modelleken keresztül **Google, nyílt modellek** Gemma, Qwen, Llama; teljes tuning vagy LoRA Nem ellenőrzött Nem ellenőrzött A tanár modell hangol egy kisebb diák modellt **AWS Bedrock** Amazon Nova és mások; Claude 3 Haiku az us-west-2-ben Nem ellenőrzött Nova 2 Lite, gpt-oss-20B, Qwen3 32B Igen; tanár és diák azonos családból Három gyakorlati következmény. Először: ma a „melyik modellt hangolhatom?” többet számít, mint a „melyik módszer?”: azok a frontier modellek, amelyeket a legtöbb csapat élesben használ, többnyire nem hangolhatók, mert a jelenlegi Claude- vagy GPT-5-osztályú modellekhez nem találtam menedzselt fine-tuningot. Másodszor: az RFT valós, de fiatal: a Google Pre-GA-ként listázza, a Microsoft saját RFT-posztjai pedig determinisztikus graderekkel javasolják kezdeni. Harmadszor: a nyílt súlyú út (LoRA Gemmán, Qwenen vagy Llamán) az egyetlen hordozható, és a hosting üzemeltetési terhét is magával hozza. ## Kezdd promptinggal, de mérd Az OpenAI saját optimalizálási útmutatója a munkát evalok, prompt engineering és fine-tuning körforgásaként írja le, és az alapvonal-értékelést teszi az elejére. A sorrenddel egyetértek, és hozzáteszek egy szabályt: **addig nem mondhatod, hogy a prompting megbukott, amíg ki nem próbáltad az erős változatát.** Ez azt jelenti: világos feladatleírás, strukturált kimeneti séma, három–tíz valódi példa a nehéz esetekkel együtt, és egy a feladathoz elég erős modell. - A formátumszerződést sémába vagy structured output módba tedd, ne folyó szövegbe. - A few-shot példákat valódi hibákból vedd, ne kitalált esetekből. - Cache-eld a stabil előtagot. A hosszú, ismétlődő prompt főleg költségprobléma, és a caching nagy részét megoldja (lásd: [költség, késleltetés és routing](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing)). - Előbb próbálj erősebb modellt, mielőtt egy gyengébbet hangolnál. Sok „fine-tuning probléma” valójában modellméret-probléma. - Az eval-halmazt írd meg először. Nélküle nem tudod, hogy egy későbbi változtatás segített-e (lásd: [evalok termékfunkciókhoz](https://balazscsorba.com/hu/blog/llm-evals-for-product-features)). A Google tuning-dokumentációja ugyanezt a határt húzza: a prompting a kevés címkézett adathoz és a gyors prototípusokhoz illik, a tuning akkor a leghatékonyabb, ha nagyobb címkézett adathalmazod van (100 vagy több példát javasol), és a feladatot a fejlett prompting sem oldja meg. A tuning előnyét maga is megnevezi: jobb minőség a feladatodon, kisebb késleltetés és költség a rövidebb promptoknak köszönhetően. ## RAG a tudáshoz, nem fine-tuning Ha a modellből tények hiányoznak, add oda neki a tényeket lekérdezéskor. Itt történik a legdrágább hiba, ezért érdemes kimondani a bizonyítékot. A _Fine-Tuning or Retrieval?_ című tanulmányban Ovadia és társai a felügyelet nélküli fine-tuningot hasonlították össze a RAG-gal, és azt találták, hogy a RAG következetesen jobb, mind a tanítás során látott tudásnál, mind a teljesen új tudásnál; a modellek egyáltalán nehezen tanultak új tényeket fine-tuninggal. A _Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?_ című tanulmányban Gekhman és társai azt találták, hogy az új tudást hozó példákat lassabban tanulja meg a modell, és ha már megtanulta, lineárisan nő a hallucinációra való hajlama. Következtetésük: a modellek a ténybeli tudást főleg az előtanítás alatt szerzik, a fine-tuning azt tanítja meg, hogyan használják hatékonyabban. A gyakorlati érvek ugyanilyen erősek, mint a kutatási érvek. A tények változnak, és egy betanított tényt nem lehet újratanítás nélkül frissíteni, idézni vagy GDPR-kérésre törölni. A RAG forrásokat, dokumentumonkénti jogosultságot és percek alatt megvalósuló frissítést ad. Az ár egy jól megépítendő pipeline: chunkolás, hibrid keresés és reranking, amelyekről a [RAG pipeline útmutatóban](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking) és a [RAG 2026: hibrid, ágens-alapú vagy hosszú kontextus](https://balazscsorba.com/hu/blog/rag-2026-hybrid-agentic-long-context) cikkben írok. Egy hasznos próba: ha a helyes válasz benne van egy dokumentumban, amelyet valaki a kezedbe adhatna, az retrieval-probléma. Ha egyetlen dokumentum sem tartalmazhatná, mert a gond az, hogyan kell válaszolni, akkor nem az. ## Supervised fine-tuning viselkedésre és formátumra Az SFT akkor a jó eszköz, ha a probléma a következetes viselkedés. Az OpenAI útmutatója az osztályozást, az árnyalt fordítást, a meghatározott formátumú tartalom előállítását és az utasításkövetési hibák javítását említi, és óv attól, hogy az SFT-t teljesen új tudásra használd. Projektekből származó kiegészítéseim: szigorú házi stílus, rögzített sémába történő kinyerés ott, ahol a promptok túl hosszúvá válnának, és egy 3000 tokenes prompt súlyokba sűrítése, hogy minden hívás olcsóbb legyen. **Adat.** A szolgáltatók által említett számok kicsik. Az OpenAI már 10 példát elfogadott, és 50–100 példától látott javulást; a Google útmutatója több száz címkézett példáról beszél; az AWS Claude 3 Haiku fine-tuningja 32 és 10 000 sor közötti adatot fogadott. A mennyiség nem a nehéz rész. Az OpenAI best practice útmutatója jól fogalmaz: ha a modelled nyelvtani, logikai vagy stílusproblémákkal küzd, nézd meg, hogy az adataidban nincsenek-e ugyanezek, és kevesebb jó minőségű adat többet ér, mint sok rossz. Figyelj az egyensúlyra is: a 60 százalékban elutasítást tartalmazó tanítóadatból túl sokat elutasító modell lesz. **Módszer.** A paraméterhatékony tuning megfizethetően tartja ezt. A LoRA-tanulmány nagyjából 10 000-szer kevesebb tanítható paramétert és körülbelül háromszor kevesebb GPU-memóriát említ a GPT-3 175B teljes finomhangolásához képest, plusz inferencia-késleltetés nélkül. A menedzselt szolgáltatások ezt elrejtik; nyílt modelleknél magad választasz a LoRA és a teljes tuning között. **Karbantartás.** A fine-tune egy adott alapmodell elágazása. Amikor azt a modellt kivezetik, újratanítasz, és a tanítóadatod meg az eval-halmazod az az érték, amely megmarad. Néhány platform azt is megváltoztatja, hogyan fizetsz: az AWS Provisioned Throughputot kér egy testre szabott Claude 3 Haiku futtatásához, ami a tokenenkénti költséget állandó költséggé alakítja. ## Preference tuning és RFT: csak jelzéssel A **DPO** párokon tanít: egy prompt, egy preferált és egy nem preferált kimenet. Az OpenAI a megfelelő hangsúlyú összefoglalásra és a jó hangnemű, stílusú chatre ajánlja, a cookbook pedig ezres-tízezres nagyságrendű példát említ adatigényként. A Google azt javasolja, hogy előbb SFT-t, utána preference tuningot futtass, és az OpenAI pipeline-ja is először az SFT-vel tanítja meg a pontos megfogalmazást. A DPO ízlésbeli finomhangolás, nem módja egy feladat megtanításának. Az **RFT** más természetű: a modell a tanítás alatt válaszokat generál, és egy grader pontozza őket. Az OpenAI dokumentációja azt tanácsolja, hogy kicsiben kezdj, néhány tucattól néhány százig terjedő példával, hogy lásd, hasznos-e egyáltalán az RFT. Ellenőrizhető eredményű feladatokhoz illik, például teszteken átmenő kódhoz, ismert válaszú strukturált kinyeréshez vagy korlátozott következtetéshez. A Google string-match, Gemini-autorater és kódvégrehajtásos jutalmakat kínál, akár 16-ot kombinálva; az AWS az RFT-jére alapmodellekhez képest átlagosan 66 százalékos pontosságnövekedést közöl, ami kiválasztott esetekből származó gyártói állítás, nem garancia. Az RFT nem működik ott, ahol a modellnek nincs kezdeti képessége vagy homályos a jel, és a gyenge gradert kihasználják. A grader megírása a valódi projekt; egy másik nevű értékelés, ezért az [evalokról szóló útmutatóm](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) közvetlenül érvényes. ## Distillation: költség és késleltetés visszavásárlása A distillation az az egy eszköz, amely a számlát célozza. Egy erős tanár modell kimeneteket generál a valódi bemeneteiden, és egy kisebb diák modellt hangolnak rájuk. Az AWS a Bedrock Model Distillationt az eredeti nagy modellnél akár ötször gyorsabbnak és akár 75 százalékkal olcsóbbnak írja le, kevesebb mint két százalék pontosságvesztéssel, főleg RAG-alkalmazásoknál. Ezek az AWS számai a saját termékére, ezért mérj a saját adataidon. A korlátok tanulságosak: a tanárnak és a diáknak azonos családból kell származnia, és az AWS maga is azt tanácsolja, hogy ha a diák már így is jól teljesít, használd változtatás nélkül. A Google nyílt modellekre vonatkozó dokumentációja ugyanezt mondja a másik oldalról: a distillation akkor működik a legjobban, ha a tanár érdemben erősebb a diáknál, például többlépéses következtetésnél, és kisebb nyereséget hoz, ha a diák már közel jár, vagy a feladat rövid retrieval. Szabályom: csak stabil, valódi forgalmú feladatot desztillálj, miután egy értékelés bizonyítja, hogy a diák eléri a tanárt. Ha ehelyett egy kicsi és egy nagy modell közti routing a célod, nézd meg a [típusos döntések LLM-routinghoz](https://balazscsorba.com/hu/blog/jev-typed-decisions-llm-routing) cikket. ## Döntési fa A kérdések sorrendje a lényeg. Mindegyiket olcsóbb kipróbálni, mint a következőt, és minden válasz kizárja a drágább eszközöket. _A kérdések költség szerint rendezettek. Az első előtt alapvonal-értékelés áll._ Két megjegyzés az olvasáshoz. Az eszközök kombinálhatók: egy éles rendszer gyakran egy hangolt vagy jól promptolt modell, a tényekhez retrievallal, egy eval-kapu mögött. A fa pedig újraindul, valahányszor az alapmodell változik, mert egy jobb modell feleslegessé teheti a tegnapi fine-tune-t, és az OpenAI szerint pontosan ezt látták. ## A leggyakoribb hibák - **Fine-tuning tudásra.** A modell a tanítás alatt felmondja a termékkatalógusodat, élesben pedig árakat talál ki. Használj retrievalt. - **Hangolás mérés előtt.** Nincs alapvonal, nincs eval, így senki sem mondhatja meg, hogy a hangolt modell jobb-e. A letesztelt eseteken kívül gyakran rosszabb. - **Piszkos tanítóadat.** A korábbi modellkimenetekből vagy egymásnak ellentmondó emberi válaszokból másolt példák az ellentmondást tanítják. - **Gyenge modell hangolása egy rossz feladatdefiníció megmentésére.** Ha két ember nem ért egyet a helyes válaszban, semmilyen módszer nem segít. - **Az alapmodell életciklusának figyelmen kívül hagyása.** A fine-tune az alapmodelljével együtt hal meg, és 2026-ban a szolgáltató akár teljesen meg is szüntetheti a tuningot. - **Regressziós halmaz kihagyása.** Egy viselkedésre hangolva csendben más viselkedéseket is károsíthatsz, a biztonságit is. - **Bekapcsolva hagyott thinking egy hangolt feladatnál.** A Google azt javasolja, hogy hangolt feladatoknál állítsd a thinking budgetet 0-ra (Gemini 3-tól felfelé a szintet minimálisra), ami javíthatja a teljesítményt és csökkentheti a költséget. ## Értékelési és karbantartási ellenőrzőlista Bármelyik eszközt is húzod meg, ugyanaz a fegyelem érvényes. Ezt az ellenőrzőlistát tenném egy pull request sablonba minden prompt-, retrieval- vagy modellváltoztatáshoz. 1. Fagyassz be egy eval-halmazt valódi forgalomból, hibákkal és szélső esetekkel, mielőtt bármit változtatsz. 2. Rögzítsd az alapvonalat a jelenlegi promptra és modellre, minőséggel, késleltetéssel és feladatonkénti költséggel. 3. Egyszerre egy eszközt változtass, és futtasd újra a teljes halmazt, ne csak azokat az eseteket, amelyeket éppen néztél. 4. Tarts regressziós halmazt olyan viselkedésekhez, amelyeket nem veszíthetsz el: elutasítások, biztonság, formázás. 5. Verziózd a tanítóadatot, a grader vagy judge promptot és az alapmodell azonosítóját a hangolt modell mellett. 6. Állíts be újratanítási triggert: alapmodell kivezetése, az eval-pontszám elcsúszása vagy megváltozott követelmény. 7. Számold ki a megtérülést: a tuning és a hosting költsége a havonta megspórolt tokenekkel szemben. ## Mit tennék én Egy új LLM-funkciónál az első héten megépíteném az eval-halmazt, a másodikban jó promptig jutnék, és retrievalt adnék hozzá, amint a tények számítanak. Fine-tuningot csak akkor mérlegelnék, ha ezek után egy stabil viselkedés még mindig hibázik, és csak olyan platformon, amelyről azt várom, hogy két év múlva is kínálja. Ma ez a Google, az AWS vagy a nyílt modellek felé mutat, nem egy visszavonuló zárt API felé. RFT-t csak determinisztikus graderrel próbálnék, distillationt pedig csak akkor, ha a havi számla elég nagy ahhoz, hogy kifizesse a projektet. A legtöbb európai B2B termékben a prompting plusz a retrieval plusz egy jó értékelés megadja az érték 90 százalékát. Ez a projektjeimből származó megítélés, nem mért szám, és az eval-halmazodnak felül kell bírálnia. A mesterség abban áll, hogy felismerd, milyen fajta hibát látsz magad előtt. ## Források 1. [OpenAI community: OpenAI self-serve fine-tuning availability (wind-down announcement)](https://community.openai.com/t/openai-s-self-serve-fine-tuning-availability/1380481) 2. [Tessl: OpenAI is shutting down self-serve fine-tuning](https://tessl.io/blog/openai-shutting-fine-tuning-signals-for-enterprise-ai) 3. [OpenAI API docs: Model optimization](https://developers.openai.com/api/docs/guides/model-optimization) 4. [OpenAI API docs: Supervised fine-tuning](https://developers.openai.com/api/docs/guides/supervised-fine-tuning) 5. [OpenAI API docs: Direct preference optimization](https://developers.openai.com/api/docs/guides/direct-preference-optimization) 6. [OpenAI API docs: Reinforcement fine-tuning](https://developers.openai.com/api/docs/guides/reinforcement-fine-tuning) 7. [OpenAI API docs: Fine-tuning best practices](https://developers.openai.com/api/docs/guides/fine-tuning-best-practices) 8. [OpenAI Cookbook: Choosing between SFT, DPO and RFT](https://developers.openai.com/cookbook/examples/fine_tuning_direct_preference_optimization_guide) 9. [Google Cloud: Introduction to tuning (Gemini)](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/tune-models) 10. [Google Cloud: About supervised fine-tuning for Gemini models](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini-supervised-tuning) 11. [Google Cloud: About preference tuning for Gemini models](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini-preference-tuning) 12. [Google Cloud: Reward functions for reinforcement learning fine-tuning](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/tuning/reinforcement-tuning/reinforcement-tuning-job/reward-functions) 13. [Google Cloud: Supervised and distillation fine-tuning for open models](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/open-model-tuning) 14. [AWS: Fine-tuning for Claude 3 Haiku in Amazon Bedrock is now generally available](https://aws.amazon.com/blogs/aws/fine-tuning-for-anthropics-claude-3-haiku-model-in-amazon-bedrock-is-now-generally-available/) 15. [AWS: Amazon Bedrock now supports reinforcement fine-tuning](https://aws.amazon.com/about-aws/whats-new/2025/12/bedrock-reinforcement-fine-tuning-66-base-models) 16. [AWS: Amazon Bedrock Model Distillation (preview announcement)](https://aws.amazon.com/blogs/aws/build-faster-more-cost-efficient-highly-accurate-models-with-amazon-bedrock-model-distillation-preview/) 17. [AWS: Bedrock reinforcement fine-tuning adds open-weight models](https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-reinforcement-fine-tuning-openai) 18. [Microsoft Foundry blog: What is new in Foundry fine-tuning, April 2026](https://devblogs.microsoft.com/foundry/whats-new-in-foundry-finetune-april-2026/) 19. [Microsoft: Announcing new fine-tuning models and techniques in Azure AI Foundry](https://azure.microsoft.com/en-us/blog/announcing-new-fine-tuning-models-and-techniques-in-azure-ai-foundry/) 20. [Ovadia et al.: Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs](https://arxiv.org/abs/2312.05934) 21. [Gekhman et al.: Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?](https://arxiv.org/abs/2405.05904) 22. [Hu et al.: LoRA: Low-Rank Adaptation of Large Language Models](https://arxiv.org/abs/2106.09685) ## Gyakori kérdések RAG-ot vagy fine-tuningot használjak? RAG-ot, ha hiányzó vagy változó tények a gond, fine-tuningot, ha a viselkedés, a hangnem vagy a kimeneti formátum. A fine-tuning rossz módszer tudás hozzáadására: egy 2023-as tanulmány szerint a RAG a meglévő és az új tudásnál is jobb, egy 2024-es pedig azt találta, hogy az új tényeket tartalmazó példákat lassan tanulja meg a modell, és a megtanulásuk után nő a hallucináció. Mikor éri meg a fine-tuning? Ha egy letesztelt, példákkal ellátott prompt egy stabil, jól definiált viselkedésnél még mindig hibázik, van néhány száz jó példád, és mérni tudod az eredményt. Tipikus nyereség a szigorú kimeneti formátum, az osztályozás, az egységes hangnem és a rövidebb promptok nagy forgalomnál. Elérhető még az OpenAI fine-tuning 2026-ban? Csak azoknak a szervezeteknek, amelyek már használták. Az OpenAI 2026 májusában jelezte a fejlesztőknek, hogy leépíti a platformot: új szervezetek nem hozhatnak létre jobokat, 2027. január 6-án pedig mindenki számára megszűnik a jobok létrehozása. A meglévő finomhangolt modellek addig futnak, amíg az alapmodellt ki nem vezetik. Mi a különbség az SFT, a DPO és az RFT között? A supervised fine-tuning (SFT) bemenet és ideális kimenet párokon tanít. A direct preference optimization (DPO) promptonként egy preferált és egy elutasított válaszon. A reinforcement fine-tuning (RFT) során a modell válaszokat generál, amelyeket egy grader pontoz, ez az ellenőrizhető eredményű feladatokhoz illik. Mi az a distillation, és mikor használjam? A distillation során egy erősebb tanár modell tanítóadatot generál egy kisebb diák modellnek. Stabil, nagy forgalmú feladatnál használd, ha egy olcsóbb modell az értékelő halmazodon eléri a tanárt, és valódi pénzt spórol. Az AWS azt javasolja, hogy ha a diák modell már így is jól teljesít, maradj annál. Hány példa kell a fine-tuninghoz? A szolgáltatók kis kezdőszámokat mondanak: az OpenAI minimum 10 példát fogadott el, és 50–100 példától látott javulást, a Google nagyjából 100 vagy több címkézett példát javasol. A DPO-hoz jellemzően jóval több kell, az OpenAI szerint ezres nagyságrend. A minőség és a szélső esetek lefedettsége többet számít a puszta darabszámnál. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [LLM-ügynökök megfigyelhetősége OpenTelemetryvel: trace-ek, tokenek, PII és eval](https://balazscsorba.com/hu/blog/agent-observability-opentelemetry) - [Claude Opus 5.5 az Artificial Analysis élén, de az igazi hír a medium effort](https://balazscsorba.com/hu/blog/artificial-analysis-leaderboard-claude-opus-5-5) - [Tipizált döntések LLM routingra és triázsra: kalibrált konfidencia Jevvel](https://balazscsorba.com/hu/blog/jev-typed-decisions-llm-routing) - [LLM evals termékfunkciókhoz: a valódi trace-ektől a CI kapuig](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Beszélgetés kérése](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)