Nemrég az egyik ügyfelemnek volt egy problémája: gyorsabban gyűltek a support ticketek, mint ahogy azokat triázsolni tudták volna.

Valakinek el kellett olvasnia mindegyiket, kitalálnia a kategóriát, és a megfelelő queue-ba irányítania.

Lévén 2026-ot írunk, egy AI agenthez nyúltak, mert hallották, hogy a nagyok közül is páran ezt az utat követik.

Az egész ötlet tök egyszerűnek tűnt: adjunk az LLM-nek egy ticketet, egy pár tool-t, és egy célt: "irányítsd a megfelelő helyre", aztán oldja meg a többit magától.

Eltelt három hét, és volt is egy működő prototípusuk. Csakhogy az lassú volt, elég drága, és időnként egy-egy számlázási kérdést a security csapathoz irányított valamiért, amit aztán senki nem tudott visszafejteni a trace logokból.

Aztán valaki megemberelte magát, elővette a régi ticketeket, tréningezett egy betonegyszerű szöveg-klasszifikálót tizennyolc hónapnyi ilyen routing-döntésen, és a hét végére előállt egy megoldással, ami gyorsabb, olcsóbb és kiszámíthatóbb volt.

A mögöttes technológia borzasztóan unalmas volt.

És pontosan ez volt a lényeg.

A klasszifikáció egy olyan probléma, amit a supervised learning már évtizedek óta megoldott.

Ehhez pedig nem kell LLM, AI, agentek, vagy bármi hasonló.

Task, goal, és a különbség, ami tényleg számít

Az egyik legegyszerűbb módja eldönteni, hogy szükség van-e arra a bizonyos agentre, ha feltesszük ezt az egyszerű kérdést:

Le tudom írni a helyes outputot mint az input függvényét?

Egy task ugyanis nem más, mint egy fix input-output leképezés. Vegyük ezt a ticketet:

A számlámon kétszer szerepel ugyanaz az előfizetési díj.
Vissza tudjátok téríteni a duplikációt?

Legyen a kimenet:

billing

Hát bizony ez nem más, mint egy sima függvény:

def classify(ticket):
    return model.predict(ticket)

Nincs benne se állapot, se elágazás, nem kell döntenie arról, mi legyen a következő lépés, és azt sem kell megvizsgálnia, mi lett egy lépés eredménye, mielőtt eldöntené, mi jöjjön utána. Ennyi az egész:

Egy goal viszont lényegesen más állat: egy kimenetelt ír le anélkül, hogy előírná az odáig vezető utat.

Mondjuk így:

Oldd meg ennek az ügyfélnek a problémáját.

Ez akár ilyesmit is jelenthet:

A következő lépés ugyanis mindig attól függ, mit derítünk ki menet közben - és itt kezd el igazán érdekessé válni egy agent.

Csakhogy itt van a csapda is.

Az "Irányítsd a ticketet a megfelelő helyre" úgy hangzik, mint egy goal, hiszen utasításként van megfogalmazva.

Csak épp nem feltétlenül az.

Ha ugyanis minden egyes tickethez pontosan egyetlen helyes routing-döntés tartozik, a probléma alapjában véve még mindig ez marad:

Csak épp felszólító módban van megfogalmazva, magyarul vagy angolul, teljesen mindegy.

A különbség tehát nem attól függ, mennyire nyitottnak hangzik a mondat.

Attól függ, hogy a válaszhoz vezető utat futásidőben kell-e felfedezni.

És ez a különbség maga a lényeg.

Egy egyszerű teszt

Mielőtt agenthez nyúlnánk, érdemes megpróbálni felírni a problémát egyetlen függvényként.

Például:

def route_ticket(ticket):
    """
    Input:
        ticket: ügyfélszolgálati üzenet

    Output:
        az alábbiak egyike:
        - billing
        - security
        - technical
        - account
    """
    ...

Ha ésszerűen meg tudjuk határozni ezt a függvényt, a következő kérdés már csak ez:

