Optimalizáció

Miért érdekel ez téged?

Az optimalizáció nem egy technika, hanem egy sorrend. A legdrágább hiba nem az, hogy rossz eszközt választasz — hanem hogy a helyes eszközt rossz sorrendben, például a legvégső lépéssel kezded.

Képzeld el, hogy egy lakást újítasz fel. Nem azzal kezded, hogy egyedi bútort rendelsz — előbb megnézed, hol szivárog a víz, kifested a falat, és csak a végén jön a méretre gyártott szekrény, ha egyáltalán kell. A fine-tuning ilyen egyedi bútor: drága, lassan készül, és utólag nehéz átalakítani. Mégis rengeteg csapat ezzel kezdi, mielőtt egyáltalán megmérte volna, hol a baj.

Ebben a fejezetben végigmegyünk azon a sorrenden, ahogyan egy AI-rendszert érdemes gyorsabbá, olcsóbbá és jobbá tenni — a legolcsóbb, leggyorsabban visszafordítható beavatkozásoktól a legköltségesebbek felé. Ehhez az kell, hogy előbb tudd mérni, mit optimalizálsz; erről szól az 11. Evals fejezet, amelyre itt végig építünk.

Miért fontos ez a gyakorlatban? Mert az AI-költségek a kérések számával arányosan nőnek — ami prototípusban elhanyagolható, az skálán könnyen elszabadul. Egy prototípus, ami napi 100 kérést szolgál ki, elhanyagolható pénzbe kerül. Ugyanaz a rendszer napi 1 millió kérésnél, ha minden hívást a legdrágább modellre és a leghosszabb contextre bíz, könnyen havi öt-hat számjegyű dollárszámlát produkál. A különbség egy jól optimalizált és egy naiv rendszer között tipikusan 5-20× a fajlagos költségben — anélkül, hogy a felhasználó bármit érzékelne a minőségből. Az optimalizáció tehát nem „nice to have", hanem az, ami eldönti, hogy a termékedet egyáltalán meg lehet-e fizetni skálán.

Az optimalizáció sorrendje

Ez a fejezet legfontosabb üzenete. Az optimalizálásnak van egy bevált sorrendje, és a lépések olcsóságban és visszafordíthatóságban egyre romlanak, ahogy haladsz lefelé. A legtöbb fájdalom abból származik, hogy valaki átugorja az elejét és rögtön a legalján kezd.

1. Definiáld a sikert Mit jelent egyáltalán, hogy „jó"? Mérhető, konkrét kritérium kell: pontosság, latency-küszöb, költségplafon sikeres feladatonként. Amit nem tudsz definiálni, azt nem tudod optimalizálni sem — csak azt hiszed, hogy javítasz rajta. Konkrétan: „a válaszok 95%-a legyen faktikusan helyes, a p95 latency 3 másodperc alatt, a fajlagos költség 2 cent alatt kérésenként" — ez definíció; a „legyen jó és gyors" nem az.
2. Építs eval datasetet Reprezentatív, címkézett példák, edge case-ekkel és negatív esetekkel együtt. Ez a mérőszalagod: minden későbbi változtatást ehhez viszonyítasz. Már 50-100 jól válogatott példa is nagyságrendekkel jobb, mint a semmi — ne várj a „tökéletes" datasetre. Részletesen lásd az 11. Evals fejezetben.
3. Készíts baseline-t a legerősebb modellel Először a legjobb (és igen, legdrágább) modellel érd el a kívánt minőséget. Ez megmutatja, hogy a feladat egyáltalán megoldható-e LLM-mel. Ha a legerősebb modell sem elég jó, nem modellt kell váltanod — a feladaton, a contexten vagy a retrievalen van a hiba. A baseline egyben a felső korlátod is: olcsóbb modellre váltva legfeljebb ezt a minőséget közelítheted meg, felülmúlni nem fogod.
4. Javítsd a contextet és a toolokat A legtöbb minőségi probléma nem a modellben van, hanem abban, amit elé raksz. Jobb instrukciók, tisztább context, pontosabb tool-leírások gyakran többet javítanak, mint bármilyen modellcsere (lásd 2. Context engineering és 7. Tool engineering).
5. Javítsd a retrievalt Ha a rendszer külső tudásra támaszkodik, a rossz válasz oka gyakran a rossz retrieval: nem a megfelelő dokumentumot kapta meg a modell. Hybrid search, reranking, query rewriting — ezek olcsóbbak és biztosabbak, mint a modell átalakítása (lásd 4. RAG).
6. Válts kisebb modellre, ahol lehet Ha megvan a minőségi baseline, részfeladatonként próbálj kisebb, olcsóbb modellt — és evallal igazold, hogy tartja a szintet. A jól körülhatárolt feladatok (osztályozás, kinyerés, rövid összefoglalás) gyakran meglepően jól mennek kis modellen: egy címkézési feladatnál a kis modell akár a nagy minőségének 98%-át hozhatja a költség 10-20%-áért.
7. Optimalizáld a latenciát és a költséget Most jönnek a rendszerszintű trükkök: caching, routing, batching, streaming, párhuzamosítás, budgetek. Ezek nem a modellhez nyúlnak, hanem ahhoz, ahogyan hívod. Erről szól a következő szekció.
8. Csak ezután gondolkodj fine-tuningon A fine-tuning az utolsó lépés, nem az első. Akkor van értelme, ha minden fentebbi lépést kimerítettél, és marad egy stabil, ismétlődő minta, amit érdemes „belesütni" egy kisebb modellbe. Ekkorra pontosan tudod, mit és mihez képest mérsz.

