LLM-funkciók élesben: mi marad állva, amikor igazi felhasználók használják

A demó és az éles üzem közötti szakadék

A nagy nyelvi modelleket minden eddigi technológiánál könnyebb demózni – és az egyik legnehezebb élesre vinni. A demó ugyanis mindent elrejt, ami üzemeltetés közben számít: a nyolc másodperces válaszidőt, a kimenetet, ami nem abban a formátumban érkezik, amit a kódod vár, a tokenköltséget, ami a sikerrel együtt lineárisan nő, és a felhasználókat, akik olyat gépelnek be, amire a prompt írásakor senki nem gondolt.

A saját AI-alapú projektbecslőnk – ezen az oldalon fut élesben – ezt első kézből tanította meg nekünk. A mérnöki munka zöme arra ment el, hogy a modell kimenetét defenzíven dolgozzuk fel, kezeljük a hibás válaszokat, és akkor is elfogadható maradjon az élmény, ha a modell lassú. A prompt volt a könnyű rész.

Minták, amelyek beválnak

Az eddigi AI-munkáinkban – legyen szó LLM-alapú funkcióról, AI-ágenses munkafolyamatról vagy OpenAI-ra, Anthropicra, LangChainre és n8n-re épülő integrációról – az élesben is beváló funkciók ugyanarra a mintára épülnek:

• —Szűk hatókör: egy jól körülhatárolt feladat (becsüld meg ezt a projektet, foglald össze ezt a dokumentumot) megbízhatóságban, költségben és felhasználói bizalomban is jobb, mint egy parttalan chatablak
• —Kizárólag szerveroldali hívások: API-kulcs soha nem kerül mobil- vagy webkliensbe – a hívások egy backend rétegen mennek keresztül (Firebase-alapú stackben Cloud Functions), és ott laknak a kulcsok, a rate limitek és a naplózás is
• —Strukturált kimenet: kösd sémához a modell válaszát, és validáld, mielőtt felhasználod; nyers modellszöveg soha ne kerüljön közvetlenül a programlogikába
• —Tervezett hibaág: a funkciónak legyen válasza arra az esetre, ha a modell hibázik vagy nem válaszol időben – és ez a válasz ne egy törött képernyő legyen
• —Költségplafon: felhasználónkénti és napi limitek már az első naptól, mert egy virális pillanat nem válhat számlázási incidenssé

Hova ne tedd a modellt

A leggyakoribb hiba, amivel találkozunk, hogy LLM-et használnak ott, ahova determinisztikus kód való. Árszámítás, áfaszabályok, adatvalidáció, bármi, aminek jogilag egyetlen helyes válasza van – ez nem a modell terepe, és egy számla végösszegénél az „az AI elszámolta” nem elfogadható incidensjelentés. A jól működő munkamegosztás: a modell a nyelvvel és a rendszer peremén felmerülő mérlegeléssel foglalkozik – megérti a felhasználó kusza leírását, megfogalmaz egy összefoglalót –, minden másról, aminek van helyes válasza, determinisztikus kód dönt.

Ugyanez a válasz a megbízhatósági aggályokra is. Az az LLM-funkció, amelyet úgy terveztek, hogy a modell hibája ne okozzon kárt – mert ember nézi át, kód validálja, vagy eleve kicsi a tét –, nyugodt szívvel élesíthető. Az, amelyikben egy hallucináció eljuthat egy pénzügyi dokumentumig, nem.

Egy funkcióval kezdd, ne stratégiával

Egyre több cég érzi úgy, hogy „AI-stratégiára” van szüksége. A mi tanácsunk ennél kisebb és hasznosabb: keresd meg a termékedben azt az egy valódi súrlódási pontot, ahol a nyelvértés tényleg segítene, építsd meg azt az egy funkciót a fenti fegyelemmel, és tanulj belőle. Egyetlen működő AI-funkció élesben többet tanít egy szervezetnek, mint egy negyedévnyi stratégiai dokumentum – ráadásul kamatozik is: az első funkcióhoz kiépített alapok (szerveroldali hívások, validáció, költségkontroll) a másodikat már olcsóvá teszik.