Cross-encoder rerankerek: Cohere, bge, Voyage, Jina és késői interakció (2026)

A reranker együtt olvassa a lekérdezést és egy jelölt dokumentumot, és relevanciapontszámot ad, ami pontosabb két beágyazás összevetésénél, de túl lassú ahhoz, hogy egy teljes korpuszon fusson. Ezért kétlépcsős a visszakeresés: egy gyors visszakereső 50–250 jelöltet talál, egy cross-encoder pedig újrarendezi őket, hogy a legjobb néhány jusson a modellhez. A döntés az, melyik reranker, hány jelölt, és megéri-e a javulás a késleltetést.

Ez a cikk összeveti a pontozási architektúrákat, a 2026 októberében elérhető modelleket, a hosztolt árakat és a saját üzemeltetést, alternatívaként a késői interakciót és az LLM-rerankereket, valamint egy kis kiértékelést k megválasztásához. Hogy a teljes folyamatban hol a helye az újrarangsorolásnak, azt a RAG-folyamatok: darabolás, hibrid keresés és újrarangsorolás című cikk írja le.

Mit ad a reranker, és mibe kerül

A reranker pontosságot ad a lista elején, és k-val arányos késleltetésbe kerül. Hogy miért nem váltja ki a visszakeresést, az aritmetika: a Sentence-BERT-tanulmány szerint 10 000 mondat közül a leghasonlóbb pár megtalálása körülbelül 50 millió BERT-következtetést, nagyjából 65 órát igényel, ami „alkalmatlanná teszi szemantikus hasonlósági keresésre” (SBERT). A dokumentált éles felépítés ezért egy jelölteket kereső bi-encoder és egy azokat újrarangsoroló cross-encoder (Sentence Transformers).

A két szám, amelyet bevezetés előtt ismerni kell: az első lépcső recallja k mellett és k pár pontozásának többletkésleltetése. Ha a megfelelő dokumentum nincs a top 100-ban, semmilyen reranker nem találja meg; ha a 30. helyen van, és Ön öt találatot mutat, a reranker pontosan a megoldás. A cikkszámokat és hosszú német összetett szavakat tartalmazó termékkeresés tipikus eset, ahol a megfelelő tételt megtalálja, de túl hátra sorolja a rendszer, lásd szemantikus termékkeresés B2B-ben.

A második szám ugyanolyan fontos, mint az első. Pointwise modellnél minden jelölt egy újabb futás, így 50-ről 200 jelöltre lépve nagyjából négyszeresére nő az újrarangsorolás ideje. Egy interaktív keresőmezőben ezt a felhasználó észreveszi; egy háttérben készülő RAG-válasznál, amely amúgy is másodperceket vár a generálásra, talán egyáltalán nem számít. Írja le a késleltetési keretet, mielőtt modelleket hasonlít össze, mert ez dönti el, a lenti táblázat melyik fele jöhet egyáltalán szóba.

Hogyan pontoznak a rerankerek: párok, listák és tokenvektorok

Három architektúra van, és a modell nélküli összefésülés. A pointwise cross-encoder összefűzi a lekérdezést egy dokumentummal, és egy relevancia-logitot ad, így k jelölt k futást jelent. A listwise reranker a lekérdezést és az összes jelöltet egy kontextusablakba teszi, és egyetlen menetben rendezi őket. A késői interakció indexeléskor tokenenként egy vektort tárol, és lekérdezéskor MaxSim-mel illeszti hozzájuk a lekérdezés tokenjeit, így a munka nagy része kikerül a lekérdezés útjából.

A Jina Reranker v3 a legtisztább listwise példa: egy 0.6B-s modell, amely egyetlen ablakban olvassa a lekérdezést és az összes jelöltet, a Jina szavaival „last but not late interaction”. A 2026 augusztusi v3.5 megtartja a 0.6B paramétert, 131K tokenre bővíti a kontextust, és a v3-nál akár 1,56-szor gyorsabb újrarangsorolást jelent (Jina). A listwise modellek egymáshoz viszonyítva látják a jelölteket, ami a közel azonos találatoknál segít, de az egész listának bele kell férnie a kontextusba.

A 2026-os kínálat

2026 októberében a hosztolt sorozatok a Cohere Rerank 4, amely 2025 decemberében jelent meg rerank-v4.0-pro és rerank-v4.0-fast változatban 32k kontextussal, valamint a 2026. szeptember 30-án kiadott Voyage rerank-3 és rerank-3-lite, szintén 32k-val. A Voyage szerint a rerank-3 95 adathalmazon 2,72 százalékkal jobb a Cohere Rerank 4 Prónál (Voyage); ez gyártói állítás gyártói tesztsoron, nem független eredmény. A nyílt modellek licence megengedi a kereskedelmi saját üzemeltetést.

