Amikor az eval hazudik

Adott egy egyszerű kérdés: érdemes-e nagyobb modellre váltani a dokumentum-feldolgozó motorunkban? A jelenlegi produkciós modell a Qwen3.6-35B-A3B, 35 milliárd paraméteres MoE-architektúra (Mixture of Experts), amelyből tokenenként csak ~3 milliárd aktiválódik. A kihívó a Llama-3.3-70B-Instruct: klasszikus dense modell, kétszer akkora papíron, és minden egyes tokenhez a teljes súlykészletet mozgatja.

Fontos, hogy mit vártunk tőle, mert a mérés nem ott lett érdekes, ahol számítottunk rá.

Sebességben nem reméltünk semmit. Egy dense 70B ezen a hardveren lassabb lesz, mint egy 3B-aktív MoE; ehhez nem kell mérés, elég egy osztás (lentebb el is végzem). Ezt előre tudtuk, és el is fogadtuk volna: ha a pontosság érdemben jobb, egy lassabb, de megbízhatóbb modellre lehet architektúrát tervezni, batch-elve, éjszakai futtatással, kétlépcsős pipeline-nal.

Pontosságban viszont azt reméltük, hogy legalább hozza a Qwen szintjét. És bevallom, ebben a várakozásban volt egy ki nem mondott feltevés is: hogy egy amerikai nagylabor zászlóshajó-modellje egy európai nyelven — magyar számlákon, magyar cégneveken, magyar adószám-formátumon — legalább annyira otthon lesz, mint egy kínai. A Llama tréningkorpusza jóval nyugatibb súlyozású; ha valahol, hát a magyar üzleti szövegen kellett volna behúznia.

Nem hozta. Harminc F1-ponttal maradt le.

Amerika kontra Kína, magyar terepen, és megint Kína nyert. Ez a cikk viszont nem erről szól. Erről a mondatról két bekezdés lesz a végén, mert egyetlen mérésből ilyen következtetést levonni pont az a hiba, ami ellen az egész írás szól. A cikk arról a két dologról szól, ami útközben derült ki: egy hibadetektorról, amely magabiztosan az ellenkezőjét állította a valóságnak, és egy szorzásról, amit előre el kellett volna végezni.

Az ügyfél- és partnernevek anonimizálva: „saját cég”, „A partner”, „B partner”, a dokumentumok sorszámozva. A modellnevek és a számok valósak.

Mit és hogyan mértünk

A feladat KIE (Key Information Extraction): magyar üzleti dokumentumokból strukturált JSON-t kell kinyerni: számlaszám, partnernév, adószám, bankszámlaszám, tételsorok, és néhány „kié ez a dokumentum” jellegű mező.

• Korpusz: 100 valós magyar dokumentum, 119 kiértékelési egységre bontva (100 fejléc + 19 tételsor-blokk)
• Modellek: Qwen3.6-35B-A3B FP8 (a jelenlegi prod) vs Llama-3.3-70B-Instruct FP8 (nvidia/Llama-3.3-70B-Instruct-FP8, ModelOpt-kvantálás)
• Metrika: mező-szintű F1, verziózott normalizáló mögött (szóköz, kis/nagybetű, adószám-formátum stb. egységesítve)
• Szignifikancia: McNemar-teszt, dokumentum-szinten párosítva — ugyanaz a dokumentum ugyanazzal a promptal ment be mindkét modellbe, tehát a párosított teszt a helyes eszköz
• Hardver: GB10-alapú fejlesztői gép, 121 GB egyesített memória, vLLM 0.25.1
• Kvantálás: mindkét oldalon FP8, tehát azonos bit-osztály

Egy fontos részlet a splitekről. A Qwen multimodális: kap egy 200 DPI-s oldalképet is a szöveg mellé. A Llama nem. Emiatt a teljes korpuszon mért szám nem tiszta modell-összehasonlítás, a Qwen többletinputot kapott. A döntéshez ezért csak azt az 52 egységet vettük irányadónak, ahol mindkét modell pontosan ugyanazt kapta: csak szöveget.

