Frameworkök, amelyeket érdemes ismerni

Miért érdekel ez téged?

A framework nem varázslat, hanem tervezési döntés: kényelmet ad cserébe azért, hogy elrejt előled egy csomó részletet. Ha nem érted, mit rejt el, akkor debugolni sem tudod, amikor félrecsúszik — pedig egy nemdeterminisztikus rendszer garantáltan félre fog csúszni.

Gondolj a frameworkre úgy, mint egy ORM-re az adatbázisok fölött. Az ORM remekül gyorsítja a fejlesztést, de ha sosem láttál nyers SQL-t, az első lassú lekérdezésnél tanácstalanul állsz. Ugyanez igaz itt: aki egyszer megírt egy agent loopot puszta provider SDK-val — modell, tool, állapot, ciklus, kilépési feltétel —, az pontosan tudja, mit tesz helyette a LangGraph vagy a Pydantic AI, és mikor éri meg egyáltalán bevetni.

Ez a fejezet szándékosan nem rangsorol. Nincs „legjobb framework" — csak feladathoz illő és feladathoz nem illő eszköz van. A cél, hogy a végén magabiztosan tudj választani, ne pedig a Twitteren éppen felkapott nevet másold be a requirements.txt-be.

state = {"messages": [user_input]}

while not done:                      # vezérlési ciklus
    reply = model.generate(state)    # modellhívás
    if reply.tool_calls:             # következő lépés kiválasztása
        result = run_tool(reply)     # tool meghívása
        state["messages"] += [reply, result]   # állapotfrissítés
    else:
        done = True                  # kilépési feltétel

Ha ezt a néhány sort érted, akkor minden orchestration framework dokumentációját fél óra alatt fel tudod térképezni — mert mind ugyanezt csomagolják be, csak checkpointinggal, típusossággal vagy vizuális gráffal megtoldva. Az agent loopról bővebben az 5. Agentek fejezet szól.

A négy réteg, amiből egy AI-rendszer összeáll

Egy éles AI-alkalmazás ritkán egyetlen framework — inkább négy réteg egymásra rakva, és mindegyik réteghez más eszközcsalád tartozik. Ez a fejezet is e négy réteg mentén halad, mert így könnyebb eldönteni, melyik döntést hol hozod meg:

• Provider stack (modellréteg) Maga a modellhívás és a provider hivatalos agent-eszközei. Ez a legalacsonyabb, legkevésbé absztrakt réteg — itt kezdd, és sokszor itt is állhatsz meg.
• Orchestration (vezérlésréteg) Amikor a puszta loop már nem elég: elágazások, párhuzamosság, checkpointing, human-in-the-loop, órákig futó folyamatok megbízható újrafuttatása.
• Dokumentum és retrieval (tudásréteg) A RAG-infrastruktúra: parsing, chunking, indexelés, keresés, reranking. Itt nem egy eszközt választasz, hanem egy pipeline-t raksz össze.
• Observability és eval (mérésréteg) Ami összeköti a fejlesztést a production valósággal: látod, mi történik, és méred, hogy a változtatásaid jobbá tették-e a rendszert.

Provider stackek

A provider stack a legközvetlenebb réteg: maga a modellhívás plusz a provider hivatalos agent-eszközei. Itt kezdd, mert ez tanít meg arra, mit tud egyáltalán a modell — és sok esetben itt is állhatsz meg, ha nincs szükséged külső orchestrationre.

