Kontextusérzékeny AI: stabil döntések Schema–Bindinggel

A legtöbb cég ott csúszik el az „okos” AI bevezetésnél, hogy a modell néha zseniális, néha meg teljesen mellémegy – ugyanazzal a prompttal, hasonló adatokkal. A jelenség különösen fáj a kiskereskedelemben és e-kereskedelemben, ahol egy rossz termékajánlás, egy félreértett ügyfélszándék vagy egy hibás készletjelzés közvetlenül bevételbe kerül. És a kellemetlen rész: sokszor nem az adatok a rosszak, hanem az, ahogyan a modell a kontextust „összerakja”.

2025.12.22-én friss arXiv-kutatás jelent meg az in-context learning (ICL) működéséről, ami végre kézzelfogható, mérnökileg is hasznos magyarázatot ad: az ICL két külön mechanizmusból áll. Az egyik a Task Schema (feladat-séma), a másik a Binding (konkrét hozzárendelés). A szerzők ezt nem csak viselkedési megfigyelésként állítják, hanem több modellcsaládon, oksági beavatkozásokkal (activation patching) támasztják alá.

Ez a felosztás azért nagy ügy, mert ugyanazt a problémát látjuk az egészségügyben is (kampányunk fókusza), csak más kockázati szinten: egy triázs-tanács, gyógyszer-interakció, tünet–kórkép illesztés vagy leletösszegzés esetén a „néha jó, néha rossz” egyszerűen nem fér bele. A retail és a healthcare viszont egymástól tanulhat: ami stabilabb diagnosztikai gondolkodást ad, az stabilabb ajánlórendszert és ügyfélszolgálati asszisztenst is.

Mit jelent a Task Schema és a Binding az ICL-ben?

Röviden: a Task Schema annak felismerése, hogy „milyen típusú feladatot kell csinálnom”, a Binding pedig annak megtanulása a példákból, hogy „ebben a konkrét helyzetben mi melyik kimenethez tartozik”. A kutatás szerint a kettő neurálisan is szétválik, és külön-külön „átvihető” a modellben.

A paper három száma, amit érdemes megjegyezni (mert sokat elárul):

• 100% Task Schema transzfer: a szerzők késői MLP rétegek patch-elésével teljesen át tudták vinni a feladat-sémát.
• 62% Binding transzfer: a konkrét input–output hozzárendelések csak részben (62%-ban) vihetők át residual stream patch-eléssel.
• Prior–Schema trade-off: a séma-használat fordítottan arányos a modell előzetes tudásával (Spearman ρ = -0,596; p < 0,001; N = 28).

A gyakorlatban ez a következőképp néz ki.

Task Schema példa (retail)

Ha adsz 2–3 példát arra, hogyan kell egy termékleírást „tömör, vásárlóbarát bulletpontokra” átalakítani, a modell gyorsan ráérez a feladattípusra. Ez a séma: átalakítás, stílus, struktúra.

Binding példa (retail)

Ha adsz példákat egy ideiglenes kategóriarendszerre (pl. „A=karácsonyi ajándék”, „B=utazási kiegészítő”) és kéred, hogy az új termékeket A/B szerint sorolja be, akkor a modellnek a konkrét hozzárendelést kell megtanulnia a promptból. Ez a binding. És ez az, ami gyakrabban elromlik – különösen akkor, ha a modellnek van előzetes, „erős” véleménye a világról.

Healthcare párhuzam (miért releváns a kampányhoz?)

Ugyanez történik egy klinikai döntéstámogató rendszerben:

• Schema: „laboreredményekből kockázati besorolást kell adni” vagy „leletet kell összefoglalni a beteg számára”.
• Binding: „ebben az intézményi protokollban a piros/sárga/zöld pontosan ezt jelenti” vagy „ebben a gyógyszerlistában ez a rövidítés ehhez a hatóanyaghoz tartozik”.

Ha a Binding hibázik, az a retailben „csak” konverzióvesztés. Az egészségügyben betegbiztonsági kockázat.

A kutatás legfontosabb üzenete: nem egyetlen „ICL-trükk” van

Direkt állítás: az ICL nem monolit. Két külön folyamat játszik össze, és ez megmagyarázza a mindennapi anomáliákat: miért megy az „önkényes” mapping (ha nincs prior), és miért nehéz felülírni tényeket (ha van prior).

A szerzők szerint amikor a modellnek erős előzetes tudása van, az nem úgy zavar be, hogy „két válasz összeverekszik a kimeneten”. Hanem úgy, hogy a figyelem rossz helyre megy: attentional mis-routing. A cikk egy konkrét számot is ad: a hibák 72,7%-a recency bias jellegű, miközben 0% volt „direkt kimeneti verseny”.

A retail nyelvére lefordítva: nem az a baj, hogy a modell „nem akarja” követni a példádat – hanem az, hogy rossz mintát talál relevánsnak a prompton belül, és rossz kontextuselemet emel ki.

Mit kezdjen ezzel egy e-kereskedelmi csapat? (Prompt- és rendszertervezési lépések)

Válasz először: külön kezeld a sémát és a bindingot. A séma stabilan átadható, a binding sérülékenyebb, ezért a kockázatot ott kell csökkenteni.

1) Sémát adj át, minimális példával

A kutatás egyik gyakorlati implikációja, hogy a megbízható sémaátadás csökkenti a szükséges demók számát új feladatoknál. Ezt érdemes kihasználni akkor, amikor gyorsan kell új kampány- vagy katalóguslogikát bevezetni.

Működő minta retailben:

• Adj 1 jó példát a formátumra (pl. „termékleírás → 5 bullet”)
• Adj 1 ellenpéldát (mit ne csináljon: túl hosszú, túl marketinges)
• Adj egy rövid „szabályblokkot” (stílus, hossz, tiltott állítások)

Itt a cél a Schema stabilizálása.

2) Bindingnál „prior-tudatosság” kell

Ha a modellnek erős priorja van (pl. orvosi tartalom, gyógyszernevek; retailben márkák, kategóriák, árképzési logikák), akkor a binding könnyebben elcsúszik.

Gyakorlati trükkök, amik csökkentik a 38% körüli binding-hibakockázatot (a paper által sugallt nagyságrend):

• Egyértelmű jelölések: ne A/B, hanem pl. KATEGORIA_01, KATEGORIA_02.
• Rövid, közeli példák: a recency bias miatt a legutóbbi példák túl nagy súlyt kapnak, ezért inkább 2–4 példát adj, de legyenek jól válogatva.
• „Anti-prior” mondatok: explicit kikötés, hogy a hozzárendelés csak a megadott táblázat szerint történhet, és a modell ne használjon „általános tudást”.
• Tesztesetek beépítése: egy mini „self-check” sor a végén: „Írd le, melyik szabály alapján soroltad be.” Ez nem varázslat, de segít a figyelem helyes irányításában.

3) Válaszd szét a pipeline-ban is: Schema modul + Binding modul

A cikk egyik legfontosabb üzenete, hogy a kettő külön mechanizmus. Én ezt rendszertervezésben is különválasztanám:

• Schema-lépés: feladattípus felismerése + válaszformátum (klasszifikálás/összegzés/ajánlás)
• Binding-lépés: konkrét mapping, üzleti szabályok, intézményi protokollok

Retail példa:

1. „Határozd meg, a vásárló üzenete panaszként, érdeklődésként vagy rendelésmódosításként értelmezhető-e.” (Schema)
2. „A belső folyamatkódok szerint rendeld hozzá: PROC_07, PROC_12, PROC_21.” (Binding)

Egészségügyi analógia:

1. „Ez triázs/összegzés/figyelmeztetés feladat?” (Schema)
2. „A helyi protokoll szerinti kockázati kategória és javasolt következő lépés.” (Binding)

Miért érdekes, hogy több architektúrán (még Mamba-n is) működik?

Válasz először: mert ez azt sugallja, hogy a Schema–Binding felosztás nem egyetlen modellcsalád „furcsasága”, hanem szélesebb, mérnökileg kihasználható minta.

A szerzők 9 modellt vizsgáltak 7 Transformer családból és egy nem-Transformer architektúrát (Mamba), 370M–13B paraméteres tartományban. Ha ugyanaz a mechanizmus többféle architektúrán megjelenik, az jó hír azoknak, akik termékben gondolkodnak:

• kevésbé modellfüggő tervezési elvek,
• hordozhatóbb prompt-sablonok,
• könnyebb A/B tesztelés különböző modellekkel.

A kiskereskedelemben ez konkrétan költség: ha modellváltáskor nem kell mindent újratanítani/újrapromptolni, gyorsabb a time-to-value. Az egészségügyben pedig a validációs teher csökkenhet, mert a rendszer logikája átláthatóbb (a validáció így is kötelező, csak nem mindent kell „fekete dobozként” kezelni).

„People also ask” – rövid, gyakorlati válaszok

Miért működik az AI jól új feladatoknál, de rosszul, amikor tényeket kell felülírni?

Mert új feladatnál a Schema dominál, és nincs prior, ami félreviszi a figyelmet. Tényfelülírásnál a prior erős, és a binding könnyebben elcsúszik.

Elég több példát adni a promptban, hogy javuljon a pontosság?

Nem mindig. A recency bias miatt a rosszul megválasztott plusz példák rontanak is. Inkább kevesebb, de jobban célzott demonstráció működik.

Hogyan lesz ebből jobb ajánlórendszer vagy ügyfélszolgálati chatbot?

Úgy, hogy a csapat tudatosan külön kezeli:

• a feladat-sémát (formátum, döntési típus),
• és a konkrét hozzárendeléseket (üzleti szabályok, kategóriák, kuponlogika).

Zárás: a stabil kontextusértés üzleti és klinikai kérdés is

Az in-context learning Schema–Binding felosztása nekem azért tűnik különösen hasznosnak, mert végre nem „promptmágia” szinten beszélünk a hibákról. A számok (100% schema transzfer, 62% binding transzfer, 72,7% recency bias) elég világos irányt mutatnak: a szűk keresztmetszet gyakran a figyelem irányítása, nem a kimeneti válasz „legyőzése”.

A „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” sorozatban sokat beszélünk személyre szabott ajánlásokról, kereslet-előrejelzésről és készletkezelésről. Én ehhez hozzátenném: a következő szint a kontextusrobosztus működés. Ugyanaz a gondolkodás, ami egy orvosi döntéstámogatót biztonságosabbá tesz, egy ajánlórendszert is kiszámíthatóbbá tesz a karácsonyi csúcsban, akciók alatt vagy új kategóriák bevezetésekor.

Ha most vezetsz be (vagy skálázol) LLM-alapú megoldást, érdemes egy belső auditot csinálni: a hibák nagy része Schema-probléma (rossz feladattípus), vagy Binding-probléma (rossz hozzárendelés)? Ha megvan a válasz, a javítás is gyorsabb lesz.

Te melyikbe futsz bele gyakrabban a gyakorlatban: a modell félreérti a feladatot, vagy érti a feladatot, csak rosszul köti össze a konkrét szabályokat?