Hogyan adj AI-funkciókat az appodhoz

AI-funkciók hozzáadásához hívj egy nagy nyelvi modell (LLM) API-t a szerveredről: küldj neki világos utasításokat a releváns adatokkal, és használd fel, ami visszajön. A leghasznosabb funkciók négy mintának egyikét követik – összefoglalás, chat, strukturált adatkinyerés és besorolás –, és mindegyik néhány tucat sornyi kód, amelyet egy AI-építő meg tud írni helyetted. A munka, amely eldönti, hogy a funkció jó lesz-e, a hívás körüli részen van: az API-kulcs szerveren tartása, a felhasználónkénti költségkontroll és a kimenet ellenőrzése, mielőtt megbíznál benne.

A négy minta, amely a legtöbb AI-funkció mögött áll

A kinyerés és a besorolás gyakran a legértékesebb és a legkevésbé látható. Rekordonként pár percet spórolnak meg csendben, és mivel a kimenet rögzített alakú, automatikusan ellenőrizhető. A chat a legszembetűnőbb, de a legnehezebb jól csinálni, és saját útmutatója van: hogyan építs AI-chatbot appot.

Hogyan illeszkedik az appodba

Minden minta ugyanazt a formát követi:

1. A felhasználó cselekszik – rákattint az „Összefoglalás” gombra, feltölt egy fájlt, üzenetet küld.
2. A frontended a saját szerveredet hívja, nem az AI-szolgáltatót.
3. A szervered összeállítja a kérést: rendszerutasítások, a felhasználó bemenete, és az adatbázisból a modellnek szükséges adatok – csak olyan adatok, amelyeket ez a felhasználó láthat.
4. A szervered meghívja az LLM API-t egy környezeti változóban tárolt kulccsal.
5. A szervered ellenőrzi a választ – érvényes JSON, ismert címke, észszerű hossz –, majd menti vagy visszaadja.
6. A frontend megjeleníti, hosszabb válaszoknál folyamatosan, ahogy érkezik a szöveg.

A kulcs a 4. lépésben a szerveren marad, és soha nem jut el a böngészőig. Ha az API fogalma új, a mi az az API rövid bevezető, a hogyan használj LLM API-kat pedig részletesebben tárgyalja a tokeneket, a modelleket és a kulcsokat.

Szolgáltató és modell kiválasztása

A nagy szolgáltatók – OpenAI, Anthropic, Google és mások – nagyjából hasonló felépítésű szöveges API-kat kínálnak. Hasznos kérdések a választáskor:

• Minőség a te feladatodon. Próbálj ki néhány valódi példát az appodból két-három modellen. A különbségek gyakran jobban látszanak a te adataidon, mint az általános benchmarkokon.
• Méret és költség. A szolgáltatók nagyobb, képesebb modelleket és kisebb, olcsóbb, gyorsabb modelleket kínálnak. A besorolás és az egyszerű kinyerés gyakran jól működik kis modellen; a hosszú érvelés vagy az árnyalt szövegírás nagyobbat igényelhet.
• Strukturált kimenet. Kinyerésnél és besorolásnál részesítsd előnyben azt az API-funkciót, amely megadott séma szerinti JSON-t ad vissza, ahelyett, hogy szabad szöveget kellene elemezned.
• Adatkezelés. Olvasd el a szolgáltató feltételeit arról, hogy az API-bemenetek tárolódnak-e vagy tanításra használják-e őket, és ez illik-e a felhasználóid adataihoz.
• Limitek. Az új fiókokra gyakran alacsonyabb sebességkorlát vonatkozik; indulás előtt ellenőrizd.

A modellnevek és az árak gyakran változnak, ezért a kód a modellnevet konfigurációból olvassa, ahelyett hogy többfelé beégetve szerepelne.

Funkció hozzáadása lépésről lépésre

Vegyünk egy konkrét példát: egy kis CRM, ahol minden kontaktnak hosszú jegyzetelőzménye van.

