Dinamikus eszközfüggés-kezelés: gyorsabb AI döntések

A legtöbb AI-alapú „ügynök” ott vérzik el, ahol a felhasználó már nem lát rá: túl sok eszközt adunk a modell kezébe, rossz sorrendben, rossz pillanatban. Egy kiskereskedelmi chatbot, egy e-kereskedelmi kereső, vagy egy egészségügyi triázsrendszer ilyenkor ugyanazt csinálja: kinyit egy túlzsúfolt szerszámosládát, aztán bizonytalanul matat benne. Ebből lesz a lassú válaszidő, a felesleges API-hívás, és a „majdnem jó” döntés.

A 2025.12.22-én frissen publikált kutatás (arXiv:2512.17052) erre egy nagyon gyakorlatias választ ad: Dynamic Tool Dependency Retrieval (DTDR), vagyis dinamikus eszközfüggés-visszakeresés. A lényeg: ne csak a kezdeti kérdés alapján válasszunk eszközöket (mint a statikus retrieverek), hanem az éppen futó végrehajtás állapota alapján is, lépésről lépésre. A szerzők mérései szerint a dinamikus megközelítés 23%–104% közötti javulást hozott a funkcióhívások sikerességében több adathalmazon és több LLM-backbone-on.

És hogy jön ez a „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” sorozathoz, illetve az egészségügyi kampányunkhoz? Úgy, hogy ugyanaz a probléma jelenik meg mindkét területen: a valós idejű döntésekhez nem elég okosnak lenni. Gyorsnak és megbízhatónak is kell lenni.

Miért rossz a statikus eszközválasztás a valós rendszerekben?

Válasz elsőre: a statikus eszköz-retrieval azért bukik meg, mert a feladat kontextusa menet közben változik, miközben az eszközlista nem alkalmazkodik.

A legtöbb funkcióhívásos (function calling) ügynök úgy indul, hogy a felhasználó kérdéséből kiválaszt néhány releváns toolt (API-kat, függvényeket), majd ezek leírását beteszi a promptba. Ez papíron jó: rövidebb kontextus, kevesebb zavaró információ.

A gond az, hogy a való életben a feladat többlépéses:

• Egy e-kereskedelmi ügyfélszolgálati kérdésnél előbb rendelést kell azonosítani, aztán szállítási státuszt lekérni, majd kompenzációt ajánlani.
• Egy kiskereskedelmi készletoptimalizálásnál előbb értékesítési adatot aggregálunk, aztán promóciós naptárt és beszállítói lead time-ot veszünk hozzá, végül rendelési javaslatot generálunk.
• Egészségügyben egy triázs-ügynök előbb tüneteket strukturál, aztán rizikófaktorokat kérdez, majd döntési protokollt futtat és időpontot foglal.

A statikus retriever nem látja, hogy a 2. vagy 3. lépésben épp hol tartunk. Így két rossz dolog történik:

1. Irreleváns eszközök kerülnek be (zaj a promptban), ami félreviheti a modellt.
2. Hiányoznak a „következő lépéshez” szükséges eszközök, mert az elején még nem látszottak.

Ez különösen fájdalmas ott, ahol számít a milliszekundum és a pontosság: valós idejű ajánlórendszerek, pénztári csalásdetektálás, vagy egészségügyben képalkotó előszűrés.

DTDR röviden: eszközök, amik a végrehajtással együtt „érnek be”

Válasz elsőre: a DTDR úgy javítja a function calling ügynököket, hogy az eszközök kiválasztását nem egyszer, hanem többször végzi el, és közben figyelembe veszi az aktuális végrehajtási kontextust.

A cikk központi állítása egyszerű és erős: a toolválasztásnak dinamikusnak kell lennie. Nem elég a kezdeti felhasználói kérdés. Kell az is, hogy mi történt eddig:

• milyen függvényt hívtunk meg,
• mi volt a válasz,
• milyen rész-eredmények jöttek,
• milyen terv bontakozik ki.

A DTDR ezt a „futó kontextust” használja, és eszközfüggőségeket is modellez: ha egy lépésnél tipikusan egy másik eszköz következik, akkor azt nagyobb eséllyel fogja előhívni a rendszer.

