Az LLM-ek működésének gyakorlati megértése

Miért érdekel ez téged?

Az LLM egy statisztikai szövegjósló: a betáplált szöveg alapján a legvalószínűbb következő tokent generálja, újra és újra. Ez az egyszerű elv magyaráz szinte minden furcsaságot — a hallucinációt, a nemdeterminizmust, az árazást és azt is, miért „felejt el" dolgokat.

Gondolj rá úgy, mint egy hihetetlenül művelt, de kissé szórakozott kollégára, aki mindig magabiztosan válaszol — akkor is, ha csak tippel. A te feladatod mérnökként az, hogy körülvedd olyan rendszerrel (grounding, validáció, evalok), amely a tippelést megbízható munkává szelídíti.

Nem kell transformer-kutatónak lenned, és nem is az a cél, hogy fejből tudd levezetni az attention képletét. A cél az, hogy a működés minden „furcsasága" mögé lásd az okot — mert amíg okot látsz, addig tervezel; amint nem, addig babonázol. Az egész fejezet erről szól: annyi belső működést értsél meg, amennyi ahhoz kell, hogy jó mérnöki döntéseket hozz árazásról, modellválasztásról, context-méretezésről és arról, mit bízol egyáltalán a modellre.

Az alapfogalmak, amiket értened kell

Ezek nem akadémiai kuriózumok — mindegyik közvetlenül befolyásol egy döntést, amit építés közben meghozol. Először vedd végig a listát, aztán a következő szekciókban mélyebbre megyünk a legfontosabbakban.