• OpenAI Responses API + Agents SDK A Responses API a modern, állapotkezelést és beépített toolokat (web search, code interpreter, file search) egyesítő végpont; az Agents SDK erre épít könnyű agent-, handoff- és guardrail-absztrakciókat. Akkor válaszd, ha az OpenAI modelljeire építesz, és gyors, provider-natív agentekhez kell egy vékony, jól dokumentált réteg — nem egy nehéz orchestration motor. Egy tipikus egyszerű agentet néhány tucat sorban összeraksz vele, handofffal együtt.
• Anthropic API + Agent SDK A Claude API adja a modellhívást, tool use-t és streaminget; az Agent SDK (a Claude Code alatti motor) fájlrendszer-, bash- és MCP-eszközökkel felszerelt, hosszú futású coding- és kutató-agenteket tesz egyszerűvé. Akkor válaszd, ha Claude-ra építesz, és olyan agentet akarsz, amely fájlokkal, terminállal és MCP-szerverekkel dolgozik dobozból. A prompt caching itt nagyságrendekkel olcsóbbá teszi az ismétlődő system promptokat — ez hosszú agent-futásoknál kritikus költségtétel.
• Google ADK (Agent Development Kit) A Google nyílt forrású agent-frameworkje, amely a Gemini modellekhez és a Vertex AI-hoz illeszkedik legszorosabban, de más modellekkel is használható. Akkor válaszd, ha a Google Cloud ökoszisztémájában vagy, és a Vertex AI menedzselt infrastruktúráját (deployment, tracing, evaluation) is használni akarod az agentjeidhez — így nem kell külön futtatókörnyezetet üzemeltetned.
• Azure AI / Foundry A Microsoft menedzselt platformja, amely több provider modelljét, agent-szolgáltatásokat, tartalomszűrést és vállalati compliance-t (VNet, private endpoint, régió-pinnelés) csomagol egybe. Akkor válaszd, ha a szervezet már Azure-ban van, és a szabályozási, hálózati és számlázási integráció fontosabb, mint a legutolsó modell azonnali elérhetősége. Cserébe számolj azzal, hogy egy új modell itt jellemzően később jelenik meg, mint a provider natív API-jában.
• AWS Bedrock Az AWS egységes API-ja több providertől (Anthropic, Meta, Mistral és mások) származó modellekhez, IAM-alapú jogosultságkezeléssel és Bedrock Agents/Guardrails funkciókkal. Akkor válaszd, ha AWS-en futsz, és egy providerfüggetlen végponton keresztül, meglévő IAM- és VPC-szabályaid mögött akarsz modelleket hívni — így a hozzáférés-kezelés ugyanaz, mint a többi AWS-erőforrásodnál.

Cloud provider vs. modell provider — ne keverd össze a kettőt

Két különböző dolog, amit könnyű összemosni. A modell provider (OpenAI, Anthropic, Google) magát a modellt és a natív API-ját adja. A cloud integráció (Azure AI/Foundry, AWS Bedrock, Vertex AI) ugyanezeket a modelleket csomagolja a felhő számlázási, hálózati és jogosultsági rendszerébe. Ugyanaz a Claude-modell elérhető közvetlenül az Anthropic API-n és Bedrocken keresztül is — a döntés nem a modellről szól, hanem arról, hol akarod, hogy a forgalom, a naplók és a számla landoljanak.

from openai import OpenAI

client = OpenAI()
resp = client.responses.create(
    model="gpt-4.1",
    input="Foglald össze a Q3-as bevételi jelentést.",
    tools=[{"type": "web_search"}],   # provider-natív, beépített tool
)
print(resp.output_text)

Amit ebből tanulj: a provider-natív beépített toolok (web search, code interpreter) egyetlen paraméterrel bekapcsolhatók — nincs külön tool-implementáció, nincs sandbox, amit te üzemeltetsz. Ez a kényelem az ára a lock-innak: ha holnap másik providerre váltanál, ezt a réteget újra kell írnod.

Orchestration

Az orchestration framework onnan lesz hasznos, ahol a puszta agent loop már nem elég: elágazások, párhuzamos ágak, checkpointing, human-in-the-loop, vagy több lépés megbízható újrafuttatása kell. Ezek nem versenytársak, hanem különböző filozófiák — némelyik a gráfra, némelyik a típusosságra, némelyik a durability-re fókuszál.

