02 – Tokens and Context Window¶

Az LLM nem közvetlenül karaktereket vagy hagyományos értelemben vett szavakat dolgoz fel. A szöveg először tokenekre bomlik, és a modell ezekkel dolgozik.

A tokenek megértése azért fontos, mert a context mérete, a költség és sok esetben a latency is tokenekhez kötődik.

Mi a token?¶

Egy token lehet:

teljes szó;
szórészlet;
írásjel;
whitespace mintázat;
kódrészlet.

Például egy egyszerű mondat nem feltétlenül úgy tokenizálódik, hogy egy szó = egy token.

"authentication failed"

Lehetséges, hogy az egyik tokenizer számára néhány token, egy másik számára több. Nyelvtől és modelltől is függ.

Ezért a pontos tokenszámot mindig a konkrét tokenizer határozza meg. Durva fejben számolásra lehet becslést használni, de rendszertervezésnél a valódi token count az érdekes.

Mi kerül a contextbe?¶

A context nem csak a user aktuális kérdése.

Egy valós AI applicationben például:

system instructions
+ developer/application instructions
+ conversation history
+ user question
+ retrieved documents
+ tool results
+ examples
+ generated reasoning/state depending on runtime
= effective context

A modell az adott hívásban ebből dolgozik.

Context window¶

A context window azt a maximális tokenmennyiséget jelenti, amelyet a modell egy adott futásban kezelni tud. Ebbe tipikusan az input és a generált output is beleszámít a szolgáltató/model implementációjától függő módon.

A fontos gyakorlati szemlélet:

max context
- system instructions
- conversation
- retrieved data
- tool results
- reserved output
= felhasználható context budget

Ha a modell nagy context window-val rendelkezik, az nem jelenti azt, hogy mindig érdemes telepakolni.

Több context nem automatikusan jobb¶

Ez az egyik legfontosabb pont.

Tegyük fel, hogy egy kérdéshez három dokumentum releváns, de mi beadunk 400 fájlt.

3 releváns dokumentum
+ 397 irreleváns dokumentum

Technikailag lehet, hogy belefér a contextbe, de:

drágább;
lassabb lehet;
a fontos információ elvész a zajban;
nő az ellentmondó vagy elavult információ esélye;
nehezebb a modellnek eldönteni, mire fókuszáljon.

Ezért a helyes kérdés nem az, hogy:

Mennyi context fér bele?

hanem:

Mi az a minimális és releváns context, amelyből a feladat jól megoldható?

Context pollution¶

Context pollutionről beszélhetünk, amikor a modell olyan információt kap, amely nem segíti, vagy egyenesen rontja az aktuális döntést.

Példa egy coding agentnél:

Feladat: módosítsd a payment retry logikát

Hasznos context:

retry service;
hozzá tartozó interface;
releváns tesztek;
coding rules.

Kevésbé hasznos:

teljes frontend;
öt éve nem használt migrationök;
unrelated README-k;
minden repository file csak azért, mert belefér.

Lost in the middle¶

Hosszú contextnél előfordulhat, hogy a modell nem egyformán jól használja a context minden részét. Gyakorlati szempontból ezért nem jó stratégia pusztán hatalmas dokumentumhalmazt átadni és remélni, hogy a modell mindig megtalálja a kritikus mondatot.

Jobb stratégia:

retrieve relevant chunks
        ↓
rank / filter
        ↓
compact context
        ↓
LLM

Ez lesz később a RAG és context engineering egyik alapja.

Context budget gondolkodás¶

Érdemes a contextet erőforrásként kezelni, hasonlóan a CPU-hoz vagy memóriához.

Példa:

Total budget: 100%

15% system/application instructions
20% recent conversation
45% retrieved knowledge
5% tool results
15% reserved output

Ez nem konkrét ajánlott arány, csak azt mutatja, hogy a contextet tudatosan lehet felosztani.

Conversation history: mindent vigyünk tovább?¶

Nem feltétlenül.

Egy hosszú beszélgetésnél három tipikus stratégia:

1. Teljes history¶

Egyszerű, de idővel drága és zajos.

message 1
message 2
...
message 300
current question

2. Sliding window¶

Csak az utolsó N üzenetet visszük tovább.

last 10 messages
+ current question

Előnye az egyszerűség, hátránya, hogy régi fontos döntés kieshet.

3. Summary + relevant memory¶

conversation summary
+ relevant durable facts
+ recent messages
+ current question

Ez általában skálázhatóbb megközelítés.

Példa: knowledge base mint context source¶

A saját repository rendszerünknél nem szeretnénk minden új sessionben az egész repót beadni.

Jobb flow:

START_HERE.md
      ↓
knowledge/status.md
      ↓
AI status
      ↓
relevant foundation topic
      ↓
LLM

Itt maga a struktúra segít a context kiválasztásában.

Példa: RAG kérdés¶

User:

„Mi a refund policy enterprise ügyfeleknek?”

Rossz:

összes cégdokumentum → LLM

Jobb:

query
  ↓
retrieval
  ↓
enterprise refund policy releváns részei
  ↓
LLM

Az LLM így kisebb, tisztább és frissebb contextből dolgozik.

Input és output együtt számít¶

Ha a modellnek hosszú választ kell generálnia, annak is helyet kell hagyni.