• Tokenizáció A szöveg felosztása tokenekre, amelyeket a modell számokként dolgoz fel. Egy token lehet egy szó, szórész vagy karakter — az angol „hello" egy token, de egy hosszú magyar összetett szó akár 8-10 token is lehet. Ez közvetlenül hat az árazásra és a context window kihasználására: minél több token, annál drágább és annál kevesebb hely marad az ablakban. Ökölszabály angolra: ~4 karakter vagy ~0,75 szó egy token; magyarra ez rosszabb, mert a tokenizálót túlnyomórészt angol szövegen tanították.
• Embeddingek A szöveg jelentését sűrítő számvektor (tipikusan 384–3072 dimenzió). Két hasonló jelentésű mondat vektora közel lesz egymáshoz a térben — ezért lehet velük szemantikus keresést csinálni (lásd 4. RAG). A hasonlóságot általában koszinusz-távolsággal méred. Az embedding nem ugyanaz, mint a generatív modell: más a feladata, és külön modellt hívsz hozzá.
• Attention és context window Az attention az a mechanizmus, amivel a modell minden token generálásakor „visszanéz" a korábbi tokenekre, és eldönti, melyik mennyire fontos az éppen soron következő szó szempontjából. A context window az a maximális tokenmennyiség, amit egyszerre lát — ezen belül minden benne van, amit „tud" az adott hívásnál: a system prompt, a beszélgetés, a betöltött dokumentumok és az eddigi válasz is. Ami kicsúszik az ablakból, az a modell számára nem létezik.
• KV cache A Key-Value cache az attention gyorsítótára. Generálás közben minden új tokennél visszanéz az összes korábbira — a KV cache eltárolja ezeket a köztes számításokat, hogy ne kelljen újraszámolni. Analógia: mint amikor egy vizsgán jegyzetelhetsz, nem kell fejben tartanod mindent. A KV cache mérete a fő szűk keresztmetszet a GPU memóriánál, és ez az oka annak is, hogy a hosszú promptok lassabbak és drágábbak.
• Input-, output- és reasoning tokenek Az input a promptod, az output a válasz, a reasoning token pedig a „gondolkodós" modellek belső, gyakran nem látható lépéssora. Mindhármat külön számlázzák, és az output (illetve a reasoning) tipikusan 3-5×-ös szorzóval drágább, mint az input. A reasoning tokenek jelentősen megdobhatják a költséget anélkül, hogy egy karaktert is látnál belőlük — egy nehéz feladatnál a „gondolkodás" simán lehet több ezer token.
• Generatív és embedding modellek különbsége A generatív modell szöveget ír, az embedding modell vektort készít. Keresésnél embeddinggel indexelsz és keresel, de a végső választ generatív modell fogalmazza meg. Rossz eszközt választani olyan, mint kalapáccsal csavart behajtani: technikailag „megy", gyakorlatilag rossz. Az embedding modellek ráadásul nagyságrenddel olcsóbbak, ezért indexelni sosem generatív modellel indexelsz.
• Reasoning és nem reasoning modellek A reasoning modellek több lépésben „gondolkodnak", mielőtt válaszolnak — jobbak komplex logikában, matematikában, tervezésben, több lépéses agent-feladatokban. Cserébe lassabbak (a TTFT másodpercekig is tarthat, amíg „gondolkodik") és drágábbak. Egyszerű kinyerési, osztályozási vagy formázási feladatra fölösleges őket bevetni — ott csak pénzt és időt égetsz.
• Vision-language és audio modellek Nem csak szöveget értenek: képet, dokumentumot vagy hangot is fel tudnak dolgozni. A képet is tokenné bontják — egy nagy felbontású kép több száz vagy több ezer tokent is felemészthet, tehát a vision hívás gyorsan drága lesz. A multimodális alkalmazások külön mérnöki kihívás — erről bővebben a 10. Multimodális fejezet szó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. Cserébe kicsit romolhat a minőség — a 8 bit gyakran alig érezhető, a 4 bit alatt már mérni kell. Főleg self-hosted inference-nél számít, ahol a GPU-memória a szűk keresztmetszet (lásd 16. AI Platform).
• Sebesség–minőség–ár kompromisszum Nincs ingyen ebéd: a legerősebb modell a legdrágább és leglassabb. A mérnöki művészet az, hogy minden részfeladathoz a lehető legkisebb, még elég jó modellt válaszd — de ezt csak evalokkal tudod eldönteni (lásd 12. Optimalizáció). A jó gyakorlat: erős modellel állítsd fel a minőségi baseline-t, aztán bizonyítsd evallal, hogy egy olcsóbb is elég.
• Context length vs. tényleges használhatóság Az, hogy egy modell 1 millió tokent „elfogad", nem jelenti, hogy mindet jól is használja. A közepén lévő információt gyakran „elveszti" (lost in the middle jelenség): egy 200 oldalas dokumentum közepére rejtett tényt sokkal rosszabbul találja meg, mint az elejére vagy a végére tettet. A context véges attention budget — ne öntsd tele.
• Hallucination, nemdeterminizmus és model drift A hallucináció, hogy a modell magabiztosan állít valótlant — nem bug, hanem a működés velejárója. A nemdeterminizmus, hogy ugyanarra a promptra máskor mást válaszolhat. A model drift, hogy a provider frissítésével a viselkedés csendben megváltozik. Mindhárom ellen evalok és verziópinnelés véd — külön szekcióban vesszük végig őket.
• Temperature, top-p és stop conditionök A temperature és a top-p a „kreativitás szabályozói": alacsony érték fókuszált, kiszámítható választ ad, magas érték változatosabbat és kockázatosabbat. Kinyeréshez, osztályozáshoz, structured outputhoz alacsonyra állítsd (0 közelébe); ötleteléshez, fogalmazáshoz magasabbra (0,7–1,0). A stop condition megmondja, hol álljon le a generálás — pl. egy záró tag vagy egy üres sor.
• Streaming és time-to-first-token (TTFT) A streaming azt jelenti, hogy a választ tokenről tokenre kapod, nem egyben — így a felhasználó azonnal lát valamit, még ha a teljes válasz 10 másodperc is. A TTFT az első token megérkezéséig eltelt idő; UX szempontból gyakran fontosabb, mint a teljes válaszidő, mert ez dönti el, hogy „lassúnak" érződik-e a rendszer (lásd 19. Product/UX).
• Provider rate limitek és model verziók A providerek korlátozzák, hány kérést (RPM) vagy tokent (TPM) küldhetsz percenként — production rendszerben ezt kezelned kell retryvel, exponenciális backoffal, esetleg több kulccsal vagy régióval. A model verziót pedig pinneld egy konkrét snapshotra, különben egy csendes frissítés (model drift) tönkreteheti az evaljaidat egyik napról a másikra.

A statisztikai szövegjóslás mechanikája

