Generatív ajánlórendszerek skálázása: xGR a gyakorlatban

2025 végére a generatív modellek már nemcsak „szép” szövegeket írnak: egyre több cég próbálja LLM-alapú generatív ajánlórendszerekkel kiváltani vagy kiegészíteni a klasszikus rangsoroló pipeline-okat. A gond ott kezdődik, amikor a prototípus találkozik a valós forgalommal: csúcsidőben sok ezer párhuzamos kérés, szigorú válaszidő-SLA, és közben a költségkeret sem végtelen.

A friss xGR kutatás (2025.12.19-én frissített verzió) pontosan ezt a fájdalompontot célozza: hogyan lehet a generatív ajánlást alacsony késleltetéssel és nagy áteresztőképességgel kiszolgálni. Ami nekem különösen tetszik benne, hogy nem „még egy modelltrükk”: ez szolgáltatás- és rendszertervezés. És ez az a réteg, ami a kiskereskedelmi/e-kereskedelmi AI-ban is gyakran alulbecsült.

A cikkben végig a „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” sorozat szemszögéből gondolkodom, de közben folyamatosan áthidalom az egészségügyi párhuzamokat is: ha a skálázott generatív ajánlás működik a kosárértékért, működhet a betegút- és diagnosztikai ajánlásokért is – csak a szabályozási és biztonsági elvárások sokkal szigorúbbak.

Miért más a generatív ajánlás, mint a „sima” LLM-serving?

A lényeg: a generatív ajánlórendszerek terhelési mintája eltér a klasszikus LLM-chat kiszolgálástól.

LLM-chatnél jellemzően rövidebb promptokkal indítunk, aztán hosszabban generálunk. Generatív ajánlásnál (GR) viszont gyakori, hogy:

• hosszú a bemenet (például több száz eseményből álló user–item szekvencia: kattintások, megtekintések, kosárba tétel, vásárlás),
• rövid és fix hosszú a kimenet (pl. top-20 ajánlás),
• a decode szakasz mégis drága, mert nagy a beam width (több párhuzamos „jelölt út” keresése),
• a jelölt tér hatalmas, ezért a rendezés/szűrés overheadje időben és költségben is megugrik.

E-kereskedelemben ez úgy csapódik le, hogy hiába jobb az ajánlás minősége, ha a válaszidő miatt romlik a konverzió, vagy a magas GPU-költség megeszi a marzsot. Egészségügyben pedig még keményebb a helyzet: egy triázs vagy klinikai döntéstámogatás esetén a késleltetés nemcsak UX-kérdés, hanem folyamatbiztonsági tényező.

Egy mondatban: a generatív ajánlás „hosszú prefill + rövid, de drága decode”, és ezt külön kell optimalizálni.

Mit ígér az xGR, és miért érdekes üzletileg?

Az xGR egy GR-orientált serving rendszer, ami kifejezetten alacsony késleltetés mellett, nagy konkurencia esetén próbál maximális throughputot adni. A tanulmány szerint a mért nyereség legalább 3,49× áteresztőképesség a korábbi state-of-the-art baseline-hoz képest, szigorú latency korlátok mellett.

Ez üzletileg több dolgot jelenthet:

• ugyanazzal a GPU-parkkal több forgalmat szolgálsz ki,
• vagy ugyanazt a forgalmat kisebb költséggel,
• és (ami a legfontosabb) stabilabb SLA-t kapsz csúcsidőben.

A kiskereskedelmi AI-ban ezt tipikusan a karácsonyi időszakban érzed meg a legerősebben (és igen, 2025 decemberében ez kifejezetten aktuális): az ajánlórendszer terhelése ilyenkor nem „kicsit nő”, hanem megugrik.

Az xGR három ötlete: mit csinál másképp a pipeline-ban?

Az xGR három technikai pillért emel ki. Nem kell minden belső részletet ismerni ahhoz, hogy értsük a lényegét: mindhárom arról szól, hogy kevesebb felesleges munka történjen a kritikus útvonalon, és jobban átfedjék a számítást.

1) Prefill és decode egységesítése: staged compute + szeparált KV cache

Válasz elsőként: az xGR úgy kezeli a prefill és a decode munkát, hogy jobban illeszkedjen a GR terhelési profiljához.