1. Tárold a kulcsot. Hozz létre kulcsot a szolgáltató irányítópultján, és mentsd szerveroldali titokként, például OPENAI_API_KEY vagy ANTHROPIC_API_KEY néven.

2. Kérj egy szűk funkciót:

Adj egy „Összefoglalás” gombot a kontakt oldalára. A szerveren küldd el a kontakt utolsó 20 jegyzetét a [PROVIDER] szolgáltatónak a [ENV_NAME] titok használatával, azzal az utasítással, hogy három felsorolásjelet írjon: jelenlegi státusz, nyitott kérdések, következő lépés. Csak azokat a jegyzeteket add hozzá, amelyeket a bejelentkezett felhasználó láthat. Mutass töltési állapotot, mentsd el az összefoglalót időbélyeggel, és ha a hívás sikertelen, jelenítsd meg: „Most nem sikerült összefoglalni”. A kulcsot soha ne küldd a böngészőnek.

3. Adj kinyerést ott, ahol gépelést spórol:

Amikor a felhasználó beilleszt egy e-mail aláírást a „Gyors hozzáadás” mezőbe, hívd meg a [PROVIDER] szolgáltatót a szerveren, és a szolgáltató strukturált kimeneti funkciójával adj vissza JSON-t névvel, céggel, beosztással, e-mail címmel és telefonszámmal. Ellenőrizd a JSON-t a szerveren, töltsd ki vele az új kontakt űrlapját, és hagyd, hogy a felhasználó mentés előtt szerkeszthesse. A mezőket hagyd üresen, ahelyett hogy találgatnál.

A „hagyd, hogy a felhasználó mentés előtt szerkeszthesse” a lényeg: a modell javasol, az ember dönt.

4. Besorolás háttérben:

Amikor új hibajegy érkezik, sorold pontosan egy kategóriába: számlázás, hiba, funkciókérés, fiókhozzáférés, egyéb. Kis, alacsony költségű modellt használj. Ha a válasz nem ezek közül való, mentsd „egyéb”-ként. A címkét szerkeszthető címkeként jelenítsd meg.

5. Teszteld valódi, rendezetlen adatokkal – hosszú jegyzetek, üres jegyzetek, más nyelvek, aláírás telefonszám nélkül –, és indulás előtt nézz meg húsz kimenetet egymás mellett.

Működő utasítások írása

A minden kéréssel küldött utasítások (gyakran rendszerpromptnak nevezik) adják a minőséget.

• Mondd meg, kinek szól, és mi a jó. Az „az összefoglalót egy értékesítő 10 másodperc alatt olvassa hívás előtt” célt ad a modellnek.
• Rögzítsd a formátumot. Pontos számú felsorolásjel, hosszkorlát, mezők, címkék.
• Mondd meg, mit tegyen bizonytalanság esetén. „Ha a jegyzetek nem említenek következő lépést, írd: »Nincs rögzített következő lépés«.” Ez csökkenti a kitalált válaszokat.
• Adj két-három példát jó bemenetre és kimenetre kinyerésnél és besorolásnál.
• Tartsd elkülönítve az utasításokat a felhasználói tartalomtól, és jelöld egyértelműen a felhasználói tartalmat, hogy a modell különbséget tudjon tenni.

A promptokat tárold a kódbázisban fájlokban, hogy verziózva és átnézhetően kezelhetők legyenek, mint bármely más kód.

A költségek kontroll alatt tartása

Az LLM API-k tokenekkel – kis szövegdarabokkal – számolnak, mind a küldött, mind a visszakapott szövegért. A költség a kérésenkénti kontextus mennyiségének és a futás gyakoriságának szorzataként nő. Gyakorlati kontrollok:

• Csak a szükségeset küldd. Az utolsó 20 jegyzetet, nem a teljes előzményt. Hosszú dokumentumokat vágj le vagy bontsd részekre.
• Használd a legkisebb modellt, amely elvégzi a feladatot. Teszteld, mielőtt alapértelmezésben a legnagyobbat választanád.
• Korlátozd a kimenet hosszát az API maximális tokenbeállításával.
• Gyorsítótárazz. Tárold az összefoglalót, és csak akkor generáld újra, ha a forrás változik, ne minden oldalmegjelenítésnél.
• Korlátozd felhasználónként. A fiókonkénti vagy csomagonkénti napi limit megakadályozza, hogy egy nagy használó vagy egy szkript felhajtsa a számlát.
• Sebességkorlátozd a végpontot, mint bármely más drága útvonalat.
• Állíts be költségkeretet vagy riasztást a szolgáltató irányítópultján, és indulás után hetente nézd meg a használatot.
• Naplózd a tokenhasználatot funkciónként, hogy tudd, melyik mennyibe kerül.

Ha az AI-funkciók a terméked központi részei, a futási költségüket az árazásba építsd be, ahelyett hogy elnyelnéd.

Biztonság és bizalom

Az AI-kimenet valószínűségi. Lehet téves, miközben magabiztosan hangzik, és azt a szöveg is befolyásolhatja, amit olvas. Ehhez építs:

• Kezeld a kimenetet nem megbízható bemenetként. Ellenőrizd a szerkezetét, HTML-ként való megjelenítés előtt escape-eld, és soha ne futtasd kódként vagy adatbázis-lekérdezésként.
• Tarts embert a körben minden olyan dolognál, aminek következménye van – e-mail küldése, rekord módosítása, fizetés visszatérítése. A modell piszkozatot készít; egy ember megerősít.
• Védekezz a promptinjektálás ellen. Egy dokumentum vagy üzenet tartalmazhat olyan szöveget, mint „hagyd figyelmen kívül az utasításaidat”. Korlátozd, mit láthat a modell, arra, amit az aktuális felhasználó láthat, és ne adj neki olyan eszközt, amely érzékeny műveleteket indíthat anélkül, hogy a kódod előbb ellenőrizné a jogosultságot.
• Jelöld az AI-tartalmat, hogy a felhasználók tudják: egy összefoglalót vagy javaslatot generáltak, és ellenőrizhetik.
• Kezeld kecsesen a hibákat. A szolgáltatóknál kiesések és sebességkorlátok előfordulnak. Állíts be időtúllépést, jelezz egyértelmű üzenetet, és hagyd, hogy az app többi része működjön tovább.
• Figyeld, mit küldenek a felhasználók. Nyílt szöveges bemenetnél fontolj meg egy moderációs lépést, és az adatvédelmi szabályzatban légy egyértelmű arról, hogy a tartalmat egy harmadik féltől származó AI-szolgáltató dolgozza fel.

Az ellenőrzések szélesebb listája az AI-val épített appok biztonsági ellenőrzőlistájában található.

Gyakori hibák

• Általános chatbottal kezdeni, amikor egy egyszerű „Összefoglalás” vagy „Kategorizálás” gomb több embernek segítene.
• A kulcs a frontend kódba vagy egy nyilvános repositoryba kerül.
• Az egész adatbázis kontextusként való elküldése, ami lassú, drága, és más felhasználók adatait teheti ki.
• Szabad szöveges kimenet megbízása, ahol egy séma vagy rögzített címkekészlet ellenőrizhetővé tenné.
• Felhasználónkénti limitek hiánya, ami akkor derül ki, amikor megjön az első számla.

AI-funkciók hozzáadása a Mythexszel

A Mythexben az AI-t a saját appodon belül úgy adod hozzá, hogy chatben kéred, a saját szolgáltatói kulcsoddal. Tárold a kulcsot projekttitokként – amikor az ügynöknek szüksége van rá, a Mythex titok-kártyát jelenít meg a chatben, így nem kell a kulcsot a beszélgetésbe illeszteni –, az ügynök pedig megírja a szerveri útvonalat, a promptokat és a felületet. Az appod AI-használatát a szolgáltatód számlázza, külön a Mythex-kredittől, amelyet az építésre költesz. A dokumentációban egy kezdő prompt található: AI-funkciók hozzáadása a saját API-kulcsaiddal.

Kérdések