Snippet-kompatibilis állítás: A DTDR nem csak releváns eszközt keres, hanem a következő lépéshez releváns eszközt keresi.

A tanulmány szerint a dinamikus eszközretrieval a funkcióhívások sikerességét 23%–104% között javította a statikus retrieverekhez képest. Ez nem „szép plusz”, hanem gyakran a különbség aközött, hogy egy ügynök használható-e élesben.

Kiskereskedelem és e-kereskedelem: hol hoz azonnali ROI-t a dinamikus tool retrieval?

Válasz elsőre: ott, ahol a feladat több rendszeren megy keresztül (CRM, ERP, webshop motor, logisztika), és a következő lépés csak az előző válaszból derül ki.

1) Ügyfélszolgálati automatizálás: kevesebb félrehívás, rövidebb válaszidő

Egy tipikus e-kereskedelmi jegy:

• „Nem érkezett meg a csomagom, és ajándék lenne karácsonyra.”

Itt a rendszernek sorban kell:

1. azonosítani a rendelést,
2. lekérni a trackinget,
3. megnézni a futárszolgálat SLA-ját,
4. kompenzációs szabályt alkalmazni,
5. ha kell, újraküldést indítani.

Statikus retrieverrel gyakori, hogy már az elején betesz 10–15 toolt, köztük olyat is, ami nem kell (például számlázási reklamáció). DTDR szemlélettel az ügynök az első lépésnél csak az azonosításhoz szükséges eszközöket kapja, majd a tracking válasz után célzottan jönnek a következő függvények.

A gyakorlati hatás:

• kevesebb prompt-zaj,
• kevesebb rossz API-hívás,
• stabilabb folyamat a csúcsidőszakban (decemberben ez konkrét túlélési kérdés).

2) Készletkezelés és kereslet-előrejelzés: függőségek kezelése a valóság szerint

A készletoptimalizálás nem egyetlen modellkimenet. Függ attól, hogy:

• milyen promóció fut,
• milyen beszállítói késések vannak,
• van-e alternatív termék,
• milyen a regionális kereslet.

Dinamikus eszközretrieval akkor hasznos, amikor a rendszer a következő kérdést a részadatokból tudja megfogalmazni. Például ha a beszállító lead time-ja váratlanul nőtt, akkor a „rendelési javaslat” előtt automatikusan előrébb kerül a „helyettesítő SKU-k” eszköze, vagy a „regionális átcsoportosítás” modul.

3) Személyre szabott ajánlórendszerek: kontextusfüggő adatlekérés

Sokan túl hamar akarnak „mindent” betolni a modellnek: kosáradat, böngészés, korábbi vásárlások, készlet, ár, kedvezmények. A valóságban a releváns jelzések sessionenként változnak.

• Ha valaki ajándékot keres, más attribútumok számítanak.
• Ha valaki új vásárló, a hidegindítás a szűk keresztmetszet.

A DTDR logika itt abban segít, hogy ne minden adatforrást kérjünk le automatikusan, hanem csak azt, ami a pillanatnyi „mini-tervhez” kell.

Egészségügyi párhuzam: miért életbevágó a függőségkezelés?

Válasz elsőre: mert egészségügyben a rossz eszköz vagy rossz sorrend nem csak költség, hanem kockázat is.

A kampányunk („Mesterséges intelligencia az egészségügyben”) szempontjából a DTDR üzenete nagyon tiszta: a megbízhatóság nem csak a modellben van, hanem az eszközláncban is.

Valós idejű képalkotás és diagnosztikai támogatás

Egy radiológiai előszűrő rendszer lépései:

1. DICOM betöltés és normalizálás,
2. minőségellenőrzés (artifact, mozgás),
3. modell-inferálás (pl. vérzés gyanú),
4. priorizálás a munkalistán,
5. riasztás / dokumentálás.

Ha a rendszer statikusan minden eszközt „odadob”, több a téves eszközválasztás és nő a késleltetés. Dinamikus retrievalnél a workflow természetes függőségei érvényesülnek: előbb minőségellenőrzés, csak utána inferálás, és ha a minőség gyenge, akkor más útvonal.

