Product- és UX-ismeretek

Miért érdekel ez téged?

A legjobb modell is megbukhat a felhasználó szemében, ha a köré épített termék rossz. Az előző 18 fejezet a motorról szólt — a tokenekről, a retrievalről, az agentekről, az evalokról. Ez a fejezet arról, hogy mindezt hogyan érzi meg a felhasználó, és mitől lesz belőle valódi érték a képernyő túloldalán.

Egy AI-termék UX-e alapvetően más, mint egy hagyományos szoftveré, mert a rendszer nemdeterminisztikus: lassú lehet, tévedhet, és ugyanarra a kérdésre máskor mást válaszol. Egy hagyományos „mentés" gomb mindig ugyanazt csinálja; egy LLM-hívás ugyanarra a promptra ma egy három bekezdéses választ ad, holnap egy másikat, és néha magabiztosan hazudik. A jó UX ezeket a tulajdonságokat nem elrejti, hanem tudatosan kezeli — láthatóvá teszi a folyamatot, ellenőrizhetővé a kimenetet, és visszafordíthatóvá a hibát.

Fontos átállni egy szemléletre: az AI-terméknél a UI nem a modell után jön, hanem a modell része a terméknek. Ugyanaz a GPT-hívás lehet frusztráló vagy kellemes élmény attól függően, hogy streamelsz-e, mutatsz-e forrást, engedsz-e visszavonni. A mérnöki munka fele a promptban és a retrievalben van, a másik fele abban, ahogy a bizonytalan kimenetet emberi kézbe adod.

A nemdeterminizmus mint terméktervezési kihívás

Egy klasszikus alkalmazásnál a hibaállapotok végesek és megjósolhatók: a form vagy validál, vagy nem. Egy LLM-nél a „hiba" egy folytonos skála — a válasz lehet 90%-ban jó, egy rossz számmal a közepén, amit semmilyen kivételkezelő nem fog el. Ez háromféle új felelősséget ró a termékre, amelyek a fejezet gerincét adják:

• Láthatóság (a folyamat) Mivel a válasz lassan, lépésenként áll össze, a felhasználónak látnia kell, hogy a rendszer dolgozik és merre tart. Streaming, progress, „épp keresek a dokumentumokban" — ezek nem díszek, hanem a bizalom fenntartói egy 5-30 másodperces várakozás alatt.
• Ellenőrizhetőség (a kimenet) Mivel az LLM ugyanolyan magabiztosan mond igazat és valótlant, a felhasználónak eszközt kell adni, hogy kételkedni és ellenőrizni tudjon: forráshivatkozás, kiemelt bizonytalanság, több alternatíva. A jó termék nem hisz helyetted, hanem megmutatja, mire alapoz.
• Visszafordíthatóság (a hiba) Mivel a modell tévedhet, a hatással járó műveleteket vagy előzetes jóváhagyás, vagy utólagos undo kell hogy védje. Ha egy tévedésnek nincs olcsó visszaútja, akkor a funkció túl kockázatos ahhoz, hogy ember nélkül fusson.

Tudnod kell kialakítani

Ezek nem csak „szép” UI-elemek — mindegyik egy konkrét problémát old meg, ami abból fakad, hogy egy LLM lassú, tévedhet, és nem determinisztikus. Nézzük, miért fontos mindegyik pontosan az AI kontextusában, és hol van a határuk — mikor NE erőltesd rá a termékre.

A folyamat láthatóvá tétele

