Több lépéses RAG-ek és más agentikus rendszerek működtetése kapcsán az egyik fő fájdalompont az észrevétlenül növekvő LLM-költségek. Az interaktív módon, chatfelületen keresztül használt modellek esetében az elhasznált input- és outputtokenek nagyságrendje általában jól követhető, de a különféle külső erőforrásokat, API-kat önállóan hívogató agentikus rendszereknél sokszor csak utólag szembesülünk a nagy számlákkal – arról nem is szólva, hogy az anyagiakon kívül hosszabb távon több egyéb probléma is keletlezik (infrastrukturális-tárhelyes korlátok, lassú látencia, pontatlanabb válaszok). Nézzük meg, milyen okok vezethetnek a jelenséghez és hogyan tudjuk ezeknek előzetesen korlátokat szabni.

Kontextus halmozódása

LLM-ekkel kapcsolatos munkánál kontextusnak nevezzük az előzetes működés során keletkező outputokat, amelyek a logikailag következő további lépésekhez egyúttal inputként is szolgálnak. Agentikus működésnél az egymás után ismétlődő lépéseknél alapértelmezetten minden korábbi üzenet bekerül minden következő lépésbe a friss outputokkal együtt, tehát a modell többször is látja ugyanazt a részkontextust. Feltételezve mondjuk egy tíz lépéses folyamatot, a tizedik lépésnél a model kilenc már ismert előzményt újra megkap, ami nyilvánvaló redundancia. Ez természetesen régóta ismert jelenség, így vannak is már rá megoldások, legismertebb a kontextustömörítés (context compaction), amely minden lépésnél próbál sűríteni az addigi (halmozott) kontextuson valahogy (erre különféle logikák léteznek). A megoldás hátránya, hogy nehéz meghatározni a tömörítés kívánt mennyiségét, ellenőrizni a minőségét, emiatt előfordulhat “túltömörítés”, azaz érdemi információ elvesztése. Akkor javasolt alkalmazni, ha legalább öt lépéses folyamattal vagy jelentős méretű kontextussal dolgozunk.

Limitálatlan eszközhíváskísérletek

Ha a modell egy külső eszközt akar meghívni és hibával (pl. 400-as kivétellel) szembesül, akkor a hibaüzenetet hozzáteszi a kontextushoz, és valamilyen korrekció után újra kísérletezik a hívással. Azon kívül, hogy így a kontextus minden sikertelen hívás után redundás módon növekszik, külön probléma, hogy tartós hiba esetén értelmetlen hívások sorozatának eredményeképpen feleslegesen nagy költséggel szembesülünk. A probléma megoldása többféle lehet: vagy kiszűrjük az ismétlődő hibaüzenetet a kontextusból, vagy valamilyen előre meghatározott limitet állítunk be a megkísérelt hívások számára nézve, esetleg valamilyen késleltetés (is) beépítünk. Célszerű alkalmazni minden külső API-hívás esetén.

Limitálatlan payload

Jellemző alaphiba, hogy az eszközhívások kapcsán kontroll nélkül a kontextushoz csapjuk az adott eszközök nyers kimenetelét, amelyek nagy része nem bír hasznos információértékkel. Itt megoldás lehet, ha pl. a JSON-válaszokat valahogy parsolni próbáljuk, és csak a konkrét (validált, kulcs-érték pár formájú) tényleges értékeket visszük tovább. Probléma lehet ezzal a módszerrel, hogy hiányzó kinyert adatok esetén a modellünk esetleg hajlamos lehet hallucináció útján értékeket kitalálni. Javasolt mindenféle nem-strukturált választ nyújtó rendszerhez való kapcsolódás esetén.

Szofisztikált modellválasztás

Nem csak a kontextus áramvonalasításával tudunk takarékoskodni. Alapvető gyakorlatként az ágensek sokszor egyetlen (értelemszerűen a legjobb képességű, így legdrágább) modellel kommunikálnak, ez a differenciálatlan működés azonban a sok esetben pazarlás, hiszen JSON-formázáskor, egyszerűbb klasszifikációnál, sémavalidálásnál olcsóbb, akár lokális modellek is bőségesen elegendőek. Nagy forgalmú folyamatoknál célszerű mindenképpen megfontolni ilyen router-megoldás beépítését a gráfba, ami persze egyúttal növeli a megoldás komplexitását, az orkesztrációs overheadet.

Promptduplikáció

Legáltalánosabb, ugyanakkor legegyszerűbben orvosolható pazarlás a statikus rendszerprompt ismételt hozzáadása a kontextushoz eszközfüggetlenül. Erre megoldás lehet különböző eszközökhöz speciálisan egyedi, kis terjedelmű promptok előállítása az adott aktuális lépéshez szükséges módon. Különösen indokolt nagy számú (legalább húsz) felhasznált különböző eszköz esetében. Hátrány, hogy az ilyen módon dinamikusan előállított kontextusszövegek nagyobb lehetőséget biztosítanak promptinjekciós támadásokra.