Task schema az AI-ban: megbízhatóbb ICL a gyakorlatban

Egy kórházi ügyeletben vagy egy karácsony előtti csúcsidős webáruházban ugyanaz a mondat hangzik el túl gyakran: „most nincs idő újratanítani a modellt, most kell működnie.” 2025 végén ez már nem csak kényelmi kérdés, hanem üzemi kockázat. A nagy nyelvi modelleket (LLM-eket) azért szeretjük, mert promptból képesek feladatot tanulni – ezt hívjuk in-context learningnek (ICL). Csakhogy a valóságban az ICL néha meglepően stabil… máskor pedig ugyanazzal a stílussal megírt prompttól is szétesik.

Egy friss kutatás (Chaeha Kim, 2025.12) erre a „miért működik ma, miért nem működik holnap?” problémára ad mechanisztikus választ: az ICL nem egyetlen trükk, hanem két külön folyamat együttese: Task Schema és Binding. A lényeg: a modell először felismeri a feladat típusát (schema), aztán hozzáköti az adott példák konkrét input–output párosait (binding). A kettő nem ugyanaz, és másképp is romlik el.

Ez a felismerés különösen hasznos két területen, amelyek látszólag távol állnak egymástól, mégis ugyanazt a fájdalmat érzik: egészségügyi döntéstámogatás és kiskereskedelmi / e-kereskedelmi AI. Mindkettőben gyors alkalmazkodás kell, minimális újratanítással, miközben erős „prior” (előzetes tudás) zavarhat be.

Mit bizonyít a kutatás: az ICL két, szétválasztható mechanizmus

Válasz röviden: a kutatás ok-okozati (nem csak megfigyeléses) módszerekkel igazolja, hogy az ICL két komponensre bontható, és ezek külön „javíthatók” vagy „ronthatók el”.

A szerző activation patching kísérletekkel dolgozott többféle modellen (9 modell, 7 Transformer-család, plusz Mamba; 370M–13B paraméter). A patching lényege: a modell belső aktivációit „átültetik” egy futásból a másikba, és megnézik, mi az a belső jel, ami ténylegesen hordozza a feladatmegoldáshoz szükséges információt.

A három legfontosabb eredmény számszerűen:

• Kettős disszociáció (double dissociation):
  • Task Schema átvihető 100%-ban késői MLP patchinggel.
  • Binding csak 62%-ban vihető át a reziduális folyam (residual stream) patchinggel.
• Prior–Schema trade-off: minél több előzetes tudása van a modellnek egy területen, annál kevésbé támaszkodik schema-vezérelt ICL-re (Spearman ρ = -0,596, p < 0,001, N = 28 feladat–modell pár).
• Architektúra-függetlenség: a jelenség nem csak Transformerben látszik, hanem a Mamba architektúrában is.

Egy mondatban: a modell először „ráismer” a feladat fajtájára (schema), majd megpróbálja „összekötni” a példákat a helyes válaszokkal (binding) – és ezek külön hibáznak.

Task Schema vs. Binding: mi a különbség a gyakorlatban?

Válasz röviden: a Task Schema a feladat-formátum felismerése, a Binding pedig az aktuális példák pontos hozzárendelése.

Task Schema (feladatséma): „mit kell itt csinálni?”

A schema olyan, mint amikor egy új kolléga ránéz a kasszára és azonnal érti, hogy „itt visszárut kezelünk”, még ha a konkrét termékkódokat nem is tudja fejből. LLM-es példában: felismeri, hogy a prompt pár példát mutat és utána jön egy új sor – tehát osztályozás, kivonatolás, formátum-konverzió vagy döntési fa jellegű triázs történik.

Egészségügyben ez lehet például:

• triázs logika (sürgősségi besorolás szabályai),
• lelet-összegzés formátuma,
• gyógyszer-interakció ellenőrzés „checklist” mintája.

Kiskereskedelemben:

• termék-attribútum kinyerés (márka, kiszerelés, kompatibilitás),
• ügyfélszolgálati ticket címkézés,
• kosár-szabályok alkalmazása (pl. ajándékcsomagolás, kuponfeltételek).