• Streaming válasz A választ tokenről tokenre jeleníted meg, nem egyben a végén. Egy LLM-generálás több másodpercig is tarthat — ha addig üres képernyőt bámul a felhasználó, azt hiszi, elakadt a rendszer. A streaming a percepcióban gyorsabbá tesz, még ha a teljes válaszidő ugyanannyi is: a time-to-first-token (TTFT) sokszor fontosabb az élményben, mint a teljes időtartam (lásd 1. LLM alapok). Egy tipikus chat-élményben a TTFT 0,3-1 másodperc, a teljes válasz 5-15 másodperc lehet — a felhasználó az elsőt éli meg „gyorsaságként". Hang- és multimodális agenteknél ide tartozik a félbeszakíthatóság (interruptibility) is (lásd 10. Multimodális). Mikor NE: ha a kimenet egy strukturált objektum, amit egyben validálsz és renderelsz (pl. egy táblázat vagy egy JSON-alapú UI), a token-szintű streaming félkész, ugráló állapotokat mutathat — ilyenkor jobb egy jól megtervezett progress-állapot.
• Progress indication Amikor egy agent több lépésen — keresés, tool-hívás, összegzés — megy végig, mutasd meg, épp hol tart. Egy gyors válasznál elég egy spinner, de egy 30 másodperces agent-futásnál a felhasználónak látnia kell, hogy „épp a dokumentumokban keresek", különben megszakítja. Olyan ez, mint az ételrendelés követése: nem gyorsul tőle a futár, de tudod, hogy halad, és nem hívod fel idegesen. A gyakorlatban a lépéseket a trace-adatokból tudod közvetlenül a UI-ra vezetni (lásd 14. Observability): minden tool-hívás egy-egy látható „állomás". Empirikus szabály: 1-2 mp alatt elég egy spinner, 2-10 mp között jelezd, mi történik, 10 mp fölött adj konkrét, változó státuszokat és ideálisan részeredményt is.

A kimenet ellenőrizhetővé tétele

• Forráshivatkozások A válasz mellé megmutatod, mely dokumentumból, melyik szakaszból származik az állítás. Mivel az LLM ugyanolyan magabiztosan mond igazat és valótlant, a forráshivatkozás az egyetlen mód, hogy a felhasználó ellenőrizni tudja a hallucinációt. Bizalmat épít, auditálhatóvá teszi a választ, és felelősséget helyez a forrásra — a RAG-fejezet claim-level groundingje itt válik látható termékfunkcióvá (lásd 4. RAG). A jó megoldás nem csak a dokumentum nevét adja, hanem mélylinkel a pontos szakaszra, és kiemeli a hivatkozott bekezdést. Mikor NE bízz benne vakon: az LLM néha „idéz" egy valós forrást egy olyan állításhoz, ami nincs benne — ezért a citation-t érdemes gépi grounding-ellenőrzéssel is alátámasztani, nem csak megjeleníteni.
• Bizonytalanság kommunikációja A rendszer jelezze, mennyire biztos a válaszban — és merjen nemet mondani, ha nincs elég alapja. Mivel az LLM kalibrálatlanul magabiztos, a „ezt nem találtam a forrásokban" vagy „ebben nem vagyok biztos" megfogalmazás megóvja a felhasználót a téves döntéstől. Ahogy egy jó orvos is „valószínűleg"-et mond a hamis bizonyosság helyett, úgy a jó AI-termék is őszinte a saját korlátairól. A gyakorlatban ez nem feltétlenül egy százalékos „confidence score" (ami maga is félrevezető lehet), hanem inkább viselkedés: ha nincs releváns forrás, ne találgasson, hanem mondja meg, hogy nem tudja. Antipattern: minden válasz mellé kitenni egy „87%" számot, ami valójában semmit sem mér — ez hamis pontosság érzetét kelti.
• Alternatív javaslatok Nyitott feladatoknál — szövegváltozatok, megoldási utak, dizájnötletek — egyetlen „helyes" válasz helyett kínálj több opciót. A felhasználó választ közülük, ami jobb élmény, és közben implicit feedbacket is ad arról, melyik irány tetszik. A determinisztikus, egyetlen válasz csak ott jó, ahol tényleg egy helyes megoldás van (pl. egy tényszerű lekérdezésnél). Mikor NE: ha a felhasználó gyors, egyértelmű választ vár (pl. „mennyi 2+2 típusú" tudásbázis-kérdés), három variáns csak zajt és döntési terhet ad.
• Clarification mechanizmus Ha a kérés kétértelmű, a rendszer kérdezzen vissza, ahelyett hogy találgat. Egy jó kolléga is visszakérdez, ha nem érti pontosan a feladatot; a rossz AI viszont magabiztosan elindul rossz irányba, és csak a végén derül ki, hogy félreértette. Egyetlen jól időzített tisztázó kérdés sok elpazarolt tokent és csalódást spórol meg — egy 20 másodperces, rossz irányba futó agent-futás drágább, mint egy másodperces visszakérdezés. A trükk az egyensúly: a túl gyakran visszakérdező asszisztens ugyanolyan idegesítő, mint a mindig találgató. Jó heurisztika: csak akkor kérdezz vissza, ha a kétértelműség több, drágán javítható kimenetet eredményezne.

