Vektoros keresés Elasticsearchben és OpenSearchben: kNN, hibrid keresés és a licencek

A vektoros keresés Elasticsearchben és OpenSearchben azt jelenti, hogy a valószínűleg már üzemelő keresőmotort használja vektortárként: egy dense_vector vagy knn_vector mező a szöveges mezők mellett, rajta közelítő legközelebbi-szomszéd keresés, és ugyanabban a kérésben BM25-tel kombinált hibrid rangsorolás. Egy webshopnál vagy webhelynél, ahol már van keresőfürt, ez gyakran egyszerűbb egy külön vektoradatbázisnál, ha a memória és a licenc rendben van.

Ez a cikk bemutatja, hogyan működik a kNN és a szűrés a két motorban, hol változtat a kvantálás a memóriaszámlán, a hibrid összefésülést RRF-fel, a GPU-s indexépítést, a 2021 és 2024 közötti licenctörténetet, és azt, mikor jobb egy dedikált tár. A dedikált lehetőségeket a pgvector és a vektoradatbázisok és a Milvus és Zilliz ismertető veti össze. A verziók 2026 októberi állapotot tükröznek: Elasticsearch 9.5 és OpenSearch 3.9.

Kell vektoradatbázis, ha már fut keresőfürt?

Gyakran nem. Ha a szöveges keresés már Elasticsearchben vagy OpenSearchben él, egy vektormező hozzáadásával egyetlen lekérdezésben kap szemantikus és kulcsszavas visszakeresést, strukturált mezőkre szűrést és összefésülést, egyetlen üzemeltetendő és mentendő rendszerrel. Az ára a memória: a HNSW-alapú közelítő kNN csak akkor hatékony, ha a vektoradatok beférnek a csomópont page cache-ébe (Elastic). Ez az egy feltétel határozza meg a lenti döntések többségét.

A B2B termékkeresés a tipikus eset: a lekérdezések keverik a cikkszámokat, a márkaszűrőket és a laza leírásokat, így a kulcsszavas és a vektoros visszakeresés kiegészíti egymást. Ezt a mintát a szemantikus termékkeresés B2B-ben írja le. Sok Spryker- vagy Pimcore-alapú webshop már üzemeltet ilyen fürtöt a katalógushoz, ezért a motor saját vektortámogatása a kézenfekvő első kísérlet.

Üzemeltetési szempontból egy fürt egyetlen mentési rendet, egyetlen hozzáférési modellt és egyetlen helyet jelent, ahol a dokumentumok frissülnek. Ha egy termék változik, a szöveges mezői és a beágyazása ugyanabban a dokumentumfrissítésben íródik, így a kulcsszavas és a vektoros index nem csúszhat szét. Külön vektoradatbázisnál ezt a szinkronizálást, a törléseket is beleértve, Önnek kell megépítenie és felügyelnie, és a legtöbb elavult találatos hiba éppen itt keletkezik.

Hogyan működik a kNN és a szűrés a két motorban

Az Elasticsearch három belépési pontot kínál a közelítő kNN-hez: a legfelső szintű knn opciót, egy knn lekérdezést és egy knn retrievert, kis jelölthalmazokra pedig pontos, nyers erős kNN-t; a dense_vector mezőkön a közelítő keresés alapból be van kapcsolva (Elastic). A legfontosabb beállítás az, hová kerül a szűrő. A kNN-záradékon belüli szűrő a közelítő keresés közben érvényesül, így k illeszkedő dokumentumot kap. A bool lekérdezésben a kNN-záradék mellé tett szűrő utána fut, és k-nál kevesebbet is adhat (Elastic).

A második szabályozó a num_candidates: hány jelöltet gyűjt ki shardonként a gráfból, mielőtt kiválasztja a top k-t. Növelése javítja a recallt és késleltetésbe kerül, és ez az első beállítás, amelyhez hozzányúl, ha az eredmények kicsit pontatlanok. Tartsa k-t közel ahhoz, amit ténylegesen megjelenít vagy továbbad, például 50 egy rerankernek vagy 10 egy válasznak, a num_candidates értékét pedig emelje ennek két-négyszeresére, miközben egy mintán pontos kNN-hez méri a recallt.

Az OpenSearchben mezőnként választhat motort: Lucene HNSW-vel és hatékony natív szűréssel, Faiss HNSW-vel és IVF-fel, valamint skalár, szorzat- és bináris kódolókkal, az elavult NMSLIB, és a JVector, egy tisztán Java nyelvű, DiskANN-szerű motor szorzatkvantálással és párhuzamos beszúrással (OpenSearch). A legtöbb új indexnél a Lucene vagy a Faiss a kiindulópont; a JVector akkor jön szóba, ha az index nagyrészt lemezen éljen.

A kvantálásnál dől el a memória