• LangGraph Gráfalapú orchestration: az agentedet csomópontok és élek állapotgépeként írod le, és cserébe kapsz checkpointot, persistence-t, streaminget és human-in-the-loop megszakítási pontokat. Akkor válaszd, ha az agentednek elágazó, ciklikus vagy hosszú futású folyamata van, és a durable execution meg a folytathatóság elsődleges szempont (lásd 9. State és memory). Egy jóváhagyási pontnál például megállítod a gráfot, elmented az állapotot, és órákkal később, egy másik processzben pontosan onnan folytatod.
• Pydantic AI A Pydantic csapatának agent-frameworkje, amely a típusosságot és a strukturált kimenetet helyezi a középpontba: az inputok, outputok és dependency-k mind típusozottak, és beépített eval-támogatás jár hozzá. Akkor válaszd, ha Python-heavy, típusbiztos kódbázisban dolgozol, és a megbízható structured output (lásd 3. Structured output) meg a tesztelhetőség fontosabb, mint a vizuális gráf. Aki már használt FastAPI-t vagy Pydantic modelleket, annak ez otthonos lesz — ugyanaz a validációs logika, csak az LLM-kimenetre kiterjesztve.
• Semantic Kernel A Microsoft SDK-ja, amely .NET, Python és Java támogatással plugineket, planner-t és memóriát kínál, és jól illeszkedik az enterprise Microsoft-stackhez. Akkor válaszd, ha vegyes nyelvű vagy .NET-alapú vállalati környezetben építesz, és a meglévő Azure/Microsoft integrációra akarsz támaszkodni. Ez gyakran az egyetlen komoly opció olyan csapatoknál, ahol a fő kódbázis C#, és a Python nem alternatíva.
• LlamaIndex workflows Eseményvezérelt workflow-absztrakció, amely a LlamaIndex erős retrieval- és dokumentum-rétegére ül rá: lépéseket eseményekkel kötsz össze, és köré építesz RAG-heavy folyamatokat. Akkor válaszd, ha a rendszered súlypontja a dokumentumfeldolgozás és a lekérdezés, és az orchestrationt is ugyanabban az ökoszisztémában akarod tartani — nem akarsz külön retrieval- és külön orchestration-frameworkot összedrótozni.
• Provider-native agent SDK-k Az OpenAI Agents SDK, az Anthropic Agent SDK és a Google ADK maga is orchestration-réteg — csak szándékosan vékony, egy provider köré húzva. Akkor válaszd ezeket külön orchestration framework helyett, ha egyetlen providerre építesz, és nincs szükséged komplex gráfra vagy durability-re: kevesebb függőség, kevesebb absztrakció, gyorsabb indulás.
• Temporal (durable workflow engine) Nem AI-specifikus: általános durable execution motor, amely a folyamat állapotát perzisztálja, és hálózati hiba, deploy vagy crash után is pontosan onnan folytatja, ahol abbahagyta. Gondolj rá úgy, mint egy videójáték automatikus mentésére: nem kezded elölről a pályát, ha megszakad az áram. Akkor válaszd, ha egy agent órákig vagy napokig fut, pénzügyi vagy destruktív műveleteket végez, és a megbízhatóság üzemeltetési, nem csak modell-szintű kérdés.

Gráf vs. típusosság vs. durability — melyik filozófia illik hozzád?

A három domináns orchestration-megközelítés más problémára optimalizál, és ezt érdemes tudatosan választani, nem véletlenül belesodródni:

• Gráf-first (LangGraph) A folyamatot explicit állapotgépként modellezed. Előny: az elágazások, ciklusok és a folytathatóság első osztályú polgárok. Hátrány: még egy egyszerű lineáris folyamat is gráf-terminológiába kényszerül, ami kezdetben túlmérnökölésnek tűnhet.
• Típus-first (Pydantic AI) A megbízhatóságot a típusrendszeren és a validáción keresztül éred el. Előny: a hibás LLM-kimenet a határon elhasal, nem a rendszer mélyén. Hátrány: a komplex, hosszú futású, folytatható folyamatokhoz külön durability-réteg kell mellé.
• Durability-first (Temporal) A folyamat crash-tűrő folytatása a fő cél, függetlenül attól, hogy AI van-e benne. Előny: production-grade megbízhatóság hosszú, drága folyamatokhoz. Hátrány: külön workerekkel járó üzemeltetési teher, és nem tud semmit az LLM-specifikus dolgokról — azt neked kell hozzátenned.

from pydantic import BaseModel
from pydantic_ai import Agent

class Ticket(BaseModel):
    priority: str        # "low" | "high" — validáció a kimeneten
    summary: str

agent = Agent("openai:gpt-4.1", output_type=Ticket)
result = agent.run_sync("A fizetés kétszer levonódott!")
print(result.output.priority)   # garantáltan Ticket, nem nyers szöveg

Amit ebből tanulj: a típus-first megközelítés a hibás kimenetet ott bukja el, ahol keletkezik — nem kell a rendszer mélyén nyers JSON-t parse-olgatnod. A structured output részleteit lásd a 3. Structured output fejezetben.