Ez a fajta önkorlátozás nem szerénykedés. Ha a saját mérésedben nem különíted el, hol kaptak a modellek eltérő inputot, akkor nem modellt hasonlítasz össze, hanem pipeline-t, és utána azon fogsz csodálkozni, hogy a „nyertes” modell egy másik környezetben nem hozza, amit ígért.

Az eredmény

¹ Ezekben a sorokban a Qwen többletinputot (oldalképet) kapott, lásd fent.

Harminc F1-pont. Ez nem árnyalatnyi különbség, és nem is a mérés zaja: a párosított teszten p=0,0043.

Két dolgot érdemes kiemelni, mert mindkettő ellentmond a szokásos várakozásnak:

A formátumot a Llama hibátlanul tartotta. JSON-validitás: 119-ből 119, mindkét modellnél. Nulla érvénytelen kimenet. A „nagy modell, de nem tudja tartani a sémát” félelem itt egyszerűen nem igazolódott, a hiba tartalmi, nem szintaktikai. A Llama pontosan azt a JSON-t adta vissza, amit kértünk; csak rossz értékekkel töltötte ki.

A hiba nem kihagyás, hanem tévedés. A Llama mező-szintű kimeneteinek megoszlása: 746 találat, 108 rossz érték, 43 kihagyás, 26 fölösleges kitöltés. A domináns hibatípus a mismatch: a modell magabiztosan beír valamit, ami nem az. Ez üzemeltetési szempontból lényegesen rosszabb, mint a kihagyás, egy üres mezőt az ellenőrző rendszer kiszúr, egy hihető, de hibás adószámot nem.

És hol hibázik? Ha mezőnként bontjuk, a kép nagyon nem egyenletes:

A hibák súlypontja pontosan a partner-azonosítás és a dokumentum-tulajdonlás kérdése. Iktatásban ez a két legdrágább mezőcsoport: erre épül a partner-párosítás és az, hogy egy számla bejövő vagy kimenő oldalra kerül-e. Egy 0,90-es átlagos F1 megnyugtató lehet, amíg meg nem nézed, hogy a hiányzó 10% nem egyenletesen oszlik el, hanem pont azokra a mezőkre koncentrálódik, amelyekre a downstream logika épül.

A csapda: a hibadetektor, ami megfordult

Itt jön a cikk lényege.

Van egy kis segédszkriptünk, amit egy korábbi méréssorozathoz írtunk. A logikája egy mondat: ha a saját cégünk kerül a partner-mezőbe, az hiba, flageld meg. Egy korábbi, kvantálási összehasonlításban ez jó szolgálatot tett: a rosszabb kvantálású modellek hajlamosak voltak a fejlécen legfelül szereplő céget bemásolni a partner-slotba, és ez a szkript pontosan ezt kapta el.

Lefuttattuk erre a mérésre is. Az eredmény:

Qwen3.6-35B-A3B    doc=100   flagelt=7
Llama-3.3-70B      doc=100   flagelt=1     McNemar p = 0,070

Hét az egyhez. A Llama javára. A tendencia a szignifikancia határán.

Ez lett volna az egyetlen dimenzió az egész mérésben, ahol a Llama jobb. És pontosan illeszkedett volna a várakozásunkhoz: „na, valamiben azért mégis a nagyobb modell a megbízhatóbb.” Kézenfekvő lett volna beírni a jelentésbe egy „a Llama a tulajdonlás-eldöntésben viszont pontosabb” mondatot, és tovább lépni.

Ehelyett megnéztük a hét dokumentumot a ground truth ellen. És ez derült ki:

A hét flagelt dokumentumból hatban a helyes válasz tényleg a saját cég volt. Szállítói oldali dokumentumok: olyan számlák, ahol a mi cégünk a vevő, tehát a dokumentum kibocsátója szempontjából mi vagyunk a partner. A Qwen ezeket mind eltalálta, és a detektor pont ezért flagelte meg.

