> Hogyan válassz embedding-modellt RAG-hoz 2026-ban: mit mond az MTEB és az RTEB, API vagy nyílt súlyok, árak, dimenziók és egy egyhetes összehasonlító teszt.
>
> Web page: https://balazscsorba.com/hu/blog/embedding-model-selection-2026 · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/embedding-model-selection-2026.md) · [Deutsch](https://balazscsorba.com/de/blog/embedding-model-selection-2026.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: best embedding model 2026, how to choose an embedding model, embedding model comparison, MTEB leaderboard explained, RTEB benchmark, open source embedding model, multilingual embedding model, voyage-4 vs openai embeddings, Qwen3-Embedding, EmbeddingGemma, embedding model for RAG, switching embedding models re-embed

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

# Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon

Hogyan válassz embedding-modellt RAG-hoz 2026-ban: mit mond az MTEB és az RTEB, API vagy nyílt súlyok, árak, dimenziók és egy egyhetes összehasonlító teszt.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 17.·9 perc olvasás

-   Embeddings
-   RAG
-   MTEB
-   Vector search
-   Model selection

![Három oszlop egymásra rakott kockákból, középen a legmagasabb, mindegyik rövid sávval mérve.](https://balazscsorba.com/images/blog/embedding-model-selection-2026/cover.webp?v=25f077f46f)

## A lényeg röviden

-   A különböző modellek vektorterei nem kompatibilisek, így a döntés visszafordítása teljes újraembeddelésbe kerül; a Google ezt a gemini-embedding-001-ről a gemini-embedding-2-re váltásnál kifejezetten leírja.
-   Az MTEB-helyezés a szűkített lista szűrője, nem döntés; az RTEB privát adatkészleteket ad hozzá, mert a nyilvános benchmarkokra rá lehet tanítani.
-   Az árak nagyjából tízszeres sávban mozognak, a text-embedding-3-small és a voyage-4-lite millió tokenenkénti 0,02 dollárjától a gemini-embedding-2 0,20 dollárjáig, de az újraindexelés ideje általában többe kerül, mint a tokenek.
-   A nyílt súlyú modellek, például a Qwen3-Embedding és az EmbeddingGemma, elég erősek egy komoly alapvonalhoz, főleg ha az adatnak a saját szervereiden kell maradnia.
-   Összehasonlító teszttel dönts: 100–300 valódi kérdés megjelölt releváns chunkokkal, jelöltenként recall@10 és nDCG@10, nagyjából egy hét alatt.

Ezen az oldalon

1.  [Miért hosszú távú döntés az embedding-modell?](https://balazscsorba.com/#why-it-is-sticky)
2.  [Mit mond valójában az MTEB és az RTEB?](https://balazscsorba.com/#leaderboards)
3.  [Mely modellek kerüljenek 2026-ban a szűkített listára?](https://balazscsorba.com/#shortlist)
4.  [Mely szempontok fontosabbak a ranglistás helyezésnél?](https://balazscsorba.com/#criteria)
5.  [Hosztolt API vagy nyílt súlyok?](https://balazscsorba.com/#hosted-or-open)
6.  [Mit változtatnak a közös embedding-terek?](https://balazscsorba.com/#shared-spaces)
7.  [Mely API-részletek okoznak észrevétlen minőségromlást?](https://balazscsorba.com/#details)
8.  [Hogyan futtass összehasonlító tesztet a saját adataidon?](https://balazscsorba.com/#bake-off)
9.  [Hogyan készülj fel a következő modellre?](https://balazscsorba.com/#migrations)
10.  [Mik az ésszerű alapválasztások 2026 végén?](https://balazscsorba.com/#my-defaults)
11.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Az embedding-modell a RAG-rendszer legkevésbé látható része, és az egyik legnehezebben cserélhető. Az index minden chunkját ez állította elő, minden lekérdezésnek ugyanezen a modellen kell átmennie, egy másik modell vektorai pedig nem összevethetők. Ha rosszul választasz, hónapokkal később derül ki, amikor a javítás a teljes korpusz újraembeddelését jelenti.

Ez az útmutató azt mutatja meg, hogyan választok 2026 októberében: mire jók a ranglisták, mely modellek kerüljenek a szűkített listára, mely tulajdonságok fontosabbak a helyezésnél, és hogyan futtass kis összehasonlító tesztet a saját adataidon. Kiegészíti a lépésenkénti [éles RAG-pipeline](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking) cikket, amely már kiválasztott modellt feltételez.

## Miért hosszú távú döntés az embedding-modell?

Az embedding egy pozíció egy olyan térben, amelyet csak egyetlen modell határoz meg. Két modell kimenete lehet egyaránt 1024 szám szövegenként, mégis értelmetlenek egymás számára, mert mindegyik saját geometriát tanult. A Google a saját modelljeiről egyértelműen fogalmaz: a gemini-embedding-001 és a gemini-embedding-2 tere nem kompatibilis, a váltáshoz az összes meglévő adatot újra kell embeddelni.

Az újraembeddelés tokenszámlája ritkán a gond. Egy 50 millió tokenes korpusz egyszeri embeddelése a text-embedding-3-large modellel, millió tokenenként 0,13 dollárért, 6,50 dollár. A valódi költség a pipeline ideje: újrafeldolgozás, újra-chunkolás, indexek újraépítése, értékelések ismétlése és a forgalom leállás nélküli átállítása. Ezért a döntés egyhetes mérést érdemel, nem egy pillantást a ranglistára.

## Mit mond valójában az MTEB és az RTEB?

Az MTEB az embedding-modellek szabványos nyilvános benchmarkja. Többnyelvű kiterjesztése, az MMTEB, több mint 500 minőségellenőrzött feladatot fed le több mint 250 nyelven, köztük visszakeresést, osztályozást, klaszterezést, utasításkövetést, hosszú dokumentumokat és kódot. Az MMTEB-tanulmány egyik megállapítását érdemes megjegyezni: a milliárdos paraméterszámú modellek egyes részhalmazokon vezetnek, de a vizsgálat legjobb nyilvánosan elérhető modellje a mindössze 560 millió paraméteres multilingual-e5-large-instruct volt. A méret nem azonos azzal, mennyire illik a modell a feladatodhoz.

A nyilvános benchmark gyengesége éppen az, hogy nyilvános. Ha a tesztkészletek átfednek a tanítóadatokkal, a modellek általánosítás nélkül is jól teljesítenek, ezt a Hugging Face csapata a tesztre tanításnak nevezi. A válaszuk, az RTEB, 2025. október 1-jén indult béta változatban: egy visszakeresési benchmark nyílt és olyan privát adatkészletekkel, amelyeket csak az MTEB karbantartói értékelnek ki, jog, egészségügy, kód és pénzügy területén, 20 nyelven, nDCG@10 szerint rangsorolva.

A szolgáltatói benchmarkok egy harmadik kategóriát alkotnak, és ezekkel kell a legóvatosabban bánni. A Voyage szerint a voyage-4-large az RTEB-adatkészleteken átlagosan 14,05%-kal veri az OpenAI text-embedding-3-large modelljét és 3,87%-kal a Gemini Embedding 001-et, a mérést maga a Voyage végezte. Az ilyen számok abban segítenek, mit tesztelj, nem abban, mit vegyél meg.

## Mely modellek kerüljenek 2026-ban a szűkített listára?

A táblázat azokat a modelleket sorolja fel, amelyeket ma egy új RAG-projekthez számításba vennék, a szolgáltatók dokumentációjának vagy modellkártyájának 2026. októberi adataival. Az árak millió bemeneti tokenenként, standard díjszabással értendők.

Modell

Dimenziók

Kontextus

Ár / 1 millió

Megjegyzés

`text-embedding-3-small`

1536

8,192

$0.02

Olcsó alapmodell, rövidíthető

`text-embedding-3-large`

3072, rövidíthető

8,192

$0.13

Széles körben támogatott, régebbi generáció

`voyage-4-large`

256–2048

32,000

$0.12

Közös tér a voyage-4, lite és nano modellel

`voyage-4-lite`

256–2048

32,000

$0.02

Olcsó lekérdezőmodell egy large indexhez

`gemini-embedding-2`

128–3072

8,192

0,20 $, batch 0,10 $

Szöveg, kép, hang, videó, PDF

`embed-v4.0` / `embed-v5.0-pro`

256–1536 / 256–2048

128k

lásd a Cohere árlistáját

Szöveg és kép, hosszú bemenetek

`Qwen3-Embedding` 0.6B/4B/8B

32–4096 (8B)

32k

nyílt súlyok

Apache 2.0, 100+ nyelv

`EmbeddingGemma`

768 → 128

2k

nyílt súlyok

308 millió paraméter, kvantálva 200 MB alatt

A modellkártyák két részlete fontos német vagy magyar tartalomnál. A Qwen3-Embedding-8B 2025. június 5-én 70,58 ponttal az első helyen állt az MTEB többnyelvű ranglistáján, a szerzők pedig azt javasolják, hogy a feladatutasításokat többnyelvű használatnál is angolul írd. A Google az EmbeddingGemmát az MTEB legjobb helyezésű, 500 millió paraméter alatti nyílt többnyelvű szöveg-embedding modelljének nevezi, mindössze kb. 2000 tokenes kontextussal. A [német és magyar nyelvű többnyelvű RAG](https://balazscsorba.com/hu/blog/multilingual-rag-german-hungarian) cikkemben leírtam, mi minden változik még ezeknél a nyelveknél.

## Mely szempontok fontosabbak a ranglistás helyezésnél?

Egy összesített benchmarkon mért kétpontos különbség eltörpül, ha az alábbi tulajdonságok bármelyikében nincs egyezés:

-   **Nyelvek és szakterület.** Ellenőrizd, milyen nyelveken kérdeznek ténylegesen a felhasználók, a vegyes nyelvű kérdéseket is beleértve, és hogy a modell látott-e a tiédhez hasonló szöveget: cikkszámokat, jogi németet, forráskódot.
-   **Kontextushossz és chunkméret.** Egy 2000 tokenes modell elég 400 tokenes chunkokhoz, egy 6000 tokenes szakaszt viszont csendben levág. A Voyage alapértelmezésben levágja a túl hosszú bemenetet, hacsak a `truncation` értékét nem állítod false-ra.
-   **Dimenziók és kimeneti típusok.** A Matryoshka-modelleknél hívásonként kisebb vektort választhatsz, és több API közvetlenül int8 vagy bináris vektort ad vissza. Mindkettő csökkenti az index memóriaigényét, ahogy az [embedding-kvantálásról](https://balazscsorba.com/hu/blog/embedding-quantization-binary-matryoshka) szóló cikkben leírtam.
-   **Hosztolás és adattárolási hely.** Az, hogy a dokumentumaid elhagyhatják-e az infrastruktúrádat, és melyik régióba kerülhetnek, még a minőség előtt eldönti, hosztolt API vagy nyílt súlyok.
-   **Lekérdezési késleltetés és mennyiség.** Minden keresés először egy lekérdezést embeddel. Egy hálózati oda-vissza út lekérdezésenként egy chatasszisztensnél elfogadható, gépelés közbeni keresésnél viszont érezhető.
-   **Modellcsalád és élettartam.** Egy közös terű, közzétett kivezetési szabályzattal és több mérettel rendelkező modellcsalád később több mozgásteret ad, mint egyetlen checkpoint.

## Hosztolt API vagy nyílt súlyok?

A hosztolt modellekkel lehet a leggyorsabban indulni: nincs GPU, nincs kiszolgálási stack, a nagy indexelési futáshoz pedig batch-árazás jár. A Google a Batch API-n keresztül a standard ár feléért kínálja az embedding-modelljeit, a Voyage pedig a standard díjnál 33%-kal olcsóbban számlázza a batch-kéréseket. Az ára az, hogy minden dokumentum és minden lekérdezés egy harmadik félen halad át, így a döntés adatvédelmi kérdéssé válik. A régióbeállításokat és a megőrzési lehetőségeket a [GDPR és LLM-adattárolás](https://balazscsorba.com/hu/blog/gdpr-llm-api-eu-data-residency) cikkben tárgyaltam.

A nyílt súlyú modelleknél a munka hozzád kerül, de ezek a modellek mára kicsik lettek. Az EmbeddingGemma kb. 308 millió paraméteres, és kvantálva 200 MB RAM alatt marad; a Qwen3-Embedding sorozat 0,6 milliárd paraméternél kezdődik, Apache 2.0 licenccel; a Voyage a voyage-4-nanót Apache 2.0 alatt tette közzé a Hugging Face-en. Egy átlagos CPU-s szerveren ezek kényelmesen elvégzik a lekérdezések embeddelését, a nagy indexelési futás pedig lehet egy egyszeri feladat egy bérelt GPU-n. Még ha végül hosztolt modellt választasz is, egy nyílt modell az összehasonlító tesztben megmutatja, mit kapsz a felárért.

## Mit változtatnak a közös embedding-terek?

A legújabb változás az egy közös térbe tanított modellcsaládok megjelenése. A négy Voyage 4 modell kompatibilis embeddingeket állít elő, így a voyage-4-large-dzsel egyszer embeddelt dokumentumok a voyage-4-lite vagy a nyílt voyage-4-nano lekérdezéseivel is kereshetők. A Voyage ezt aszimmetrikus visszakeresésnek hívja. Az index minőségét a drága modell adja, a lekérdezésenkénti költséget és késleltetést az olcsó, és a lekérdezőmodell később az index érintése nélkül cserélhető.

A Voyage által dokumentált kompatibilitás a négy Voyage 4 modellre vonatkozik, korábbiakra nem, így a Voyage 3 generációról váltáskor számolj újraembeddeléssel. A közös tér ok arra, hogy egy modellcsaládot válassz, de nem ok arra, hogy ne tárold, melyik modell állította elő az egyes vektorokat.

## Mely API-részletek okoznak észrevétlen minőségromlást?

A rossz összehasonlító eredmények többsége, amit látok, a modell hibás hívásából ered, nem magából a modellből. Három részletet érdemes minden jelöltnél a dokumentációval összevetni:

1.  **Lekérdezés- és dokumentummód.** A Voyage az `input_type` query és document értékénél más-más promptot fűz a szöveg elé. A gemini-embedding-001 `task_type` paramétert vár, például RETRIEVAL\_QUERY, a gemini-embedding-2 pedig feladatelőtagot a szövegben. A Qwen3-Embedding a lekérdezés oldalán utasítást vár, ami a szerzők szerint jellemzően 1–5%-kal javítja az eredményt.
2.  **Normalizálás a vágás után.** Az OpenAI embeddingjei 1 hosszúságúra normalizáltak, és a `dimensions` paraméter ezt megőrzi. Ha magad vágsz le egy vektort, vagy a gemini-embedding-001-et 3072 dimenzió alatt használod, a skalárszorzat előtt újra normalizálnod kell.
3.  **Hosszú bemenetek levágása.** Tudd, hogy az API levágja vagy elutasítja-e a túl hosszú bemenetet, és naplózd a chunkonkénti tokenszámot, hogy egy chunkoló-módosítás ne tolja észrevétlenül a határ fölé a chunkokat.

```
import numpy as np

def prepare(vec: list[float], dims: int | None = None) -> np.ndarray:
    """Truncate a Matryoshka embedding and re-normalize it for dot-product search."""
    v = np.asarray(vec, dtype=np.float32)
    if dims is not None:
        v = v[:dims]               # keep the leading dimensions only
    return v / np.linalg.norm(v)   # unit length again, so dot product == cosine

# Store the model id next to every vector: vectors from different models never mix.
row = {"chunk_id": "doc-42#3", "model": "voyage-4-large", "dims": 1024,
       "embedding": prepare(raw_vector, 1024).tolist()}
```

## Hogyan futtass összehasonlító tesztet a saját adataidon?

Egy hasznos összehasonlító teszt kicsi, és nagyjából egy hétig tart. Valódi kérdések kellenek, a rájuk válaszoló chunkok, és minden jelöltnél ugyanaz a chunkolás, hogy csak a modell változzon.

A chunkoló, a korpusz és a kérdések rögzítettek; a futások között csak az embedding-modell változik.

1.  Gyűjts 100–300 valódi kérdést keresési naplókból, ügyfélszolgálati jegyekből vagy a felhasználóktól, és jelöld meg az egyes kérdésekre válaszoló chunkokat. Legyenek köztük rövid kulcsszavas kérdések és hosszú kérdések is, minden nyelven, amelyen a felhasználóid írnak.
2.  Válassz három-öt jelöltet: egy olcsó hosztolt modellt, egy erős hosztolt modellt, egy nyílt súlyú modellt és azt, amit a jelenlegi rendszered használ.
3.  Embeddeld ugyanazokat a chunkokat mindegyikkel, a helyes lekérdezés- és dokumentummóddal, abban a dimenzióban, amelyet élesben használnál.
4.  Mérd jelöltenként a recall@10 és az nDCG@10 értéket, aztán ismételd meg hibrid kereséssel és rerankerrel, mert a reranker elfedheti az első lépcső különbségeit. A metrikákat a [RAG értékelése](https://balazscsorba.com/hu/blog/rag-evaluation-metrics) cikk magyarázza.
5.  Tedd egy táblázatba a minőséget, az indexméretet, a millió tokenenkénti költséget és a p95 lekérdezési késleltetést, és a minőségi kereten belüli legolcsóbb modellt válaszd.

**Soha ne keverj modelleket egy indexben**

A vektorkeresés gond nélkül összeveti az A modell lekérdezését a B modell dokumentumaival, és magabiztos zagyvaságot ad vissza. Minden vektor mellé tárold a modell nevét, verzióját és dimenzióját, a lekérdezési útvonal pedig tagadja meg a keresést egy másik modellel épített indexben.

## Hogyan készülj fel a következő modellre?

Lesz még váltás; az elmúlt két év kiadási tempója alapján erre nyugodtan lehet fogadni. Az első naptól tervezz vele: őrizd meg a feldolgozott és chunkolt szöveget, hogy az újraembeddelés ne jelentsen újrafeldolgozást, verziózd az index nevét a modellel, és az új indexet a régi mellé építsd fel. Futtasd le mindkettőn az összehasonlító teszt kérdéseit, tükrözd az éles forgalom egy részét, majd konfigurációváltással válts át, és tartsd meg a régi indexet, amíg az értékelés stabil. Ugyanez a fegyelem érvényes a generáló modellre is, amit az [LLM-modellváltás regresszió nélkül](https://balazscsorba.com/hu/blog/llm-model-migration-regression-testing) cikkben írtam le.

## Mik az ésszerű alapválasztások 2026 végén?

Ezek a véleményeim, nem benchmarkeredmények. Egy olyan német vagy magyar B2B-tudásbázisnál, amely használhat hosztolt API-t, az összehasonlító tesztet egy közös terű, több méretben elérhető modellcsaláddal, egy Gemini-modellel és nyílt alapvonalként a Qwen3-Embedding-0.6B modellel kezdem. Ha a dokumentumoknak helyben kell maradniuk, a Qwen3-Embedding két méretét vetem össze az EmbeddingGemmával, és a nagyobbat csak akkor választom, ha a mért javulás igazolja a plusz hardvert. Mindkét esetben legfeljebb 1024 dimenzióval élesítek, hacsak a teszt nem mutat egyértelmű veszteséget.

A modell kevésbé számít, mint várnád, ha a chunkolás, a hibrid keresés és a rerankelés már a helyén van. Az első hetet az értékelőkészletre fordítsd, mert az túlél minden modellt, amit kipróbálsz.

## Források

1.  [Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (2025)](https://arxiv.org/abs/2502.13595)
2.  [Hugging Face: Introducing RTEB, a new standard for retrieval evaluation (Oct 2025)](https://huggingface.co/blog/rteb)
3.  [OpenAI: Vector embeddings guide](https://developers.openai.com/api/docs/guides/embeddings)
4.  [OpenAI: API pricing](https://developers.openai.com/api/docs/pricing)
5.  [Voyage AI: The Voyage 4 model family, shared embedding space with MoE architecture (Jan 2026)](https://blog.voyageai.com/2026/01/15/voyage-4/)
6.  [Voyage AI: Text embeddings documentation](https://docs.voyageai.com/docs/embeddings)
7.  [Voyage AI: Pricing](https://docs.voyageai.com/docs/pricing)
8.  [Google: Gemini API embeddings documentation](https://ai.google.dev/gemini-api/docs/embeddings)
9.  [Google: Gemini API pricing](https://ai.google.dev/gemini-api/docs/pricing)
10.  [Cohere: Embed models documentation](https://docs.cohere.com/docs/cohere-embed)
11.  [Qwen: Qwen3-Embedding-8B model card](https://huggingface.co/Qwen/Qwen3-Embedding-8B)
12.  [Google Developers Blog: Introducing EmbeddingGemma (Sep 2025)](https://developers.googleblog.com/en/introducing-embeddinggemma/)

## Gyakori kérdések

Melyik a legjobb embedding-modell 2026-ban?

Nincs egyetlen legjobb. A ranglisták havonta változnak, a szolgáltatók pedig saját maguk által futtatott benchmarkokat közölnek. Válassz három-öt jelöltet, amelyek lefedik a nyelveidet, a kontextushosszt és a hosztolási feltételeket, aztán mérd le őket a saját kérdéseiden.

Megbízható az MTEB-ranglista?

Jó kiindulópont egy szűkített listához. A gyengesége, hogy a nyilvános tesztkészletek bekerülhetnek a tanítóadatokba, ezért vezették be az MTEB karbantartói 2025 októberében az RTEB-et olyan privát adatkészletekkel, amelyeket ők maguk értékelnek ki.

Válthatok embedding-modellt újraembeddelés nélkül?

Általában nem. A különböző modellek vektorai különböző terekben élnek. Kivételt a közös térre épített modellcsaládok jelentenek, például a Voyage 4 család, ahol a voyage-4-large-dzsel embeddelt dokumentumok voyage-4-lite lekérdezésekkel is kereshetők.

Használjak nyílt forráskódú embedding-modellt?

Igen, ha az adatnak a saját infrastruktúrádon kell maradnia, ha a lekérdezések mennyisége drágává teszi az API-hívásokat, vagy alapvonalként az összehasonlító tesztben. A Qwen3-Embedding (Apache 2.0) és az EmbeddingGemma elég kicsi ahhoz, hogy átlagos szervereken fusson.

Hány dimenzióra van szükségem?

Többnyire kevesebbre, mint az alapértelmezett. A Matryoshka-tanítású modelleknél hívásonként csökkentheted a dimenziót; mérd a recallt 256, 512 és 1024 dimenziónál, és a minőségi kereten belüli legkisebb méretet tartsd meg.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [PDF-feldolgozás RAG-hoz: layout-pipeline-ok, OCR és vizuális modellek összevetve](https://balazscsorba.com/hu/blog/pdf-document-parsing-for-rag)
-   [Többnyelvű RAG német és magyar tartalomra: embeddingek, összetett szavak és nyelvek közötti keresés](https://balazscsorba.com/hu/blog/multilingual-rag-german-hungarian)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)