Mindkét motor ma már alapból vagy egyetlen beállítással kvantál, és az alapértékek gyorsan változtak. Az Elasticsearchben a 9.0 alapértéke int8_hnsw volt; a 9.1-től 384 vagy több dimenziójú vektoroknál bbq_hnsw, egyébként int8_hnsw; a 9.4-től pedig bbq_disk, ha a licenc engedi (Elastic). A BBQ a 8.16-tal jelent meg 2024 szeptemberében, akár 32-szeres tömörítéssel (Elastic), a dokumentáció szerint dimenziónként 96 százalékos memóriamegtakarítással, miközben a nyers vektorok az újrapontozáshoz a lemezen maradnak (BBQ).

A DiskBBQ, vagyis a bbq_disk típus, hierarchikus k-means módszerrel lemezen klaszterezi a vektorokat, nagyjából 95 százalékos recallig ajánlott, és Enterprise előfizetést igényel (BBQ). Az OpenSearch más úton ér el hasonló arányokat: a memóriaoptimalizált vektorok in_memory módban alapból 1-szeres, on_disk módban float esetén 32-szeres tömörítést használnak, 32-szeresnél 2,0-s túlmintavételezési tényezővel az újrapontozáshoz (OpenSearch), a Faiss bináris kvantálása pedig 1, 2 vagy 4 bitet támogat 32-, 16- vagy 8-szoros tömörítéssel (OpenSearch).

Szintválasztás előtt segít egy durva méretbecslés. Egymillió 1024 dimenziós float32 vektor nyersen nagyjából 4 GB, int8-ként kb. 1 GB, dimenziónként egy biten kb. 128 MB, plusz a gráf többletterhe. Néhány százezer termékes katalógusnál az int8 gyakran kényelmesen elfér, és magasan tartja a recallt; a BBQ milliós vektorszámnál vagy kis csomópontokon kezd megtérülni, ahol azon múlik, hogy az index egyáltalán befér-e a memóriába.

Kutatás közben nem találtam semleges, közvetlen benchmarkot a BBQ és az OpenSearch kvantálása között; ami létezik, azt maguk a gyártók publikálják. Mérje a recallt a saját k-ja mellett, a saját vektorain, a szintváltás előtt és után, és hagyja bekapcsolva az újrapontozást.

Hibrid keresés RRF-fel

Mindkét motor összefésüli a kulcsszavas és a vektoros találatokat, de más-más helyen. Az Elasticsearch a 8.8-ban vezette be a reciprocal rank fusiont, és a 8.16-ban retrieverekkel általánosan elérhetővé tette; az rrf retrieverhez legalább két gyermek retriever kell, a rank_constant alapértéke 60, és nem támogatja a sort, scroll és rescore funkciókat (Elastic). Az OpenSearch keresési pipeline-ban fésül össze: pontszámalapú normalizálással a 2.10 óta, és score-ranker processzorként RRF-fel a 2.19 óta.

PUT products
{
  "mappings": {
    "properties": {
      "title":     { "type": "text" },
      "brand":     { "type": "keyword" },
      "embedding": { "type": "dense_vector", "dims": 1024, "similarity": "cosine",
                     "index_options": { "type": "bbq_hnsw" } }
    }
  }
}

GET products/_search
{
  "retriever": {
    "rrf": {
      "retrievers": [
        { "standard": { "query": { "match": { "title": "Kugelhahn DN50 Edelstahl" } } } },
        { "knn": { "field": "embedding", "query_vector": [/* 1024 floats */], "k": 50,
                   "num_candidates": 200,
                   "filter": { "term": { "brand": "acme" } } } }
      ],
      "rank_constant": 60
    }
  }
}

Az OpenSearch hasznos összevetést publikált: hat BEIR-adathalmazon az RRF átlagosan 3,86 százalékkal alacsonyabb NDCG@10-et ért el, mint a pontszámalapú hibrid pipeline, hasonló késleltetés mellett (OpenSearch). Ha a pontszámskálák nagyon eltérnek, az RRF mégis a biztonságosabb alapválasztás, mert teljesen figyelmen kívül hagyja a pontszámokat. Ha az összefésült listát utána egy modellel finomítaná, lásd cross-encoder rerankerek összehasonlítva.

A gyakorlatban a relevanciaproblémák először az összefésülésnél jelentkeznek. Egy pusztán cikkszámból álló lekérdezést a BM25-nek kell megnyernie, egy homályos leírást a vektoroknak, és az RRF hangolás nélkül kezeli mindkettőt. Valódi lekérdezések egy mintáján naplózza, melyik retriever melyik találatot adta; ha az egyik oldal sosem járul hozzá, akkor vagy a lekérdezése rossz, vagy nem éri meg a költségét.

GPU-s indexépítés és betöltés

A HNSW-gráfok felépítése a betöltés drága része, és mindkét projekt ma már NVIDIA cuVS-re terheli. Az Elasticsearchben a GPU-s vektorindexelés a 9.3-ban előzetes volt, a 9.4 óta általánosan elérhető; Enterprise előfizetést, x86_64-es Linuxot, legalább 8 GB-os, Ampere vagy újabb GPU-t igényel, és csak float elemű hnsw és int8_hnsw indexekhez működik (Elastic). Az OpenSearch a 3.0-ban előzetesként, a 3.1-ben éles használatra készen szállította a GPU-gyorsítást, és a csak CPU-s építésnél akár 9,3-szor gyorsabb és 3,75-ször olcsóbb indexépítést jelent (OpenSearch).