Minden fenti fogalom egyetlen alapmechanizmusból következik: a modell autoregresszív, azaz mindig csak egy következő tokent jósol, a már meglévő szöveg (a prompt + az eddig generált válasz) feltételével. Ezt a tokent hozzáfűzi a szöveghez, és az egészet újra betáplálja — így nő a válasz tokenről tokenre. A modell nem „lát előre", nincs terve a mondat végéről; minden lépésben egy valószínűségi eloszlást számol az összes lehetséges következő tokenre, és abból mintavételez.

Ebből az egy mondatból levezethető szinte minden: miért drágább az output (mert soronként újra le kell futtatni a modellt), miért van szükség KV cache-re (hogy ne kelljen minden lépésnél újraszámolni a korábbi tokeneket), miért nemdeterminisztikus (mert mintavételez az eloszlásból), és miért hallucinál (mert a „hihető" és az „igaz" a modell számára ugyanaz a valószínűségi jel).

Token a gyakorlatban

A tokenizáció nem elméleti kérdés: a magyar szöveg jellemzően több tokenre bomlik, mint az azonos jelentésű angol, mert a modellek tokenizálóját túlnyomórészt angol szövegen tanították. Ugyanaz a mondat magyarul így többe kerülhet és több helyet foglal a context window-ban — ez a „magyar adó", amit érdemes betervezni a költségbe.

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4.1")
hu = "A mesterséges intelligencia átalakítja a szoftverfejlesztést."
en = "Artificial intelligence is transforming software development."

print(len(enc.encode(hu)))  # ~18 token
print(len(enc.encode(en)))  # ~9 token

A tanulság: ha költséget vagy context-férőhelyet tervezel, mérd meg a tokeneket — ne a karaktereket vagy a szavakat számold. Ugyanez a szöveg magyarul nagyjából kétszer annyi tokenbe kerül; egy ilyen kétszeres szorzó egy nagy volumenű rendszernél havi szinten komoly összeg.

Nagyságrendek, amikkel érdemes fejben számolni

Nem kell fejből tudnod az árlistát, de a nagyságrendek segítenek gyorsan megérezni, mi drága és mi nem. Az alábbi táblázat tipikus, becsült értékeket mutat — a pontos számot mindig a provider aktuális dokumentációjából vedd.

Modelltípusok: melyiket mire használd

Az „LLM" gyűjtőfogalom több, eltérő rendeltetésű modellt takar. A jó mérnök nem egyetlen modellt használ mindenre, hanem minden részfeladathoz a megfelelőt választja. Ebben a szekcióban végigvesszük a fő típusokat és azt, mikor melyik való.

Generatív vs. embedding modell

A kettő nem egymás versenytársa, hanem egy pipeline két különböző szerszáma. Egy tipikus RAG-rendszerben mindkettőt használod: embedding modellel indexeled és keresed a dokumentumokat, majd generatív modellel fogalmazod meg a választ a megtalált részletekből.

Reasoning vs. nem reasoning modell

A reasoning modell a válasz előtt egy belső „gondolkodási" fázist futtat le — láthatatlan reasoning tokeneket generál, amelyekben lépésről lépésre végigmegy a problémán. Ettől sokkal jobb komplex, több lépéses feladatokban (matematika, kódtervezés, összetett agent-döntések), de cserébe lassabb és drágább. Egy egyszerű „nyerd ki a nevet és a dátumot ebből a mondatból" feladatnál ez tiszta pazarlás.

Vision-language és audio modellek

A multimodális modellek nem csak szöveget, hanem képet, dokumentumot vagy hangot is bemenetként fogadnak. A kulcs, hogy ezeket is tokenné bontják: egy nagy felbontású képernyőkép több ezer tokent is jelenthet, egy percnyi hang szintén jelentős. Használd őket, ha az input maga vizuális vagy hangalapú (szkennelt űrlap, diagram, hangfelvétel) — de ha a tartalom már tiszta szövegként is elérhető, ne pazarolj rájuk. A részletekért lásd a 10. Multimodális fejezetet.

Quantization: amikor te üzemeltetsz

Ha nem provider API-t hívsz, hanem magad futtatod a modellt (self-hosted inference), a quantization dönti el, elfér-e a modell a GPU-dban. A súlyok pontosságát csökkented (pl. FP16 → INT4), amivel a memóriaigény drámaian esik — egy modell, ami 16 biten 140 GB, 4 biten már ~40 GB alá kerülhet. Cserébe a minőség kicsit romlik: 8 biten általában alig, 4 bit alatt már mérni kell evallal. Ez tisztán platform-döntés, részletei a 16. AI Platform fejezetben.