A klasszikus transformer servingnél a KV cache (Key-Value cache) a decode gyorsításának alapja. GR esetén viszont a prefill hosszú, a decode rövid, és a beam search miatt a cache-kezelés könnyen széttöredezik.

Az xGR két irányból fogja meg:

• staged computation: a számítást lépésekre bontja úgy, hogy a GPU/CPU és memória-hozzáférések jobban ütemezhetők legyenek,
• separated KV cache: a cache-t úgy választja szét/strukturálja, hogy kevesebb legyen a fölös másolás és jobb legyen az újrahasznosítás.

E-kereskedelemben ez akkor látványos, ha sok az ismétlődő minta (pl. ugyanazon kampány-termékek sok felhasználónál). Egészségügyben pedig azért fontos, mert a betegút-szekvenciák (laborok, ICD-kódok, vizitek) hasonlóan hosszúak lehetnek, és ott sem fér bele, hogy a rendszer cache-menedzsment miatt „akadozzon”.

2) Beam search gyorsítása: korai rendezés-leállítás és maszkos item-szűrés

Válasz elsőként: a legdrágább pontot, a hatalmas item-tér rendezését és szűrését rövidíti le.

Generatív ajánlásnál a beam search nemcsak több jelöltet futtat, hanem a végén (vagy közben) sokat kell rendezni, top-k-t kiválasztani, és ki kell zárni érvénytelen jelölteket.

Az xGR itt két praktikus trükköt hoz:

• early sorting termination: nem rendez végig mindent, ha már biztosan megvan, ami kell (tipikusan top-k),
• mask-based item filtering adatstruktúra-újrahasznosítással: a rendszer nem enged be eleve olyan itemeket a jelöltek közé, amik „tiltólistán” vannak (készlethiány, jogi tiltás, életkori korlát, személyes preferencia), és mindezt úgy, hogy a szűréshez használt struktúrák nem épülnek fel újra minden kérésnél.

Kiskereskedelmi párhuzam (nagyon kézzelfogható):

• ha egy termék nincs készleten, vagy nem szállítható az adott régióba, akkor ne is kerüljön be a beam jelöltterébe,
• ha bizonyos kategóriák tiltottak (pl. szabályozott termékek), a maszk ezt rögtön levágja,
• így az ajánlás nemcsak gyorsabb, hanem „tisztább” is.

Egészségügyi analógia: klinikai ajánlásnál a „maszk” lehet protokoll- és kontraindikációs szűrés (például egy gyógyszerjavaslat ne jelenjen meg, ha allergia vagy interakció miatt nem releváns). Itt az optimalizáció egyszerre teljesítmény- és biztonsági kérdés.

3) Pipeline újraépítése: multilevel overlap és multi-stream párhuzamosság

Válasz elsőként: az xGR a várakozási időt csökkenti azzal, hogy több műveletet átfedésbe hoz, és párhuzamos streameken futtat.

A serving rendszerekben gyakori, hogy a GPU számol, közben a CPU vár, vagy fordítva, és a memória-mozgatás is „láthatatlanul” eszi az időt. Az xGR célja, hogy:

• a prefill/decode egyes lépései átfedjék egymást,
• a különböző stream-ek (GPU munkafolyamok) jobban kihasználják a rendelkezésre álló erőforrásokat,
• így ugyanazon hardveren több request férjen bele ugyanabba az időablakba.

A gyakorlati üzenet számomra: ha GR-t akarsz élesben, akkor nem elég „jó modellt” tréningezni. A kiszolgáló pipeline ugyanúgy termék, és külön optimalizációt igényel.

Mit jelent ez a kiskereskedelmi és e-kereskedelmi AI-ban?

Válasz elsőként: a generatív ajánlás akkor lesz üzletileg életképes, ha a serving költség és a latency együtt kezelhető.

A klasszikus ajánlórendszerek (kétlépcsős retrieval + ranking) évtizedek óta azért működnek jól, mert kiszámíthatóak és gyorsak. A generatív ajánlás előnye a szekvenciák mélyebb megértése és a rugalmasabb jelöltképzés. De ha a beam search és a decode költsége elszáll, a CFO gyorsan nemet mond.