Dokumentum és retrieval

A RAG-rendszer minősége nagyrészt a retrieval-infrastruktúrán múlik: hogyan darabolod fel a dokumentumot, hova indexeled, hogyan keresel benne, és hogyan rangsorolod a találatokat. Itt ritkán egyetlen eszközt választasz — inkább egy pipeline-t állítasz össze belőlük (lásd 4. Modern RAG).

• LlamaIndex / LlamaParse Dokumentum-infrastruktúra: parsing, chunking, indexelés és lekérdezés egy csomagban, a LlamaParse pedig a nehéz, táblázatos, többoszlopos PDF-eket alakítja LLM-barát szöveggé. Akkor válaszd, ha összetett dokumentumokból kell megbízhatóan kinyerni a tartalmat, és nem akarsz saját parsing-pipeline-t építeni a nulláról. Egy tipikus 50 oldalas, táblázatokkal teli szerződésből egy naiv text-extract kinyeri a szöveget rossz sorrendben — a layout-tudatos parsing viszont megőrzi a táblázatok szerkezetét.
• Elasticsearch / OpenSearch Érett kereső motorok, amelyek erős BM25 sparse keresést, szűrést és aggregációt kínálnak, mostanra vektormezőkkel és hybrid kereséssel kiegészítve. Akkor válaszd, ha már használod őket logokra vagy keresésre, vagy ha a kulcsszavas pontosság és a metaadat-szűrés legalább olyan fontos, mint a szemantikus hasonlóság. Termékkódok, jogszabályi hivatkozások, pontos azonosítók keresésénél a BM25 gyakran veri a puszta vektorkeresést.
• PostgreSQL + pgvector A jól ismert relációs adatbázis vektorkeresés-kiegészítővel: az embeddingeket ugyanabban a Postgresben tárolod, ahol az üzleti adataid is vannak. Akkor válaszd, ha már Postgresre építesz, és a mérsékelt méretű korpuszhoz (nagyjából százezres–egymilliós nagyságrendig kényelmesen) nem akarsz külön rendszert üzemeltetni — egy adatbázissal kevesebb a tranzakció, a backup és a jogosultságkezelés. Ez a legtöbb induló RAG-projekt legjobb kiindulópontja.
• Dedikált vector database-ek Kifejezetten vektorkeresésre tervezett rendszerek (pl. Pinecone, Weaviate, Qdrant, Milvus), amelyek nagy méretben, alacsony késleltetéssel és fejlett indexeléssel (HNSW, kvantálás) szolgálják ki a keresést. Akkor válaszd, ha a korpusz tíz- vagy százmilliós nagyságrendű, és a retrieval-teljesítmény önmagában szűk keresztmetszet lenne egy általános adatbázisban. Alatta a méret alatt jellemzően csak fölösleges operatív komplexitást hozol a rendszerbe.
• Reranker modellek Egy második, drágább, de pontosabb modell, amely a retrieval által visszaadott sok találatot újrarangsorolja relevancia szerint, mielőtt a generatív modellhez érne. Olyan, mint a sommelier: a pincér hozhat tíz palackot, de a szakértő dönti el, melyik három illik igazán az ételhez. Egy reranker jellemzően 100–500 ms plusz késleltetést ad, cserébe a top néhány találat minősége érezhetően javul. Akkor válaszd, ha a válasz minősége a top néhány találaton múlik, és a nyers keresés túl zajos.
• OCR / layout modellek Szkennelt vagy komplex elrendezésű dokumentumok szövegét és szerkezetét (oszlopok, táblázatok, cellák) ismerik fel, hogy egyáltalán legyen mit indexelni. Akkor válaszd, ha az input képként vagy strukturált PDF-ként érkezik — enélkül a legjobb retrieval sem tud mit kezdeni egy beszkennelt szerződéssel (lásd 10. Multimodális).

Sparse, dense és hybrid — melyik keresés mikor?

A retrieval szíve a keresési stratégia. Három alapmegközelítés van, és a jó rendszerek gyakran kombinálják őket:

A gyakorlatban a hybrid keresés (BM25 + vektor, majd egy reranker a tetején) a legrobusztusabb alapértelmezés éles rendszerekhez — de csak akkor kezdd ezzel, ha a mérés (lásd 11. Evals) mutatja, hogy a puszta vektorkeresés nem elég.