Költség, sebesség és a context window közgazdaságtana

Egy production LLM-rendszernél a költség és a késleltetés nem utólagos gond, hanem tervezési kényszer. Ebben a szekcióban összekapcsoljuk a tokeneket, a KV cache-t, a streaminget és a rate limiteket egyetlen gyakorlati képpé.

Miből áll a számla

A költséget három tokentípus adja össze: input (a prompt), output (a látható válasz) és — reasoning modellnél — a rejtett reasoning tokenek. Mivel az output többszörösen drágább az inputnál, a bőbeszédű válaszok aránytalanul sokba kerülnek. Egy egyszerű becslő függvény sokat segít a tervezésnél.

def hivas_koltseg(input_tok, output_tok,
                  ar_input, ar_output):
    # az árak $/1M token-ben értendők (tipikus egység)
    return (input_tok / 1_000_000) * ar_input + \
           (output_tok / 1_000_000) * ar_output

# pl. 3000 token prompt, 500 token válasz
print(hivas_koltseg(3000, 500,
                     ar_input=2.5, ar_output=10.0))
# a válasz aránya a költségben gyakran nagyobb,
# mint amit a tokenszám alapján várnál

Amit tanulj belőle: a rövidebb, célzottabb válasz nem csak jobb UX, hanem közvetlen megtakarítás is. A „légy tömör" instrukció és a `max_tokens` korlát nem stílus­kérdés, hanem költség­kontroll.

Miért lassít és drágít a hosszú context

A KV cache miatt minden korábbi token „ott ül" a memóriában, és minden új token generálásakor részt vesz az attention számításban. Ezért egy 80 000 tokenes prompt nem csak drágább, hanem lassabb TTFT-t is ad, mint egy 4 000 tokenes — a modellnek először az egész promptot fel kell dolgoznia (prefill), mielőtt az első választokent kiadná. Ez a gyakorlati oka annak, miért nem érdemes „biztos, ami biztos" alapon mindent beönteni az ablakba.

Streaming és a TTFT mint UX-eszköz

Streaming nélkül a felhasználó egy pörgő ikont bámul, amíg a teljes válasz elkészül — ez 5-10 másodpercnél már türelmetlenné tesz. Streaminggel az első token pár száz ezredmásodperc múlva megjelenik, és a szöveg folyamatosan „gépelődik", így a rendszer gyorsnak érződik akkor is, ha a teljes válaszidő ugyanannyi. A TTFT tehát gyakran fontosabb metrika, mint a teljes latencia.

from openai import OpenAI
client = OpenAI()

stream = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": "Írj egy limericket a tokenekről."}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)  # azonnal kiírjuk

Amit tanulj belőle: a streaming nem gyorsítja a modellt, csak korábban ad visszajelzést. A felhasznált tokenszám és a teljes idő ugyanannyi — de a felhasználói élmény sokkal jobb.

Rate limitek és model verziók

A providerek percenkénti kérés- (RPM) és token- (TPM) limitet szabnak. Ha ezt átléped, HTTP 429-et kapsz, és egy naiv rendszer itt egyszerűen elhasal. Production­ben ezt exponenciális backoffal és retryvel kezeled, esetleg több kulccsal vagy régióval terheléselosztva — a részletes mintát a 13. Production architektúra model gateway része tárgyalja.

A megbízhatatlanság három arca

Az LLM-mel dolgozó mérnök legfontosabb belátása, hogy a modell alapból nem megbízható — és ez nem hiba, hanem tulajdonság. Három formában találkozol vele: hallucináció, nemdeterminizmus és model drift. Mindhárom ugyanabból a valószínűségi működésből ered, és mindhárom ellen rendszerrel véded magad.

Hallucináció

A modell a legvalószínűbb következő tokent generálja, nem azt, ami igaz — a „hihető" és az „igaz" számára ugyanaz a jel. Ezért magabiztosan kitalál nem létező forrásokat, API-végpontokat, jogszabályi paragrafusokat. Soha ne bízz egy LLM faktikus állításában ellenőrzés nélkül. A védekezés a grounding: adj a modellnek megbízható forrást (RAG, tool call), és kérd, hogy csak abból dolgozzon, illetve mondjon nemet, ha nincs elég információ (abstention — lásd 4. RAG).