A hiba visszafordíthatóvá tétele

• Módosítható terv Mielőtt az agent végrehajt egy több lépéses feladatot, mutasd meg a tervet, és engedd, hogy a felhasználó szerkessze. Így a félreértés a végrehajtás előtt javítható, nem utána, amikor már drága vagy visszafordíthatatlan a kár. Egy jó asszisztens is elmondja, mit tervez, mielőtt belevág egy nagy feladatba. Gondolj egy kódoló agentre, ami előbb felsorolja: „1. létrehozom a fájlt, 2. átírom a configot, 3. futtatom a teszteket" — itt a felhasználó egy kattintással kihúzhatja a veszélyes lépést. Ez a plan-then-execute minta az agentek egyik legfontosabb UX-mintázata (lásd 5. Agentek).
• Jóváhagyási pontok Destruktív vagy visszafordíthatatlan műveletek előtt — email kiküldése, fájl törlése, fizetés indítása — kérj kifejezett emberi jóváhagyást. Ez egyszerre UX- és biztonsági kérdés: a human-in-the-loop kontroll megvéd attól, hogy egy téves modelldöntés valós kárt okozzon (lásd 15. AI Security). A trükk a jó egyensúly: annyi jóváhagyás, amennyi a tét indokolja, nem több. Ha mindenre rákérdezel, a felhasználó „approval fatigue"-ba esik, és reflexből OK-t nyom — ilyenkor a jóváhagyás elveszti a védő funkcióját. Csoportosítsd a kis kockázatú lépéseket, és csak a valóban tétre menőket emeld ki.
• Undo lehetőség Ahol lehet, a jóváhagyás mellett/helyett tedd visszavonhatóvá a műveletet. AI kontextusban ez különösen értékes, mert a modell tévedhet: az undo csökkenti a hiba tétjét, így a felhasználó bátrabban, gyakrabban használja a rendszert. Olyan, mint a Ctrl+Z vagy egy biztonsági háló — a létezése önmagában bátorít a próbálkozásra. Technikailag gyakran a „soft delete" (30 napos visszaállítás), a piszkozat-mód vagy a verziózás valósítja meg. Fontos: az undo és a jóváhagyás nem versenyeznek — egy jól visszavonható művelet kevesebb blokkoló jóváhagyást igényel, ami gyorsabb élményt ad.
• Partial result Ha a feladat egy része sikerül, a másik nem, add vissza a részeredményt, ne dobj el mindent egy hibaüzenettel. Egy 10 dokumentumot feldolgozó agent 8 kész eredménye sokkal értékesebb, mint egy üres „Hiba történt" képernyő. A részleges siker is siker — csak legyél őszinte arról, mi maradt ki, és adj lehetőséget a hiányzó rész újrapróbálására. Ez szorosan kapcsolódik a production hibakezeléshez: a jól tervezett rendszer degradál, nem összeomlik (lásd 13. Production architektúra).

Emberi kontroll és tanulás