Miért pont ez a sorrend?

A sorrend nem önkényes: két tengely szerint rendeződik. Az egyik a költség (mennyi idő, pénz és emberi munka egy beavatkozás), a másik a visszafordíthatóság (milyen könnyen csinálod vissza, ha nem vált be). A prompt átírása másodpercek kérdése és teljesen reverzibilis. Egy fine-tuning futtatás órákig-napokig tarthat, több száz vagy több ezer dollárba kerülhet, és ha rossz adatot használtál, a betanított modell viselkedését csak újratréninggel javítod.

Ebből következik a legfontosabb heurisztika: mindig a leggyengébb elköteleződéssel kezdj. Ha egy problémát meg tudsz oldani promptolással, ne nyúlj RAG-hoz; ha RAG-gal megoldható, ne finomhangolj. A gyengébb elköteleződés nemcsak olcsóbb, hanem gyorsabb iterációt is enged — és az AI-fejlesztésben a gyors iteráció mindent visz.

Gyakori hibák a sorrendben

• „Rossz a válasz, váltsunk nagyobb modellre" A leggyakoribb reflex — és gyakran a rossz irány. Ha a modell nem kapja meg a helyes dokumentumot (retrieval hiba) vagy homályos az instrukció (context hiba), a nagyobb modell csak magabiztosabban téved. Előbb nézd meg, mit adtál a modellnek, mielőtt magát a modellt cserélnéd.
• Optimalizálás mérés nélkül Ha nincs eval dataseted, minden „javítás" csak hiedelem. Láttál már olyat, hogy egy promptátírás egy esetnél jobb lett, tíz másiknál viszont romlott — csak nem vetted észre, mert nem mérted. Mérőszalag nélkül nem optimalizálsz, hanem szerencsejátékozol.
• Túl korai fine-tuning Csábító a gondolat, hogy „betanítjuk a saját adatunkra". A gyakorlatban a legtöbb csapat, aki ezzel kezd, hónapokat és több ezer dollárt költ el, mire rájön, hogy egy jobb prompttal és RAG-gal ugyanoda jutott volna — töredék idő alatt.

Technikák

Az optimalizációs technikákat három tengely mentén érdemes rendezni: mit javítanak elsősorban — a latenciát (sebesség), a költséget, vagy a minőséget és megbízhatóságot. Néhány technika egyszerre több tengelyen is hat; ilyenkor ott soroljuk fel, ahol a legnagyobb a haszna.

Latencia — a sebességet javító technikák

