Kontextuskezelés és megbízhatóság

A legkisebb súly, a legnagyobb kockázat

A tématerületek súlya azt mutatja, hány kérdés jut rá a vizsgán, nem azt, mennyire fontos a gyakorlatban. A kontextuskezelés és a megbízhatóság a legkisebb részt kapja, mégis ez az a réteg, amelyen minden más áll. Egy agentic architektúra, egy jól megírt prompt vagy egy gondosan megtervezett eszköz is csak akkor ér valamit, ha a modell a megfelelő információt látja, és a rendszer túléli, amikor valami elromlik. Vegyünk egy fiktív magyar céget, a Tisza Biztosítót. Ügyfélszolgálati AI asszisztenst építenek, amely a beérkező kárbejelentésekre válaszol, kikeresi az ügyfél szerződését, és megmondja, mi a következő lépés. Ezen a példán keresztül nézzük végig, mitől lesz megbízható egy ilyen rendszer.

A kontextusablak

A kontextusablak az az információmennyiség, amelyet a modell egyetlen kérés során egyszerre lát és figyelembe vesz. Minden beleszámít, ami a modell elé kerül. A rendszerprompt, amely megmondja, ki ő és mit csináljon. A felhasználó kérdése. A korábbi beszélgetés. A behúzott dokumentumok és az eszközök által visszaadott eredmények. Ez az ablak véges. Ha túllépjük a méretét, a legrégebbi vagy legkevésbé fontos rész kiszorul, és a modell egyszerűen nem tud róla. Ezért nem az a cél, hogy minél többet zsúfoljunk bele, hanem hogy a helyes dolog legyen benne a helyes pillanatban.

Mit tegyünk bele és mit ne

A kezdő ösztön az, hogy biztos, ami biztos, mindent beadunk a modellnek. Ez hiba. Több információ nem jelent jobb választ, sőt. A felesleges tartalom zaj, amely elvonja a figyelmet a lényegről, és rontja a válasz minőségét. A Tisza Biztosító asszisztensének nem az egész szabályzatra van szüksége, hanem arra az egy pontra, amely a bejelentett kárra vonatkozik. Nem a teljes ügyfélállományra, hanem az adott ügyfél aktív szerződésére. A jó kontextus szűk és pontos. A releváns dolgot tesszük bele, nem a teljes elérhető tudást, és nem a régi, ide nem tartozó beszélgetéseket.

Ennek gyakorlati következménye is van. Ha az egész szabályzatot beöntjük, a modellnek magának kell kikeresnie a helyes pontot a sok közül, és könnyen a rossz bekezdésre hivatkozik. Ha viszont eleve csak a bejelentett kárra vonatkozó szabályt adjuk oda, a válasz pontosabb lesz, a folyamat gyorsabb, és utólag is könnyebb ellenőrizni, mire épült a döntés. A kontextus válogatása tehát nem takarékossági kérdés, hanem közvetlenül a minőséget határozza meg.

Hosszú kontextus és a lényeg kiemelése

Egy hosszú ügyintézés során a beszélgetés folyamatosan hízik. Sok üzenet gyűlik össze, és egyre nagyobb az esély, hogy a fontos utasítás elvész a részletek között. Két eszközünk van erre. Az egyik a lényeg kiemelése. A legfontosabb instrukciókat a rendszerprompt elején és a kérdés közelében helyezzük el, mert ezekre a modell erősebben figyel, mint a hosszú szöveg közepére szoruló részekre. A másik a kontextus tömörítése. Amikor egy munkamenet elnyúlik, a régebbi fordulókat összefoglaljuk egy rövid, tömör kivonatba, és csak a friss, részletes részt tartjuk meg teljes hosszban. Így a beszélgetés lényege bent marad, a felesleges terjedelem viszont eltűnik, és nem szorít ki fontosabb tartalmat.

A RAG, friss külső tudás behúzása

