AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.

Van valami egészen szórakoztató abban, ahogy az AI megérkezésével a szoftverfejlesztés hirtelen újranevezi saját magát.

Ami tegnap még framework volt, ma már harness. Ami tegnap API call volt, ma function calling. A scriptből agent lett, az adatbázisból memory, az input validációból guardrail, a workflow-ból pedig AI workflow.

Persze, mielőtt bárki felháborodna: ezek között vannak valódi új fogalmak is. Az LLM-ek tényleg hoztak új problémákat, új absztrakciókat és új fejlesztési mintákat.

Csak közben néha olyan érzése van az embernek, mintha a technológiai ipar felfedezte volna a marketing egyik legrégebbi trükkjét:

Ha valamit új néven nevezel el, az máris új technológiának tűnik.

Íme egy rövid AI-korszakbeli szótár.

Agent

Régen: script, automation, worker.

Most: agent.

Az agent talán a legjobb példa arra, mennyire el tud mosódni a határ egy valóban új fogalom és egy új címke között.

Ha van egy programod, ami kap egy feladatot, meghív néhány függvényt, elágazik, majd elvégzi a dolgát, azt régen egyszerűen automatizációnak hívtuk.

Ha ugyanezt egy LLM vezérli, akkor már sokkal nagyobb eséllyel agent.

És ez nem feltétlenül helytelen. Egy LLM által vezérelt, dinamikusan tervező és eszközöket használó rendszer tényleg másképp működik, mint egy előre megírt script.

De azért érdemes észben tartani:

attól még nem lesz agent valami, hogy ráragasztottuk a szót.

Harness

Régen: framework, orchestration layer, runtime.

Most: AI harness.

A harness eredetileg nem valami misztikus AI-technológia. Egy keretrendszer vagy infrastruktúra, amely köré egy rendszert felépítünk.

Az AI világában azonban hirtelen minden második LLM köré épített segédinfrastruktúra harness lett.

És persze van értelme a fogalomnak: egy AI-agent futtatási környezete tényleg tartalmazhat kontextuskezelést, toolokat, memóriát, állapotkezelést, jogosultságokat és egy rakás olyan dolgot, ami egy hagyományos frameworknél nem feltétlenül volt jelen.

De a mondat továbbra is viccesen hangzik:

„Készítettünk egy új harness-t.”

Fordítás:

„Készítettünk egy frameworköt.”

Csak most már AI van benne.

Function calling

Régen: API call.

Ez talán az egyik kedvencem.

Az LLM kap egy struktúrált lehetőséget arra, hogy meghívjon egy függvényt:

get_weather("Budapest")

És ezt function callingnak hívjuk.

A program pedig meghívja a megfelelő függvényt.

Ezt egyébként teljesen jogos külön fogalomként kezelni az LLM-ek világában, mert a modellnek valamilyen módon strukturáltan kell jeleznie, hogy milyen eszközt szeretne használni.

De ha nagyon lecsupaszítjuk:

egy program meghív egy másik programot.

A szoftverfejlesztésben ezt meglehetősen régóta API callnak hívjuk.

Tool use

Régen: function call.

Aztán rájöttünk, hogy a modell nem csak függvényeket tud meghívni.

Kereshet az interneten. Fájlokat olvashat. Adatbázishoz férhet hozzá. Terminált használhat. Böngészőt vezérelhet.

Ezért ezek már nem egyszerűen functionök, hanem toolok.

És itt már tényleg van értelme az új terminológiának: az AI számára egy külső képesség egységesen kezelhető „eszközként”, függetlenül attól, hogy mögötte API, adatbázis vagy valamilyen más szolgáltatás van.

De a terminológiai fejlődés gyönyörű íve:

function → function calling → tool → tool use

A következő lépés valószínűleg az lesz, hogy a tool már önmagában is túl régi szó lesz.

Memory

Régen: adatbázis. State. Persistent storage.

Most: memory.

Ez az egyik legszebb példája annak, amikor egy teljesen hétköznapi informatikai problémát emberibb névvel látunk el.

Az AI-agentnek szüksége van arra, hogy valamit megjegyezzen két futtatás között.

Mit csinálunk?

Elmentjük.

Hová?

Adatbázisba.

Hogy hívjuk?

Memory.

És hirtelen úgy hangzik, mintha valami egészen új technológiai áttörést találtunk volna fel.