A BAAI/bge-reranker-v2-m3 az elterjedt nyílt alapválasztás: 0.6B-s többnyelvű cross-encoder XLM-RoBERTa alapon, Apache-2.0 licenccel, az elmúlt hónapban több mint 15 millió letöltéssel (Hugging Face). A Qwen3-Reranker-8B a Qwen3 Embedding sorozat nehézsúlyú nyílt változata, a mixedbread mxbai-rerank-large-v2 modellje pedig 1,54B paraméterrel, FP16-ban nagyjából 3,09 GB-tal a kettő között áll, több mint 100 nyelvvel (mixedbread).

Két gyakorlati különbség többet számít egy nDCG-pontnál. A kontextushossz dönti el, hogy egy hosszú termékadatlap vagy szerződéses záradék egyetlen dokumentumként belefér-e, vagy fel kell darabolni; a Cohere v4-es modelljei 32 764 tokennél darabolják a dokumentumokat, és a legmagasabb darabpontszámot tartják meg. A nyelvi lefedettség dönti el, hogy a német és magyar lekérdezések ugyanolyan jól működnek-e, mint az angolok, ezért európai tartalomhoz általában a többnyelvű bge, mxbai és Cohere modellek a jelöltek.

Árak: keresésenként, tokenenként vagy a saját CPU-n

A hosztolt rerankereket két különböző egységben árazzák, ezért nehéz első ránézésre összevetni őket. A Cohere keresésenként számláz: 1000 keresésenként 2,00 dollár a Rerank 4 Fast és 2,50 a Rerank 4 Pro, ahol egy keresés egy lekérdezés legfeljebb 100 dokumentummal, az 500 tokennél hosszabb dokumentumok pedig többnek számítanak (Cohere árak). A Voyage tokenenként számláz: millió tokenenként 0,05 dollár a rerank-3 és 0,02 a rerank-3-lite (Voyage árak).

Választás előtt hozza közös nevezőre a kettőt. 100, egyenként körülbelül 300 tokenes jelöltnél egy lekérdezés nagyjából 30 000 token: kb. 0,0015 dollár a rerank-3-mal és 0,0025 a Rerank 4 Próval. Hosszabb daraboknál megfordul az arány, mert a Cohere dokumentumonként, a Voyage tokenenként számol. A Cohere hasznos korlátokat is dokumentál: lekérdezésenként legfeljebb 2048 token, és azt ajánlja, hogy kérésenként ne küldjön 1000-nél több dokumentumot (Cohere).

Saját üzemeltetésnél az ár számítási kapacitássá alakul. CPU-n a méret a gyakorlati korlát: a FastEmbed ONNX rerankerei a ms-marco-MiniLM-L-6-v2 0,08 GB-jától a jina-reranker-v2-base-multilingual 1,11 GB-jáig terjednek, utóbbi csak nem kereskedelmi célra licencelt (FastEmbed). Páronkénti CPU-késleltetésre nem találtam elsődleges benchmarkot, ezért elköteleződés előtt mérjen a saját hardverén, a saját darabhosszával. A saját Nuxt-oldalamon, ahol LLM-funkciókat futtatok, az ilyen feladatra az olcsó út a hibrid visszakeresés és egy kis ONNX-modell a szerveren, nem lekérdezésenként egy LLM-hívás.

A késői interakció mint alternatíva

A késői interakció más kompromisszum, nem jobb cross-encoder. A ColBERTv2 tokenenként egy vektort tart, reziduális tömörítéssel hat-tízszeresére csökkenti a késői interakciós modellek tárigényét, és lekérdezéskor olcsó MaxSim-mel pontoz (ColBERTv2). Lekérdezési késleltetés helyett indexmérettel fizet, ami nagy k-hoz és nagy lekérdezésszámhoz illik. Oldalképekhez ugyanez az ötlet hajtja a ColPalit, lásd multimodális RAG ColPalival. A rerankers könyvtár egy felület mögé csomagolja a cross-encodereket, az API-kat és a késői interakciós modelleket, így egy kiértékelésben könnyű cserélgetni őket (rerankers).

LLM-rerankerek, és mikor elég önmagában az RRF

Egy általános LLM is tud újrarangsorolni, de ritkán ez a legolcsóbb út. A RankGPT megmutatta, hogy egy jól instruált GPT-4 az IR-benchmarkokon felveheti a versenyt a felügyelt rerankerekkel, sőt jobb is lehet náluk, és hogy egy desztillált 440M-es modell legyőzött egy felügyelt 3B-s modellt a BEIR-en (RankGPT). A Voyage saját tanulmánya a másik oldalt képviseli: szerinte a célra épített rerankerek akár 60-szor olcsóbbak és 48-szor gyorsabbak az LLM-eknél (Voyage); mindkét forrás érdekelt, ezért a saját adatain teszteljen.

