[{"data":1,"prerenderedAt":776},["ShallowReactive",2],{"blog-elasticsearch-opensearch-vector-search-hu":3},{"slug":4,"published":5,"updated":6,"minutes":7,"category":8,"tags":9,"keywords":15,"about":26,"sources":34,"cover":71,"og":72,"expertise":73,"locales":74,"lang":77,"title":78,"description":79,"coverAlt":80,"metaTitle":81,"takeaways":82,"faq":88,"toc":104,"blocks":132,"others":521},"elasticsearch-opensearch-vector-search","2026-09-30","2026-10-01",8,"rag",[10,11,12,13,14],"Elasticsearch","OpenSearch","Vector search","Hybrid search","Licensing",[16,17,18,19,20,21,22,23,24,25],"vector search in Elasticsearch and OpenSearch","elasticsearch knn vector search","opensearch neural search","hybrid search rrf","elasticsearch bbq better binary quantization","opensearch diskann jvector","elasticsearch agpl license","filtered knn search","elasticsearch vs opensearch vector database","search engine as vector store",[27,29,31],{"name":10,"url":28},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FElasticsearch",{"name":11,"url":30},"https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FOpenSearch_%28software%29",{"name":32,"url":33},"Nearest neighbor search","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FNearest_neighbor_search",[35,38,41,44,47,50,53,56,59,62,65,68],{"title":36,"url":37},"Elastic docs: kNN search","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Fsolutions\u002Fsearch\u002Fvector\u002Fknn",{"title":39,"url":40},"Elastic docs: filtered kNN search","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Fsolutions\u002Fsearch\u002Fvector\u002Fknn\u002Ffiltered-knn-search",{"title":42,"url":43},"Elastic docs: dense_vector field type","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Freference\u002Felasticsearch\u002Fmapping-reference\u002Fdense-vector",{"title":45,"url":46},"Elastic docs: BBQ","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Freference\u002Felasticsearch\u002Fmapping-reference\u002Fbbq",{"title":48,"url":49},"Elastic docs: reciprocal rank fusion","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Freference\u002Felasticsearch\u002Frest-apis\u002Freciprocal-rank-fusion",{"title":51,"url":52},"Elastic docs: GPU vector indexing","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Fsolutions\u002Fsearch\u002Fvector\u002Fgpu-vector-indexing",{"title":54,"url":55},"Elastic blog: Elasticsearch is open source again (Aug 2024)","https:\u002F\u002Fwww.elastic.co\u002Fblog\u002Felasticsearch-is-open-source-again",{"title":57,"url":58},"OpenSearch docs: methods and engines","https:\u002F\u002Fdocs.opensearch.org\u002Flatest\u002Fmappings\u002Fsupported-field-types\u002Fknn-methods-engines\u002F",{"title":60,"url":61},"OpenSearch docs: memory-optimized vectors","https:\u002F\u002Fdocs.opensearch.org\u002Flatest\u002Fmappings\u002Fsupported-field-types\u002Fknn-memory-optimized\u002F",{"title":63,"url":64},"OpenSearch docs: reciprocal rank fusion","https:\u002F\u002Fdocs.opensearch.org\u002Flatest\u002Fvector-search\u002Fai-search\u002Fhybrid-search\u002Frrf\u002F",{"title":66,"url":67},"OpenSearch docs: version history","https:\u002F\u002Fdocs.opensearch.org\u002Flatest\u002Fversion-history\u002F",{"title":69,"url":70},"AWS Open Source blog: introducing OpenSearch (Apr 2021)","https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fopensource\u002Fintroducing-opensearch\u002F","\u002Fimages\u002Fblog\u002Felasticsearch-opensearch-vector-search\u002Fcover.webp","\u002Fimages\u002Fblog\u002Felasticsearch-opensearch-vector-search\u002Fog.jpg","ai-engineer",[75,76,77],"en","de","hu","Vektoros keresés Elasticsearchben és OpenSearchben: kNN, hibrid keresés és a licencek","Elasticsearch és OpenSearch vektortárként: kNN és szűrők, BBQ és bináris kvantálás, hibrid keresés RRF-fel, GPU-s indexépítés és a licenckérdés.","Szekrény egy szöveges és egy vektoros fiókkal, egyetlen nagyító keres bennük.","Vektoros keresés: Elasticsearch, OpenSearch · Balázs Csorba",[83,84,85,86,87],"Ha már üzemeltet Elasticsearch- vagy OpenSearch-fürtöt termék- vagy oldalkereséshez, a beépített kNN általában az első kipróbálandó vektortár, mert a hibrid keresés és a szűrők vele járnak.","Az Elasticsearchben a kNN-záradékon belüli szűrő a gráfkeresés közben érvényesül, és k találatot ad; a mellette álló szűrő utána fut, és kevesebbet is adhat.","A kvantálás dönti el a memóriaszámlát: az Elasticsearch a 9.1 óta 384 vagy több dimenziónál alapból BBQ-t használ, az OpenSearch 32-szeres lemezes tömörítést és 1, 2 vagy 4 bites bináris kvantálást kínál.","Mindkét motor RRF-fel fésüli össze a BM25- és vektoros találatokat; az OpenSearch saját BEIR-tesztje szerint az RRF átlagosan 3,86 százalékkal marad el a pontszámalapú normalizálástól.","A licencek eltérnek: az OpenSearch Apache-2.0, az Elasticsearch 2024 augusztusa óta AGPL, SSPL vagy ELv2 alatt érhető el, és több vektoros funkcióhoz, például a DiskBBQ-hoz és a GPU-s indexeléshez Elastic Enterprise előfizetés kell.",[89,92,95,98,101],{"q":90,"a":91},"Használható az Elasticsearch vektoradatbázisként?","Igen. A dense_vector mező alapból HNSW-alapú közelítő kNN-t támogat, kis jelölthalmazokra pontos kNN-t, keresés közbeni szűrést, kvantálást és BM25-tel kombinált hibrid keresést RRF-fel. Sok csapatnál, amely már üzemeltet Elasticsearchöt, ez fölöslegessé teszi a külön vektoradatbázist.",{"q":93,"a":94},"Mi a különbség az Elasticsearch és az OpenSearch között vektoros keresésben?","Az OpenSearch az Elasticsearch 7.10.2 Apache-2.0 licencű forkja 2021-ből. Mindkettő kínál HNSW-alapú kNN-t, kvantálást és RRF-et, de a részletek eltérnek: az Elasticsearchben BBQ és DiskBBQ van, az OpenSearchben több motor, köztük a Lucene, a Faiss és a DiskANN-szerű JVector, valamint lemezes tömörítési módok.",{"q":96,"a":97},"Mi a BBQ az Elasticsearchben?","A Better Binary Quantization az Elasticsearch 8.16-tal jelent meg 2024 szeptemberében; minden vektordimenziót egyetlen bitre tömörít, akár 32-szeres tömörítéssel, a nyers vektorok pedig az újrapontozáshoz a lemezen maradnak. A 9.1 óta ez az alapértelmezett indextípus a 384 vagy több dimenziós vektoroknál.",{"q":99,"a":100},"Újra nyílt forráskódú az Elasticsearch?","2024 augusztusa óta az Elastic harmadik licencopcióként az AGPL v3-at is kínálja az SSPL és az Elastic License 2.0 mellett. Az OpenSearch továbbra is Apache-2.0 alatt érhető el. Hogy melyik illik Önhöz, az attól függ, hogyan terjeszti vagy hosztolja a termékét, ezért egyeztessen a cégnél a licencekért felelős kollégákkal.",{"q":102,"a":103},"Mikor jobb egy külön vektoradatbázis az Elasticsearchnél vagy az OpenSearchnél?","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 megfizethetően a page cache-ben tartsa, vagy ha nagyon nagy léptékben kellenek olyan funkciók, mint a több bérlős névterek. Ilyenkor egy dedikált tár, például a Qdrant, a Milvus vagy egy menedzselt szolgáltatás egyszerűbb és olcsóbb lehet.",[105,108,111,114,117,120,123,126,129],{"id":106,"title":107},"do-you-need-a-vector-database","Kell vektoradatbázis, ha már fut keresőfürt?",{"id":109,"title":110},"how-knn-works","Hogyan működik a kNN és a szűrés a két motorban",{"id":112,"title":113},"quantization-and-memory","A kvantálásnál dől el a memória",{"id":115,"title":116},"hybrid-search-with-rrf","Hibrid keresés RRF-fel",{"id":118,"title":119},"gpu-and-ingestion","GPU-s indexépítés és betöltés",{"id":121,"title":122},"licensing","A licenctörténet, és mit jelent Önnek",{"id":124,"title":125},"when-not-to-use","Mikor rossz vektortár az Elasticsearch vagy az OpenSearch",{"id":127,"title":128},"checklist","Gyakorlati ellenőrzőlista",{"id":130,"title":131},"sources","Források",[133,151,165,168,177,185,188,189,215,221,231,237,238,266,270,297,300,303,304,330,332,343,346,347,365,375,378,379,389,435,438,445,446,454,457,458,475,482,483],{"type":134,"content":135},"paragraph",[136,137,141,142,146,147,150],"A ",{"tag":138,"children":139},"strong",[140],"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 ",{"tag":143,"children":144},"code",[145],"dense_vector"," vagy ",{"tag":143,"children":148},[149],"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.",{"type":134,"content":152},[153,154,159,160,164],"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 ",{"tag":155,"to":156,"children":157},"link","\u002Fblog\u002Fpgvector-vs-vector-databases",[158],"pgvector és a vektoradatbázisok"," és a ",{"tag":155,"to":161,"children":162},"\u002Fblog\u002Fmilvus-zilliz",[163],"Milvus és Zilliz ismertető"," veti össze. A verziók 2026 októberi állapotot tükröznek: Elasticsearch 9.5 és OpenSearch 3.9.",{"type":166,"level":167,"id":106,"text":107},"heading",2,{"type":134,"content":169},[170,171,176],"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 (",{"tag":172,"href":173,"children":174},"a","https:\u002F\u002Fwww.elastic.co\u002Fdocs\u002Fsolutions\u002Fsearch\u002Fvector\u002Fknn\u002Fapproximate-knn",[175],"Elastic","). Ez az egy feltétel határozza meg a lenti döntések többségét.",{"type":134,"content":178},[179,180,184],"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 ",{"tag":155,"to":181,"children":182},"\u002Fblog\u002Fsemantic-product-search-b2b",[183],"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.",{"type":134,"content":186},[187],"Ü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.",{"type":166,"level":167,"id":109,"text":110},{"type":134,"content":190},[191,192,195,196,198,199,201,202,204,205,207,208,211,212,214],"Az Elasticsearch három belépési pontot kínál a közelítő kNN-hez: a legfelső szintű ",{"tag":143,"children":193},[194],"knn"," opciót, egy ",{"tag":143,"children":197},[194]," lekérdezést és egy ",{"tag":143,"children":200},[194]," retrievert, kis jelölthalmazokra pedig pontos, nyers erős kNN-t; a ",{"tag":143,"children":203},[145]," mezőkön a közelítő keresés alapból be van kapcsolva (",{"tag":172,"href":37,"children":206},[175],"). 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 ",{"tag":143,"children":209},[210],"bool"," lekérdezésben a kNN-záradék mellé tett szűrő utána fut, és k-nál kevesebbet is adhat (",{"tag":172,"href":40,"children":213},[175],").",{"type":216,"src":217,"alt":218,"wide":219,"caption":220},"image","\u002Fimages\u002Fblog\u002Felasticsearch-opensearch-vector-search\u002Fdiagram-8.webp","Lekérdezési utak az Elasticsearchben és az OpenSearchben Két sáv. Felső sáv, Elasticsearch: egy lekérdezés kNN-záradékkal és benne szűrővel; a szűrő a HNSW-gráf bejárása közben érvényesül; az eredmény k illeszkedő dokumentum, amelyet egy RRF retriever fésül össze egy BM25 retrieverrel. Alsó sáv, OpenSearch: egy hibrid lekérdezés BM25 és knn_vector résszel; mindkettő lefut; egy keresési pipeline normalizálja a pontszámokat vagy a score-ranker RRF processzort alkalmazza; az összefésült lista tér vissza.",true,"Az Elasticsearch a gráfbejárás közben szűr, és retrieverekkel fésül össze; az OpenSearch a hibrid lekérdezés mindkét felét lefuttatja, és egy keresési pipeline-ban fésüli össze őket.",{"type":134,"content":222},[223,224,227,228,230],"A második szabályozó a ",{"tag":143,"children":225},[226],"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 ",{"tag":143,"children":229},[226]," értékét pedig emelje ennek két-négyszeresére, miközben egy mintán pontos kNN-hez méri a recallt.",{"type":134,"content":232},[233,234,236],"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 (",{"tag":172,"href":58,"children":235},[11],"). 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.",{"type":166,"level":167,"id":112,"text":113},{"type":134,"content":239},[240,241,244,245,248,249,251,252,255,256,258,259,262,263,214],"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 ",{"tag":143,"children":242},[243],"int8_hnsw"," volt; a 9.1-től 384 vagy több dimenziójú vektoroknál ",{"tag":143,"children":246},[247],"bbq_hnsw",", egyébként ",{"tag":143,"children":250},[243],"; a 9.4-től pedig ",{"tag":143,"children":253},[254],"bbq_disk",", ha a licenc engedi (",{"tag":172,"href":43,"children":257},[175],"). A BBQ a 8.16-tal jelent meg 2024 szeptemberében, akár 32-szeres tömörítéssel (",{"tag":172,"href":260,"children":261},"https:\u002F\u002Fwww.elastic.co\u002Fblog\u002Fwhats-new-elastic-search-8-16-0",[175],"), 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 (",{"tag":172,"href":46,"children":264},[265],"BBQ",{"type":216,"src":267,"alt":268,"wide":219,"caption":269},"\u002Fimages\u002Fblog\u002Felasticsearch-opensearch-vector-search\u002Fdiagram-13.webp","Memória vektoronként kvantálási szint szerint Négy szint balról jobbra: nyers float32 vektorok teljes méretben; int8 skalár kvantálás nagyjából negyed méretben, az Elasticsearch 9.0 alapértéke; int4 nagyjából nyolcad méretben; és dimenziónként egy bit BBQ-val vagy bináris kvantálással, akár 32-szer kisebben, ami a 9.1 óta az Elasticsearch alapértéke 384 vagy több dimenziónál, és az OpenSearch lemezes módjának alapértéke float vektoroknál.","Minden lépés memóriát cserél recallra, amelyet a lemezen tárolt nyers vektorokkal végzett újrapontozás visszanyer.",{"type":134,"content":271},[272,273,275,276,278,279,282,283,286,287,290,291,293,294,214],"A DiskBBQ, vagyis a ",{"tag":143,"children":274},[254]," 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 (",{"tag":172,"href":46,"children":277},[265],"). Az OpenSearch más úton ér el hasonló arányokat: a memóriaoptimalizált vektorok ",{"tag":143,"children":280},[281],"in_memory"," módban alapból 1-szeres, ",{"tag":143,"children":284},[285],"on_disk"," módban ",{"tag":143,"children":288},[289],"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 (",{"tag":172,"href":61,"children":292},[11],"), 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 (",{"tag":172,"href":295,"children":296},"https:\u002F\u002Fdocs.opensearch.org\u002Flatest\u002Fvector-search\u002Foptimizing-storage\u002Fbinary-quantization\u002F",[11],{"type":134,"content":298},[299],"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.",{"type":134,"content":301},[302],"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.",{"type":166,"level":167,"id":115,"text":116},{"type":134,"content":305},[306,307,310,311,314,315,318,319,322,323,326,327,329],"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 ",{"tag":143,"children":308},[309],"rrf"," retrieverhez legalább két gyermek retriever kell, a ",{"tag":143,"children":312},[313],"rank_constant"," alapértéke 60, és nem támogatja a ",{"tag":143,"children":316},[317],"sort",", ",{"tag":143,"children":320},[321],"scroll"," és ",{"tag":143,"children":324},[325],"rescore"," funkciókat (",{"tag":172,"href":49,"children":328},[175],"). 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.",{"type":143,"code":331},"PUT products\n{\n  \"mappings\": {\n    \"properties\": {\n      \"title\":     { \"type\": \"text\" },\n      \"brand\":     { \"type\": \"keyword\" },\n      \"embedding\": { \"type\": \"dense_vector\", \"dims\": 1024, \"similarity\": \"cosine\",\n                     \"index_options\": { \"type\": \"bbq_hnsw\" } }\n    }\n  }\n}\n\nGET products\u002F_search\n{\n  \"retriever\": {\n    \"rrf\": {\n      \"retrievers\": [\n        { \"standard\": { \"query\": { \"match\": { \"title\": \"Kugelhahn DN50 Edelstahl\" } } } },\n        { \"knn\": { \"field\": \"embedding\", \"query_vector\": [\u002F* 1024 floats *\u002F], \"k\": 50,\n                   \"num_candidates\": 200,\n                   \"filter\": { \"term\": { \"brand\": \"acme\" } } } }\n      ],\n      \"rank_constant\": 60\n    }\n  }\n}",{"type":134,"content":333},[334,335,337,338,342],"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 (",{"tag":172,"href":64,"children":336},[11],"). 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 ",{"tag":155,"to":339,"children":340},"\u002Fblog\u002Freranking-models-compared",[341],"cross-encoder rerankerek összehasonlítva",".",{"type":134,"content":344},[345],"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.",{"type":166,"level":167,"id":118,"text":119},{"type":134,"content":348},[349,350,352,353,322,356,358,359,361,362,214],"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 ",{"tag":143,"children":351},[289]," elemű ",{"tag":143,"children":354},[355],"hnsw",{"tag":143,"children":357},[243]," indexekhez működik (",{"tag":172,"href":52,"children":360},[175],"). 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 (",{"tag":172,"href":363,"children":364},"https:\u002F\u002Fopensearch.org\u002Fblog\u002Fgpu-accelerated-vector-search-opensearch-new-frontier\u002F",[11],{"type":134,"content":366},[367,368,371,372,374],"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 ",{"tag":143,"children":369},[370],"half_float"," vektortípust, valamint a 2 és 4 bites skalár kvantálást (",{"tag":172,"href":67,"children":373},[11],"). A lebegőpontos szélesség felezése indexelés előtt gyakran a legolcsóbb elérhető memórianyereség.",{"type":134,"content":376},[377],"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.",{"type":166,"level":167,"id":121,"text":122},{"type":134,"content":380},[381,382,385,386,388],"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 (",{"tag":172,"href":70,"children":383},[384],"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é (",{"tag":172,"href":55,"children":387},[175],"). Az OpenSearch továbbra is tisztán Apache-2.0.",{"type":390,"head":391,"rows":402},"table",[392,394,396,398,400],[393],"Helyzet",[395],"Vektoros beállítás",[397],"Hibrid összefésülés",[399],"GPU-s építés",[401],"Licenckockázat",[403,414,425],[404,406,408,410,412],[405],"Már Elasticsearch fut",[407],"dense_vector, alapból bbq_hnsw",[409],"rrf retriever",[411],"csak Enterprise",[413],"AGPL, SSPL vagy ELv2; a DiskBBQ-hoz Enterprise kell",[415,417,419,421,423],[416],"Már OpenSearch fut",[418],"knn_vector, Lucene vagy Faiss",[420],"normalizálás vagy score-ranker",[422],"3.1 óta elérhető",[424],"Apache-2.0",[426,428,430,432,433],[427],"Új projekt, a vektor a fő terhelés",[429],"dedikált tár mérlegelése",[431],"tártól függ",[431],[434],"tárként ellenőrizendő",{"type":134,"content":436},[437],"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.",{"type":439,"variant":440,"title":441,"body":442},"callout","note","A licenc termékdöntés",[443],[444],"Egy keresőfürtöt a saját alkalmazás mögött futtatni más, mint szolgáltatásként kínálni vagy egy termékbe építve szállítani. Az AGPL, az SSPL, az ELv2 és az Apache-2.0 közötti különbségek épp ezekben az esetekben számítanak, ezért mielőtt fizetős funkciókra építene, tisztázza a kérdést a licencekért felelős kollégákkal.",{"type":166,"level":167,"id":124,"text":125},{"type":134,"content":447},[448,449,453],"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 ",{"tag":155,"to":450,"children":451},"\u002Fblog\u002Fpgvector",[452],"pgvector"," vagy a fenti összehasonlító cikkek felől.",{"type":134,"content":455},[456],"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.",{"type":166,"level":167,"id":127,"text":128},{"type":459,"ordered":219,"items":460},"list",[461,463,465,467,469,471,473],[462],"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.",[464],"A szűrőket a kNN-záradékba tegye, ne mellé.",[466],"Kezdjen a verzió alapértelmezett kvantálásával, és hagyja bekapcsolva az újrapontozást.",[468],"Először RRF-fel fésülje össze a BM25-öt és a vektorokat, aztán tesztelje a pontszám-normalizálást.",[470],"Mérje a recallt k mellett egy mintán, pontos kNN-t használva viszonyítási alapként.",[472],"Tervezés előtt ellenőrizze, mely funkciókhoz kell fizetős előfizetés.",[474],"Minden kisebb verziófrissítés után teszteljen újra, mert az alapértékek verziónként változnak.",{"type":134,"content":476},[477,478,342],"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 ",{"tag":155,"to":479,"children":480},"\u002Fexpertise\u002Fai-engineer",[481],"MI-mérnöki munkámat",{"type":166,"level":167,"id":130,"text":131},{"type":459,"ordered":219,"items":484},[485,488,491,494,497,500,503,506,509,512,515,518],[486],{"tag":172,"href":37,"children":487},[36],[489],{"tag":172,"href":40,"children":490},[39],[492],{"tag":172,"href":43,"children":493},[42],[495],{"tag":172,"href":46,"children":496},[45],[498],{"tag":172,"href":49,"children":499},[48],[501],{"tag":172,"href":52,"children":502},[51],[504],{"tag":172,"href":55,"children":505},[54],[507],{"tag":172,"href":58,"children":508},[57],[510],{"tag":172,"href":61,"children":511},[60],[513],{"tag":172,"href":64,"children":514},[63],[516],{"tag":172,"href":67,"children":517},[66],[519],{"tag":172,"href":70,"children":520},[69],[522,597,657,715],{"slug":523,"published":524,"minutes":525,"category":8,"tags":526,"keywords":531,"about":544,"sources":554,"cover":591,"og":592,"expertise":73,"locales":593,"lang":77,"title":594,"description":595,"coverAlt":596},"embedding-model-selection-2026","2026-10-17",9,[527,528,529,12,530],"Embeddings","RAG","MTEB","Model selection",[532,533,534,535,536,537,538,539,540,541,542,543],"best embedding model 2026","how to choose an embedding model","embedding model comparison","MTEB leaderboard explained","RTEB benchmark","open source embedding model","multilingual embedding model","voyage-4 vs openai embeddings","Qwen3-Embedding","EmbeddingGemma","embedding model for RAG","switching embedding models re-embed",[545,548,551],{"name":546,"url":547},"Word embedding","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FWord_embedding",{"name":549,"url":550},"Information retrieval","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FInformation_retrieval",{"name":552,"url":553},"Discounted cumulative gain","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDiscounted_cumulative_gain",[555,558,561,564,567,570,573,576,579,582,585,588],{"title":556,"url":557},"Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2502.13595",{"title":559,"url":560},"Hugging Face: Introducing RTEB, a new standard for retrieval evaluation (Oct 2025)","https:\u002F\u002Fhuggingface.co\u002Fblog\u002Frteb",{"title":562,"url":563},"OpenAI: Vector embeddings guide","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fembeddings",{"title":565,"url":566},"OpenAI: API pricing","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing",{"title":568,"url":569},"Voyage AI: The Voyage 4 model family, shared embedding space with MoE architecture (Jan 2026)","https:\u002F\u002Fblog.voyageai.com\u002F2026\u002F01\u002F15\u002Fvoyage-4\u002F",{"title":571,"url":572},"Voyage AI: Text embeddings documentation","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fembeddings",{"title":574,"url":575},"Voyage AI: Pricing","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fpricing",{"title":577,"url":578},"Google: Gemini API embeddings documentation","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fembeddings",{"title":580,"url":581},"Google: Gemini API pricing","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fpricing",{"title":583,"url":584},"Cohere: Embed models documentation","https:\u002F\u002Fdocs.cohere.com\u002Fdocs\u002Fcohere-embed",{"title":586,"url":587},"Qwen: Qwen3-Embedding-8B model card","https:\u002F\u002Fhuggingface.co\u002FQwen\u002FQwen3-Embedding-8B",{"title":589,"url":590},"Google Developers Blog: Introducing EmbeddingGemma (Sep 2025)","https:\u002F\u002Fdevelopers.googleblog.com\u002Fen\u002Fintroducing-embeddinggemma\u002F","\u002Fimages\u002Fblog\u002Fembedding-model-selection-2026\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fembedding-model-selection-2026\u002Fog.jpg",[75,76,77],"Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon","Hogyan válassz embedding-modellt RAG-hoz 2026-ban: mit mond az MTEB és az RTEB, API vagy nyílt súlyok, árak, dimenziók és egy egyhetes összehasonlító teszt.","Három oszlop egymásra rakott kockákból, középen a legmagasabb, mindegyik rövid sávval mérve.",{"slug":598,"published":524,"minutes":599,"category":8,"tags":600,"keywords":604,"about":616,"sources":626,"cover":651,"og":652,"expertise":73,"locales":653,"lang":77,"title":654,"description":655,"coverAlt":656},"contextual-retrieval-late-chunking",10,[528,601,527,602,603],"Chunking","Contextual retrieval","Late chunking",[605,606,607,608,609,610,611,612,613,614,615],"contextual retrieval","anthropic contextual retrieval","late chunking","contextual chunk embeddings","contextual embeddings rag","contextual bm25","chunk context rag","voyage-context-3","voyage-context-4","late chunking vs contextual retrieval","rag chunking context loss",[617,620,623],{"name":618,"url":619},"Retrieval-augmented generation","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FRetrieval-augmented_generation",{"name":621,"url":622},"Okapi BM25","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FOkapi_BM25",{"name":624,"url":625},"Sentence embedding","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSentence_embedding",[627,630,633,636,639,642,645,648],{"title":628,"url":629},"Anthropic: Introducing Contextual Retrieval (Sep 2024)","https:\u002F\u002Fwww.anthropic.com\u002Fnews\u002Fcontextual-retrieval",{"title":631,"url":632},"Günther et al.: Late Chunking, Contextual Chunk Embeddings Using Long-Context Embedding Models (2024, rev. 2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2409.04701",{"title":634,"url":635},"Jina AI: Late Chunking in Long-Context Embedding Models (Aug 2024)","https:\u002F\u002Fjina.ai\u002Fnews\u002Flate-chunking-in-long-context-embedding-models\u002F",{"title":637,"url":638},"Voyage AI: Introducing voyage-context-3 (Jul 2025)","https:\u002F\u002Fblog.voyageai.com\u002F2025\u002F07\u002F23\u002Fvoyage-context-3\u002F",{"title":640,"url":641},"Voyage AI: voyage-context-4 (Jun 2026)","https:\u002F\u002Fblog.voyageai.com\u002F2026\u002F06\u002F29\u002Fvoyage-context-4\u002F",{"title":643,"url":644},"Voyage AI: Contextualized chunk embeddings documentation","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fcontextualized-chunk-embeddings",{"title":646,"url":647},"Anthropic: Claude API pricing","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fabout-claude\u002Fpricing",{"title":649,"url":650},"Qu, Tu and Bao: Is Semantic Chunking Worth the Computational Cost? (2024)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2410.13070","\u002Fimages\u002Fblog\u002Fcontextual-retrieval-late-chunking\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fcontextual-retrieval-late-chunking\u002Fog.jpg",[75,76,77],"Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat","A chunkok elveszítik a dokumentumukat. Hogyan javít ezen a contextual retrieval, a late chunking és a kontextusos embedding, mennyibe kerül, és mikor hagyd ki.","Négy szabad négyzet, alul széles kapocs fogja össze, mindegyik felfelé egy nagy laphoz kapcsolódik.",{"slug":658,"published":524,"minutes":525,"category":8,"tags":659,"keywords":663,"about":676,"sources":684,"cover":709,"og":710,"expertise":73,"locales":711,"lang":77,"title":712,"description":713,"coverAlt":714},"rag-access-control-permissions",[528,660,661,662,12],"Access control","Security","Multi-tenancy",[664,665,666,667,668,669,670,671,672,673,674,675],"rag access control","permission aware rag","document level security rag","rag multi tenancy","vector database access control","pgvector row level security","security trimming azure ai search","openfga rag authorization","qdrant multitenancy","pinecone namespaces multitenancy","owasp llm08 vector and embedding weaknesses","rag data leakage",[677,680,683],{"name":678,"url":679},"Access-control list","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FAccess-control_list",{"name":681,"url":682},"Multitenancy","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FMultitenancy",{"name":618,"url":619},[685,688,691,694,697,700,703,706],{"title":686,"url":687},"OWASP GenAI Security Project: LLM08:2025 Vector and Embedding Weaknesses","https:\u002F\u002Fgenai.owasp.org\u002Fllmrisk\u002Fllm082025-vector-and-embedding-weaknesses\u002F",{"title":689,"url":690},"PostgreSQL documentation: Row Security Policies","https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fddl-rowsecurity.html",{"title":692,"url":693},"pgvector README: filtering and iterative index scans","https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector",{"title":695,"url":696},"Qdrant: Multitenancy and partitions guide","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fguides\u002Fmultiple-partitions\u002F",{"title":698,"url":699},"Pinecone: Implement multitenancy using namespaces","https:\u002F\u002Fdocs.pinecone.io\u002Fguides\u002Findex-data\u002Fimplement-multitenancy",{"title":701,"url":702},"Microsoft Learn: Document-level access control in Azure AI Search","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fsearch\u002Fsearch-document-level-access-overview",{"title":704,"url":705},"OpenFGA: RAG authorization use case","https:\u002F\u002Fopenfga.dev\u002Fdocs\u002Fuse-cases\u002Frag-authorization",{"title":707,"url":708},"Morris et al.: Text Embeddings Reveal (Almost) As Much As Text (EMNLP 2023)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2310.06816","\u002Fimages\u002Fblog\u002Frag-access-control-permissions\u002Fcover.webp","\u002Fimages\u002Fblog\u002Frag-access-control-permissions\u002Fog.jpg",[75,76,77],"Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül","Hogyan szivárogtatnak dokumentumot a RAG-asszisztensek, és hogyan állítsd meg: ACL minden chunkon, előszűrés, sorszintű biztonság pgvectorban, jogszinkron.","Hét kártya sorban, haton lakat jelvény, a csupasz kártya nyilat küld kifelé.",{"slug":716,"published":524,"minutes":599,"category":8,"tags":717,"keywords":722,"about":734,"sources":742,"cover":769,"og":770,"expertise":771,"locales":772,"lang":77,"title":773,"description":774,"coverAlt":775},"rag-product-catalog-pim-data",[528,718,719,720,721],"PIM","Product data","B2B e-commerce","Metadata filtering",[723,724,725,726,727,728,729,730,731,732,733],"rag product catalog","rag pim data","llm product data","product catalog chatbot","akeneo rag","pimcore ai search","rag structured data","metadata filtering rag","product attributes embeddings","b2b product assistant","etim classification ai",[735,738,739],{"name":736,"url":737},"Product information management","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FProduct_information_management",{"name":618,"url":619},{"name":740,"url":741},"ETIM (standard)","https:\u002F\u002Fwww.etim-international.com\u002Fclassification\u002F",[743,746,749,752,754,757,760,763,766],{"title":744,"url":745},"Akeneo API: Products, product values, metric values and product models","https:\u002F\u002Fapi.akeneo.com\u002Fconcepts\u002Fproducts.html",{"title":747,"url":748},"Akeneo Help Center: What about products with variants?","https:\u002F\u002Fhelp.akeneo.com\u002Fserenity-take-the-power-over-your-products\u002Fserenity-what-about-products-with-variants",{"title":750,"url":751},"Pimcore documentation: Classification Store","https:\u002F\u002Fdocs.pimcore.com\u002Fplatform\u002FPimcore\u002FObjects\u002FObject_Classes\u002FData_Types\u002FClassification_Store\u002F",{"title":753,"url":741},"ETIM International: Classification",{"title":755,"url":756},"ETIM International: ETIM releases and the IXF format","https:\u002F\u002Fetim-international.com\u002F?p=754",{"title":758,"url":759},"Reddy et al.: Shopping Queries Dataset, a large-scale ESCI benchmark for improving product search (2022)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2206.06588",{"title":761,"url":762},"Amazon Science: esci-data repository","https:\u002F\u002Fgithub.com\u002Famazon-science\u002Fesci-data",{"title":764,"url":765},"Qdrant documentation: Filtering","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fconcepts\u002Ffiltering\u002F",{"title":767,"url":768},"Sui et al.: Table Meets LLM, can large language models understand structured table data? (WSDM 2024)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2305.13062","\u002Fimages\u002Fblog\u002Frag-product-catalog-pim-data\u002Fcover.webp","\u002Fimages\u002Fblog\u002Frag-product-catalog-pim-data\u002Fog.jpg","b2b-ecommerce-developer",[75,76,77],"RAG termékkatalógusra: PIM-adatokból megbízható válaszok","A termékadat strukturált, ezért a PDF-szerű chunkolás itt elbukik. Hogyan sorosítsd a PIM-attribútumokat, és hogyan küldd a specifikációs kérdéseket szűrőkhöz.","Kilenc négyzetből álló keret apró jelekkel, alatta tölcsér egyetlen kártyához.",1792342717023]