A betöltés apróbb részletei is összeadódnak. Az OpenSearch 3.8 négyszer gyorsabb vektorbetöltést jelent Base64-kódolt vektorokkal, a 3.9 pedig bevezette a half_float vektortípust, valamint a 2 és 4 bites skalár kvantálást (OpenSearch). A lebegőpontos szélesség felezése indexelés előtt gyakran a legolcsóbb elérhető memórianyereség.

Egy naponta, nem másodpercenként változó katalógusnál ritkán a GPU-s építés a szűk keresztmetszet; a nagyobb betöltési költség általában maguknak a beágyazásoknak az előállítása. Kötegelje a beágyazási hívásokat, hagyja ki azokat a dokumentumokat, amelyek beágyazott szövege nem változott, és csak modellváltáskor ágyazzon be mindent újra. A GPU-s indexépítés több tízmillió vektor teljes újraépítésénél válik érdekessé, mert lerövidíti azt az időablakot, amíg egy új index készül.

A licenctörténet, és mit jelent Önnek

2021 áprilisában az AWS az Elasticsearch és a Kibana 7.10.2 közösségi forkjaként jelentette be az OpenSearch-öt Apache License 2.0 alatt (AWS), miután az Elastic az SSPL-re és saját Elastic License-ére váltott. 2024. augusztus 29-én az Elastic harmadik lehetőségként felvette az AGPL v3-at az ELv2 és az SSPL mellé (Elastic). Az OpenSearch továbbra is tisztán Apache-2.0.

A gyakorlati következmény a funkciólistában van, nem csak a licencszövegben. A fent tárgyalt Elasticsearch-vektorfunkciók közül több, köztük a DiskBBQ és a GPU-s indexelés, Enterprise előfizetést igényel, míg a megfelelő OpenSearch-funkciók az Apache-2.0 disztribúció részei. A felhőszolgáltatók menedzselt ajánlatai saját feltételeket is hoznak, ezért azt a funkciót hasonlítsa össze, amelyre ténylegesen szüksége van, abban a kiadásban, amelyet ténylegesen futtatna.

Mikor rossz vektortár az Elasticsearch vagy az OpenSearch

A dedikált vektortár akkor nyer, ha a vektorok a fő terhelést jelentik, nem a szöveges keresés kiegészítését, ha az index túl nagy ahhoz, hogy elfogadható áron a page cache-ben tartsa, vagy ha bérlőnkénti névterekre, nagyon nagy írási sebességre vagy olyan vektornatív funkciókra van szükség, amelyeket a keresőmotorok nem kínálnak. Akkor is nyer, ha a csapatban senki sem akar JVM-alapú keresőfürtöt üzemeltetni. Ilyenkor induljon a dedikált lehetőségekből, például a pgvector vagy a fenti összehasonlító cikkek felől.

A későbbi váltás nem drága, ha előre tervez vele. Minden vektor mellett tárolja a beágyazó modellt, annak verzióját és a beágyazott szöveget, és a dokumentumokat egyetlen indexelő szolgáltatáson keresztül írja, ne több helyről. Így a vektortár cseréje, vagy egy dedikált tár hozzáadása egyetlen terheléshez, csupán a betöltés újrafuttatását jelenti egy új célra, nem a teljes folyamat újraépítését.

Gyakorlati ellenőrzőlista

1. Becsülje meg a vektormemóriát a dimenziószám és a kvantálási szint alapján, és vesse össze a csomópontok page cache-ével.
2. A szűrőket a kNN-záradékba tegye, ne mellé.
3. Kezdjen a verzió alapértelmezett kvantálásával, és hagyja bekapcsolva az újrapontozást.
4. Először RRF-fel fésülje össze a BM25-öt és a vektorokat, aztán tesztelje a pontszám-normalizálást.
5. Mérje a recallt k mellett egy mintán, pontos kNN-t használva viszonyítási alapként.
6. Tervezés előtt ellenőrizze, mely funkciókhoz kell fizetős előfizetés.
7. Minden kisebb verziófrissítés után teszteljen újra, mert az alapértékek verziónként változnak.

Ha egy már működő keresőfürtöt bővítene vektoros kereséssel, mért és nem feltételezett recall mellett, nézze meg a MI-mérnöki munkámat.

Források

1. Elastic docs: kNN search
2. Elastic docs: filtered kNN search
3. Elastic docs: dense_vector field type
4. Elastic docs: BBQ
5. Elastic docs: reciprocal rank fusion
6. Elastic docs: GPU vector indexing
7. Elastic blog: Elasticsearch is open source again (Aug 2024)
8. OpenSearch docs: methods and engines
9. OpenSearch docs: memory-optimized vectors
10. OpenSearch docs: reciprocal rank fusion
11. OpenSearch docs: version history
12. AWS Open Source blog: introducing OpenSearch (Apr 2021)