SPLADE és tanult ritka visszakeresés a gyakorlatban: BM25, indexméret, késleltetés

A tanult ritka visszakeresés megtartja a BM25 működését, a szókincsbeli kifejezések invertált indexét, de a kézzel hangolt kifejezésstatisztikák helyett egy nyelvmodell által tanult súlyokat használ, és olyan bővítő kifejezéseket ad hozzá, amelyek sosem szerepelnek a szövegben. A legismertebb család a SPLADE. Így egy „rozsdamentes golyóscsapról” szóló dokumentum illeszkedhet egy „korrózióálló elzárószelep” lekérdezésre, miközben az index, a lekérdezőmotor és a pontos kifejezésegyezés ugyanaz marad, amit már üzemeltet.

Ez a cikk bemutatja, hogyan bővíti a SPLADE a szöveget, a modellcsaládot és a licenccsapdáját, mibe kerül az index és a lekérdezés, hogyan futtatja az Elasticsearch és az OpenSearch, és mikor jobb a BM25-nél vagy egy sűrű hibrid keresésnél. Hogy a ritka visszakeresés hol helyezkedik el egy teljes RAG-folyamatban, azt a RAG-folyamatok: darabolás, hibrid keresés és újrarangsorolás című cikk írja le; a számok 2026 októberi állapotot tükröznek.

Mi a tanult ritka visszakeresés

BM25-szerű visszakeresés tanult súlyokkal és tanult szókincsbővítéssel. Minden dokumentum és lekérdezés a modell szókincse fölötti vektorrá válik, nagyrészt nullákkal, pozitív súlyokkal a fontos kifejezéseken, beleértve a modell által hozzáadott rokon kifejezéseket is. Mivel a vektor ritka, és kifejezések szerint kulcsolt, belefér egy invertált indexbe, és megőrzi a kulcsszavas keresés átláthatóságát: látja, mely kifejezések illeszkedtek.

A javulás főként a tanítási területen kívül jelentkezik. A SPLADE++-tanulmányban 13 BEIR-adathalmazon a BM25 átlaga 43,7 nDCG@10 volt, a Contrieveré 47,5, a ColBERTv2-é 49,7, a SPLADE++-é 50,5–50,7; a SPLADE++ és a BM25 pontszámainak összege 52,1-et ért el, vagyis a kettő továbbra is kiegészíti egymást (SPLADE++). A tanítási területen, MS MARCO-n ugyanez a tanulmány a BM25-re 18,4, a SPLADE++-ra 38,0 MRR@10-et közöl.

A sűrű visszakeresők más úton oldanak meg hasonló problémát: néhány száz vagy ezer folytonos dimenzióra képezik le a szöveget, és vektoros hasonlóság alapján illesztenek. Erősek a jelentésben, gyengék a ritka pontos kifejezésekben, és a találataikat nehéz megmagyarázni. A tanult ritka visszakeresés a kettő között áll: megtartja a pontos kifejezésegyezést és az áttekinthető szókincset, a nyelvmodellt pedig csak arra használja, hogy eldöntse, mely kifejezések számítanak, és mely rokon kifejezéseket kell hozzáadni.

Hogyan bővíti a SPLADE a szöveget

A SPLADE a BERT maszkolt nyelvmodell-fejét használja újra, amely minden bemeneti tokenre már megjósolja, mennyire valószínű az adott helyen a szókincs bármely kifejezése. Ezeket a pontszámokat ReLU-n és logaritmikus telítésen vezeti át, maximum-poolinggal összevonja a bemeneti tokeneken, és szókincsbeli kifejezésenként egy súlyt kap, a BERT szókincsénél 30 522-t (SPLADE-v3). Tanítás közben egy ritkasági regularizáló a legtöbb súlyt nullára nyomja, így minden szöveg csak a fontos kifejezéseit és korlátozott számú bővítést tart meg.

A bővítésnél romolhat is el valami. Egy webes kérdéseken tanított modell olyan kifejezéseket is hozzáadhat, amelyek az általános angolban hihetők, az Ön területén viszont félrevezetők, például egy termékcsalád nevét egy független köznapi szóhoz rendeli. Ha a lenti kódrészlethez hasonlóan kiírja a legfontosabb bővítő kifejezéseket a saját dokumentumai egy mintájára, az percek alatt megvan, és gyorsan megmutatja, érti-e a modell a szókincsét, vagy adaptálni kell.

A regularizáló erőssége a fő szabályozó: erősebb regularizálás kevesebb nem nulla kifejezést, kisebb indexet és gyorsabb lekérdezést jelent, némi minőségi áron. A Naver saját repója pontosan ezért írja le a SPLADE-et úgy, mint „inkább modellek egy osztálya, mint egyetlen modell” (naver/splade). A lekérdezés és a dokumentum eltérően is kódolható, és ezt használják ki a lenti hatékony és csak dokumentumoldali változatok.

# Encode with a learned sparse model and inspect the expansion terms (sentence-transformers SparseEncoder)
from sentence_transformers import SparseEncoder

