TL;DR
A legtöbb RAG implementáció kizárólag embedding-alapú (dense) keresésre épül — és ezzel egy jól bevált, 30 éves eszközt hagy a polcon. A BM25 (sparse keresés) rövid, pontos kulcsszavas lekérdezéseknél szisztematikusan veri az embeddingeket. A hibrid keresés — ahol a két jel RRF (Reciprocal Rank Fusion) újrarangsorolással kombinálódik — megközelíti az elméleti maximumot anélkül, hogy választani kellene. A kérdés nem az, hogy dense vagy sparse, hanem hogy mikor éri meg a hibrid pipeline komplexitása.
A könyvtáros, aki sosem felejtett el egy szót
Van egy kép, amit nehéz kiverni a fejemből: egy régi könyvtáros, aki fejből tudja, melyik polcon van minden könyv. Nem azért, mert megértette az összes tartalmat — hanem mert pontosan emlékszik a szavakra, a szerzőkre, a címekre. Ha azt mondod neki: „Akerlof, 1970, citromok,” azonnal mutatja az utat.
Az embedding-alapú keresés ezzel szemben inkább egy tapasztalt olvasóhoz hasonlít: érti a szöveg jelentését, megérzi a kapcsolatokat, de ha egy egzakt terminust keresel — egy cikkszámot, egy specifikus jogszabályt, egy ritka névmást —, néha elveszíti a fonalat. A szemantikai tér nem mindig tükrözi a lexikális pontosságot.
Ez a feszültség az alapja annak, amit hibrid keresésnek nevezünk.
Mi a különbség dense és sparse keresés között, és miért számít?
A dense keresés egy szöveget egy magas dimenziós vektortérbe ágyaz be, ahol a szemantikailag hasonló szövegek közel kerülnek egymáshoz. Ha azt kérdezed: „Milyen hatással van az infláció a fogyasztói bizalomra?”, a modell megérti a kérdés mögötti szándékot, és olyan dokumentumokat hoz fel, amelyek tartalmilag kapcsolódnak, még ha szóról szóra nem fedik egymást.
A sparse keresés (BM25 és rokonai) ezzel szemben a lexikális átfedésre épít. Megméri, milyen szavak jelennek meg a lekérdezésben és a dokumentumban, és súlyozza azokat a dokumentumon belüli előfordulás és az egész korpuszban való ritkaság szerint. Ez az TF-IDF logikájának finomított leszármazottja — egyszerű, determinisztikus, gyors.
A két megközelítés eltérő hibákat követ el:
- Dense keresés gyenge pontos kulcsszavaknál, ritka fogalmaknál, termékkódoknál, nevekneknél, ahol az embedding nem tud megbízható kapcsolatot felépíteni.
- Sparse keresés gyenge szinonimáknál, parafrázisoknál, kontextuális lekérdezéseknél, ahol a kulcsszó nem egyezik, de a jelentés igen.
A hibrid stratégia ezért nem egyszerűen jobb — hanem más hibákat követ el, és a két hibahalmaz metszete kicsi.
Hogyan működik az RRF, és miért érdemes rá építeni?
Az RRF (Reciprocal Rank Fusion) egy elegánsan egyszerű aggregációs módszer. Mindkét keresési rendszer visszaad egy rangsorolt listát. Az RRF minden dokumentumhoz kiszámít egy pontszámot: az összes listában kapott ranghelyezés reciprokösszege. Ha egy dokumentum mindkét rendszerben magas helyezést ér el, az összesített pontszáma domináns lesz.
A képlet: az egyes listák ranghelyeihez hozzáad egy kis konstanst (általában 60), majd veszi a reciprokot, és összeadja az összes listán kapott értéket. Ez az egyszerű mechanizmus rendkívül robusztus az outlier-ek ellen — egy rendkívül magas dense-pontszám nem nyomja el a sparse-jelet, ha az gyenge.
A módszer fő előnye, hogy nem igényel tanítást és nem érzékeny a két rendszer eltérő pontszám-skálájára. Nem szükséges kalibrálni azt, hogy egy cosine similarity 0.87 mennyit ér egy BM25 score 23-hoz képest — az RRF csak a relatív sorrendet nézi.
Mikor érdemes hibridet építeni, és mikor elég a pure dense?
Ez az a kérdés, ahol a legtöbb implementáció siet. A válasz a korpusz természetétől függ.
Pure dense elég, ha:
- A korpusz jól strukturált, egységes stílusú szövegekből áll (pl. vállalati tudásbázis, belső dokumentáció).
- A lekérdezések konceptuálisak, nem terminológia-specifikusak.
- Az embedding modell a domain-re jól kalibrált (pl. finomhangolt domain-specifikus modell).
Hibrid szükséges, ha:
- A korpusz vegyes: termékleírások, jogszabályok, szakmai glosszáriumok, nevekkel és kódokkal teli szövegek.
- A felhasználók pontos kulcsszavakkal keresnek, nem csak természetes nyelvű kérdésekkel.
- Az embedding modell általános célú, és a domain-specifikus terminológia nem szerepelt a tanítóadatokban.
- A lekérdezések között vannak „needle in a haystack” jellegű, pontos egyezést igénylő keresések.
A tapasztalatom az, hogy a vállalati RAG rendszerek döntő többsége a második kategóriába esik. Egy pénzügyi szolgáltató dokumentumainál, ahol jogszabályi hivatkozások, ISIN-kódok, és specifikus termékelnevezések szerepelnek, a pure dense keresés szisztematikusan elveszíti a legfontosabb, legpontosabb lekérdezéseket.
A komplexitás ára: mikor érdemes egyszerűbbnek maradni?
Minden hibrid pipeline növeli az infrastruktúra komplexitását. Két indexet kell fenntartani, két lekérdezési utat szinkronizálni, és az RRF aggregáció is egy extra lépés a latency-ben. Ha az alkalmazás valós idejű, ez számít.
Néhány esetben van egy egyszerűbb alternatíva: a dense-only keresés query expansion-nel. A lekérdezést az LLM segítségével parafrazeálják és kibővítik több szemantikus változattal, majd ezeket párhuzamosan keresik. Ez sokat segít a szinonimia-problémán, de nem old meg minden lexikális pontossági kihívást.
A döntési logika röviden: ha a korpuszodon elvégzett RAGAS kiértékelés (context recall, context precision) azt mutatja, hogy az egyezési hibák kulcsszavas jellegűek — azaz a releváns dokumentum benne van a korpuszban, de nem kerül be a top-k-ba —, akkor a hibrid megközelítés azonnal mérhető javulást hoz. Ha a hibák konceptuálisak — a relevancia megítélése nehéz, a kérdés és a dokumentum közötti szemantikai távolság a probléma —, akkor az embedding modell minőségén és a chunk stratégián kell dolgozni, nem a keresési módszeren.
A hibrid keresés nem mágikus megoldás. De az a RAG rendszer, amelyik soha nem foglalkozik a sparse jelekkel, vakon hagy egy dokumentumgyűjtemény legjobban kereshető dimenzióját.
Kapcsolódó gondolatok
Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership Build for the query you actually get, not the one you wish for.