Van történeti példám erre a bemenet-kimenet leképezésre?

Ha igen, akkor valószínűleg nem is agent-problémával, hanem egy sima gépi tanulási feladattal állunk szemben.

Mondjuk így néz ki:

Ez ugyanis tréningadat.

Nem kell egy modellnek tool-inventoryt nyomni a kezébe, és megkérni, hogy fedezze fel, mit is jelent a klasszifikáció.

Egyszerűen meg lehet tanítani neki a leképezést.

Hogy néz ez ki kódban

A tényleges modell meglepően egyszerű is lehet.

Egy klasszikus szövegklasszifikáló pipeline nagyjából így fest:

from sklearn.pipeline import Pipeline
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression

model = Pipeline([
    ("features", TfidfVectorizer(
        ngram_range=(1, 2),
        min_df=2
    )),
    ("classifier", LogisticRegression())
])

model.fit(training_tickets, training_labels)

queue = model.predict([
    "Kétszer terheltek meg az előfizetésemért"
])[0]

print(queue)
# billing

Nincs itt se prompt engineering, se tool calling, se agent framework, se beszélgetés-history, se autonóm loop.

Csak egy modell, ami megtanulja ezt:

És ez gyakran pontosan az, amire production környezetben szükség van.

Ráadásul egy confusion matrix-szal remekül mérhető is:

Valódi \ Predikció	Bill	Sec	Tech	Account
Bill	940	3	12	5
Sec	2	410	4	1
Tech	8	2	870	9
Account	4	1	7	690

Innentől pontosan látszik, hol hibázik a rendszer.

Ehhez képest egy agent trace valahogy így fest:

Agent trace:
"Először azt gondoltam, hogy ez talán security-probléma..."
"Aztán megnéztem az ügyfelet..."
"Aztán elgondolkodtam a billingen..."
"Aztán úgy döntöttem..."

Az egyik egy confusion matrix.

A másik meg egy detektívregény, amit senki nem kért.

Workflow: control logic, amit egy ember már kigondolt

Sok minden, ami első ránézésre valami komoly döntéshozó rendszert igényelne, valójában csak egy workflow.

Vegyük megint a support routingot.

Lehet, hogy a tényleges folyamat ennyi:

Akár LLM-et is be lehet vetni a klasszifikáláshoz:

category = llm.classify(ticket)

customer = get_customer(ticket.customer_id)

queue = routing_rules(
    category=category,
    customer_tier=customer.tier
)

send_to_queue(ticket, queue)

Ezzel semmi baj nincs.

Csak épp ez így sem feltétlenül lesz agent.

A műveletek sorrendjét, az elágazásokat és a kilépési feltételeket mind egy ember döntötte el előre - a modell csak egy komponens a workflow-ban.

Ez pedig azért fontos különbség, mert a workflow-oknak van egy jelentős mérnöki előnyük:

a control flow látható.

El lehet olvasni a kódot, és meg lehet válaszolni:

Mi történik ezután?

Egy agentnél az erre adható válasz jó eséllyel csak ennyi:

Attól függ, mit dönt a modell.

Ez pedig akkor hasznos, ha a környezet valóban felfedezést igényel.

És sokkal kevésbé hasznos, ha a folyamatot már réges-régen kitaláltuk.

Példa: LLM workflow vs agent

Képzeljük el, hogy egy dolgozó megkérdezi:

"Mi a helyzet a költségtérítésem elbírálásával?"

Egy workflow erre simán elég:

employee = get_employee(user_id)
expense = get_latest_expense(employee.id)
status = get_expense_status(expense.id)

return format_response(status)

Az LLM-et itt legfeljebb arra használjuk, hogy az eredményt természetes nyelvű válasszá alakítsa.

Ez pedig még mindig workflow marad.

Most képzeljük el, hogy a követelmény ehelyett ez:

"Segíts megoldani, bármi is legyen a dolgozó problémája a költségtérítésével."

