Az API alapjai

Mi az API, egyszerűen

Az API egy megállapodás arról, hogyan kérhet egy program szolgáltatást egy másiktól. Olyan, mint egy étterem étlapja. Nem kell tudnod, hogyan működik a konyha, elég annyit tudnod, mit kérhetsz és milyen formában. Feladod a rendelést a megadott módon, és megkapod, amit kértél. A nyelvi modellek esetében az étlap egyszerű. Küldesz egy üzenetet, és kapsz egy választ. Ami a felhasználó számára egy chatablak, az a fejlesztő számára egy API-hívás. Beírsz valamit, a rendszer elküldi a modellnek, majd a modell válaszát visszakapod, és megjeleníted.

A lényeg, hogy a modell egy távoli szolgáltatásként él, jellemzően valaki más szerverén. Az appod nem magát az óriási modellt tartalmazza, hanem csak azt a néhány sort, amivel elér hozzá. Ez felszabadító gondolat. Nem kell megérteni a modell belső matematikáját ahhoz, hogy építs vele, ahogy egy térkép beépítéséhez sem kell műholdakat üzemeltetni.

Ez a réteg egyben szabadságot is ad. Mivel az appod és a modell egy jól meghatározott ponton, az API-n keresztül kapcsolódik, viszonylag könnyű a modellt kicserélni vagy frissebbre váltani anélkül, hogy az egész alkalmazást újra kellene írni. A modellek gyorsan fejlődnek, és ami ma a legjobb választás, az fél év múlva már lehet, hogy nem az. Ha az alkalmazásod eleve úgy épül, hogy a modell csak egy cserélhető szolgáltatás a háttérben, akkor sokkal könnyebben tartod lépést a változásokkal. Ez a rugalmasság az egyik legfontosabb gyakorlati előnye annak, hogy a modellt nem beépítjük, hanem egy tiszta határon át elérjük.

Mit tartalmaz egy hívás

Egy modellhívás jellemzően néhány jól elkülönülő részből áll. Az első, hogy melyik modellt szeretnéd használni, hiszen egy szolgáltató több modellt is kínálhat, eltérő sebességgel és tudással. A második a tényleges tartalom, vagyis maga az üzenet, amit a modellnek küldesz. A harmadik néhány beállítás, amivel a válasz jellegét hangolod, például a korábban említett hőmérséklet, vagy a válasz megengedett maximális hossza. Ezek együtt alkotják a kérést.

Válaszként a modell visszaküldi a legenerált szöveget, gyakran néhány kísérő adattal együtt. Ilyen adat lehet például, hogy hány tokent használt fel a kérés és a válasz. Ez utóbbi azért érdekes, mert a legtöbb szolgáltató a felhasznált tokenek után számláz. Fejlesztőként érdemes már a legelső naptól figyelni erre, mert a hosszú beszélgetések és a nagy szövegek észrevétlenül megnövelhetik a költséget.

A modellválasztás önmagában is fontos döntés. A nagyobb, erősebb modellek jellemzően okosabbak, de lassabbak és drágábbak, a kisebbek gyorsabbak és olcsóbbak, cserébe egyszerűbb feladatokra valók. Egy jól tervezett alkalmazás nem mindig a legnagyobb modellt hívja, hanem a feladathoz mértet. Egy rövid cím megfogalmazásához elég lehet egy kisebb modell, egy összetett elemzéshez viszont indokolt a nagyobb. Ez a mérlegelés a felhasználó számára láthatatlan, de a rendszer sebességét és havi költségét komolyan befolyásolja.

A kulcs és a felelősség

A hívásokhoz szinte mindig szükség van egy hozzáférési kulcsra. Ez egy titkos azonosító, amely alapján a szolgáltató tudja, ki használja a modellt, és kit terhel a költséggel. A kulcsot úgy kell kezelni, mint egy jelszót. Soha nem tesszük bele a böngészőben futó, bárki által megnézhető kódba, és nem tesszük ki nyilvános helyre. Ha valaki illetéktelenül hozzáfér, a te neveden tud költeni. Ezért a kulcs jellemzően a szerveroldalon él, védett helyen, és a felhasználó gépe soha nem látja közvetlenül.

Ez a mintázat egyben az első komoly építészeti döntés is. Nem a felhasználó böngészője beszél közvetlenül a modellel, hanem a saját szervered áll közéjük. Így te ellenőrzöd, milyen kérés megy ki, védheted a kulcsot, és korlátozhatod, hogy egy felhasználó mennyit terhelhet a rendszeren. Ez a réteg a későbbi leckékben egyre fontosabb lesz.

Amivel az első naptól számolni kell

A modellhívás egy hálózaton keresztül történik, egy távoli szolgáltatóhoz, ezért nem viselkedik úgy, mint egy pillanat alatt lefutó helyi függvény. Időbe telik, néha másodpercekbe, és a modell hosszabb válasznál gyakran fokozatosan küldi vissza a szöveget, szinte úgy, ahogy egy ember gépelne. Ezt hívjuk folyamatos, adagolt válasznak. A felhasználó számára ez kellemes, mert nem egy üres képernyőt bámul, hanem látja, hogy elindult a válasz. A fejlesztőnek viszont fel kell készülnie arra, hogy a válasz nem egyben, hanem darabokban érkezik, és ehhez kell igazítania a felületet.

Mint minden hálózati kérés, a modellhívás is elromolhat. A szolgáltató lehet éppen túlterhelt, a kérés kifuthat az időből, vagy a szolgáltató átmenetileg elutasíthatja, ha túl sok kérést küldünk rövid idő alatt. Ezekre nem hibaként, hanem várható esetként kell tekinteni. Egy komoly alkalmazás udvariasan újrapróbálja a hívást, ha átmeneti a hiba, és nyugodt üzenettel áll meg, ha tartós. Emellett érdemes felső korlátot szabni annak, mennyit költhet egy felhasználó vagy az egész rendszer, hogy egy hiba vagy egy visszaélés ne fusson el a számlával.

Van egy csendben visszatérő tanulság is. Az adat, amit a modellhez küldünk, elhagyja a saját rendszerünket, és egy külső szolgáltatóhoz kerül. Ezért gondosan mérlegelni kell, milyen felhasználói vagy céges információt továbbítunk, és mit nem szabad kiengedni. A kényes adatot vagy előbb eltávolítjuk, vagy eleve nem küldjük el. Ez a szemlélet nem lassítja a fejlesztést, viszont sok későbbi kellemetlenségtől megóv.