A felhasználó nem a teljes válaszidőt érzékeli, hanem azt, mennyi idő telik el, amíg történik valami. A cél gyakran nem az abszolút gyorsaság, hanem az érzékelt gyorsaság. Két metrikát érdemes külön kezelni: a time-to-first-token (TTFT — mennyi idő az első látható jelig) és a total latency (mennyi idő a teljes válaszig). A streaming a TTFT-t javítja drámaian, miközben a total latency nem változik.

• Streaming A választ tokenről tokenre küldöd, nem egyben — így a felhasználó azonnal lát valamit, és a time-to-first-token drámaian lecsökken. Egy 500 tokenes válasz „egyben" akár 8-10 másodperc várakozás üres képernyő előtt; streaminggel az első szó 300-500ms alatt megjelenik. A teljes válaszidő nem változik, de az élmény igen. UX-szempontból gyakran ez a legnagyobb hatású, legolcsóbb beavatkozás (lásd 1. LLM alapok).
• Parallel model calls Ha több független részfeladat van (pl. egy dokumentum öt szakaszának összefoglalása), ne sorban hívd a modellt, hanem egyszerre. Az összidő a leglassabb hívás idejére csökken, nem a hívások összegére: öt darab 2 másodperces hívás sorban 10 másodperc, párhuzamosan ~2. Csak akkor működik, ha a hívások tényleg függetlenek egymástól.
• Speculative execution Előre elindítasz egy valószínűleg szükséges műveletet, mielőtt biztosan tudnád, hogy kell. Például amíg a modell „gondolkodik", már betöltöd a legvalószínűbb dokumentumot. Ha jól tippeltél, időt nyertél; ha nem, eldobod az eredményt. Analógia: a jó pincér már hozza a vizet, mielőtt kérnéd. Mikor NE: ha a spekulatív művelet drága vagy mellékhatása van (pl. adatot ír) — akkor a rossz tipp többe kerül, mint a nyert idő.
• Async tool execution A tool-hívásokat aszinkron módon futtatod, hogy a rendszer ne blokkoljon egyetlen lassú külső API-ra várva. Miközben az egyik tool fut, a rendszer mással foglalkozhat. Production agenteknél alapelvárás (lásd 13. Production architektúra).
• Parallel retrieval Ha több indexből vagy adatforrásból kérsz le, ne egymás után kérdezd őket. A párhuzamos lekérdezés után egyben rerankeled az összes találatot. Így a retrieval latenciája nem az adatforrások számával, hanem a leglassabbal skálázódik.
• Early exit Ha egy köztes lépés már elég biztos eredményt ad, ne futtasd végig a teljes láncot. Például ha egy olcsó osztályozó magas konfidenciával dönt, felesleges eszkalálni egy drágább, lassabb modellhez. Kevesebb lépés — kevesebb idő és pénz.

A párhuzamosítás Pythonban asyncio-val néhány sor. Figyeld meg, hogy a lényeg a gather: minden hívás egyszerre indul, és a teljes idő a leglassabbhoz igazodik, nem az összeghez.

import asyncio

async def summarize(section):
    resp = await client.responses.create(
        model="gpt-4.1-mini",
        input=f"Foglald össze: {section}",
    )
    return resp.output_text

async def summarize_all(sections):
    # Minden szakasz egyszerre indul, nem sorban
    tasks = [summarize(s) for s in sections]
    return await asyncio.gather(*tasks)

# 5 szakasz: sorban ~10s, párhuzamosan ~2s
summaries = asyncio.run(summarize_all(document_sections))

Mit tanulj belőle: a latencia gyakran nem a modell, hanem az architektúra kérdése. Ugyanaz a modell, ugyanaz a munka — csak más elrendezésben — ötszörös sebességkülönbséget adhat, egyetlen extra token nélkül.

Költség — a kiadást csökkentő technikák

A költség két helyről jön: hányszor hívod a modellt, és mekkora modellt hívsz mennyi tokennel. Szinte minden költségtechnika e kettő valamelyikét támadja. Érdemes tudni, hogy az input és output token ára eltér — az output tipikusan 3-5×-e az inputnak —, ezért a hosszú, fecsegő válaszok aránytalanul drágák.