A reciprocal rank fusion a legolcsóbb lépés, és gyakran ez az első, amit érdemes hozzáadni. Több visszakereső rangsorát kizárólag a pozíciók alapján fésüli össze; az Elasticsearch egy alapértelmezésben 60-as rank_constant és egy rank_window_size paraméterrel valósítja meg (Elastic). Az RRF elég, ha a BM25 és a vektoros keresés más-más jó találatokat hoz, és az összefésült lista eleje már rendben van. Akkor tegyen rá modellt, ha a megfelelő dokumentum rendszeresen az összefésült top 50-ben van, de nem a top 5-ben.

k és a modell kiválasztása egy kis kiértékeléssel

Induljon egy ismert alapértékről, és hagyja, hogy egy kis címkézett készlet mozdítsa el. Az Azure AI Search szemantikus rangsorolója csak a top 50 találatot viszi tovább, dokumentumonként legfeljebb 2000 tokennel, egy BM25- vagy RRF-alapú eredményhalmazból kiindulva (Azure). Ez észszerű kezdő k. Ezután címkézzen fel 50 valódi lekérdezést azokkal a dokumentumokkal, amelyeknek meg kell válaszolniuk őket, és mérje a 10-es recallt újrarangsorolás előtt és után 25-ös, 50-es és 100-as k mellett.

# A small reranker eval: 50 labelled queries, recall@k before and after reranking
from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

def recall_at(ranked_ids, relevant_ids, n):
    return len(set(ranked_ids[:n]) & relevant_ids) / len(relevant_ids)

for k in (25, 50, 100):
    before, after = [], []
    for q in labelled_queries:                       # [{"text": ..., "relevant": {...}}]
        hits = first_stage(q["text"], k=k)           # your hybrid search: [(id, text), ...]
        scores = reranker.predict([(q["text"], t) for _, t in hits])
        reranked = [i for (i, _), _ in sorted(zip(hits, scores), key=lambda p: -p[1])]
        before.append(recall_at([i for i, _ in hits], q["relevant"], 10))
        after.append(recall_at(reranked, q["relevant"], 10))
    print(k, sum(before) / len(before), sum(after) / len(after))

Ne növelje tovább k-t, ha a 10-es recall már nem javul, és ezt mérje össze a mért késleltetéssel. Futtassa ugyanazt a szkriptet két-három modellel, és tartsa meg a legolcsóbbat, amely legfeljebb egy ponttal marad el a legjobbtól. Minden beágyazómodell-csere után futtassa újra, mert az első lépcső dönti el, mit lát a reranker. Hogy az ilyen kiértékelések hogyan illeszthetők egy kiadási folyamatba, azt az LLM-kiértékelések termékfunkciókhoz című cikk írja le.

Mikor ne használjon rerankert, és egy ellenőrzőlista

Hagyja ki a rerankert, ha az első lépcső már az első néhány találat közé teszi a jó választ, ha a lekérdezésekben a pontos azonosítók dominálnak, és a BM25 megtalálja őket, vagy ha a késleltetési keret nem bír el k további futást. Ilyenkor a jobb darabolás, a metaadat-szűrők vagy az RRF kevesebbért többet ad. Akkor vegyen fel egyet, ha a kiértékelés szerint a releváns dokumentumok közvetlenül a vágási határ alatt vannak.

1. Mérje az első lépcső recallját k mellett, mielőtt rerankert választ.
2. Fésülje össze RRF-fel a BM25- és vektoros találatokat, mielőtt modellt tesz rá.
3. Kezdjen 50-es k-val, és adjon vissza 5–20 találatot.
4. Számolja át a hosztolt árakat lekérdezésenkénti költségre a saját darabhosszán.
5. Saját üzemeltetés előtt ellenőrizze a licencet; egyes rerankerek nem kereskedelmi célúak.
6. A többletkésleltetést a saját hardverén mérje, ne publikált számokból vegye át.
7. Futtassa újra az 50 lekérdezéses kiértékelést minden modell- vagy darabolásváltás után.

Ha egy RAG-rendszer vagy termékkeresés visszakeresését hangolja, és számokkal szeretné alátámasztani a reranker-döntést, nézze meg a MI-mérnöki munkámat. Az alatta lévő vektortár választását a Qdrant-ismertető tárgyalja.

Források

1. Sentence-BERT (arXiv 1908.10084)
2. Sentence Transformers: retrieve and re-rank
3. BAAI/bge-reranker-v2-m3 model card
4. Cohere docs: reranking best practices
5. Cohere pricing
6. Voyage AI blog: rerank-3 (30 Sep 2026)
7. Voyage AI docs: pricing
8. Jina AI: Reranker v3.5 (3 Aug 2026)
9. ColBERTv2 (arXiv 2112.01488)
10. Elasticsearch docs: reciprocal rank fusion
11. Azure AI Search: semantic ranking overview
12. RankGPT (arXiv 2304.09542)