Őszinte, részletes technikai cikkek a DocAI fejlesztéséből: LLM inference tuning, GPU optimalizáció, dokumentumfeldolgozó pipeline-ok, vállalati MI architektúra. Negatív eredmények és tanulságok is. Hetente új poszt.
A cikkek mögötti mérések nyers adatai és módszertana nyilvánosak: github.com/k3net/docai-evals
Egy asztali gépen 64 perc alatt betanítottunk egy nyílt nyelvi modellt Arany János 485 versére, aztán megmértük vonalzóval, mi lett belőle. Formában rosszabb lett: minden szabályossági tengelyen alulmaradt egy pár tucat soros rerankerrel szemben, ami semmit nem tanult, csak nyolcszor kérdezett. A stílus viszont fordítva viselkedett: a reranker ott meg sem mozdult, a felismerhetőséget kizárólag a tanulás vitte 56%-ról 92%-ra. Plusz a mérőléc, ami szerint maga Arany is csak 0,577-et ér el, és az ár, amit a gép kitalált szavakban fizet.
Kipróbáltuk a kétszer akkora Llama-3.3-70B-t a produkciós Qwen3.6-35B-A3B ellen 100 valós magyar dokumentumon. A várt eredmény: 30 F1-pont hátrány és 26× lassulás. A nem várt: az egyetlen dimenzió, ahol a Llama jobbnak látszott, egy hibadetektor kimenete volt, és amikor visszanéztük a ground truth-t, kiderült, hogy a szám a fordítottját mutatja a valóságnak. Plusz a képlet, amivel öt perc alatt eldöntöd, hogy egy modell egyáltalán játékban van-e a te vasadon.
Egy gyártó „agent-ready” serving receptet ad ki a modellcsaládunkhoz. Lemértük mindhárom flagjét a saját FP8-as modellünkön: −2,2%, −2,4%, −3,6%, egyik sem került be. Az érdekes rész a harmadik kar: a hosszabb spekulatív draft JSON-kinyerésen +19%, rövid chaten −9%, mert a törésvonal az elfogadási arány mentén húzódik. Plusz egy kellemetlen önvizsgálat arról, hogy 8-as konkurencián mértünk, miközben a valóság 1–3.
Ugyanaz a modell NVFP4-ben: +40% átbocsátás, +69% egyszálú kinyerés — és mégis maradt a block-FP8. A bejáratott F1-mérésünk nem tudott dönteni (a normalizálás után 0,0001 a különbség), a beszélgetés-evalunk sem. A döntést egy harmadik mérés hozta meg: 100 valós dokumentumon a „melyik cég a miénk” hiba 7-ről 12–18-ra ugrott. Plusz egy módszertani önvizsgálat és egy jó hír: a hiba totális, tehát három sor kóddal 100%-ban elkapható.
Két gyártó, ugyanaz a DGX Spark, ellentétes indítási parancs ugyanarra a modellre — az egyik pont azt tiltja, amit a másik előír. Lemértük: a rossz backend 2,0–3,3× lassulás, 10 mérési pont, 0 keresztezés. Aztán a fordulat: ugyanaz a marlin backend NVFP4-en nyer, block-FP8-on veszít. A helyes backend nem a hardver tulajdonsága, hanem a hardver és a kvantálási formátum párosáé, és ezt egyik gyártói model card sem mondja ki.
A Magyar Telekom szerint a tokenköltség a legnagyobb AI-kockázat — nem tudni, hogyan alakul az ára. Megnéztük a saját számainkat: két DGX Spark, 30 nap Prometheus-adat, a GPU átlag 11,56 W, a teljes rendszer havi ~100 kWh, azaz nagyjából 6 500 forint. Nem azt állítom, hogy olcsóbb, azt, hogy nem mozdul. A doboznak van plafonja, a tokenszámlának nincs. Plusz a mérnöki őszinteség: mikor NE csináld így.
2026-ban a kérdés már nem az, hogy használjunk-e AI-t, hanem hogy hová kerül az adat. Végigvesszük, mi élesedik most a GDPR és az EU AI Act oldalán a Digital Omnibus után, hol az öt valódi fájáspont (jogalap, tájékoztatás, érintetti jogok, automatizált döntés, harmadik országba továbbítás), és hogy miért nem jogi, hanem építészeti kérdés a megfelelés nagy része. Plusz: gyakorlati checklist és a döntő kérdés, felhő vagy on-premise?
Az elmúlt hónap DocAI-fejlesztései: a Partner 360 egyetlen képernyőn hozza a partner minden adatát, a cégadat-lekérdezés VIES-ellenőrzéssel bővült, a feltöltött bankszámlakivonatokat a rendszer automatikusan párosítja a számlákkal, új a szerződés- és bérjegyzék-nyilvántartás, a chat-asszisztens pedig már konkrét számlatételekre is válaszol. Plusz: NAV-független bizonylatok és Telegram-integráció.
Mi az AI dokumentumfeldolgozás, és miben más az OCR, az IDP és a KIE? Végigvesszük a piac három megoldástípusát — a felhős hyperscalert (Azure Document Intelligence, Copilot), a tanácsadói projektet és a SharePoint + RAG-chatet —, és hogy mindhárom hol enged: az adat elhagyja a céget, nincs magyar nyelvi optimalizálás, a megoldás sosem lesz a tied. Plusz a DocAI mért válasza: on-premise, magyar korpuszon F1 = 0,983.
Nyolc partnercég, egy nap a megszokott DocIT alapoktól a DocAI élő demójáig. Számtech óra az LLM-től az ügynökig, élesben futtatott spontán kérdések, egy kikapcsolva is figyelmet kapó DGX Spark, és egy ötlet, ami a beszélgetésből nőtt ki: a NIS2-audit modul, amibe még a nyáron belevágunk.
Egy 35 milliárd és egy 122 milliárd paraméteres modell szisztematikus összehasonlítása a DocAI saját magyar üzleti eval-harness-én. A nagyobb modell nem nyert a strukturált adatkinyerésen, és 2,6× lassabb, viszont a komplex, többlépéses elemzéseken hat feladatból ötben jobb választ adott, és ötször kevesebb adatlekéréssel. Mindkét modell termelésben, különböző célokra. Plusz a buktatók: NVFP4 sm_121a-n, FlashInfer MoE, KV-cache FP8 trade-off.
Hogyan lett több napos jóváhagyási folyamatból napon belüli ügymenet a szarvasi székhelyű Gree Magyarországnál? Napi 30–70 irat, négy közhiteles forrás automatikus partnerellenőrzése, 1+ óra napi megtakarítás csak az utaláson, 3–4 hónapos megtérülés, első ügyfelünk őszinte tapasztalataival.
Gemma4 candidate eval a DocAI magyar számla KIE corpuson: F1 0.890 vs Qwen3.6 0.975, single-stream decode 30-80%-kal lassabb. De a sebesség-mérés mellékterméke felfedte, hogy az MTP acceptance rate JSON-KIE workloadon 99%, az előző cikk 72.5%-os globális száma ezt teljesen elrejtette. A DocAI workload az MTP architekturális best case-e.
Qwen3.5-122B-A10B NVFP4 single Sparkon, vLLM 0.19.2-vel, MTP-vel: 30 tok/s JSON-KIE 100% MTP acceptance-szel, 64 tok/s aggregate 4 párhuzamos felhasználón, és a stress test, ahol a Spark megtörik a 100K-s párhuzamos kontextusoknál. Production-relevant memory budget, prefix caching és a végén egy őszinte konklúzió: érdemes-e DocAI-be tenni.
Qwen3.6-35B-A3B-FP8 + MTP (multi-token prediction) benchmark DGX Sparkon, GB10 chipen. A vanilla modell ugyanolyan gyors mint a 3.5, de a 16-concurrent stress teszten az MTP +24% throughput-ot és −56% TTFT-t adott, pont ott, ahol a spec decoding elméletileg negatív kellett volna legyen. A unified memory architektúra és a spec decoding váratlan szimbiózisa.
Kétnapos vLLM + Triton MoE tuning maraton a DGX Sparkon, Qwen3.5-35B-A3B-FP8 modellel. A végén a production config 5-7%-kal rosszabb lett. Mit tanultam a pure-kernel vs serving benchmark különbségéről, és hat konkrét tanulság, amit átvehetsz.
A következő cikk már készül. Ha nem akarsz lemaradni, iratkozz fel a kapcsolati űrlapon keresztül, vagy nézz vissza jövő héten.