Megfordítva a számokat: valódi tulajdonlás-hiba a Qwennél 1, a Llamánál 6. A detektor nyers kimenete („1 vs 7”) ennek szó szerint a fordítottját sugallta.

Miért fordult meg?

Nem a szkript volt hibás. A szkriptbe épített előfeltevés vándorolt el a korpusz alól.

A detektor implicit feltételezése ez volt: „ebben a korpuszban a saját cég sosem legitim partner.” Azon a korábbi korpuszon ez igaz volt. Kizárólag kimenő számlák voltak benne. Az új korpuszban viszont vegyesen szerepelnek bejövő és kimenő dokumentumok, és ott ez az állítás egyszerűen nem igaz. Ugyanaz a kód, ugyanaz a logika, ellentétes jelentés.

És ez a rossz fajta hiba: nem robban el. Nem dob kivételt, nem ad üres kimenetet, nem lóg ki a tartományból. Lefut, ad egy értelmesnek látszó számot, aminek a jele fordított. Egy elszállt szkriptet öt perc alatt észreveszel. Egy csendben megfordult metrikát csak akkor, ha kézzel visszanézed a ground truth-t, vagyis pont azt a munkát végzed el, amit a metrikával akartál megspórolni.

Amit ebből elvittünk

A proxy-metrikáknak lejárati idejük van, és nem magukat kell verziózni, hanem az előfeltevésüket. Egy heurisztikus hibadetektor nem a hibát méri, hanem a hiba egy korpuszfüggő lenyomatát. Amikor a korpusz változik, a lenyomat érvényessége is változik, csendben.

Nálunk ez három konkrét szabállyá vált:

1. Minden heurisztikus detektor mellé leírjuk egy mondatban a feltevését — ott, a fájl tetején, nem a fejünkben. Ha nem tudod egy mondatban leírni, nem tudod, mit mér.
2. Ez a szkript ezentúl csak ground-truth-verifikációval együtt fut. A nyers flag-szám önmagában nem kerül jelentésbe.
3. Ha egy mérésben pontosan egy dimenzió mond mást, mint az összes többi, az nem érdekes kivétel, hanem gyanús. Először a metrikát ellenőrizzük, csak utána írjuk le következtetésnek.

Ez a harmadik a legfontosabb, és a legnehezebb betartani, mert az az egy kilógó szám mindig izgalmasabbnak tűnik, mint a húsz egyirányba mutató. Különösen akkor, ha épp egybeesik azzal, amit reméltünk.

A második tanulság: a szorzás, amit előre el kellett volna végezni

A sebesség-különbség brutális:

Huszonhatszoros lassulás. Ezt vártuk is, de nem ez a lényeg. A lényeg, hogy ezt előre ki lehetett volna számolni, egy osztással, és akkor a mérés első napján tudjuk, hogy a pontosságnak nemcsak hoznia kellene a Qwent, hanem érdemben felül kellene múlnia ahhoz, hogy egyáltalán tárgyalóképes legyen.

A GB10 memória-sávszélessége 273 GB/s. Egy dense modellnél minden egyes generált tokenhez a teljes súlykészletet át kell olvasni a memóriából. 70 GB súly, 273 GB/s:

273 GB/s ÷ 70 GB = 3,9 token/s

Ez az elméleti felső korlát. Nem a mért érték, hanem az a szám, amit a fizika enged. Mértünk 2,5-öt, vagyis a valóság a plafon 64%-án van, ami egy dense modellnél teljesen normális.

Ebből következik a legfontosabb mondat az egész mérésben: ez nem hangolási kérdés. Nincs az a batch-méret, kvantálás vagy kernel-optimalizáció, ami ezt 3,9 fölé viszi ugyanezen a gépen. A hangolással a 2,5-ből lehet 3,2, a 8,2 másodperces dokumentum-latenciából nem.

A Qwen ugyanezt a képletet a másik oldaláról nézve nyeri meg: MoE-nál tokenenként csak a kiválasztott szakértők súlyait kell beolvasni, tehát a ~35 GB-ból csak töredék mozog. Innen a nagyságrendi különbség, nem a modell „okosabb”, hanem kevesebb bájtot olvas.

