Multimodális alkalmazások

Miért érdekel ez téged?

A multimodális rendszer ott dől el, ahol a legtöbben elrontják: nem a modellnél, hanem az input előkészítésénél és a kimenet validálásánál. Egy szkennelt PDF, egy hívásfelvétel vagy egy képernyőkép önmagában rendezetlen nyersanyag — a te dolgod, hogy olvasható, indexelhető, hivatkozható és ellenőrizhető formába hozd.

Gondolj rá úgy, mint egy tolmácsra egy tárgyaláson: nem elég, hogy két nyelvet beszél. Tudnia kell, mikor ki beszél, mi a lényeg, mit hagyjon ki, és hogyan adja vissza pontosan — különben a kommunikáció összeomlik. A vision- és audiomodellek a „nyelvtudás", de a rendszer, amit köréjük építesz, dönti el, hogy megbízható lesz-e. A modellek képességeiről a 1. LLM alapok fejezet ad hátteret, a multimodális retrievalről pedig a 4. RAG.

Miért fontos ez üzletileg? Mert a vállalati tudás túlnyomó része nem tiszta szövegben él. Egy tipikus szervezetnél a dokumentumok jelentős hányada szkennelt PDF, számla, szerződés, prezentáció vagy táblázat — olyan formátumok, amelyeket egy pusztán szöveges pipeline vagy egyáltalán nem lát, vagy roncsolt formában olvas be. Ha a multimodális előfeldolgozásod rossz, a fölötte futó legjobb modell és a legdrágább RAG sem tud pontos választ adni: a hiba már a lánc elején bekerült.

Dokumentumok

A dokumentum a legelterjedtebb multimodális input: szerződések, számlák, orvosi leletek, tudományos cikkek. A kihívás az, hogy a jelentés nem csak a szavakban, hanem az elrendezésben, a táblázatokban és az ábrákban is benne van — ezeket mind rendezett formába kell hozni, mielőtt a modell dolgozni tud velük. Egy 50 oldalas, ábrákkal és táblázatokkal teli riport nem egyszerűen „ötvenszer annyi szöveg", hanem ötven különböző elrendezési probléma.