• Emberi escalation Legyen mindig út, amin a felhasználó — vagy maga az agent — átadhatja a feladatot egy embernek. Egy support-bot, amelyből nem lehet emberhez eljutni, több kárt és frusztrációt okoz, mint amennyi ügyet megold. Az escalation nem a rendszer kudarca, hanem a felelős tervezés része; a mérendő cél a jó időzítés, nem a nulla átadás. Jó gyakorlat: az agent maga ismerje fel, ha kicsúszik a hatásköréből (pl. dühös ügyfél, jogi kérdés, ismételt sikertelen próbálkozás), és proaktívan adja át — az átadáskor pedig vigye magával a teljes kontextust, hogy az ember ne nulláról kezdje.
• Feedback capture Építs be egyszerű módot — hüvelykujj fel/le, javítás, elfogadás/elvetés —, hogy a felhasználó jelezze, hasznos volt-e a válasz. Ez a feedback lesz a jövőbeli eval-dataset és a fejlesztés nyersanyaga (lásd 11. Evals). Feedback nélkül vakon fejlesztesz: nem tudod, min javíts, és nem látod, ha egy változtatás rontott. Az explicit feedback (👍/👎) ritka és torzított — a felhasználók inkább csak a rossz élményt jelzik —, ezért az implicit jelek gyakran értékesebbek: elfogadta a javaslatot? újrafogalmazta a kérdést? azonnal escalált? Ezek passzívan, extra kattintás nélkül gyűlnek.

Az alábbi táblázat összefoglalja, melyik UX-elem melyik alapproblémára válasz, és milyen tét mellett éri meg beépíteni:

Így néz ki streaming és forráshivatkozás a kódban

A streaming a legtöbb provider SDK-jában egy egyszerű, iterálható stream. A lényeg, hogy a szervered a tokeneket azonnal továbbadja a kliensnek (pl. Server-Sent Eventsként), és ne várja meg a teljes választ. Íme a legkisebb szemléltető minta:

from openai import OpenAI