Nemdeterminizmus

Mivel a modell az eloszlásból mintavételez, ugyanarra a promptra máskor más választ adhat — még temperature=0 mellett is előfordulhat kis eltérés, hardveres és batching okokból. Ez azt jelenti, hogy nem tesztelhetsz egzakt string-egyezésre úgy, mint egy determinisztikus függvényt. Ezért van szükség evalokra, amelyek eloszlásban, sok példán mérik a minőséget, nem egyetlen futáson (lásd 11. Evals).

Temperature és top-p: a mintavétel szabályozói

A temperature „lelapítja" vagy „kihegyezi" a valószínűségi eloszlást: alacsony (0 közeli) érték szinte mindig a legvalószínűbb tokent választja — fókuszált, kiszámítható, ismételhetőbb. Magas érték (0,8–1,2) esélyt ad a ritkább tokeneknek is — változatosabb, kreatívabb, de kockázatosabb. A top-p (nucleus sampling) más úton hasonlót ér el: csak a legvalószínűbb tokenek közül mintavételez, amíg a valószínűségük összege el nem éri a p küszöböt.

from openai import OpenAI
client = OpenAI()

def hivas(prompt, temperature):
    return client.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": prompt}],
        temperature=temperature,
    ).choices[0].message.content

# kinyerés, osztályozás, structured output -> alacsony
adat = hivas("Nyerd ki a dátumot JSON-ben: 2026. július 13.", temperature=0)

# ötletelés, fogalmazás -> magasabb
otletek = hivas("Adj 5 kreatív terméknevet egy jegyzetappnak.", temperature=0.9)

Amit tanulj belőle: a temperature nem „minőség-csúszka", hanem a determinizmus és a változatosság közti kompromisszum. Adatkinyeréshez és structured outputhoz állítsd 0 közelébe; kreatív feladathoz emeld. Egy dolgot ne várj tőle: hogy „igazabbá" tegye a választ — a hallucináció ellen nem a temperature véd.

Model drift

Ha a provider frissíti a modellt a háttérben, a viselkedés megváltozhat: ami tegnap átment az evalodon, ma megbukhat, vagy fordítva. Ez különösen alattomos, mert nem kapsz róla hibaüzenetet. A védekezés kettős: verziópinnelés (fix snapshotra hivatkozz) és rendszeres regression eval, ami elkapja, ha egy modell- vagy promptváltozás rontott a minőségen.

Tudnod kell dönteni

Az igazi mérnöki tudás nem a fogalmak felmondása, hanem a jó döntés a konkrét helyzetben. Íme a leggyakoribb kérdések, mindegyikhez egy tipikus szituációval.

• Mikor kell erősebb modell? Ha a feladat többlépéses következtetést, komplex kódot vagy megbízható tervezést igényel — pl. egy agent, aminek egy hibás lépés az egész futását elrontja. Itt a nagyobb modell megbízhatósága megéri az árát, mert egy elrontott futás újrafuttatása vagy egy hibás művelet sokkal többe kerül, mint a drágább token.
• Mikor elég kisebb, olcsóbb modell? Jól körülhatárolt, ismétlődő feladatoknál: osztályozás, kinyerés fix sémára, rövid összefoglalás. Ha ezt egy erős baseline után evallal igazolod, sok pénzt spórolsz — egy nagy volumenű pipeline-nál a modellváltás akár egy nagyságrendnyi költségcsökkenést is hozhat, minőségvesztés nélkül.
• Mikor kell embedding modell? Amikor jelentés alapján kell keresned vagy csoportosítanod — pl. „találd meg a szerződés releváns bekezdését". Kulcsszavas, pontos egyezésű keresésre nem embedding, hanem BM25 a jó eszköz; a kettő kombinációja a hybrid retrieval, ami a gyakorlatban általában felülmúlja bármelyiket önmagában.
• Mikor kell reranker? Ha a retrieval sok, közepesen releváns találatot ad, és a legjobb néhányat kell kiszűrnöd a válasz elé. A reranker drágább és lassabb (tipikusan 100-500 ms plusz), de pontosabb rendezést ad — akkor éri meg, ha a válasz minősége a top találatokon múlik, és a recall már jó, csak a precizitás gyenge.
• Mikor kell vision modell? Ha az input maga vizuális: szkennelt dokumentum, diagram, képernyőkép, űrlap. Ha a tartalom már tiszta szövegként elérhető (pl. egy rendes HTML vagy egy jól OCR-ezett szöveg), ne pazarolj vision modellt rá — lassabb, drágább, és gyakran rosszabb is, mint a szöveges feldolgozás.
• Mikor jobb determinisztikus kódot írni, mint még egy LLM-hívást hozzáadni? Amikor a feladat pontosan meghatározható: dátumformázás, összeadás, validáció, elágazás fix szabályokra. Egy LLM-hívás itt csak bizonytalanságot, késleltetést és költséget ad hozzá. Alapszabály: ha meg tudod írni `if`-fel, írd meg `if`-fel — a legjobb LLM-hívás gyakran az, amit meg sem hívsz.

