01 – LLM Mental Model¶
Az első fontos cél nem az, hogy matematikailag részletesen értsük a transformer architektúrát, hanem hogy helyes mentális modellünk legyen arról, mit csinál egy LLM, és mit nem. Ez azért kritikus, mert rossz mentális modellből rossz rendszerarchitektúra születik.
Mit csinál egy LLM futás közben?¶
Nagyon leegyszerűsítve az LLM a kapott context alapján a következő token valószínűségét becsüli, majd ebből lépésről lépésre felépíti a választ.
input/context
↓
modell
↓
következő token valószínűségek
↓
kiválasztott token
↓
új context
↓
következő token...
Ez nem azt jelenti, hogy az LLM csak „autocomplete”. A modern modellek a training során nagyon összetett nyelvi, logikai, programozási és problémamegoldási mintákat tanulnak meg. A fontos különbség az, hogy futás közben nem egy klasszikus programot hajtanak végre, és nem egy adatbázisból olvassák ki a választ.
Training knowledge és runtime context¶
Két dolgot érdemes szétválasztani.
Training knowledge: azok a minták és összefüggések, amelyeket a modell a tanítás során a paramétereibe tanult.
Runtime context: az az információ, amelyet az adott kérésnél ténylegesen megkap: system instruction, user message, korábbi üzenetek, dokumentumok, tool resultok stb.
Példa:
Training során:
- a modell megtanulhatta, hogyan néz ki egy Kubernetes Deployment
- ismeri a YAML általános szerkezetét
Runtime:
- viszont a te aktuális deploymented replicas=7 értékét
csak akkor tudja, ha ezt most megkapja contextként vagy toolból
Ezért veszélyes az a gondolat, hogy „a modell biztos tudja”. Lehet, hogy ismeri a témát, de nem feltétlenül ismeri az aktuális állapotot.
Az LLM alapvetően stateless¶
Egy API-hívás önmagában nem emlékszik az előző hívásra. Ha folyamatos beszélgetést akarunk, az alkalmazásnak kell visszaadnia a szükséges előzményeket.
request #1
User: A projekt neve Atlas.
request #2
User: Mi a projekt neve?
Ha a második kérésben az első üzenet nincs benne a contextben, a modell számára az információ nem létezik.
A „memory” tehát tipikusan nem egy mágikus LLM-feature, hanem alkalmazásoldali mechanizmus:
conversation / DB / files / memory store
↓
relevant information
↓
LLM
A saját knowledge base rendszerünk is ezért hasznos: új sessionben a repo adja vissza a tartós állapotot.
Miért hallucinálhat?¶
Az LLM elsődleges feladata koherens és valószínű folytatás generálása, nem pedig egy belső adatbázisban lévő tény rekordjának garantált visszaadása.
Ha hiányos a context, a modell képes valószerű választ generálni akkor is, amikor nincs biztos információja.
Példa:
Kérdés:
„Milyen timeoutot állítottunk be tegnap a payment service-ben?”
Ha ez nincs a contextben, a modellnek három tipikus lehetősége van:
- jelzi, hogy nem tudja;
- következtet valamilyen általános mintából;
- rossz esetben magabiztosan kitalál egy értéket.
A production rendszernek ezért nem arra kell épülnie, hogy „a modell majd biztos nem talál ki semmit”. Inkább olyan architektúrát kell készíteni, ahol az igazság forrása elérhető:
LLM → tool → configuration service → valódi timeout
Reasoning nem ugyanaz, mint determinisztikus algoritmus¶
Az LLM nagyon jó lehet összetett problémák elemzésében, de ettől az eredmény még nem lesz ugyanúgy garantált, mint egy determinisztikus függvény esetén.
Példa:
calculate_tax(invoice)
Ha az adószabály egyértelmű programlogikával leírható, akkor ezt nem érdemes minden alkalommal az LLM-re bízni.
Jobb felosztás:
LLM:
- értelmezze a természetes nyelvű kérést
- válassza ki, melyik művelet kell
Application code:
- számolja ki az adót
- validálja az adatokat
- hajtsa végre a tranzakciót
Általános szabály:
Ami determinisztikusan kiszámolható vagy ellenőrizhető, azt lehetőleg a szoftver garantálja, ne a prompt.
Model capability vs application capability¶
A modell képessége és az alkalmazás képessége két külön dolog.
Egy LLM önmagában például nem feltétlenül tudja:
- mi van a mai adatbázisodban;
- milyen issue nyílt öt perce GitHubon;
- jogosult-e a user törölni egy rekordot;
- ténylegesen elküldeni egy e-mailt;
- garantálni egy üzleti szabály betartását.
Az alkalmazás ezeket toolokkal és környező komponensekkel adja hozzá.
AI application
|
+----------------+----------------+
| | |
LLM Tools deterministic code
| | |
reasoning/text external world rules/validation
Ez az egyik legfontosabb AI engineering szemlélet: nem „LLM-et építünk”, hanem rendszert építünk egy LLM köré.
Példa: support assistant¶
Tegyük fel, hogy egy support assistant válaszol arra, hogy:
„Miért utasították el a tegnapi számlámat?”
Rossz megoldás:
User question → LLM → válasz
A modell ilyenkor csak általános okokat tud felsorolni, és könnyen találgatásba csúszik.
Jobb megoldás:
User question
↓
LLM felismeri: invoice lookup kell
↓
get_invoice(user_id, date)
↓
valódi invoice status + reason code
↓
LLM emberi nyelven elmagyarázza
Itt a tényt az alkalmazás/tool szolgáltatja, az LLM pedig értelmez és kommunikál.
Példa: coding assistant¶
A modell általánosságban tudja, mi a repository pattern vagy a dependency injection. De azt, hogy a konkrét repóban milyen konvenció van, csak akkor tudja megbízhatóan követni, ha látja a releváns fájlokat és szabályokat.
General model knowledge
+
AGENTS.md / project rules
+
relevant source files
+
current task
↓
jobb módosítás
Ez már átvezet a későbbi context engineering témához.
Mire használd az LLM-et?¶
Tipikusan erős olyan problémákban, ahol:
- természetes nyelvet kell értelmezni vagy generálni;
- nem teljesen strukturált inputból kell jelentést kinyerni;
- összetett kontextust kell összefoglalni;
- több lehetséges megoldást kell mérlegelni;
- szemantikai hasonlóság, kategorizálás vagy extraction kell;
- emberi jellegű kommunikáció szükséges.
Kevésbé jó hely önmagában olyan feladatra, ahol:
- 100%-os matematikai pontosság kell;
- szigorú authorization döntés történik;
- pénzügyi tranzakciót kell garantáltan helyesen végrehajtani;
- pontos aktuális állapot kell külső rendszerből;
- determinisztikus szabály könnyen implementálható kódban.
Mit érdemes ebből megjegyezni?¶
- Az LLM probabilisztikus komponens, nem klasszikus adatbázis vagy függvény.
- A training knowledge és az aktuális context nem ugyanaz.
- A tartós memória jellemzően alkalmazásoldali feladat.
- Hallucination ellen nem csak jobb prompttal, hanem jobb architektúrával védekezünk.
- A modell capability nem egyenlő az application capabilityvel.
- Az AI applicationben az LLM egy komponens a toolok, adatok és determinisztikus kód mellett.