Egy tipikus retrieval-pipeline lépésről lépésre

# 1. Nyers retrieval: sok jelölt, gyors, olcsó
candidates = vector_store.search(query, top_k=50)

# 2. Rerank: kevés, pontos, drágább modell
ranked = reranker.rank(query, candidates)
top = ranked[:5]                     # csak a legjobbak mennek a modellbe

# 3. Generálás a szűkített kontextussal
context = "\n\n".join(c.text for c in top)
answer = model.generate(f"Kontextus:\n{context}\n\nKérdés: {query}")

Amit ebből tanulj: a retrieval két fázis — először sokat és olcsón hozol be (top_k=50), majd kevésre és pontosra szűrsz reranker-rel. A modellbe csak a legjobb 5 kerül, mert a context window drága, és a zajos találat rontja a választ. Egy 50 oldalas PDF nagyjából 30–40 chunkot ad — nem a mennyiség, hanem a top néhány pontossága számít.

Observability és eval

Egy nemdeterminisztikus rendszert nem tudsz „ránézésre" üzemeltetni: látnod kell, mi történik minden hívásnál, és mérned kell, hogy a változtatásaid jobbá vagy rosszabbá tették-e a rendszert. Ez a réteg köti össze a fejlesztést a production valósággal (lásd 14. Observability és 11. Evals).

• OpenTelemetry Nyílt, vendor-független tracing-szabvány, amelynek GenAI semantic conventionjei egységes attribútumokat adnak a modellhívásokhoz, tokenekhez, tool callokhoz és agent workflow-khoz. Akkor válaszd alaprétegnek, ha nem akarsz egyetlen observability-szolgáltatóhoz kötődni: ugyanaz a trace később bármelyik kompatibilis backendbe elküldhető. Gondolj rá úgy, mint a naplózás közös nyelvére — ha erre építesz, a backend cserélhető marad.
• MLflow GenAI Az MLflow generatív AI-ra kiterjesztett változata, amely tracinget, evaluationt, promptkezelést és monitoringot fog össze egy platformon. Akkor válaszd, ha már MLflow-t használsz kísérletkövetésre, vagy ha a prompt-, eval- és trace-lifecycle-t egy helyen, nyílt eszközzel akarod kezelni. A klasszikus ML-es csapatoknak ez a legkisebb ugrás, mert a meglévő tudás és infra átvihető.
• Langfuse Nyílt forrású, LLM-re specializált observability és eval platform: trace-vizualizáció, prompt-menedzsment, költségkövetés és annotáció egy fókuszált felületen. Akkor válaszd, ha gyorsan, LLM-specifikus nézetekkel akarod látni az agenteid futását, és fontos a self-hosting lehetősége — például ha az adatok nem hagyhatják el a saját infrastruktúrádat.
• Arize Phoenix Nyílt forrású observability és eval eszköz, amely a trace-ek vizsgálatára, hibaanalízisre és beépített evaluatorokra összpontosít, és jól illeszkedik OpenTelemetryhez. Akkor válaszd, ha a fejlesztés közbeni debugolás és a gyors iteráció a fő cél, és értékeled a beépített LLM-as-judge kiértékelőket. Kiválóan használható lokálisan, notebookból is, amíg a rendszered még alakul.
• Saját trace + eval pipeline Nem eszköz, hanem opció: OpenTelemetryre és a saját adattárodra építve magad rakod össze a tracinget és az evalokat. Akkor válaszd, ha egyedi compliance-, adatrezidencia- vagy integrációs igényeid vannak, amiket kész termék nem fed le — de számolj azzal, hogy a karbantartás a te terhed lesz. A legtöbb csapatnak ez túl korai lépés; előbb bizonyíts kész eszközzel.

A négy csoport eszközei más-más filozófiát követnek. Az alábbi táblázat néhány jellemző választás fókuszát állítja szembe — nem rangsor, hanem tájékozódási pont ahhoz, hogy melyik mikor illik a feladatodhoz:

Miért az OpenTelemetry legyen az alapréteg

Az observability-eszközök piaca gyorsan mozog: ami ma a legjobb felület, holnap lehet elavult vagy drágább. Ezért érdemes a trace-generálást (mit és hogyan naplózol) elválasztani a trace-megjelenítéstől (hol nézed meg). Ha OpenTelemetry semantic conventions szerint instrumentálsz, akkor a Langfuse, az Arize Phoenix vagy egy saját backend közül bármikor válthatsz anélkül, hogy a kódot újraírnád — ugyanaz a trace mindegyikbe elmegy.