Természetesen az AI memória-problémája lehet összetettebb ennél. Lehet rövid távú és hosszú távú memória, szemantikus keresés, embedding, relevancia-alapú visszatöltés és mindenféle érdekes mechanizmus.

De az alapötlet továbbra is meglehetősen ősi:

„Ezt később is tudni akarjuk, ezért elmentjük valahová.”

RAG

Régen: keresés + dokumentumtár.

A RAG, vagyis Retrieval-Augmented Generation már sokkal komolyabb fogalomnak hangzik.

És itt valóban van mögötte technikai tartalom.

A modell nem csak a saját paramétereiből válaszol, hanem előbb megkeres releváns információkat egy külső tudásbázisban, majd azokat beadjuk neki kontextusként.

De ha nagyon leegyszerűsítjük:

„Nem tudja? Keresse meg.”

Ezt a problémát az informatika történetében már néhányszor megoldottuk.

A különbség az, hogy most a keresés eredményét egy generatív modell kapja meg, amely abból választ készít.

Ez tényleg új kombináció.

A keresés önmagában viszont nem tegnap született.

Prompt engineering

Régen: specifikáció.

Vagy instrukció.

Vagy józan ész.

Az AI megjelenésével hirtelen egy teljes szakma épült arra, hogyan kell úgy megfogalmazni egy utasítást, hogy a modell azt csinálja, amit szeretnénk.

És ez valóban érdekes terület.

Egy LLM nem determinisztikus függvény, amelynek átadjuk az inputot és mindig ugyanazt kapjuk vissza. A megfogalmazás, a kontextus, a példák és a korlátozások tényleg számítanak.

De azért vicces belegondolni, hogy a szoftverfejlesztés egyik új szakmai készsége részben az lett:

„Írd le neki rendesen, mit akarsz.”

A fejlesztők ezt egyébként specifikációnak hívták.

Context engineering

Régen: adat-előkészítés + promptolás + state management.

A prompt engineering után természetesen kellett egy még menőbb kifejezés.

Így megszületett a context engineering.

És ez már tényleg érdekesebb.

Egy modern AI-rendszernél nem az a kérdés, hogy milyen mondatot írunk a modellnek. A kérdés az, hogy milyen információhalmazt adunk neki.

Milyen dokumentumokat?

Milyen korábbi beszélgetést?

Milyen tool eredményeket?

Milyen rendszerutasítást?

Milyen felhasználói adatokat?

Milyen állapotot?

Ez már valóban egy komoly rendszertervezési probléma.

Csak azért érdemes észben tartani, hogy a fogalom mögött részben továbbra is az áll:

„Adjunk a programnak megfelelő adatot, mielőtt megkérjük valamire.”

Guardrails

Régen: validáció, jogosultságkezelés, üzleti szabályok.

A guardrail különösen szép kifejezés.

Mert senki sem akarja azt mondani egy prezentációban, hogy:

„A bemenetet validáljuk, a jogosultságokat ellenőrizzük, és ha valami nem megengedett, visszautasítjuk.”

Sokkal jobban hangzik:

„Robusztus AI guardrail-rendszert építettünk.”

És valójában ez nagyon fontos az AI-rendszereknél.

Csak nem teljesen új.

A szoftverfejlesztés mindig is arról szólt, hogy ne bízz vakon az inputban.

Az AI esetében viszont a probléma nagyobb, mert a modell maga is képes nem várt döntéseket hozni.

Tehát:

régi probléma + új környezet = jogosan új hangsúly.

Nem minden új kifejezés tehát bullshit.

Néha csak régi építőelemeket használunk egy új problémára.

AI orchestration

Régen: backend logika.

Ez talán az egyik legveszélyesebb kategória.

Van három szolgáltatásunk.

Az egyik lekér valamit.

A második feldolgozza.

A harmadik elmenti.

Közöttük van néhány feltétel, retry, timeout és hibakezelés.

Régen ezt backendnek hívtuk.

Most:

AI orchestration layer.

És ha a döntési pontokba még egy LLM-et is teszünk, akkor természetesen már agent orchestration.

A rendszerdiagramon pedig sokkal komolyabban néz ki.

Multi-agent system

Régen: microservices.

Na jó, ez már gonosz.

Nem minden multi-agent rendszer microservice.

De néha tényleg olyan érzése van az embernek, mintha ugyanazt az architekturális ötletet fedeznénk fel újra.

Van egy agent, amelyik kutat.