Az agentnek ekkor már ilyesmit kell tennie:

Az érdekes rész itt nem az, hogy egy LLM be van vonva.

Az érdekes rész az, hogy a következő akció előre nem volt ismert.

Ez már agent-terep.

Ahol egy sima modell veri az agentet

Rengeteg olyan feladatot pitchelnek agent projektként, ami valójában klasszifikációs, regressziós vagy ranking probléma - olyasmi, amit a klasszikus ML már réges-régen jól kezel.

1. Ticket- és email-triázs

Input:

"Le tudom cserélni az előfizetésemhez tartozó bankkártyát?"

Output:

billing

Ez klasszifikáció, semmi több.

Egy történeti ticketeken tréningezett klasszifikáló ide természetes választás.

A rendszernek nem kell azon gondolkodnia, melyik tool-t hívja meg következőnek.

2. Churn prediction

Tegyük fel, hogy azt próbáljuk megjósolni, mekkora eséllyel mondja le egy ügyfél az előfizetést.

Lehet, hogy ezek az adataink:

account_age
monthly_spend
number_of_logins
support_tickets
days_since_last_login
feature_usage

A kimenet lehet:

P(churn) = 0.83

Egy gradient-boosted modell tökéletesen elboldogul ezzel:

model.predict_proba([
    customer_features
])

Egy agent, ami nyomozni kezd az ügyfél account-ja körül, talán tényleg lenyűgöző magyarázatot produkál.

De ha a tényleges követelmény ez:

"Adj egy churn-valószínűséget."

akkor egy milliszekundumos predikciós problémát cseréltünk le egy drága nyomozásra.

3. Csalásdetektálás

A fraud rendszereknek gyakran valami nagyon unalmas és nagyon értékes dologra van szükségük:

Mondjuk így:

risk = fraud_model.predict_proba(transaction_features)[0, 1]

if risk > 0.95:
    block(transaction)
elif risk > 0.75:
    review(transaction)
else:
    approve(transaction)

Itt általában azt akarjuk, hogy ugyanaz a bemenet mindig ugyanazt a döntést eredményezze.

Ha bevezetünk egy autonóm modellt, ami tetszőleges tool-okat vizsgálhat meg, és saját maga találhatja ki a nyomozási stratégiáját, azzal pont azt a fajta változékonyságot visszük be a rendszerbe, amit egy fraud pipeline-ban a legkevésbé szeretnénk.

4. Keresletelőrejelzés

Ha a holnapi keresletet próbáljuk megjósolni egy termékre, a modellnek nagyjából ezekre van szüksége:

történeti kereslet
szezonalitás
hét napja
promóciók
ár
ünnepnapok
időjárás

Majd:

Ez egy forecasting probléma, ahol nincs semmi hasznos szerepe egy olyan agentnek, ami azon töpreng, hogy:

"Meg kéne néznem, mi történt múlt kedden, mielőtt megjóslok bármit."

A modellnek ugyanis már ott van kedd is a training datasetben.

5. Hibadetektálás

Képzeljünk el egy gyártósort, ahol egy kamera minden legyártott alkatrészt megvizsgál.

A bemenet egy kép.

A kimenet:

OK

vagy:

DEFECT

Egy image classifier másodpercek alatt több ezer képkockát ki tud értékelni.

Nem kell hozzá agent, ami ránéz a képre, meghív egy tool-t, elgondolkodik rajta, újragondolja, majd végül klasszifikálja.

A gyárat ugyanis nem érdekli a modell belső monológja.

Csak a hibaarány.

Az agent használatának rejtett költsége

Az agentekkel nem az a probléma, hogy eredendően rosszak lennének.

Hanem hogy minden plusz szabadságfok egy újabb dolog, amit a production rendszernek el kell viselnie.

Vegyünk egy egyszerű klasszifikálót:

Most hasonlítsuk össze egy agenttel:

Minden újabb lépés hozhat magával latency-t, költséget, átmeneti hibákat, rossz tool-választást, hallucinációt, nem-determinisztikus viselkedést, state-management problémákat és observability-komplexitást.

