Az AI* robbanásszerű elterjedése és fejlődése hatalmas költekezési versenyt hozott magával,
a cégek egymást túllicitálva égetik el az erőforrásokat a versenyképesség javításának oltárán,
miközben majdnem 50%-uk nem látja viszont a kívánt eredményt. Ennek több oka is van –
pl.: nincs egyértelmű felelős a szervezetben, aki karbantartja az AI rendszert annak élesítése
után – de talán a legfontosabb hiányosság az, hogy nincs jól definiált cél kijelölve, a cél az AI
használata, nem egy probléma megoldása. Technikai oldalról nézve ez egy jó evaluation
(kiértékelő) rendszer hiányát jelenti.

Egy igazán jó evaluation rendszernek nagyon érzékeny egyensúlyt kell teremtenie, kellően jól
leképezve a jó felhasználói élmény mérését, de ugyanakkor Goodhart törvényét betartva, nem
lehet fő célként kitűzni egy metrika javítását sem. A rohamos fejlődés egyik mérőszáma a
különböző publikus benchmarkokon az egyes LLM-ek teljesítménye. A Llama 4
megjelenésekor jobban teljesített a benchmarkokon elődjeinél, de a fejlesztők közönsége
jobbnak találta az elődjeit. Hasonló fogadtatásban részesült 2025 augusztusában az OpenAI
GPT-5 megjelenése is, amit kezdetben a felhasználók egyértelműen elutasítottak. Ezek jó
példái annak, hogy egy – vagy akár több – mérőszám javulása a komplex AI rendszerek
esetében már nem jelent egyértelműen elégedettebb felhasználókat. Emellett ezen
benchmarkok esetében kérdéses, hogy a modellek legalább részben nem memóriából végzik-e
el a teszteket.

A felhasználói élmény szintjének fenntartásának és fejlesztésének záloga a jó evaluation
rendszer fejlesztése és karbantartása. Ez csak akkor sikerülhet, ha a szinte hetente érkező,
magukat világmegváltónak tartó módszerek és modellek alkalmazása helyett a fő célul a
konkrét probléma megoldását tűzzük ki, azaz a szekérhez keresünk lovat és nem a lóhoz
szekeret. Ennek a gyakorlati megvalósulása erősen use-case függő – egy rendszer esetében
lehet, hogy a sebesség és a pontosság a legfontosabb, míg egy másik rendszernél a
sebességnél fontosabb a hangvétel – azonban vannak olyan irányelvek, amik egységesen
megjelennek minden esetben. Az egyik ilyen a repeatability (ismételhetőség). Ha a fejlesztés
során egy rendszer képes volt egy feladatot egyszer jól megoldani, az kicsit ironikusan ugyan,
de pontosan csak ennyit jelent, azaz képes megoldani a feladatot. Mivel végső soron
valószínűségi modellek állnak az AI rendszerek mögött, így vakmerő lépés lenne egy sikeres
kísérlet után arra következtetni, hogy mindig képes lesz megoldani azt a problémát az AI, ezt
hivatott mérni a repeatability.

Emellett természetesen senki sem szeretné, ha feltörnék a rendszerét, így az ártó szándékkal
szembeni védekezésnek (pl.: prompt injekció) is meg kell jelennie az evaluation-ünkben.
Harmadik közös szempont: egy jó evaluation pipeline-nak része kell, hogy legyen a
felhasználóknál ténylegesen megjelenő hibák javítása. Valós használat során megjelenhetnek
olyan problémák, amikre a fejlesztői csapat nem is gondolhatott volna. Végül, de nem utolsó
sorban az evaluation teszteket érdemes a lehető legegyszerűbbnek hagyni. Ez az elv jól
tükrözi azt a valóságot, miszerint egy felhasználó vagy elégedett lesz, vagy nem, így hiába
lehet a fejlesztők számára nagyon vonzó egy bonyolultabb, több lépcsős skálán értékelni az AI teljesítményét, ez a „fától nem látjuk az erdőt” esete lenne. Végső soron az AI vagy átment a teszten, vagy megbukott.

Az AI által megnyitott világban érthető okokból mindenki szeretne a legjobb, leggyorsabb
technológiával felszerelve versenybe szállni, de célba csak azok érhetnek, akik a megfelelő
evaluation iránytűt is magukkal viszik.

*ezen cikkben a klasszikus gépi tanulástól kezdve a neurális hálókon át az LLM-ig és agent-
ekig mindent AI-nak hívunk a könnyebb olvashatóságért

Szerző:
Máth Benedek
Data scientist