Egy másik ír.

Egy harmadik ellenőriz.

Egy negyedik összefoglal.

És ezek kommunikálnak egymással.

Multi-agent architecture.

Vagyis:

„Szétbontottuk a rendszert több komponensre, amelyek üzenetekkel kommunikálnak.”

A szoftveripar erre már több évtizede használ különböző neveket.

Most azonban legalább minden komponens beszélgethet is.

AI-native

Régen: szoftver.

Az „AI-native” kifejezés ma már szinte bármire ráhúzható.

Van egy alkalmazásunk.

Van benne egy chatbot.

AI-native.

Van egy keresőnk.

Az eredményeket egy LLM összefoglalja.

AI-native.

Van egy CRM-ünk, ami automatikusan ír egy e-mailt.

AI-native.

A fogalom persze jelenthet ennél többet is: azt, hogy a termék alapvető működése eleve egy generatív modell képességeire épül, nem pedig utólag raktak bele egy AI-funkciót.

Csak a gyakorlatban néha:

AI-native = van benne AI.

Human-in-the-loop

Régen: jóváhagyás.

A mesterséges intelligencia megjelenésével természetesen rá kellett jönnünk, hogy az ember még mindig hasznos lehet.

Ezért lett:

human-in-the-loop.

Ha az AI javasol valamit, az ember ránéz.

Ha jó, mehet tovább.

Ha rossz, javítjuk.

Ez egyébként kifejezetten fontos architekturális minta.

Csak a neve alapján úgy hangzik, mintha valami futurisztikus új rendszer lenne.

Pedig a legtöbb vállalati szoftverben az elmúlt harminc évben valamilyen formában úgy működött:

„Valaki még hagyja jóvá.”

Model routing

Régen: strategy pattern + load balancing.

Van három modellünk.

Az egyszerű feladatot olcsóbb modellel végezzük.

A nehéz feladatot drágábbal.

A gyors választ gyors modellel adjuk.

A nagy kontextust kezelő feladatot másikkal.

Ez nagyon hasznos.

És nagyon is indokolt.

De azért:

„Model routing”

vs.

„Eldöntjük, melyik modellt hívjuk.”

Az AI-világ szereti, ha az egyszerű dolgoknak is van háromszavas neve.

És akkor mi az, ami tényleg új?

A cinizmus ellenére nem lenne fair azt mondani, hogy az AI-ipar csak átnevez mindent.

Mert az LLM-ek tényleg hoztak új problémákat.

Egy hagyományos programnál általában mi határozzuk meg a vezérlési logikát.

Egy agentnél részben maga a modell dönt arról, hogy mi legyen a következő lépés.

Egy hagyományos API determinisztikusabb szerződést ad.

Egy LLM valószínűségi modellként működik.

Egy hagyományos adatbázisban tudjuk, milyen adatot kérünk le.

Egy AI-rendszernél azt is meg kell oldani, hogy milyen információt adjunk a modellnek, mikor, milyen formában és mekkora mennyiségben.

És egy hagyományos programnál általában könnyebb meghatározni, hogy egy adott inputra mi fog történni.

Egy agentnél már az is kérdés lehet, hogy egyáltalán milyen utat választ a cél eléréséhez.

Ezek valódi új kihívások.

És éppen ezért van szükség új fogalmakra.

A probléma akkor kezdődik, amikor az új név önmagában elkezd új technológiának számítani.

A végső AI-szótár

Talán a legegyszerűbb szabály ez:

Ha egy régi dolgot AI-val kombinálsz, először nézd meg, hogy tényleg új problémát oldottál-e meg.

Ha igen, adj neki nevet.

Ha nem:

valószínűleg csak átnevezted.

És ez egyébként nem feltétlenül baj.

A technológia fejlődésének természetes része, hogy új fogalmak születnek. Az új terminológia segíthet abban, hogy felismerjük az új mintákat, és különbséget tegyünk olyan dolgok között, amelyek első pillantásra hasonlónak tűnnek.

Csak néha érdemes visszakérdezni:

„Ez tényleg új, vagy csak most lett benne egy LLM?”

Mert lehet, hogy a következő nagy AI-áttörés nem egy új modell lesz.

Hanem egy új szó arra, amit már húsz éve csinálunk.

AI Disclosure: A cikk elkészítéséhez generatív AI-eszközöket is használtam. A végső tartalomért és annak pontosságáért a szerző vállal felelősséget.