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

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 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.

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 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 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 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.

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 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.

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 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)
2. Hugging Face: Introducing RTEB, a new standard for retrieval evaluation (Oct 2025)
3. OpenAI: Vector embeddings guide
4. OpenAI: API pricing
5. Voyage AI: The Voyage 4 model family, shared embedding space with MoE architecture (Jan 2026)
6. Voyage AI: Text embeddings documentation
7. Voyage AI: Pricing
8. Google: Gemini API embeddings documentation
9. Google: Gemini API pricing
10. Cohere: Embed models documentation
11. Qwen: Qwen3-Embedding-8B model card
12. Google Developers Blog: Introducing EmbeddingGemma (Sep 2025)