Tokenmaxxing: hogyan mérjük az AI-val végzett fejlesztés eredményét?

Egy fejlesztő sok AI-tokent használhat egy nehéz rendszer feltérképezésére, és kevésből is készíthet hibás módosítást. A fogyasztás ezért önmagában nem alkalmas arra, hogy megmutassa, ki dolgozott jobban. A vezetőnek mégis szüksége van visszajelzésre: mire jutott a csapat az új eszközökkel, és hol növekedett az ellenőrzés terhe?

A „tokenmaxxing” kifejezést itt arra a szemléletre használjuk, amely a felhasznált tokenmennyiséget önálló sikerként kezeli. Ez a cikk az ösztönzőkről és a teljesítménymérésről szól. Nem állítja, hogy minden vállalat így rangsorol, és nem vezet le nemzetközi példákból magyar piaci arányokat.

Mit tudunk ténylegesen a rangsorokról?

Konkrét, nyilvánosan ellenőrizhető példa a TOKENMAXXING oldal, amely a 2026. július 30-ig tartó időablakról lezárt, anonim Hermes-tokenforgalmi rangsort közöl. Saját leírása szerint a sorrend a teljes tokenmennyiségen alapul, és külön jelzi a gyorsítótárhoz kapcsolódó forgalmat. Ez egy rangsor létezésének elsődleges bizonyítéka, nem a közzétett felhasználási adatok független auditja és nem vállalati teljesítményfelmérés. A dátumozott rangsor és módszertana.

A példa nem bizonyítja, hogy a résztvevők rosszul dolgoztak, vagy hogy a mért használat felesleges volt. Arra viszont alkalmas, hogy megmutassa: a tokenmennyiség önállóan is verseny tárgyává tehető. Az ebből fakadó munkahelyi kockázatok az alábbiakban szerkesztői következtetések, nem a rangsor résztvevőiről tett állítások.

A mérési probléma régebbi az AI-eszközöknél. A 2021 februárjában megjelent SPACE kutatási keret több dimenzióban vizsgálja a fejlesztői produktivitást, és óv az egyetlen aktivitási mutatóra épülő értékeléstől. Ez elvi támpontot ad, de nem bizonyítja egy konkrét AI-eszköz megtérülését. A SPACE tanulmány a Microsoft Research oldalán.

Hogyan lesz a mérésből rossz ösztönző?

Ha a vállalkozás jutalmazza a magas fogyasztást, érdemes lehet több futást indítani akkor is, amikor a feladat már megoldódott. Ha csak az alacsony fogyasztást jutalmazza, az ellenőrzés és a tanulás kerülhet hátrányba. Mindkét irány eltérítheti a munkát a tényleges céltól.

Ez lehetséges következmény, nem minden csapat szükségszerű viselkedése. A szabályok számítanak: az elkészült javaslatok számát korlátozhatjuk, a bonyolult feladatot felbonthatjuk, és megállíthatjuk az új munkát, amíg nincs ellenőrzési kapacitás. A több generált kód nem kényszeríti ki a minőségi ellenőrzés gyengítését.

A tanulási célú használatot külön érdemes kezelni. Egy új eszköz kipróbálásának eredménye lehet az is, hogy adott feladatra nem megfelelő. Ha ezt kudarcként büntetjük, a csapatnak érdeke lehet elhallgatni a negatív tapasztalatot. A kísérlet lezárható hasznos felismeréssel akkor is, ha nem kerül belőle kód az éles rendszerbe.

Minden mutató mellé kell ellenőrző szempont

Az alábbi táblázat javasolt értékelési keret. Csapatszintű folyamatjavítást szolgál, nem egyéni rangsort. Az ellenmutató sem teszi kijátszhatatlanná a rendszert, de segít észrevenni, ha a látszólagos javulás máshol többletterhet okozott.

Mutató	Mit mutat?	Hogyan torzulhat?	Mit nézzünk mellette?
Tokenmennyiség	Feldolgozási aktivitás	Felesleges ismétlések, túlméretezett bemenet	Elfogadott feladat és teljes ráfordítás
Token / PR	Fogyasztás egy módosítási kérelemre	A munka mesterséges felaprózása	Feladatméret, összevont üzleti eredmény
Lezárt hibajegyek	Adminisztratív előrehaladás	Könnyű ügyek kiválogatása, korai lezárás	Újranyitás, nehézség, felhasználói visszajelzés
Tesztlefedettség	Tesztekkel elért kódrész	Érdemi ellenőrzés nélküli tesztek	Hibás működést felismerő konkrét próba
Átfutási idő	Feladatkezdéstől elfogadásig eltelt idő	Várakozás vagy utómunka kihagyása	Ellenőrzési idő, javítás, teljes sorban állás
Éles hibaarány	Kiadás utáni minőségi jel	Rövid megfigyelés, hibák átnevezése	Azonos időablak, súlyosság, használati terhelés