• Model routing Egy előzetes döntés (szabály vagy kis modell) eldönti, melyik modellhez küldd a kérést. Az egyszerű kéréseket olcsó modell kapja, a nehezeket az erős. Analógia: a call centeres ügyintéző, aki a hívást a megfelelő osztályhoz irányítja, nem próbál mindent maga megoldani. A router maga is lehet egy apró, gyors modell vagy akár egy egyszerű kulcsszó-/hossz-alapú szabály.
• Model cascade Először a legolcsóbb modell próbálkozik; ha az eredmény nem elég jó (konfidencia, validáció vagy egy grader alapján), akkor lép feljebb egy erősebb, drágább modellhez. A kérések nagy része megáll az olcsó szinten, így az átlagköltség lezuhan. Ez a triage-elv: a betegek zöme nem kerül a sürgősségire. Ha a kérések 80%-a megáll az olcsó szinten, az átlagköltség a drága modell árának töredékére esik.
• Smaller model subtaskokra Bontsd fel a feladatot, és minden részfeladathoz a lehető legkisebb, még elég jó modellt használd. A kinyerést, címkézést, formázást gyakran egy apró modell is tökéletesen elvégzi — az erős modellt tartsd a valóban nehéz lépésekre.
• Prompt caching Ha a promptod eleje sokszor ugyanaz (rendszerinstrukció, séma, példák), a provider gyorsítótárazhatja ezt a prefixet, és a következő hívásoknál sokkal olcsóbban és gyorsabban dolgozza fel — a cache-elt input token tipikusan az ára 10-25%-áért megy. Ezért érdemes a statikus részt előre, a változót hátra tenni — cache-barát promptstruktúra.
• Semantic caching Nem a pontos promptot, hanem a jelentését cache-eled: ha egy új kérdés embeddingje elég közel van egy korábbihoz (pl. cosine similarity > 0.95), visszaadod a korábbi választ. Vigyázat, ez kockázatos — a „majdnem ugyanaz" kérdésre néha rossz a régi válasz („mennyi 2+2" vs „mennyi 2+3"), ezért küszöböt és evalt kell hozzá használni.
• Response caching Az azonos kérésre adott teljes választ eltárolod, és legközelebb modellhívás nélkül szolgálod ki. Determinisztikus, gyakran ismétlődő kéréseknél (pl. ugyanaz a dokumentum-összefoglaló) ingyenes és azonnali. Olyan, mint a memoizáció a hagyományos kódban.
• Batching Több kérést egyetlen kötegben küldesz el. Ahol nem kell azonnali válasz (offline feldolgozás, éjszakai indexelés), a providerek batch API-ja jelentős, tipikusan ~50%-os kedvezményt ad, cserébe akár 24 órás feldolgozási ablakot kérhet. Nem a latenciát, hanem a fajlagos költséget optimalizálja.
• Max-turn limit Felső korlát az agent ciklusainak számára. Enélkül egy elakadt agent végtelenül pörögve égeti a tokeneket — egy rossz loopba került agent egyetlen éjszaka alatt több száz dolláros számlát csinálhat. A limit egyszerre költség- és biztonsági kontroll: garantálja, hogy a futás véget ér.
• Tool-call budget Korlátozod, hányszor hívhat toolt egy agent egy feladaton belül. Megakadályozza a felesleges, ismétlődő tool-hívásokat, amelyek nem visznek közelebb a megoldáshoz, csak fogyasztják a keretet.
• Reasoning budget A „gondolkodós" modelleknél beállítható, mennyi belső reasoning tokent használhat a modell. Egyszerű feladatra fölösleges hosszan gondolkodnia — a reasoning tokenek láthatatlanul, de valósan (és output-áron) megdobják a számlát. Egy triviális kérdésre néha többe kerül a rejtett gondolkodás, mint maga a válasz (lásd 1. LLM alapok).
• Dynamic context compression Ahelyett, hogy a teljes előzményt átadnád minden híváskor, dinamikusan összefoglalod, szűröd vagy tömöríted a contextet. Kevesebb input token, olcsóbb és gyakran jobb válasz — a túl sok irreleváns context ráadásul rontja a minőséget is (a „lost in the middle" jelenség, lásd 2. Context engineering).

Prompt caching mélyebben: a struktúra számít

A prompt caching csak akkor működik, ha a prompt eleje bájtról bájtra azonos. Egyetlen változó karakter a prefixben (pl. egy timestamp vagy a felhasználó neve az elején) érvényteleníti a teljes cache-t az adott ponttól. Ezért a szabály: statikus rész előre, változó rész hátra.

# ROSSZ: a változó adat elöl van, a cache soha nem talál
prompt = f"Felhasználó: {user_name}, {timestamp}\n\n{long_system_rules}\n\n{docs}"

# JÓ: a nagy, statikus rész (rules + docs) elöl, a változó hátul
prompt = f"{long_system_rules}\n\n{docs}\n\n---\nKérdés: {user_query}"
# A providerek a stabil prefixet (rules + docs) cache-elik;
# csak a rövid, változó farok kerül teljes áron feldolgozásra.

Mit tanulj belőle: ugyanaz a tartalom, más sorrendben — és a második változat egy sokszor hívott rendszernél a nagy prefix költségének 75-90%-át megspórolja. A caching gyakran a legnagyobb megtérülésű optimalizáció olyan rendszereknél, ahol hosszú, ismétlődő system prompt vagy few-shot példahalmaz van.

Minőség és megbízhatóság — a kimenet biztosságát javító technikák

Az optimalizáció nem csak spórolás: a rendszer akkor jó, ha ritkán bukik el, és ha elbukik, van tartaléka. Néhány technika elsősorban ezt a megbízhatóságot szolgálja — bár a routing és a cascade a költség mellett a minőséget is védi.

• Fallback model Ha az elsődleges modell nem elérhető, timeoutol vagy hibát ad, egy másik modell (akár másik providernél) veszi át. A rendszer így nem áll le egyetlen provider kiesésekor. Ez a tartalék kerék: nem gyorsabb, de akkor számít, amikor baj van. Production rendszernél a több providerre épített fallback a rendelkezésre állás (availability) egyik legfontosabb eszköze.
• Nagyobb modell csak escalation esetén Az erős, drága modellt tartsd tartaléknak: csak akkor lépsz hozzá, ha az olcsóbb megoldás bizonytalan vagy elbukott. Ez a cascade minőségi oldala — a nehéz esetek megkapják a szükséges tűzerőt, a többségnél viszont nem pazarolsz.

A cascade-elv kódban is egyszerű: előbb az olcsó modell próbálkozik, és csak elégtelen eredménynél eszkalálunk.

def answer(query):
    # 1. Olcsó modell próbálkozik először
    draft = cheap_model(query)
    if confidence(draft) >= 0.85:
        return draft  # az esetek többsége itt megáll

    # 2. Escalation: erős modell csak a bizonytalan esetekre
    return strong_model(query)

Mit tanulj belőle: a cascade ereje a forgalom eloszlásában van. Ha a kérések 80%-a triviális és megáll az olcsó szinten, akkor gyakorlatilag a felhasználók ötödénél fizeted csak a drága modellt — miközben a nehéz esetek így is megkapják a legjobb minőséget.

def robust_call(query):
    try:
        return primary_provider(query, timeout=10)
    except (Timeout, ProviderError):
        # Az elsődleges kiesett — a rendszer nem áll le
        return fallback_provider(query, timeout=10)

Mit tanulj belőle: a megbízhatóság nem egyetlen tökéletes modellről szól, hanem a redundanciáról. Egy production rendszer sosem bízhat egyetlen külső szolgáltatás 100%-os elérhetőségében.

Döntési szempontok: melyik tengelyen szorít a cipő?

Ne mindent optimalizálj egyszerre. Először állapítsd meg, melyik dimenzió a szűk keresztmetszet, és arra fókuszálj — a másik kettőt csak addig húzd, amíg nem romlik el.

Model adaptation

Amikor a rendszerszintű technikák sem elegendők, felmerül, hogy magához a modellhez nyúlj. Ezek az eszközök egyre költségesebbek és egyre kevésbé visszafordíthatók — fentről lefelé haladva egyre nagyobb elköteleződést kérnek. Fontos tudni, mikor melyik indokolt.

• Prompt engineering A legolcsóbb adaptáció: a viselkedést pusztán az instrukciókkal, példákkal és a formátum megadásával alakítod. Nulla tréningköltség, azonnal visszafordítható. Mindig innen indulj — sok „modellproblémának" hitt dolog valójában rossz prompt (lásd 2. Context engineering).
• RAG (retrieval-augmented generation) Nem a modellt változtatod, hanem külső tudást adsz be futásidőben. Így a modell friss, cégspecifikus vagy jogosultságfüggő adatot használhat anélkül, hogy bármit betanítanál. A tudás frissítése egy dokumentum cseréje, nem egy újratréning (lásd 4. RAG).
• Supervised fine-tuning (SFT) Címkézett bemenet–kimenet párokon tanítod tovább a modellt, hogy egy konkrét stílust, formátumot vagy feladatot megbízhatóan hozzon. Sok jó minőségű példa kell hozzá — tipikusan legalább néhány száz, de inkább pár ezer —, és minden példa lényegében egy „megmutatom, hogyan kell" lecke a modellnek. A rossz vagy inkonzisztens tanítóadat rosszabb modellt eredményez, mint a fine-tuning nélküli alap.
• LoRA / PEFT Parameter-efficient fine-tuning: nem az egész modellt tanítod újra, hanem csak néhány kis adapter-réteget. Sokkal olcsóbb és gyorsabb, mint a teljes finomhangolás, és több különböző adaptert is tarthatsz ugyanahhoz az alapmodellhez — így egy alapmodellre több „személyiséget" is ráültethetsz. Ma a legtöbb fine-tuning valójában így történik.
• Preference tuning A modellt nem egyetlen „helyes" válaszra tanítod, hanem preferenciapárokon: „ez a válasz jobb, mint az". Így finomítható a hangnem, a hasznosság vagy a biztonságosság, ahol nincs egyetlen objektív jó válasz, csak jobb és rosszabb. A DPO (Direct Preference Optimization) ma ennek elterjedt, viszonylag egyszerű módszere.
• Reinforcement fine-tuning (RFT) A modellt jutalomjel alapján tanítod: egy grader vagy verifikálható kimenet pontozza a válaszokat, és a modell a magasabb jutalmú viselkedés felé mozdul. Akkor erős, ha van objektíven ellenőrizhető siker (pl. lefut-e a kód, helyes-e a számítás, átmegy-e a teszt).
• Distillation Egy erős, drága modell (a „tanár") kimeneteiből tanítasz be egy kisebb, olcsóbb modellt (a „diák"). A cél, hogy a kicsi modell a szűk feladaton közel akkora minőséget hozzon, töredék áron. Analógia: a mester kimeneteit másolva a tanítvány elsajátítja a fogásokat anélkül, hogy évekig tanulna. A gyakorlatban ez a fine-tuning egyik legkifizetődőbb formája.
• Continued pretraining Az alapmodellt nagy mennyiségű, címkézetlen domain-szövegen tanítod tovább (pl. orvosi vagy jogi korpusz), hogy a szaknyelvet és a terület alapmintáit jobban ismerje. Ez a legdrágább és leginkább specialista beavatkozás — ritkán éri meg alkalmazásszinten, jellemzően csak nagy, erőforrás-gazdag szervezeteknél.
• Quantization A modell súlyainak kisebb pontosságra kerekítése (pl. 16 bitről 4-re), hogy kevesebb memóriát foglaljon és gyorsabban fusson, minimális minőségromlás árán. Egy 4-bites quantization tipikusan a memóriaigényt a negyedére csökkenti, így egy nagy modell egyetlen GPU-ra is elfér. Nem a viselkedést változtatja, hanem az inference erőforrásigényét — főleg self-hosted esetben számít (lásd 1. LLM alapok és 16. AI Platform).

A fine-tuning valósága: mit kapsz és mit nem

A fine-tuning nem tud tudást hozzáadni megbízhatóan — nem attól lesz „okosabb" a modell egy témában, hogy betanítod rá. Amit jól tanít: a viselkedést, a formátumot, a stílust és a feladat-mintázatot. Ha friss, tényszerű tudásra van szükséged, az RAG a jó eszköz, nem a fine-tuning.

Mikor mit? A döntés

A leggyakoribb kérdés: RAG, fine-tuning vagy tool? Ezt gyakran vagylagosan teszik fel, pedig a legtöbb valós rendszerben kombinálod őket. Mégis hasznos tudni, melyik problémára melyik az alap válasz — a három eszköz három különböző hiányt pótol: a hiányzó tudást, a hiányzó viselkedést és a hiányzó cselekvőképességet.

A döntést három egyszerű kérdés segít eldönteni; ha többre is igent mondasz, kombináld az eszközöket.

• RAG kell, ha… Változó külső tudást adsz a modellnek, forrásokat kell idézni, a dokumentumok frissülnek, vagy jogosultságfüggő adatot kezelsz. Röviden: a tudás kívül van és mozog.
• Fine-tuning kellhet, ha… Stabil viselkedést vagy formátumot tanítasz, domain-specifikus stílus kell, sok azonos jellegű feladatod van, kisebb modellen akarsz jó teljesítményt, vagy a prompt már túl hosszú és komplex lett. Röviden: a minta stabil, és megéri „belesütni".
• Tool kell, ha… Aktuális vagy tranzakciós adat szükséges, számolni kell, adatot kell módosítani, vagy egy külső rendszerben kell műveletet végrehajtani. Röviden: nem tudni, hanem tenni kell valamit (lásd 7. Tool engineering).

Kombináció a gyakorlatban

A valós rendszerek ritkán választanak egyet a háromból. Egy tipikus production ügyfélszolgálati asszisztens például mindhármat használja egyszerre: RAG-gal hozza be a friss termékdokumentációt és a szabályzatokat, toolokkal kérdezi le az adott ügyfél aktuális rendelését és számláját, és opcionálisan fine-tuninggal biztosítja, hogy a válaszok mindig a cég hangnemében és a megkövetelt strukturált formátumban jöjjenek. A kérdés tehát nem „melyik", hanem „melyik hiányt melyikkel pótolom".

Összefoglalás

Az optimalizáció nem egyetlen trükk, hanem egy sorrend: definiáld a sikert, építs eval datasetet, állíts fel baseline-t a legerősebb modellel, majd javítsd a contextet, a toolokat és a retrievalt — és csak ezután nyúlj kisebb modellhez, rendszerszintű technikákhoz, végül a fine-tuninghoz. A sorrend logikája egyszerű: mindig a leggyengébb elköteleződéssel kezdj, mert az a legolcsóbb és a legkönnyebben visszafordítható. A legdrágább hiba a végét venni előre.

A technikákat három tengelyen érdemes rendezni: a latenciát javítja a streaming, a párhuzamosítás és az early exit; a költséget a routing, a cascade, a caching, a batching és a különféle budgetek; a megbízhatóságot a fallback és az escalation. Ezek nagy része nem a modellhez, hanem ahhoz nyúl, ahogyan hívod — és éppen ezért olcsó és biztonságos. A model adaptation eszközei (prompt engineeringtől a distillationön át a quantizationig) egyre költségesebbek — mindig a legolcsóbbal kezdj.

A „RAG vagy fine-tuning vagy tool?" ritkán vagylagos: a RAG a hiányzó tudást, a fine-tuning a hiányzó viselkedést, a tool a hiányzó cselekvőképességet pótolja. Ha tudod, melyik hiányzik, tudod, mit használj — és mindezt csak azért tudod eldönteni, mert előbb megmérted. Az optimalizáció végső tanulsága: mérj először, optimalizálj másodszor, és fine-tuningolj utoljára.