Három konkrét, alkalmazható tanulság e-kereskedelmi csapatoknak:

1. Ne általános LLM-serving stackre húzd rá a GR-t „ahogy van”. A terhelésprofil más, a bottleneckek mások.
2. A jelöltteret üzleti szabályokkal korán szűkítsd. Készlet, margin, szállíthatóság, compliance: ezek nem a végén „szépítések”, hanem teljesítménykulcsok.
3. Mérj beam width és top-k oldalról is. A minőség–költség görbe nem lineáris: egy kis beam csökkentés néha nagy latency nyereséget ad minimális minőségromlással.

Ugyanez az egészségügyben: személyre szabás, csak nagyobb téttel

Válasz elsőként: az xGR-szerű serving megközelítés a klinikai generatív ajánlásoknál is releváns, mert ott is hosszú a kontextus és szigorú a válaszidő.

Az egészségügyi MI (mesterséges intelligencia az egészségügyben) területén egyre gyakoribbak az olyan use case-ek, ahol „ajánlani” kell:

• következő diagnosztikai lépéseket (labor, képalkotás),
• betegút-útvonalakat (melyik szakrendelés, milyen kontroll),
• személyre szabott életmód- vagy terápiás javaslatokat.

Ezek valójában nagyon hasonlítanak az e-kereskedelmi ajánláshoz: hosszú előzményt nézünk, rövid listát adunk vissza. A különbség, hogy:

• sokkal szigorúbb a traceability (miért ezt ajánlotta?),
• erősebb a safety (mit nem szabad ajánlani?),
• és a késleltetés gyakran folyamatkritikus.

A „mask-based filtering” itt különösen erős üzenet: a klinikai rendszerben a maszk lehet guideline, kontraindikáció, életkor, terhesség, gyógyszer-interakció, intézményi protokoll. Ha a serving architektúra eleve úgy van kitalálva, hogy a tiltás és szűrés gyors, akkor a biztonsági korlát nem „ráépített fék”, hanem a rendszer természetes része.

Gyakorlati ellenőrzőlista: mikor érdemes xGR-szemléletben gondolkodni?

Válasz elsőként: akkor, ha már most a serving a szűk keresztmetszet, vagy 3–6 hónapon belül az lesz.

Ha generatív ajánlást tervezel (kiskereskedelemben vagy egészségügyben), én ezt a listát szoktam javasolni egy gyors helyzetfelméréshez:

• Konkurencia: hány párhuzamos ajánláskérés jön csúcsban (P95, P99)?
• SLA: mi a maximális P95 latency? (Nem átlag!)
• Kimenet: fix top-k kell (pl. 10/20/50), vagy adaptív?
• Beam width: mekkora beam kell ténylegesen minőséghez, és mekkora „megszokásból”?
• Item space: hány aktív termék/entitás van, és mennyi a szűrés után?
• Szűrési szabályok: mennyi üzleti/compliance tiltás van, és ezek a pipeline melyik pontján érvényesülnek?
• Költség: mennyi a megengedett ajánlás-költség 1000 requestre vetítve?

Ha ezekből 2-3 elemre azt mondod, hogy „nem tudjuk pontosan”, akkor a projekt tipikusan nem modell-, hanem operációs és mérési kockázatba fut.

Következő lépés: ajánlásból döntéstámogatás – felelősen

A generatív ajánlórendszerek skálázása nem látványos téma, mégis itt dől el, hogy egy AI-képességből lesz-e termék. Az xGR üzenete számomra egyszerű: a generatív ajánlás servingje külön műfaj, és aki erre külön optimalizál, az stabilabb latency-t és jobb költség/érték arányt kap.

Ha a „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” sorozatot követed, ez a poszt jó helyre illeszkedik: a személyre szabott ajánlások minősége mellett most a kiszolgálhatóság a fókusz. És ugyanaz a tudás átvihető az egészségügybe is, ahol a személyre szabás értéke még nagyobb, de a kontrolloknak is erősebbnek kell lenniük.

A kérdés, amin szerintem érdemes elgondolkodni 2026 eleje előtt: a csapatod ma modellben gondolkodik, vagy rendszerben?