A mechanizmus: ki csinálja mit?
Négy lépés, és a harmadik a lényeg.
1. A fejlesztő leírja az eszközt. Három mező: név, leírás és bemeneti séma JSON Schema formában. A leírás nem dokumentáció a csapatnak — ez a modellegyetlen támpontja arra, mikor használja az eszközt.
2. A modell kitölti az űrlapot. A válaszban nem szöveg jön, hanem egy eszközhívás-blokk: melyik eszközt kéri, milyen argumentumokkal, és egy azonosítóval, amivel majd párosítani lehet az eredményt. A válasz leállási oka is átvált „eszközhasználatra".
3. A te kódod hajtja végre. A gyártói dokumentáció szó szerint így fogalmaz: a kliensoldali eszközök a te alkalmazásodban futnak — a modell válaszol az eszközhívás-blokkal, a te kódod végzi a műveletet, és küldi vissza az eredményt.
Van egy kivétel: a szerveroldali eszközök — webes keresés, weblekérés, kódfuttatás — a szolgáltató infrastruktúráján futnak, ott te nem hajtasz végre semmit, csak megkapod az eredményt.
4. Az eredmény visszamegy a beszélgetésbe. Egy eredményblokként, az eredeti hívás azonosítójával párosítva. A modell innen folytatja.
Ebből következik az agentek legfontosabb költségtétele: egy eszközhívás két modellhívást jelent. Egyet előtte, egyet utána.
Hol romlik el?
Van egy egyetemi ranglista, ami kifejezetten a függvényhívást méri, és a verziótörténete többet mond, mint a pillanatnyi sorrend: egyszerű hívás → élő adat → többkörös és többlépéses hívás → agentikus kiértékelés.
Négy hibamintázat, mérve, egy száz többlépcsős kérdésből álló feladatkészleten:
| Hibamintázat | Mit csinál a modell |
|---|---|
| Eszközkerülés | van keresője, mégis a saját tudásából válaszol — elavult vagy hiányos eredménnyel |
| Hibás feltevés | feltételezi, hogy egy esemény még nem történt meg, ezért el sem indítja a keresést |
| Rossz felbontás | nem bontja lépésekre a többlépcsős kérdést, hanem egyetlen mindent átfogó kereséssel próbálkozik |
| Félreolvasás | megtalálja a helyes oldalt, és rosszul értelmezi a tartalmát |
Ugyanezen a mérésen egy mellékmegállapítás: eszközhasználat nélkül a pontosság drámaian esik. Vagyis az eszköz nagyon sokat ér — de a fenti négy hiba mind azzal történik, akinek van eszköze.
És egy nem triviális lelet, ami sokakat meglep. Ugyanez a ranglista külön mérte a formátumérzékenységet 39 modellen: ugyanaz az eszköz, ugyanaz a modell, csak a dokumentáció formátuma más.
- A függvénydokumentáció formátumában következetes trend majdnem minden modellnél: a JSON a legjobb, az XML gyengébb, a Python a legrosszabb.
- A visszatérési formátumnál a Python és a JSON jobb, mint bármelyik XML-változat — és a kisebb modellek érzékenyebbek rá.
- Az eszközhívás-címkék nélkül a modellek valamivel jobban teljesítenek, mint velük.
- A promptformátumára és stílusára viszont a modellek nagyjából érzéketlenek.
A szélsőségek beszédesek: volt olyan tesztelt modell, aminek a teljesítménye nullához közelivé vált pusztán attól, hogy JSON-formátumot követeltek meg tőle, és egy másik ugyanígy járt az eszközhívás-címkékkel.
A gyakorlati tanulság: ha nem megy, előbb a formátumot próbáld cserélni, csak utána a modellt.
Hány eszköz fér egy promptba?
Erre két gyártó két különböző számot mond, és egyikhez sincs közölt módszertan.
| Forrás | Ajánlás | Jelleg |
|---|---|---|
| Az egyik gyártó | 20 alatt egy kör elején | „laza javaslat", indoklás nélkül |
| A másik | 30–50 fölött romlik a választás | állítás, mérési adat nélkül |
Amihez viszont van konkrét szám: egy több szervert összekötő tipikus beállítás nagyjából 55 ezer tokent fogyaszt pusztán az eszközdefiníciókkal, mielőtt a modell bármit csinálna. Az eszközkereső megoldás ezt a gyártó szerint 85%-nál nagyobb mértékben csökkenti, mert csak a kérdéshez tartozó 3–5 eszközt tölti be.
Egy még élesebb szám ugyaninnen, kódfuttatásos megközelítéssel: 150 ezer tokenről 2 ezerre — 98,7%-os megtakarítás.
De a kérdésre, hogy hol van pontosan a törés, nincs független mérés. Amit tudunk: több kontextus mérhetően megbízhatatlanabb kimenetet ad — de ezt egyik vizsgálat sem az eszközszám függvényében mérte. Ez egy valódi, nyitott kérdés.
A gyakorlatban ebből egy szabály következik: ne az legyen a kérdés, hány eszközt tudsz bekötni, hanem hogy hányat lát a modell egy adott kérésnél.
Amit nem garantálnak
Három dolog, amit a dokumentáció kifejezetten nem ígér.
Nem tudod, hány hívás jön. Az egyik gyártó szó szerint azt írja, hogy a válasz nulla, egy vagy több hívást is tartalmazhat, és a legjobb, ha a kódod mindegyikre felkészül. A párhuzamos hívás alapból engedélyezett, de kikapcsolható.
A séma-megfelelés nem tartalmi helyesség. Van olyan mód, ami kikényszeríti, hogy a hívás megfeleljen a sémának. Ez hasznos — de nem garantálja, hogy a modell a helyes eszközt vagy a helyes értékeket választotta. A fenti négy hibamintázat mind sémahelyes, tartalmilag hibás hívás.
A hibát vissza kell írni a beszélgetésbe. Az eredményblokkon van külön hibajelző mező — a modell abból tanul a következő lépésre. Ha csak eldobod a hibát, a modell nem tudja, hogy elrontotta. Egy éles agentben ehhez ott a védelem is: három egymás utáni formátumhiba után leáll a futás.
Mennyivel drágább egy eszközhívásos kör?
Két tétel jön hozzá, mielőtt bármit csinálnál.
Az első a rendszerprompt felára. Az eszközhasználat engedélyezése automatikusan hozzátesz egy rendszerpromptot, aminek a mérete modellenként közölt adat — a mai modelleknél nagyjából 280 és 590 token között, attól függően, hogy szabadon választhat-e a modell, vagy kötelezően eszközt kell hívnia. Ez még az eszközdefiníciók előtt jelentkezik.
A második maguk a definíciók. Bemeneti tokenként számláznak, minden hívásnál.
Saját számítás. Vegyünk egy közepes árfekvésű modellt ($2 / millió bemeneti token, $10 / millió kimeneti), és hasonlítsunk össze két esetet:
| Sima válasz | Egy eszközhívásos kör | |
|---|---|---|
| Modellhívások száma | 1 | 2 |
| Bemeneti token összesen | 500 | 2 688 |
| Kimeneti token összesen | 150 | 230 |
| Költség | $0,0025 | $0,0077 |
A szorzó: 3,07×. Ezer körnél ez 2,50 dollár helyett 7,68.
(Saját számítás. A rendszerprompt-felár mért, gyártói adat; az eszközdefiníció és az eszközeredmény mérete saját becslés, és a valóságban nagy a szórásuk. A számítás nem tartalmaz prompt cache-t.)
Két dolog, ami ezt módosítja.
Felfelé: N eszközhívásnál N+1 modellhívás van, és minden hívás a teljes addigi előzményt viszi. A szorzó tehát nem áll meg háromnál — hosszú futásnál tovább romlik.
Lefelé: a prompt cache a legfontosabb optimalizáció. Cache-találatnál a bemeneti token tizedáron megy — és mivel a második hívás bemenetének nagy része szó szerint ugyanaz, mint az elsőé, pont ott üt, ahol a legtöbbet számít.
Kereszthivatkozás a saját számításhoz: az egyik gyártó saját mérése szerint az agentek nagyjából négyszer annyi tokent fogyasztanak, mint egy beszélgetés. A 3,07× egyetlen hívásra vonatkozik, és jól illeszkedik ehhez a nagyságrendhez — a két szám független úton jött.
Tipikus félreértések
- „A modell meghívja az API-t." Nem. Kitölti az űrlapot, a hívást a te kódod végzi. A kivétel a szolgáltatónál futó szerveroldali eszköz.
- „Ha a séma szigorú, a hívás helyes lesz." A séma a formát kényszeríti ki, nem a tartalmat. A mért hibák túlnyomó része sémahelyes.
- „Az eszköz leírása dokumentáció." Az eszköz leírása prompt. Ez az egyetlen dolog, amiből a modell eldönti, mikor használja.
- „Bekötök mindent, majd válogat." Egy több szervert összekötő beállítás 55 ezer tokent vihet el pusztán a definíciókkal, munkavégzés előtt. Nem a bekötött, hanem a látható eszközök száma számít.
- „Mindig egy hívás jön vissza." Nulla, egy vagy több. A kódnak mindegyikre fel kell készülnie.
- „Csak a modell számít." Ugyanaz a modell más dokumentációformátummal mérhetően más találati arányt ad — a JSON következetesen jobb, mint az XML vagy a Python.
Amit érdemes elvinni
A function calling nem hívás, hanem javaslat. A modell megmondja, mit szeretne; a végrehajtás, a hibakezelés és a jogosultság a te oldaladon marad. Ez jó hír: itt tudsz beavatkozni.
A három dolog, ami a gyakorlatban a legtöbbet javítja: jó eszközleírás (mert az a prompt), JSON-formátum (mert azon mérhetően jobbak a modellek), és prompt cache (mert az eszközhívásos kör bemenetének nagy része ismétlődik).
Hogy ebből hogyan lesz teljes agent-ciklus, arról mit tesz egy agent lépésenként poszt szól végigvezetve; a szabványról pedig, amivel az eszközöket ma be szokás kötni, az MCP poszt ad áttekintést.