> Qdrant értékelés: szűrhető HNSW, négy kvantálási mód, a memória-szintek az 1.19-ben és az üzemeltetés, amit már senki nem publikál.
>
> Web page: https://balazscsorba.com/hu/blog/qdrant · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/qdrant.md) · [Deutsch](https://balazscsorba.com/de/blog/qdrant.md)
> Author: Balázs Csorba · Published: 2026-05-26 · Keywords: qdrant, qdrant vs pinecone, vector database comparison, hnsw index, filtered vector search, vector quantisation, hybrid search rrf, rag vector store

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

# Qdrant: egy szűrés körül felépített vektordatabázis

Qdrant értékelés: szűrhető HNSW, négy kvantálási mód, a memória-szintek az 1.19-ben és az üzemeltetés, amit már senki nem publikál.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. május 26.·10 perc olvasás

-   Vector search
-   HNSW
-   Quantisation
-   Hybrid search
-   Filtering

![Széles tölcsér kis négyzetek sorával a nyílásán, alatta három polc kevesebbel.](https://balazscsorba.com/images/blog/qdrant/cover.webp?v=745837a3a9)

## A lényeg röviden

-   Az aktuális kiadás 1.19.2, 2026. október 5.; a méretezés minden döntését meghatározó memória-szint paraméter az 1.19-ben érkezett.
-   A szűrés az értékajánlat: egy payload index vezeti a HNSW bejárását, de az indexnek az import előtt léteznie kell, különben a grafikont újra kell építeni.
-   A TurboQuant akár 32-szeres tömörítést ad, alapból aszimmetrikus, és a top-k-t újraértékeli teljes pontosságú vektorokkal, ami minden lekérdezésnél latencia-költség.
-   Egy saját gépen futó példány minden hálózati interfészre nyitva van, hitelesítés nélkül, amíg kézzel nem állít be API-kulcsot, TLS-t és hálózati kötést.
-   A gyártó benchmark oldala még 2024. januári és júniusi futásokat mutat, így az összehasonlító számai 2026-ban nem hordoznak vásárlási döntést.

Ezen az oldalon

1.  [Mi ez](https://balazscsorba.com/#what-it-is)
2.  [Hogyan fut le egy lekérdezés](https://balazscsorba.com/#how-it-works)
3.  [Első lépések](https://balazscsorba.com/#getting-started)
4.  [Memória és kvantálás](https://balazscsorba.com/#memory-and-quantisation)
5.  [Saját üzemeltetés és biztonság](https://balazscsorba.com/#self-hosting-and-security)
6.  [Hol gyengül](https://balazscsorba.com/#where-it-weakens)
7.  [Összegzés](https://balazscsorba.com/#verdict)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A Qdrant Rustban írt, Apache-2.0 alatt kiadott vektordatabázis, és egy olyan döntésre épül, amelyet a legtöbb versenytárs mellékesnek tekint: a metaadat-szűrő nem valami, amit a visszakeresés után alkalmazunk, hanem valami, amin az indexet bejárjuk. Ebből a nyílt forrású világ legmeggyőzőbb szűrt keresési története lesz, és valóban egyszerű üzemeltetési történet – egy konténer, egy REST- és gRPC-felület, hivatalos kliensek hat nyelven. Ennek a fókusznak az ára: a sűrű keresésnek pontosan egy index-implementációja van, az HNSW, a menedzselt szolgáltatás pedig fogyasztás alapján számol, nem publikált árral. Szűrésre nehezített visszakeresésre ajánlott, általános tárolóként kevésbé.

Ugyanabban a rétegben található, mint a pgvector, a Milvus, a Weaviate és a Pinecone, de az ajánlata más. A Weaviate egy integrált, AI-ra specializált tárolót ad beépített hibrid kereséssel és modulokkal; a Milvus vízszintes skálázást ígér a milliárdokig; a Pinecone nulla üzemeltetést. A Qdrant memóriahatékonyságot és szűrőátvitelt ad egyetlen csomóponton – ez szűkebb és könnyebben megtartott állítás.

## Mi ez

Az adatmodell szándékosan kicsi. Egy pont egy rekord egy vektorral és einem optional JSON payload-dal. Egy collection névvel ellátott ponthalmaz, amelynek tagjai azonos dimenziójúak és azonos távolsági metrikát használnak. A named vector lehetővé teszi, hogy egy pont több vektort hordozzon saját mérettel és metrikával – így fejeződik ki a hibrid keresés. A termék minden más része gépezet arra, hogy a következő szomszédot gyorsabban találja meg, teljes átvizsgálás nélkül.

-   Apache-2.0 licenc, Rust implementáció, egyetlen repository körülbelül 35.000 csillaggal és 7.100 committal.
-   Aktuális kiadás 1.19.2, 2026. október 5.; az 1.19 hozta a `memory` szinteket, amelyek meghatározzák, hol élnek a vektorok, az indexek és a payloadok.
-   A távolsági metrikák: dot product, cosine, euklideszi és manhattani; a cosine normalizált vektorokon végzett dot productként van implementálva, a normalizálás feltöltéskor történik.
-   A sűrű keresés kizárólag HNSW-t használ, `m` alapértéke 16, `ef_construct` értéke 100, mindkettő felülírható collection és named vector szinten.
-   A payload index típusai: keyword, integer, float, bool, geo, datetime, text és uuid, mindegyik az import előtt hozandó létre, hogy a szűrhető HNSW ki tudja használni.
-   A hibrid és többlépéses keresés az 1.10-ben érkezett a Query API-val: `prefetch` részlekérések RRF-fel vagy DBSF-fel összefésülve, a prefetch-ek egymásba ágyazhatók.
-   Hivatalos kliensek vannak Python, TypeScript, Rust, Go, Java és .NET nyelven, REST-en a 6333-on, gRPC-en a 6334-en.

## Hogyan fut le egy lekérdezés

Az érdekes mérnöki munka a query plannerben van, és három esetre bomlik. Egy olyan szűrő, amely alig enged át adatot, jobban jár egy teljes beolvasással, mint egy grafikonos bejárással. Egy olyan szűrő, amely szinte mindent átenged, használhatja a HNSW-t változtatás nélkül. A köztük lévő minden – ahol a bérlőszintű és nyelvenkénti visszakeresés él – az az eset, amelyet egy tiszta vektorindex utószűréssel rosszul kezel, és az, amire a szűrhető HNSW épült.

![Three paths a filtered query can take through Qdrant A query carrying a vector and a filter enters at the top and splits three ways. Left: the filter is strict and few points match, so the payload index is used for a full scan and the HNSW graph is skipped; the default full scan threshold is 10,000 kilobytes, where one kilobyte is one vector of size 256. Middle: the filter is weak and most points match, so the HNSW graph is used as it is and filtering happens afterwards. Right: the filter is in the middle, the case that matters in production, so the payload index feeds the HNSW walk, and the payload indexes have to exist before the data is ingested or the graph has to be rebuilt. A band below: with quantisation enabled the graph is walked over compressed vectors and the top candidates are rescored against the originals, with rescore and oversampling as per-query settings.](https://balazscsorba.com/images/blog/qdrant/diagram-7.webp?v=98b3960983)

A szűrő dönti el a végrehajtási utat, az alapértelmezett küszöbök pedig örökölt konfiguráció, nem választott beállítás.

Ebben a középső oszlopban van egy üzemeltetési részlet, amely több kiesést okoz, mint bármelyik lekérdezésfinomhangolás: a payload indexek csak akkor segítik a HNSW grafikont, ha az adatok előtt már léteztek. Ha egy tenant mezőt adunk egy meglévő collectionhöz, a grafikont újra kell építeni, hogy szűrés-tudatos legyen, ami nagy collectionönként órákban mérhető. A payload sémát az első upsert előtt kell megtervezni, nem az első incidens után.

## Első lépések

Egy konténer a 6333-on, hitelesítés nélkül elég az induláshoz, és ez egyben a legfontosabb dolog, amit a laptop elhagyása előtt javítani kell. Az alábbi konfiguráció egy bites TurboQuanttal létrehoz egy collectiont, az import előtt indexeli a tenant mezőt, és egy szűrt lekérdezést futtat a Query API-n át:

```
from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="chunks",
    vectors_config=models.VectorParams(size=1024, distance=models.Distance.COSINE),
    quantization_config=models.TurboQuantization(
        turbo=models.TurboQuantQuantizationConfig(bits=models.TurboQuantBitSize.BITS1),
    ),
)

# Before ingestion: the HNSW graph can only be filter-aware for
# fields that already have a payload index.
client.create_payload_index(
    collection_name="chunks",
    field_name="tenant",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

client.upsert(
    collection_name="chunks",
    points=[models.PointStruct(id=1, vector=[0.1] * 1024, payload={"tenant": "acme"})],
)

hits = client.query_points(
    collection_name="chunks",
    query=[0.1] * 1024,
    query_filter=models.Filter(
        must=[models.FieldCondition(key="tenant", match=models.MatchValue(value="acme"))],
    ),
    limit=10,
    search_params=models.SearchParams(quantization=models.QuantizationSearchParams(oversampling=2.0)),
).points
```

Két dolog érdemes ebből kiemelni. A kvantálás collection szintű beállítás, amely az indexeléskor lép életbe, és a tömörített vektorok az eredetiek mellett élnek, tehát az eredetiek megmaradnak egy újraértékeléshez. Az `oversampling` paraméter a kétszeres számú jelöltet kéri a kvantált indextől újraértékelés előtt. Ez az a kapcsoló, amit akkor kell elfordítani, ha a tömörített keresés olyan találatokat veszít, amelyeknek ott kellene lenniük.

**A kapacitás oldalt az első csomópont előtt olvassa el**

A gyártó saját méretezési szabályai rövidek ahhoz, hogy megjegyezhetők legyenek. A vektorok és a HNSW indexek alapértelmezés szerint `cached` szinten állnak, vagyis előtöltve, de kiszoríthatók; a `cold` a lemezre helyezi őket. A payloadok alapból `cold`, a payload indexek és a kvantált vektorok `pinned` szinten. A payload indexekre az indexelt mezők méretének kétszeresét, a payload tárolásra pedig további 1,5-szöröst vegyen rá.

## Memória és kvantálás

A kvantálás az egyetlen legnagyobb hatású lépés az éles beállítás előtt, és a Qdrant ma már négy módszert kínál valóban különböző kompromisszumokkal egyetlen bináris kapcsoló helyett. Az éles ellenőrzölista a három legfontosabb lépés mellett említi: a RAM őszinte becslése és a szűrt mezők indexelése.

Módszer

Tömörítés

Alapból újraértékel

Hol illik

Ár

TurboQuant

Akár 32-szeres, 4 bitől 1 bitig

Igen, 1, 1,5 és 2 bitnél

Az 1.18 óta alapértelmezett választás

Aszimmetrikus, a lekérdezések teljes pontosságúak maradnak

Skálás

4-szeres, float32-ból int8

Nem

A legkisebb kockázatú tömörítés

Kvantil kell a kiugró értékek levágásához

Bináris

Akár 32-szeres, 1–2 bit komponensenként

Igen

Nagy dimenziójú, középre húzott embeddingek

Elbukik olyan eloszlásokon, amikre nem tervezték

Produkt

Akár 64-szeres, 256 centroid szakaszonként

Nem

Ha csak a memória számít

A négy közül a legnagyobb pontosságvesztés

A módszeren túl az 1.19 memória-szint paramétert adott a kvantált másolathoz, és ez teszi a kvantálást RAM-csökkentésre használhatóvá, nem csupán gyorsító trükké. Ha az eredetiek a `cold` szinten vannak, a kvantált vektorok pedig a `pinned` szinten, a keresés csak a legjobb jelöltek újraértékelésekor nyúl a lemezhez. A `turbo4` adattípus, amely minden dimenziót a lemezen négy bitben tárol a lebegőpontos 32 bit helyett, tovább csökkenti a lemezoldalt recall árán. A HNSW index inline tárolása, amely 1.16 óta elérhető, tovább csökkenti az I/O-t, de csak akkor éri meg, ha a vektorok és az index a `cold` szinten van és a kvantálás be van kapcsolva; legfeljebb négy bit/dimenzió mellett érdemes használni, különben az index felfújódik.

**A kvantálás recall-döntés, nem tárolási döntés**

A dokumentáció kifejezetten mondja, hogy egyes embedding modelleket nem lehet hatékonyan kvantálni, az éles ellenőrzölista pedig újrabenchmarkolást kér utána, feltételezés helyett. A recall legyen számmal kifejezett átvételi kritérium, és maradjon lehetőség a kvantálás lekérdezésenkénti kikapcsolására: a `ignore` keresési paraméter pontosan ezt teszi, collection-újraépítés nélkül.

## Saját üzemeltetés és biztonság

A biztonsági dokumentáció azzal kezdődik, hogy a saját gépen futó open source telepítések alapból nem biztonságosak és nem éleskészek, és egy alapértelmezett példány minden hálózati interfészre nyitva van, konfigurált hitelesítés nélkül. Ez őszintébb biztonsági oldal, mint amit a legtöbb adatbáziskiadó ad, és egy konkrét ellenőrzőlista tartozik hozzá.

-   Három API-kulcstípus: admin, csak olvasható a kizárólag lekérdező szolgáltatásokhoz, és granuláris kulcsok collectionönkénti olvasási vagy írási joggal.
-   TLS mindkét irányban, plusz hálózati kötés privát interfészre; fejlesztés közben 127.0.0.1-re kötni.
-   Az API-műveletek audit naplózása fájlba, forensics és megfelelőségi bizonyíték céljából, nem insightokhoz.
-   Qdrant Cloudon ugyanez működik, ott ezek a kontrollok alapból aktívak – ez a menedzselt szint valódi érve.
-   A Community, Standard és Premium támogatási szintek a válaszidőben különböznek (négy óra teljes kiesésnél az ingyenes szinten, egy óra Standardon), nem a funkciókban.

**A migráció állítottan nem téma, többnyire**

A cég migrációs eszközt és dokumentációt említ a saját telepítésből a Qdrant Cloudba mozgáshoz, a másik irányban pedig a konténer elég. A vektorokra ez igaz. A körülötte épített dolgokra nem: a Query API fúziós stratégiái és az HNSW hangolása azok a részek, amelyeket fel kell írni, mielőtt elköltözünk.

## Hol gyengül

Öt gyengeséget érdemes nyíltan kimondani, mert ezek döntenek ellene.

-   Egyetlen sűrű index. A dokumentáció szerint a Qdrant sűrű vektorokhoz kizárólag HNSW-t használ. Nincs IVF, nincs lemezen tárolt grafikon és nincs GPU index, így egy olyan korpusz, amely nem fér egy gép RAM-jába, architekturális váltást igényel, nem egy beállítást.
-   A payload indexek az import előtt jönnek létre, vagy sehogy. Az optimalizálás hatékonysága attól függ, hogy betervezünk-e egy migrációt.
-   A vízszintes skálázás valós, de nem ingyenes. A shardok, a replikációs tényezők és a shard-keyt tisztelő olvasások olyan konfiguráció, aminek helyesnek kell lennie, és a kapacitás oldal mindezt a provisionálás előtt kéri eldönteni.
-   A menedzselt szint nem publikál árat. Óránként számol vCPU, memória, tár, mentés és infereciós token alapján, árlista helyett számolóval, és a serverless még mindig a „hamarosan” listán szerepel.
-   A nyilvános benchmark elavult. A gyártó összehasonlító oldala 2024. januárját és júniusát hordozza, így az a következtetés, hogy a Qdrant vezet átvitelnél és késésnél, két évvel ezelőtti szoftverről szól.

Motor

Licenc

Sűrű index lehetőségek

Hol szűrnek

Üzemeltetési forma

Qdrant

Apache-2.0

Csak HNSW, szűrhető

A payload index vezeti a grafikonos bejárást

Egy konténer vagy menedzselt felhő

pgvector

PostgreSQL Licenc

HNSW, IVFFlat

SQL WHERE ugyanazon a táblán

Kiterjesztés egy már futó adatbázisban

Milvus

Apache-2.0

HNSW, IVF, DiskANN, SCANN, GPU

Szorzatos index a motoron belül

Elosztott szolgáltatások, nehéz üzemeltetni

Weaviate

BSD-3-Clause

HNSW, flat, dynamic

Inverz index, natív BM25 hibrid

Eetlen bináris, opcionális klaszter

Pinecone

Saját, csak menedzselt

Saját serverless index

Szolgáltatásoldali szűrés

Nincs mit futtatni, lekérdezésenkénti elszámolás

A rövid változat: pgvector, ha már fut a Postgres és a korpusz belefér; Weaviate, ha a natív hibrid keresés a követelmény; Milvus, ha a számok tényleg százmilliók felé járnak; Pinecone, ha senki sem fog semmit üzemeltetni. A Qdrant a köztük lévő választás, ahol minden lekérdezésen van metaadat-szűrő, és ez fontosabb a plafonnál.

**Mérje a saját recall értékét**

Minden összehasonlítás ezen a területen egy gyártó, aki a saját tesztkörnyezetében fut. A hasznos szám ezért az, amit Ön állít elő: a valódi legközelebbi szomszédok hányadrésze tér vissza az Ön `ef` és `m` értékénél, kvantálással és anélkül. A keresési API pont erre ismer egy pontos módot, és egy futás a saját embeddingjeivel egy délutánt és a vitát eldönt.

## Összegzés

A Qdrant a legjobb nyílt forrású válasz a szűrt vektorsuchnak, és a gyengeségei mind olyan területeken vannak, ahol nem akar nyerni. Ha a lekérdezések gyakorlatilag mindegyikén van tenant, nyelv vagy dátum – és élesben szinte mindig van –, a szűrhető HNSW valódi architekturális előny, nem egy funkciójelölőnégyzet. Válassza úgy, hogy tudja: a sűrű keresésnek egyetlen indexe van, a payload sémának első naptól helyesnek kell lennie, és a biztonsági ellenőrzelistát Ön fogja végigjárni.

1.  Válassza, ha szinte minden lekérdezésen van metaadat-szűrő, és a korpusz tartalékkal egy gép RAM-jába belefér.
2.  Válassza, ha nem akar licencről tárgyalni: Apache-2.0, nincs funkciózár, nincs visszajelzési kötelezettség, nincs használati jelentés.
3.  Válassza, ha a csapata magára vállalja az API-kulcsot, a TLS-tanúsítványt, a mentési ütemtervet és a verziófrissítést.
4.  Ne válassza, ha a korpusz túllépi a RAM méretét, és senkinek nincs kedve elosztott motorra migrálni.
5.  Ne benchmark alapján válasszon. Nézze meg a pontos módban a recall értékét a saját embeddingjeivel, aztán döntsön.

> A saját gépen futó open source telepítések alapból nem biztonságosak és nem éleskészek. Alapértelmezés szerint minden önállóan felállított Qdrant példány minden hálózati interfészre nyitva van, konfigurált hitelesítés nélkül.

## Források

1.  [Qdrant dokumentáció](https://qdrant.tech/documentation/)
2.  [Qdrant: pontok](https://qdrant.tech/documentation/manage-data/points/)
3.  [Qdrant: collectionök](https://qdrant.tech/documentation/concepts/collections/)
4.  [Qdrant: indexelés, payload indexek és a szűrhető HNSW](https://qdrant.tech/documentation/manage-data/indexing/)
5.  [Qdrant: kvantálási módok és memória-szintek](https://qdrant.tech/documentation/manage-data/quantization/)
6.  [Qdrant: kapacitástervezés](https://qdrant.tech/documentation/capacity-planning/)
7.  [Qdrant: teljesítmény optimalizálása](https://qdrant.tech/documentation/ops-optimization/optimize/)
8.  [Qdrant: hibrid és többlépéses lekérdezések](https://qdrant.tech/documentation/concepts/hybrid-queries/)
9.  [Qdrant: szűrőfeltételek](https://qdrant.tech/documentation/concepts/filtering/)
10.  [Qdrant: biztonság és hozzáférés-szabályozás](https://qdrant.tech/documentation/security/)
11.  [Qdrant árazás: ingyenes, standard és premium szintek](https://qdrant.tech/pricing/)
12.  [Qdrant a GitHubon](https://github.com/qdrant/qdrant)
13.  [Qdrant vektor benchmarkok](https://qdrant.tech/benchmarks/)

## Gyakori kérdések

Ingyenes-e a Qdrant éles használatra?

Igen. A szerver Apache-2.0 licencű, az önhostolt használatnak nincs licencdíja, nincs funkciózár és nincs visszajelzési kötelezettség. A cserébe az üzemeltetés: a hitelesítés, a TLS, a mentés, a shard-újraelosztás és a frissítés az Ön dolga. A Qdrant Cloud a menedzselt alternatíva, ingyenes szintje egyetlen csomópont, 1 GB RAM és 4 GB lemez.

Qdrant vagy pgvector?

Néhány millió vektor alatt, egy már amúgy is futó adatbázison a pgvector nyer mindenben a teljesítményt kivéve: egy kiterjesztés egy olyan szolgáltatás helyett, amely miatt valakit fel kell riasztani. A Qdrant akkor érdemli ki a helyét, ha minden lekérdezésen van metaadat-szűrő, mert azt közvetlenül a HNSW bejárásába tudja táplálni ahelyett, hogy jelölteket hozna vissza és eldobná őket.

Mennyibe kerül a Qdrant Cloud?

A gyártó nem publikál belépési árat. Az ároldal óránkénti, használatalapú elszámolást ír le vCPU-ra, memóriára, tárra, mentési tárra és infereciós tokenekre, és hivatkozik egy számolóra; az ingyenes szint 1 GB RAM és 4 GB lemez, a Standard 99,5%-os uptime SLA-t, a Premium SSO-t, privát VPC-linkeket és 99,9%-ot ad. A gyakran idézett, legkisebb fizetős klaszterre vonatkozó körülbelül 25 dolláros havi összeg harmadik fél becslése, nem publikált ár.

Mi történik, ha bekapcsolom a kvantálást?

A tömörített vektorok az eredetiek mellett tárolódnak, tehát semmi nem vész el, és a kvantálás ki is kapcsolható. A top-k újraértékelése az eredeti vektorokon alapértelmezés szerint be van kapcsolva bináris kvantálásnál, valamint TurboQuant esetén 1, 1,5 és 2 bitnél, skálánál és produkt kvantálásnál viszont nincs. Az éles ellenőrzőlista megkívánja a visszakeresési minőség újramérését, mert egyes embedding modellek rosszul kvantálhatók.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026)
-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)