Hogyan válaszoljon az AI „azonnal"? — Streaming és valós idejű AI a gyakorlatban

A 8 másodperces csend, ami megöli az AI termékedet

Képzeld el: az ügyfeled rákattint a chat ikonra a weboldaladon, beír egy kérdést — és a képernyő üres marad. 1 másodperc. 3 másodperc. 5 másodperc. Az ügyfél már gyanakszik. 8 másodperc. Bezárja a böngészőt.

Pedig az AI háttérben dolgozott. Lekérdezte a CRM-et, kereste a tudásbázisban, generált egy részletes választ. Csak épp nem szólt róla a felhasználónak.

Ez a különbség egy demo-szintű AI integráció és egy produkciós AI termék között. És a megoldás nem az, hogy gyorsítsd fel az LLM-et — az fizikai korlát. A megoldás: streaming.

A Google kutatása szerint a felhasználók 53%-a elhagyja azt az oldalt, ami 3 másodpercnél tovább tölt be. Ugyanakkor egy modern LLM (GPT-4o, Claude, Gemini) komplex kérdésre adott válasza — különösen tool calling-gel és RAG kontextussal — 5–15 másodpercig is tarthat. A két szám nem fér össze. Ezt a szakadékot hidalja át a streaming architektúra.

Ez a cikk áttekinti, mit jelent a valós idejű AI gyakorlatban, miért az SSE az iparági alapértelmezés, hogyan tedd észrevétlenné a 8 másodperces várakozást, és milyen produkciós csapdák várnak rád, amikor élesbe áll a rendszer.

---

A percepció pszichológiája: miért nem a sebesség számít

Az emberi agy nem stopperórával méri a válaszidőt. Várakozást mér. És a várakozás nem ugyanaz, ha üres képernyőt nézel, mint ha látod, hogy „valami történik".

A klasszikus UX-skála szerint:

• 0–100ms: azonnali
• 100ms–1s: gyors, de észrevehető
• 1–3s: „gondolkodik" — még elfogadható, ha van visszajelzés
• 3–10s: lassú, de tolerálható, ha látsz valamit közben
• 10s+: elfogadhatatlan

A streaming nem csökkenti a tényleges válaszidőt — egy 8 másodperces LLM válasz továbbra is 8 másodperc. Amit csökkent, az a Time to First Byte (TTFB): az az idő, amíg a felhasználó az első karaktert látja.

Streaming nélkül a TTFB = a teljes válaszidő (8s). Streaming-gel a TTFB = ~50–500ms. Ez a különbség az „azonnali" és az „elfogadhatatlan" élmény között.

Ezért gépel a ChatGPT karakterről karakterre, ezért „beszél" a Claude folyamatosan, ezért látsz a Gemini-nél azonnali választ. Nem azért, mert látványos — hanem mert enélkül használhatatlan lenne.

---

SSE, WebSocket, HTTP/2 — melyik kell az AI-hoz?

Amikor felmerül a streaming, a fejlesztők gyakran a WebSocket-re ugranak, mert „úgy szokás". Pedig az AI chat streaming-hez az SSE (Server-Sent Events) szinte mindig a jobb választás.

Miért SSE?

Az SSE egy egyszerű HTTP-alapú streaming: a szerver egy nyitott kapcsolaton küldi az adatokat, a kliens egy EventSource objektummal fogadja. Néhány előnye:

• HTTP-alapú: átmegy minden proxy-n, CDN-en, load balancer-en, vállalati tűzfalon
• Beépített újrakapcsolódás: a böngésző automatikusan visszacsatlakozik megszakadás után
• Egyszerű implementáció: szerver oldalon res.write(), kliensen new EventSource(url)
• Minden nagy LLM provider SSE-t használ: OpenAI, Anthropic, Google, Mistral

Mikor kell mégis WebSocket?

Két eset:

1. Voice AI — a hangadat bináris, az SSE csak szöveget tud
2. Kétirányú stream — ha a kliens a stream közepén szeretne adatot küldeni a szervernek (pl. „stop generating" gombbal). SSE-vel ezt csak külön HTTP kérésen lehet megoldani

A HTTP/2 és HTTP/3 (QUIC) szintén jobbá teszik a streaming-et — multiplexelt stream-ek egy TCP kapcsolaton, 0-RTT setup, jobb mobilos teljesítmény. De ezek a HTTP infrastruktúra rétegén javítanak; az alkalmazás-szintű protokoll továbbra is SSE.

Egy mondatban: szöveges AI chat → SSE. Voice AI → WebSocket. Háttérfeladat → nem kell streaming, queue-alapú feldolgozás (BullMQ) + webhook.

---

Multi-fázisú streaming: nem csak szöveg jön

Egy modern AI ágens válasza nem egyetlen folyamatos szövegfolyam. A tipikus flow:

1. Gondolkodás (200–500ms): az LLM eldönti, milyen tool-okat kell hívnia
2. Tool hívás (100–2000ms): CRM lekérdezés, RAG keresés, külső API
3. Eredmény feldolgozása (~50ms): a tool válasz visszakerül az LLM-hez
4. Esetleg újabb gondolkodás és tool hívás
5. Végső válasz generálása (2000–8000ms): ekkor jön a token stream

Ha a felhasználó az 1–4. fázis alatt nem lát semmit, az élmény ugyanúgy rossz, mintha nem lenne streaming. A megoldás: kétféle eseményt küldj a stream-en.

Fázis 1 (státusz események) — szöveges visszajelzés, hogy mit csinál a rendszer:

Client ← {"type": "status", "message": "Keresem az ügyfél adatait..."}
Client ← {"type": "status", "message": "CRM lekérdezés..."}
Client ← {"type": "status", "message": "3 találat a tudásbázisban..."}

Fázis 2 (token események) — a tényleges válasz karakterről karakterre:

Client ← {"type": "token", "content": "Kiss"}
Client ← {"type": "token", "content": " Anna"}
Client ← {"type": "token", "content": " utolsó"}
Client ← {"type": "done", "usage": {...}}

A felhasználó azonnali visszajelzést kap arról, hogy a rendszer dolgozik — még akkor is, ha az első valódi karakter csak 3 másodperc múlva érkezik.

Ez az architektúra különbség például a ChatGPT és egy „eddigi" chatbot között. Az előbbi mond valamit minden fázisban, az utóbbi csak akkor szólal meg, amikor kész.

---

A latency-budget: hová tűnik a milliszekundum?

Ha 1500ms TTFB a célod (ami szöveges AI chat-hez elfogadható), érdemes tudnod, hová megy a 1500ms. Egy reális bontás:

• Kliens → szerver hálózat: < 50ms (EU régió, CDN)
• Auth + parsing: < 10ms (cache-elt JWT, minimális middleware)
• RAG + history betöltés: < 200ms (párhuzamosan, pgvector index)
• LLM TTFT (Time to First Token): < 1000ms (streaming, optimalizált prompt)
• Szerver → kliens: < 50ms (SSE keep-alive, nincs buffering)
• Összesen: < 1500ms

A legnagyobb két optimalizálási nyereség:

1. Párhuzamos RAG és history: ne sorban hívd a vektoradatbázist, a chat előzményeket és a CRM-et — ezek függetlenek egymástól, futtasd párhuzamosan. Ha mindhárom 200ms, sorosan 600ms, párhuzamosan 200ms.

2. Prompt méret csökkentés: a prefill fázis (amikor az LLM beolvassa a prompt-ot) lineárisan skálázódik a prompt hosszával. Egy 8000 tokenes prompt ~600ms TTFT-t ad, egy 2000 tokenes ~150ms-ot. Hasznos technikák: kontextus tömörítés, csak a releváns RAG találatok, system prompt cache (Anthropic ~75% input token megtakarítás).

További jó gyakorlatok: connection pool az LLM provider felé (ne nyiss minden hívásnál új TCP kapcsolatot), edge computing (EU régió európai felhasználóknak), cold start eliminálás (dedikált szerver vagy melegen tartott konténer), LLM provider failover (adapter pattern: OpenAI → Claude → Gemini).

---

Produkciós csapdák, amiket egy demo nem mutat meg

A streaming működik egy localhost demo-n. A produkcióban viszont edge case-ek várnak.

1. Load balancer timeout: az SSE egy hosszan élő HTTP kapcsolat. Ha az LLM 30 másodpercig „gondolkodik" (komplex tool calling iterációk), a load balancer (Nginx, HAProxy, AWS ALB) idle timeout miatt bonthatja a kapcsolatot. Megoldás: rendszeres heartbeat SSE comment (: prefix), vagy a proxy timeout növelése streaming endpoint-okra.

2. Reconnect kezelés: a kliens hálózata megszakadhat (mobilhálózat váltás, alagút, lift). Az SSE EventSource automatikusan visszacsatlakozik — de az LLM provider stream nem visszajátszható. Az addig generált tokeneket el kell tárolni (memóriában vagy Redis-ben), és a Last-Event-ID alapján visszaküldeni a reconnect-nél. Anélkül a felhasználó újrakezdheti az egész választ.

3. Stream közbeni hiba: mi történik, ha az LLM API a stream közepén 500-as hibát dob? A felhasználó félig kapott egy választ. Best practice: error event küldése a stream-en, a részleges válasz mentése, és kliens-oldali „Újragenerálás" gomb. Ne csak hagyd, hogy a kapcsolat „eltűnjön" — kommunikáld a hibát.

4. Backpressure: ha az LLM gyorsabban generál, mint amilyen gyorsan a kliens fogyaszt (rossz hálózat, gyenge mobil), a tokenek a TCP pufferben torlódnak. A Node.js stream pipe() natívan kezeli a backpressure-t — de explicit teszteld edge case-eken (lassú 3G hálózat szimuláció).

5. Markdown streaming probléma: az LLM-ek Markdown-ban válaszolnak. Egy félig érkezett kódrészlet vagy táblázat eltöri a renderelést. Megoldás: incremental Markdown parser, vagy a ChatGPT-féle dual rendering (stream közben plain text, végén Markdown re-render).

Ezek nem elméleti problémák — minden produkciós AI rendszer találkozik velük az első hetekben. Érdemes a tervezéskor figyelembe venni őket, nem hibajegyként kezelni utólag.

---

A következő határ: voice AI

Ha a szöveges streaming „luxus", a voice AI-nál kötelező. A hangnál a latency közvetlenül érezhető — ha egy másodpercig csend van a válaszod után, az „robotikus" érzést kelt.

A voice AI pipeline három fázisú: STT (Speech-to-Text, ~200–500ms) → LLM (~500–2000ms) → TTS (Text-to-Speech, ~200–500ms). Összesen 900–3000ms — ami kétszerese a kényelmes voice élménynek.

A kulcs trükkök:

• Streaming TTS: ne várd meg a teljes szöveget. Mondatonként generálj hangot — az első mondat 500ms-on belül szól
• Sentence boundary detection: az LLM stream-ben detektáld a ., !, ? karaktereket, és azonnal küldd TTS-re
• Filler sounds: „Hmm...", „Egy pillanat..." (a Google Duplex 2018 óta használja) — természetes hangzás, ami elrejti a latency-t
• WebSocket protokoll: a hang bináris, SSE nem alkalmas. WebRTC akkor jön képbe, ha P2P latency kell

Az OpenAI Realtime API (2024 október) és a Gemini 2.0 multimodális streaming már full-duplex voice + szöveg kommunikációt biztosít — ezek lesznek a következő 2 év fő UX innovációi.

---

Mit vigyél haza ebből a cikkből?

Öt gyakorlati pont, amit holnap reggel elkezdhetsz:

1. Mérd a TTFB-t, ne csak a teljes válaszidőt. A felhasználói percepció szempontjából az első karakter ideje fontosabb, mint a teljes válasz hossza.

2. Használj SSE-t szöveges AI chat-hez. Ne ugorj WebSocket-re, csak ha tényleg kell (voice, kétirányú stream).

3. Streamelj státusz-üzeneteket a tool calling alatt. „Keresem...", „Lekérdezek..." — a felhasználó ne nézzen üres képernyőt.

4. Definiálj latency budget-et (pl. < 1500ms TTFB), és optimalizálj a legnagyobb tételekre: párhuzamos RAG/history, prompt méret csökkentés.

5. Tervezz a produkciós edge case-ekre: heartbeat SSE comment, reconnect token puffer, error event a stream-en. Ne hagyd, hogy a demo és a produkció között legyen 6 hét tűzoltás.

A legjobb streaming implementáció az, amit a felhasználó nem vesz észre — csak azt érzékeli, hogy az AI „azonnal" válaszol. Pedig a háttérben 8 másodpercig dolgozik.

---