Kórházi workflow-ügynökök: protokollok, jogosultságok, naplózás

A kórházi folyamatokban a „tool” sokszor nem csak API, hanem szabály: jogosultság, naplózási kötelezettség, protokoll-lépések. A függőségek kezelése itt azt jelenti, hogy a rendszer nem ugorhat át lépéseket. A DTDR-szemléletű rendszerekben a kontextus alapján előjönnek azok az eszközök, amelyek biztosítják a megfelelést (audit log, consent ellenőrzés), nem pedig „opcionális extraként” szerepelnek.

Ezt szoktam a csapatoknak mondani: egy életkritikus ügynökben a sorrend nem UX-kérdés, hanem biztonsági követelmény.

Hogyan építsd be a DTDR gondolkodást egy termékbe? (Gyakorlati lépések)

Válasz elsőre: a dinamikus tool retrieval bevezetéséhez nem kell mindent újraírni, de kell egy tiszta eszközkatalógus, logolt demók és kontextus-alapú újrarankelés.

1) Eszközkatalógus rendbetétele (igen, ez a legunalmasabb rész)

Ha az eszközleírások pontatlanok, a legjobb retriever is szenved. Minimum:

• egyértelmű név és cél,
• bemenet/kimenet minta,
• hibakódok és tipikus edge case-ek,
• jogosultsági feltételek.

2) „Demók” gyűjtése: mi következik mi után?

A DTDR egyik kulcsa, hogy függőségeket tanul a funkcióhívási demonstrációkból. A gyakorlatban ez lehet:

• ember által vezetett „arany út” (golden path) log,
• sikeres automatikus futások,
• gondosan címkézett hibás esetek (nagyon értékesek).

3) Dinamikus újraválasztás lépésenként

Ne egyetlen retrieval legyen a folyamat elején. Legyen:

1. retrieval az induláskor,
2. retrieval minden nagyobb tool-válasz után,
3. retrieval hibaágakon külön (pl. timeout, hiányos adat).

4) Prompt-integráció: kevesebb, de pontosabb tool a kontextusban

A tanulmány külön vizsgálja, hogyan érdemes a visszakeresett eszközöket promptba tenni. Termékoldalon én ezt tartom működőnek:

• 3–8 eszköz egy lépésben,
• rövidített, feladat-specifikus leírások,
• a „miért most ezt az eszközt” jellegű kontextus rövid indoklása.

5) Mérőszámok, amiket tényleg nézz

Ha leadeket és üzleti eredményt akarsz, ne csak „pontosságot” mérj.

• Tool selection precision (mennyi a felesleges tool?)
• Function calling success rate (végigmegy-e?)
• Átlagos lépésszám (nem csúszik-e el a terv?)
• Késleltetés és költség (API-hívások száma, tokenek)
• Hibajavítási ráta (mennyit „kapar vissza” az ügynök)

Mit jelent ez a sorozatunk szempontjából?

A „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” témában sokszor az ajánlások, kereslet-előrejelzés és készletkezelés kerül fókuszba. Én azt látom, hogy 2026 felé haladva a versenyelőny egyre inkább a rendszerszintű hatékonyságon múlik: mennyire jól tud az AI ügynök együtt dolgozni a vállalati eszközökkel.

A DTDR üzenete pedig átvihető az egészségügyi vonalra is: ha diagnosztikai vagy workflow AI-t építesz, a modell „IQ-ja” csak az egyik fele a történetnek. A másik fele az, hogy mikor, melyik eszközt, milyen függőségek szerint engeded a kezébe.

Ha most tervezel AI-ügynököt ügyfélszolgálatra, készletoptimalizálásra, vagy akár egészségügyi döntéstámogatásra, a következő lépés nagyon konkrét: térképezd fel a tool-láncodat, logold a sikeres futásokat, és kezdd el a retrievalt dinamikusan kezelni. A kérdés csak az, hogy a te rendszeredben hol a legdrágább a rossz eszköz a rossz időben?