client = OpenAI()
stream = client.chat.completions.create(
    model="gpt-4.1",
    messages=[{"role": "user", "content": "Foglald össze a Q3 jelentést"}],
    stream=True,  # a válasz darabokban érkezik
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        yield delta  # azonnal a UI-ra (pl. SSE-n keresztül)

Amit tanulj belőle: a stream=True önmagában nem gyorsítja a modellt, de a felhasználó az első token megjelenését éli meg gyorsaságként. A yield azonnal továbbküldi a darabot — ne gyűjtsd bufferbe, mert azzal pont a streaming előnyét dobod el.

A forráshivatkozáshoz a modellt strukturált kimenetre kényszeríted, hogy minden állítás mellé odategye, melyik forrásból származik — így a UI mélylinkelni tud a pontos szakaszra (lásd 3. Structured output):

from pydantic import BaseModel

class Claim(BaseModel):
    text: str          # egy állítás a válaszból
    source_id: str     # melyik chunkból származik
    quote: str         # a pontos idézett szakasz

class GroundedAnswer(BaseModel):
    summary: str
    claims: list[Claim]  # minden állítás visszavezethető forrásra

# A UI a claims listából emeli ki és linkeli a forrásokat,
# a quote mezőt pedig gépi grounding-ellenőrzésre használhatod.

Amit tanulj belőle: a citation nem szöveges dísz, hanem adat. Ha strukturáltan kéred vissza (source_id + quote), a terméked mélylinkelni és automatikusan ellenőrizni tudja, hogy az idézet tényleg szerepel-e a forrásban — ez a különbség a látszat-grounding és a valódi grounding között.

Gyakori hibák az AI-UX tervezésben

• „Big bang" válasz streaming nélkül A felhasználó 8 másodpercig üres képernyőt néz, majd hirtelen megjelenik minden. A percepcióban ez sokkal lassabbnak és megbízhatatlanabbnak hat, mint egy azonnal induló, folyó válasz — pedig a modell ugyanannyi ideig dolgozott.
• Approval fatigue Minden apró lépésre külön jóváhagyást kérsz. Két nap után a felhasználó reflexből nyomja az „OK"-t anélkül, hogy elolvasná — és pont a fontos jóváhagyást is átengedi. A jóváhagyás értéke a ritkaságában van.
• Néma hiba Az agent elakad egy tool-hívásnál, és vagy örökké pörög, vagy egy generikus „Hiba történt" jön. A felhasználó nem tudja, mit tehet. Adj konkrét okot, részeredményt és újrapróbálási utat.
• Hamis magabiztosság A modell forrás nélkül, magabiztos hangnemben állít egy tényt, a UI pedig ezt kritikátlanul tálalja. A felhasználó megbízik benne, és rossz döntést hoz — a hallucináció így termékkockázattá válik.
• Zsákutca escalation nélkül A bot körbe-körbe küldi a felhasználót, emberi kiútat nem kínál. Ez a leggyorsabb módja a bizalom és az ügyfél elvesztésének — a mentőöv hiánya többe kerül, mint az átadott ügyek maroknyi költsége.

Az ember–gép munkamegosztás szintjei

„Human-in-the-loop" nem egy kapcsoló, hanem egy skála. Ugyanaz a modell lehet teljesen kézivezérelt vagy majdnem autonóm — a helyes szint a tét és a modell megbízhatósága közötti egyensúlyból adódik. Minél nagyobb a kár egy hibából, annál több emberi kontroll indokolt.

• Human-in-the-loop (ember a hurokban) A modell javasol, az ember minden lépésnél jóváhagy vagy szerkeszt, mielőtt bármi történik. Ez a legbiztonságosabb, de a leglassabb. Ide tartozik a kódoló asszisztens, ami javasol, de te commitolsz, vagy az orvosi döntéstámogatás, ahol a diagnózist mindig ember mondja ki. Magas tét, alacsony hibatűrés esetén ez az alapértelmezett.
• Human-on-the-loop (ember a hurok fölött) A rendszer önállóan cselekszik, de az ember figyeli, és bármikor közbeavatkozhat vagy leállíthatja. Olyan, mint a repülőgép robotpilótája: magától repül, de a pilóta felügyel és átveheti az irányítást. Ide tartozik a legtöbb agentic workflow, ahol a kész eredményt utólag nézed át, nem minden lépést.
• Human-out-of-the-loop (teljes autonómia) A rendszer ember nélkül fut, utólagos auditra hagyatkozva. Csak ott indokolt, ahol a hiba olcsó és visszafordítható, vagy a volumen olyan nagy, hogy emberi ellenőrzés lehetetlen (pl. spam-szűrés, automatikus tagelés). Nagy tétű, visszafordíthatatlan műveleteknél kerülendő.

Döntési szempontok: mennyi autonómiát adj?

A legjobb metric

Az „accuracy" azt méri, hogy a válasz technikailag helyes-e. Csakhogy a felhasználót nem a helyesség érdekli önmagában, hanem az, hogy megoldódott-e a problémája. Egy tökéletesen pontos válasz, ami nem viszi előrébb az ügyet, a felhasználó szemében kudarc — a helytelenül feltett kérdésre adott helyes válasz haszontalan.

Ezért a production AI-rendszereket kimenet-alapú (outcome) metrikákkal érdemes mérni, nem pusztán a modellválasz minőségével. Íme az öt legfontosabb, és hogy melyik miért mond többet az accuracynál.

• Megoldódott-e a ticket (task resolution) A végeredmény számít, nem a köztes válaszok helyessége. Egy support-agentnél az igazi kérdés: lezárult-e az ügy anélkül, hogy a felhasználónak újra írnia kellett volna? Ez a metrika átfogja az egész rendszert — retrieval, tervezés, végrehajtás —, nem csak egyetlen modellhívást. Praktikus proxyk: a beszélgetés lezárult reopen nélkül, nem történt escalation, a felhasználó nem tért vissza ugyanazzal a problémával 24 órán belül.
• Elfogadta-e a felhasználó (acceptance rate) Kód-asszisztensnél elfogadta-e a javaslatot, szövegíró eszköznél megtartotta-e a generált szöveget? Az elfogadás a valós hasznosság közvetlen proxyja — és passzívan, extra kérdés nélkül mérhető. Egy „helyes", de a felhasználó által mindig elvetett javaslat valójában használhatatlan. Vigyázz a felszíni elfogadásra is: ha a felhasználó elfogadja, majd azonnal átírja a felét, az valójában gyenge minőség — érdemes a „megtartott arányt" (retained ratio) is nézni, nem csak a kattintást.
• Mennyi emberi munka maradt (human effort / deflection) Mennyivel csökkentette a rendszer az emberi ráfordítást? A részleges automatizálás is érték: ha a modell 80%-ban előkészíti a választ, és az embernek csak jóvá kell hagynia, az hatalmas megtakarítás — akkor is, ha nem volt 100%-ban „önjáró". A megspórolt emberórákban mérhető haszon gyakran meggyőzőbb, mint bármilyen accuracy-szám. Egy support-csapatnál a „deflection rate" (hány ügyet oldott meg a bot ember nélkül) közvetlenül fordítható pénzre.
• Történt-e hibás művelet (harmful action rate) Egyetlen rossz destruktív művelet — kitörölt adat, hibás fizetés, kiküldött téves email — többet árthat, mint amennyi hasznot száz jó válasz hoz. A kockázat aszimmetrikus, ezért ezt külön, szigorúan kell mérni és a lehető legalacsonyabban tartani, akár az összteljesítmény rovására is. Ez a metrika összeér a biztonsággal (lásd 15. AI Security): egy prompt injection okozta hibás művelet ide is beleszámít.
• Költség sikeres feladatonként (cost per successful task) Nem a nyers token- vagy hívásköltség a valódi gazdaságossági mérőszám, hanem a sikeres kimenetre vetített költség. Egy olcsó modell, amit háromszor kell újrafuttatni, drágább lehet, mint egy drágább, ami elsőre megoldja a feladatot. Ezt a metrikát a tracing- és eval-adataidból tudod kiszámolni (lásd 14. Observability és 11. Evals). Ez köti össze a UX-et az optimalizációval is (lásd 12. Optimalizáció): a sikeres kimenet a nevező, nem a nyers hívásszám.

Output-metrika kontra modell-metrika

A kettő nem ugyanaz, és a legtöbb kezdő hibája, hogy összekeveri őket. A modell-metrika (accuracy, F1, BLEU) egyetlen komponenst mér izoláltan; az output-metrika azt, amit a felhasználó ténylegesen megél. A jó termékcsapat mindkettőt figyeli, de a döntéseket az output-metrikák vezérlik.

Jó analógia egy étterem: hiába „technikailag ehető" a fogás (accuracy), a valódi kérdés az, hogy visszajön-e a vendég, ajánlja-e másnak, és megérte-e a konyhának előállítani. Ugyanígy az AI-terméknél is a kimenet, az elfogadás és a fajlagos költség mondja meg, hogy jó terméket építettél-e — nem a válaszok izolált pontossága.

Összefoglalás

Ez a fejezet zárja a kört: itt kapcsolódik össze a teljes technikai tudás a valós értékteremtéssel. A tokenek, a retrieval, az agentek és az evalok mind eszközök — a felhasználó a terméket látja, és azt méri, megoldotta-e a problémáját. A jó AI-UX nem elrejti a rendszer nemdeterminisztikus természetét, hanem tudatosan kezeli: láthatóvá teszi a folyamatot (streaming, progress), ellenőrizhetővé a kimenetet (forráshivatkozás, bizonytalanság, alternatívák), és visszafordíthatóvá a hibát (módosítható terv, jóváhagyás, undo, partial result, escalation).

Az ember–gép munkamegosztás nem kapcsoló, hanem skála: a human-in-the-loop, on-the-loop és out-of-the-loop szintek közül a tét és a bizonyított megbízhatóság dönt. Kezdj több emberi kontrollal, és csak adattal alátámasztva engedj belőle. És ne feledd: a jó AI-rendszer nem feltétlenül teljesen autonóm — a legtöbb érték a jól megtervezett ember–gép együttműködésből születik.

A siker mércéje sem az accuracy, hanem a kimenet: megoldódott-e a feladat, elfogadta-e a felhasználó, mennyi emberi munkát váltott ki, nem okozott-e kárt, és mennyibe került egy sikeres eredmény. Ha ezekre a kérdésekre tudsz jó terméket építeni és jól mérni, akkor a technikai tudásod valódi hatássá vált — és ezzel készen állsz felmérni, mely kompetenciaterületeket tudod már bizonyítani.