És előbb-utóbb valakinek ezt az egészet el kell magyaráznia annak, aki felel az SLA-ért.

Minél több autonómiát adunk hozzá, annál drágább lesz a hiba.

Ahol egy agent tényleg megéri az árát

Mindettől persze még nem lesz az agent rossz választás mindenhol.

Vannak problémák, ahol az út tényleg nem ismerhető előre.

Vegyünk egy on-call asszisztenst.

Kap egy problémát:

"A checkout szolgáltatás megemelkedett 5xx hibaszámot ad vissza."

Talán ilyen tool-okat kap hozzá:

get_logs()
get_metrics()
get_deployment_history()
get_database_status()
get_feature_flags()
rollback_deployment()

Az agent innen felfedezhet valami ilyesmit:

A lényeg itt az, hogy ezt a pontos workflow-t nem feltétlenül lehetett volna előre megírni.

Az agent a megfigyelésekből fedezi fel az utat.

És ettől lesz hasznos.

A kutatás egy másik példa

Tegyük fel, hogy megkérdezzük:

"Derítsd ki, miért nőttek 30%-kal a felhőköltségeink múlt hónapban."

Itt nincs egyetlen előre meghatározott workflow.

Az agent talán így jut el a válaszig:

A következő kérdés mindig attól függ, mi volt az előző kérdésre a válasz.

Ez alapvetően más, mint ez:

Az előbbi feltárás.

Az utóbbi meg egyszerű leképezés.

A kódolóagentek is jó példák

Egy kódoló agent olyasmit tud csinálni, amivel egy statikus workflow eleve küszködne:

A környezet ugyanis visszajelzést ad az agentnek, ez a visszajelzés pedig megváltoztatja, mit kell tennie ezután.

Technikailag persze elő lehetne sorolni előre minden lehetséges sorrendet.

Ahogy technikailag azt is meg lehetne jósolni, milyen lesz az időjárás, ha minden egyes molekulától megkérdezzük, merre tart.

Csak épp egyik sem különösebben hasznos.

Egy hasznos mentális modell

A három kategóriáról nagyjából így érdemes gondolkodni:

És ez előtt még feltehetünk egy kérdést is:

Tehát a progresszió nagyjából ez:

Modell

Workflow

Agent

A hiba pedig az, ha rögtön a harmadikhoz ugrunk.

A kérdés, amit fel kell tenni, mielőtt agentet építünk

Az a reflex, hogy agenthez nyúljunk, teljesen érthető.

Az agentek érdekesek, jól finanszírozottak, és remekül demóznak.

Egy fix klasszifikáló, valljuk be, nem éppen konferencia-keynote-anyag.

Csakhogy a production rendszerek nem a legdivatosabb architektúráért osztanak pontot.

Azért osztanak pontot:

költség
latency
megbízhatóság
kiszámíthatóság
karbantarthatóság

Szóval mielőtt agent frameworkhöz nyúlnánk, érdemes feltenni a kérdést:

Létezik-e már a leképezés az inputtól a helyes outputig?

Ha igen, jöhet a következő:

Meg tudom-e tanulni ezt a leképezést olyan adatból, ami már megvan?

Ha igen, ott is kezdjük.

Ha a folyamat fix, de tartalmaz néhány intelligens lépést, építsünk workflow-t.

Ha viszont a következő akció valóban attól függ, mit fedez fel a rendszer, akkor jöhet szóba az agent.

A cél ugyanis nem az, hogy a lehető legautonómabb rendszert építsük meg.

A cél az, hogy a legegyszerűbb olyan rendszert használjuk, ami tényleg megoldja a problémát.

Néha ez egy agent.

Néha csak egy LLM-hívás.

Néha egy workflow.

És néha, kicsit ijesztő módon, sima logisztikus regresszió.

Ez megint nem az AI kudarca.

Ez csak a mérnöki hozzáállás.