Negyven százalékkal gyorsabb, és mégsem váltunk

Volt egy működő produkciós modellünk: egy Qwen3.6-35B, block-FP8-ban, magyar számlák strukturált kinyerésére. Aztán megjelent ugyanez a modell NVFP4-ben, három különböző kvantálásban, két gyártótól. A mérés egyértelmű volt: +40% párhuzamos átbocsátás, +69% egyszálú kinyerés. Kisebb súlyfájl, gyorsabb dekódolás, ugyanaz a modell.

Nem váltottunk.

Ez a cikk arról szól, hogyan jutottunk el idáig, és arról, hogy a döntést végül nem az a metrika hozta meg, aminek a mérését elkezdtük.

Az első mérés hazudott

A természetes első kérdés: romlik-e a kinyerés pontossága? Erre van egy bejáratott mérésünk, egy 25 dokumentumos annotált korpusz, mezőszintű F1-el, az FP8 vs NVFP4 minőségmérés adatai nyilvánosak.

Az eredmény elsőre világosnak látszott:

Az FP8 javul, a kvantálás pontosságot veszít. Kész is lehetnénk.

Csakhogy a hibák egy részét megnézve kiderült, hogy nem hibák. A modell 1.0-t írt oda, ahol a ground truth 1-t; egy hosszabb forrásszövegben más helyre esett a sortörés; egy hiányzó numerikus mezőt null helyett 0.0-ként adott vissza. Formátumkülönbség, nem tartalmi tévedés.

Itt jön a kellemetlen rész. Először utólag hoztunk egy „tisztított F1” szabályt, miután már láttuk, melyik verzió nyer. Ez módszertani hiba, akkor is, ha jó szándékkal születik: ha a szabályt az eredmény ismeretében alakítod, addig fogod alakítgatni, amíg nem leszel elégedett az eredménnyel. Ezért az egészet újrakezdtük: megírtuk a normalizálót, verziószámmal rögzítettük, és csak utána pontoztunk újra, mind a négy checkpointra ugyanazzal a kóddal.

Az FP8 és az Unsloth-változat közti különbség: 0,0001. Döntetlen.

És figyeld meg, mi történt közben a másik két sorral: a normalizálás megcserélte a sorrendjüket. Amit nyersen 0,5 pont különbségnek láttunk, az javarészt formázási zaj volt, nem minőségbéli probléma.

Ez a mérés tehát nem azt mondta, amire elsőre gondoltunk volna. Nem azt mondta, hogy „az FP8 pontosabb”, hanem azt, hogy ezen a korpuszon nem tud dönteni.

A saját benchmarkunk sem mondott semmit

Van egy második mérésünk is: 16 forgatókönyves beszélgetés, ami az eszközhívásokat, a többlépcsős következtetést és a visszautasításokat vizsgálja: „mennyi a kintlévőségem”, „hasonlítsd össze a beszállítókat”, „mi a helyzet egy nem létező céggel”.

Ez semmit nem adott. A 16-ból 7 mind a négy modellnél elbukott, méghozzá egyazon ok miatt: a teszt-tenant adatai hiányosak, tehát a helyes válasz mindenhol „nincs adat”, amit az értékelő hibának vesz. Összesen 3 forgatókönyv differenciált egyáltalán, és azok közül kettőnél a két Unsloth-változat egymásnak is ellentmondott.

Ez zaj. Egy 16 elemű mintán 3 ingadozó eredményből nem lehet modellt választani, és aki mégis megteszi, az a saját tesztkészletének a szórását nevezi el minőségnek.

Két méréssel voltunk beljebb, és egyik sem tudott dönteni. Ekkor jött a végső megoldás.

A kapu, ami számított

A számlakinyerésünkben van egy döntés, ami minden más felett áll: melyik a saját cégünk, és melyik a partner a számlán. A dokumentumon mindkettő szerepel, névvel, adószámmal, címmel. Ha a modell felcseréli őket, akkor a könyvelésbe rossz irányú tétel kerül, és ezt a hibát a rendszer később nem tudja magától felfedezni.