Számold ki a sajátodra

Két adat kell hozzá, mindkettő megvan öt perc alatt:

felső korlát (token/s) ≈ memória-sávszélesség (GB/s) ÷ aktív súlyméret (GB)

Ahol az aktív súlyméret dense modellnél a teljes checkpoint mérete, MoE-nál nagyjából az aktív paraméterek aránya szerinti hányad (plusz a mindig aktív rétegek). Ha az így kapott szám kisebb, mint amit a use-case megkövetel, akkor a modell nem alkalmas arra a hardverre, függetlenül attól, milyen jók a benchmark-pontszámai.

Ez a számítás átfogalmazza a szokásos kérdést. Nem az, hogy „elfér-e a memóriában” — elfért, betöltődött, működött. Hanem az, hogy „hányszor tudom végigolvasni másodpercenként”.

Aki on-prem szeretné futtatni a saját dokumentumfeldolgozását, annak ez a képlet többet ér, mint bármelyik ranglista: megmondja, hogy a kiszemelt modell a te dobozodban egyáltalán játékban van-e, mielőtt bármit letöltenél.

Amit ez a mérés nem bizonyít

Ha egy összehasonlításnak nincs korlátozás-fejezete, akkor nem mérés, hanem marketing. Az itteni négy:

1. FP8-at mértünk, nem BF16-ot. A meta-llama/Llama-3.3-70B-Instruct BF16 változata (~141 GB) nem fér a 121 GB-os gépbe, ezért az nvidia/Llama-3.3-70B-Instruct-FP8 checkpointot mértük. A prod Qwen szintén FP8, tehát az összevetés bit-osztályon belül fair — de egy BF16 Llama valamivel jobb lehet.
2. A prompt a Qwenre van hangolva. A prompt-készletet hónapokon át a jelenlegi prod modellel iteráltuk. Ez rendszerszintű előny a Qwennek. Egy Llamára hangolt prompt szűkítené a rést — a 30 pontot aligha tüntetné el, de ezt nem mértük, tehát nem is állítom.
3. A legtisztább split kicsi. A fejléc-only mintán n=33, ott a p=0,118 — nem szignifikáns. A tágabb, 52 elemű fej-fej minta már igen (p=0,0043), és az irány minden bontásban azonos, de a legszigorúbb olvasat szerint a legtisztább szeleten csak tendencia van.
4. Egyetlen feladatot mértünk. KIE magyar üzleti dokumentumokon. Ez nekünk a fő produkciós metrika; másnak nem az. Ebből semmit nem állítok a Llama-3.3-70B általános képességeiről — chat, kódolás, tool-calling, hosszú kontextus mind mérhetetlen maradt.

Ráadás: az üzemeltetési tanulság

Az első Llama-indítási kísérlet megbénította a gépet, az SSH-kapcsolat elveszett, kézi újraindítás kellett. A kézenfekvő magyarázat az lett volna, hogy kifogyott a memória: a kernel négyszer dobott NVRM: Out of memory-t.

Nem az volt. A modell szépen betöltődött. Utána a FlashInfer autotuner ragadt be: az első hangolási kör 48 percig futott, egyetlen profil 865 másodpercig, majd nekiállt egy második körnek több mint kétórás becsléssel. A tünet valóban memóriahiba volt, de az ok egy háttérben futó optimalizáló, amit senki nem kért.

A javítás egyetlen kapcsoló: enable_flashinfer_autotune: false. Mellékhaszonként a runai_streamer betöltési formátum a modell indulását 490 másodpercről 16-ra vitte.

A tanulság ugyanaz, mint a guardnál, csak más ruhában: a tünet és az ok között nincs megbízható leképezés. Ha az „out of memory” üzenetnél megállunk, ma is azt hinnénk, hogy a modell nem fér a gépbe, és egy hibás következtetés alapján zárnánk ki egy egyébként jól betöltődő checkpointot.

