Egy alábecsült, de fontos terület
Ezt a tématerületet sokan átugorják, mert technikainak és másodlagosnak érzik a prompthoz vagy az architektúrához képest. A vizsgán a súlya mégis jelentős, a nyilvános tématerületek szerint körülbelül tizennyolc százalék, és a gyakorlatban is itt dől el, hogy a modell tényleg végez-e valódi munkát, vagy csak beszél róla. Egy jól megtervezett eszközkészlet a különbség aközött, hogy a modell megbízhatóan lekéri a szükséges adatot és elvégzi a műveletet, vagy hogy találomra, rossz helyzetben és rossz paraméterekkel próbálkozik. Érdemes tehát legalább annyi figyelmet fordítani rá, mint a promptra.
Mi az eszközhasználat
Az eszközhasználat, angolul tool use vagy function calling, azt jelenti, hogy a modell nemcsak szöveget generál, hanem eszközöket hív, hogy adatot kérjen le vagy műveletet végezzen a külvilágban. A folyamat egy körben zajlik. A modell megkapja a felhasználó kérését és a rendelkezésre álló eszközök listáját, majd eldönti, hogy egy adott lépéshez szüksége van-e valamelyik eszközre. Ha igen, nem a végleges választ írja meg, hanem strukturáltan jelzi, melyik eszközt milyen paraméterekkel akarja meghívni. Az alkalmazás lefuttatja az eszközt, például meghív egy API-t vagy lekérdez egy adatbázist, és az eredményt visszaadja a modellnek. A modell ezután az eredmény birtokában folytatja, akár további eszközt hív, akár megírja a végleges választ. Fontos, hogy magát az eszközt nem a modell futtatja, hanem a mi kódunk, a modell csak kéri a hívást. Ez a felosztás adja a biztonságot is, mert eldönthetjük, mely hívásokat engedjük automatikusan lefutni, és melyeknél kérünk emberi jóváhagyást, mielőtt a művelet ténylegesen megtörténik.
Az eszköz definíciója
Egy eszköz definíciója három részből áll. Az első a név, egy rövid, gépi azonosító, amelyre a modell a hívásnál hivatkozik. A második a leírás, amely szabad szöveggel elmagyarázza, mit csinál az eszköz és mikor érdemes használni. A harmadik a bemeneti séma, amely felsorolja a paramétereket, azok típusát, hogy melyik kötelező, és mit jelentenek. A séma nem díszítés. Ez zárja ki, hogy a modell hiányos vagy rossz típusú bemenettel próbálja hívni az eszközt, és ez teszi kiszámíthatóvá a kapcsolódó kódot. A három rész közül azonban nem mind egyforma súlyú. A leírás sokkal többet nyom a latba, mint amennyit a legtöbben feltételeznek.
A jó eszközleírás dönt
Ez a lecke legfontosabb üzenete. A jó eszközleírás dönti el, hogy a modell helyesen és a megfelelő helyzetben használja-e az eszközt, sokkal inkább, mint azt a legtöbben gondolják. A modell nem látja az eszköz forráskódját, csak a nevet, a leírást és a sémát. Ebből a kevés információból következteti ki, mikor nyúljon az eszközhöz, és milyen értékeket adjon át. Ha a leírás pontatlan, félreérthető vagy hiányos, a modell rossz helyzetben hívja meg az eszközt, jó helyzetben viszont nem hívja meg, vagy rossz paramétereket ad neki. Rossz leírás egyenesen rossz eszközhasználathoz vezet, akkor is, ha maga a kód hibátlan. Sok fejlesztő a promptot csiszolja órákon át, miközben az eszközleírás egy odavetett félmondat marad, és pont ez okozza a hibás viselkedést.
Egy mondat, ami mindent eldönt. Az eszköz leírása az egyetlen csatorna, amelyen keresztül a modell megérti, mikor és hogyan használja az eszközt. Ha erre nem szánsz időt, a legjobb prompt sem menti meg a hibás eszközhasználatot.
Rossz és jó eszközleírás
Nézzük meg konkrétan, mi a különbség. Vegyünk egy fiktív magyar céget, a Dunakanyar Logisztika Kft.-t, amely szeretné, ha az ügyfélszolgálati asszisztense meg tudná mondani egy csomag aktuális állapotát. Ehhez kap egy eszközt, amely a szállítmánykövető rendszertől lekéri a státuszt. Ugyanaz az eszköz kétféleképpen leírva teljesen máshogy viselkedik a modell kezében. A bal oldali változat általános és üres, a jobb oldali pontosan megmondja, mikor és mivel kell hívni.
Rossz eszközleírás
- Név: get_data
- Leírás: Adatlekérés a rendszerből
- Paraméter: id, típus és kötelezőség nélkül
- Nincs benne, mikor és mire használja
Jó eszközleírás
- Név: szallitmany_statusz_lekerese
- Leírás: egy csomag aktuális állapotát adja vissza a követőszám alapján, akkor hívd, ha az ügyfél a saját küldeménye állapotát kérdezi
- Paraméter: kovetoszam, kötelező szöveg, formátuma DKL és nyolc számjegy
- Egyértelmű, mikor és mivel kell hívni
Mi az MCP
Az MCP, teljes nevén Model Context Protocol, egy nyílt szabvány, amely egységes módon köti össze a modellt a külső eszközökkel és adatforrásokkal. A korábbi világban minden integráció egyedi volt. Ahány eszköz, annyiféle bekötés, saját formátummal és saját hívási logikával. Az MCP ezt szabványosítja. Két szereplője van. Az MCP szerver közzéteszi az eszközöket és az adatokat, például egy fájlrendszert, egy adatbázist vagy egy céges API-t. Az MCP kliens, amely jellemzően a modellt futtató alkalmazásban él, egységes protokollon keresztül fedezi fel és hívja ezeket. A modell így nem tud arról, milyen konkrét rendszerhez kapcsolódik, csak a szabványos felületet látja. Ez a jelentősége, standardizálja az integrációt, és cserélhetővé teszi az eszközöket. Ha a Dunakanyar Logisztika lecseréli a szállítmánykövető rendszerét, elég egy új MCP szervert bekötni, a modell és a kliens oldalán semmit nem kell átírni.
Hogyan néz ki ez egy cégnél
Maradjunk a Dunakanyar Logisztikánál. Az ügyfélszolgálati asszisztensük egy MCP kliensen keresztül két szerverhez kapcsolódik. Az egyik a szállítmánykövetést teszi elérhetővé, a másik az ügyfél adatbázist. Amikor egy vevő beír, hogy hol tart a csomagja, a modell felismeri, hogy a szállítmány státusz eszközre van szüksége, kiolvassa a követőszámot az üzenetből, és a jó eszközleírás alapján pontosan azt a paramétert adja át, amit kell. A státusz visszaérkezik, és a modell emberi hangon összefoglalja a vevőnek. Ha a cég később másik futárpartnerre vált, csak a mögötte lévő MCP szervert kell újrahangolni, az asszisztens logikája és a promptja változatlan marad. Ez a szabvány gyakorlati haszna, a modell és az üzleti rendszerek függetlenül fejleszthetők.
Mire figyelj a tervezésnél
Néhány elv visszatér minden jó eszközkészletnél, és a vizsgán is ezek köszönnek vissza. A leírás legyen pontos és egyértelmű, mondja meg, mit csinál az eszköz és mikor kell használni. A paraméterek legyenek szűkek és jól definiáltak, minden mezőnek legyen típusa, legyen világos, mi kötelező, és a nevük árulja el a jelentésüket. A hibakezelést pedig előre kell megtervezni, mert az eszköz hívása bármikor meghiúsulhat. Egy jó gyakorlat, hogy inkább kevés, jól elhatárolt eszközt adunk a modellnek, mint sok, egymással átfedő funkciót, mert a túl sok hasonló eszköz között a modell nehezebben választ helyesen. Amikor a Dunakanyar Logisztika követő eszköze nem talál csomagot a megadott számhoz, a hibaüzenet ne csak annyit közöljön, hogy hiba történt, hanem azt, hogy a követőszám nem létezik, így a modell vissza tud kérdezni a vevőnél a helyes szám után, ahelyett hogy elakadna.
- Pontos, egyértelmű leírásA leírás mondja meg, mit tesz az eszköz és mikor érdemes hívni, kétértelműség nélkül.
- Szűk, jól definiált paraméterekMinden paraméternek legyen típusa és egyértelmű jelentése, a kötelező mezők legyenek megjelölve.
- Beszédes nevekAz eszköz és a paraméterek neve önmagában is árulja el, mire való, ne kelljen kitalálni.
- Átgondolt hibakezelésA hívás meghiúsulhat, ezért a hibaüzenet legyen érthető, hogy a modell tudjon belőle mit kezdeni.
Összefoglalás
Az eszközhasználat teszi lehetővé, hogy a modell ne csak beszéljen, hanem adatot kérjen le és műveletet végezzen. Egy eszköz a nevéből, a leírásából és a bemeneti sémájából áll, és ezek közül a leírás dönti el a leginkább, hogy a modell helyesen használja-e. Az MCP nyílt szabványként egységesíti, ahogy a modell a külső eszközökhöz és adatforrásokhoz kapcsolódik, ezzel standardizálja az integrációt és cserélhetővé teszi az eszközöket. A gyakorlatban három dologra kell figyelni, a pontos leírásra, a szűk és jól definiált paraméterekre, valamint az átgondolt hibakezelésre. Ha ezeket komolyan veszed, a modell megbízhatóan és a megfelelő helyzetben nyúl az eszközeihez.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.
Érdekel a program →