Dinamikus eszközretrieval: gyorsabb AI döntések

A legtöbb vállalat ott veszít időt és pénzt az AI-projektekben, ahol elsőre nem is keresné: nem a modell „okossága” a szűk keresztmetszet, hanem az, hogy a modell milyen eszközökhöz fér hozzá, és mikor. Ha egy LLM-alapú ügynök rossz eszközt választ, vagy túl sok irreleváns „szerszámot” kap a kezébe, a végeredmény általában ugyanaz: hosszabb futásidő, drágább működés, több hiba.

A 2025.12.22-én frissen megjelent DTDR (Dynamic Tool Dependency Retrieval) megközelítés pont ezt a fájó pontot célozza: az eszközök kiválasztását nem egyszer, a kérdés elején dönti el, hanem a végrehajtás közben, a kontextus alakulásával együtt frissíti. A tanulmány szerint ez a dinamikus eszközretrieval a funkcióhívásos feladatok sikerességét 23% és 104% között javítja a statikus retrieverekhez képest.

Ez a cikk a „Mesterséges intelligencia a kiskereskedelemben és e-kereskedelemben” sorozat része, de szándékosan áthúzunk egy erős párhuzamot az egészségügy felé is: a „tool dependency” valójában ugyanaz a probléma, mint amikor egy klinikai döntéstámogató rendszernek több lépésben kell labort, képalkotót, gyógyszer-interakció ellenőrzést és protokollokat összehangolnia. A lényeg: az AI akkor lesz gyors és megbízható, ha okosan választ eszközt — lépésről lépésre.

Miért bukik el a tool selection a valós folyamatokban?

Válasz röviden: mert a valós feladatok több lépésből állnak, és a következő lépés eszközigénye gyakran csak az előző lépés eredményéből derül ki.

A statikus eszközretrieval tipikusan úgy működik, hogy a rendszer az induló kérdés (pl. „készíts heti készlet-előrejelzést”) alapján behúz egy eszközlistát: idősor-előrejelző, készletmodul, jelentésgenerátor, esetleg ároptimalizáló. Csakhogy a feladat menete közben új információk kerülnek elő:

• hiányosak az adatok (kell adatminőség-ellenőrző),
• van egy kiugró promóció (kell kampány-naptár integráció),
• régiós eltérés van (kell bolt-szintű szegmentálás),
• beszállítói lead time változott (kell beszerzési modul).

Ha az ügynök eleve túl sok eszközt kap, nő a zaj. Ha túl keveset, akkor „vak” marad. A DTDR állítása az, hogy a retrievalt a végrehajtási kontextusra kell kondicionálni, nem csak az induló kérdésre.

A kiskereskedelmi és e-kereskedelmi analógia: kosárérték vs. útvonal

E-kereskedelemben sokszor a cél metrika (pl. kosárérték növelés) ismert, de az útvonal nem. Az ajánlórendszernek lehet, hogy először méretproblémát kell kezelnie (return risk), utána szállítási opciót, végül csomagajánlatot. A releváns „eszköz” lépésenként változik.

Egészségügyi párhuzam: diagnosztika több lépésben

Egy klinikai döntéstámogató agent kezdeti kérdése lehet: „milyen vizsgálatok indokoltak mellkasi fájdalomnál?”. A következő lépés viszont már attól függ, mi jön vissza EKG-ból, troponinból, anamnézisből. Ha a rendszer statikusan „mindent” betölt (összes protokoll, összes gyógyszeradatbázis, összes képalkotó irányelv), az lassú és hibaérzékeny.

Mit hoz újat a DTDR a funkcióhívásos ügynökökben?

Válasz röviden: a DTDR az eszközök közti függőségeket a demonstrációkból tanulja, és a retrievalt menet közben frissíti az aktuális végrehajtási állapot alapján.

A kutatás kiindulópontja egyszerű, de erős: a tool calling ügynökök nem csak „eszközt választanak”, hanem eszközláncokat futtatnak. Például:

1. lekérdezés egy adatforrásból
2. normalizálás / validáció
3. számítás / döntési szabály
4. riport vagy API-hívás

A statikus retriever gyakran az 1. lépéshez passzoló eszközöket hozza, de a 2–4. lépéshez szükségeseket nem, vagy épp ellenkezőleg: túl sok, félrevezető opciót ad.

A DTDR két kulcsötlete:

• Evolving execution context: nem csak a kezdeti prompt számít, hanem az is, hol tart a terv, milyen eredmények születtek, milyen hibák jöttek elő.
• Tool dependency model: demonstrációkból (function calling példákból) megtanulható, hogy bizonyos eszközhívások után tipikusan mely eszközök következnek.

A paper által közölt eredmény, ami a vezetőknek is jól érthető: 23–104% közötti javulás a funkcióhívás sikerességében a statikus módszerekhez képest. Ez nagy szórás, de a trend világos: minél összetettebb a több lépéses függőség, annál többet hoz a dinamika.

Hogyan néz ki ez egy kiskereskedelmi AI-ügynökben a gyakorlatban?

Válasz röviden: úgy, hogy a rendszer nem „eszköztárat” ad az LLM-nek, hanem aktuális, kisméretű eszközkészletet minden lépésben.

Vegyünk egy tipikus omnichannel feladatot 2025 decemberében (karácsony utáni készletkorrekciók, visszáru, akciók kifutása):

Példa: készletoptimalizálás promóciók után

Kezdő kérés: „Számold újra a jövő heti készletszinteket, és jelezd a kockázatos SKU-kat.”

• 1. lépés: értékesítési és készletadatok lekérése
  • releváns eszközök: adatlekérdezők, jogosultságkezelés