Binding (kötés): „pontosan ehhez ezt társítsd”

A binding az a rész, amikor a modell nem csak érti a feladatot, hanem a konkrét példákból megtanulja, hogy „ha itt ez a bemenet, akkor ott az a kimenet”. Ez az, ami az üzemben gyakran elcsúszik:

• a modell rossz példára figyel (recency bias),
• összekeveri a párosításokat,
• vagy „okos” akar lenni és visszanyúl a saját előzetes tudásához.

A kutatás szerint a hiba sokszor figyelmi útvonalhibából ered: a szerző 72,7%-ban recency bias jellegű félrefigyelést talált, miközben a „kimeneti versengés” (mintha két válasz közül kellene választani) 0% volt. Ez fontos üzenet: nem (csak) az a baj, hogy „a modell makacs”, hanem hogy rossz helyre néz.

Miért számít ez diagnosztikában és döntéstámogatásban?

Válasz röviden: mert az egészségügyi AI megbízhatóságát gyakran nem a tudás hiánya, hanem a helytelen binding rontja el – különösen akkor, amikor sok a „prior” és nagy a tét.

A klinikai szövegek, kódok és protokollok tele vannak ismert mintákkal. Pont ez az, ami a prior–schema trade-off szerint gond: ha a modell „túl sokat tud”, könnyebben félreviszi a figyelme.

Konkrét, életszerű példa (tanulságos, nem „labor”):

• Egy döntéstámogató rendszernek rövid anamnézis alapján kell javasolnia vizsgálati sort.
• A prompt 3 példát ad, ahol atípusos tünetekhez atípusos ajánlás tartozik.
• A negyedik esetben a modell visszacsúszik a „klasszikus” protokollba, mert a szövegben meglát egy ismerős kulcsszót.

A schema itt működik (érti, hogy protokollajánlás a feladat), de a binding elromlik (nem azt a párosítást alkalmazza, amit a példák tanítanak). A kutatás állítása szerint ez főleg figyelmi hiba, tehát prompt- és folyamatdesignnal sokat lehet javítani.

Mit jelent ez a kiskereskedelemben és e-kereskedelemben?

Válasz röviden: az ICL kettébontása megmagyarázza, miért stabil a „formátum-átalakítás”, és miért csúszik el gyakrabban a személyre szabás, kuponszabály vagy ügyfélszolgálati kivételkezelés.

A sorozatunk ("Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben") tipikus problémái – ajánlórendszerek, kereslet-előrejelzés, készletkezelés, vásárlói viselkedéselemzés – egyre gyakrabban kapnak LLM-es réteget:

• termékleírások normalizálása,
• keresési lekérdezések értelmezése,
• ügyfélpanaszok automatikus osztályozása,
• „miért ezt ajánlottad?” magyarázat generálása.

Ezekben a feladatokban a schema általában erős: a modell jól érti, hogy „címkézz”, „fogalmazz át”, „vonj ki mezőket”. A binding viszont akkor sérül, amikor rövid ideig érvényes, üzletspecifikus szabályokat kell követni:

• „Ezen a héten a ‘Téli csomag’ kedvezmény csak 2+ darabtól él.”
• „A VIP ügyfélnek más a visszaküldési folyamata.”
• „A 2025.12.20–2025.12.24 közötti rendelések SLA-ja módosult.”

Ezekhez nem nagy tudás kell, hanem hibátlan kötés a promptban megadott példákhoz. Pont az a 38% körüli binding-vesztés (62% átvihetőség), ami termelési környezetben „random hibáknak” tűnik.

Gyakorlati prompt minták: így erősítsd a schemát, és védd a bindinget

Válasz röviden: külön kezeld a „feladatmegértést” és a „párosítás megtartását”, és számolj azzal, hogy nagy prior mellett a binding sérülékenyebb.

1) Külön blokk a feladatsémának (schema-lock)