A tokenadatok összesítésénél a modell és az elszámolási kategória is számít. A bemenet, a kimenet és a gyorsítótárból újra felhasznált tartalom összevonása különböző munkákat moshat össze. Itt nem ártáblát készítünk: az a cél, hogy azonos definícióval hasonlítsuk össze a mért időszakokat.

Szemléltető mérés egy kis csapatnál

A következő példa minden száma feltételezett. Egy négyfős csapat rendelésfeldolgozó rendszerben végez kisebb módosításokat. Az alapidőszak négy hét, majd négyhetes AI-próba következik. Mindkét időszakban 20 feladatot vizsgálnak, azonos előzetes besorolással: 12 kisebb és 8 közepes összetettségű munka.

A besorolás alapja a módosított üzleti szabályok, az érintett rendszerek és a szükséges tesztkörnyezet. A képernyő színének cseréjét nem hasonlítják készletfoglalási hibajavításhoz. A feladatokat még az eszköz használata előtt sorolják be, és utólag indoklással jelzik, ha a kezdeti becslés téves volt.

Feltételezett eredmény	Alapidőszak	AI-próba
Vizsgált feladat	20	20
Megvalósítási munka összesen	100 óra	70 óra
Ellenőrzési munka összesen	20 óra	35 óra
Utólagos javítás összesen	8 óra	15 óra
Teljes ráfordítás	128 óra	120 óra
Éles hibával érintett feladat, azonos 14 napos követéssel	2 / 20	3 / 20

A megvalósítás 30 órával rövidült, de a teljes munkaráfordítás csak 8 órával csökkent. Ez 8 / 128, azaz 6,25% különbség. A hibával érintett feladatok aránya a példában 10%-ról 15%-ra változott, de ilyen kis mintából nem indokolt tartós javulást vagy romlást kijelenteni. A hibák súlyosságát külön kell megvizsgálni.

Az üzleti eredményt is mérjük: a példában legyen a cél a rendelésenként szükséges kézi korrekció csökkentése. Ha az alapidőszak 100 összehasonlítható rendeléséből 18, a próba 100 rendeléséből 12 igényel korrekciót, az kedvező megfigyelés. Nem bizonyítja önmagában az AI hatását: változhatott a rendelésösszetétel, a munkatársak tapasztalata vagy maga a követelmény.

Mi hiányzik egy egyszerű előtte–utána mérésből?

A csapat a második időszakban már jobban ismerheti a rendszert. Az AI-val könnyen kezelhető feladatokat tudatosan vagy akaratlanul előnyben részesítheti. A betegszabadság, a sürgős ügyfélkérés és egy nehéz adatbázis-hiba önmagában is megváltoztathatja az átlagot.

Ezért a vezető ne csak a táblázat végösszegét kérje. Nézze meg a feladatok eloszlását, a kimaradt eseteket és az eltérések magyarázatát. Ha megoldható, hasonló feladatoknál váltakozó vagy előre kijelölt eszközhasználattal végezzen újabb próbát. A cél a bizonytalanság csökkentése, nem egy előre eldöntött beruházás igazolása.

A siker feltétele legyen előre rögzítve: például csökkenő teljes ráfordítás, változatlan elfogadási feltételek és elfogadható hibakép. A súlyos biztonsági vagy adatkezelési hiba külön megállítási ok lehet akkor is, ha az átlagos idő javul. A döntési határt a vállalkozás kockázata szabja meg, nem egy általános iparági százalék.

A mérés ne hozzon létre új adatvédelmi problémát

A használati naplóban elegendő lehet a feladat azonosítója, az eszköz, a modell, a fogyasztási kategória és az időtartam. Teljes ügyféladatot vagy üzleti titkot tartalmazó bemenetek gyűjtése ne legyen automatikus. A hibakereséshez szükséges részleteket szűk hozzáféréssel, meghatározott megőrzéssel kezeljük.

A szolgáltatói fogyasztási adat, a belső feladatnyilvántartás és az üzleti eredmény külön forrás. Összekapcsolásuknál dokumentáljuk, mi hiányzik, és ki módosíthatja az adatot. A csapatszintű összesítés sem anonim, ha egy kis csoportban könnyen visszafejthető belőle az egyén.

A hosszú távú cél egy olyan értékelési rend, amelyben a munkatárs biztonságosan jelezheti: ezt a feladatot AI nélkül oldotta meg gyorsabban, annál pedig az AI segített. A vezetés így a bevált munkamódszereket terjesztheti. Ehhez nincs szükség tokenbajnokra; ellenőrizhető feladatokra, összehasonlítható mérésre és a hibákról szóló őszinte visszajelzésre van szükség.