model = SparseEncoder("Qdrant/Splade_PP_en_v1")        # Apache-2.0 re-host; check the license you deploy
doc = model.encode_document(["Stainless steel ball valve DN50, PN40, threaded ends"])
query = model.encode_query(["corrosion resistant shut-off valve 2 inch"])

for token, weight in model.decode(doc[0], top_k=12):    # expansion terms that were never in the text
    print(f"{token:>14}  {weight:.2f}")
print(model.similarity(query, doc))                     # dot product over the shared vocabulary

A modellcsalád és a licenccsapda

A SPLADE v2-t a SPLADE++ követte, amely cross-encoderből való desztillációt, bányászott nehéz negatívokat és CoCondenser-inicializálást adott hozzá, majd 2024 márciusában a SPLADE-v3, amely MS MARCO-n 40,2 MRR@10-et, BEIR-13-on 51,7 átlagos nDCG@10-et közöl, legfeljebb 512 bemeneti tokennel (SPLADE-v3). 2026-ban a Naver kiadta a SPLADE-Code-06B-t is, egy Qwen3-alapú, 0.6B-s kódmodellt, amelyet a modellkártyája az 1B paraméter alatti legjobb MTEB-modellként mutat be; ezt kezelje gyártói állításként (SPLADE-Code).

A hatékonyság a gyakorlatban: indexméret és késleltetés

A bővítés meghosszabbítja a posting-listákat, így egy tanult ritka index nagyobb és lassabban bejárható, mint egy ugyanarról a szövegről készült BM25-index; hogy mennyivel, az a modell regularizálásának erősségén múlik, és nem találtam erre egyetlen elsődleges arányszámot. A mért költségek viszont konkrétak. Az OpenSearch MS MARCO-n futtatott benchmarkja szerint a BM25 5,4 ms fix késleltetés plusz millió dokumentumonként 2,80 ms, a csak dokumentumoldali neurális ritka keresés 8,7 ms plusz millió dokumentumonként 5,15 ms, ami a BM25 bejárásának nagyjából 1,8-szorosa (OpenSearch).

A drága mód az, amely minden lekérdezésnél modellt futtat. Ugyanebben a benchmarkban a bi-encoder mód 265,4 ms fix késleltetést és millió dokumentumonként 20,58 ms-ot adott; az OpenSearch kétfázisú processzora, amely először a nagy súlyú tokenekkel pontoz, majd finomít, az átlagos késleltetést csak dokumentumoldali módban 53,56-ról 38,61 ms-ra, bi-encoder módban 300,79-ről 121,64 ms-ra csökkentette. A Naver hatékonysági munkája külön, könnyebb lekérdezéskódolókkal 4 ms-on belül került a BM25 késleltetéséhez, kevesebb mint 10 százalékos MRR@10-veszteséggel (naver/splade).

A metszés a legolcsóbb eszköz. A tanult ritka indexek statikus metszése legfeljebb 2 százalékos minőségvesztéssel kétszeres, legfeljebb 8 százalékossal négyszeres gyorsulást adott, a rerankerek pedig a metszett indexekből származó jelölteken is robusztusak maradtak (statikus metszés). Az OpenSearch betöltési processzora többféle metszést támogat, és a 0,1-es max_ratio kevesebb mint 1 százalékos relevanciaveszteség mellett nagyjából 40 százalékkal csökkenti a tárigényt (OpenSearch).

Támogatás az Elasticsearchben és az OpenSearchben

Mindkét motor súlyozott kifejezésekként tárolja a tanult ritka vektorokat az invertált indexen. Az Elasticsearchben a sparse_vector a használandó mezőtípus; a tokenmetszés a 9.1 óta alapból be van kapcsolva, a ritka vektorok a 9.2 óta alapból kimaradnak a _source-ból, a súlyokat pedig 9 értékes biten tárolja, nagyjából 0,4 százalékos relatív hibával (Elastic). Az Elastic saját modellje, az ELSER v2 csak angolul működik, egy mező első 512 tokenjét kódolja, és 12 BEIR-adathalmazból 10-en legyőzte a BM25-öt, átlagosan 18 százalékkal jobb nDCG@10-zel (ELSER).

Az ELSER lekérdezésoldali optimalizálását érdemes elvként átvenni: hagyja el a vártnál sokkal gyakoribb lekérdezéstokeneket, tartsa meg a maximális súly 0,4-szerese fölötti tokeneket, és a top 50-et pontozza újra a teljes tokenkészlettel. Az Elastic átlagosan 3,4-szeres gyorsulást jelent elhanyagolható nDCG@10-változás mellett (Elastic Search Labs). Összefésüléshez az Elasticsearch RRF retrievere egy BM25 standard retrievert kombinál egy ELSER retrieverrel, alapértelmezett 60-as rank_constant mellett (RRF). Az OpenSearch csak dokumentumoldali és bi-encoder módú neurális ritka keresést, kétfázisú processzort, a 3.3 óta pedig közelítő keresést kínál sparse_vector mezőkön.

A dedikált vektortárak is támogatják a ritka vektorokat, ami akkor számít, ha már üzemeltet ilyet; ezt az oldalt a Qdrant-ismertető tárgyalja. A keresőfürtön belüli vektorok általános működését a vektoros keresés Elasticsearchben és OpenSearchben írja le.

