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

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.

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.

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.

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.

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.

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.

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.

Ö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ó
2. Qdrant: pontok
3. Qdrant: collectionök
4. Qdrant: indexelés, payload indexek és a szűrhető HNSW
5. Qdrant: kvantálási módok és memória-szintek
6. Qdrant: kapacitástervezés
7. Qdrant: teljesítmény optimalizálása
8. Qdrant: hibrid és többlépéses lekérdezések
9. Qdrant: szűrőfeltételek
10. Qdrant: biztonság és hozzáférés-szabályozás
11. Qdrant árazás: ingyenes, standard és premium szintek
12. Qdrant a GitHubon
13. Qdrant vektor benchmarkok