• OCR Az Optical Character Recognition kép alapú tartalomból (szkennelt PDF, fotózott számla, kézírás) géppel olvasható szöveget készít. A modern vision modellek beépítve is tudják, de dedikált OCR-motor nagy volumennél gyakran pontosabb és jóval olcsóbb — mérd meg, mielőtt mindent a legdrágább modellel olvastatsz fel. Nagyságrend: egy klasszikus OCR-motor oldalanként töredék centet fogyaszt, míg egy nagy vision modellel felolvastatott oldal ennek sokszorosa lehet — 10 000 oldalnál ez már érezhető havidíj-különbség.
• Layout (elrendezés-felismerés) Az oldal szerkezetének azonosítása: cím, bekezdés, hasáb, táblázat, fejléc, lábléc. Analógia: a nyers OCR olyan, mintha valaki felolvasná egy újságoldal összes szavát fentről lefelé, oszlopokon átugrálva — érthetetlen kása lesz belőle. A layout-felismerés tudja, hol a hasábhatár, így a szöveg olvasható sorrendben marad. Ez az a lépés, amit a legtöbben kihagynak, és utána csodálkoznak, miért ad rossz válaszokat a RAG egy egyébként „jól beolvasott" PDF-re.
• Táblázatok A táblázatból nem csak a szöveget, hanem a cellastruktúrát is ki kell nyerni: sorok, oszlopok, összevont cellák, fejlécek. Egy csendben elrontott táblázat-parse a legveszélyesebb hiba — a modell magabiztosan a rossz cellához rendeli a számot, és nem tűnik fel senkinek. Példa: ha egy összevont fejléccella miatt a „2024 Q3" oszlop számai a „2024 Q2" fejléc alá csúsznak, a modell konzisztensen rossz negyedévet fog idézni, és semmi nem jelzi a hibát.
• Chartok (diagramok) Oszlop-, vonal- és kördiagramok értelmezése: a tengelyek, feliratok, mértékegységek és trendek kiolvasása. Sok dokumentumban a lényeg épp az ábrában van, nem a szövegben — egy pénzügyi riport üzenete gyakran egyetlen grafikon. A vision modellek a durva trendet („emelkedik") jól olvassák, de a pontos értékeket (mekkora oszlop pontosan) gyakran becslik; ha a szám kritikus, keresd meg a mögöttes adattáblát, ne a grafikonról olvastasd le.
• Képaláírások Az ábrákhoz, táblázatokhoz, fényképekhez tartozó felirat hozzárendelése a megfelelő vizuális elemhez. Ha a caption elszakad a képétől, elveszik a kontextus: a „3. ábra: éves bevétel" felirat önmagában semmit sem ér a hozzá tartozó grafikon nélkül. A gyakorlatban a caption és a hozzá tartozó régió közelségét (bounding box távolság) használjuk a párosításra.
• Lábjegyzetek A láb- és végjegyzeteket el kell választani a főszövegtől, de a hivatkozásukat meg kell őrizni. Ha összekevered őket, a lábjegyzet szövege beékelődik egy bekezdés közepébe, és értelmetlen mondatokat gyárt a modellnek. Jogi és tudományos dokumentumoknál a lábjegyzet gyakran a legfontosabb rész (kivételek, feltételek) — nem szemét, amit ki lehet dobni.
• Többoszlopos oldalak Tudományos cikkek, újságok, brosúrák hasábos elrendezése. A helyes olvasási sorrend rekonstruálása kritikus: a bal hasáb végéről a jobb hasáb tetejére kell lépni, nem soronként átvágni az oldalon — különben a mondatok félbeszakadnak. Egy kétoszlopos oldal soronkénti olvasása szó szerint minden mondatot kettévág, és a szöveg kaotikus lesz.
• Oldalszintű és régiószintű retrieval Nem mindegy, hogy találatként egy egész oldalt adsz vissza, vagy pontosan azt a régiót (bekezdést, táblázatot, ábrát), amelyik a választ tartalmazza. A régiószintű retrieval szűkebb, olcsóbb és pontosabb kontextust ad a modellnek — kevesebb zaj, kevesebb token. Egy sűrű A4-es oldal 800–1200 token; ha csak a releváns 150 tokenes bekezdést adod be, tisztább kontextust és olcsóbb hívást kapsz.
• Vizuális és szöveges embeddingek A dokumentumot indexelheted a kinyert szöveg alapján (szöveges embedding), vagy a lap képi reprezentációja alapján (visual embedding), ami megőrzi az elrendezést és az ábrákat. A multimodális RAG a kettőt kombinálja, hogy táblázatból és diagramból is tudjon bizonyítékot gyűjteni — erről bővebben a 4. RAG fejezet. A visual embedding (pl. ColPali-szerű megközelítés) épp azoknál a dokumentumoknál nyer, ahol az OCR gyenge: kézírás, rossz szkennelés, komplex layout.
• Bounding box és page reference Minden kinyert adathoz tárold el, melyik oldalon és a lap melyik koordináta-téglalapjában (bounding box) volt. Ez teszi a választ visszakereshetővé és ellenőrizhetővé: nem csak azt tudod, mi a válasz, hanem azt is, pontosan honnan származik. A bounding box tipikusan négy szám (x, y, szélesség, magasság) az oldal koordinátarendszerében — ebből tudsz a UI-ban egy sárga kiemelést rajzolni a forrásra.
• Multimodal citation A generált válasz ne csak szövegrészletre hivatkozzon, hanem a konkrét oldalra, régióra vagy ábrára, amelyet a felhasználó ránézésre ellenőrizhet. Ez a grounding vizuális megfelelője: a bizalom alapja, hogy a forrás egy kattintással látható. A jó multimodal citation UX-ben a válasz mellett ott a forrásoldal thumbnailje, a kérdéses régió kiemelve — a felhasználó másodpercek alatt ellenőriz.

A dokumentum-pipeline lépései

A dokumentumfeldolgozás nem egyetlen modellhívás, hanem egy több lépcsős pipeline, ahol minden lépés kimenete a következő bemenete. Érdemes fejben tartani a teljes láncot, mert mindegyik lépés önálló hibaforrás és önálló mérési pont:

A gyakorlatban ez azt jelenti, hogy a modellhívás önmagában triviális — a nehéz munka a kép előkészítése és a válasz forráshoz kötése. Íme egy minimális példa, ahol nem csak az értéket kérjük, hanem az oldalszámot is, hogy a válasz hivatkozható legyen:

from openai import OpenAI

client = OpenAI()
resp = client.responses.create(
    model="gpt-4.1",
    input=[{
        "role": "user",
        "content": [
            {"type": "input_text",
             "text": "Add vissza a számla végösszegét és az oldalt, ahol találtad."},
            {"type": "input_image", "image_url": "https://pelda.hu/szamla-2.png"},
        ],
    }],
)
print(resp.output_text)  # pl. {"total": "128 400 Ft", "page": 2}

A page reference nem díszítés: e nélkül a felhasználó nem tudja ellenőrizni a választ, és egy hallucinált végösszeg észrevétlenül továbbmehet egy pénzügyi rendszerbe. Amit tanulj belőle: mindig kérj a modelltől lokációt (oldal, régió) a nyers érték mellé — a strukturált kimenet kikényszerítéséről a 3. Structured output fejezet ad receptet.

Chunking és extrakció megbízhatóan

A dokumentum darabolása (chunking) multimodális kontextusban nem lehet vak, karakterszám-alapú vágás. Egy táblázatot vagy egy ábra + caption párost soha ne vágj ketté chunk-határon, mert a fél táblázat félrevezető. A layout-alapú chunking a régiókat tartja egyben: egy táblázat egy chunk, egy szakasz egy chunk. Az alábbi minta azt mutatja, hogyan kérj egyszerre strukturált táblázatot és forrásmetaadatot Pydantic-kel:

from pydantic import BaseModel
from openai import OpenAI

class TablaSor(BaseModel):
    megnevezes: str
    ertek: str

class TablaKivonat(BaseModel):
    oldal: int
    fejlecek: list[str]
    sorok: list[TablaSor]

client = OpenAI()
resp = client.responses.parse(
    model="gpt-4.1",
    input=[{"role": "user", "content": [
        {"type": "input_text", "text": "Nyerd ki a táblázatot és az oldalszámot."},
        {"type": "input_image", "image_url": "https://pelda.hu/riport-4.png"},
    ]}],
    text_format=TablaKivonat,
)
print(resp.output_parsed.oldal, resp.output_parsed.sorok)

Amit tanulj belőle: a séma kikényszeríti, hogy a modell tényleg sorokra és oszlopokra bontsa a táblázatot, ne szabad szöveggé mossa össze — és az oldal mező garantálja, hogy minden kivonat visszakereshető marad.

Multimodális RAG: szöveges vs vizuális index

A dokumentum-RAG-nél az első nagy döntés, hogy mit indexelsz: a kinyert szöveget, a lap képét, vagy mindkettőt. Nincs univerzális győztes — a dokumentum jellege dönt:

Gyakori hibák dokumentumfeldolgozásnál

• Layout-lépés kihagyása Nyers OCR-t adsz a RAG-nak layout nélkül. Hasábos vagy táblázatos oldalaknál ez összekevert szöveget eredményez, és a hiba láthatatlan, mert a szöveg „olvashatónak" tűnik darabokban.
• Táblázat félbevágása chunk-határon A karakterszám-alapú chunking a táblázat közepén vág. A fejléc az egyik chunkba, a számok a másikba kerülnek, és a modell fejléc nélküli számokat kap — értelmezhetetlen.
• Metaadat elhagyása Beindexeled a szöveget oldal és bounding box nélkül. Utólag nem tudsz citationt adni, a válasz nem ellenőrizhető, és a rendszer bizalmatlanná válik.
• Minden oldalt a legdrágább modellel olvastatsz Nem méred, hogy egy olcsó OCR-motor elég lenne-e. Nagy volumennél ez feleslegesen sokszoros költség — előbb mérj, aztán válassz modellt.

Audio

Az audio a leggyorsabban felnőtt modalitás: a valós idejű hangalapú (voice) agentek 2026-ban már nem kísérleti demók, hanem mainstream terméktípus — ügyfélszolgálat, asszisztensek, hívásösszefoglalók. A nehézség itt a latencia és a beszélgetés természetessége: egy döcögő, egymás szavába vágó bot azonnal leleplezi magát.

• Speech-to-text (STT) A beszéd átírása szöveggé — minden hangos interfész belépőpontja. A pontosság erősen nyelv- és zajfüggő; a magyar nyelvre gyengébb lehet, mint az angolra, ezért a modellválasztást itt is mérni kell, nem feltételezni. A minőséget általában word error rate (WER) mutatóval mérik: tiszta angolra a jó modellek pár százalékos WER-t érnek el, zajos magyar telefonos hangnál ez könnyen a többszörösére nő.
• Text-to-speech (TTS) A szöveg természetes hangzású beszéddé alakítása — a voice agent kimeneti oldala. A minőség (intonáció, tempó, hangszín) közvetlenül hat arra, mennyire érzi a felhasználó emberinek a beszélgetést. Fontos részlet a first-byte latency: az számít, milyen gyorsan szólal meg az első hang, nem az, mikor ér a mondat végére — ezért streamelve generáld a hangot mondatrészenként.
• Diarization Annak felismerése, „ki mikor beszélt": a hangsáv beszélőkre bontása. Analógia: mint egy jegyzőkönyv, amely minden mondat mellé odaírja, ki mondta. Meetingek és hívásátiratok elengedhetetlen eleme, különben egy összefolyó monológ marad. Egy ügyfélszolgálati hívásnál a diarization nélkül nem tudod szétválasztani, mit ígért az ügyintéző és mit kért az ügyfél.
• Voice activity detection (VAD) Felismeri, mikor van egyáltalán beszéd a csendhez vagy zajhoz képest. Így nem küldöd feleslegesen a csendet a felismerőnek, és pontosan tudod, hol kezdődik és végződik egy megszólalás — ez alapozza meg a valós idejű feldolgozást. A VAD egyben költségcsökkentő is: a csend átírása fizetett token és felesleges latencia lenne.
• Streaming A hangot és az átiratot folyamatosan, apró darabokban dolgozod fel, nem a beszéd végén egyben. Ez teszi lehetővé, hogy az agent már reagáljon, miközben a felhasználó még beszél — a valós idejű élmény alapfeltétele. A streaming nélkül a felhasználó a teljes mondat kimondása után még másodperceket vár a válaszra, ami telefonon elviselhetetlen.
• Interruptibility A felhasználó félbe tudja szakítani az agentet, ahogy egy valódi beszélgetésben. Enélkül a bot végigmondja a monológját, miközben a user már rég mást kérdez — ez a leggyakoribb oka annak, hogy egy voice agent frusztrálónak érződik. A helyes viselkedés: amint a VAD user-beszédet érzékel, a TTS azonnal elhallgat (barge-in).
• Turn detection Annak felismerése, mikor fejezte be a másik a mondandóját, és mikor kerül sorra a válasz. Analógia: mint telefonban, amikor ösztönösen érzed, mikor a te köröd beszélni. Rosszul beállítva a bot vagy türelmetlenül közbevág, vagy kínosan sokáig hallgat. A jó turn detection nem pusztán csendhossz-alapú, hanem a mondat prozódiáját is figyeli (befejezetlen intonáció = még nem az én köröm).
• Zajszűrés A háttérzaj (kávézó, utca, billentyűzet) eltávolítása a felismerés előtt. A tisztább jel jobb átiratot ad — és mivel a hibák halmozódnak, egy rossz STT-kimenet az egész beszélgetést félreviszi. Egy call center környezetben a zajszűrés önmagában több százalékpontot javíthat a WER-en.
• Real-time latency A teljes kör (hang be → STT → modell → TTS → hang ki) alatt eltelt idő. Ha ez túl nagy, a beszélgetés akadozik és kínossá válik; a cél a néhány száz milliszekundumos válaszidő — az emberi beszélgetésben a fordulóközi szünet tipikusan 200 ms körüli, így ~500–800 ms fölött már érezhetően „robotos" a bot. A latencia UX-vetületeiről lásd a 19. Product/UX fejezetet.
• Audio consent és retention A hangfelvétel személyes adat: rögzítés előtt beleegyezés kell, és szabályozni kell, meddig és hol tárolod. Ez GDPR-releváns kérdés — a „minden hívást naplózunk mindenre" megközelítés adatvédelmi incidenssé válhat. A gyakorlatban tárolj a lehető legkevesebbet a lehető legrövidebb ideig, és különítsd el az átiratot a nyers hangtól. Az adatkezelés observability-oldalát a 14. Observability fejezet is érinti.

A voice agent pipeline: cascaded vs duplex

Két alapvető architektúra létezik. A cascaded (láncolt) modell külön STT + LLM + TTS komponenseket fűz össze, a duplex (speech-to-speech) modell egyetlen modellben kezeli az egészet. Az egyik hibakereshetőbb, a másik gyorsabb és természetesebb:

Döntési szempontok voice agent tervezésekor

Kép és videó

A tisztán vizuális feladatoknál a modell nem dokumentumot olvas, hanem jelenetet ért: tárgyakat, összefüggéseket, mozgást. A videó ehhez hozzáteszi az időtengelyt, ami a feldolgozást nagyságrendekkel drágábbá teszi — ezért a legfontosabb döntés itt az, hogy egyáltalán mit adsz be a modellnek.

Miért drága a videó? Mert egy 10 perces, 30 FPS-es videó 18 000 képkocka. Ha ezt mind beadnád egy vision modellnek, az képenkénti több száz–ezer token miatt milliós nagyságrendű tokent és irreális költséget jelentene. Ezért a videó feldolgozása mindig a képkockák okos kiválasztásával kezdődik, nem a nyers streammel.

• Image understanding A kép tartalmának értelmezése: objektumok, jelenet, a képen látható szöveg és azok viszonya. Ez a vizuális megértés alapja. Fontos költségtudnivaló: a legtöbb vision modell a képet felbontástól függően „csempékre" (tile) bontja, és minden csempe tokenbe kerül — egy nagy felbontású kép így jóval drágább, mint egy lekicsinyített. Ha nem kell a részlet, csökkentsd a felbontást.
• Image generation Szöveges leírásból új kép előállítása. Termékvizualizáció, illusztráció, prototípus — a promptból pixel lesz. Éles rendszerben figyelj a jogi és brand-kockázatra: a generált képen ne jelenjen meg védett logó vagy valós személy engedély nélkül; érdemes tartalomszűrőt tenni a kimenetre (lásd 15. AI security).
• Image editing Meglévő kép módosítása utasításra: háttércsere, objektum eltávolítása, inpainting. A szerkesztés megőrzi az eredeti kép nagy részét, csak a maszkolt régiót írja újra. Tipikus üzleti use case: termékfotó hátterének egységesítése egy webshopban több ezer képnél, emberi retusálás helyett.
• Visual grounding Egy szöveges hivatkozás összekötése a kép konkrét régiójával, pl. „a bal felső piros gomb". Ez teszi a vizuális választ pontossá: nem csak azt mondja a modell, hogy „van egy gomb", hanem koordinátával megmutatja, melyik. Ez a képi megfelelője a dokumentumos bounding boxnak, és ugyanúgy az ellenőrizhetőség alapja.
• Frame sampling Videóból reprezentatív képkockák kiválasztása feldolgozásra — nem minden frame-et adsz a modellnek. Analógia: fotóalbumot lapozgatsz a teljes film megnézése helyett, így töredék költséggel megvan a lényeg. Egyszerű stratégia a fix ütemű mintavétel (pl. 1 frame másodpercenként), okosabb a jelenetváltásra időzített mintavétel, ami a tartalmilag fontos pillanatokat kapja el.
• Temporal reasoning A képkockák közti időbeli összefüggések értelmezése: mi történt előbb, mi okozott mit. E nélkül a videó csak összefüggéstelen állóképek halmaza. Példa: egy biztonsági felvételen a „bement, majd kivett valamit, majd kiment" sorrend a lényeg — egyetlen frame-ből ez nem derül ki, csak a sorrendből.
• Scene detection A videó jelenetekre és vágásokra bontása, hogy szegmensenként lehessen keresni és összefoglalni — mint egy könyv fejezetekre osztása. A scene detection egyben a frame sampling alapja is: minden jelenetből elég néhány reprezentatív kockát venni, nem az egészet.
• Multimodális keresés Kereszt-modális keresés: kép alapján szövegre, szöveg alapján képre. Pl. „keresd meg a képet, amin piros autó van" — a lekérdezés és a találat más modalitásban van. Ez közös embedding-térben (pl. CLIP-szerű modellel) történik, ahol a hasonló jelentésű kép és szöveg egymáshoz közel kerül.

Frame sampling a gyakorlatban

A videófeldolgozás legfontosabb mérnöki döntése a mintavételi stratégia, mert ez határozza meg a költséget és a pontosságot is. Az alábbi minta egy jelenetváltás-vezérelt mintavétel vázát mutatja — a lényeg, hogy ne minden frame-et, hanem jelenetenként néhányat adj a modellnek:

def sample_frames(scenes, per_scene=2):
    """scenes: [(start_ts, end_ts), ...] — scene detection kimenete."""
    selected = []
    for start, end in scenes:
        step = (end - start) / (per_scene + 1)
        for i in range(1, per_scene + 1):
            selected.append(start + i * step)  # timestamp
    return selected  # ezekhez a ts-ekhez dekódolsz 1-1 frame-et

# 10 perc, 50 jelenet, jelenetenként 2 frame -> 100 frame,
# szemben a nyers 18 000 frame-mel (30 FPS).

Amit tanulj belőle: a jó mintavétel a képkockaszámot két-három nagyságrenddel csökkenti (18 000 → ~100), miközben megtartja a tartalmilag fontos pillanatokat — a költség és a latencia is ezzel arányban esik.

UI-vezérlő agentek

Az UI-vezérlő (computer-use) agentek úgy dolgoznak, mint egy ember a gép előtt: nézik a képernyőt, kattintanak, gépelnek, űrlapot töltenek ki. Ez az egyik leggyorsabban fejlődő terület — de egyben az egyik legtörékenyebb is, mert egy nem az API-nak, hanem az emberi felületnek tervezett világban kell megbízhatóan cselekednie.

• Screenshot understanding Az agent a képernyőképet „látja" és értelmezi: hol vannak a gombok, mezők, menük, szövegek. Analógia: mint egy új munkatárs, aki csak a monitorra néz, és onnan próbálja kitalálni, mit kell csinálni — dokumentáció és API nélkül. A screenshot understanding a computer-use belépőpontja, de egyben a leglassabb és legdrágább lépés is, mert minden lépéshez új képet kell értelmezni.
• Coordinate grounding A felismert elemhez pixelkoordinátát rendel, ahová kattintania kell. Ez a lánc leggyengébb pontja: ha a UI elcsúszik, más felbontáson fut, vagy egy popup megjelenik, a koordináta elavul, és az agent rossz helyre kattint. Ezért kritikus a kattintás utáni ellenőrzés: tényleg az történt, amit vártál?
• DOM használata, amikor elérhető Weboldalnál a DOM (a strukturált HTML) sokkal megbízhatóbb, mint a pixelre kattintás: az elemet a szerepe és azonosítója alapján éred el, nem a helyzete alapján. Ha hozzáférsz, a screenshot helyett vagy mellett mindig a DOM-ot részesítsd előnyben. Egy button[data-testid="submit"] szelektor nem csúszik el felbontásváltáskor, egy pixelkoordináta igen.
• Browser automation A böngésző programozott vezérlése: navigálás, kattintás, űrlapkitöltés, várakozás elemekre — Playwright- vagy Puppeteer-szerű eszközökkel. Ez a bejáratott, determinisztikusabb réteg a nyers pixelvezérlés alatt. A browser automation azért erős, mert megvárja az elem megjelenését (explicit wait), nem vakon kattint egy fix koordinátára.
• Computer use Az agent nem csak a böngészőt, hanem az egész gépet vezérli: egeret, billentyűzetet, tetszőleges alkalmazást. Ez a legáltalánosabb és egyben legkockázatosabb képesség, mert olyan műveletekhez is hozzáfér, amelyeknek nincs biztonságos API-ja. Ezért mindig izolált környezetben (sandbox, külön VM vagy konténer) futtasd, korlátozott jogosultságokkal — a prompt injection itt akár fájltörléshez is vezethet (lásd 15. AI security).
• Action confirmation Kockázatos vagy visszafordíthatatlan műveletek (vásárlás, törlés, üzenetküldés) előtt emberi jóváhagyás. Kapcsold össze a 19. Product/UX jóváhagyási pontjaival: a felhasználó lássa és hagyja jóvá, mielőtt az agent megnyomja a „Fizetés" gombot. A megbízható elv: az olvasás (navigálás, keresés) mehet automatikusan, az írás (tranzakció, törlés) emberi megerősítést kérjen.
• Backend-state ellenőrzés Annak validálása, hogy a művelet a rendszerben ténylegesen megtörtént — nem csak a képernyő mutat sikert. Egy „Sikeres rendelés" felirat még nem jelenti, hogy a rendelés valóban létrejött az adatbázisban. Ha van rá API vagy adatbázis-lekérdezés, azzal ellenőrizz, ne a képpel — a kép a leggyengébb bizonyíték.

DOM vs pixel: melyiket mikor

A computer-use agent egy zárt cselekvési hurokban dolgozik: érzékel, célra lő, cselekszik, majd ellenőrzi, hogy tényleg megtörtént-e. A lánc leggyakoribb bukása a validáció kihagyása — ezért a hurok nem a kattintással, hanem a backend-ellenőrzéssel zárul:

A computer-use agent megbízhatósága nagyrészt azon múlik, hogy mennyire tudsz a törékeny pixel-kattintás helyett a stabil, strukturált DOM-ra támaszkodni. A kettő nem kizárja egymást — sokszor a DOM az elsődleges, a screenshot pedig a tartalék, amikor a felület nem ad DOM-ot (natív app, canvas, távoli asztal):

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    page = p.chromium.launch().new_page()
    page.goto("https://pelda.hu/rendeles")
    page.click("button[data-testid='submit']")   # stabil DOM-szelektor
    page.wait_for_selector("text=Rendelés rögzítve")  # UI visszajelzés

    # NE állj meg a UI-nál: validáld a backend állapotot is!
    order = api_get_order(order_id)               # forrásrendszer lekérdezés
    assert order["status"] == "confirmed"

Amit tanulj belőle: a wait_for_selector a UI-visszajelzést várja, de a valódi bizonyíték a backend-lekérdezés. A kettő együtt zárja ki, hogy egy cache-elt vagy elavult képernyő „sikert" hazudjon.

Gyakori hibák UI-vezérlő agenteknél

• Vakon kattintás fix koordinátára Nem vársz az elem megjelenésére, hanem betöltés után rögtön egy pixelre kattintasz. Ha az oldal lassabb, vagy egy banner feljön, rossz helyre kattintasz. Használj explicit várakozást és DOM-szelektort.
• UI-siker = valódi siker feltételezése A „Rendelés rögzítve" feliratra hagyatkozol, backend-ellenőrzés nélkül. A képernyő hazudhat; a forrásrendszer az igazság.
• Sandbox nélküli computer use Teljes jogosultsággal, éles gépen futtatod az agentet. Egy prompt injection vagy egy félreértett utasítás visszafordíthatatlan kárt okozhat — izolálj és korlátozz.
• Hiányzó action confirmation Az agent emberi jóváhagyás nélkül hajt végre visszafordíthatatlan műveletet (fizetés, törlés). Az írás jellegű lépések mindig kérjenek megerősítést.

Közös mérnöki elvek minden modalitásra

Bár a dokumentum, az audio, a kép és a UI-vezérlés különböző, ugyanaz a néhány mérnöki elv teszi őket megbízhatóvá. Ha ezeket minden modalitásnál betartod, a rendszered demóból üzemeltethető termékké válik.

• Grounding és hivatkozhatóság Minden kimenet vezessen vissza egy ellenőrizhető forráshoz: dokumentumnál oldal + bounding box, audiónál időbélyeg az átiratban, képnél régió, UI-nál a backend-állapot. A ground truth mindig valami ellenőrizhető, nem a modell szava.
• Validáció a modell után A modell kimenetét soha ne fogadd el vakon: strukturált outputnál sémavalidáció (3. Structured output), UI-nál backend-ellenőrzés, számoknál értéktartomány-check. A „csendes hiba" (magabiztos, de rossz válasz) a legveszélyesebb.
• Költségtudatos előfeldolgozás Ne a legdrágább modellel oldj meg mindent: OCR-nél olcsó motor, videónál frame sampling, képnél felbontáscsökkentés. Előbb mérj, aztán skálázz — a költségoptimalizálás rendszerezett tárgyalása a 12. Optimalizáció fejezetben.
• Evals modalitásonként Minden réteget külön mérj golden dataseten: OCR-pontosság, layout-helyesség, STT WER, UI task success rate. Csak így tudod, melyik lépés rontja a végeredményt. A multimodális evalről bővebben a 11. Evals fejezet szól.
• Adatvédelem és megőrzés A hang, a fotó és a dokumentum jellemzően személyes adat: gyűjts a lehető legkevesebbet, tárold a lehető legrövidebb ideig, és dokumentáld a jogalapot. Ez GDPR-kötelezettség, nem opció.

Összefoglalás

A multimodalitás nem a modell képessége, hanem egy pipeline: a nyers dokumentumot, hangot, képet és képernyőt rendezett, indexelhető, hivatkozható és validálható formába kell hoznod. A dokumentumoknál a layout, a táblázatok és a forráshivatkozás (bounding box, oldalszám) a kulcs; az audiónál a latencia, a turn detection és az adatvédelmi consent; a képnél és videónál az, hogy egyáltalán mit adsz be a modellnek (frame sampling, scene detection). Mindegyiknél igaz, hogy a hibák halmozódnak, ezért rétegenként kell mérni.

Az UI-vezérlő agentek a leggyorsabban fejlődő és egyben legtörékenyebb területet jelentik — itt a legfontosabb tanulság, hogy a képernyőn látott sikernek soha ne higgy önmagában: mindig a backend állapotot validáld, és ahol lehet, a törékeny pixel-kattintás helyett a stabil DOM-ra támaszkodj. A közös mérnöki elvek — grounding, validáció, költségtudatosság, modalitásonkénti evals, adatvédelem — kötik össze a négy területet. Ha ezeket a mérnöki rétegeket komolyan veszed, a multimodális rendszered nem demó marad, hanem megbízhatóan üzemeltethető termék lesz.