A gyakorlatban a motorválasztás a már futó fürtöt követi. Ha Elasticsearchet használ Elastic-előfizetéssel és angol tartalommal, az ELSER a legkevesebb munka. Ha OpenSearchet, akkor annak saját ritka modelljei és a csak dokumentumoldali mód a természetes kezdés. Ha bármelyik motorban nyílt SPLADE-checkpointot szeretne, kódolja a dokumentumokat saját betöltési feladatban, és a tokensúlyokat írja egy ritka mezőbe, amelyet mindkét motor elfogad.

Mikor jobb a BM25-nél, és mikor nem

A tanult ritka visszakeresés ott segít a legtöbbet, ahol a lekérdezések és a dokumentumok mást szóval mondják ugyanazt: felhasználói kérdések műszaki dokumentációval szemben, természetes nyelvű termékkeresések tömör katalógusszöveggel szemben, szinonimák és átfogalmazások angolul. Ráadásul egy második visszakeresőt ad, amelynek találatai kifejezésről kifejezésre magyarázhatók, amit a sűrű vektorok nem tudnak. A Spryker- és Pimcore-munkákból ismert, cikkszámokkal és normalizált attribútumokkal teli B2B katalógusokban éppen a bővítés és a pontos kifejezések kombinációja a fő motiváció.

Kevésbé segít, ha a lekérdezések többnyire pontos azonosítók, amelyeket a BM25 már megtalál, ha a tartalom nem angol, a modell pedig csak angolul működik, mint az ELSER, vagy ha a korpusz olyan nagy, hogy egy második, hosszabb posting-lista a drága rész. A benchmarkokon sem egyöntetűen jobb; a SPLADE++ eredményei szerint egyes BEIR-adathalmazokon továbbra is a BM25 nyer. Kifejezetten a cikkszámos termékkeresést a szemantikus termékkeresés B2B-ben tárgyalja.

Tanítás és területi adaptáció

Egy ritka modell adaptálása egyetlen GPU-val is elérhető. A naver/splade repó tanítási forgatókönyvenként ad konfigurációkat, köztük egy 16 GB-os kártyára szabott, egy GPU-s konfigurációt, amely 37,2 MRR@10-et ér el (naver/splade). A Sentence Transformersben ma már teljes értékű SparseEncoder van SPLADE-specifikus veszteségfüggvényekkel, például SpladeLoss, CachedSpladeLoss és FlopsLoss, és támogatja a lekérdezés és a dokumentum aszimmetrikus kódolását (Sentence Transformers).

Az angoltól eltérő nyelveknél gyakran az adaptáció az egyetlen út, mert a legtöbb publikált ritka checkpoint, köztük az ELSER, csak angolul működik. Egy BERT-szerű szókincsű többnyelvű alapmodell ugyanazokkal a veszteségfüggvényekkel ritka kódolóvá tanítható, de maga a szókincs korlátozza, mi bővíthető; a német összetett szavakat például szódarabokra bontja, és a bővítés ezeken a darabokon működik, nem egész szavakon.

Az adatoldal ugyanaz, mint a sűrű finomhangolásnál: lekérdezés–dokumentum párok naplókból vagy generált lekérdezésekből, bányászott nehéz negatívok és egy befagyasztott kiértékelő készlet; ezt a ciklust a beágyazó modellek finomhangolása tárgyalja. A ritkasági regularizáló a plusz szabályozó, és érdemes végigpróbálni, mert közvetlenül cseréli a minőséget indexméretre és késleltetésre.

Gyakorlati ellenőrzőlista

1. Először mérje meg a BM25-öt és a jelenlegi hibrid keresését egy címkézett lekérdezéskészleten.
2. Ellenőrizze pontosan a checkpoint licencét; a Naveréi nem kereskedelmi célúak.
3. Vesse össze a modell nyelvi lefedettségét a tartalmával.
4. Csak dokumentumoldali módban kezdjen, és késleltetésmérés előtt metssze a tokeneket.
5. RRF-fel fésülje össze BM25- vagy sűrű találatokkal, majd vesse össze nélküle végzett összefésüléssel.
6. Mérje az indexméretet és a p95 késleltetést a valós dokumentumszámán.
7. Csak akkor tartsa meg, ha a recall a saját k-ja mellett annyit javul, hogy megérje a második index.

Ha azt mérlegeli, kiérdemli-e egy tanult ritka visszakereső a helyét a BM25 és a sűrű keresés mellett, nézze meg a MI-mérnöki munkámat.

Források

1. naver/splade on GitHub
2. SPLADE++ (arXiv 2205.04733)
3. naver/splade-v3 model card
4. Static pruning for learned sparse indexes (arXiv 2304.12702)
5. OpenSearch blog: faster semantic sparse retrieval in 2.12
6. OpenSearch docs: sparse encoding processor
7. Elastic docs: sparse_vector field type
8. Elastic docs: ELSER
9. Elastic Search Labs: ELSER v2, part 2
10. Sentence Transformers: sparse encoder usage