Mit jelent az OpenAI-kompatibilis API
Az OpenAI évekkel ezelőtt kialakított egy formát arra, hogyan kérjen egy program választ egy nyelvi modelltől. Ez a forma annyira elterjedt, hogy mára gyakorlatilag iparági alappá vált. Amikor azt olvasod egy szolgáltatóról, hogy OpenAI-kompatibilis API-t kínál, az pontosan azt jelenti, hogy ugyanabban a szerkezetben fogadja a kéréseket és ugyanabban a szerkezetben adja vissza a választ, mint az eredeti. A modell mögötte lehet teljesen más, akár egy nyílt súlyú modell, akár egy másik cég saját fejlesztése, a beszélgetés nyelvtana viszont azonos marad.
A gyakorlati következmény óriási. Ha egyszer megírtad a kliens-kódot az egyik szolgáltatóhoz, ugyanaz a kód működik a másiknál is. Nem kell megtanulni egy új felület logikáját, nem kell újraírni a programot. A legtöbb esetben mindössze két apró dolgot cserélsz ki, és a rendszer máris egy másik szolgáltatóval dolgozik.
Az API négy alapfogalma
Négy fogalommal érdemes tisztában lenni, mielőtt az első hívást megnézzük. Ez a négy visszatér minden szolgáltatónál, függetlenül attól, hogy melyiket használod.
Az első az API végpont, angolul endpoint. Ez egy webcím, ahová a program elküldi a kérést. Minden szolgáltatónak megvan a maga végpont-címe, és éppen ez az egyik olyan adat, amit szolgáltatóváltáskor kicserélsz.
A második az API kulcs. Ez egy hosszú, titkos karaktersor, amit a szolgáltatónál regisztráció után kapsz. A kulcs azonosítja, hogy ki küldi a kérést, és ehhez köti a használatot. Úgy viselkedik, mint egy jelszó, ezért ugyanolyan gonddal is kell kezelni.
A harmadik a kérés, angolul request. Ez az az üzenetcsomag, amit a végpontra küldesz. Megmondod benne, melyik modellt szeretnéd, átadod az üzeneteket, és beállítasz néhány paramétert.
A negyedik a válasz, angolul response. Ez az, amit a modell visszaküld. Egy strukturált csomag, amelyből a program kiolvassa a tényleges szöveget, és általában azt is megtudja, mennyi szöveget dolgozott fel a hívás.
Érdemes látni, hogy ez a négy fogalom mindig együtt jár. A végpont megmondja, hová megy a kérés, a kulcs igazolja, hogy jogosult vagy rá, a kérés hordozza a tényleges feladatot, a válasz pedig visszahozza az eredményt. Amint ezt a négyet átlátod, bármelyik szolgáltató dokumentációja ismerősnek fog tűnni, mert mind ugyanerre a négy pillérre épül.
Hogyan épül fel egy kérés
A kérés szíve az üzenetek listája. A modell nem egyetlen szövegre válaszol, hanem egy egész beszélgetésre, amit üzenetek sorozataként adsz át. Minden üzenetnek van egy szerepe és egy tartalma.
A rendszer szerep, angolul system, adja a keretet. Itt mondod meg a modellnek, hogyan viselkedjen, milyen hangnemben és milyen szempontok szerint válaszoljon. A felhasználói szerep, angolul user, maga a konkrét kérdés vagy feladat. Van egy harmadik, az asszisztens szerep is, amely a modell korábbi válaszait jelöli, ha többfordulós beszélgetést építesz.
Az üzenetek mellett néhány paraméter finomítja a választ. A modell neve megmondja, pontosan melyik modellt hívod, hiszen egy szolgáltató több modellt is kínálhat egyszerre. A maximális hossz, amit gyakran max_tokens néven állítasz, felső korlátot ad a válasz terjedelmére. A hőmérséklet, angolul temperature, azt szabályozza, mennyire legyen kiszámítható vagy szabad a válasz. Az alacsony érték józan, ismételhető választ ad, a magasabb érték változatosabbat.
- Végpont és kulcs beállításaMegadod, melyik szolgáltató címére küldöd a kérést, és melyik API kulccsal azonosítod magad.
- Üzenetek összeállításaEgy listát építesz szerepekkel, a rendszer szerep a keret, a felhasználói szerep a konkrét feladat.
- Modell és paraméterek megadásaKiválasztod a modell nevét, és beállítod a maximális hosszt meg a hőmérsékletet.
- Kérés elküldéseA program elküldi a csomagot a végpontra, és megvárja, míg a modell feldolgozza.
- Válasz kiolvasásaA visszaérkező csomagból a program kiszedi a tényleges választ, és felhasználja tovább.
Így néz ki egy hívás
Az alábbi néhány sor konceptuálisan mutatja, hogyan áll össze egy hívás. A cél most nem a pontos szintaxis, hanem hogy lásd a felépítést, a végponttól a válasz kiolvasásáig.
# A kliens beállítása
endpoint = "https://a-szolgaltato.pelda/v1"
kulcs = KORNYEZETI_VALTOZOBOL
# A kérés összeállítása és elküldése
valasz = kliens.chat.completions.create(
model = "modell-neve",
messages = [
{ "role": "system", "content": "Rövid, magyar válaszokat adsz." },
{ "role": "user", "content": "Foglald össze a beérkezett üzenetet." }
],
max_tokens = 400,
temperature = 0.2
)
# A válasz kiolvasása
print( valasz.choices[0].message.content )Konceptuális példa. A lényeg a szerkezet, nem a nyelv, ugyanez a minta él más környezetben is.
Ez a néhány sor tartalmazza mind a négy alapfogalmat. Beállítod a végpontot és a kulcsot, összeállítod az üzeneteket a szerepekkel, megadod a modell nevét és a paramétereket, majd a végén kiolvasod a válaszból a szöveget.
Ami igazán fontos, az a következő. Ha holnap egy másik szolgáltatóhoz akarsz átállni, a kód szinte teljes egészében változatlan marad. Az endpoint és a kulcs sort írod át, esetleg a modell nevét, minden más marad a helyén.
Miért óriási előny ez
A legnagyobb kockázat, amit egy vállalkozás bevállalhat egy AI megoldásnál, hogy egyetlen szolgáltatóhoz köti magát. Ha az egyetlen beszállító lelassul, drágul, korlátoz egy funkciót vagy éppen megszünteti a szolgáltatást, a rendszered vele együtt kerül bajba. Az OpenAI-kompatibilis forma pontosan ez ellen véd. Mivel a kliens-kód nem egy konkrét szolgáltatóhoz, hanem egy közös nyelvtanhoz igazodik, a szolgáltatók egymással felcserélhetők.
A gyakorlatban ez azt jelenti, hogy nem ragadsz be. Ha az egyik szolgáltató lassú a csúcsidőben, átirányíthatod a forgalmat egy másikhoz. Ha az egyik ára megváltozik, összehasonlíthatod a többivel, és a program szintjén szinte ingyen váltasz. Sőt, akár párhuzamosan is használhatsz többet, olcsóbbat a nagy tömegű, egyszerű feladatokra, erősebbet a ritka, nehéz kérdésekre. Ez a rugalmasság önmagában is érv amellett, hogy erre a formára építs.
Csak két adat cserélődik. Ha OpenAI-kompatibilis szolgáltatóra építesz, egy szolgáltatóváltás jellemzően a végpont-cím és az API kulcs kicserélése, esetleg a modell nevének átírása. A rendszer többi része érintetlen marad.
Egy fiktív céges példa
Vegyünk egy fiktív magyar céget, egy webshopot üzemeltető kisvállalkozást, nevezzük Kék Kosár Kft-nek. A cég beépít egy AI lépést, amely a beérkező vevői üzeneteket röviden összefoglalja az ügyfélszolgálatnak. Elsőként egy ingyenes keretet kínáló szolgáltatóra kötik rá a rendszert, mert a kezdeti tesztekhez az bőven elég.
Ahogy nő a forgalom, észreveszik, hogy csúcsidőben a válaszok lassulnak. Mivel OpenAI-kompatibilis formára építettek, nem kell újraírni a programot. A fejlesztő átírja a végpont-címet és beállít egy másik API kulcsot, és a rendszer máris egy gyorsabb szolgáltatónál fut. A vevői üzeneteket összefoglaló logika, a rendszer szerep utasítása, a paraméterek, mind maradnak a helyükön. Ami hetes projekt lenne egy zárt megoldásnál, itt néhány sor módosítása.
Fél évvel később a Kék Kosár egy nehezebb feladatot is bevezet, a hosszabb reklamációk kivonatolását. Ehhez már egy erősebb modell kell, de nem kell új rendszert építeni hozzá. Ugyanabban a kliens-kódban egyszerűen egy másik modell nevét adják meg erre a lépésre, míg az egyszerű összefoglalók továbbra is az olcsóbb modellen futnak. Egyetlen közös nyelvtan, több szolgáltató és több modell, egymás mellett, a cég igényei szerint.
Mire figyelj
Két dolgot érdemes az elejétől helyesen csinálni, mert később sok gondtól kímél meg.
Az első a kulcs biztonságos tárolása. Az API kulcsot soha ne írd bele közvetlenül a kódba, és semmiképp ne töltsd fel közös tárhelyre vagy verziókövetőbe. A bevett módszer, hogy környezeti változóban vagy egy titkos beállításban tárolod, és a program onnan olvassa ki. Ha egy kulcs mégis kiszivárog, azonnal vond vissza a szolgáltatónál, és állíts ki egy újat. A kulcs olyan, mint egy jelszó, aki hozzáfér, a te neveden és a te keretedből használja a szolgáltatást.
A második a modellnév helyes megadása. Minden szolgáltatónál más és más lehet a modellek pontos neve, még akkor is, ha ugyanaz a nyílt súlyú modell fut mögötte. Ha elgépeled a nevet vagy egy olyan modellt kérsz, ami az adott szolgáltatónál nem elérhető, a hívás hibával tér vissza. Ezért szolgáltatóváltáskor mindig nézd meg a dokumentációban, náluk pontosan hogyan hívják a modellt, amit használni szeretnél.
Ha ezt a kettőt rendben tartod, és a végponttal meg a kulccsal tudatosan bánsz, az OpenAI-kompatibilis API az egyik legkényelmesebb és legszabadabb belépő az ingyenes és nyílt modellek világába. A következő leckében megnézzük, milyen nyílt súlyú modellek közül választhatsz, és mikor melyik a jó döntés.
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 →