Döntési szempontok: LLM-hívás vs. determinisztikus kód

Ez a döntés visszatér szinte minden rendszernél, ezért érdemes explicit szempontokat használni. Ha a bal oszlop igaz, valószínűleg kódot írj; ha a jobb, akkor van értelme LLM-nek.

Gyakori hibák kezdő AI mérnököknél

Ezek a hibák szinte mindenkinél előjönnek az első rendszereknél. Ha előre ismered őket, hónapokat spórolsz — mindegyik egy-egy fenti fogalom félreértéséből fakad.

• „Öntsünk be mindent a nagy context window-ba" A több kontextus nem mindig jobb: az irreleváns szöveg elvonja az attention-t, drágít, lassít, és a lost-in-the-middle miatt a lényeg elveszhet. Adj be célzottan annyit, amennyi kell, és nem többet.
• Faktikus állítást ellenőrzés nélkül elhinni A modell magabiztosan hallucinál forrásokat, számokat, API-kat. Production­ben groundinggal (RAG, tool) és validációval kell alátámasztani minden állítást, amit egy másik rendszer vagy ember felhasznál.
• Egyetlen futásból ítélni a minőségről A nemdeterminizmus miatt egy „szép" válasz nem bizonyít semmit. Evalra van szükség: sok példa, eloszlásban mért minőség (11. Evals).
• A „latest" model-aliasra építeni Verziópinnelés nélkül egy csendes providerfrissítés bármikor megváltoztathatja a viselkedést. Pinnelj snapshotra, és futtass regression evalt váltás előtt.
• Rate limit és retry nélkül élesíteni A 429-es hibák és a hálózati zaj a normál üzem része. Backoff, retry és timeout nélkül az első terheléscsúcs kiüti a rendszert.
• LLM-et használni oda, ahol egy `if` is elég Determinisztikus feladatra (formázás, számolás, validáció) az LLM csak bizonytalanságot és költséget ad. A legolcsóbb, leggyorsabb és legmegbízhatóbb hívás az, amit ki sem küldesz.

Összefoglalás

Az LLM egy valószínűségi szövegjósló, amely mindig csak a következő tokent találja el a meglévő szöveg alapján — ebből az egy mechanizmusból fakad minden erőssége és minden veszélye. A tokenizáció a költséged és a context-férőhelyed valutája (magyarul dupla áron); a context window egy véges attention budget, nem korlátlan tárhely; a KV cache magyarázza, miért lassabb és drágább a hosszú prompt; a hallucináció, a nemdeterminizmus és a model drift pedig nem hiba, hanem a működés velejárója, amit evalokkal, groundinggal és verziópinneléssel kell megzabolázni.

Végigvettük a fő modelltípusokat (generatív, embedding, reasoning, vision, audio), a quantizationt, a temperature és a streaming szerepét, valamint a költség és a latencia közgazdaságtanát. A gyakorlati tudás lényege azonban a döntés: melyik modell, mikor embedding, mikor reranker, mikor vision, és mikor jobb egyszerűen determinisztikus kódot írni. Ha ezekre magabiztosan tudsz válaszolni — és felismered a gyakori hibákat, mielőtt elköveted őket —, kész vagy a következő rétegre: hogyan tervezd meg tudatosan, mi kerül egyáltalán a modell elé.