Ezt nem a curated korpuszon mértük, hanem 100 valós céges dokumentumon. Nem szép, nem válogatott, nem annotált, olyan dokumentumok ezek, amelyek az éles rendszerben tényleg átmennek a pipeline-on. A módszertan és az aggregált eredmények külön megtalálhatók: a partner-azonosítási kapu mérése, McNemar-teszttel.

Mindhárom NVFP4-változat nagyjából megduplázza azt a hibát, ami a leginkább számít nekünk.

Ugyanaz a bemenet, temperature=0, ugyanaz a prompt. Az egyetlen különbség a súlyok kvantálása.

A hiba természete —itt lett érdekes a mérés!

Megnéztük, hogyan romlik el. Azt vártuk, hogy a névegyeztetés lesz bizonytalan: hasonló cégnevek, rövidítések, ékezetek.

Nem ez történt. Egyetlen részleges eset sem volt. Mind a 18 hibás dokumentumban a modell a saját cég teljes identitását másolta át a partner-mezőbe, nevet és adószámot, és közben mind a 18-nál a saját cég azonosítására szolgáló belső jelzőszám is nullára esett.

Vagyis nem arról van szó, hogy a modell bizonytalan a nevekben. Arról van szó, hogy tudja, hogy két cég szerepel a számlán, és rossz oldalra teszi őket. Ez szerep-hozzárendelési hiba, nem szövegegyeztetési.

Aminek van egy nagyon praktikus következménye: a hiba totális, tehát maradéktalanul detektálható. Írtunk rá egy háromsoros determinisztikus ellenőrzést, ha a partner adószámának számjegyei megegyeznek a sajátunkkal, vagy a partner neve tartalmazza a saját cégnevünket, akkor gyanús esetről beszélhetünk. Ez a szabály a 18 hibából 18-at megfogott. Nem 16-ot, nem 17-et. Mindet.

Van egy nyom is a mechanizmusra. A szabály két olyan dokumentumot is megjelölt, amit az adószám-alapú ellenőrzésünk nem tudott igazolni. Mindkettő külföldi partner volt, az egyiknél SWIFT-kód állt az adószám helyén, a másiknál semmi. A modell ezekben az esetekben is úgy döntött, hogy a saját cég a partnercég. Ez felveti, hogy a hiba akkor jön elő, amikor a partner adószáma nem a megszokott formátumú vagy hiányzik, de két dokumentum nem bizonyíték, csak hipotézis a következő körre.

Amit a statisztika enged, és amit nem

A 7 kontra 18 látványos, de a látványosság nem érv. Párosított teszt kell, mert ugyanazokat a dokumentumokat futtattuk mindegyik modellen.

McNemar-próba a produkciós FP8-hoz képest:

Az első kettő szignifikáns, a harmadik nem. És mivel három összehasonlítást végeztünk ugyanazzal a viszonyítási alappal, a többszörös tesztelésre korrigálva egyik sem éri el egyedileg az 5%-os küszöböt.

Aztán megnéztük a három NVFP4-változatot egymáshoz képest is:

A három NVFP4 egymástól ezen a mintán nem különböztethető meg. A 12–16–18 sorrend zaj.

Ez fontos, mert kivesz egy kézenfekvő narratívát. Volt egy hipotézisünk, hogy az agresszívabb kvantálás rontja jobban a következtetést, logikus, és a szakirodalom is ezt sugallja. A mérés viszont fordítva rangsorolt: a legkevésbé agresszív változat hibázott a legtöbbet, a legagresszívabb a legkevesebbet. Csakhogy ez a fordított sorrend nem szignifikáns.

Amit tehát állíthatunk: mindhárom NVFP4 nagyjából megduplázza ezt a hibát az FP8-hoz képest (12–18 kontra 7), és a három közti különbség ezen a mintán nem eldönthető. s

A döntés

Marad az FP8.

Nem azért, mert az NVFP4 rossz. A +40% valós, a mérés tiszta, ugyanazon a gépen, ugyanazon a motoron, mindkettő a saját legjobb backendjével.

Hanem ezért:

Száz minta kevés ahhoz, hogy megértsük a hibát. Tudjuk, hogy van; tudjuk, hogy totális; tudjuk, hogy detektálható; van egy hipotézisünk a kiváltó okára. Amit nem tudunk: mekkora és valójában milyen dokumentumtípusokon jön elő, és van-e olyan NVFP4-változat, amelyik érdemben jobb a többinél. Amíg a három jelölt statisztikailag megkülönböztethetetlen, nem tudunk közülük választani sem, nem arról van szó, hogy melyiket vegyük, hanem hogy az adat nem enged választani.

És mert a pontosság fontosabb, mint a sebesség, ezen a terhelésen. A pipeline nem átbocsátás-korlátos. Az a +40% nem old meg egyetlen létező problémát sem: nem várunk sorban, nem hagyunk ki határidőt, nem fizetünk akkor sem, ha többi időbe telik. Cserébe egy olyan hibaosztályt kapnánk, aminek a méretét nem ismerjük. Ez rossz üzlet, függetlenül attól, mennyire szép a szám.

Ha valaha átbocsátás-korlátossá válunk, ez a döntés újranyílik, a mérés megvan hozzá, és a determinisztikus ellenőrzés is.

Amit ebből tanultunk

A metrika, ami dönt, ritkán az, ami a model cardon van. Mindkét gyártó publikált benchmarkokat: MMLU-Pro, GPQA, AIME. Az egyik változat 85,85, a másik 85,58, hivatkozható, összehasonlítható, és a mi döntésünk szempontjából teljesen érdektelen. A mi számunkat egyik sem mérte, és nem is mérhette: ez a fajta mérés a mi dokumentumainkon, a mi sémánkkal, a mi üzleti szabályunkkal létezik csupán, és számunkra releváns.

A saját benchmarkod is lehet vak. Nekünk két bejáratott mérésünk volt, és egyik sem tudott dönteni. A döntést egy olyan mérés hozta meg, amit kifejezetten azért építettünk, mert tudtuk, melyik hiba fáj a legjobban az üzletnek. Ha nem lett volna meg ez a kapu, ma NVFP4-en futnánk, és valószínűleg hetekig nem vettük volna észre, miért nőtt a manuális javítások száma.

Rögzítsd a szabályt, mielőtt megnézed az eredményt. Az utólagos „tisztított F1” jó szándékú volt, de mégis érvénytelen. Az előre rögzített normalizálóval ugyanaz az adat döntetlent adott ott, ahol előtte győzelmet láttunk.

A totális hiba jó hír. Ha egy modell részlegesen téved, azt nehéz elkapni. Ha totálisan, azt könnyű. Három sor kódot írtunk, és a hibák 100%-át megfogja. Ez pedig felveti a kérdést, ami a következő körünk témája lesz: ha egy döntést egy determinisztikus szabály hiánytalanul ellenőrizni tud, kell-e egyáltalán a nyelvi modellre bízni? Nem biztos, hogy igen. A számlán szereplő két cég szétválogatása nem LLM feladat, hanem azonosító-egyeztetés, arra pedig az adatbázis tökéletesen megfelel.

Ami hátravan

Nagyobb korpusz. Száz dokumentum elég volt ahhoz, hogy lássuk a különbséget az FP8 és az NVFP4-osztály között, de kevés ahhoz, hogy a hibát jellemezzük. A külföldi-partner hipotézist külön kell mérni, célzottan gyűjtött mintán.

A determinisztikus előszűrés kiépítése, nem azért, hogy utána válthassunk, hanem mert az FP8 is hibázik 7 esetben százból. Ha van egy szabály, ami mindet elkapja, akkor a kérdés nem az, hogy melyik modellt használjuk, hanem hogy miért engedjük egyáltalán a modellt dönteni ebben.

Ez a kvantálási teszt végül nem is a kvantálásról szólt, hanem arról, hogy találtunk egy hibaosztályt a saját rendszerünkben, ami eddig is ott volt, csupán nem találtunk rá.

---

A mérések egy GB10-alapú fejlesztői gépen készültek, vLLM v0.24.0-n, azonos image-digesttel, minden checkpoint a saját legjobb backendjével. A pontossági mérések temperature=0 mellett futottak. A 100 dokumentumos kapu valós, céges adaton készült; a cikkben csak aggregált számok szerepelnek. A statisztikai próbák párosított McNemar-tesztek, a p-értékek egzakt binomiális számításból.