A modell tudása két helyről jöhet. Az egyik a betanított tudás, ami a modellben van, de nem tartalmazza a cég belső dokumentumait, és egy idő után elavul. A másik a kontextusba behúzott friss tudás. A RAG, vagyis a kereséssel támogatott válaszadás pontosan ez utóbbit oldja meg. Ahelyett, hogy reménykednénk, a modell fejből tudja a választ, vagy beleraknánk az egész tudásbázist, egy külső, naprakész forrásban rákeresünk a kérdéshez tartozó részletre, és csak azt az egy darabot tesszük a kontextusba. A Tisza Biztosító asszisztense így mindig az érvényes szerződési feltételekkel dolgozik, nem egy régi, fejből felidézett változattal. A RAG a friss, céges és folyamatosan változó tudás behúzásának a bevált módja.

A megbízhatóság négy eleme

Eddig arról volt szó, mit lát a modell. A második nagy kérdés az, mi történik, amikor valami nem az elvárt módon fut le. Egy éles rendszerben ez nem kivétel, hanem mindennapos. Egy API-hívás időtúllépésbe fut, egy eszköz hibát ad vissza, a modell bizonytalan, vagy magabiztosan téveset állít. A megbízhatóság nem azt jelenti, hogy ezek soha nem történnek meg, hanem azt, hogy a rendszer számít rájuk és kezeli őket. A különbség egy törékeny és egy stabil rendszer között nem az, hogy az egyikben van hiba, a másikban nincs. A különbség az, hogy a stabil rendszer előre eltervezi, mit tesz, amikor a hiba bekövetkezik. Az alábbi négy elem együtt adja ezt a stabil működést.

A bizonytalanság és a guardrail a gyakorlatban

A modell bizonytalansága önmagában nem baj, a kezeletlen bizonytalanság az. A Tisza Biztosító asszisztensénél, ha a bejelentés nem egyértelmű, vagy a szerződés egy határesethez ér, sokkal jobb, ha visszakérdez vagy jelzi, hogy ezt egy ügyintézőnek kell eldöntenie, mint ha határozottan kimondana egy téves összeget. A guardrail ehhez ad kereteket. Ez az a védőkorlát, amely megszabja, mit tehet a modell magától, és mit nem. Egy kárkifizetést nem hagyunk jóvá emberi ellenőrzés nélkül, a kimenő üzenetet átnézzük, mielőtt kimegy, és a modell nem léphet ki a számára kijelölt körből. A megbízható rendszer nem hibátlan. Ismeri a gyenge pontjait, és úgy építi köréjük a korlátokat, hogy egy hiba ne válhasson kárrá.

Miért terjed tovább minden hiba

Az itteni hibáknak azért van akkora súlyuk, mert nem maradnak egy helyben. Ha az asszisztens rossz szerződést kap a kontextusba, akkor hiába kifogástalan az agentic vezénylés, hiába jó a prompt és az eszköz, minden további lépés egy hamis alapra épül. A vezénylés a rossz adatot dolgozza fel, az eszközök a rossz adatra hívódnak meg, a válasz pedig magabiztosan téves lesz. Egy retry sem segít, ha a bemenet maga hibás, mert az újrapróbálkozás ugyanazt a rossz kontextust futtatja le újra. Ezért kap ez a kis súlyú terület akkora figyelmet a gyakorlatban. A rossz kontextus és a kezeletlen hiba a rendszer aljáról indul, és felfelé haladva minden más tématerület munkáját beszennyezi.

Összegzés

A kontextuskezelés arról szól, hogy a modell a helyes információt lássa a helyes pillanatban. A kontextusablakba a rendszerpromptot, a releváns tudást és az aktuális beszélgetést tesszük, a zajt kihagyjuk, a hosszú munkameneteket pedig kiemeléssel és tömörítéssel tartjuk kézben. A friss, változó tudást a RAG húzza be. A megbízhatóság arról szól, hogy a rendszer túlélje a hibákat. Ehhez hibakezelés, retry, a bizonytalanság kezelése és a guardrailek kellenek. A megbízható rendszer nem hibátlan, hanem ismeri és kezeli a gyenge pontjait. És mert ez a réteg tartja az összes többit, egy itteni hiba mindenhová továbbterjed. A következő leckében a Claude API gyakorlati alapjaira lépünk át.