• 2. lépés: adattisztítás (hiányzó készletmozgások, duplikált rendelések)
  • releváns eszközök: adatminőség-ellenőrző, anomália-detektor
• 3. lépés: promócióhatás leválasztása (baseline vs. uplift)
  • releváns eszközök: promóció-naptár integráció, kauzális becslő modul
• 4. lépés: beszállítói késések figyelembevétele
  • releváns eszközök: beszerzési lead time API, beszállítói score
• 5. lépés: döntés és kommunikáció
  • releváns eszközök: riasztásküldő, dashboard frissítő

A DTDR-szemléletben a retriever minden lépésnél újraértékeli, mely eszközök a következők. Ettől két dolog történik:

1. Rövidebb prompt és kisebb kontextus: nem kell 40 eszköz leírását beégetni, elég 6–10 releváns.
2. Kevesebb félrehívás: az ügynök ritkábban választ „hasonló nevű, de rossz” funkciót.

Mit jelent ez az egészségügyi workflow-kban (és miért érdekelje a retail vezetőket is)?

Válasz röviden: az egészségügy a „valódi” multi-step függőségek terepe, ezért ott gyorsan kiderül, hogy a statikus eszközlista zsákutca.

Egy egészségügyi AI-rendszerben a tool dependency tipikusan ilyen:

• tünet → triage protokoll
• protokoll → vizsgálatkérés
• lelet → kockázati pontszám
• pontszám → gyógyszer-interakció ellenőrzés
• döntés → dokumentáció / EESZT-kompatibilis export (belső rendszerekben)

Ha az ügynök a kezdeti kérdés alapján „mindenhez is” hozzáfér, nő a hibázás esélye és a validációs teher. Ha viszont dinamikusan, a leletek és döntési pontok alapján kapja a következő eszközöket, az auditálhatóbb és biztonságosabb.

Retailben ugyanígy: a dinamikus eszközretrieval nem csak gyorsít, hanem segít abban is, hogy a rendszer működése visszakövethetőbb legyen („miért azt a modult hívta?”).

Snippet, amit érdemes megjegyezni: A jó ügynök nem attól okos, hogy sok eszközt lát, hanem attól, hogy mindig a következőt látja.

Hogyan vezesd be: 5 gyakorlati lépés DTDR-szerű működéshez

Válasz röviden: a legnagyobb nyereséghez nem kell mindent újraépíteni; elég a retrievalt „állapotossá” tenni és a függőségeket logolni.

1. Instrumentáld a tool callingot

   • Mentsd el minden lépésnél: kérés, kiválasztott eszköz, paraméterek, kimenet, hiba.
   • Ez lesz a demonstrációs alap a függőségek tanulásához.

2. Vezess be végrehajtási állapotot (execution state)

   • Például: stage=data_fetch, stage=validation, stage=forecasting.
   • A retrieval lekérdezése kapja meg ezt is, ne csak a nyers felhasználói kérést.

3. Rangsorolj függőség alapján, ne csak szöveghasonlósággal

   • A statikus embedding-keresés sokszor „név alapján” talál.
   • A függőségi jel (mi jött tipikusan ez után) gyakran jobb prediktor.

4. Korlátozd a választható eszközök számát lépésenként

   • Tapasztalatom szerint már az is látványos javulást ad, ha 30–50 helyett 8–12 eszköz marad egy lépésben.

5. Prompt-stratégia: ne öntsd rá az eszközleírásokat

   • A DTDR paper külön vizsgálja, hogyan érdemes a retrievelt eszközöket promptba tenni.
   • Gyakorlati szabály: rövid, egységes sémában add át az eszközöket (név + 1 mondat + paraméterek).

Gyors ellenőrzőlista vezetőknek (ROI szemmel)

• Csökkent-e a futtatások átlagos tokenhasználata?
• Nőtt-e a „first pass success rate” (újrapróbálkozás nélkül)?
• Csökkent-e a hibás tool hívások aránya?
• Rövidebb-e a teljes átfutási idő (end-to-end latency)?

Ha ezekből kettő javul, már érdemes tovább mélyíteni.

Gyakori kérdések (amit a csapatod biztosan feltesz)

„Ez csak nagy cégeknek való?”

Nem. A dinamika lényege nem a méret, hanem a folyamat több lépésessége. Egy 20 fős webáruház is fut multi-step folyamatokat (rendelés → fizetés → számlázás → logisztika → ügyfélszolgálat).

„Nem lesz bonyolultabb a rendszer?”

A retrieval réteg igen, kicsit. Cserébe az ügynök viselkedése egyszerűbb és kiszámíthatóbb lesz, mert kevesebb opció közül választ.

„Mi a minimum, amit holnap meg tudok csinálni?”

Logolás + lépéscímkézés + top-k korlátozás. Már ez közelebb visz a DTDR hatásához.

Merre tart ez 2026-ban a kiskereskedelemben?

A dinamikus eszközretrieval szerintem 2026-ban ugyanaz lesz az ügynökös rendszerekben, mint a jó készletgazdálkodás a retailben: nem látványos a kirakatban, de minden ezen múlik. Ha a tool selection rossz, hiába jó az ajánlórendszered, a kereslet-előrejelzésed vagy a kampányoptimalizálásod.

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. A DTDR üzenete ehhez passzol: a jó AI nem csak prediktál, hanem jól szervezi a munkát is.

Ha a csapatod agenteket épít ügyfélszolgálatra, rendeléskezelésre, készletoptimalizálásra vagy akár egészségügyi jellegű döntéstámogatásra (pl. gyógyszertári e-kereskedelem, OTC ajánlások), akkor a következő kérdést érdemes feltenni: a rendszeretek az induló kérdésből választ eszközt, vagy a folyamat közben is tanulja, mi kell a következő lépéshez?