És akkor Amerika kontra Kína?

Vissza a bevezető ki nem mondott feltevéséhez. Azt vártuk, hogy a Llama a magyar üzleti szövegen legalább hozza a Qwent, nyugatibb tréningkorpusz, kétszer annyi paraméter, egy amerikai nagylabor zászlóshajója. Nem hozta, és nem is szorosan maradt le.

Csak azt engedjük meg magunknak, amit az adat elbír. Ez egy feladat, egy nyelv, egy korpusz, FP8-ban, a Qwenre hangolt promptal. Ebből „a kínai modellek jobbak” következtetést levonni pontosan az a hiba lenne, ami ellen az egész detektor-fejezet szól: egyetlen szám kiemelése, mert illik egy narratívába.

Amit viszont nyugodtan kimondok: aki magyar dokumentumfeldolgozásban ma nyílt súlyú modellt választ, annak semmilyen alapja nincs arra, hogy a származási ország alapján szűkítsen. A „majd egy nagy amerikai modell úgyis jobb lesz az európai nyelveken” intuíció ezen a korpuszon nemhogy nem igazolódott, az ellenkezője mérhető, szignifikánsan. Mindkettő nyílt súlyú, mindkettő letölthető, mindkettő futtatható a saját vasadon, és ez az egyetlen dolog, ami a magyar adatvédelmi valóságban igazán számít.

A tanulság tehát nem geopolitikai, hanem módszertani: mérd le a saját korpuszodon. Ez ugyanaz a mondat, mint a cikk többi tanulsága, csak nagyobb léptékben, ne a ranglistát hidd el, és ne is az intuíciódat.

Összefoglalva

A modellcsere-döntés maga unalmas: nem váltunk. A Llama-3.3-70B harminc F1-ponttal gyengébb a fej-fej összevetésben, a hibái pont a legdrágább mezőcsoportokra koncentrálódnak, és huszonhatszor lassabb ezen a hardveren. A három dolog, ami viszont túléli ezt a konkrét modellpárost:

1. A heurisztikus metrikáid egy korpuszra vannak kalibrálva, akkor is, ha ezt sehol nem írtad le. Amikor a korpusz megváltozik, a metrika nem robban el — csendben mást kezd jelenteni. Írd le a feltevését egy mondatban, a kód mellé.
2. Ha egy dimenzió az összes többivel ellentétesen mutat, először a metrikát gyanúsítsd, ne a modellt. Nálunk ez a szabály mentett meg egy hibás mondattól egy jelentésben — pont abban a dimenzióban, ahol a hibás mondatot amúgy is szívesen leírtuk volna.
3. A sávszélesség-plafont ki lehet számolni, mielőtt bármit letöltesz. Sávszélesség osztva az aktív súlymérettel. Ha a kapott szám nem elég, a modell nincs játékban azon a gépen — és ezen semmilyen hangolás nem segít.

Az utolsó pedig inkább hozzáállás, mint tanulság: a mérés akkor ér valamit, ha készen állsz arra, hogy magát a mérőeszközt is megmérd, és arra, hogy az eredmény ne azt mondja, amit vártál. Ez a cikk lényegében arról szól, hogy egyszer majdnem elmulasztottuk mindkettőt.

---

A mérés 100 valós magyar üzleti dokumentumon készült, 119 kiértékelési egységre bontva, GB10-alapú fejlesztői gépen (121 GB egyesített memória, vLLM 0.25.1). Mindkét modell FP8-ban futott, azonos promptal; a szignifikanciát dokumentum-szinten párosított McNemar-teszttel számoltuk. A döntéshez csak azt az 52 egységet vettük irányadónak, ahol mindkét modell azonos inputot kapott. A multimodális és a teljes korpuszra vonatkozó sorokban a Qwen 200 DPI-s oldalképet is kapott, ezért azok nem tiszta modell-összehasonlítások. Az ügyfél- és partnernevek anonimizálva; a modellnevek és a számok valósak.