Hogyan válassz frameworköt?

A választásnál nem az a kérdés, hogy melyik framework a „legjobb", hanem hogy a feladatod melyik réteget feszíti szét. Egy egyszerű heurisztika: kezdj a legkevesebb absztrakcióval, és csak akkor lépj feljebb, amikor egy konkrét fájdalom kikényszeríti.

Döntési szempontok sorrendben

• 1. Elég a nyers provider SDK? Ha a feladat néhány tool callból és lineáris lépésekből áll, egyetlen providerrel, akkor ne húzz be orchestration frameworköt. A legtöbb prototípus és sok éles rendszer is elvan ennyivel.
• 2. Kell durable, folytatható folyamat? Ha az agent órákig fut, jóváhagyási pontok vannak benne, vagy crash után folytatnia kell — akkor LangGraph (AI-natív) vagy Temporal (általános) irányba nézz.
• 3. A megbízhatóság a kimenet helyességén múlik? Ha a fő kockázat a hibás strukturált kimenet, és típusbiztos Python-kódbázisod van, a Pydantic AI erre optimalizál.
• 4. Dokumentum-nehéz a rendszer? Ha a súlypont a parsing és retrieval, a LlamaIndex ökoszisztéma egyben adja a dokumentum- és orchestration-réteget.
• 5. Vállalati stackhez kell illeszkedni? .NET-alapú környezetben Semantic Kernel; Azure-ban Azure AI/Foundry; AWS-en Bedrock — a döntést itt gyakran a compliance és a meglévő infra hozza meg, nem a modell.

Gyakori hibák framework-választáskor

• Divatot követsz, nem feladatot A közösségi médiában felkapott név nem feltétlenül illik a te problémádra. Előbb írd le a feladatot, aztán keress hozzá eszközt — ne fordítva.
• Túl korán, túl sok absztrakció Egy nehéz orchestration framework debugolása lassabb, mint 50 sor átlátható loopé. Amíg nem érzed a fájdalmat, amit megold, ne fizesd ki az árát.
• Framework-lock-in gateway nélkül Ha mélyen egy framework absztrakcióiba szövöd az üzleti logikát, a váltás később drága lesz. Tartsd a saját kódodat a framework mögött, egy vékony saját rétegben (lásd 16. AI Platform).
• Nincs eval, csak framework Bármelyik frameworköt is választod, mérés nélkül vakon repülsz. Az observability és eval réteget ne halaszd „majd később"-re — az a réteg mondja meg, hogy a többi jól működik-e.

Összefoglalás

A frameworkök nem célok, hanem eszközök: mindegyik egy adott problémára ad kényelmes választ, cserébe elrejt előled valamit. Ezért a sorrend nem alku tárgya — előbb a nyers provider SDK-val értsd meg az agent loopot, a tool callt és a streaminget, és csak utána válassz frameworkeket ahhoz, ami már valóban fáj: orchestration a komplex folyamatokhoz, retrieval-infrastruktúra a dokumentumokhoz, observability és eval a méréshez.

Gondolj a rendszeredre négy rétegként — modell, orchestration, retrieval, mérés —, és minden rétegnél a legkevesebb absztrakcióval kezdj. A provider stack tanít meg arra, mit tud a modell; az orchestration akkor lép be, amikor elágazás, durability vagy human-in-the-loop kell; a retrieval-pipeline a dokumentumok minőségén dönt; az observability és eval pedig azt mondja meg, hogy az egész egyáltalán működik-e.

A választás mindig feladatfüggő. A LangGraph a durable, elágazó folyamatokban erős; a Pydantic AI a típusosságot és a tesztelhetőséget hozza; a Temporal az üzemeltetési megbízhatóságot; a LlamaIndex a dokumentumokat; az MLflow GenAI, a Langfuse és az Arize Phoenix pedig azt, hogy egyáltalán lásd, mit csinál a rendszered. Ne a divatot kövesd, hanem a feladatot — és tartsd meg a lehetőséget, hogy egy vékony saját réteg mögött cserélhető maradjon, amit ma választasz.