A cél: a modell ne találgassa, milyen feladattípus van, hanem kapjon egy stabil keretet.

• Adj fix címsorokat és kimeneti sémát.
• Ne változtasd a példák formátumát (még apróságokban se).
• Használj rövid, ismétlődő „szabálymondatot”.

Példaelv:

• „Mindig JSON-t adsz vissza label és reason mezőkkel.”

2) Binding védelem: minimalizáld a félrefigyelést

A kutatás fényében a cél az, hogy a modell oda nézzen, ahol a releváns példa van.

Ami nálam bevált (és jól illeszkedik a mechanisztikus magyarázathoz):

• Példák számozása és a bemenet egyedi azonosítója (pl. Eset-04).
• A példákban a kritikus különbség ugyanazon a helyen szerepeljen.
• Ne hagyj „csábító” extra információt a promptban (felesleges domain-mondatok).

3) Prior-tudatos design: ne vitatkozz a modellel, tereld

Ha a modellnek erős előzetes tudása van (pl. orvosi protokollok, gyakori e-kereskedelmi minták), akkor könnyebben „visszaugrik” a saját rutinjára.

Ilyenkor jobb stratégia:

• tedd explicitté, hogy „most kivétel-szabály jön”,
• adj ellenpéldát, amely megmutatja, hogy a „klasszikus” válasz itt rossz,
• tartsd röviden a demonstrációt, de legyen benne a kivétel.

4) Operatív kontroll: mérd külön a schemát és a bindinget

Termelési környezetben (kórházban vagy webshopnál) nem elég annyi, hogy „pontosság 92%”. Én két külön jellegű tesztet futtatnék:

1. Schema-teszt: ugyanaz a feladattípus, sokféle tartalommal. (A formátum stabil?)
2. Binding-teszt: ugyanaz a tartalom, de promptban megadott ideiglenes párosításokkal. (A kivételeket tartja?)

Ez a felosztás gyorsan megmutatja, hogy a hibák „feladatmegértési” vagy „kötési” jellegűek.

„People also ask” – gyors válaszok a tipikus kérdésekre

Tényleg lehet az ICL-t megbízhatóbbá tenni újratanítás nélkül?

Igen, ha a hibák jelentős része binding jellegű, akkor prompt-szerkezet, demonstrációk és figyelemterelés (strukturálás) sokat javít.

Miért romlik gyakrabban a modell ott, ahol „sokat tud”?

Mert a kutatás szerint a prior tudás interferál a schema-alapú működéssel, és a modell figyelme könnyebben rossz példára vagy rossz mintára csúszik.

Mit vigyek haza ebből, ha ajánlórendszerekkel foglalkozom?

A személyre szabásnál gyakran ideiglenes üzleti szabályokat kell alkalmazni (kampány, készlet, SLA). Ezek binding-nehéz feladatok. A stabil output-séma és a binding-védett prompt többet ér, mint még egy plusz bekezdés „szép szöveg”.

Következő lépés: a megbízható ICL nem varázslat, hanem tervezés

A Task Schema és Binding szétválasztása nekem azért erős gondolat, mert rendet tesz a mindennapi tapasztalatban: vannak feladatok, ahol a modell „érti, mit kell csinálni”, mégis hibázik – és ez nem ellentmondás, hanem két külön mechanizmus külön hibája.

Egészségügyben ez közvetlenül a biztonság és az ellenőrizhetőség kérdése. Kiskereskedelemben és e-kereskedelemben pedig a konverzió, a SLA, a készlet és az ügyfélelégedettség bánja, ha a modell egy kampányszabályt rosszul köt meg. A jó hír: ha tudod, hogy schema vagy binding fáj, célzottan tudsz javítani.

Ha most egyetlen dolgot változtatnál meg a saját LLM-es folyamataidban 2026-ra: kezdj el külön mérni schema- és binding-hibákat, és ennek megfelelően tervezd a promptot. A kérdés már nem az, hogy „mennyire okos a modell”, hanem az, hogy mennyire jól irányítod a figyelmét ott, ahol a döntés születik.